
Ask HN: What best practices for in-house Docker Registry? - cellover
Hello,<p>I am using Gitlab EE at work and have noticed recently that we had some issues with our registry validation process.<p>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&#x27;t have the source branches for these, hence we don&#x27;t exactly know what these specificities are.<p>Are there any best practices in this particular area? What is your experience with such issues?
======
underyx
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
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
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.

------
seslattery
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.

