This article describes how to build a Docker host with a single Tuono Blueprint. Using the same Blueprint, this can easily be extrapolated out to a whole Docker Swarm.
During a recent discussion with a customer at a software development company, they explained that they wanted to fully automate a Docker deployment and the required infrastructure in the public cloud. They had several Docker images, containing all the dependencies that they needed to work with a range of languages and frameworks. What they wanted to do was automate the deployment of the Docker infrastructure and pulling down the discrete container images based on the languages they wanted to work with.
This got me thinking…
Starting with the default Tuono “tutorial” Blueprint, we could easily modify this to become a Docker Blueprint using some standard Tuono functionality. We could automate the deployment of the correct Docker image from the container library based on the current requirement.
For this example, I created a Docker image from scratch, to demonstrate the principle. If you already have a few Docker images, you know how all this works and can make the appropriate changes in the “userdata” section, but if you don’t, you’ll have your own custom image at the end of this… the batteries are included.
Let’s dive straight in to the schema, and then we can talk about what it does.
# # This is an example blueprint which demonstrates the # creation of a Docker host with a public ip address. # # The machine can be accessed via: # # # ssh <admin_username>@<ip> # # And the Docker machine can be accessed via; # # # ssh <admin_username>@<ip> -p 8080 # --- variables: admin_username: description: The username for the administrative user. type: string default: adminuser container_password: description: The password for the Docker container type: string admin_public_key: description: The OpenSSH Public Key to use for administrative access. type: string number_of_cores: type: integer preset: true memory_in_gb: type: integer preset: true presets: venue: azure: number_of_cores: 1 memory_in_gb: 2 aws: number_of_cores: 2 memory_in_gb: 1 location: region: datacenter: aws: eu-west-1 azure: northeurope folder: docker: region: datacenter networking: network: testing: range: 10.0.0.0/16 public: true subnet: public: range: 10.0.0.0/24 network: testing firewall: only-secure-access public: true protocol: secure: ports: - port: 22 proto: tcp - port: 443 proto: tcp - port: 8080 proto: tcp firewall: only-secure-access: rules: - protocols: secure to: self compute: image: bionic: publisher: Canonical product: UbuntuServer sku: 18.04-LTS venue: aws: image_id: ami-06868ad5a3642e4d7 vm: docker-host: cores: ((number_of_cores)) memory: ((memory_in_gb)) GB image: bionic disks: data: size: 64 GB tags: tag: base_disk nics: external: ips: - private: type: dynamic public: type: static firewall: only-secure-access subnet: public tags: wicked: cool configure: admin: username: ((admin_username)) public_key: ((admin_public_key)) userdata: type: shell content: | #!/bin/sh ## Configure admin_username on the host machine userid=$(id -u ((admin_username))) if [ -z "$userid" ]; then set -e adduser --gecos "" --disabled-password ((admin_username)) cd ~((admin_username)) mkdir .ssh chmod 700 .ssh echo "((admin_public_key))" > .ssh/authorized_keys chmod 600 .ssh/authorized_keys chown -R ((admin_username)).((admin_username)) .ssh usermod -aG sudo ((admin_username)) echo "((admin_username)) ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers set +e fi ## Update the repositories and upgrade sudo apt update sudo apt upgrade -y ## Install and configure Docker sudo apt install docker.io -y sudo usermod -aG docker (( admin_username )) sudo systemctl enable --now docker ## Configure the Docker instance cd /home/((admin_username))/dockerbuild mkdir dockerbuild ## Create Dockerfile and do some bootsrapping on the container machine echo "FROM ubuntu:20.04 # Install the required dependencies RUN apt-get update && apt-get install -y openssh-server RUN mkdir /var/run/sshd # Add the admin_username RUN useradd ((admin_username)) RUN echo '((admin_username)):((container_password))' | chpasswd # Fix some ENV issues ENV NOTVISIBLE='in users profile' RUN echo 'export VISIBLE=now' >> /etc/profile # Open up port 22 EXPOSE 22 # This is a workaround to start (and keep up) SSHd CMD service ssh start && while true; do sleep 3000; done" > dockerbuild/dockerfile ## Build and run the Docker image docker build -t dockerfile dockerbuild docker run -d -p 8080:22 -t -i dockerfile
As you can see, this is a fairly standard VM Blueprint. In this case, I decided to create a preset for Azure and AWS. The only reason for this is so that it’s possible to deploy it in the free-tier of AWS (2 CPU and 1 GB RAM, or t3.micro). This size has no cognate in Azure. In real life, you’d remove the presets altogether, set it to a sensible amount of CPU and memory and it will deploy to Azure and AWS just fine. The other non-standard part of the base template is the use of port 8080. This is the port that will be mapped to the Docker image – container port 22 in this case. With the explanation complete, let’s talk about the interesting bit.
For this example, it’s the “userdata” that does most of the heavy lifting. Userdata is interesting in that it allows you to use any shell-supported scripting language to bootstrap your infrastructure. It’s extremely useful for doing the initial infrastructure configuration (see the webservice example), or as in this case, for doing the initial configuration where state is not a concern. I should also add that cloud-init is fully supported too, but I specifically used bash in this example on the assumption that it may be more familiar to people if they wanted to extend this example.
So, what’s going on in the userdata? The first section is simply about configuring the admin_username that was defined as a variable. If we use userdata, it is expected that we do all the initial configuration in here, so we add the user, configure sudo and add them to the sudoers file and enable SSH key authentication. You can consider this section as boilerplate and should be present in some form in almost every case where you leverage userdata. From here, we:
- Update the Ubuntu instance
- Install Docker
- Add our admin_username to the Docker group. This ensures that the containers are accessible to this user.
The next section is where we write out our Dockerfile. In this example we do only the very minimum to make it useful:
- Update the Ubuntu container
- Install OpenSSH
- Add the admin_username
- Update /etc/profile
- Finally, start SSH at runtime using a workaround to keep it up and accessible.
If you want to take it for a test-drive:
To access the Docker host
# ssh <admin_username>@<ip>
And to access the container:
# ssh <admin_username>@<ip> -p 8080
All the IP details can be viewed by clicking the “Inventory” button on the Environment Screen.
If you want to go ahead and try this out, feel free to take Community Edition for a spin. It’s entirely free, with no credit card required, so it’s a good way to have some fun with this example. Stay tuned for more fun examples.