CoreOS and Docker in Interoute Virtual Data Centre (Part 1)
If you’ve stuck your head into the world of cloud computing during the last year or so, you have probably heard of Docker. Docker is a clever set of components for building and managing Linux containers (known as LXC for short). LXC is an operating system–level virtualization method for running multiple isolated Linux systems (containers) on the same host machine. Linux containers are small and therefore they can deploy very fast. They can also connect to the Internet or private networks for sharing data as they inherit the network configuration of the VM they are running on. Docker is compatible with Linux-based operating systems and there are special 'lightweight' distributions of Linux that come with Docker preinstalled and configured. One of these special Linux distributions which has attracted a lot of users is CoreOS.
Docker has a lot of benefits compared with hardware-based virtualisation, in the form of 'virtual machines' or 'instances', that is the basis of today's cloud computing IaaS services. Containers are typically 10% of the size of an equivalent VM (around 0.5 GB instead of 5 GB or more). Therefore you can pack many containers on a single VM host machine. This is possible because of all the sharing of VM resources going on. In effect, there’s only one operating system and one virtualised hardware platform, shared by all of the containers. There is just a small application and an operating environment in a container. Therefore, this means that you can run far more containers on a host than you could possibly run complete virtual machines in your cloud environment.
Moreover, Docker containers are deployed fast, within a fraction of a second. In contrast VMs require a full virtual system boot and can take many minutes to get going. Containers are isolated from each other: Docker isolates applications at the filesystem and networking level. Your experience of using containers is hardly different from using a VM, and nearly all of the standard application programs that you use (web servers, databases, etc) will run without modification inside containers.
In this post, I will be going through a short tutorial on how to get started with Docker and CoreOS in Interoute Virtual Data Centre. The tutorial involves deploying a virtual machine running CoreOS Linux, which can be remotely accessed via SSH and can perform public key authentication. By default, CoreOS uses this stronger authentication technique than conventional password authentication, as it protects your VMs against malicious attack (brute force password attacks on VMs with open SSH ports are very common). But also it enables automatic logins between VMs, which means you can write scripts and programs to manage containers automatically, and this is key to running containers on groups (usually called clusters) of VMs, which will be covered in later blog posts.
To follow this tutorial you will need to have an Interoute VDC account. You can easily sign up for a free trial (no credit card required). You will also need the Cloudmonkey command line tool installed and configured on the computer that you are working on. Instructions on how to install and configure Cloudmonkey so that it can communicate with the VDC API can be found in the Introduction the VDC API. Finally you will need to install OpenSSH client software. This is usually already installed in Linux and Mac OS. For Windows it can be downloaded at the OpenSSH website.
Now you are ready to start the tutorial. First you should open a new terminal or command prompt window and start Cloudmonkey by typing:
$ cloudmonkey set display table && cloudmonkey sync && cloudmonkey252 APIs discovered and cached Apache CloudStack cloudmonkey 5.3.0. Type help or ? to list commands. Using management server profile: local (local) >
After running this, you should see that Cloudmonkey has started successfully and that it’s ready to accept API calls. I put three commands together (using the '&&' connectors) which have set the output format of Cloudmonkey, and performed a 'sync' so that Cloudmonkey has copied from the API server information about the API commands and parameters available. All of the VDC API commands that can be accepted by Cloudmonkey can be found in the API Command Reference.
Note: In this post, commands beginning with '$' are to be typed into the command line, and commands beginning '>' are to be typed into Cloudmonkey. Long lines of code have been broken up for display purposes, indicated by a continuation symbol '↩', but if you copy the code make sure to remove any linebreaks.
I am going to deploy a new virtual machine in VDC running CoreOS, using the following API call from Cloudmonkey:
> deployVirtualMachine serviceofferingid=value1 zoneid=value2 templateid=value3 networkids=value4 ↩ keypair=value5 name=value6
As you can see above I need to provide 6 parameter values. I will go through these one by one. The first parameter is the 'service offering id' which represents the amount of memory and number of CPUs that you want to allocate to the VM. Bear in mind that the service offering you choose must meet the requirements of the containers you are going to run; CoreOS and Docker running a few containers will work with 0.5 GB or 1 GB of RAM and 1 CPU core. As you add more containers, or run applications that are memory-hungry (such as databases), you will need a larger VM (note that you can modify the VM's service offering at any time later, larger or smaller, so long as the VM is powered off). I have decided to use the service offering with 4 Gigabytes of RAM and 2 CPU cores. I need to know the UUID of the service offering which I can get with the following command:
> listServiceOfferings name=4096-2 filter=id
The name parameter above denotes how much RAM (in Mbytes) and CPU cores you want to have. You should see an output like the following:
+--------------------------------------+ | id | +--------------------------------------+ | 85228261-fc66-4092-8e54-917d1702979d | +--------------------------------------+
Great! I have just discovered the value for the first parameter, this is the UUID for the service offering: '85228261-fc66-4092-8e54-917d1702979d'.
The second parameter which is called 'zoneid' specifies the zone (data centre of VDC) of the VM to be deployed. I can view the list of the available zones by typing:
> listZones filter=id,name
You should get the following result, if you are working in the Europe region of VDC. (You can use the North America or Asia regions to deploy CoreOS and Docker, following exactly the same procedure. Note that the UUID values required for most of the input parameters will be different from the ones shown here.):
+--------------------------------------+-------------------+ | id | name | +--------------------------------------+-------------------+ | 374b937d-2051-4440-b02c-a314dd9cb27e | Paris (ESX) | | 58848a37-db49-4518-946a-88911db0ee2b | Milan (ESX) | | fc129b38-d490-4cd9-acf8-838cf7eb168d | Berlin (ESX) | | 3c43b32b-fadf-4629-b8e9-61fb7a5b9bb8 | Amsterdam 2 (ESX) | | f6b0d029-8e53-413b-99f3-e0a2a543ee1d | London 2 (ESX) | | 5343ddc2-919f-4d1b-a8e6-59f91d901f8e | Slough (ESX) | | 1ef96ec0-9e51-4502-9a81-045bc37ecc0a | Geneva 2 (ESX) | | ddf450f2-51b2-433d-8dea-c871be6de38d | Madrid (ESX) | | 7144b207-e97e-4e4a-b15d-64a30711e0e7 | Frankfurt (ESX) | +--------------------------------------+-------------------+
I am going to deploy my VM in London and therefore I am going to use the zoneid 'f6b0d029-8e53-413b-99f3-e0a2a543ee1d'.
The third parameter I need to give is 'templateid' which specifies the operating system that I want the VM to run. I am going to choose the templateid of CoreOS, which is named 'IRT-COREOS' in VDC. Here is how to find out the required UUID:
> listTemplates templatefilter=featured zoneid=f6b0d029-8e53-413b-99f3-e0a2a543ee1d name=IRT-COREOS ↩ filter=id,name
Note this is the 'CoreOS stable' version, there is another template for 'CoreOS alpha'. When the above command is executed it gives me the templateid '73bc5066-b536-4325-8e27-ec873cea6ce7'.
The fourth parameter is 'networkids' (network identifiers) which specifies the network or networks that the deployed VM will be using. As I chose the VM to be located in London then the chosen network(s) should also be located in London. Type the following to show your networks in the London zone:
> listNetworks zoneid=f6b0d029-8e53-413b-99f3-e0a2a543ee1d filter=id,name
This is the output for my VDC account:
+--------------------------------------+--------------------+ | id | name | +--------------------------------------+--------------------+ | e9e1220b-76c8-47cd-a6c2-885ffee49972 | PrvWithGW Lon2 | | 182e8be5-6f73-4a31-a9f9-b6f445a46b53 | IPVPN_LON02 | +--------------------------------------+--------------------+
As you can see above, I have two networks in the London zone. I want my deployed VM to be connected to only one network, so I choose networkids to be 'e9e1220b-76c8-47cd-a6c2-885ffee49972'. (If I wanted two or more networks, I would make a list using commas to separate, such as: 'networkids=e9e1220b-76c8-47cd-a6c2-885ffee49972,182e8be5-6f73-4a31-a9f9-b6f445a46b53'.)
The fifth parameter that I need to specify is 'keypair', which will be used for connecting to the new CoreOS VM, in place of a password login. The CoreOS template does not allow for any logins (root user or otherwise) using passwords so you must set up a keypair in VDC using the VDC API, and this will be used to configure the VM when it is first booted. Since there is no login available you cannot access the VM anytime later to install a keypair.
First of all, I am going to create a new keypair on my own machine using the OpenSSH command line tool, ssh-keygen. Although you can reuse keypairs it is good practice to create a new keypair for each particular purpose:
$ cd ~/.ssh && ssh-keygen -t rsa -f id_rsa_coreos#(for Linux)
cd C:/ && ssh-keygen -t rsa -f id_rsa_coreos#(for Windows)
You will be asked to provide an optional passphrase, but ignore this by pressing Return (the passphrase protects your private key by encrpting it, but then you have to supply the passphrase every time the private key is used). A new keypair will be created in 'C:/' if you are using a Windows operating system, or in '~/.ssh' if you’re using Linux. You should see two new files, in the above case they would be 'id_rsa_coreos' (the private key) and 'id_rsa_coreos.pub' (the public key) since 'id_rsa_coreos' was the key name which I specified with the '-f' option.
The next step is to 'register' your keypair, which means storing your public key in VDC, so that VMs can boot with that information. (Note: the template needs to have a specific script in place to perform the keypair installation, which the CoreOS template is set up to do. Nothing will happen only by giving the keypair as an input parameter.)
> registerSSHKeyPair name=CoreOS-Key01 ↩ publickey="ssh-rsa AAAAB3NzaC1y...........fyskMb4oBw== PapanCostas@interoute.com"keypair: name = CoreOS-Key01 fingerprint = 55:33:b4:d3:b6:52:fb:79:97:fc:e8:16:58:6e:42:ce
The 'name' is arbitrary and is used for your reference only. I have abbreviated the input of the public key which is a very long string and must be input without any linebreaks. You can check that the stored key matches with your private key by calculating its fingerprint and comparing it with the returned value. And you can check the stored keys at any time with the
listSSHKeyPairs command. On your own computer you would type:
$ ssh-keygen -lf ~/.ssh/id_rsa_coreos
Finally, the sixth parameter that I need to provide is the name of the VM. You can choose any name that is unique and is not used by any existing VM on your VDC account. I will choose the name 'DockerTutorialVM01'.
So after a lot of preparation we finally have all the information we need to deploy a VM running CoreOS. I am going to make sure that Cloudmonkey is set to the mode of waiting for deployment to complete (known as 'asynchronous blocking'), otherwise the VM information will not be output to the terminal:
> set asyncblock true
Now input the deploy command:
> deployVirtualMachine serviceofferingid=85228261-fc66-4092-8e54-917d1702979d ↩ zoneid=f6b0d029-8e53-413b-99f3-e0a2a543ee1d templateid=73bc5066-b536-4325-8e27-ec873cea6ce7 ↩ networkids=e9e1220b-76c8-47cd-a6c2-885ffee49972 keypair=CoreOS-Key01 name=DockerTutorialVM01
(If you copy this code, remove the linebreaks.)
If will take several minutes for the VM to deploy and boot up. The above command will output a set of information about the VM. Please note the ‘id’ value of the VM as you will need to use it later.
The VM is running, but I still need to configure the network so a port connection is available for SSH. This requires a port forwarding rule. I am going to set a rule for port 22 (SSH connections), and also port 80 (HTTP web traffic) which I will be using in Part 2 of this tutorial. To set the rules, I need to know the UUID for the public IP address of the network. You can find it this way:
> listPublicIpAddresses filter=name,id,zonename,associatednetworkname,ipaddress
So I create the port forwarding rules like this:
> createPortForwardingRule protocol=TCP publicport=80 ipaddressid=value1 virtualmachineid=value2 ↩ privateport=80 openfirewall=true
> createPortForwardingRule protocol=TCP publicport=22 ipaddressid=value1 virtualmachineid=value2 ↩ privateport=22 openfirewall=true
The last configuration step is to set an egress firewall rule for the network so that the CoreOS VM will be able to get outward access to the internet. This is needed for Docker to access repositories for container images, and to allow CoreOS to access internet update servers to do automatic updating. Type the following:
> createEgressFirewallRule networkid=e9e1220b-76c8-47cd-a6c2-885ffee49972 protocol=all cidr=0.0.0.0/0
For simplicity I am allowing egress on any port. In a production environment I would want to be more careful about allowing only the required ports.
So finally my VM is set up for me to connect to it, using the 'ipaddress' found from the
listPublicIpAddresses command and specifying the private SSH key file to match the public key which I registered in VDC. Type this ssh command into a terminal:
$ ssh –i ~/.ssh/id_rsa_coreos core@IPADDRESS
Hopefully you now see something similar to the following. At the first connection to the VM I am asked to check authenticity of the VM. Then I type the command 'docker info' to get some information about Docker and CoreOS:
The authenticity of host '[IPADDRESS]:22 ([IPADDRESS]:22)' can't be established. ED25519 key fingerprint is 4a:f4:85:c0:1d:e0:fa:26:94:89:7c:39:1b:57:42:d2. Are you sure you want to continue connecting (yes/no)?
yesWarning: Permanently added '[IPADDRESS]:22' (ED25519) to the list of known hosts. CoreOS (stable) core@DockerTutorialVM01 ~ $
docker infoContainers: 0 Images: 0 Storage Driver: btrfs Execution Driver: native-0.2 Kernel Version: 3.17.2+ Operating System: CoreOS 494.4.0
You have successfully finished this tutorial. We can now get started using Docker in Part 2.