Skip to content

Remove redundant commands in Dockerfile#2744

Merged
drwetter merged 1 commit into3.2from
fix_imagebuild
Apr 23, 2025
Merged

Remove redundant commands in Dockerfile#2744
drwetter merged 1 commit into3.2from
fix_imagebuild

Conversation

@drwetter
Copy link
Copy Markdown
Collaborator

.. see #2420 (comment)

As suggested by @polarathene the not needed repos are more elegantly removed, commands for removing util-linux removal and zypper up were redudant and thus squashed.

First stage was build manually and it looked fine.

This fixes #2439 .

What is your pull request about?

  • Bug fix
  • Improvement
  • New feature (adds functionality)
  • Breaking change (bug fix, feature or improvement that would cause existing functionality to not work as expected)
  • Typo fix
  • Documentation update
  • Update of other files

If it's a code change please check the boxes which are applicable

  • For the main program: My edits contain no tabs, indentation is five spaces and any line endings do not contain any blank chars
  • I've read CONTRIBUTING.md and Coding_Convention.md
  • I have tested this fix or improvement against >=2 hosts and I couldn't spot a problem
  • I have tested this new feature against >=2 hosts which show this feature and >=2 host which does not (in order to avoid side effects) . I couldn't spot a problem
  • For the new feature I have made corresponding changes to the documentation and / or to help()
  • If it's a bigger change: I added myself to CREDITS.md (alphabetical order) and the change to CHANGELOG.md

.. see #2420 (comment)

As suggested by @polarathene the not needed repos are more elegantly removed,
commands for removing util-linux removal and zypper up were redudant and thus
squashed.

First stage was build manually and it looked fine.

This fixes #2439 .
@drwetter
Copy link
Copy Markdown
Collaborator Author

@polarathene : better?

@polarathene
Copy link
Copy Markdown
Contributor

polarathene commented Apr 23, 2025

Yeah looks like the advice I gave in 2023 👍

I personally have been sticking to Fedora as a base image of choice but I don't expect much to have changed with the Leap advice since then :)

Reference - Comparison to chisel for the builder stage

FWIW: Switching from openSUSE Leap to Canonical's chisel is over 20MB less in size for the builder stage (43MB vs 65MB):

EDIT: My mistake, I was looking at the openSUSE Leap builder stage first RUN layer for /root-fs that included other changes outside of that location, and the other two RUN don't help reduce the weight of that stage until the final stage COPY 😓 (where /root-fs becomes 46MB). Thus nevermind this feedback below, it only saves a few MB.

# This is only necessary until an eventual official chisel image is published:
FROM alpine AS chisel
ARG CHISEL_VERSION=1.1.0
ARG TARGETARCH
ARG CHISEL_RELEASE="https://github.com/canonical/chisel/releases/download/v${CHISEL_VERSION}/chisel_v${CHISEL_VERSION}_linux_${TARGETARCH}.tar.gz"
RUN wget -qO - "${CHISEL_RELEASE}" | tar -xz --no-same-owner -C /usr/local/bin chisel

# Instead of COPY from `/root-fs`, you can instead use `FROM builder`
# as Chisel installed packages directly to `/` of a scratch base.
FROM scratch AS builder
ARG XDG_CACHE_HOME=/cache
SHELL ["/nu", "-c"]
# These bind mounts are only needed temporarily to run `chisel`
RUN --mount=type=cache,target=${XDG_CACHE_HOME}/chisel,id="chisel-cache" \
    --mount=type=bind,from=chisel,source=/etc/ssl/certs/ca-certificates.crt,target=/etc/ssl/certs/ca-certificates.crt \
    --mount=type=bind,from=chisel,source=/usr/local/bin/chisel,target=/chisel \
    --mount=type=bind,from=ghcr.io/nushell/nushell,source=/usr/bin/nu,target=/nu \
    /chisel cut --release ubuntu-24.04 --root / \
      base-files_base bash_bins procps_bins grep_bins gawk_bins sed_bins coreutils_bins busybox_bins openssl_bins curl_bins
