Unable to Use Compose with Windows Containers

[nerddtvg]

Description

When running nerdctl compose up, by default a --hostname parameter is passed to nerdctl run which is invalid on Windows OS.

https://github.com/containerd/nerdctl/blob/v2.0.2/pkg/containerutil/container_network_manager_windows.go#L50-L64

https://github.com/containerd/nerdctl/blob/v2.0.2/pkg/composer/serviceparser/serviceparser.go#L608-L614

Steps to reproduce the issue

1. Use a similar docker-compose.yaml file:

   services:
     github:
       image: mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019
       isolation: hyperv
       platform: windows/amd64
       restart: unless-stopped
       scale: 1
       # Hostname gets set and causes problem

2. nerdctl compose up

Describe the results you received and expected

We would expect the container to be started successfully.

> nerdctl compose up
time="2025-01-10T18:35:02Z" level=warning msg="Ignoring: service github: [Isolation]"
time="2025-01-10T18:35:02Z" level=info msg="Ensuring image mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019"
time="2025-01-10T18:35:02Z" level=info msg="Creating container runners-github-1"
time="2025-01-10T18:35:02Z" level=info msg="Running [C:\\Program Files\\nerdctl\\nerdctl.exe run --cidfile=C:\\Users\\user\\AppData\\Local\\Temp\\2\\compose-2714756652\\cid -l=com.docker.compose.project=runners -l=com.docker.compose.service=github -d --name=runners-github-1 --pull=never --net=runners_default --hostname=github --platform=windows/amd64 --restart=unless-stopped mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019]"
time="2025-01-10T18:35:03Z" level=fatal msg="failed to verify networking settings: the following networking arguments are not supported on Windows: [--hostname]"
time="2025-01-10T18:35:03Z" level=fatal msg="error while creating container runners-github-1: error while creating container runners-github-1: exit status 1"

What version of nerdctl are you using?

nerdctl version
time="2025-01-10T18:36:06Z" level=warning msg="unable to determine runc version: exec: \"runc\": executable file not found in %PATH%"
Client:
 Version:       v2.0.2
 OS/Arch:       windows/amd64
 Git commit:    1220ce7ec2701d485a9b1beeea63dae3da134fb5
 buildctl:
  Version:      v0.18.2
  GitCommit:    e4da654b1251f91e914fab18eba33743aefd7080

Server:
 containerd:
  Version:      v2.0.1
  GitCommit:    88aa2f531d6c2922003cc7929e51daf1c14caa0a
 runc:
  Version:

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

None

Host information

Windows Server 2019

Microsoft Windows [Version 10.0.17763.6659]

[apostasie]

Wondering if we should just null m.netOpts.Hostname and issue a warning instead of hard failing on it.

@AkihiroSuda wdyt?

[TinaMor]

@apostasie Tested this on Docker with the provided Compose file using WS22. I also tested with the hostname in the compose file and it worked.

#docker-compoase.yaml
services:
  github:
    image: mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2022
    isolation: hyperv
    platform: windows/amd64
    restart: unless-stopped
    scale: 1
    hostname: testCtr

> docker inspect 5418727e348d  --format "{{ .Config.Hostname }}"
testCtr

Digging around the compose-spec/compose-go and docker/compose, there doesn't appear to be any explicit handling that marks hostname as an invalid field for Windows.

Additional testing is required in nerdctl to determine the implications of explicitly setting the hostname value or allowing it to default to the service name, on Windows. This will help identify any potential restrictions from Compose or the underlying container runtime.

[apostasie]

@apostasie Tested this on Docker with the provided Compose file using WS22. I also tested with the hostname in the compose file and it worked.

#docker-compoase.yaml
services:
github:
image: mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2022
isolation: hyperv
platform: windows/amd64
restart: unless-stopped
scale: 1
hostname: testCtr

docker inspect 5418727e348d --format "{{ .Config.Hostname }}"
testCtr
Digging around the compose-spec/compose-go and docker/compose, there doesn't appear to be any explicit handling that marks hostname as an invalid field for Windows.

Additional testing is required in nerdctl to determine the implications of explicitly setting the hostname value or allowing it to default to the service name, on Windows. This will help identify any potential restrictions from Compose or the underlying container runtime.

Could it be a CNI plugins limitation on windows?

[TinaMor]

Perhaps. But there have been some developments in the CNI-plugins since the code was written. Will test this using both microsoft/windows-container-networking and containernetworking/plugins. Not sure if nerdctl supports containernetworking/plugins yet for Windows.

[TinaMor]

@apostasie Removed the --hostname from the nonZeroArgs. The error in #3808 is resolved, but then the hostname is not set correctly. Need to do further investigation on where the hostname value is set.

Draft PR: https://github.com/containerd/nerdctl/pull/3963/files

#docker-compose.yaml

services:
  github:
    image: mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2022
    isolation: hyperv
    platform: windows/amd64
    restart: unless-stopped
    scale: 1
    hostname: github-container  # Set a hostname
    command: ["ping", "-t", "localhost"]

Docker

```bash
> docker exec -it 24a4490b4af9 hostname

github-container
```

nerdctl

```bash
> nerdctl exec -it 2c539828bb76 hostname

3f372f051f8a
```

[apostasie]

Might want to try and see what happens on Windows when you do pass --hostname (to figure out where this restriction is coming from).

[TinaMor]

--hostname is not a valid flag for both nerdctl compose up and docker compose up

[apostasie]

--hostname is not a valid flag for both nerdctl compose up and docker compose up

Yep, so I guess the million dollar question is how do they set the hostname then...

[apostasie]

Actually, is docker run --hostname allowed (not compose)?