6

I'm having an issue with my travis-ci before_script while trying to connect to my docker postgres container: Error starting userland proxy: listen tcp 0.0.0.0:5432: bind: address already in use

I've seen this problem raised but never fully addressed around SO and github issues, and i'm not clear whether it is specific to docker or travis. One linked issue (below) works around it by using 5433 as the host postgres address but i'd like to know for sure what is going on before i jump into something.

my travis.yml: sudo: required services: - docker env: DOCKER_COMPOSE_VERSION: 1.7.1 DOCKER_VERSION: 1.11.1-0~trusty

before_install:
  # list docker-engine versions
  - apt-cache madison docker-engine
  # upgrade docker-engine to specific version
  - sudo apt-get -o Dpkg::Options::="--force-confnew" install -y docker-engine=${DOCKER_VERSION}
  # upgrade docker-compose
  - sudo rm /usr/local/bin/docker-compose
  - curl -L https://github.com/docker/compose/releases/download/${DOCKER_COMPOSE_VERSION}/docker-compose-`uname -s`-`uname -m` > docker-compose
  - chmod +x docker-compose
  - sudo mv docker-compose /usr/local/bin
before_script:
  - echo "Before Script:"
  - docker-compose -f docker-compose.ci.yml build
  - docker-compose -f docker-compose.ci.yml run app rake db:setup
  - docker-compose -f docker-compose.ci.yml run app /bin/sh

script:
  - echo "Running Specs:"
  - rake spec

my docker-compose.yml for ci:

postgres:
  image: postgres:9.4.5
  environment:
    POSTGRES_USER: web
    POSTGRES_PASSWORD: yourpassword
  expose:
    - '5432' # added this as an attempt to open the port
  ports:
    - '5432:5432'
  volumes:
    - web-postgres:/var/lib/postgresql/data

redis:
  image: redis:3.0.5
  ports:
    - '6379:6379'
  volumes:
    - web-redis:/var/lib/redis/data

web:
  build: .
  links:
    - postgres
    - redis
  volumes:
    - ./code:/app
  ports:
    - '8000:8000'
  # env_file: # setting these directly in the environment 
  #   - .docker.env # (they work fine locally)

sidekiq:
  build: .
  command: bundle exec sidekiq -C code/config/sidekiq.yml
  links:
    - postgres
    - redis
  volumes:
    - ./code:/app

Docker & Postgres: Failed to bind tcp 0.0.0.0:5432 address already in use

How to get Docker host IP on Travis CI?

Community
  • 1
  • 1
erikdstock
  • 1,117
  • 9
  • 16

2 Answers2

1

It seems that Postgres service is enabled by default in Travis CI.

So you could :

  1. Try to disable the Postgres service in your Travis config. See How to stop services on Travis CI running by default?. See also https://docs.travis-ci.com/user/database-setup/#PostgreSQL .

Or

  1. Map your postgres container to another host port (!= 5432). Like -p 5455:5432.

It could also be useful to check if the service is already running : Check If a Particular Service Is Running on Ubuntu

Guillaume Husta
  • 4,049
  • 33
  • 40
-1

Do you use Travis' Postgres?

services: - postgresql

Would be easier if you provide travis.yml

  • but to answer your question, no. i double checked that- assume that my container will launch its own postgres. – erikdstock Jul 15 '16 at 14:37
  • If I understood correctly you can just remove `ports: - '5432:5432'` Because you don't use Postgres from travis (only from docker itself) – Oleksandr Kurakin Jul 15 '16 at 14:44
  • @erikdstock, I think I found a problem: From [documentation](https://docs.docker.com/compose/reference/run/): Commands you use with run start in new containers with the same configuration as defined by the service’ configuration. This means the container has the same volumes, links, as defined in the configuration file. There two differences though. – Oleksandr Kurakin Jul 15 '16 at 14:50
  • Yes, but i'm passing the compose yml file to override those. also below in that document it says 'If you start a service configured with links, the run command first checks to see if the linked service is running and starts the service if it is stopped. Once all the linked services are running, the run executes the command you passed it.' - so i'm actually setting up the DB from my main service and that is where the connection is failing. These commands all work as expected locally. – erikdstock Jul 15 '16 at 15:09