Why is curl shutting down the docker container?

Question

Good day! I have a microservice that runs in a windower and a registry that stores the address of the microservices. I also have a script that runs when the container is turned on. The script gets its local ip and sends it to another server using curl. After executing the script, code 0 is returned and the container exits. How can you fix this problem?

#docker-compose realtime logs

nginx_1        | "code":"SUCCESSFUL_REQUEST" nginx_1 exited with code 0

My bash script

#!/bin/bash
address=$(hostname -i)
curl -X POST http://registry/service/register -H 'Content-Type: application/json' -d '{"name":"'"$MICROSERVICE_NAME"'","address":"'"$address"'"}'

The script runs fine and no problem, but unfortunately it breaks the container process. Is it possible to somehow intercept this code so that it does not shut down the container?

I would be grateful for any help or comment!

EDIT:

Dockerfile here the script is called after starting the container

FROM nginx:1.21.1-alpine
WORKDIR /var/www/
COPY ./script.sh /var/www/script.sh
RUN apk add --no-cache --upgrade bash && \
    apk add nano 

#launch script
CMD /var/www/script.sh

EDIT 2:

my docker-compose.yml

version: "3.9"

services:
    #database
    pgsql:
        hostname: pgsql
        build: ./pgsql
        ports:
            - 5432:5432/tcp
        volumes:
            - ./pgsql/data:/var/lib/postgresql/data
      

    #registry
    registry_fpm:
        build: ./fpm/registry
        depends_on:
            - pgsql
        volumes:
            - ./microservices/registry:/var/www/registry

    registry_nginx:
        hostname: registry
        build: ./nginx/registry
        depends_on:
            - registry_fpm
        volumes:
            - ./microservices/registry:/var/www/registry
            - ./nginx/registry/nginx.conf:/etc/nginx/nginx.conf

    
    #server
    nginx:
        build: ./nginx
        environment:
            MICROSERVICE_NAME: Microservice_1
        depends_on:
            - registry_nginx
        ports:
            - 80:80/tcp

Answer 1

the purpose of the registry is to store only the ip of all microservices. If you are familiar with microservices, then it is quite possible that you know that the registry is like the custodian of all addresses of microservices. The registry is used by other microservices to obtain microservice addresses so that microservices can communicate over http.

there is no need for these addresses as far as i can tell. the microservices can easily use each other's hostnames.

you already do this with your curl: the POST request goes to the server registry; and so on

docker compose may just be all the orchestration you require for you microservices.

---

regarding IPs and networking

if you prefer, for more isolation and consistency, you can configure in your compose.yaml

• custom networks virtualised network adapters; think of it as vLANs where the nodes are selected containers only.

  • for addn info on networking refer

• custom IP addresses for each container

• hostnames for each container

• links deprecated; do not use; information only

---

regarding heartbeat

keeping track of a heartbeat shouldn't be necessary.

but if you really need one, doing it from within the container is a no-no. a container should be only one running process. and creating a new record is redunduant as the docker daemon is already keeping track of all IP and state (and loads of others).

the function of registry (keeping track of lifecycle) is instead played by the docker daemon. try docker compose ps

however, you can configure the container to restart automatically when it fails using the restart tag

if you need a way to monitor these without the CLI, listening on the docker socket is the way to go.

you could make your own dashboard that taps into the Docker API whose endpoints are listed here. NB: the socket might need to be protected and if possible, ought to be mounted as read-only

but better solution would be a using an image that already does this. i cannot give you recommendations unfortunately; i have not used any.