Upcoming breaking change: Drop reference to buildpack-deps for SDK images · Issue #1814 · dotnet/dotnet-docker (original) (raw)

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.

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.