Establish governance for your image repositories

Introduction

Public cloud provides private repositories to host your images. You can maintain a shared image repository that is highly avaialble for all your workloads across regions. As your organization grows and more and more containerized workloads are run, it is essential that you establish governance process for image repositories. This article discuss some of the governance items that you should consider

Distingush development images from release images

When you have continuous integration setup, you end up with a lot of development images provided you do not overwrite using same tags. For a strategy similar to gitflow, you would also have images built from master/main branch. It is essential that you are able to distinguish between development and release images as that will help you clean up development images at regular basis. Consider using one of the following approaches

• Use standard image naming convention. This allows you to build automation that can use image naming standard to apply some logic.
• Use tag prefix or suffix to mark images as development or release. For example dev images can be tagged as {version}.{buildId}.dev while release images can be tagged as {version}.{buildId}.release or simply {version}.{buildId}
• Use different repos for development and release images. In this case, ensure that your build piplines have branch and repository awareness. Your deployment pipeline should also be aware of target env and should pull images from corresponding repos

Monior storage

Storage is not free. The more images you keep, the more storage you use and gets charged. Use the following approach to monitor storage

• Setup alerts for when you are nearing to storage limits
• Define retention policy — limit number of images that are retained. Fir example, you can retain 3 latest development images. If you have a multi tenant shared system and do not need to cater to multiple customers to support multiple versions, you can keep 3 latest images — one for current release and 2 for rollback scenarios if needed
• Tag your code in code rwpo with release number. Ensure you build pipelines that can build images based on release tags. This will help you to rebuild images if required even though you do not have them in image repo
• Perioically purge images based on retention policy. Public clouds provides tooling to purge images using cli or api based on filters. Build scheduled pipeline or crons to execute perge at regular intervals

Establish a strong communication mechanism

In a devops culture, communication is the key. Define cimmunication channels such that all governance related activities are communicated to all stakeholders. This can include

• Publish a list of images to be purged in next run
• Publish stats on storage consumption, number of repositories and images within each repository
• Whever possible publish additional metadata like age of the image, last accessed date, owner, size that can help governance team.
• Build compliance utils and publish non compliance. For example, your build pipeline can verify image name format and fail the image build process if image name is not compliant.

Use image best practices

You can find a list of best practices for docker builds. Adhering to these will help minimize size of the image that helps reduce the size of the storage. A few important considerations are

• Use minimal images as base images. The minimal images only package the required runtime to run your application in container
• If use of minimal image is not possible, consider removing debug tools, ide, utilities that are not required for your container to run
• Minimize layers to improve build time
• Use multi stage images to reduce image size

Do share your comments or any other best practices that you follow.