[GH-ISSUE #37] Unify apt packages across container images #2

New issue

Closed

opened 2026-03-04 01:33:51 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 01:33:51 +03:00

Owner

Originally created by @rgov on GitHub (Jul 28, 2022).
Original GitHub issue: https://github.com/spr-networks/super/issues/37

Many of the Dockerfiles declare very similar sets of apt packages:

RUN apt-get install -y iptables nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates
RUN apt-get install -y iptables nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates curl
RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates
RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates curl
RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates curl hostapd systemd jq jc iw
RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates git curl
RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates git curl clang
RUN apt-get install -y --no-install-recommends ca-certificates nftables iproute2 netcat inetutils-ping net-tools nano
RUN apt-get install -y --no-install-recommends nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates git curl
RUN apt-get install -y --no-install-recommends nftables iproute2 netcat inetutils-ping net-tools nano wireguard-tools

This is going to take up a lot of space and increase build time generating many different layers that are similar to one another. Consider factoring out the common group and installing them all at once as the first step.

There is also an official note on best practices when using apt-get. The recommendation is to make all package installations follow this pattern (with alphabetized packages for better diffs):

RUN apt-get update && apt-get install -y \
    aufs-tools \
    automake \
    build-essential \
    curl \
    dpkg-sig \
    libcap-dev \
    libsqlite3-dev \
    mercurial \
    reprepro \
    ruby1.9.1 \
    ruby1.9.1-dev \
    s3cmd=1.1.* \
 && rm -rf /var/lib/apt/lists/*

You may end up running multiple installations in one Dockerfile (e.g., common packages vs container-specific packages).

Originally created by @rgov on GitHub (Jul 28, 2022). Original GitHub issue: https://github.com/spr-networks/super/issues/37 Many of the Dockerfiles declare very similar sets of apt packages: ``` RUN apt-get install -y iptables nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates RUN apt-get install -y iptables nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates curl RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates curl RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates curl hostapd systemd jq jc iw RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates git curl RUN apt-get install -y nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates git curl clang RUN apt-get install -y --no-install-recommends ca-certificates nftables iproute2 netcat inetutils-ping net-tools nano RUN apt-get install -y --no-install-recommends nftables iproute2 netcat inetutils-ping net-tools nano ca-certificates git curl RUN apt-get install -y --no-install-recommends nftables iproute2 netcat inetutils-ping net-tools nano wireguard-tools ``` This is going to take up a lot of space and increase build time generating many different layers that are similar to one another. Consider factoring out the common group and installing them all at once as the first step. There is also [an official note on best practices](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#apt-get) when using `apt-get`. The recommendation is to make all package installations follow this pattern (with alphabetized packages for better diffs): ``` RUN apt-get update && apt-get install -y \ aufs-tools \ automake \ build-essential \ curl \ dpkg-sig \ libcap-dev \ libsqlite3-dev \ mercurial \ reprepro \ ruby1.9.1 \ ruby1.9.1-dev \ s3cmd=1.1.* \ && rm -rf /var/lib/apt/lists/* ``` You may end up running multiple installations in one Dockerfile (e.g., common packages vs container-specific packages).

kerem closed this issue

2026-03-04 01:34:00 +03:00

kerem commented

2026-03-04 01:34:03 +03:00

Author

Owner

@rgov commented on GitHub (Jul 28, 2022):

If you need a set of packages in both the builder and the final image, you can avoid repetition like so:

FROM ubuntu:22.04 as common
RUN apt update && ...

FROM common as builder
...

FROM common
...

@rgov commented on GitHub (Jul 28, 2022): If you need a set of packages in both the builder and the final image, you can avoid repetition like so: ```dockerfile FROM ubuntu:22.04 as common RUN apt update && ... FROM common as builder ... FROM common ... ```

kerem commented

2026-03-04 01:34:03 +03:00

Author

Owner

@rgov commented on GitHub (Jul 28, 2022):

Quick glance at the apt-get update layers suggests each one takes 35.2 MB * 11 images = 387.2 MB of unnecessary list files.

Also as the link above shows, if apt-get update is on its own layer, the package lists will get cached separately and this will be an annoyance to invalidate if you ever want to pull newer packages.

@rgov commented on GitHub (Jul 28, 2022): Quick glance at the `apt-get update` layers suggests each one takes 35.2 MB * 11 images = 387.2 MB of unnecessary list files. Also as the link above shows, if `apt-get update` is on its own layer, the package lists will get cached separately and this will be an annoyance to invalidate if you ever want to pull newer packages.

kerem commented

2026-03-04 01:34:03 +03:00

Author

Owner

@lts-rad commented on GitHub (Jul 29, 2022):

will take a look at this much later. my bigger question is if this actually saves us considerable space, for the headaches it might cause in the future as a result of trying to keep everything in sync.

clang, hostapd, wireguard-tools we do not want across all containers. hostapd in particular could interfere with the wifid container which builds its own.

@lts-rad commented on GitHub (Jul 29, 2022): will take a look at this much later. my bigger question is if this actually saves us considerable space, for the headaches it might cause in the future as a result of trying to keep everything in sync. clang, hostapd, wireguard-tools we do not want across all containers. hostapd in particular could interfere with the wifid container which builds its own.

kerem commented

2026-03-04 01:34:04 +03:00

Author

Owner

@lts-rad commented on GitHub (Feb 9, 2023):

This has been merged

@lts-rad commented on GitHub (Feb 9, 2023): This has been merged

kerem referenced this issue

2026-03-04 01:35:50 +03:00

[PR #2] [CLOSED] [build] Add github action to build arm64 containers #237