Tag: CoreOS
12 Apr 2016 in Series: Fleet on CoreOS, Fleet, CoreOS

Fleet on CoreOS, Part Two

In my previous post, we learnt how fleet automatically reshuffles services across your cluster whenever a node fails to keep your app available. To be more specific, the code running on the failed node is automatically moved to one of the other healthy nodes in the cluster, and from the outside, your app continues to run smoothly.

If you’re interested in understanding more about how fleet fits into CoreOS, we go into that in a previous post about self-sufficient containers.

In this post, I explain that commands you can use to interact with fleet. This will lay the foundation for more advanced uses of fleet in subsiquent posts. But, before diving into commands, let's revisit unit files. This is important because most of the fleet commands are about handling unit files.

Read More
11 Mar 2016 in Series: Fleet on CoreOS, Fleet, CoreOS

Fleet on CoreOS, Part One

Servers crash all the time. But it is important to make sure applications, and hence the business, doesn’t suffer. This is why service availability is one of biggest concerns for operational engineers deploying applications in the cloud.

Fleet—a CoreOS tool—solves this problem and frees you from worry by automatically routing application execution to healthy nodes.

So, how does this work?

How does Fleet know if a node is down? How does the rerouting happen?

We covered this in detail in a previous post. But if you’re in a hurry, I will recap.

Each node in a CoreOS cluster runs the fleet daemon, which keeps a tab on the node’s health and is responsible for communicating with other nodes. The daemons coordinate to elect a leader during cluster startup, or when the current leader fails. The leader schedules new services on the nodes whenever a new service request is submitted to the cluster, or when a node goes down taking services with it.

In this miniseries, we’ll get some services up-and-running on a cluster, then take down a node to see how fleet reshuffles things. We’ll then move on and take a closer look at some additional fleet functionality.

Read More
12 Feb 2016 in Series: CoreOS Overview, CoreOS, Overview

CoreOS Overview, Part Three

This post is available in: Chinese`

This is the third and final post in a series looking at CoreOS.

In my last post, we looked at the cloud-config file, running etcd in proxy mode, and some common etcd cluster setups.

In this post, we take a closer look at systemd, unit files, Fleet, and fleetctl.

systemd Overview

systemd is an init system used by CoreOS that provides many powerful features for starting, stopping, monitoring, and restarting process. On CoreOS, systemd is used to manage the lifecycle of your Docker containers and also for different system bootstrap tasks.

Learning systemd would need a series of blog posts in itself. Here we only cover systemd to the extent that we need to run systemd units for Docker containers on CoreOS.

For more information about systemd, see the documentation.

Read More
5 Feb 2016 in Series: CoreOS Overview, CoreOS, Overview

CoreOS Overview, Part Two

This post is available in: Chinese`

This is the second post in a series looking at CoreOS.

In my last post, we looked at how CoreOS is different from other Linux systems, atomic upgrades and release channels, and the basics of cluster discovery.

In this post, we take a closer look at cloud-config and etcd. We'll also look at a few common cluster architectures.