# If have another `RUN` that should execute via `/bin/sh` or `/bin/bash`, change `SHELL`:
SHELL ["/bin/bash", "-c"]

NOTES:

  • /usr/share/doc at the install root location will be under 1MB, but otherwise none of the other stuff needs to be cleaned up like with Leap builder stage.
  • If /etc/ssl/certs/ca-certificates.crt is required, then add this slice too: ca-certificates_data
    • EDIT: Actually this file doesn't seem to be present in the existing Leap image so should be a non-issue 😅
  • socat is missing a slice presently.
    • A slice for this package was almost contributed indirectly here, that would need to be upstreamed for a socat_bins slice to have parity with the OpenSUSE Leap base image.
    • socat is required for testing STARTTLS injection vulnerabilities (mail service ports only).
    • The socat package on Leap is only a 1MB weight difference.

Worth switching?:

  • It might be worth keeping an eye on chisel, once it gets some UX improvements (and that socat slice) you could have a simpler, smaller image build (EDIT: Actual image size reduction wasn't as big as I initially thought).
  • Compared to Fedora / openSUSE distros that offer more complex package managers (and a far broader selection of packages), chisel may not be as convenient / flexible. chisel is more of an optimization tool oriented towards minimal image builds akin to "distroless" images.

@drwetter drwetter merged commit 51a21cb into 3.2 Apr 23, 2025
2 checks passed
@drwetter drwetter deleted the fix_imagebuild branch April 23, 2025 14:13
@drwetter
Copy link
Copy Markdown
Collaborator Author

Thanks! And apologize to have this hung for so long.

Actually heard the first time about chisel. Thanks for the heads up. IIRC by the end of the year opensuse 15.6 should be EOL and after that it looks like there's a version 16 from which I don´t know what it'll be like. From what I've heard earlier the desktop version will be containerized -- whatever that means for this project.

@polarathene
Copy link
Copy Markdown
Contributor

Thanks! And apologize to have this hung for so long.

No worries! I know how it is finding the time to spare for such 😅

From what I've heard earlier the desktop version will be containerized -- whatever that means for this project.

SUSE has other base images specifically for containers (BCI - Base Container Image) at their own image registry.

It's been a while but I think the BCI images might differ a little with packages. So if there were an issue with your current base image in the future, the BCI images should be similar enough for you and I doubt they'd be dropping those.

If needed you could also switch to an alternative base image:

  • Fedora (more frequent release cadence + minimal lag in package versions, approx 6 months)
  • Debian (packages tend to lag behind more than openSUSE Leap, usually releases a major version every 2 years?)
  • Ubuntu + chisel (optimized for containers via chisel, very competitive in size, limited package selection, follows upstream Ubuntu releases every 6 months for package updates)
  • Alpine (musl instead of glibc, frequent releases + minimal lag in package versions, previously encountered some compatibility and performance issues)

Fedora was simple enough, with a similar approach to what openSUSE Leap is doing with --installroot. It is my preferred choice since I investigated in the original discussions / PR that contributed Leap to this project.

chisel seems great for minimal size, just needs more time to be friendlier to maintain / use.

@drwetter
Copy link
Copy Markdown
Collaborator Author

Short comment here..

Debian (packages tend to lag behind [..]

It's seems to me not relevant

@polarathene
Copy link
Copy Markdown
Contributor

I think we also considered Debian alongside Fedora and Leap. It wasn't as competitive at meeting the size goal though that was important for you.

A recent issue I had with Debian was Debian 12 was released around June 2023, and that came with SpamAssassin 4.0 package, which in March 2024 released 4.0.1, yet that did not arrive until Debian 12 in March 2025. Dates might be slightly off, but that was quite a long time for a bug fix to land.

Other software also similarly lagged behind in receiving updates with point releases to get fixes we wanted. We still use Debian as a base for now but that is one of my annoyances with it. You shouldn't have to wait 1-2 years for that, it's even longer for some packages when it comes to upgrading major/minor versions (Leap had a similar observation IIRC, but was a bit more inconsistent).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Review the recent change of the Dockerfile as suggested

2 participants