Convenience Images Update: Removing Hardcoded Postgres User

docker
convenience-images
postgres

#1

To accommodate upstream changes to the Docker Library Postgres images that we extend in our circleci/postgres Docker Hub repository, we are removing hardcoded references to a POSTGRES_USER in the Dockerfiles for our Postgres images.

For further context, from @FelicianoTech’s earlier post:

The Problem

Most of the CircleCI Docker Convenience Images are small CI tweaks we apply to the upstream Docker Library images. So the circleci/postgres image is based on the postgres image.

4 days ago the upstream maintainers made a small tweak to the image so that the postgres role/user is only created when the POSTGRES_USER is not set. So of course, we set it to root . This has caused circleci/postgres images built within the last few days to no longer have the postgres role.

Thus, to avoid further confusion, we have removed the root user entirely. Once this publish_postgres job completes, the postgres role/user should again be created automatically in our Postgres images—or you can use @FelicianoTech’s second solution from the previously mentioned post:

Set the POSTGRES_USER environment variable in your CircleCI config to postgres and you’ll get the role back in the image as it was before. This would be done something like this:

      - image: circleci/postgres:9.6-alpine
        environment:
          POSTGRES_USER: postgres

In the longer-term, we plan to build these images entirely from scratch, to avoid the mutability of extending a community image.


Mystery DATABASE_USER=ubuntu Setting
CircleCI Postgres Image suddenly causing problems? "role postgres not found"
CircleCI Postgres Image suddenly causing problems? “role postgres not found”
#2

Hi @rose and @FelicianoTech - thank you for the communication!

If you wish to maintain you own images, that seems like a reasonable approach. However, I also think you might want to investigate your release process for new images. Even if you were to maintain your own image, it’s possible you could ship a change that breaks lots of users in a similar manner.

A few areas to consider:

  • might you be able to “rollback” in similar problem scenario, rather than applying a partial hotfix?
  • might there be testing you could do before pulling in latest master from upstream (Postgres/etc)?
  • might you somehow incrementally/canary deploy similar changes, so that not all users get impacted at once?

Thanks for all the great work you do and for the speedy response and communications here.

Best,
Nathan


#4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.