InfluxDB Latest Tag Updated in Docker Hub
By Michael Hall / Feb 26, 2021 / InfluxDB, Community, Developer
The latest InfluxDB OSS (version 2.0.4) has officially been released on Docker Hub! While this will allow a smooth upgrade path for both new and existing users of InfluxDB, we found out that some users were being unexpectedly upgraded to the new images due to having configured their deployments to always use the
:latest tag of these images.
In our effort to ensure the best experience possible, we’ve documented here what happened to cause this, how to avoid it, and what to do if you’ve found yourself in a similar situation.
Over the past several weeks, we have been working with Docker Hub to update their official InfluxDB images to the new InfluxDB OSS 2.0 release. The final step in that process was updating the
:latest tag reference to point to the new InfluxDB 2.0.4 version of the container image. That update was accepted by Docker Hub a couple of days ago, and went live later that night. Since then, anybody who pulled a copy of the image, either using the
:latest tag explicitly or using no tag at all, started using the InfluxDB 2.0.4 image.
This came as a surprise to some users, who were updating an environment that was originally deployed with the InfluxDB 1.8 version of the container, and now found themselves running InfluxDB 2.0 especially because their data files from InfluxDB 1.8.x are not compatible with the InfluxDB 2.0 codebase.
If this happened to you, don’t worry, YOUR DATA IS SAFE! InfluxDB OSS has built-in migration tooling to update your data files to the new format, but it will not be run automatically. Depending on your setup, you can either go back to the InfluxDB OSS 1.8 version of the Docker image, or run the command to upgrade your data to work with the latest version. For a list of key differences between InfluxDB 1.x and InfluxDB 2.x, please check out our documentation.
The next section will explain in more detail why this happened and what we’re going to do going forward to help our users avoid it. If you just want to fix your setup and get back to work, scroll down to the “How to Fix It” section
Why this happened
:latest tag is a convenience provided by Docker Hub that makes it easy to pull the most up to date version of an image without having to know what that version is. It’s useful for automating things like CI where you always want to use the most recent version of your software, and for developers who just want to get started running your software as quickly and easily as possible.
As the default when no tag is specified, it also allows for shorter instructions such as
docker run influxdb, which we can put in our documentation and not have to update every time the release version changes.
However, it is NOT meant to be used for deployments, since the version it refers to will constantly be changing. The official Kubernetes instructions warn against this use explicitly:
"You should avoid using the
:latesttag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly." https://kubernetes.io/docs/concepts/configuration/overview/#container-images
Even if you are only deploying a personal or hobby project you should only use
:latest in your development and testing environment, and switch to an explicit release tag once you’ve got it working the way you want.
:latest tag for InfluxDB currently points to the 2.0.4 release images. As we release new versions of InfluxDB OSS 2.x and beyond, this tag will be updated to point to those new versions. This is how Docker Hub intends for the
:latest tag to be used, and is the expected behavior among users.
We will also continue to publish docker images for the 1.x codebase, and will put out new images for each new release of that codebase. These images, however, will never again have the
:latest tag pointing to them, so you will need to give the specific version tag every time you want to run or update them.
We have identified several places where we can improve our documentation, both on our site and in Docker Hub, to be more explicit about when the
:latest tag should be used, and when a specific version should be given instead. We will also add more documentation on how to upgrade your Docker environment from InfluxDB 1.8 images to influxDB 2.0 images.
How to fix it
If you have existing data from your InfluxDB OSS 1.8 deployment, you can either upgrade that to work with the latest InfluxDB OSS 2.0 release, or roll your deployment back to using the InfluxDB OSS 1.8 release.
Upgrade to InfluxDB OSS 2.0
If you want to stay on InfluxDB OSS 2.0, you can do an in-place upgrade of your existing data using the new version of the InfluxDB image. To do that, you will need to run your container with some additional environment variables set, these will tell InfluxDB OSS 2.0 that you want to upgrade your data and configuration files. We have updated the instructions on the InfluxDB Docker Hub page to walk you through this process.
Rollback to InfluxDB OSS 1.8
If you’d rather just get everything back to how it was before this happened, all you need to do is tell docker to use the
1.8 tag explicitly.
In the Docker CLI, you can do this with:
docker run --rm influxdb:1.8
If you are using docker-compose, add the
1.8 tag to the
image: parameter in your docker-compose.yml:
Likewise if you are using Kubernetes, update your pod spec to use:
Lastly I’d like to thank Matthew Iverson, an InfluxDB customer and one of our community InfluxAces, who let us know that this tag update was causing confusion among users of our open source release, even though it didn’t affect him directly. I’d also like to thank Srajan Bhagat in our Customer Success team, who passed Matthew’s message on to me immediately after hearing it.
And I would especially like to thank the InfluxData Product and Engineering teams, in particular Phillip Steinbachs, Daniel Moran, Russ Savage, Jonathan Sternberg and Ryan Betts, who all dropped what they were doing and jumped onto calls with me to help find a resolution as soon as I said that our open source users were having an issue. Their commitment to ensuring the best possible experience for all of our users is what makes InfluxData and the InfluxDB community so great.