Cloud-config allows you to declaratively customize various OS-level items, such as network configuration, user accounts, and systemd units (which we'll cover the next post). This came from Ubuntu and was modified a bit to fit the needs of CoreOS.

At the core of every CoreOS cluster machine, there is the bootstrap mechanic coreos-cloudinit. The coreos-cloudinit program the cloud-config file when it configures the OS after startup or during runtime.

Read More
3 Feb 2016 in etcd, CoreOS, Overview

etcd on CoreOS

In my last post, we learnt about CoreOS installation on AWS EC2 instances. Specifically, we saw how to create a CoreOS cluster with three nodes and connect to nodes from terminal window.

One of the main building blocks of CoreOS is etcd, a distributed key-value store. When applications run on a cluster, accessing application config data in a consistent manner is a problem, since using the underlying system’s file system is not feasible.

If you want to build a failsafe cluster, application config needs to be available across the cluster. etcd solves this problem. Think of it as a file system available across all the cluster nodes. See my previous post that discusses etcd in more detail.

In this post, we’re going to look at how to use etc in real-life scenarios.

Read More
29 Jan 2016 in Series: CoreOS Overview, CoreOS, Overview

CoreOS Overview, Part One

This post is available in: Chinese

CoreOS is an important part of many container stacks. In this series of posts, we’re going to take a look at CoreOS, why it’s important, and how it works. If you don’t know anything about CoreOS already, don’t worry. We start at the beginning.

The Basics and How CoreOS Is Different From Other Linux Systems

CoreOS is designed for security, consistency, and reliability.

  • Automatic CoreOS updates are done using an active/passive dual-partition scheme to update CoreOS as a single unit, instead of using a package-by-package method. We go over this in detail later.

  • 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 a single CoreOS machine or many CoreOS machines in a cluster.

  • Linux containers provide similar benefits to complete virtual machines, but are focused on applications instead of entire virtualized hosts. Because 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, OpenStack, and your own bare-metal hardware.

Read More
22 Jan 2016 in CoreOS, AWS, Tutorial

Production CoreOS on AWS EC2

In previous posts, we learnt about installing CoreOS on VirtualBox to get you up to speed with cloud-config files and the general installation process. We also learnt about various CoreOS components, such as systemd, fleet, and etcd. However, if you want to run CoreOS in production, there are several other things to take care of: security, system failures, cluster scaling, and remote access, to name just a few.

CoreOS ensures scalability and failsafe clustering out of the box. And cloud deployment is the way to go if you want scalable, secure infrastructure. But how do you get a CoreOS cluster running in the cloud? There are several related questions. Do you need to install CoreOS on all the nodes separately? What about the cloud-config files? How does a cluster get defined logically?

In this post I’ll go over the CoreOS installation process and hopefully answer these questions for you.

Read More
17 Dec 2015 in CoreOS

Get Started With CoreOS on OS X

In one of our recent posts we have covered how to install CoreOS with VirtualBox.

In this post, we learn how to run CoreOS without VirtualBox.

This setup is specific to OS X as it uses xhyve, which is built on top of Hypervisor.framework introduced in OS X 10.10.


We’re going to use the CoreOS VM application, which is an independent open source project that bundles CoreOS into a VM for running on OS X.

The CoreOS VM app uses the new corectl tool to manage xhyve-based VMs.

First, download the CoreOS VM app.

The CoreOS VM App does not have many dependencies to download. Everything needed is already included. However, the app will perform some automatic downloads on your behalf., they include CoreOS ISO file needed to run the VM, as well as Docker and fleetctl clients for OS X.

Read More
8 Dec 2015 in CoreOS, Containers, Fleet, Etcd

Run Self-Sufficient Containers on CoreOS

In my last post we learnt about CoreOS and took a look at the steps needed to install it on your laptop (using VirtualBox). We also learnt CoreOS doesn’t ship a package manager. Instead it comes with Docker pre-installed. So, for every service that you need (e.g. web server, database, cache, and so on) you can just create and use a Docker container for it.

So, what’s the deal with self-sufficient containers?

Containers are self-sufficient by default, right? Well, this depends on what you call self-sufficient. Of course, containers are self-sufficient in that they don’t depend on any software running outside of their logical boundaries. But they need kernel support and computing resources from the host computer.

Let’s see it like this: containers are generally set up on a network with several nodes, with each node running one or more containers. Each container may be self-sufficient, but the node on which the container is supposed to run is not! Nodes may crash or run slow or get disconnected off the network. And in such cases, you need to find out the offline node and re-route the traffic meant for that node to other nodes.

But how do we do that?

Enter CoreOS and three particularly crucial components: systemd, fleet, and etcd.

In this post, we’ll take a look at these three components and learn how they’re used by CoreOS to help you create self-sufficient containers.

Read More