Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
richlander opened this issue Apr 7, 2020 · 5 comments
Closed
Assignees
Labels
area-dockerfiles enhancement needs-announcement
Milestone

Comments

@richlander
Copy link
Member

@richlander richlander commented Apr 7, 2020

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:

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.

@mthalman mthalman self-assigned this Apr 7, 2020
@jkotas
Copy link
Member

@jkotas jkotas commented 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
Copy link
Member

@mthalman mthalman commented 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:

  • curl
  • git
  • wget

@richlander
Copy link
Member Author

@richlander richlander commented 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
Copy link
Member

@mthalman mthalman commented Apr 28, 2020

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

@mthalman
Copy link
Member

@mthalman mthalman commented 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

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%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-dockerfiles enhancement needs-announcement
Projects
None yet
Development

No branches or pull requests

4 participants