As I move to containers, I am realizing that the container concept ties the OS and the Application into the same deployment system.
Background
docker pull mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim
This command pulls the container image setup by Microsoft for the .NET Core Runtime. That container image depends on the mcr.microsoft.com/dotnet/core/runtime-deps:3.1-buster-slim container image. And that runtime-deps container image is built from the debian:buster-slim image.
The debian:buster-slim image currently targets version 10.2 of Linux Debian. But when 10.3 is released it will target 10.3. (And I assume it targeted 10.1 when it was the current release.)
Question
When the buster-slim tag of debian gets updated to target 10.3, do all downloads of mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim get updated to start using 10.3?
Or is mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim somehow locked in at 10.2?
I am worried about something like this happening:
I make a container that depends on mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim and release it to production (which runs Debian 10.2)
Debian releases 10.3 of their OS and update the buster-slim tag to point to 10.3.
I do a very minor change to my container (from step 1), rebuild the container image and deploy it. But because of how docker works, my minor change also includes an unintended OS upgrade to Debian 10.3.
I expect something like this when using the tag latest, but not when I am using a specific tag.
So this can be summed up with this question:
Am I going to get dependency upgrades for a tag, even if I keep using the exact same tag?
Yes, potentially. Nothing in Docker prevents authors from uploading a new image to the same tag multiple times, even for the specific tags like you're talking about here.
Related
We have an ASP.NET Core Docker image built via the default FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base in the Dockerfile.
We have a weekly build. Our vulnerability scan raises a different issue each build for low-level Debian libraries.
E.g. Week1: issue about libraryA v1. It is recommending us to update libraryA to v2.
But the following week, when we build a new Docker image, ASPNET automatically comes with v2 of libraryA. We didn't even have to do something about libraryA. But then, new vulnerabilities are reported, which will then be automatically fixed in the coming weeks.
Is there a way to tell ASP to use a specific OS version?
From the ASPNET dockerhub,
https://hub.docker.com/_/microsoft-dotnet-aspnet/
These are the tags for Debian11:
6.0.13-bullseye-slim-amd64, 6.0-bullseye-slim-amd64, 6.0.13-bullseye-slim, 6.0-bullseye-slim, 6.0.13, 6.0
Our build last November was using 6.0.11 by checking the docker history of the image.
It reported some issue about krb5/libgssapi-krb5-2, recommending it to upgrade to version 1.18.3-6+deb11u3.
Our docker image last November was only using deb11u2 when I docker-exec'ed into it.
Today (January), if I try the following FROM to force the specific ASPNET version, the library is automatically updated to deb11u3 out of the box.
• FROM mcr.microsoft.com/dotnet/aspnet:6.0.11 AS base
• FROM mcr.microsoft.com/dotnet/aspnet:6.0.11-bullseye-slim-amd64 AS base
I am thinking of baselining a specific ASPNET or Debian version, and I will just manually address the vulnerability reports by using apt-get of those libraries. But from my testing above, it seems like Microsoft automatically updates the underlying OS even if I specify a specific version in the Dockerfile's FROM.
Any clue how to tell ASPNET to use a specific OS version? (Sorry Docker newbie here)
The aspnet Dockerfiles aren't based on pinned versions of their dependencies, so even if you pin the aspnet version you want by using 6.0.13-bullseye-slim-amd64, if Microsoft rebuild it and re-publish it, some of the underlying libraries might have been updated.
To completely pin what version of the image you want, you can use the digest in your FROM statements instead of a tag. That way, you won't get any updates at all and will always point to the exact version of the image you want.
You use it like this
FROM mcr.microsoft.com/dotnet/aspnet#sha256:5cf4aaa3fceb9bca683d56213873c0e418133a1ed36886a629bca266fb12e41b
You can find the digest by running docker inspect image <image>. The digest is in the 'RepoDigests' field. The digest is also printed when you do docker pull.
You should then add a comment in the Dockerfile about what tag the digest refers to, since that's not obvious anymore.
Let me add that this might not be a good idea to do. You're denying yourself security updates that could fix important vulnerabilities. It might be worth looking into how you can have a smooth workflow and also get these updates at the same time.
After accidental run, I can't get nextcloud's database and image in sync.
My database is somehow updated to the latest version, but the image (apps) are not.
In my config.php the version is: 'version' => '20.0.5.2'
My version.php shows: $OC_Version = array(22,1,1,2);
If I spin up docker image version 20.0.12, the image keeps restarting with this error:
Can't start Nextcloud because the version of the data (22.1.1.2) is higher than the docker image version (20.0.12.1) and downgrading is not supported. Are you sure you have pulled the newest image version?
But If I start the latest (the same version of the "data") v22.1.1.2, I can't finish the update because:
Updates between multiple major versions and downgrades are unsupported. Can't start Nextcloud because the version of the datais higher than the docker image version and downgrading is not supported.
So I am kind of stuck! I can't run previous the version because the database reports it is updated, and I can't update to the last version, because it is not supported.
What should I do?
I read I have to update 'gradually' but the database reports it's already the latest version.
Just in case somebody is still looking for answer, you need to change your version.php file back to the version matching your last working configuration (in this case probably to 20.0.5.2). Definitely use backup of this file if you have it.
If you have no backup, you can make it yourself as described here: https://help.nextcloud.com/t/skipped-major-version-21-23-did-not-run-the-updater-yet/139638/2?u=vset
There's a current version of .net sdk 5.0 on docker hub:
https://hub.docker.com/_/microsoft-dotnet-sdk
If I run docker pull mcr.microsoft.com/dotnet/sdk:5.0 with tag 5.0, what will exactly be downloaded and used?
There are many versions in Full Tag Listing section with tag 5.0 or latest
I'm not even sure if it's on top of Windows or Linux.
This .NET SDK image page doesn't include the standard Docker Hub tag listing, but often in amidst the very long listing of names like 6.0.100-preview.7-focal-amd64 or 3.1.412-bionic-arm64v8 there will in fact be just a 5.0.
In this specific case, the image includes versions for each supported architecture, and so you will get whichever one matches your local Docker. The list of tags has a section for each supported architecture and where there is a 5.0 it seems to be in the first line.
As of this writing, on Linux the default 5.0 images are generally based on Debian "Buster"; on Windows, Nano Server 2022.
When starting a .NET 5 project locally there is an automatic roll forward, meaning when starting the project the runtime will choose the newest minor/patch version installed on the system.
For deploy to production I use docker with a typical Dockerfile with lines like
FROM mcr.microsoft.com/dotnet/sdk:5.0
and
FROM mcr.microsoft.com/dotnet/aspnet:5.0
When typing "dotnet --info" on the server where the docker image is running on I always get version "5.0.0".
I would like to know if I have to enter the correct minor/patch versions manually in the Dockerfile each time a new version is released or if there is a version specifier to install those small versions with automatic roll forward.
mcr.microsoft.com/dotnet/sdk:5.0 is a floating tag. It always refers to the latest patch in that major.minor release:
The tag is updated to always reference the most recent patch that is currently available for the Major.Minor release.
For example, if you inspect the docker image today, you should see this is a 5.0.102 SDK and 5.0.2 Runtime image:
$ podman inspect mcr.microsoft.com/dotnet/sdk:5.0 --format='json' | jq '.[0].Config.Env'
[
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"ASPNETCORE_URLS=",
"DOTNET_RUNNING_IN_CONTAINER=true",
"DOTNET_VERSION=5.0.2",
"ASPNET_VERSION=5.0.2",
"DOTNET_SDK_VERSION=5.0.102",
"DOTNET_USE_POLLING_FILE_WATCHER=true",
"NUGET_XMLDOC_MODE=skip",
"POWERSHELL_DISTRIBUTION_CHANNEL=PSDocker-DotnetSDK-Debian-10"
]
If you are seeing that this is still 5.0.0 on you server, you might be using an older container. By default docker run will run the image last pulled, without checking for an update.
You might need to docker pull to explicitly update the image, or use docker run --pull=always to make sure you are running the latest container image.
Docker hangs when I try to create a docker node
I am trying to set up a docker node as per step 4 of the instructions on docker.com. Unfortunately, Whenever I run the "create" command in the command prompt, the process hangs on
(testNode1) Waiting for host to start...
The instruction set is roughly as follows:
Enable HyperV (done)
Set up external network switch (done)
Reboot (done)
Create nodes (hangs)
The document explicitly states that step 3 is included to prevent exactly this error from happening. However, I have completed that step, and I still encounter this error.
Solutions I have tried
Other sources have suggested that I'm either targeting the wrong network switch, or that the one I've created is not set to "external". I have verified that the switch is set to "external" and that the correct network switch is being targeted, so that does not seem to be the problem.
I have also made sure to restart my machine a few times already, so I doubt another reboot on its own will help.
I also left it running for a day to see if it would eventually resolve itself, but it did not.
Additional details
The command I'm using is:
docker-machine create -d hyperv --hyperv-virtual-switch "VirtualSwitchName" testNode1
I am using Docker version 18.09
I am using Windows 10 Enterprise.
The node is hosted on Hyper-V
Make sure the Docker version is compatible with the Windows version
There are multiple versions of Docker Enterprise. Each successive version has improved functionality, but each version also requires a more up-to-date version of Windows 10.
For example, if you are trying to run Docker 18.09, then you need Windows 10 version 1809 or higher. Docker 18.09 is simply not compatible with earlier versions of Windows 10.
How to check for a compatible Docker version
There is a useful chart here detailing which versions of Docker are compatible with which operating systems. This will tell you what the highest version of Docker is that you can run based on your current OS.
To check your OS version, open your command prompt and type "winver". This will bring up a popup telling you what version of windows you are running (for example, Windows 10, Version 1709). Use this and the above chart to determine if your current version of Docker is compatible with your current OS.