Debian Jessie End of Life -- Impact on .NET Core Docker Images

[richlander]

Debian Jessie End of Life -- Impact on .NET Core Docker Images

Debian Jessie (AKA Debian 8) is now out of support. Debian Jessie is no longer a supported operating system for .NET Core. Docker users need to switch to Debian Stretch-based (AKA Debian 9) images to stay in support.

Context

Jessie-based images are currently provided for .NET Core 1.0, 1.1 and 2.0. .NET Core 1.0 and 1.1 expose multi-arch tags, such as 1.0-runtime and 1.1-sdk, that support Debian Jessie. When pulled for a Linux Docker daemon (on Linux or Windows), these tags pull Jessie-based images. .NET Core 2.0 supports Jessie, but it is not the default. .NET Core 2.0 multi-arch tags, such as 2.0-runtime and 2.0-sdk, pull Debian Stretch-based images, when pulled for a Linux Docker daemon. We made a conscious decision with .NET Core 2.0 to move off of Jessie as the default to avoid this problem, based the Jessie 2018 EOL date. .NET Core 2.1 does not support Jessie, only Stretch.

We recently posted about our policy for underlying operating system dependencies with Docker:

For each major and minor .NET version, we may take a new major operating system version dependency. As I mentioned earlier, we adopted Debian 9 as the base image for .NET Core 2.0. We stayed with Debian 9 for .NET Core 2.1, since Debian 10 (AKA “Buster”) has not been released. Debian 9 will remain the default base image for .NET Core 2.1 for the life of .NET Core 2.1. Once we adopt an underlying operating system major version, we will not change it for the life of that given .NET release.

Source: https://blogs.msdn.microsoft.com/dotnet/2018/06/18/staying-up-to-date-with-net-container-images/

Plan

We will continue to re-build .NET Core 1.0 and 1.1 multi-arch tags on top of Jessie for the remaining supported lifetime of .NET Core 1.0 and 1.1. We will also provide a Stretch-based image for .NET Core 1.1. This tag will look like the following: 1.1-runtime-stretch or 1.1.9-sdk-stretch. This is same format that Jessie has used.

We will produce Jessie-based images for NET Core 2.0 until October 2018, which is when .NET Core 2.0 support ends. .NET Core 2.0 multi-arch tags support Debian Stretch, not Jessie, as described above.

In summary, .NET Core is no longer supported on Debian Jessie, with Docker or otherwise. We will produce Docker images for Jessie until .NET Core 1.0, 1.1 and 2.0 support ends, respectively, to avoid breaking applications. This aligns with the policy defined above, per Staying up-to-date with .NET Container Images.

Affected Repos

• microsoft/dotnet
• microsoft/dotnet-nightly
• microsoft/aspnetcore
• microsoft/aspnetcore-build

[dasMulli]

Would be interesting to see if users may actually want an automatic switch to a higher OS version. While it may be a breaking change in OS functionality, it shouldn't be breaking in terms of .NET Core API behaviour (🤞).
To stay on the same base OS versions, fixed OS images should have the version name (1.0-runtime-jessie) in there from the start and 1.0-runtime may switch base OS.
Personally, I would prefer this approach, but I can't speak for everyone and I do see the downsides. Most important: If you don't have some form of staged rollouts, integration tests using built containers or just proper monitoring, you may risk breaking a production deployment.
On the other side, the typical "MVC website using SQL/EF to a DB" shouldn't be affected since those APIs are already meant to abstract away platform specifics.

[richlander]

Most important: If you don't have some form of staged rollouts, integration tests using built containers or just proper monitoring, you may risk breaking a production deployment.

This true. At the same time, we've received complaints when we cause build/test break's in people's CI systems.

To stay on the same base OS versions, fixed OS images should have the version name (1.0-runtime-jessie) in there from the start and 1.0-runtime may switch base OS.

That's pretty subtle given that multi-arch is the default choice. Documenting a different policy ahead of time would help but it wouldn't cover all cases. That said, we should think about it more for .NET Core 3.0. It has also occurred to me to switch to Alpine as the default base image for 3.0.

Your base premise is correct that .NET apps are much more susceptible to changes in .NET than the OS in the general case. The case I'm worried about are Dockerfiles that install their own APT packages. Those installations may not work across major Debian versions. This is a more extreme example, but we want to avoid scenarios like this: docker-library/openjdk#180

[MichaelSimons]

1.1 Debian Stretch images are now available.