Docker compose read connection reset by peer error on pipeline [Enterprise Customer]

Deployment
1

I’m running a docker compose instancein a pipeline, I’m getting this error when the tests on the pipleine are making use of mycontainer’s API.

panic: Get "http://localhost:8080/api/admin/folder": read tcp 127.0.0.1:60066->127.0.0.1:8080: read: connection reset by peer [recovered]

panic: Get "http://localhost:8080/api/admin/folder": read tcp 127.0.0.1:60066->127.0.0.1:8080: read: connection reset by peer

This is my docker copose file:

version: "3"

volumes:
  postgres_vol:
    driver: local
    driver_opts:
      o: size=1000m
      device: tmpfs
      type: tmpfs

networks:
  mynetwork:
    driver: bridge

services:
  postgres:
    image: postgres:14
    container_name: postgres
    restart: always
    environment:
      - POSTGRES_USER=xxx
      - POSTGRES_PASSWORD=xxx
      - POSTGRES_DB=newdatabase
    volumes:
      #- ./postgres-init-db.sql:/docker-entrypoint-initdb.d/postgres-init-db.sql
      - "postgres_vol:/var/lib/postgresql/data"
    ports:
      - 5432:5432
    networks:
      - mynetwork

  mycontainer:
    image: myprivaterepo/mycontainer-image:1.0.0
    container_name: mycontainer
    restart: always
    environment:
      - DATABASE_HOST=postgres
      - DATABASE_PORT=5432
      - DATABASE_NAME=newdatabase
      - DATABASE_USERNAME=xxx
      - DATABASE_PASSWORD=xxx
      - DATABASE_SSL=false
    depends_on:
      - postgres
    ports:
      - 8080:8080
    networks:
      - mynetwork

mycontainer is listening on port 8080 and locally everything works fine.

However, when I run the pipeline which is initiating this docker compose is where I’m getting the error.

Basically, I’m running some tests in the pipeline that make use of mycontainer API (http://localhost:8080/api/admin/folder).

If I run the docker compose locally and I reproduce the steps followed on my pipeline to make use of the API everything is working fine. I can comunicate locally with both containers through localhost.

Also, I tried using healthchecks on the containers and 127.0.0.1:8080:8080 on mycontainer & 127.0.0.1:5432:5432 in postgres (including 0.0.0.0:8080:8080 & 0.0.0.0:5342:5432 just in case).

Any idea about this? This has put deployment to stop. Do you know anything about this @Montana?

2

Hi @Northskool,

Make sure that you are not caching anything, meaning the code that’s interacting with the API.

You didn’t mention this in the OP, but if this is the case make sure you remove it. This should resolve the issue.

So for example, move Dockerfile and let’s say you have a file called hello into separate directories and build a second version of the image (without relying on cache from the last build). Use -f to point to the Dockerfile and specify the directory of the build context:

mkdir -p dockerfiles context
mv Dockerfile dockerfiles && mv hello context
docker build --no-cache -t yourapp

Cheers,
Montana Mendy

2 Likes
3

Thanks for the quick response @montana, this worked perfectly here in this emergency situation this halted all builds looks we are building again

4

This might be worth adding a TIP on our Travis CI documentation. I’ll talk to our documentation person.