2

I've seen a lot of repositories with Docker images and I think (correct me if my guessing is wrong) that the projects that handle a docker image with multiple tags can be grouped into three groups:

  • Dockerfiles with different names in the same directory.
  • Dockerfiles with the same name (i.e. "Dockerfile") in different directories.
  • Dockerfiles with the same name (i.e. "Dockerfile") in different branches.

I've looked at the Docker documentation page but there are no suggestions on how one should manage multiple tag images. I'm not looking for a subjective answer. Of course, any advice will be appreciated but what I want is to know the pros and cons of each of the three possibilities.

Of course, there is the possibility that I've understood nothing of how docker images should be deployed. In this unfortunate case, please be merciful and point me in the right direction.

Case study

I wanted to pose a general question but I realized that maybe it was too broad. For this reason, I explain here what is my case hoping that could help a bit more what I wanted to achieve and what I've done now (this question is about only a part of what I wanted to achieve).

What I want is to develop a docker hub automated build linked to a Git Hub repository. The images are about LaTeX on Ubuntu. The first build, tagged base, starts from Ubuntu 18.04 and comes with texlive-base. Another build, tagged full, starts from the build tagged base and comes with texlive-full. Another two builds, tagged develop-base and develop-full, will start from the respectively builds without 'develop' and will come with writing and visualization tools. All the builds will probably have some semantic versioning system.

What I've done right now is implement base and full through two different Docker files into two different directories in the same Git Hub repository. Whenever a tag base or full is created/moved, the corresponding build is triggered. This implementation has a problem: if I move the tag base, the image base is correctly built but all the images that depend on it are not built again and I have to manually trigger them. What I've thought is to have a branch for each tagged image (with the corresponding automated builds triggered at each new push on that branch) and a tag system to keep track of the version number (with the corresponding automated builds triggered at each new tag). The tags will be base, full, develop-base, etc. for each latest version and with semantic versioning for each version, including the latest, i.e. 1.0-base, 2.3-full, 1.3.1-develop-base, ecc. In the latter case, the automated build triggering will probably have to handle regular expression to automatically label the images with a version number.

I realize that my question isn't very related to what I wanted to achieve but I want to learn to walk before trying to run. Thus, I want to understand when and why one should choose one way or the other to put on a docker hub repository with several images and which are those ways. The project of LaTeX images itself, that maybe you could think that is very naive, is to deeply understand the way docker, docker hub, docker cloud, docker compose, ecc. work.

Improve this question
11
  • I would hazard that this question has no good canonical answer. It is worth describing patterns though. The right pattern would depend on your codebase, dependencies and delivery pipelines. Would you consider rewording the question to ask about patterns instead of the single best way?
    – Bruce Becker
    Commented Nov 27, 2018 at 7:31
  • @BruceBecker In my last sentence, I said that probably I've missed the whole point. My aim is to understand how to organize a project that is supposed to have multiple tag images. If you think that the question could be rewording to better achieve this result, feel free to edit it. I'm not lazy, simply I don't know what should I ask instead of what I already did.
    – gvgramazio
    Commented Nov 27, 2018 at 10:11
  • @BruceBecker I don't know if it is relevant but I want that my repository should be linked to an automatic build. I didn't specify it in the question because I was worried to mix too much things that are not completely clear in my mind.
    – gvgramazio
    Commented Nov 27, 2018 at 10:13
  • I agree with @BruceBecker that here it seems hard to provide a "canonical" answer. I would even suggest there is no direct connection between tagging of images and the location of Dockerfiles. That is, you could have just one Dockerfile but many tags if you give them by date and number of the CI build which produced them. Also, you could parametrize a Dockerfile including the base image to use which might reduce the demand to have many Dockerfiles.
    – Ta Mu
    Commented Nov 27, 2018 at 11:39
  • @gvgramazio - no stress, I was just trying to get at the heart of your question, so that we can have a useful answer and actually solve your problem :) I think your comments help to clarify the situation, so an answer should be possible soon.
    – Bruce Becker
    Commented Nov 27, 2018 at 11:41

1 Answer 1

Reset to default
2

If you think of the Dockerfile as a kind of "bill of materials" for your containers, then there is the following consideration:

  • container environments are mostly same - you can use many Dockerfiles in same folder, or even just one Dockerfile with parametrized builds
  • container environments are or might divert in terms of further "local assembly parts" configuration files, scripts etc., then you are better off with using separate folders.

Branching has rather to do with developing versions, or also independent features which then should be anyway merged together. See Git flow on this topic.

As a reference project laoyut, check for example the GitHub project linked from Tomcat Docker Hub site. Here you find different folders, even with single Dockerfiles.

See also this TeX-Docker distro:

Side note: strange enough there is no "official" Docker distro for TeX, while many other well established open source communities have this library entry.

Improve this answer
6
  • One thing that I don't understand is how I could use many Docker files in the same directory with automated builds. I know that when I build them manually or through a makefile I could set the docker file name for each tagged image, but I don't know how to do it with automated builds.
    – gvgramazio
    Commented Nov 28, 2018 at 11:07
  • Do you mean the Docker Hub image build automation?
    – Ta Mu
    Commented Nov 28, 2018 at 11:10
  • I currently use gitflow on other projects. I wanted to use it also in this case but first I should solve the part about automated builds of semantic version tags with regex (that will be the topic of my next question on devops probably). Also, even if it is true that in gitflow version are developed through branch, the opposite could be not true, e.g. I could use branches for features. Also, each release branch is supposed to die somewhere while the tags that indicate the version is supposed to survive and not to be moved.
    – gvgramazio
    Commented Nov 28, 2018 at 11:12
  • Yes, I mean exactly that. I edited my question to better clarify which is the context in which I want to develop these things. However, think of the edit only has a clarification of the context, my question still is about the best practices to put on a docker hub project. I will post the other doubts in other question. This is because if the question is too strict maybe it could not be helpful for future users.
    – gvgramazio
    Commented Nov 28, 2018 at 11:15
  • 1
    I really appreciate your effort. In particular, the TeX-docker repository is the first automated build with multiple tags that I've seen. I will explore it in details. However, I miss how he/she automates the process but probably I will soon send a mail. I think that it's related to webhooks (a concept that I still don't grasp).
    – gvgramazio
    Commented Nov 28, 2018 at 22:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.