You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SDK images do not have a consistent pattern of base images. The Ubuntu and Debian images are based on the buildpack-deps:scm images which provide a rich experience as they include curl, wget, ca-certificates, git, etc.
When Windows containers came around, the option to base the SDK images on buildpack-deps:scm was unavailable. As a result, the Windows SDK images are based on the base NanoServer OS images. On Windows curl is already included but SCM (e.g. git) is not. With 3.0 PS is included which provides other options for downloading content. IIRC no feedback has been provided in regards to not having git in the image.
When Alpine support was added, the buildpack-deps:scm option was again unavailable. The buildpack-deps repo maintainers believe the Alpine images are not intended for development scenarios (docker-library/buildpack-deps#51 (comment)). As a result the Alpine images were based on the runtime-deps images. The runtime-deps were chosen over the base Alpine image because of the need for the native dependencies.
I think the correct choice was made to utilize the buildpack-deps:scm images where available. For the images where buildpack-deps is not available, I think adjustments should be made. In these scenarios basing the SDK images on the runtime images would support maximize layer re-use. This will provide customers with a better experience. This is valuable in particular with the Windows images as they are larger when compared to the Linux images. The runtime specific layers on disk are ~70 MB and the aspnet layers add another ~20 MB.
The text was updated successfully, but these errors were encountered:
MichaelSimons
changed the title
Change the base image of the window and alpine sdk images to maximize layer sharing
Change the base image of the windows and alpine sdk images to maximize layer sharing
Oct 24, 2019
Crazy idea ... would could create a two-pronged story for the SDK:
"sdk1" (minimal -- depends on aspnet and not buildpack-deps; adds curl).
"sdk2" (status quo; we could add things like runtime-packs and old targeting packs to this)
We'd have to decide which one is the default. I see two options, and would propose the first one:
sdk and sdk-scm
sdk and sdk-slim
I like the first option because most people would get the value w/o changing anything. Only people that needed more functionality would need to change their FROM statement.
If we chose option 1, we would have to do it for both Debian and Ubuntu. If we chose option 2, we could choose to do it for just Debian. Option 1 would be a bit odd because of existing .NET versions. I would make this split for 5.0+ only.
mthalman
changed the title
Change the base image of the windows and alpine sdk images to maximize layer sharing
Change the base image of the SDK images to maximize layer sharing
Apr 6, 2020
mthalman
changed the title
Change the base image of the SDK images to maximize layer sharing
Change the base image of the Windows and Alpine SDK images to maximize layer sharing
Apr 7, 2020
The SDK images do not have a consistent pattern of base images. The Ubuntu and Debian images are based on the buildpack-deps:scm images which provide a rich experience as they include curl, wget, ca-certificates, git, etc.
When Windows containers came around, the option to base the SDK images on buildpack-deps:scm was unavailable. As a result, the Windows SDK images are based on the base NanoServer OS images. On Windows curl is already included but SCM (e.g. git) is not. With 3.0 PS is included which provides other options for downloading content. IIRC no feedback has been provided in regards to not having git in the image.
When Alpine support was added, the buildpack-deps:scm option was again unavailable. The buildpack-deps repo maintainers believe the Alpine images are not intended for development scenarios (docker-library/buildpack-deps#51 (comment)). As a result the Alpine images were based on the runtime-deps images. The runtime-deps were chosen over the base Alpine image because of the need for the native dependencies.
I think the correct choice was made to utilize the buildpack-deps:scm images where available. For the images where buildpack-deps is not available, I think adjustments should be made. In these scenarios basing the SDK images on the runtime images would support maximize layer re-use. This will provide customers with a better experience. This is valuable in particular with the Windows images as they are larger when compared to the Linux images. The runtime specific layers on disk are ~70 MB and the aspnet layers add another ~20 MB.
The text was updated successfully, but these errors were encountered: