Dec 05 2017
09:10 AM
- last edited on
Apr 15 2021
11:37 AM
by
TechCommunityAP
Dec 05 2017
09:10 AM
- last edited on
Apr 15 2021
11:37 AM
by
TechCommunityAP
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.
Dec 05 2017 09:21 AM - edited Dec 05 2017 09:23 AM
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?
Dec 05 2017 09:29 AM
Dec 05 2017 09:44 AM - edited Dec 12 2017 01:37 PM
SolutionAh, 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.
Dec 05 2017 09:44 AM - edited Dec 12 2017 01:37 PM
SolutionAh, 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.