Description
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 theaspnet
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:
For Ubuntu:
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.
Activity
jkotas commentedon Apr 8, 2020
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 commentedon Apr 8, 2020
After discussion, the POR is to include the following list of packages to help compensate for what is lost by not using buildpack-deps:
richlander commentedon Apr 8, 2020
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 commentedon Apr 28, 2020
For a description of the size benefits provided by these changes, see the comparison results at #1848 (comment).
mthalman commentedon May 7, 2020
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
Net download savings: 100 MB (-30%)
Console App
Net download savings: 92 MB (-28%)
Debian 10 (Buster)
ASP.NET App
Net download savings: 146 MB (-40%)
Console App
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
Net download savings: 33 MB (-16%)
Console App
Net download savings: 24 MB (-12%)
Windows Nano Server, version 1909
ASP.NET App
Net download savings: 41 MB (-12%)
Console App
Net download savings: 32 MB (-10%)
9 remaining items