patterndockerMinor
Coupling docker registry and source control
Viewed 0 times
controldockersourcecouplingregistryand
Problem
What are the best practices (if any) for coupling a docker image registry with a SCM service (such as bitbucket)?
I know a docker registry can live in artifactory, but how can I assure that the two are as tightly coupled as possible?
For example I am worried that without due-diligence from developers the latest Docker image in the registry will not reflect the current state of the Dockerfile in SCM or vice-versa. Also it is imperative that we can always trace back to the base Dockerfile (that we made) for any image in the registry.
I know a docker registry can live in artifactory, but how can I assure that the two are as tightly coupled as possible?
For example I am worried that without due-diligence from developers the latest Docker image in the registry will not reflect the current state of the Dockerfile in SCM or vice-versa. Also it is imperative that we can always trace back to the base Dockerfile (that we made) for any image in the registry.
Solution
If you want a beautiful integration between Docker and SCM, GitLab provides it's own built-in Docker registry. This makes publishing a Docker image in the build pipeline a breeze.
The other big advantage of GitLab Docker registry is that it supports multiple Docker repositories for each GitLab repo. This allows you to create a new Docker repo for each branch, or each commit, each environment, or anything you need.
My company leverages this by pushing our images to repos based on the branch, tagged with their commit. Here is an example:
Or if you have multiple Docker images being build for a particular branch (like a front-end Angular app and it's back-end API that it talks to), you can scope it even further, like so:
There are no limits to the number of slashes (/) you can use for scoping. This makes it very easy to tell the exact commit of an image when it's deployed. For this reason, my company almost never uses the generic 'latest' tag. We prefer the specificity of which image is deployed where.
You can still apply this same 'multiple docker repo' logic to any Docker registry. You'll have to look up that specific system's capabilities for creating new repos on the fly, and how easy it is to integrate with your CI/CD pipeline.
The other big advantage of GitLab Docker registry is that it supports multiple Docker repositories for each GitLab repo. This allows you to create a new Docker repo for each branch, or each commit, each environment, or anything you need.
My company leverages this by pushing our images to repos based on the branch, tagged with their commit. Here is an example:
project-name/branch-name:commit-SHAOr if you have multiple Docker images being build for a particular branch (like a front-end Angular app and it's back-end API that it talks to), you can scope it even further, like so:
project-name/branch-name/api:commit-SHAproject-name/branch-name/front-end:commit-SHAThere are no limits to the number of slashes (/) you can use for scoping. This makes it very easy to tell the exact commit of an image when it's deployed. For this reason, my company almost never uses the generic 'latest' tag. We prefer the specificity of which image is deployed where.
You can still apply this same 'multiple docker repo' logic to any Docker registry. You'll have to look up that specific system's capabilities for creating new repos on the fly, and how easy it is to integrate with your CI/CD pipeline.
Context
StackExchange DevOps Q#3334, answer score: 5
Revisions (0)
No revisions yet.