Hacker News Reader

Hacker News

Comment by tomComb | Hacker News Reader

Full thread

tomComb

Why do actions use VM’s instead of containers? And yet codespaces use containers.

View on HN

Good question, I covered that in detail, including the issues with Docker In Docker.

https://actuated.dev/blog/blazing-fast-ci-with-microvms

https://docs.actuated.dev/faq/

sometimes you need to be able to run containers within your action, which can get complicated if you're already in a container

Is there an inherent complication here?

There are some! This is called "Docker in Docker", and you need to expose your docker socket to the container, which has some security implications.

It can be secured, as gitpod does, but as I understand it is a PITA.

> you need to expose your docker socket to the container

I always thought this was a hard limitation, but I deployed some self-hosted GHA runners in Kubernetes this week and to my surprise that setup came with an option to run the full docker daemon inside of a container - so apparently it is possible.

If you're running a full docker daemon, then you'll be running as a privileged container which is worse or about the same in terms of terms of poor security. Anyone's workload can compromise the host, and likely the cluster.

Rootless containers are a lot of work and do not support many scenarios that you're going to need.

MicroVMs are the same experience as GitHub, full system and Kernel, do what you will. Even launch a nested VM.

That's not what dind is. Rather, there is a docker daemon running inside the container, and the containers it hosts are nested inside its cgroup in the host kernel. The result is very close in feel to docker in its own VM. Furthermore nesting can be done inside one of the payload containers creating a turduckin. E.g. you can run k8s in a container, with k8s nodes implemented as nested containers and the cluster pods as doubly nested "pigeon" containers.

I haven't tried more than three levels but in theory more should work.

docker-in-docker doesn't run a docker daemon in the container, it just bind-mounts the host's docker socket inside the container, and the docker client talks to that. Any containers you launch from within docker-in-docker are siblings, not nested.

You are mistaken. From https://hub.docker.com/_/docker:

    What is Docker in Docker?
    Although running Docker inside Docker is generally not recommended, there are some legitimate use cases, such as development of Docker itself.
    ...If you are still convinced that you need Docker-in-Docker and not just access to a container's host Docker server, then read on.

This makes it pretty clear that it's a different copy of the docker daemon (which eg. allows you to test changes to docker itself) and specifically says it's different from "just access to a container's host Docker server".

Yikes, I stand corrected. Thanks for setting me straight.

It's hardly a PITA, I've done this a few times and as long as you use the dind docker image, it's easy to forget you're even using DIND.

I think it simply got easier over the years, as the various implementations overcame problems

Reply on news.ycombinator.com