Ask HN: What best practices for in-house Docker Registry?

Hello,

I am using Gitlab EE at work and have noticed recently that we had some issues with our registry validation process.

I was specifically wondering how to handle the history associated with any given tag. I realize that in our Gitlab registry, we have4 tags which have specificity. However we don't have the source branches for these, hence we don't exactly know what these specificities are.

Are there any best practices in this particular area? What is your experience with such issues?

57 points | by cellover 2251 days ago

2 comments

  • underyx 2251 days ago
    At Kiwi.com what we do is we add tons of labels when building the images:

        --label build-date=`date -Iseconds`
        --label vcs-url=$CI_PROJECT_URL
        --label version=git-$CI_COMMIT_SHA
        --label com.kiwi.gitlab.ci.builder=$GITLAB_USER_EMAIL
        --label com.kiwi.gitlab.ci.pipeline=$CI_PROJECT_URL/pipelines/$CI_PIPELINE_ID
        --label com.kiwi.gitlab.ci.ref=$CI_COMMIT_REF_NAME
        --label com.kiwi.gitlab.ci.build=$CI_PROJECT_URL/builds/$CI_JOB_ID
    
    Also, all images that get to prod are commit hash tagged, but for development we also tag them with the branch name:

        --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
        --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
    • zie 2251 days ago
      This is a great idea! We put a BUILDINFO.txt in the the container that carries all this information(and more).

      This is a history thing, we have stuff in production not in docker, and we use this approach with all the non-docker stuff and just carried it into docker. But I'm going to go add the data as labels to the image now as well!

      • underyx 2251 days ago
        What's really great about these labels is that they show up in Rancher's web UI, too, so when managing stacks, all the URLs and information are right there.
    • jabzd 2251 days ago
      This is exactly what we do as well and the approach works pretty well. We also tag the associated git repo with a build id and branch name so by looking at the git repo, you can tell if and when something has been built.
  • seslattery 2251 days ago
    What I've done before is use branch-buildID (develop-009) for tags, and then add detailed information like the git commit sha, git version tags, as labels. All of these labels were passed in as build args to Docker from the CI/CD system. One other important thing to consider is if you have docker tags that can be overwritten, which is the default in most repos, in the docker file it is useful to specify FROM sha256 checksum instead of labels for reproducible builds.