From e545993db36f55c6ef6b281330589e9060bc0a52 Mon Sep 17 00:00:00 2001 From: Dennis Date: Sun, 6 Mar 2016 14:28:58 -0800 Subject: [PATCH 1/2] Nulecule, containerd, cgroup/namespace, p24e.io * Since we have systemd-nspawn, I would like to propose we add the process supervision analog in the Dockersphere world whic is containerd. There is a pointer the blog entry announcing this project just as of December. It is meant to be compatible with any OCI compliant runtime and supports advanced features like checkpointing and socket activation already. Not bad, but it is in alpha stage. * Nulecule is a, unique, project to allow the definition of a multi-container or pod infrastructure across many hosts and then feeds that data to the likes of Kubernetes, Mesos, or Docker-Compose. There is a short slideshare preso here: http://www.slideshare.net/then4way/project-atomicnulecule I'd like to propose we add this to the blog as well. Also, this change proposes a couple of hyperlinks to cgroups, namespaces, and another site which seems to list all of the areas of concern of a modern infrastructure as well as some other niche projects, but almost no details on those projects though. --- content/post/layers-in-the-stack.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/content/post/layers-in-the-stack.md b/content/post/layers-in-the-stack.md index 057fd70..3fabcc1 100644 --- a/content/post/layers-in-the-stack.md +++ b/content/post/layers-in-the-stack.md @@ -24,7 +24,7 @@ So, with that, here is a brain dump of the parts that make up a "modern" stack: * The standard config tools ([Puppet](https://puppetlabs.com/), [Chef](https://www.chef.io/), [Ansible](http://www.ansible.com/home), [Salt](http://saltstack.com/)) can serve this role. * [CoreOS Fleet](https://coreos.com/using-coreos/clustering/) is a lightweight clustering system that can also be used to bootstrap more comprehensive solutions. * **Container Engine**. This is the system for setting up and managing containers. It is the primary management agent on the node. - * Examples include [Docker Engine](https://www.docker.com/docker-engine), [CoreOS rkt](https://coreos.com/rkt/docs/latest/), and [LXC](https://linuxcontainers.org/) and [systemd-nspawn](http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html). + * Examples include [Docker Engine](https://www.docker.com/docker-engine)-[containerd](https://blog.docker.com/2015/12/containerd-daemon-to-control-runc/), [CoreOS rkt](https://coreos.com/rkt/docs/latest/), and [LXC](https://linuxcontainers.org/) and [systemd-nspawn](http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html). * Some of these systems are more amenable to being directly controlled remotely than others. * The [Open Container Initiative](https://www.opencontainers.org/) is working to standardize the input into these systems -- basically the root filesystem for the container along with some common parameters in a JSON file. * **Container Image Packaging and Distribution.** A Container Image is a named and cloneable chroot that can be used to create container instances. It is pretty much an efficient way to capture, name and distribute the set of files that make up a container at runtime. @@ -34,7 +34,7 @@ So, with that, here is a brain dump of the parts that make up a "modern" stack: * **Container Image Registry/Repository.** This is a central place to store and load Container Images. * Hosted versions of this include the [Docker Hub](https://hub.docker.com/), [Quay.io (owned by CoreOS)](https://quay.io), and [Google Container Registry](https://cloud.google.com/container-registry/). * Docker also has an open source registry called [Docker Distribution](https://github.com/docker/distribution). - * Personally, I'm hoping that the state of the art will evolve past centralized solutions with specialized APIs to solutions that are simpler by working regular HTTP and more transport agnostic so that protocols like BitTorrent can be used to distribute images. + * Personally, I'm hoping that tche state of the art will evolve past centralized solutions with specialized APIs to solutions that are simpler by working regular HTTP and more transport agnostic so that protocols like BitTorrent can be used to distribute images. * **Container Distribution.** This is the system for structuring what is running inside of a container. Many people don't talk about this as a separate thing but instead reuse OS distributions such as Ubuntu, Debian, or CentOS. * Many folks are working to build minimal container distributions by either using distributions based in the embedded world (BusyBox or Alpine) or by building [static binaries](https://medium.com/@kelseyhightower/optimizing-docker-images-for-static-binaries-b5696e26eb07) and not needing anything else. * Personally, I'd love to see the idea of a Container Distribution be further developed and take advantage of features only available in the container world. I wrote a [blog post](http://www.eightypercent.net/post/new-container-image-format.html) on this. @@ -47,6 +47,7 @@ So, with that, here is a brain dump of the parts that make up a "modern" stack: * [AWS CloudFormation](https://aws.amazon.com/cloudformation/) and [Google Cloud Deployment Manager](https://cloud.google.com/deployment-manager/overview) play this role for their respective cloud ecosystems (only). * [Hashicorp Terraform](https://github.com/hashicorp/terraform) and [Flabbergast](http://flabbergast.org/) look like they could be applied to container orchestration systems but haven't yet. * [Docker Compose](https://docs.docker.com/compose/) is a start to a more comprehensive config system. + * [Nulecule](http://www.projectatomic.io/docs/nulecule/): [pronounce: newly-cool]A RedHat project that allows you to describe a multi-container application including all dependencies. It is also container independent. It supports parameterization, inheritence, and variable substitution among others and building a graph of your dependencies. It utilizes Kubernetes, OpenShift, Docker Compose, or Mesos as 'providers.' * The Kubernetes team (Brian Grant especially) have lots of [ideas and plans](https://github.com/kubernetes/kubernetes/labels/area%2Fapp-config-deployment) for this area. There is a [Kubernetes SIG](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs%29) being formed. * **Network Virtualization.** While not strictly necessary, clustered container systems are much easier to use if each container has full presence on the cluster network. This has been referred to as "IP per Container". * Without a networking solution, orchestration systems must allocate and enforce port assignment as ports per host are a shared resource. @@ -87,7 +88,13 @@ PaaS systems often help to bring this all together in an easy way. Systems like Next on the list would be to talk about continuous integration/continuous deployment (CI/CD) systems and systems for communicating between microservices (RPC and queues). But I think I'll stop here. If this is useful (or if you think I'm missing anything huge) please let me know via [twitter](https://www.twitter.com/jbeda). Or you can comment on the [Hacker News thread](https://news.ycombinator.com/item?id=10187598). -[^other-posts]: [Brandon Philips](https://twitter.com/brandonphilips) from CoreOS points me to a [similar post](https://coreos.com/blog/cluster-osi-model/) from [Barak Michener](https://twitter.com/barakmich). I go into more minutia here and don't try and define a strict stack. +[^other-posts]: +* [Brandon Philips](https://twitter.com/brandonphilips) from CoreOS points me to a [similar post](https://coreos.com/blog/cluster-osi-model/) from [Barak Michener](https://twitter.com/barakmich). I go into more minutia here and don't try and define a strict stack. +* The [Programmable Infrastructure](http://programmableinfrastructure.com/) website appears to try to be an exhaustive list of projects used in a modern infrastructures. + +[^ the extremely technical on containers] +At the lowest levels a container utilizes two main facilities in the kernel. The LWN has two multi-part series describing these features [cgroups](https://lwn.net/Articles/604609/) and [namespaces](https://lwn.net/Articles/531114/). For more up-to date documentation the Kernel Documentation is best. + [^caveats]: Some caveats: @@ -97,4 +104,4 @@ Next on the list would be to talk about continuous integration/continuous deploy * I've listed example projects/products/companies/systems at different levels but this isn't meant to be exhaustive. * The fact that I've listed a system here doesn't mean that I've run it in production and it has my stamp of approval. -[^flume]: Don't confuse Apache Flume with [Google FlumeJava](http://research.google.com/pubs/pub35650.html). I guess once you start processing logs some names are just obvious. Also see [Google Sawzall](http://research.google.com/archive/sawzall.html) and [Google Dremel](http://research.google.com/pubs/pub36632.html). \ No newline at end of file +[^flume]: Don't confuse Apache Flume with [Google FlumeJava](http://research.google.com/pubs/pub35650.html). I guess once you start processing logs some names are just obvious. Also see [Google Sawzall](http://research.google.com/archive/sawzall.html) and [Google Dremel](http://research.google.com/pubs/pub36632.html). From 801ed452a83867ccf5ca2a4f59b88d158aca73fd Mon Sep 17 00:00:00 2001 From: Dennis Date: Sun, 6 Mar 2016 18:14:22 -0800 Subject: [PATCH 2/2] Update layers-in-the-stack.md --- content/post/layers-in-the-stack.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/post/layers-in-the-stack.md b/content/post/layers-in-the-stack.md index 3fabcc1..a1f6abf 100644 --- a/content/post/layers-in-the-stack.md +++ b/content/post/layers-in-the-stack.md @@ -34,7 +34,7 @@ So, with that, here is a brain dump of the parts that make up a "modern" stack: * **Container Image Registry/Repository.** This is a central place to store and load Container Images. * Hosted versions of this include the [Docker Hub](https://hub.docker.com/), [Quay.io (owned by CoreOS)](https://quay.io), and [Google Container Registry](https://cloud.google.com/container-registry/). * Docker also has an open source registry called [Docker Distribution](https://github.com/docker/distribution). - * Personally, I'm hoping that tche state of the art will evolve past centralized solutions with specialized APIs to solutions that are simpler by working regular HTTP and more transport agnostic so that protocols like BitTorrent can be used to distribute images. + * Personally, I'm hoping that the state of the art will evolve past centralized solutions with specialized APIs to solutions that are simpler by working regular HTTP and more transport agnostic so that protocols like BitTorrent can be used to distribute images. * **Container Distribution.** This is the system for structuring what is running inside of a container. Many people don't talk about this as a separate thing but instead reuse OS distributions such as Ubuntu, Debian, or CentOS. * Many folks are working to build minimal container distributions by either using distributions based in the embedded world (BusyBox or Alpine) or by building [static binaries](https://medium.com/@kelseyhightower/optimizing-docker-images-for-static-binaries-b5696e26eb07) and not needing anything else. * Personally, I'd love to see the idea of a Container Distribution be further developed and take advantage of features only available in the container world. I wrote a [blog post](http://www.eightypercent.net/post/new-container-image-format.html) on this.