Tag: Fleet
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
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
1 Dec 2015 in Series: Schedulers, Docker, Fleet, Swarm, Overview

Schedulers, Part 1: Basic Monolithic

Scheduling is a method to to assign workloads to resources that can handle those workloads. In a distributed environments, there is a particularly important need for schedulers. Especially ones that provide scalability, are resource aware, and cost effective.

Monolithic schedulers are a single process entity that make scheduling decisions and deploy jobs to be scheduled. These jobs could be a long running server, a short living batch command, a MapReduce query, and so on.

For monolithic scheduler to make decision for scheduling a job, it should observe the resources available in the cluster (e.g. CPU, memory, and so on), lock the resources, schedule the job, and update the available resources.

It’s hard for Monolithic schedulers to deal with more than one job at a time because there is a single resource manager entity a single scheduling entity. Avoiding concurrency makes the system easier to design and easier to understand.

Some examples of monolithic schedulers:

  • fleet: a native scheduler to CoreOS (not resource aware)
  • Swarm: a scheduling backend for Docker containers
  • Kubernetes: an advanced type of monolithic scheduler for Pods (a collection of co-located containers that share same namespaces)

In this post, we'll cover two basic monolithic schedulers.

First we'll look fleet, a scheduler for systemd units. systemd is an advanced init system that that configures and boots Linux userspace. A unit is an individual systemd configuration file that describes a process you’d like to run. We’ll also look at Swarm, a scheduling backend for Docker containers.

Read More