For anyone who runs one or more docker applications, a huge challenge is to keep containers running smoothly with updated images. You could force updates with tools like Watchtower, but these may just automatically break your applications. Here are some of the ways I make sure docker applications stay up-to-date while failing as little as possible. This only covers docker run/create and docker-compose (for now). Here’s what I do.
I’ve been delving into Docker more and more, and recently, the internal bridge networking that docker supports. This generally allows containers to have their own IP address while communicating with other containers internally, the outside network externally. Most docker-related posts and setups don’t delve too deep into this aspect of docker (that’ll be another post), but the process for me has brought on some challenges. Today, I’ll show you one.
Discourse is a popular forum tool available as a self-hosted open-source tool. It can be installed bare-metal on Linux, but the Docker installation is one that I found most interesting. Unlike most Docker-implemented tools, Discourse has a script that runs outside of the docker containers (on your base machine) to set up the tool. This monolithic script (./discourse-setup) seems to do many of the things that docker-compose does, but obviously worse. I’m no fan of doing things this way; especially when the base alternative is nowhere on their site. My challenge this time was to build a basic docker-compose.yml that would get Discourse running in a test environment. Here’s what I did.
Docker has been an amazing tool for deploying applications fast, but as I have come to need containers that interacted with each other, the networking aspects have brought some major challenges. I wasn’t a fan of docker’s documentation either. It doesn’t explain the nuances of this process. Namely, I wanted to know how to bring up a container and right from the start assign an IP address. Let me show you how that’s done.