#docker (2021-08)

Learn from Docker experts to simplify and advance your app development and management with Docker. Stay up to date on Docker events and new version announcements!

ansible-playbook + buildah = a sweet container image - GitHub - ansible-community/ansible-bender: ansible-playbook + buildah = a sweet container image

docker pull: Most of your images will be created on top of a base image from the Docker Hub registry. Docker Hub contains many pre-built images that you can pull…

In any new tech, there are lots of thoughts around “best practices”. When a tech is new, what makes a best practice? Working at Microsoft, running the Azure Container Registry (ACR), talking with lots of customers, some that use Azure and some that don’t, we’ve had a lot of exposure to what customers have encountered. We’ve been working on a number of scenarios, including container life cycle management and OS & Framework patching with containers. This has surfaced a number of interesting issues. Issues that suggest, “both sides” of the tagging argument  have value. It’s easy to get caught up, arguing a particular best practice, …if you don’t first scope what you’re practicing. I’ll start by outlining two basic versioning schemes we’ve found map to the most common scenarios. And, how they are used together to solve the container life cycle management problem. Container Patterns Support a Self-Healing Model Before I get into specific tagging schemes, it may help to identify a specific scenario impacted by your tagging scheme. The most basic container scenario supports restart type policies. docker run –restart always myunstableimage:v0 This helps when a container fails due to some internal reasoning. But, the host is still available. In this case, our code must be resilient. Or, to an old friends point (Pat Helland), “we must write our software with a apology based computing approach.” Apology based computing suggest our code must deal with “stuff” that happens. A set of code, or a container may fail and need to re-run that logic. For the purposes of tagging, I’ll stay focused on the other aspect; we must assume a container host may fail at any point. Orchestrators will re-provision the failed node, requiring a new docker pull. Which begs the question: when you have a collection of containers running the same workload, do you want them to all run the same workload, or some of them have the last version, while new nodes have a newer version?

In the above diagram, we have: a local build of 3 images: web:1, api:1, cache:1. Looking closely, we can see every tag has an ID, otherwise known as a digest. When the images are pushed to a registry, they are stored as two parts. The image:tag, and the underlying digest. These are actually separate elements, with a pointer between them. A deployment is made, using the tag. Not the digest. Although, that is an option. Digests aren’t as clean as I show here. They actually look like this: f3c98bff484e830941eed4792b27f446d8aabec8b8fb75b158a9b8324e2da252. Not something I can easily fit in this diagram, and certainly not something you’d want to type, or even try and visually find when looking at the containers running in your environment. When a deployment is made to a host, the orchestrator keeps track of what you asked it to deploy and keep deployed. This is the important part. …wait for it… With a deployment saved, the orchestrator starts its work. It evaluates what nodes it has to work with and distributes the request. A few things here. While many would argue Kubernetes has become the defacto standard for container orchestrators, orchestration is a generalized concept. Over time, we expect orchestration to just become the underpinnings to higher level services. But, that’s another post…

As our development team moves along, a new version of the api and cache are built and pushed. Since this is just a minor fix to version 1, the team uses the same tag. Our registry acknowledges the request, saving the new :1 version of the api and cache. Notice the original tags are now pointing to the new digests (3rp, 1n4) At this point, you likely see where this is going.

As Pat would say “Stuff Happens”. Actually, Pat would say something else. Our Host-B node has failed. No problem, our orchestrator’s job is to maintain a requested deployment. It sees the failure, evaluates the request made of it, and provisions the necessary resources to recover. Our deployment chart clearly says, keep 3 copies of web:1, 3 copies of api:1 and 4 copies of cache:1. So, it does a docker run of each of those image:tag combinations. It’s doing what it was told. Our Host-C now has the replacement images running

Is this the desired state you want? The orchestrator did it’s job. It was told to deploy and maintain a given set of images. The problem was actually further upstream, when we re-used the same tag for our images. Now, if you’re like most people, you’re likely thinking: I can deploy with the digest – yup, and you can view lots of these: f3c98bff484e830941eed4792b27f446d8aabec8b8fb75b158a9b8324e2da252 I can use semantic versioning, and always bump the number – yup, that sort of works, but read on I can use my git commit id – that’s pretty good as each commit is unique, and you can easily match a container image to its source. However, do you only rebuild your images when your source changes? …read on OS & Framework Patching While I believe in “never say never”, using stable tags for deployments are fraught with problems. However, Stable Tags do have their value. Let’s consider what happens when developers stop checking in code changes. In the VM world, Ops would continue to patch the running hosts for updates to the framework and patches to the host operating system. And, at some point, those patches may break the apps running on those nodes. One of the many benefits of containers are the ability to isolate the things our apps and services depend upon. Those dependencies are contained within our image, declared within our dockerfile. A multi-stage dockerfile for an aspnetcore app, based linux FROM microsoft/aspnetcore:2.0 AS base WORKDIR /app EXPOSE 80 FROM microsoft/aspnetcore-build:2.0 AS build WORKDIR /src COPY HelloWorld.sln ./ COPY HelloWorld/HelloWorld.csproj HelloWorld/ RUN dotnet restore -nowarn:msb3202,nu1503 COPY . . WORKDIR /src/HelloWorld RUN dotnet build -c Release -o /app FROM build AS publish RUN dotnet publish -c Release -o /app FROM base AS final WORKDIR /app COPY –from=publish /app . ENTRYPOINT [“dotnet”, “HelloWorld.dll”] In the above example, we can see two images. The aspnetcore-build:2.0 image to compile our code, then we copy the output from our build image to an optimized asnetcore:2.0 image. See: .NET and MultiStage Dockerfiles for more details For the focus of tagging and OS & Framework patching, notice our base image, used for the image we actually deploy. FROM microsoft/aspnetcore:2.0 AS base You can see we’re using the stable tag, 2.0.  This is where semantic versioning does play a role. The Core team releases new capabilities, indicated by the major version. They shipped 1.0, 2.0 and you can imagine they’ll continue to ship new capabilities. In the real world, new capabilities means things change, behaviors change, and thus, you want the development team to make a conscious choice which major version of aspnetcore they depend upon. This basic pattern is used across all major frameworks, java, go, node, etc. While the team focuses on new capabilities, they must also service each version. The aspnetcore image contains aspnetcore, dotnet core, as well as linux or windows server nanao base layers, depending on which architecture you’re running. How do you get OS & Framework updates? Should you have to bump your FROM statement for every release? While the team will publish additional tags for minor, non-breaking changes, each team does update their stable major tags. This does mean, depending on when you pull aspnetcore:2.0, you’ll get different content. But, that’s the intent. Whenever you pull the stable tag, you should get the latest OS & Framework patched image. I say should as not all …