Asp.net core 6 Docker OS - docker

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.

Related

How to know which Docker image is used for .NET SDK latest tag?

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.

Is Docker-ized dev envoirment good for maintaining legacy software?

Let's say I have old, unmaintained application that lives on a VPS (i.e. Symfony 3 PHP app that relies on PHP 5).
If some changes are needed I have to clone this app to my desktop, build it, change and re-deploy. As time goes, recreating desktop dev environment gets harder - in this example I can't simply build the app as I use PHP7 in my CLI that breaks building process.
I tried to dockerize the app, so I added Ubuntu 18 to my docker-compose file... and it doesn't work as latest Ubuntu that has PHP5 support is 14.04. 14.04 is also the oldest (official) version available on DockerHub. But will it be still available in 3 years? If not, Docker won't build a container.
So, my question is: is Docker a right tool to solve described problem at all?
If so, should I backup docker images described that my build relies on?
If not, beside proper maintenance, what tool is better?
You can install PHP5 in newer ubuntu versions, but it means adding an external repository.
You could also create your own docker image, containing only the libraries you want. If so, I'd advise to try and use alpine as a base image. There is a bit of a learning curve to adapt, but once you do it you'll have a small image tailored to your needs.
Given that containers allow you to isolate processus and conf with minimal footprint compared to a VM, I think it is the best option. Tailoring and maintaining your own image is not that expensive in terms of maintenance if you document it correctly, and it will allow you to always have a system 'maintaining' all your precise requirements.

Do docker layers allow for unintended container OS upgrades?

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.

Cannot find latest dotnet core images on docker (2.2.7)

I am using this docker image now:
microsoft/dotnet:2.2.2-aspnetcore-runtime-alpine
I want to upgrade to 2.2.7 but can't manage to find correct tag on docker:
This url https://registry.hub.docker.com/v1/repositories/microsoft/dotnet/tags seems to only have 2.2.2 as the latest version.
It seems that Microsoft has moved to their own docker repository (mcr.microsoft.com/dotnet/core/runtime:2.2) while maintaining documentation on docker hub? I am really confused with what is going on in there.
So I really want to find a corresponding image to my original but version 2.2.7 for both aspnet or ordinary runtime (without aspnet)
Have found out with some help from Panagiotis:
Microsoft has moved all their images to own repository, see more information here. They do reference these images from a documentation on docker hub even though the images are not published there.
Docker images that can be used for dotnet core:
mcr.microsoft.com/dotnet/core/runtime-deps:2.2.3 - use for deploying self-contained deployment apps
mcr.microsoft.com/dotnet/core/runtime:2.2.3 - use for deploying .NET Core console apps
mcr.microsoft.com/dotnet/core/aspnet:2.2.3 - use for deploying ASP.NET Core apps
mcr.microsoft.com/dotnet/core/sdk:2.2.105 - use for building .NET Core (or ASP.NET Core apps)

Which source/tag should be used to download Odoo 12 community for Synology/Docker

Good Day:
I have been trying to create an Odoo 12 community version container on Docker in Synology DSM. Which source/tag should I use for this purpose?
The following source is the one I have been working with directly from Synology Docker:
https://hub.docker.com/_/odoo/
(Tag: Latest)
The only thing I have been able to do is creating a container for Odoo 12 enterprise, but not for Odoo 12 community.
Please advise.
Regards,
The official Odoo docker version is currently from date 2018-10-08 and it had a bug that showed incorrectly Enterprise version in Settings page also in Community version. So the good news is that you are in fact already running Community version. The bug was fixed in this commit.
The more complicated question is what version of docker image should you run. The official Odoo docker image (library/odoo or _/odoo or just odoo) does not get updated very frequently. It is not updated to fix issues. I would not recommend it for any other use than testing.
You can use other images that are updated more frequently and have static tags, e.g. I maintain an image with nightly Odoo builds. It is named veivaa/odoo. You can use a specific version of Odoo nightly build with tag version-date, e.g. veivaa/odoo:12.0-20181106. The nightly image can be found in Docker store at https://store.docker.com/community/images/veivaa/odoo. This version is updated on ”best effort” bases.
You find more information on running Odoo in Docker in my blog.
It is also not best practice with Docker to use the latest tag in production use or if you need to be able to keep the container stable. This is because you would get a different version depending on when you pull the image. Best practice is to either use a stable nonchanging tag, or build your own Dockerfile and image in own container registry.

Resources