Comments 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:
Хорошо! Но вот что тут стоит поправить с точки зрения контейнеров
хранение кредов.
environment:
 PGADMIN_DEFAULT_EMAIL: admin.com
 PGADMIN_DEFAULT_PASSWORD: root
Это надо с нуля учить выносить в .env, иначе вся сборка становится абсолютно непортируемой между средами разработки.
Относительно Pgadmin: все таки админские интерфейсы для БД - ну такое. Ведь всегда можно подключиться нативным клиентом, который проще завернуть во внутреннюю сетку.
Не уверен, что контейнер node собирается оптимально. Мы там сначала копируем файл зависимостей, собираем их, а потом снова копируем исходный код. Точно нельзя это упаковать в один шаг копирования?
Мы там сначала копируем файл зависимостей, собираем их, а потом снова копируем исходный код.
Скачивание зависимостей умышленно выносится на отдельный слой, чтобы ускорить пересборку образа при разработке.
Неоптимальность обычно сглаживается тем, что вместо запуска дев-сервера собирается статика и копируется в новый образ какого-нибудь nginx.
Спасибо! Но в таком случае не проще исходники вольюмом пробросить?
Если нужен hot reload на изменения на хосте, то так и придется поступить. Другое дело, зачем нам в таком виде это в докер заворачивать, имея все инструменты на хосте?)
Да, тут зависит от решаемой задачи. Контейнеры тут будут выполнять задачу изоляции процессов и стандартизации сред исполнения. Конечно, если надо прям вот упаковать и доставить без доступа к хосту, то volume не прокатит.
Если стандартизация сводится к NodeJS нужной версии, то контейнеры слегка избыточны.
Особенно нравится Spring с -Dmaven.test.skip=true
, без которого приложение ломится тестировать соединение с базой на этапе запаковки артефакта. Это поведение не отключается каким-то вменяемым образом через конфиги?
обожаю спринг, все четко и понятно
Я правильно понимаю что это сборка для режима разработки? По фэншую надо же реакт-приложение отбилдить и раздать билд статикой с 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"?
Пишем простой docker-compose.yml для контейнеризации приложения (React, Spring Boot, PostgreSQL, pgAdmin)