Part 2 - Working with multiple containers
In part 1 we looked at starting, inspecting and interacting with a single container that had both an attached volume and a FIP to expose a port publicly. In this section we’ll look at how to work with multiple containers by using the perennial Wordpress example.
Note If you’re familiar with Docker Compose, this will seem like a lot of manual work. Don’t worry, we’ll get to Hyper Compose in the next section!
Starting MySQL
By now you’ll probably be able to guess the next steps, but let’s walk through them anyway.
Now let’s use hyper ps
to check that the MySQL container is running:
All looks good. If you check hyper volume ls
though, you’ll see something that you perhaps didn’t expect.
The hyper run command has automatically created and attached a 10GB Hyper Volume to the MySQL container.
As we mentioned before, Hyper Volumes are analogous to Amazon EBS mounts and allow you to decouple the lifetime of your data from the lifetime of the container. This is probably desirable for a database, but why did this happen without our explicit consent?
To answer is that we need to look at the Dockerfile that created the MySQL Docker image. The important line is below:
When there is a VOLUME
line in a Dockerfile, the Docker engine will automatically create a volume when the container is started. Hyper mirrors this behaviour, but because you pay per-second with Hyper, it’s always good to know what you’re paying for.
If you would like to disable this behaviour entirely you can always do that during the run command with the --noauto-volume
flag, for example:
If you choose not to automatically create volumes all data will be written to the rootFS volume in the container that is deleted when your container is killed.
Starting Wordpress
Next we’ll start the Wordpress container. The key point here is that the Wordpress container will need to find the MySQL container in order to connect to it. This is achieved via the --link
flag for the hyper run
command.
If we now check the Wordpress container’s logs we will see that it is happily starting up:
So what exactly did --link
do? Well actually it does two things. Firstly it exposes the environments variables from the MySQL container to the Wordpress container as we can see using hyper exec
:
Secondly, --link
creates an entry in the /etc/hosts
file on the Wordpress container so that it can resolve the MySQL container’s IP address:
Note on linking containers The whole reason why linking works in this case is because the MySQL container knows to look for certain environment variables at start up time. Although this is a common container pattern, make sure you check the startup scripts of any containers that you’re using to see what information they expect.
Conclusion
You could now go ahead and connect your Wordpress container to an FIP and connect to it from the internet, but we already covered that in section 1 so that’s left up to you.
In this section we’ve seen how by using --link
we can share environment variables and dns information between containers so that they can work together.
Final note Don’t forget to clean up your resources from part 2!
In Part 3 we'll look at using Hyper Compose, which makes dealing with multiple containers much simpler.
Last updated