-
Notifications
You must be signed in to change notification settings - Fork 610
Open
Labels
RequestRequest for image modification or featureRequest for image modification or feature
Description
Hi,
Currently all image variants are based on Alpine. It's totally fine, in most cases this is the best choice for the container OS. However, some cases require a different OS to be used while still having to use Docker in Docker. I was successful in running creating a Debian-based DinD image using most of the scripts found in this repo without many changes, so it definitely can be done. Hence my question: wouldn't it be a good idea to add an official Docker image based on an OS other than Alpine?
If there's a green light on that, you can count on me to update the templates and scripts and prepare a PR with needed changes.
M.
forzagreen, MatthewWalker, mboutet, mbanders, edwarddoh and 36 moreNazaroni, gabrieldemarmiesse and junaid-aliNazaroni, gabrieldemarmiesse and JeffersonCarvalh0
Metadata
Metadata
Assignees
Labels
RequestRequest for image modification or featureRequest for image modification or feature
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
tianon commentedon Apr 7, 2021
See #127, where this has been discussed previously 😅
mLupine commentedon Apr 7, 2021
Damn, I've tried searching for that before but GitHub's search engine is far from perfect and I thought that the subject hadn't been touched yet 😉
Nevertheless, my use case requires me to use a non-Alpine OS — I'm working on containerizing a self-hosted GitHub Actions runner which does not support Alpine (and by the looks of it, it's not going to in a foreseeable future) so I'm going to have to maintain a Debian image on my own. I just thought that I could share it so that others could benefit from it too.
If you ever reconsider the decision, feel free to ping me here and I'll be happy to chip in 😊
tianon commentedon Apr 7, 2021
Heh, on the side, I personally maintain 2-3 separate Debian-based Docker-in-Docker images for my own purposes, but each of them pulls from a different source of very specific Docker binaries (so Debian was chosen in one case because it's my personal preference and in the other because the binaries I'm consuming are in
.deb
files). 😄If what you're looking for is just a "Something Else"-based Docker-in-Docker image, here's the simplest method I can think of:
(Of course, the
FROM
and the dependencies installation could be swapped out for Ubuntu, etc etc etc as desired. 👍)rafaelgaspar commentedon Jul 28, 2021
Hi,
I think that with
dind-rootless
that becomes even more important, since it falls back tovfs
on alpine.Or maybe install
fuse-overlayfs
in alpine.mbanders commentedon Aug 4, 2021
@tianon Thanks for giving that example! This is what I've been looking for.
I'm comparing your Dockerfile example with the official 20.10 Dockerfile to see what you changed.
It looks like you don't do anything to the file
/etc/nsswitch.conf
. I don't totally understand what that step accomplished anyway.You also don't copy over
modprobe.sh
- is that simply not needed for anything?You also added the command
VOLUME /var/lib/docker
, can I ask why that was needed in this Debian based image but not in the official alpine based image?Edit: Looking more closely, it's clear I don't know the difference between the docker
20.10
vs20.10-dind
. I think what I'm looking for is20.10
based on debian/ubuntu.tianon commentedon Jun 16, 2022
That's an Alpine-Linux-plus-Go-ism (not needed for distributions which already use
nsswitch.conf
).This is
dind
vscli
-- if you want to run actual Docker-in-Docker, you'll want both.The
docker:20.10
image is intended to be CLI-only anddocker:20.10-dind
includes/enables the actual Engine for full Docker-in-Docker (not just Docker-CLI-inside-Docker-container-talking-to-Docker-Engine-on-the-host-via-bind-mounted-docker.sock
, which is not Docker-in-Docker).wt-asw commentedon Feb 22, 2023
would this method also work with docker compose?
tianon commentedon Feb 22, 2023
If you ask
docker compose
tobuild:
an image for you from aDockerfile
, yes 😅wt-asw commentedon Feb 23, 2023
Haha sorry I should have clarified the question: I'm trying to set up an ubuntu:22.04 container with the ability to run docker and docker compose inside the container.
My current file looks a bit like:
And then my docker compose file:
The ultimate goal is to be able to scale up self hosted Github Actions runners that can use docker and docker compose from within the containers.
Sorry for the nooby question, I'm quite new to all this. I tried doing
Because I think that is more elegant however I couldnt get docker compose to work this way.
tianon commentedon Feb 23, 2023
Ah, sorry, you're not even using this image (or its contents), so that's really a lot out of scope here. 😅
With the approach in #306 (comment), you "just" need to add the CLI plugins directory to the things you copy from the
docker
image and you'll havedocker compose
as well.wt-asw commentedon Feb 24, 2023
I see! Thank you! I have this working now. With dockerfile:
and then the compose file:
This is a far more elegant solution than my origional one. Thank you for your help 👍
tianon commentedon Jun 5, 2025
Given that the upstream builds targeting Debian are now generally more well-supported and recommended by upstream than the static artifacts, I've done some experiments in converting this repository to use Debian instead. From a size perspective, I knew there'd be a hit, but I wasn't prepared for just how heavy that hit is. Just the Git package goes from ~10M to ~100M (in large part thanks to a Perl dependency we can't remove without changes in Debian that we wouldn't have even a hope of seeing until Debian Forky at the earliest, ~2+ years from now). My feature-for-feature CLI image based on Debian Trixie is already bigger than the full-
dockerd
-dind Alpine-based image. 😭So, in order to consider this further, we'd have to choose between just eating the significant image size increase or moving
git
off to a separate variant again (just to get something that's even in a remotely sane ballpark, size-wise).Edit: WIP can be seen at docker-library:fb263e0...infosiftr:a3f348a#diff-fe911ce6b61170e5dd0a8e52e6d400f42013dc0b56f8baa6dc206f87bd685917 (didn't go any further than hack-hack-hack to get the CLI image into a state that can generate/build -- tons and tons of
TODO
in there, both listed and unlisted)