{"id":1374,"date":"2019-02-26T10:55:34","date_gmt":"2019-02-26T10:55:34","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=1374"},"modified":"2019-03-07T20:43:48","modified_gmt":"2019-03-07T20:43:48","slug":"announcing-rancheros-a-minimalist-distro-designed-explicitly-to-run-docker","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2019\/02\/26\/announcing-rancheros-a-minimalist-distro-designed-explicitly-to-run-docker\/","title":{"rendered":"Announcing RancherOS: A minimalist distro designed explicitly to run Docker"},"content":{"rendered":"

Today I would like to announce a new open source project called
\nRancherOS \u2013 the smallest, easiest way to run Docker in production and
\nat scale. RancherOS is the first operating system to fully embrace
\nDocker, and to run all system services as Docker containers. At Rancher
\nLabs we focus on building tools that help customers run Docker in
\nproduction, and we think RancherOS will be an excellent choice for
\nanyone who wants a lightweight version of Linux ideal for running
\ncontainers.
\n\"rancherOS_logo_black\"<\/a><\/p>\n

##<\/p>\n

How RancherOS began<\/h2>\n

The first question that arises when you are thinking about putting
\nDocker in production is which OS to use. The simplest answer is to run
\nDocker on your favorite Linux distribution. However, it turns out the
\nreal answer is a bit more nuanced. After running Docker on just about
\nevery distro over the last year, I eventually decided to create a
\nminimalist Linux distribution that focuses explicitly on running Docker
\nfrom the very beginning. Docker is a fast-moving target. With a constant
\ndrum beat of releases, it is sometimes difficult for Linux distributions
\nto keep up. In October 2013, I started working very actively with
\nDocker, eventually leading to an open source project called Stampede.io.
\nAt that time I decided to target one Linux distribution that I thought
\nto be the best for Docker since it was included by default. With
\nStampede.io, I was pushing the boundaries of what was possible with
\nDocker and able to do some fun things like run libvirt and KVM in Docker
\ncontainers. Consequentially I always needed the latest version of
\nDocker, which was problematic. At the time, Docker was releasing new
\nversions each month (currently Docker is on a two month release cycle).
\nIt would often take over a month for new Docker versions to make it to
\nthe stable version of the Linux distro. Initially, this didn\u2019t seem like
\na bad proposition because undoubtedly, a new Docker release couldn\u2019t be
\nconsidered \u201cstable\u201d on day one, and I could always use alpha releases of
\nmy distribution of choice. However, alpha distribution releases include
\nother recently released software, not just Docker but alpha kernel and
\nalpha versions of other software. With RancherOS we addressed this by
\nlimiting the OS to just the things we need to run Docker, specifically,
\nthe Linux kernel, Docker and the bare minimum amount of code needed to
\njoin the two together. Picking which version of RancherOS to run is as
\neasy as saying which version of Docker you wish to run. The sole purpose
\nof RancherOS is to run Docker and therefore our release schedule is
\nclosely aligned. All other software included in the distribution is
\nconsidered stable, even if you just picked up the latest and greatest
\nDocker version.<\/p>\n

An OS where everything is a container<\/h2>\n

When most people think of Docker they think about running applications.
\nWhile Docker is excellent at that, it can also be used to run system
\nservices thanks to recently added capabilities. Since first starting
\nRancher (our Docker orchestration product), we\u2019ve wanted the entire
\norchestration stack to be packaged by and run in Docker – not just the
\napplication we were managing. This was initially quite difficult, since
\nthe orchestration stack needed to interact with the lower level
\nsubsystems. Nevertheless, we carried on with many \u201chacks\u201d to make it
\npossible. Once we determined the features we needed within Docker, we
\nhelped and encouraged the development of those items. Finally, with
\nDocker 1.5, we were able to remove the hacks, paving the way for
\nRancherOS. Docker now allows sufficient control of the PID, IPC,
\nnetwork namespaces and capabilities. This means it is now possible to
\nrun systems oriented processes within Docker containers. In RancherOS we
\nrun absolutely everything in a container, including system services such
\nas udev, DHCP, ntp, syslog, and cloud-init.
\n\"rancherOS_lighter\"<\/p>\n

A Linux distro without systemd<\/h2>\n

I have been running systemd and Docker together for a long time. When I
\nwas developing Stampede.io I initially architected the system to run on
\na distribution that heavily leveraged systemd. I started to notice a
\nnumber of strange errors when testing real world failure scenarios.
\nHaving previously run production cloud infrastructure, I cared very much
\nabout reliably managing things at scale. Having seen odd errors with
\nsystemd and Docker I started digging into the issue. You can see most of
\nmy comments in this Docker
\nissue<\/a> and this mailing
\nlist
\nthread<\/a>.
\nAs it turns out, systemd cannot effectively monitor Docker containers
\ndue to the incompatibility with the two architectures. While systemd
\nmonitors the Docker client used to launch the Docker container, this is
\nnot really helpful and I worked hard with both Docker and systemd
\ncommunities to fix the issue. I even went so far as to create an open
\nsource project called
\nsystemd-docker<\/a>. The
\npurpose of the project was to create a wrapper for Docker that attempted
\nto make these two systems work well together. While it fixed many of the
\nissues, there were still some corner cases I just couldn\u2019t address.
\nRealizing things must change in either Docker or systemd I shifted focus
\nto talking to
\nboth<\/a>
\nof
\nthem<\/a>.
\nWith the announcement of Rocket more effort is being put into making
\nsystemd a better container runtime. Rocket, as it stands today, is
\nlargely a wrapper around
\nsystemd<\/a>.
\nAdditionally, systemd itself has since added native support for pulling
\nand running Docker
\nimages<\/a> which
\nseems to indicate that they are more interested in subsuming container
\nfunctionalities in systemd than improving interoperability with Docker.
\nUltimately, all signs continue to point to no quick resolution between
\nthese two projects. When looking at our use case for RancherOS, we
\nrealized we did not need systemd to run Docker. In fact, we didn\u2019t need
\nany other supervisor to sit at PID 1. Docker was sufficient in itself.
\nWhat we have done with RancherOS is run what we call \u201cSystem Docker\u201d as
\nPID 1. All containers providing core system services are run from System
\nDocker, which also launches another Docker daemon which we call \u201cUser
\nDocker\u201d under which we run user containers. This separation is quite
\npractical. Imagine a user did docker rm -f $(docker ps -qa). You run
\nthe risk of them deleting the entire operating system.<\/p>\n

Minimalist Linux distributions<\/h2>\n

As users look at shifting workloads to containers, dependencies on the
\nhost system become dramatically less. All current minimalist Linux
\ndistributions have taken advantage of this fact, allowing them to
\ndrastically slim down their footprint. I love the model distributions
\nsuch as CoreOS have pioneered and we have been inspired by them. By
\nconstraining the use case of RancherOS to running Docker, we decided
\nonly core system services (logging, device management, alerting) and
\naccess (console, ssh) were required. With the ability to run these
\nservices in containers, all we needed was the container system itself
\nand a bit of bootstrap code (to get networking up, for example). If you
\ntake this one step further and put the server under the management of a
\nclustering\/orchestration system, you can even minimize the need to run a
\nfull console.<\/p>\n

First Meetup<\/h2>\n

On March 31st, I\u2019ll be hosting an online meet up to demonstrate
\nRancherOS, discuss some of the features we are working on, and answer
\nany questions you might have. If you would like to learn more, please
\nregister now:<\/p>\n

Conclusion<\/h2>\n

When we looked at simplifying large scale deployments of Docker, there
\nwere no solutions available that truly embraced Docker. We started the
\nRancherOS project because we love Docker and feel we can significantly
\nsimplify the Linux distribution necessary to run it. Hopefully, this
\nwill allow users to focus more on their container workloads and less on
\nmanaging the servers running them. If you\u2019re primary requirement for
\nLinux is to run Docker, we\u2019d love for you to give RancherOS a try and
\nlet us know what you think. You can find everything
\nat https:\/\/github.com\/rancherio\/os<\/a>.<\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Today I would like to announce a new open source project called RancherOS \u2013 the smallest, easiest way to run Docker in production and at scale. RancherOS is the first operating system to fully embrace Docker, and to run all system services as Docker containers. At Rancher Labs we focus on building tools that help … <\/p>\n

Continue reading “Announcing RancherOS: A minimalist distro designed explicitly to run Docker”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1374","post","type-post","status-publish","format-standard","hentry","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1374","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/comments?post=1374"}],"version-history":[{"count":1,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1374\/revisions"}],"predecessor-version":[{"id":1447,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1374\/revisions\/1447"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/media?parent=1374"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/categories?post=1374"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/tags?post=1374"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}