If you’re not familiar already, Rancher is an orchestration and scheduling tool for containers. I have written a little bit about Rancher in the past but haven’t covered much on the specifics about how to manage a Rancher environment. One cool thing about Rancher is its “single pane of glass” approach to managing servers and containers, which allows users and admins to quickly and easily manage complicated environments. In this post I’ll be covering how to quickly and automatically add servers to your Rancher environment.
One of the manual steps that can(and in my opinion should) be automated is the server bootstrapping process. The Rancher web interface allows users to add hosts across different cloud providers (AWS, Azure, GCE, etc) and importantly the ability to add a custom host. This custom host registration is the piece that allows us to automate the host addition process by exposing a registration token via the Rancher API. One important thing to note if you are going to be adding hosts automatically is that you will need to actually create the entries necessary in the environment that you bootstrap servers to. So for example, if you create a new environment you will either need to programatically hit the API or in the web interface navigate to Infrastructure -> Add Host to populate the necessary tokens and entries.
Once you have populated the API with the values needed, you will need to create an API token to allow the server(s) that are bootstrapping to connect to the Rancher server to add themselves. If you haven’t done this before, in the environment you’d like to allow access to navigate to API -> Add Environment API Key -> name it and make a note of key that gets generated.
That’s pretty much all of the prep work you need to do to your Rancher environment for this method to work. The next step is to make a script to bootstrap a server when it gets created. The logic for this bootstrap process can be boiled down to the following snippet.
#!/bin/bash
INTERNAL_IP=$(ip add show eth0 | awk '/inet/ {print $2}' | cut -d/ -f1 | head -1)
SERVER="https://example.com"
TOKEN="access_key:secret_key"
PROJID="unique_environment"
AGENT_VER="v1.0.1"
RANCHER_URL=$(curl -su $TOKEN $SERVER/v1/registrationtokens?projectId=$PROJID | head -1 | grep -nhoe 'registrationUrl[^},]*}' | egrep -hoe 'https?:.*[^"}]')
docker run \
-e CATTLE_AGENT_IP=$INTERNAL_IP \
-e CATTLE_HOST_LABELS='your=label' \
-d --privileged --name rancher-bootstrap \
-v /var/run/docker.sock:/var/run/docker.sock \
rancher/agent:$AGENT_VER $RANCHER_URL
The script is pretty straight forward. It attempts to gather the internal IP address of the server being created, so that it can add it to the Rancher environment with a unique name. Note that there are a number of variables that need to get set to reflect. One that uses the DNS name of the Rancher server, one for the token that was generated in the step above and one for the project ID, which can be found by navigating to the Environment and then looking at the URL for /env/xxxx.
After we have all the needed information and updated the script, we can curl the Rancher server (this won’t work if you didn’t populate the API in the steps above or if your keys are invalide) with the registration token. Finally, start a docker container with the agent version set (check your Rancher server version and match to that) along with the URL obtained from the curl command.
The final step is to get the script to run when the server is provisioned. There are many ways to do this and this step will vary depending a number of different factors, but in this post I am using Cloud-init for CoreOS on AWS. Cloud-init is used to inject the script into the server and then create a systemd service to run the script the first time the server boots and use the result of the script to run the Rancher agent which allows the server to be picked up by the Rancher server and its environment.
Here is the logic to run the script when the server is booted.
coreos:
units:
- name: rancher-agent.service
command: start
content: |
[Unit]
Description=Rancher Agent
After=docker.service
Requires=docker.service
After=network-online.target
Requires=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/rancher-agent
The full version of the cloud-init file can be found here.
After you provision your server and give it a minute to warm up and run the script, check your Rancher environment to see if your server has popped up. If it hasn’t, the first place to start looking is on the server itself that was just created. Run docker logs -f rancher-agent to get information about what went wrong. Usually the problem is pretty obvious.
A brand new server looks something like this.
I typically use Terraform to provision these servers but I feel like covering Terraform here is a little bit out of scope. You can image some really interesting possibilities with auto scaling groups and load balancers that can come and go as your environment changes, one of the beauties of disposable infrastructure as well as infrastructure as code.
If you are interested in seeing how this Rancher bootstrap process fits in with Terraform let me know and I’ll take a stab at writing up a little piece on how to get it working.
