Unable to connect to service in Docker container despite successfull deploy

GitLab CI/CD
, ,
1

I have a simple service written in Python which should be build, deployed and work in a Docker container. Configs for this project are as follows:

.gilab-ci.yml

default:
  image: docker:24.0.5
  services:
    - docker:24.0.5-dind

variables:
  DOCKER_TLS_CERTDIR: "/certs"
#  DOCKER_HOST: tcp://docker:2375
  DOCKER_DRIVER: overlay2

stages:
  - build
  - deploy

before_script:
  - export IMAGE=$CI_REGISTRY/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME:latest
  - apk add --no-cache openssh-client bash
  - docker login -u $CI_REGISTRY_USER -p $CI_JOB_TOKEN $CI_REGISTRY

build:
  stage: build
  script:
    - docker compose -f deploy/docker/trans_service.yml build
    - docker compose -f deploy/docker/trans_service.yml push

deploy:
  stage: deploy
  dependencies:
    - build
  script:
    - docker pull $IMAGE
    - docker compose -f deploy/docker/trans_service.yml up -d

deploy/docker/Dockerfile

FROM python:3.10

LABEL application="attacut_tranliteration"
RUN useradd -ms /bin/bash transservice

WORKDIR /app
COPY ./deploy/ /app/deploy/

RUN apt update \
    && apt install -y build-essential zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libsasl2-dev libssl-dev \
    libgeos-dev libaio1 libaio-dev libldap2-dev libsqlite3-dev libsqlite3-mod-spatialite libreadline-dev \
    libffi-dev libbz2-dev binutils libproj-dev
RUN cp /usr/bin/python3 /usr/bin/python
RUN python -m pip install --upgrade pip
RUN pip3 install --no-cache-dir  -r deploy/requirements/base.txt
RUN  apt autoremove --purge -y \
  && rm -rf \
    /var/lib/apt/lists/* \
    /etc/apt/sources.list.d/*.list \
    /root/.cache/
COPY ./* /app/
RUN chown -R transservice /app/ /run
USER transservice

CMD ["uvicorn", "main:app", "--proxy-headers", "--host", "0.0.0.0", "--port", "9989"]
EXPOSE 9989

deploy/docker/trans_service.yml

version: "1"

volumes:
  transservice:

x-logging: &logging
  driver: "json-file"
  options:
    max-size: "30m"
    max-file: "3"

services:
  attacut_tranliteration:
    image: registry.gitlab.com/usernamehere/servicename:latest
    container_name: attacut_tranliteration
    build:
      context: ../../.
      dockerfile: deploy/docker/Dockerfile
    hostname: tranliteration-attacut
    ports:
      - 9989:9989
#    command:
#      - uvicorn main:app --proxy-headers --host "0.0.0.0" --port 9989
    volumes:
      - transservice:/app
    healthcheck:
      test: ["CMD", "curl", "-f", "http://transservice:9989/"]
      interval: 1m
      timeout: 5s
      retries: 3
      start_period: 40s
#    entrypoint: ["uvicorn", "main:app", "--proxy-headers", "--host", "0.0.0.0", "--port", "9989"]
    restart: always
    networks:
      - postgres

networks:
    postgres:
        driver: bridge

Here is the config file from gitlab runner which is running on the machine used to launch this service:

[[runners]]
  name = "My Docker Runner"
  url = "https://gitlab.com"
  id = 1111111111111
  token = "xxxxxxxxxxx"
  token_obtained_at = 2023-09-15T11:07:54Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  [runners.cache]
    MaxUploadedArchiveSize = 0
  [runners.docker]
    tls_verify = false
    image = "docker:24.0.5"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/certs/client", "/cache"]
    shm_size = 0

Building and pushing to gitlab registry finishes successfully then it also successfully deploys without any error. When I am trying to find this service on the server where it was launches I cannot see it running:

ps ax|grep docker

(I see only other running containers but not this one)

netstat -ntap|grep 9989

(also there is no such service listening on the port 9989)

I tried to change docker compose -f deploy/docker/trans_service.yml up -d to docker compose -f deploy/docker/trans_service.yml up to check if it’s actually running. Job is working, service seems to run, but I can not connect to it from the server itself. What I am missing here?

2

There is nothing running, because you have “deployed” it into the ephemeral Docker in Docker (dind) service which is stopped after job is finished.