Docker Compose Example for Windows

[slominskir]

I'm looking for a Docker Compose example of launching freeipa-container that works on Windows. Here is an example that doesn't work:

ipa.yml

services:
  ipa:
    image: freeipa/freeipa-server:rocky-9-4.10.2
    hostname: ipa.example.com
    container_name: ipa
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
    environment:
      IPA_SERVER_INSTALL_OPTS: '-r EXAMPLE.COM -N -U'
      PASSWORD: password
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro      

Fails with:

C:\Users\RyanS\IdeaProjects\ipa>docker compose -f ipa.yml up
[+] Running 2/2
 ✔ Network ipa_default  Created                                                                                                                                                                                                                                          0.0s
 ✔ Container ipa        Created                                                                                                                                                                                                                                          0.1s
Attaching to ipa
ipa exited with code 123

I've tried various other configurations, but I haven't found the magic combination yet. I'm wondering if it may not work as I've seen discussions suggesting freeipa-container requires systemd and systemd in containers has historically been problematic and still may be in Docker Desktop on Windows. I'm not sure if the volume /sys/fs/cgroup is even doing what is expected as the volume may be mounting in Windows.

I can override the entrypoint to something like:

    entrypoint: 'sleep infinity'

And then the container starts fine and I can poke around with:

docker exec -it ipa bash

Not sure what to look for though. If I try running the original entrypoint I see:

[root@ipa /]# /usr/sbin/init
Couldn't find an alternative telinit implementation to spawn.

Environment:
Fully patched Windows 11 with latest Docker Desktop:

• Windows 11 Home 10.0.22631 Build 22631
• Docker Desktop 4.26.1 (131620)
• WSL version: 2.0.9.0

[abbra]

We do not test such configuration at all. However, did you enable systemd operations at all in wsl?
See https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/

[slominskir]

Thanks. After entering my WSL Ubuntu 20.04.6 LTS distro shell and adding systemd=true to the WSL distro config and restarting everything the freeipa-container now works. Would be useful to document all this in README for other Windows users.

Step 1: Stop Docker Desktop.
Step 2: Configure WSL distro and shut it down:

C:\Users\RyanS>bash
ryans@COMPUTER:/mnt/c/Users/RyanS$ echo -e "[boot]\nsystemd=true" | sudo tee -a /etc/wsl.conf > /dev/null
ryans@COMPUTER:/mnt/c/Users/RyanS$ exit
wsl --shutdown

Step 3: Start Docker Desktop
Step 4: Run docker compose up
where docker-compose.yml is:

services:
  ipa:
    image: freeipa/freeipa-server:rocky-9-4.10.2
    hostname: ipa.example.com
    container_name: ipa
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
    environment:
      IPA_SERVER_INSTALL_OPTS: '-r EXAMPLE.COM -N -U'
      PASSWORD: password
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro

Note: I guess the /sys/fs/cgroup mount is actually mounting into WSL distro, and not local windows filesystem?

[abbra]

Thank you for the update, @slominskir. May be you can submit a pull request that modifies the README?

[abbra]

Note: I guess the /sys/fs/cgroup mount is actually mounting into WSL distro, and not local windows filesystem?
correct. This is pulling the Linux host's cgroup view into the container.

[slominskir]

PR created. Odd README -> README.md setup! Means GitHub webpage doesn't preview README changes.

Historically I don't think I've ever used absolute volume bind mounts before now and relative ones work as you'd intuitively expect: it's relative to the project directory on the Windows filesystem (which perhaps is simply cloned into the WSL filesystem). Absolute paths starting in the WSL filesystem does make sense though. Thanks.

The contention between who's software has the privilege and responsibility to manage Linux PID 1 tasks in a container, systemd vs containerd, is interesting. Sounds like major reason Podman was created.

[adelton]

Note that containerd is rarely run in a container (unless you are doing something like container in container).

The systemd in the FreeIPA container image(s) is simply there, it is set in the ENTRYPOINT to be run by default, and without it the container will not reasonably function. The WSL systemd=true configuration has nothing to do with the systemd in the container.

The systemd you enabled in the WSL is likely only needed to establish the /sys/fs/cgroup mountpoint and as I commented in #579 (comment), I wonder if technically you even need systemd on the WSL Linux machine, if having things mounted wouldn't be enough.

[slominskir]

The example compose above didn't work until I added the magic Alexander suggested, which was setting systemd=true inside the wsl.conf of my WSL distro.

[adelton]

I trust you. I just tried to clarify what you've actually configured.

At the same time, the fact that this particular configuration caused the correct change of behaviour in your setup does not necessarily mean that this is the only or the best approach to do that in general.

[adelton]

In #579 we discussed what the recommendation should be and while systemd=true, it seems to configure cgroups v1 and the setup was a bit volatile.