freeipa / freeipa-container

FreeIPA server in containers — images at https://quay.io/repository/freeipa/freeipa-server?tab=tags
https://quay.io/repository/freeipa/freeipa-server?tab=tags
Apache License 2.0
602 stars 258 forks source link

Docker Compose Example for Windows #578

Closed slominskir closed 8 months ago

slominskir commented 8 months ago

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:

abbra commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

abbra commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 https://github.com/freeipa/freeipa-container/pull/579#issuecomment-1889784434, I wonder if technically you even need systemd on the WSL Linux machine, if having things mounted wouldn't be enough.

slominskir commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

In https://github.com/freeipa/freeipa-container/pull/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.