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.

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:

VOLUME /var/lib/mysql

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.

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.