At this point we’ve deployed three hosts in our first and second CoreOS posts. Now we can do some of the really cool stuff fleet is capable of doing on CoreOS! Again – I’ll apologize that we’re getting ahead of ourselves here but I really want to give you a demo of what CoreOS can do with fleet before we spend a few posts diving into the details of how it does this. So let’s dive right back in where we left off…
We should have 3 CoreOS hosts that are clustered. Let’s verify that by SSHing into one of CoreOS hosts…
Looks good, the cluster can see all three of our hosts. Let’s start work on deploying our first service using fleet.
Fleet works off of unit files. This is a systemd construct and one that we’ll cover in greater detail in the upcoming systemd post. For now, let’s look at what a fleet unit file might look like…
Note: These config files are out on my github account – https://github.com/jonlangemak/coreos/
Systemd works off of units and targets. Suffice to say for now, the fleet service file describes a service we’d like to run. In this case, the ‘Unit’ chunk of the service file defines the service and what services need to be running for this service to launch. As you can see here, we’re relying on the docker service. This makes sense since this service file attempts to launch a container. The ‘Service’ chunk of the file lists specifics about how to start and stop the service. Again, we’ll dive into this in much greater detail later but you can see that the start command appears to be launching a container. We can see that it’s called webserver1 and that the image is ‘jonlangemak/coreos:webserver1’. This piece is important. The image we want to load is in a public repo called ‘jonlangemak/coreos’. This is a public repo so you should be able to access it if you want to reproduce this in your own lab. The repo location is here…
https://registry.hub.docker.com/u/jonlangemak/coreos/
In addition of the Web Server 1 service file I also have service files for Web Server 2 and 3. Those configurations look like this…
So let’s copy these over to one of the CoreOS hosts so we can load them into fleet…
Now that they’re on the host, we can load them into fleet. Fleet refers to these service files as ‘unit’ files. To get them into fleet we can use the ‘submit’ command…
Once they’re submitted we can list the unit files that fleet is aware of. Now, all we have to do is tell fleet to launch the services. Let’s start by launching webserver1.service…
Now let’s take a look and see the status of the unit we just launched…
It looks like the unit got launched on the current host we are on (coreOS1). Let’s take a look at docker and see what’s going on…
We can see that docker downloaded a container image called ‘jonlangemak/coreos:webserver1’. In addition, it started the container and its currently running with port 80 on the CoreOS host mapped to port 80 on the container. Let’s check and see what that gives us…
On each of the container images I’ve loaded the Apache service that is serving up a couple of files. First is a index.php page that shows the overall status page. In addition each container image has a localpage.html file which shows a basic HTML page describing the local container. So to quickly break it down, the container layout looks like this…
Basically – This means that I can browse to each container on its respective port and see the main status page. The status page queries all of the possible CoreOS nodes on ports 80, 81, and 82 so we can see which container is running on which host. The reason for the different ports is so that each container can run on the same CoreOS node. So let’s start the other 2 service units with fleet…
As you can see, fleet has deployed the 2 service units we just started on the other two CoreOS nodes. Pretty cool huh? Let’s check out status page again…
Cool! So fleet has deployed all 3 containers across all 3 hosts. Before we go further, let’s break down what happened…
1 – We loaded the service unit file into fleet
2 – We tell fleet to start the unit
3 – Fleet picks a CoreOS node and deploys the service on the node
4 – The service starts and docker is told to run the defined container image
5 – Since the container image doesn’t exist locally, docker downloads it from the public repo
6 – Once the image is downloaded, the image is started
Note that step 5 can take some time since the public repo is out on the internet. Give docker some time to download the image. In my experience this takes less than 2 minutes.
So now what happens if a host goes offline? For instance, let’s shutdown node CoreOS1…
Note: Since the index.php page is on all 3 containers you can pick anyone to check page status. For instance, since the webserver3 container is running on CoreOS2 (10.20.30.113) I can browse to http://10.20.30.113:82
It doesn’t take long after telling CoreOS1 to shutdown that our status page reflects the container going offline…
Let’s check the fleet status on CoreOS2 and see what’s going on…
Interesting, it says that webserver1.service is now running on CoreOS2 (10.20.30.112). Let’s check docker…
Sure enough! Fleet say CoreOS go down and moved the container to CoreOS2. Let’s check the status page again…
Awesome! So as we can see, Fleet is a pretty powerful container scheduling system that keeps track of container status and reschedules as needed. In the post I do dedicated to fleet we’ll dive more into some of the other options we have with Fleet in regards to tuning the cluster. For now, I just wanted to give you the chance to get this up and running on your own so you can start playing around and see how powerful CoreOS is.