gitlab-runner issueshttps://gitlab.com/gitlab-org/gitlab-runner/-/issues2023-03-31T17:50:35Zhttps://gitlab.com/gitlab-org/gitlab-runner/-/issues/4186Services not working on Windows Docker Containers2023-03-31T17:50:35ZSteve Xuerebsxuereb@gitlab.comServices not working on Windows Docker Containers## Summary
Using Windows Docker executor when you define a service with an alias, the alias does not take in effect.
## Steps to reproduce
<!--
How one can reproduce the issue, such as the job definition, git repository structure.
-->...## Summary
Using Windows Docker executor when you define a service with an alias, the alias does not take in effect.
## Steps to reproduce
<!--
How one can reproduce the issue, such as the job definition, git repository structure.
-->
<!--
Please add the definition of the job from `.gitlab-ci.yml` that is failing
inside of the code blocks (```) below.
-->
<details>
<summary> .gitlab-ci.yml </summary>
```yml
web-request:
stage: service
services:
- name: mcr.microsoft.com/dotnet/core/samples:aspnetapp
alias: web
before_script: []
script:
- Invoke-WebRequest http://web:80 -UseBasicParsing
```
</details>
## Relevant logs and/or screenshots
<details>
<summary> job log </summary>
```sh
Running with gitlab-runner 11.11.0~beta.1374.gdb2eb9aa (db2eb9aa)
on windows-docker-2019 vGvfck1g
Using Docker executor with image mcr.microsoft.com/windows/servercore:1809 ...
Starting service mcr.microsoft.com/dotnet/core/samples:aspnetapp ...
Pulling docker image mcr.microsoft.com/dotnet/core/samples:aspnetapp ...
Using docker image sha256:406d5117a277bd03faaef62c0f7b8b181853729adf524a98cdec70f88e01d78f for mcr.microsoft.com/dotnet/core/samples:aspnetapp ...
WARNING: Possibly zombie container runner-vGvfck1g-project-28-concurrent-0-mcr.microsoft.com__dotnet__core__samples-0 is disconnected from network nat
Waiting for services to be up and running...
*** WARNING: Service runner-vGvfck1g-project-28-concurrent-0-mcr.microsoft.com__dotnet__core__samples-0 probably didn't start properly.
Health check error:
ContainerStart: Error response from daemon: container bc97277ebe4c8d8eafc20c39ac1faa3753b90a0a5e9eeb786b5f353aaa67c042 encountered an error during CreateProcess: failure in a Windows system call: The system cannot find the file specified. (0x2) extra info: {"CommandLine":"\"sleep 3600\"","User":"ContainerAdministrator","WorkingDirectory":"C:\\","CreateStdInPipe":true,"CreateStdOutPipe":true,"CreateStdErrPipe":true,"ConsoleSize":[0,0]} (executor_docker.go:1356:3s)
Service container logs:
2019-04-23T15:25:06.471648600Z Hosting environment: Production
2019-04-23T15:25:06.471648600Z Content root path: C:\app
2019-04-23T15:25:06.471648600Z Now listening on: http://[::]:80
2019-04-23T15:25:06.471648600Z Application started. Press Ctrl+C to shut down.
*********
Pulling docker image mcr.microsoft.com/windows/servercore:1809 ...
Using docker image sha256:29a2c2cb7e4d89c2dc7728e1d675414857b0fe2b009287fa737a39dac99a60d4 for mcr.microsoft.com/windows/servercore:1809 ...
Running on RUNNER-VGVFCK1G via
vagrant-2019...
Reinitialized existing Git repository in C:/builds/root/ci-scratch-pad/.git/
Fetching changes...
Checking out 7d5f4852 as windows-docker-executor...
git-lfs/2.7.1 (GitHub; windows amd64; go 1.11.5; git 6b7fb6e3)
Version: 11.9.0~beta.1139.g08121fc8
Git revision: 08121fc8
Git branch: 3755-helper-image-for-windows-container-execution-publish-windows-images
GO version: go1.12
Built: 2019-03-04T16:34:20+0000
OS/Arch: windows/amd64
$ sleep 30
$ Invoke-WebRequest http://web:80 -UseBasicParsing
Invoke-WebRequest : The remote name could not be resolved: 'web'
At line:1 char:1
+ Invoke-WebRequest http://web:80 -UseBasicParsing
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:Htt
pWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe
ll.Commands.InvokeWebRequestCommand
Version: 11.9.0~beta.1139.g08121fc8
Git revision: 08121fc8
Git branch: 3755-helper-image-for-windows-container-execution-publish-windows-images
GO version: go1.12
Built: 2019-03-04T16:34:20+0000
OS/Arch: windows/amd64
```
</details>
## Environment description
<details>
<summary> config.toml contents </summary>
```toml
[[runners]]
name = "windows-docker-2019"
url = "http://192.168.1.79:3000/"
token = "vGvfck1gu-S8EZNfx8iK"
executor = "docker-windows"
[runners.docker]
tls_verify = false
image = "alpine:3.9"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
shm_size = 0
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
```
</details>
## Debugging details
The service still starts and it's accessible, but not very discoverable.
This is because we are using a legacy feature [`--link`](https://docs.docker.com/network/links/) when we [set up](https://gitlab.com/gitlab-org/gitlab-runner/blob/02d9f1039c6523f96ad2d548d37cc0050145ff63/executors/docker/executor_docker.go#L910) the main build container instead of using a [user defined network](https://docs.docker.com/network/bridge/##differences-between-user-defined-bridges-and-the-default-bridge) this means that the only way to access the service is by accessing it directly with the name of the container, which is automatically generated and no way the user can know the name.
Also, notice that this effects our health check checking since we can not access the container properly, but it might be also a separate issue.
## Proposal
Using user-defined networks and then setting up aliases seems to be the way forward we already have some ~"Community contribution" such as https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1569 & https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/803
## To use the feature
To use services for windows all you need to do is [enable network per build](https://docs.gitlab.com/runner/executors/docker.html#network-per-build)12.9Steve Xuerebsxuereb@gitlab.comSteve Xuerebsxuereb@gitlab.com