CoreOS is designed for security, consistency, and reliability. Instead of installing packages via yum or apt, CoreOS uses Linux containers to manage your services at a higher level of abstraction. A single service's code and all dependencies are packaged within a container that can be run on one or many CoreOS machines.
Linux containers provide similar benefits as complete virtual machines, but focused on applications instead of entire virtualized hosts. Since containers don’t run their own Linux kernel or require a hypervisor, they have almost no performance overhead. The lack of overhead allows you to gain density which means fewer machines to operate and a lower compute spend.
CoreOS runs on almost any platform, including Vagrant, Amazon EC2, QEMU/KVM, VMware and OpenStack and your own hardware. If you're currently running in the cloud, running a single CoreOS cluster on two different clouds or cloud + bare metal is supported and encouraged.
Let’s walk through each of the building blocks of CoreOS — etcd, docker and systemd.
The main building block of CoreOS is docker, a Linux container engine, where your applications and code run. Docker is installed on each CoreOS machine. You should construct a container for each of your services (web server, caching, database) and connect them together by reading and writing to etcd.
CoreOS doesn't ship a package manager — any software you would like to use must run within a container. You can quickly try out a Ubuntu container in the step by step tutorial. The end goal is to have your build system output a container as the final artifact. CoreOS uses systemd to manage the containers that need to be started based on the resulting build artifact.
Each host provides a local endpoint for etcd, which is used for service discovery and reading/writing configuration values. Since etcd is replicated, all changes are reflected across the entire cluster. Your application can always reach the local etcd instance at 127.0.0.1:4001.
Let's say we're running a simple web app like Wordpress. Instead of hardcoding our database address with in the config file, we'll fetch it from etcd instead. It's as simple as curl-ing http://127.0.0.1:4001/v1/keys/database and using the response within your DB connection code.
A more advanced example involves service discovery for a proxy. Each of your app containers can announce itself to etcd after starting up and your proxy is listening for changes on the same value. Now your proxy container automatically knows when to reconfigure itself and new containers automatically receive traffic. Building service discovery into your application allows you to add more machines and scale your services seamlessly.
CoreOS provides stable, reliable, updates to all machines as long as they can connect to our update service. We believe that automatic updates are critical to keeping a system secure. All updates are signed offline from the build process and each update's metadata is transmitted to the machine via an SSL cert signed by our private CA. This metadata is verified against the downloaded update before it is applied to the machine.
The recommended way to secure your entire cluster is to use a physical firewall, EC2 Security Groups or a similar feature to restrict all traffic unless allowed. If you're running containers that are used for load balancing or caching, consider exposing the ports for those containers instead of all containers. You can even automate this process with etcd.