I have been using docker-compose up --build -d command for a while now and I have never had an issue with the build process and time. Today, when I ran docker-compose up --build -d, there is a very long delay (~ 1 minute) before it starts executing the build process. Below is the output for building my services:
Build authentication binary...
cd ../authentication-service && env GOOS=linux CGO_ENABLED=0 go build -o authApp ./cmd/api
Build api gateway binary...
cd ../api-gateway && env GOOS=linux CGO_ENABLED=0 go build -o apiGateway .
docker-compose down
[+] Running 4/3
✔ Container project-authentication-service-1 Removed 0.0s
✔ Container project-api-gateway-1 Removed 0.1s
✔ Container project-postgres-1 Removed 0.0s
✔ Network project_default Removed 0.1s
Building and starting docker images...
docker-compose up --build -d
[+] Building 0.0s (0/0) docker:desktop-linux
The build process hangs at
[+] Building 0.0s (0/0) docker:desktop-linux before starting to load the Dockerfile and run the containers. This is rather strange and I have not faced this before. It will eventually run the containers but the part where it hangs is new to me.
Below is the finished output:
Build authentication binary...
cd ../authentication-service && env GOOS=linux CGO_ENABLED=0 go build -o authApp ./cmd/api
Build api gateway binary...
cd ../api-gateway && env GOOS=linux CGO_ENABLED=0 go build -o apiGateway .
docker-compose down
Building and starting docker images...
docker-compose up --build -d
[+] Building 63.5s (14/14) FINISHED docker:desktop-linux
=> [api-gateway internal] load build definition from Dockerfile 10.0s
=> => transferring dockerfile: 118B 10.0s
=> [api-gateway internal] load .dockerignore 10.0s
=> => transferring context: 70B 10.0s
=> [authentication-service internal] load .dockerignore 10.0s
=> => transferring context: 2B 10.0s
=> [authentication-service internal] load build definition from Dockerfile 10.0s
=> => transferring dockerfile: 112B 10.0s
=> [api-gateway internal] load metadata for docker.io/library/alpine:latest 23.3s
=> [api-gateway auth] library/alpine:pull token for registry-1.docker.io 0.0s
=> [authentication-service 1/3] FROM docker.io/library/alpine:latest@sha256:51b67269f354137895d43f3b3d810bfacd3945438e94dc5ac55fdac340352f48 0.0s
=> [api-gateway internal] load build context 10.2s
=> => transferring context: 11.65MB 10.2s
=> [authentication-service internal] load build context 10.2s
=> => transferring context: 15.02MB 10.2s
=> CACHED [authentication-service 2/3] RUN mkdir /app 0.0s
=> CACHED [api-gateway 3/3] COPY apiGateway /app 0.0s
=> [api-gateway] exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:171f01a47b5af04235e6dfbee9ac3f00ce1c50c7e6ac89699745aa1ddc78413b 0.0s
=> => naming to docker.io/library/project-api-gateway 0.0s
=> CACHED [authentication-service 3/3] COPY authApp /app 0.0s
=> [authentication-service] exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:766dfb2e64100c9d4f1c5acaefef52f721bc7e1b4e57021f34be12907f0e3f4b 0.0s
=> => naming to docker.io/library/project-authentication-service 0.0s
[+] Running 4/4
✔ Network project_default Created 0.1s
✔ Container project-postgres-1 Started 0.3s
✔ Container project-api-gateway-1 Started 0.3s
✔ Container project-authentication-service-1 Created
docker-compose.yml file
version: '3'
services:
api-gateway:
build:
context: ./../api-gateway
dockerfile: ./../api-gateway/Dockerfile
restart: always
ports:
- '80:80'
authentication-service:
build:
context: ./../authentication-service
dockerfile: ./../authentication-service/Dockerfile
depends_on:
postgres:
condition: service_healthy
restart: always
ports:
- '8001:8001'
deploy:
mode: replicated
replicas: 1
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: password
POSTGRES_HOST: postgres
POSTGRES_PORT: '5432'
POSTGRES_DB: imsdb
postgres:
image: 'postgres:14.2'
ports:
- '5432:5432'
restart: always
deploy:
mode: replicated
replicas: 1
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: password
POSTGRES_DB: imsdb
volumes:
# using volumes instead of bind mounts
- postgres:/var/lib/postgresql/data
- ./schema.sql:/docker-entrypoint-initdb.d/schema.sql
healthcheck:
test: pg_isready -U "$$POSTGRES_USER" -d "$$POSTGRES_DB"
interval: 10s
timeout: 2s
volumes:
postgres:
Makefile
I was running make up_build that runs docker-compose down and then docker-compose up --build -d and this is the part where is hangs on the build process for around 1 minute.
AUTHENTICATION_BINARY=authApp
APIGATEWAY_BINARY=apiGateway
up_build: build_authentication build_api_gateway
docker-compose down
@echo "Building and starting docker images..."
docker-compose up --build -d
@echo "Docker images built and started!"
build_authentication:
@echo "Build authentication binary..."
cd ../authentication-service && env GOOS=linux CGO_ENABLED=0 go build -o ${AUTHENTICATION_BINARY} ./cmd/api
build_api_gateway:
@echo "Build api gateway binary..."
cd ../api-gateway && env GOOS=linux CGO_ENABLED=0 go build -o ${APIGATEWAY_BINARY} .
down:
docker-compose down
I tried uninstalling Docker Desktop in Applications (Mac M1) and reinstalling it but the problem still persists.
Could it be a process that’s taking up the CPU when running Docker? Or the storage for volumes is full? I ran docker system prune too but it’s still the same. Running a simple docker-compose up also takes a long time.
Adding DOCKER_BUILDKIT=0
docker-compose up --build -d
Sending build context to Docker daemon 6.308MB
Step 1/5 : FROM alpine:latest
---> 1dc785547989
Step 2/5 : RUN mkdir /app
---> Using cache
---> 3b744c7dca2a
Step 3/5 : COPY apiGateway /app
---> Using cache
---> 3d3bcba5ef89
Step 4/5 : CMD ["/app/apiGateway"]
---> Using cache
---> b6fcdff5430f
Step 5/5 : LABEL com.docker.compose.image.builder=classic
---> Using cache
---> 8f67e117f601
Successfully built 8f67e117f601
Successfully tagged project-api-gateway:latest
Sending build context to Docker daemon 6.972MB
Step 1/5 : FROM alpine:latest
---> 1dc785547989
Step 2/5 : RUN mkdir /app
---> Using cache
---> 3b744c7dca2a
Step 3/5 : COPY authApp /app
---> Using cache
---> bbed0acb97b4
Step 4/5 : CMD ["/app/authApp"]
---> Using cache
---> 75a7a12ab1ce
Step 5/5 : LABEL com.docker.compose.image.builder=classic
---> Using cache
---> 6469ad6fb3a0
Successfully built 6469ad6fb3a0
Successfully tagged project-authentication-service:latest
[+] Running 4/4
✔ Network project_default Created 0.0s
✔ Container project-api-gateway-1 Started 0.0s
✔ Container project-postgres-1 Started 0.0s
✔ Container project-authentication-service-1 Created
Update
Commented out volumes postgres:/var/lib/postgresql/data in docker-compose and it worked. Temporary fix though.
2
Answers
You have
For one of your services. Your postgres is slow to startup from the persisted volume you have declared:
The state of that volume delays your postgres startup most likely (the change you made effectively deleted your postgres data from a container standpoint).
You should look at the startup logging for the
postgrescontainer, it should tell you what it’s up to during startup. My best bet is that it is doing some sort of recovery due to forceful shutdown. Might be because of therestart: alwayswhich in my experience doesn’t work the way you might expect, keeping the container lingering (and at some point, probably killed).Make sure that postgres actually shuts down cleanly when you stop docker compose, make sure it has time to stop (I think default is like 10s before docker sends a SIGKILL signal). You can adjust that per container with the
stop_grace_period: 30ssetting in your compose file.(Answer posted on behalf of the question author in order to move it to the answer space).
I realized that my Kubernetes Cluster was attempting to start on my Docker Desktop, causing an issue because my Minikube cluster was not running. This led to an extended timeout during the startup of my Kubernetes Cluster, consuming all the Docker Desktop resources.