Ask HN: What best practices for in-house Docker Registry? | Hacker News Reader

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

57 pointscellover5 comments

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?

View on HN

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

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.

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!

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.

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.

Reply on news.ycombinator.com