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") %>>
|
<li<%= sidebar_current("vs-other") %>>
|
||||||
<a href="/intro/vs/index.html">Nomad vs. Other Software</a>
|
<a href="/intro/vs/index.html">Nomad vs. Other Software</a>
|
||||||
<ul class="nav">
|
<ul class="nav">
|
||||||
<li<%= sidebar_current("vs-other-chef") %>>
|
<li<%= sidebar_current("vs-other-ecs") %>>
|
||||||
<a href="/intro/vs/chef-puppet-etc.html">Chef, Puppet, etc.</a>
|
<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>
|
||||||
|
|
||||||
<li<%= sidebar_current("vs-other-custom") %>>
|
<li<%= sidebar_current("vs-other-custom") %>>
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue