How to deploy CoreOS Container Linux in VDC

Cloudmonkey setup
Create a new SSH keypair and store it in VDC
Finding the CoreOS Container Linux template
Deploy a Container Linux virtual machine
Connecting to the new Container Linux virtual machine



CoreOS Container Linux is a version of Linux designed for use in running Docker containers on clusters of virtual machines.

This document is a guide to deploying a single virtual machine on Interoute VDC, running CoreOS Container Linux. The default configuration of SSH keypair-based authentication is used, and this requires using the VDC API interface.

Note: commands beginning with '$' are to be typed into the command line, and commands beginning '>' are to be typed into Cloudmonkey.


The following are assumed:

  • You have got an API key and Secret key for your VDC account (see how to generate keys for the API)

  • You have the Cloudmonkey command line tool installed and configured on the computer that you are working on.

Cloudmonkey setup

Instructions on how to install and configure Cloudmonkey so that it can communicate with the VDC API can be found in the Introduction to the API.

Open a new terminal or command prompt window and start Cloudmonkey by typing:

$ cloudmonkey
Apache CloudStack cloudmonkey 5.3.3 [MODIFIED FOR INTEROUTE VDC 2016-11-24]. Type help or ? to list commands.

Using management server profile: local 

(local) >

If you see the '>' prompt as above then Cloudmonkey has started successfully and it's ready to accept API calls. All of the VDC API commands that can be accepted by Cloudmonkey can be found in the VDC API Command Reference.

Type these four commands to set the configuration as it is used in the rest of this demonstration:

(local) > set display table
(local) > set asyncblock true
(local) > set region europe
(local) > sync
283 APIs discovered and cached

Create a new SSH keypair and store it in VDC

The CoreOS virtual machine template does not allow any logins (root user or otherwise) using passwords. So you must have a SSH keypair ready for use before you deploy the virtual machine.

A new keypair is generated using the OpenSSH command line tool, ssh-keygen:

$ cd ~/.ssh && ssh-keygen -t rsa -f id_rsa_coreos

The keypair consists of two files, the private key which will be in a file named 'id_rsa_coreos', and the public key in the file ''. The private key should always be held securely in your own computer.

The next step is to 'register' your keypair by uploading your public key to VDC, so that virtual machines can boot up with that information:

> registerSSHKeyPair name=CoreOS-Key01 publickey="ssh-rsa AAAAB3NzaC1y...........fyskMb4oBw=="
name = CoreOS-Key01
fingerprint = 55:33:b4:d3:b6:52:fb:79:97:fc:e8:16:58:6e:42:ce

The public key has been abbreviated here; it must be entered as a single long string without linebreaks, be careful when copying the public key that you don't introduce any linebreaks.

The keypair 'name' parameter is arbitrary and is used to identify this public key. Multiple keys can be stored in your VDC account.

For security reasons you can't extract the value of the public key from VDC, only its 'fingerprint' value which you can compare against the fingerprint generated from the keypair on your own computer.

Finding the CoreOS Container Linux template

Interoute VDC has the 'CoreOS Stable' template ready-to-use, look for the template name IRT-COREOS.

You need to look up the template UUID for the zone (physical data centre location) where you want to deploy the virtual machine. This command displays the zones with their UUIDs:

> listZones filter=id,name
count = 12
|        name       |                  id                  |
|    Paris (ESX)    | 374b937d-2051-4440-b02c-a314dd9cb27e |
|    Milan (ESX)    | 58848a37-db49-4518-946a-88911db0ee2b |
|    Berlin (ESX)   | fc129b38-d490-4cd9-acf8-838cf7eb168d |
| Amsterdam 2 (ESX) | 3c43b32b-fadf-4629-b8e9-61fb7a5b9bb8 |
|   London 2 (ESX)  | f6b0d029-8e53-413b-99f3-e0a2a543ee1d |
|    Slough (ESX)   | 5343ddc2-919f-4d1b-a8e6-59f91d901f8e |
|   Geneva 2 (ESX)  | 1ef96ec0-9e51-4502-9a81-045bc37ecc0a |
|    Madrid (ESX)   | ddf450f2-51b2-433d-8dea-c871be6de38d |
|  Frankfurt (ESX)  | 7144b207-e97e-4e4a-b15d-64a30711e0e7 |
|    Zurich (ESX)   | a5d3e015-0797-4283-b562-84feea6f66af |
|   Istanbul (ESX)  | 1ce2fa41-bc99-484c-99b9-b1b6a28487ba |
|  Stockholm (ESX)  | e564f8cf-efda-4119-b404-b6d00cf434b3 |

Then with the appropriate 'zoneid', the listTemplates command shows the CoreOS template for the VDC Zurich zone:

> listTemplates templatefilter=executable zoneid=a5d3e015-0797-4283-b562-84feea6f66af name=irt-coreos filter=id,name
count = 1
|                  id                  |    name    |
| 73bc5066-b536-4325-8e27-ec873cea6ce7 | IRT-COREOS |

Deploy a Container Linux virtual machine

The following API command is used to deploy a new virtual machine based on the CoreOS template:

> deployVirtualMachine serviceofferingid=85228261-fc66-4092-8e54-917d1702979d zoneid=a5d3e015-0797-4283-b562-84feea6f66af templateid=73bc5066-b536-4325-8e27-ec873cea6ce7 networkids=c5841e7c-e69e-432b-878b-c108b07a160f keypair=CoreOS-Key01 name=CoreOS-VM-01

Six parameter values are required. 'keypair', 'templateid' and 'zoneid' you have already seen above. 'name' can be any string of your choice.

The 'serviceofferingid' represents the amount of RAM memory and number of CPUs that you want to allocate to the virtual machine. In this example, 2 CPUs and 4 GBytes of RAM have been chosen. The following command can be used to obtain the corresponding value for the id:

> listServiceOfferings name=4096-2 filter=id
|                  id                  |
| 85228261-fc66-4092-8e54-917d1702979d |

Finally, the 'networkids' parameter specifies the network(s) which the virtual machine will be attached to. You need to specify at least one network.

You can use the 'listNetworks' command to get information about the available networks.

> listNetworks zoneid=a5d3e015-0797-4283-b562-84feea6f66af filter=id,name
count = 3
|                  id                  |                       name                        |
| c5841e7c-e69e-432b-878b-c108b07a160f |          Network Local Interoute Demo 2           |
| 9a06d83e-5d50-4aec-8b93-96d4af4c6c3b | Network Private Direct Connect Interoute Demo 16  |
| 2c60fa40-2bcc-4b27-9602-7ba9a68ee59d | Network Private Direct Connect Interoute Demo 13  |

This is the output for the demonstration VDC account. The networks and UUIDs for your account will be different. If there is no network present in the zone that you want to use then you will need to create a network.

The appropriate choice here is the 'Local' network which has Internet access. The other networks are used for private inter-connection between VDC zones.

When you run the deployVirtualMachine command you will get a long output such as the following (which has been abbreviated):

cmd = org.apache.cloudstack.api.command.user.vm.DeployVMCmd
jobid = 0d80741f-b92a-4fa0-9937-ba0ad31dd773
id = 60dbe449-c0ca-407a-a3bc-19c461136bb9
name = CoreOS-VM-01
cpunumber = 2
cpuspeed = 2000
created = 2016-12-13T12:58:59+0000
displayname = CoreOS-VM-01
guestosid = d0ea999e-8510-11e3-8895-005056ac0d46
haenable = True
hypervisor = VMware
isdynamicallyscalable = True
jobstatus = 0
keypair = CoreOS-Key01
memory = 4096
passwordenabled = False
serviceofferingid = 85228261-fc66-4092-8e54-917d1702979d
serviceofferingname = 4096-2
state = Running
templatedisplaytext = CoreOS (Must be deployed with CLI e.g. CloudMonkey)
templateid = 73bc5066-b536-4325-8e27-ec873cea6ce7
templatename = IRT-COREOS
zonename = Zurich (ESX)

Note that no root password is output because password access is not enabled for this virtual machine. You can only access by presenting the private key which matches the public key that you uploaded.

Connecting to the new Container Linux virtual machine

To be able to make an SSH connection from the Internet to the virtual machine a port forwarding rule for the network must be created.

> createPortForwardingRule protocol=TCP publicport=22 ipaddressid=6b8ba421-8bba-4a25-8053-8cbcb54d76b4 virtualmachineid=60dbe449-c0ca-407a-a3bc-19c461136bb9 privateport=22 openfirewall=true

The 'virtualmachineid' can be read from the deploy output above. 'ipaddressid' can be found with the API command listPublicIpAddresses, and (if there is more than one public IP address) you look for the 'associatednetworkid' matching the id of the network that the virtual machine is attached to:

> listPublicIpAddresses zoneid=a5d3e015-0797-4283-b562-84feea6f66af filter=id,ipaddress,associatednetworkid
count = 1
|   ipaddress     |         associatednetworkid          |                  id                  |
| 213.XXX.XXX.185 | c5841e7c-e69e-432b-878b-c108b07a160f | 6b8ba421-8bba-4a25-8053-8cbcb54d76b4 |

(The IP address has been Xed out for privacy reasons.)

The last configuration step is to create an egress firewall rule for the network so that the virtual machine will be able to get outward access to the Internet. This is needed for the VM to access update servers to do automatic updating, and for Docker to access repositories for container images:

> createEgressFirewallRule networkid=c5841e7c-e69e-432b-878b-c108b07a160f protocol=all cidr=

Note: these network rules are simple and permissive, while rules for production virtual machines should always be more strictly defined.

The virtual machine is now set up for connection, using the 'ipaddress' found above and specifying the private SSH key file to match the public key which was registered in VDC (and there is no root user in Container Linux, the default user is 'core'):

$ ssh -i ~/.ssh/id_rsa_coreos core@213.XXX.XXX.185

For the first connection to the virtual machine you will be asked to check authenticity:

The authenticity of host '213.XXX.XXX.185 (213.XXX.XXX.185)' can't be established.
ED25519 key fingerprint is e8:6a:a9:02:09:93:4a:2c:20:97:e4:56:da:c1:b7:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '213.XXX.XXX.185' (ED25519) to the list of known hosts.
CoreOS (stable)
core@CoreOS-VM-01 ~ $

Check that the Internet egress is working by trying to connect to an external location, for example:

core@CoreOS-VM-01 ~ $ ping


core@CoreOS-VM-01 ~ $ docker search wordpress

The Container Linux template is configured for automatic updating: it will take a few hours for the update engine to run and download the latest version of CoreOS Container Linux into the virtual machine.