website: finish ECS and Swarm
This commit is contained in:
Armon Dadgar
parent
d0a48a0141
commit
c344bda4b0
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -13,8 +13,32 @@
|
|||
<li<%= sidebar_current("vs-other") %>>
|
||||
<a href="/intro/vs/index.html">Nomad vs. Other Software</a>
|
||||
<ul class="nav">
|
||||
<li<%= sidebar_current("vs-other-chef") %>>
|
||||
<a href="/intro/vs/chef-puppet-etc.html">Chef, Puppet, etc.</a>
|
||||
<li<%= sidebar_current("vs-other-ecs") %>>
|
||||
<a href="/intro/vs/ecs.html">AWS ECS</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-swarm") %>>
|
||||
<a href="/intro/vs/swarm.html">Docker Swarm</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-htcondor") %>>
|
||||
<a href="/intro/vs/htcondor.html">HTCondor</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-kubernetes") %>>
|
||||
<a href="/intro/vs/kubernetes.html">Kubernetes</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-mesos") %>>
|
||||
<a href="/intro/vs/mesos.html">Mesos with Aurora, Marathon, etc</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-terraform") %>>
|
||||
<a href="/intro/vs/terraform.html">Terraform</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-yarn") %>>
|
||||
<a href="/intro/vs/yarn.html">YARN</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-custom") %>>
|
||||
|
|
|
|||
Loading…
Reference in New Issue