Container Upgrade - Experiences Updating Three Databases

Outside of that change (plus adding a README to the repository), I needed to rebuild the container locally, which pulled the latest version of the MariaDB base image. I didn’t need to do anything different for my Apple silicon chip, as the same base image supports both architectures. We can see this in the mariadb image tags, as shown below. Both x86-64 and ARM 64 are there.

Once I pulled the latest version of the container and tested it, I pushed the updated image to my personal Docker Hub repositories. The commands used to do all of these steps are listed below.

The second command in the code block above is a bit long due to all of the options. I also included the same command in the run script from the Github repository, so if you clone the whole repository, you can run the script in place of the docker run command above.

First, I use the --name option to give my container instance a name. This allows me to reference the container by name in commands, instead of using the container id (complicated alphanumeric value). I then bind the container port to a host port using -p (syntax is hostPort:containerPort). Since MariaDB’s default port is 3306, I stick with that, so we bind my machine’s 3306 port to the container’s 3306 port.

The -d option that follows is to run the container in detach mode. This means it runs in the background, making it easier to see the container and gain access to it. The next two options use the -v flag, which mounts folders from the host device into the container. This means that if I have files or scripts I need to access inside the container, the container can see these through a mounted volume. In our case, we have mapped a local data folder to the /var/lib/mysql folder in the container (for data load), and we have mapped a local log folder to the /var/log/mysql folder in the container (for viewing log files).

Next, our -e option is setting environment variables to pass into the container. For us, this means a password for the database. The last bit of text in the command is specifying the image to use for building the container (jmreif/mariadb).

With that knowledge, we can take a look at the MongoDB container changes.

Moving now to the docker-mongo repository, we don’t see too many changes here either. The change for the author syntax on the Dockerfile was mentioned earlier, and I added a README for details. Otherwise, I did the same as with the MariaDB container - rebuilt the image so it pulled an updated mongo base image, then tested the container, then pushed the updated version.

The MongoDB base image also supports multiple architectures (including x86-64 and arm64), so I didn’t need to do anything different. We can confirm this with the Docker Hub image screenshot below. The x86-64 and ARM 64 tags are both there.

The commands for all these steps are very similar to the MariaDB ones shown earlier, but we will note the differences below.

We will focus on the second command. The syntax is similar, using the --name option to specify a name for our container and then using the -p option to bind a container port to a host port, with 27017 being MongoDB’s default port. Next, we specify our environment variables for the database username and password with -e. If you remember, we specified these options last in our mariadb container, but ordering doesn’t really matter here. After our password, we use the -d option to run the container in the background and have three -v options for mounting data, logs, and temporary folders to the container. Lastly, we have the image name used for creating the container.

This completes our update for the MongoDB container. Now we can continue on to Neo4j.

With Neo4j’s latest update to version 4.4, the changes align very closely with those we saw for MariaDB and MongoDB. As you might have guessed, we changed the author syntax in the Dockerfile for Neo4j, just as we did with MariaDB and MongoDB. I also added a README file in this repository to match the others. Looking at the commit, though, there are a couple other changes, so let’s walk through those.

*Note(2021-12-16):* Neo4j supports multi-arch as of version 4.4+! For Neo4j 4.3 and older, the Neo4j arm64 image supports arm64. You will need to pull a different base image by modifying the base image line to use the neo4j-arm64-experimental image.

We can see both the specified architectures on the official Neo4j repository in the screenshot below.

Neo4j also requires you to specify a version tag for the image (actually a Docker best practice), so I used the 4.4.1 version. However, feel free to use one to fit your needs. The current (as of writing this) release version is 4.4, so picking any minor versions of that ensures you have the latest features.

Next, I exposed an extra port for the default Neo4j HTTPS port (7473). The other two ports in the Dockerfile are for Neo4j’s default HTTP and BOLT ports, respectively. Though it is not required to have them all, I have all connection types covered.

With those changes in place, we can build, test, and push the new container. As before, I’ll show the commands used for all of these steps below.

The only change for the build and push commands is the image name, so we will skip to the run command differences. All of the options should look familiar, since we don’t have anything new compared to the MariaDB and MongoDB versions. The --name option lets me set a container name for referencing, and the -p lets me map host to container ports. In this case, I’ve bound both 7474 and 7687, which are the HTTP and BOLT ports for Neo4j. This means I can access Neo4j Browser using port 7474, and I can connect via applications through 7687 with the bolt protocol.

On the next line, the -e option is used to set an environment variable for the username and password (both are set with a single variable, using a / to separate the two values). A -d option follows that to run the container in the background, and then all of our -v options mount folders for data and logs, as well as two Neo4j-specific ones for import files (/import) and plugins (for adding extensions like APOC). The final bit of text specifies the image to use for building the container - jmreif/neo4j.