From c344bda4b00832000aecadbb177b47971d365ca0 Mon Sep 17 00:00:00 2001 From: Armon Dadgar Date: Sat, 19 Sep 2015 17:45:08 -0700 Subject: [PATCH] website: finish ECS and Swarm --- .../source/intro/vs/chef-puppet-etc.html.md | 45 ------------------- website/source/intro/vs/ecs.html.md | 33 ++++++++++++++ website/source/intro/vs/swarm.html.md | 37 +++++++++++++++ website/source/layouts/intro.erb | 28 +++++++++++- 4 files changed, 96 insertions(+), 47 deletions(-) delete mode 100644 website/source/intro/vs/chef-puppet-etc.html.md create mode 100644 website/source/intro/vs/ecs.html.md create mode 100644 website/source/intro/vs/swarm.html.md diff --git a/website/source/intro/vs/chef-puppet-etc.html.md b/website/source/intro/vs/chef-puppet-etc.html.md deleted file mode 100644 index 01c08f7a1..000000000 --- a/website/source/intro/vs/chef-puppet-etc.html.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -layout: "intro" -page_title: "Nomad vs. Chef, Puppet, etc." -sidebar_current: "vs-other-chef" -description: |- - Comparison between Nomad and configuration management solutions such as Chef, Puppet, etc. ---- - -# Nomad vs. Chef, Puppet, etc. - -A big part of configuring software is setting up secrets: configuring a -web application to talk to a service, configuring the credentials of a -database, etc. Because of this, configuration management systems all face -a problem of safely storing these secrets. - -Chef, Puppet, etc. all solve this in a similar way: single-key -encrypted storage. Chef has encrypted data bags, Puppet has encrypted -Hiera, and so on. The encrypted data is always one secret (a password, -a key, etc.) away from being decrypted, and this secret is generally -not well protected since in an elastic environment, every server needs -to somehow get this secret to decrypt the data. Additionally, access to -the encrypted data isn't always logged, so if there is an intrusion, it -isn't clear what data has been accessed and by who. - -Nomad is not tied to any specific configuration management system. You can -read secrets from configuration management, but you can also use the API -directly to read secrets from applications. This means that configuration -management requires less secrets, and in many cases doesn't ever have to -persist them to disk. - -Nomad encrypts the data onto physical storage and requires multiple -keys to even read it. If an attacker were to gain access to the physical -encrypted storage, it couldn't be read without multiple keys which are generally -distributed to multiple individuals. This is known as _unsealing_, and happens -once whenever Nomad starts. - -For an unsealed Nomad, every interaction is logged in via the audit backends. -Even erroneous requests (invalid access tokens, for example) are logged. -To access any data, an access token is required. This token is usually -associated with an identity coming from a system such as GitHub, LDAP, etc. -This identity is also written to the audit log. - -Access tokens can be given fine-grained control over what secrets can be -accessed. It is rare to have a single key that can access all secrets. This -makes it easier to have fine-grained access for consumers of Nomad. diff --git a/website/source/intro/vs/ecs.html.md b/website/source/intro/vs/ecs.html.md new file mode 100644 index 000000000..343670f9b --- /dev/null +++ b/website/source/intro/vs/ecs.html.md @@ -0,0 +1,33 @@ +--- +layout: "intro" +page_title: "Nomad vs. AWS ECS" +sidebar_current: "vs-other-ecs" +description: |- + Comparison between Nomad and AWS ECS +--- + +# Nomad vs. AWS ECS + +Amazon Web Services provides the EC2 Container Service (ECS), which is +a cluster manager. The ECS service is only available within AWS and +can only be used for Docker workloads. Amazon provides customers with +the agent that is installed on EC2 instances, but does not provide +the servers which are a hosted service of AWS. + +There are a number of fundamental differences between Nomad and ECS. +Nomad is completely open source, including both the client and server +components. By contrast, the only the agent code for ECS is open and +the servers are closed sourced and managed by Amazon. + +As a side affect of the ECS servers being managed by AWS, it is not possible +to use ECS outside of AWS. Nomad is agnostic to the environment it is run. +Nomad supports all public and private clouds, as well as bare metal datacenters. +Clusters in Nomad can span multiple datacenters and regions, meaning +a single cluster could be managing machines on AWS, Azure and GCE simultaneously. + +The ECS service is specifically focused on containers and the Docker +engine, while Nomad is more general purpose. Nomad supports virtualized, +containerized and standalone applications, including Docker. Nomad is +designed with extensible drivers and support will be extended to all +common drivers. + diff --git a/website/source/intro/vs/swarm.html.md b/website/source/intro/vs/swarm.html.md new file mode 100644 index 000000000..750fef565 --- /dev/null +++ b/website/source/intro/vs/swarm.html.md @@ -0,0 +1,37 @@ +--- +layout: "intro" +page_title: "Nomad vs. Docker Swarm" +sidebar_current: "vs-other-swarm" +description: |- + Comparison between Nomad and Docker Swarm +--- + +# Nomad vs. Docker Swarm + +Docker Swarm is the native clustering solution for Docker. It provides +an API compatible with the Docker Remote API, but allows containers to +be scheduled across many machines. + +Nomad differs in many ways with Docker Swarm. Most obviously, Docker Swarm +can only be used to run Docker containers, while Nomad is more general purpose. +Nomad supports virtualized, containerized and standalone applications, including Docker. +Nomad is designed with extensible drivers and support will be extended to all +common drivers. + +Docker Swarm provides API compatibility with their remote API, which focuses +on the container abstraction. Nomad uses a higher-level abstraction of jobs. +Jobs contain task groups, which are sets of tasks. This allows more complex +applications to be expressed and easily managed without reasoning about the +individual containers that compose the application. + +The architectures also differ between Nomad and Docker Swarm. +Nomad does not depend on external systems for coordination or storage, +is distributed, highly available, and supports multi-datacenter +and multi-region configurations. + +By contrast, Swarm is not distributed or highly available by default. +External systems must be used for coordination to support replication. +When Swarm has replication enabled, it uses an active/standby model, +meaning the other servers cannot be used to make scheduling decisions. +Swarm does not support multiple failure isolation regions or federation. + diff --git a/website/source/layouts/intro.erb b/website/source/layouts/intro.erb index 7dce7ed64..f3db5c99f 100644 --- a/website/source/layouts/intro.erb +++ b/website/source/layouts/intro.erb @@ -13,8 +13,32 @@ > Nomad vs. Other Software