SOLVED

AMA: Host vs container version compatibility

Copper Contributor

Hi,

 

What are the plans for host and container version compatibility. Having to rebuild the container because a host patch needs installing seems a bit to strict causing too much management in a larger installation.

4 Replies

Point of clarification: when you refer to a "host patch", are you talking about the underlying base image of a container? I.E, you have an image using windowsservercore as the base and it gets updated? The guidance we have for containers is that of a CI/CD (continuous integration / continuous development) flow with orchestration:

1. containers are meant to be torn down and spun up very quickly.

2. you can trigger new builds of your image when the underlying image is updated.

3. as you rev your image and rebuild it after the base image gets updated, the orchestrator would be spinning up the updated container and taking down the old one.

 

This is all to say: your conjecture about causing too much management can be mitigated by implementing CI/CD methodology.

 

Separately, you lead off the question asking about version compat. Are you inquiring about running 1709 containers on 1609/1703 hosts?

No, I did not refer to the rebuilding against a different base image, and spinning up new container versions. I meant 1709 containers on 1709 host but different patch levels. Like containers built on the rtm 1709 image running on 1709 ”january rollup” hosts.
best response confirmed by Ulf Axelsson (Copper Contributor)
Solution

Ah, understood. In the release of WS2016, our recommendation was to have matching host/container build and revision numbers. For example, consider a build with the value 10.0.14393.1944 (major/minor/build/revision). 14393 in this case is the build number for WS2016.

 

In 1709 we've relaxed this recommendation a little bit. Just so long as the host/container build numbers are the same (14393, 16299, etc), the revision numbers can differ. So in this case, for a host running 10.0.16299.125, it's ok to run a container with version 10.0.16299.19. Notice how the build number matches, but the revision number does not. 16299 in this case is the build number for Windows Server ver. 1709

 

Although, it is still best practice to have containers built with the latest image available. 

Great, thank you!
1 best response

Accepted Solutions
best response confirmed by Ulf Axelsson (Copper Contributor)
Solution

Ah, understood. In the release of WS2016, our recommendation was to have matching host/container build and revision numbers. For example, consider a build with the value 10.0.14393.1944 (major/minor/build/revision). 14393 in this case is the build number for WS2016.

 

In 1709 we've relaxed this recommendation a little bit. Just so long as the host/container build numbers are the same (14393, 16299, etc), the revision numbers can differ. So in this case, for a host running 10.0.16299.125, it's ok to run a container with version 10.0.16299.19. Notice how the build number matches, but the revision number does not. 16299 in this case is the build number for Windows Server ver. 1709

 

Although, it is still best practice to have containers built with the latest image available. 

View solution in original post