0

I have following setup:

1st machine. Docker server with Github integration.

2nd machine. Production with docker-agent, that starts up this way:

docker run -d 
    -e DRONE_SERVER=<ip:host>
    -e DRONE_SECRET=<secret> 
    -v /var/run/docker.sock:/var/run/docker.sock 
    --restart=always 
    --name=drone-agent
      drone/agent:0.8 agent

Repo with following .drone.yml:

pipeline:
  run:
    image: docker/compose:1.21.2
    commands:
      - cd <dir_with_docker-compose.yml>
      - docker-compose up -d <service_name>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    when:
      branch: [<branch_name>]

so when I trigger build with this .drone.yml, I get following output:

cd <dir_with_docker-compose.yml>
docker-compose up -d <service_name>
Starting docker_<service_name>_1 ...
Starting docker_<service_name>_1 ... error

ERROR: for docker_<service_name>_1  Cannot start service <service_name>: driver failed programming external connectivity on endpoint docker_<service_name>_1 
(<hash>): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use

ERROR: for <service_name>  Cannot start service <service_name>: driver failed programming external connectivity on endpoint docker_<service_name>_1
(<hash>): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use
Encountered errors while bringing up the project.

But if I insert docker ps or netstat -tulpn between cd <dir_with_docker-compose.yml> and docker-compose up -d <service_name> service starts up successfully.

Why does this happen?

IgorNikolaev
  • 1,053
  • 1
  • 12
  • 28

1 Answers1

0

The error message means something else is already using that port. Since the port in question appears to be 80, I would guess you have a webserver running. There are many ways to determine what programs are using a port (if it's a docker container, docker ps -a should show you), I would try one of those and shut down the offending process, then try starting your docker system again. If the error goes away, you have identified the culprit.

I don't know what exactly is in your docker images but it might also be that they are conflicting with each other. I believe Docker automatically assigns a random free port to images but only if the port is not specified. So if multiple containers in your assembly are trying to bind 80, that would be the issue. I would carefully look over your Dockerfiles and docker compose to see if anybody is using 80. You can explicitly ask Docker to bind a container to an arbitrary port with docker run -p 12345 CONTAINER_NAME. You do have -e DRONE_SERVER=<ip:host> in your run command but IIRC this sets an environment variable, so Docker might be disregarding the port you are specifying. So basically, for all run commands you are doing, include an argument like -p 12345 (use a different number for each container) and also change the ports in your docker-compose.yml. If that solves it, look for which containers were being run with -p 80 previously or where port 80 is specified in the docker compose.

Note that if you accidentally try to run the same Docker image twice, the new instance will of course conflict with the old one, as they would both be trying to use the same port (unless no port was specified, in which case Docker is able to resolve the conflict automatically). Because I see docker_<service_name>_1 (specifically the _1) I suspect that you had already done docker-compose run on this set up, forgot to remove it, and ran it again. Basically, you should close all containers related to this docker compose and remove them. A GUI like Portainer might help with this.

Wassinger
  • 347
  • 2
  • 16
  • drone-agent is communicating with remote drone-server. drone-server is listening on 9000 ports, and docker-agent is exposing port 3000. During the build I up only one container, so there should not be confilcts on ports between services of docker-compose. The miracle is, that `docker ps` or `netststat -tulpn` resolve the issue with port binding – IgorNikolaev Jul 11 '18 at 09:28
  • @IgorNikolaev Wait, simply printing some status fixes it? – Wassinger Jul 13 '18 at 21:09
  • @IgorNikolaev Well that's very strange, but congrats on getting it fixed. – Wassinger Jul 13 '18 at 21:15
  • well, I dont consider it fixed :) (this way) – IgorNikolaev Jul 13 '18 at 21:16