(UPDATED) Sitecore Managed Cloud Containers: Using Your "Latest" Image
Tags: sitecore, managedcloud, containers, kubernetes
Published: 2022-02-10 02:07:44

**Update 2/11/2022:** So the chatter on Slack seems to be to NOT do things this way. In fact, it looks like when my `latest` worked, it was because I updated the codebase. But later I ran the pipeline without pushing changes, and it was like it used cached versions of everything, even though my `latest` tag had changed versions. So for now, the process to get new versions of your custom images pushed has to be:

- Create a branch off the `main` branch
- Change the `config/docker-images/docker-images.json` file to update the tags as appropriate
- Check in and merge your changes to the `main` branch
- Your pipeline will fire automatically from there and update your environment

---

This is the first post I'm writing on Sitecore's managed cloud containers offering. I'm planning to put together a good number more about local setup, CI/CD, integrating with Sitecore's pipelines, etc etc. Now, this post is a little more advanced, but we just solved it and I wanted to share.

#### Quick Overview
As a quick overview, what Sitecore gives you "out of the box" when you set up a containers environment is an Azure setup that includes Kubernetes, SQL with elastic pools, a storage account, a container registry, KeyVault, FrontDoor, and other bits. They also provide an Azure DevOps instance with pipelines and configurations to build out your Sitecore environment, already keyed to a default instance. So you start with quite a lot of infrastructure set up for you, which is good!

#### The Issue
One of the frustrations I've heard from developers is that Sitecore makes you have to change the tag of your custom images each time you want to do a deployment. Sitecore has a `config/docker-images/docker-images.json` that spells out each image used in the deployment. As noted, by default you'll have the base images for Sitecore's various services. In a typical setup, the main images you'll replace will be the CM and CD images, as that's where your solution code really goes. But if you need to update your other images, here you go!

I'm assuming that you're familiar with containers here, so you'll understand that each image has a tag. In the default case, it gives you the Sitecore version you're on as a tag for each image. But you'll have your own tags for your custom images. In our CI/CD process, we use the build number as a tag (IE 20220209.1). What Sitecore tells you is that when you push an updated image to the Azure container registry (ACR), you need to go into this file and manually change the tag to your new one. Then save the file, merge it to the main branch, and you'll kick off a build. That's great...and annoying, because containers have a convention for this.

#### The Solution
So, when you send your images up to the ACR, you can tag it with the build number, as well as the `latest` tag. That's a convention that lets you know which image is considered the most up-to-date, and when you push a new image, the `latest` tag is transferred to the next image in line. (Pushing/tagging will be covered in a future post on CI/CD.) Then you can change the `docker-images.json` file to use the `latest` tag instead. Except...this won't work right away. I tried this, and when I posted a ".2" tag up that replaced `latest` as well, the new image didn't get posted out. So I checked in with my friendly neighborhood containers guy, Sean, for some help.

It's a two-step process to get this working. Step one, in your `platform-artifacts` folder, you have a YAML file for each Sitecore service. So, assuming you're just updating the CM and CD images for now, those are the YAML files to open. When you open the file, look for the `containers` section and add a line for `imagePullPolicy: Always` as shown below:

![Image Pull Policy](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ptrriwe6kpcwpjlm2n6c.png)

Step two, in your `pipelines` folder, open up the `application.yaml` file, which is the execution pipeline that pushes out your changes. Look for the `script` section, which will have a `docker-compose up` command, and tack on a `--quiet-pull` option to enforce the pull request. It should end up looking like this:

![Docker Compose Command](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e0r9zu4tur5kg4te3fjd.png)

Check in and merge your changes to the main branch, which will kick off the application pipeline, and check if your changes were applied!