Upcoming breaking change: Drop reference to buildpack-deps for SDK images

[richlander]

Upcoming breaking change: Drop reference to buildpack-deps for SDK images

We intend to change the parent image of .NET SDK images, from a buildpack-deps image to a dotnet/core/aspnet one. This change will only be made to 5.0 images, and only affects Debian and Ubuntu images, as described in the following table.

Image	Current parent image	New parent image
sdk:5.0-buster	buildpack-deps:buster-scm	aspnet:5.0-buster-slim
sdk:5.0-focal	buildpack-deps:focal-scm	aspnet:5.0-focal
sdk:5.0-alpine	runtime-deps:5.0	aspnet:5.0-alpine
sdk:5.0-nanoserver	nanoserver	aspnet:5.0-nanoserver

Alpine and Nano Server are included in the table above, because a similar (but not the same) change is being made for those images. See: #1351.

The benefits are the following:

• Size savings, on the order of the entirety of the size of the aspnet image in the case of Debian Buster, and the entirety of the .NET layer of the aspnet image in the case of Ubuntu Focal.
• Reduction in surface area, for potential security vulnerabilities.

We don't have the size saving on-hand currently. When that information is available, it will be added to this issue.

We will install git, curl, and wget packages in the 5.0 SDK images going forward.

We are planning to make this change for .NET 5.0 Preview 3 (April 2020).

Breaks and Workarounds

If you rely on tools provided by buildpack-deps:scm (beyond the three mentioned above), you will be broken by this change. We would like to know about that. Please share your scenario in the issue comments.

The complete list of tools provided by buildpack-deps:scm can be easily discovered by looking at the following Dockerfiles, for the curl and scm layers.

For Debian:

• buildpack-deps:buster-scm
• buildpack-deps:buster-curl

For Ubuntu:

• buildpack-deps:focal-scm
• buildpack-deps:focal-curl

If you rely on these tools as part of docker build, you are encouraged to install the required tool(s) yourself in your Dockerfile, or rely on multi-stage build, by using a buildpack-deps stage, as we do for .NET runtime images.

If you rely on these tools as part of docker run, you can potentially install them via a script.

Please share feedback if you this change breaks your workflow.

Context

Since .NET Core 1.0, we've been releasing SDK images on top of buildpack-deps images. We made this choice for two reasons:

• We needed access to curl to download .NET Core.
• We saw that other developer platforms (for their SDK) depend on buildpacks-deps:scm (example), which contains curl.

This made choosing buildpacks-deps:scm for the .NET Core SDK images an easy choice. We did that and moved on.

Later, Docker developed the multi-stage-build feature, which opened up many new possibilities. In particular, this feature enables you to download or build assets in one stage, and then copy into another. That's a pattern we've adopted for our runtime images.

We realized early on that the buildpack-deps dependency was problematic because it meant that the SDK images could not depend on runtime images. This means for multi-stage builds that you download the runtime twice, once with the SDK and another time for the final image. That's very unfortunate.

Both Windows and Alpine don't have a buildpack-deps image offered. That means that we have more freedom to layer our images. That's what we're proposing to do @ #1351.

Upon further thought, we realized that we didn't have any actual customer evidence that buildpack-deps was needed (as part of sdk images). We have plenty of evidence that the layer is problematic, and can deliver a sizable performance improvement to anyone using the sdk and a runtime or aspnet image in a workflow (multi-stage build of a .NET image would be the most obvious example). We believe that this change will have a large positive impact on millions of builds ever day, and have a massive impact on any commercial build host.

We hope that we can deliver this benefit to .NET docker image users. In particular, we hope that we can find satisfactory workarounds for users that are impacted by this change.

[jkotas]

git clone is the first thing I do with the SDK image in 50+% of cases. I think it would be unfortunate to lose git.

[mthalman]

After discussion, the POR is to include the following list of packages to help compensate for what is lost by not using buildpack-deps:

• curl
• git
• wget

[richlander]

The issue text has been updated to reflect this decision. I also added links to the various container layers so that people could discover the packages that will no longer be available.

[mthalman]

For a description of the size benefits provided by these changes, see the comparison results at #1848 (comment).

[mthalman]

Here's a comparison of the benefits these changes provide in terms of the download cost savings. (These comparisons also contain data for the changes made in #1351.) The canonical scenario here is a multi-stage Dockerfile that builds and publishes an ASP.NET app (see the sample ASP.NET Dockerfile). The scenario involves first pulling the SDK image in order to build the application and then pulling the ASP.NET image to contain the published application. Before these changes, there was no layer sharing between the ASP.NET image and the SDK image. This was wasteful because the SDK image does contain ASP.NET bits; it just wasn't based on the ASP.NET image. With the changes that were made here, the SDK is now based on the ASP.NET image which means that once you've pulled the SDK image, you now essentially have the ASP.NET image as well. This provides substantial download savings when both images need to be pulled.

Ubuntu 20.04 (Focal)

ASP.NET App

	Before	After	Size Difference
1. Pull SDK image	268 MB	232 MB	-36 MB (-13%)
2. Pull ASP.NET image	64 MB	10 KB (manifest only)	-64 MB (-100%)

Net download savings: 100 MB (-30%)

Console App

	Before	After	Size Difference
1. Pull SDK image	268 MB	232 MB	-36 MB (-13%)
2. Pull Runtime image	56 MB	5 KB (manifest only)	-56 MB (-100%)

Net download savings: 92 MB (-28%)

Debian 10 (Buster)

ASP.NET App

	Before	After	Size Difference
1. Pull SDK image	280 MB	218 MB	-62 MB (-22%)
2. Pull ASP.NET image	84 MB	4 KB (manifest only)	-84 MB (-100%)

Net download savings: 146 MB (-40%)

Console App

	Before	After	Size Difference
1. Pull SDK image	280 MB	218 MB	-62 MB (-22%)
2. Pull Runtime image	76 MB	3 KB (manifest only)	-76 MB (-100%)

Net download savings: 138 MB (-39%)

Alpine 3.11

New packages were added to the Alpine SDK image to give it parity with the packages available in SDK images of other Linux distros, so the Alpine SDK image size ends up being slightly larger than before.

ASP.NET App

	Before	After	Size Difference
1. Pull SDK image	164 MB	172 MB	+8 MB (+5%)
2. Pull ASP.NET image	41 MB	4 KB (manifest only)	-41 MB (-100%)

Net download savings: 33 MB (-16%)

Console App

	Before	After	Size Difference
1. Pull SDK image	164 MB	172 MB	+8 MB (+5%)
2. Pull Runtime image	32 MB	4 KB (manifest only)	-32 MB (-100%)

Net download savings: 24 MB (-12%)

Windows Nano Server, version 1909

ASP.NET App

	Before	After	Size Difference
1. Pull SDK image	294 MB	294 MB	+0 MB (+0%)
2. Pull ASP.NET image	41 MB	3 KB (manifest only)	-41 MB (-100%)

Net download savings: 41 MB (-12%)

Console App

	Before	After	Size Difference
1. Pull SDK image	294 MB	294 MB	+0 MB (+0%)
2. Pull Runtime image	32 MB	2 KB (manifest only)	-32 MB (-100%)

Net download savings: 32 MB (-10%)