Как стать автором
Обновить

Комментарии 16

depends_on в данном случае недостаточно — постгрес может не успеть стартовать до того, как приложение в него поломится. Нужен healthcheck:


  service-db:
    healthcheck:
      test: ["CMD-SHELL", "pg_isready", "--quiet"]
      interval: 1s
      timeout: 5s
      retries: 10

  service:
    depends_on:
      service-db:
        condition: service_healthy

Спасибо за комментарий. Полностью согласен с ним, возможна такая ситуация когда postgreSQL не успеет накатить БД, так как depends_on гарантирует только, что сервис будет стартовать сразу после другого, не дожидаясь полного окончания его старта.

Добрый день. Я только изучаю возможности докера и поэтому хотел вас попросить написать здесь или как то скинуть файл docker-compose.yml этого проекта с настройками healthcheck. Пробовал уже по разному вставить проверку, но все равно запуск происходит рандомно, в итоге все настройки бд не успевают подгрузиться.

Всё необходимое описано в первом комментарии. Это будет работать с официальным образом postgres. Если покажете ваш конфиг — возможно, станет понятнее, в чём проблема.

version: '3.8'
services:
  client-frontend:
    image: frontend:0.0.1
    build: ./frontend
    restart: always
    ports:
      - '3000:3000'
    volumes:
      - /app/node_modules
      - ./frontend:/app

  client-backend:
    image: client:0.0.1
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8181:8181"
    depends_on:
      service-db:
        condition: service_healthy
    environment:
      - SERVER_PORT= 8181
      - SPRING_DATASOURCE_URL=jdbc:postgresql://service-db/books_db

  service-db:
    image: postgres:14.7-alpine
    environment:
      POSTGRES_USER: username
      POSTGRES_PASSWORD: password
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready", "-d", "books_db" ]
      interval: 10s
      timeout: 3s
      retries: 3
    ports:
      - "15432:5432"
    volumes:
      - ./infrastructure/db/create_db.sql:/docker-entrypoint-initdb.d/create_db.sql
      - db-data:/var/lib/postgresql/data
    restart: unless-stopped

  pgadmin:
    container_name: pgadmin4_container
    image: dpage/pgadmin4:7
    restart: always
    environment:
      PGADMIN_DEFAULT_EMAIL: admin@admin.com
      PGADMIN_DEFAULT_PASSWORD: root
    ports:
      - "5050:80"
    volumes:
      - pgadmin-data:/var/lib/pgadmin

volumes:
  db-data:
  pgadmin-data:

Хорошо! Но вот что тут стоит поправить с точки зрения контейнеров

  1. хранение кредов.

environment:
 PGADMIN_DEFAULT_EMAIL: admin.com
 PGADMIN_DEFAULT_PASSWORD: root

Это надо с нуля учить выносить в .env, иначе вся сборка становится абсолютно непортируемой между средами разработки.

  1. Относительно Pgadmin: все таки админские интерфейсы для БД - ну такое. Ведь всегда можно подключиться нативным клиентом, который проще завернуть во внутреннюю сетку.

  2. Не уверен, что контейнер node собирается оптимально. Мы там сначала копируем файл зависимостей, собираем их, а потом снова копируем исходный код. Точно нельзя это упаковать в один шаг копирования?

Мы там сначала копируем файл зависимостей, собираем их, а потом снова копируем исходный код.

Скачивание зависимостей умышленно выносится на отдельный слой, чтобы ускорить пересборку образа при разработке.
Неоптимальность обычно сглаживается тем, что вместо запуска дев-сервера собирается статика и копируется в новый образ какого-нибудь nginx.

Спасибо! Но в таком случае не проще исходники вольюмом пробросить?

Если нужен hot reload на изменения на хосте, то так и придется поступить. Другое дело, зачем нам в таком виде это в докер заворачивать, имея все инструменты на хосте?)

Да, тут зависит от решаемой задачи. Контейнеры тут будут выполнять задачу изоляции процессов и стандартизации сред исполнения. Конечно, если надо прям вот упаковать и доставить без доступа к хосту, то volume не прокатит.

Особенно нравится Spring с -Dmaven.test.skip=true, без которого приложение ломится тестировать соединение с базой на этапе запаковки артефакта. Это поведение не отключается каким-то вменяемым образом через конфиги?

Это не spring, а lombok

Я правильно понимаю что это сборка для режима разработки? По фэншую надо же реакт-приложение отбилдить и раздать билд статикой с nginix? Или теперь так не делают?

Эээ... а в чем прикол писать миграции через xml вместо человечего sql?!

В посгри вы не задали

1)shared_buffers,effective_cache_size,work_mem

2)shm_size - ПО УМОЛАНИЮ ОН ВСЕГО 64мб, а именно он используется для shared_buffers.

3)Random_page_cost - у вас же ssd?

Как скоро вы получите "could not resize shared memory segment “/PostgreSQL.xxxx” to yyyyy bytes: No space left on device"?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории