Continuous Integration (CI) and Continuous Delivery (CD) methodologies are key traits of a modern software development practice. Docker Enterprise Edition (Docker EE) can be a catalyst for this DevOps mindset, integrating with your preferred tools and existing practices to improve the quality and speed at which innovation is delivered.
In our recent webinar, Integrating CI/CD with Docker Enterprise Edition, we walked through an example where a developer is using GitLab as the CI tool of choice. If you missed the webinar, you can watch the demo here:
Here are some of the top questions from the webinar:
Q: Can you explain the process for deploying the application to production shown in the demo?
A: This example leveraged a capability called image promotions to automatically push an approved image to the “prod” repository. The policy was defined to look for images in the “dev” repository with a specific label. If that image has less than the preset number of vulnerabilities from a security scan, it is automatically moved to the “prod” repository and a new label of “latest” is attached. With the “latest” image updated, a service refresh replaces the old production website container with the new version and the fixed code is live in production.
Q: In that demo, could you automate the last step or add more checkpoints to the process before pushing to production?
A: Yes! This is all very flexible and can be customized and configured in your CI setup.
Q: The demo added a tag “latest” to the image when it was moved to production. Is that a best practice? Won’t that get overwritten easily?
A: The demo showed a simple example, but organizations can implement different policies with the built-in capabilities of Docker EE to provide additional security checks. For example, administrators can declare certain repositories to be “immutable”. That means once an image is pushed to that repository with the “latest” tag, that tag cannot be overwritten by another image. You can also leverage automatic image promotions which can add version numbers and dates to the label. Finally, you can prevent unsigned images from being run in the environment by leveraging image signing.
Q: To integrate GitLab with Docker, does the GitLab Runner need to have a Docker Trusted Registry (DTR) account? And what does it sign the image with?
A: Instead of creating an account for the CI tool, in this demo, we’re using the client bundle. So instead of a docker login command to get access to the registry with a username and password, a copy of a client certificate is attached to the GitLab Runner, and that is being used to authenticate back into Docker EE. This TLS-encrypted authentication model allows the CI tool to have access to both DTR and the Universal Control Plane. The client bundle can be easily created and revoked in Universal Control Plane.
Q: Regarding the image signing feature, can different teams get keys to sign images?
A: Yes! Docker EE supports LDAP and Active Directory integration as part of the role-based access controls. Users, teams, and organizations can all sign images as part of the CI/CD workflow. Administrators can then set Docker EE so that only signed images are allowed to run.
To learn more about Docker Enterprise Edition:
- Download this whitepaper about Mirantis Kubernetes Engine (formerly Docker Enterprise Universal Control Plane)
- Test drive Mirantis Kubernetes Engine (formerly Docker Enterprise/UCP)