Services 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

.gitlab-ci.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

Relevant logs and/or screenshots

job log

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

Environment description

config.toml contents

[[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]

Debugging details

The service still starts and it's accessible, but not very discoverable.

This is because we are using a legacy feature --link when we set up the main build container instead of using a user defined network 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 !1569 (merged) & !803 (closed)

To use the feature

To use services for windows all you need to do is enable network per build