ты про https://medium.com/lucjuggery/docker-daemon-metrics-in-prometheus-7c359c7ff550 ?

д

Приветы. Почитал тут про entrypoint (последнюю переписку за несколько месяцев) и решил вопросов задать. Хочу использовать образ postgres:9.6 и не отказываться от docker-compose.

Если сделать docker-compose up -d, очень быстро запускается ENTRYPOINT, отрабатывает и перезапускается уже как CMD, без ENTRYPOINT. При этом, выглядит как грязный хак, что слово postgres из команды, используется и как первый параметр в ENTRYPOINT — не только как имя бинаря, но и как юзернейм. Наверное, это очень красиво, но очень ограничивает в возможностях использования.

Есть проблемы с вызовом ENTRYPOINT из docker-compose up -d, нет их в docker-compose run servicename. За и против одного и второго: + первого в том, что можно определять имя контейнера, порты. - первого в том, что вечный рестарт и ничего не работает (отдельная тема для обсуждения) + второго в том, что можно управлять вызовом ENTRYPOINT и делать свои чёрные дела, перед первым запуском postgres как процесса с PID 1 - второго в том, что отваливаются имена контейнеров, порты

Мои хотелки: 0. не пересобирать образ 1. подключить кастомизированный src/docker-entrypoint.sh:/docker-entrypoint.sh:ro вольюмом 2. docker-compose up -d и оно пошло вызывать ENTRYPOINT (главное — предсказуемо) 3. postgres запустился уже с теми данными, которые насоздавались в третьем пункте

И да, это всё для /usr/lib/postgresql/9.6/bin/pg_basebackup -h "$SRC_HOST" -U "$SRC_USER" -P -v -D "$PGDATA" -w -P

И да, это всё для /usr/lib/postgresql/9.6/bin/pg_basebackup -h "$SRC_HOST" -U "$SRC_USER" -P -v -D "$PGDATA" -w -P

а что мешает pg_basebackup запускать в отдельном контейнере?

вся эта магия нафиг не нужна с кубернетесом - подготовили данные и поехали. Почему так странно сделано в докере штатном - он должен заинитить БД, если ее нет.

Т.е. образ как бы самодостаточный

и еще я рекомендую pg_probackup

Что-то в этом есть. То есть, определить два сервиса? 1. для реплицирования с мастера, рестарт: никогда 2. для работы с этими данными, зависим от первого и не запускается, пока тот не отработает так?

типа того

я просто задачу изначальную не знал )

касательно порядка запуска в рамках докер-компоуза - это решается, но решается некрасиво

Да, я недостаточно подробно описал кейс. Спасибо

и еще я рекомендую pg_probackup

Пока не могу так сделать. Надо ограничиться использованием штатного образа и просто правильно его готовить :( Вопрос про то, как лучше сделать первый сервис: 1. переопределяю entrypoint: [] 2. переопределяю command: ["/usr/lib/postgresql/9.6/bin/pg_basebackup", "-h", "${SRC_HOST}", "-U", "${SRC_USER}", "-P", "-v", "-D", "${PGDATA}", "-w", "-P"] ... X. PROFIT!!!1! Так?

Пока не могу так сделать. Надо ограничиться использованием штатного образа и просто правильно его готовить :( Вопрос про то, как лучше сделать первый сервис: 1. переопределяю entrypoint: [] 2. переопределяю command: ["/usr/lib/postgresql/9.6/bin/pg_basebackup", "-h", "${SRC_HOST}", "-U", "${SRC_USER}", "-P", "-v", "-D", "${PGDATA}", "-w", "-P"] ... X. PROFIT!!!1! Так?

можно все что в п.2 загнать в entrypoint

как бы не особо потеря. Главное, чтобы каталог с данными существовал, а то будет подстава

т.е. запуск поверх уже существующей БД - не проблема. Проблема создать все необходимые каталоги

тогда получится в момент запуска: /usr/lib/postgresql/9.6/bin/pg_basebackup -h "$SRC_HOST" -U "$SRC_USER" -P -v -D "$PGDATA" -w -P postgres, вместо /usr/lib/postgresql/9.6/bin/pg_basebackup -h "$SRC_HOST" -U "$SRC_USER" -P -v -D "$PGDATA" -w -P

тогда получится в момент запуска: /usr/lib/postgresql/9.6/bin/pg_basebackup -h "$SRC_HOST" -U "$SRC_USER" -P -v -D "$PGDATA" -w -P postgres, вместо /usr/lib/postgresql/9.6/bin/pg_basebackup -h "$SRC_HOST" -U "$SRC_USER" -P -v -D "$PGDATA" -w -P

нет

достаточно все написать в entrypoint, а cmd оставить пустым

я про это

а, ок

сейчас поиграюсь, спасибо

Хлопцы подскажите в чем проблема, прикрепил volume который в авс с данными в контейнер, df -h выдает что содержимое есть, но внутри пусто ((

Версия докера? Ядра? Какой драйвер storage?

В продолжение своего вышеописанного эпоса, родил пару новых вопросов: 1. можно ли использовать что-нибудь вроде order: stop-first, без использования swarm? 2. как использовать depends_on: db-prepare, если хочется не запустить другой сервис сразу после запуска некоего сервиса db-prepare, а дождаться того момента, когда тот отработает и остановится? Цель: разделить подготовку БД и запуск контейнера с данными, которые подготовил другой контейнер. Возможно, цель поставлена неверно.

В продолжение своего вышеописанного эпоса, родил пару новых вопросов: 1. можно ли использовать что-нибудь вроде order: stop-first, без использования swarm? 2. как использовать depends_on: db-prepare, если хочется не запустить другой сервис сразу после запуска некоего сервиса db-prepare, а дождаться того момента, когда тот отработает и остановится? Цель: разделить подготовку БД и запуск контейнера с данными, которые подготовил другой контейнер. Возможно, цель поставлена неверно.

2: использовать version: 2 и хелсчеки на бд

А контейнер с БД запускается без враппера, просто командой postgres, PID=1

как быть?

спасибо, я не сразу понял, что healthcheck — ключевое слово

А контейнер с БД запускается без враппера, просто командой postgres, PID=1

Это проблема?

нет, просто я решил, что хелсчек надо делать перед запуском демона, в скрипте

Похоже, что я пробую какие-то несуществующие кейсы: services: init: volumes: - pgdata:/var/lib/postgresql/data healthcheck: start_period: 40s ... db: volumes: - pgdata:/var/lib/postgresql/data depends_on: init: condition: service_unhealthy ... А именно: - не бывает service_unhealthy, а так хочется проверить, что оно stopped, или unhealthy - общий volume pgdata и надо с ним работать только поочереди, а не надеяться на то, что битая БД будет поводом к останову второго контейнера.

Какие есть предложения, что мне почитать ещё?

А чо надо-то?

Запуск постгреса не требует этой херни

Есть потребность выполнить предварительную репликацию с мастера. Разделил на два контейнера, так как с одним ещё больше печалей

Сделай чтобы один контейнер можно было запускать сколько угодно раз без слома чего-то

Ну или просто возьми готовый патрони

Похоже, что я пробую какие-то несуществующие кейсы: services: init: volumes: - pgdata:/var/lib/postgresql/data healthcheck: start_period: 40s ... db: volumes: - pgdata:/var/lib/postgresql/data depends_on: init: condition: service_unhealthy ... А именно: - не бывает service_unhealthy, а так хочется проверить, что оно stopped, или unhealthy - общий volume pgdata и надо с ним работать только поочереди, а не надеяться на то, что битая БД будет поводом к останову второго контейнера.

делай наоборот

я @Andorka рассказывал. Выбери интервал времени за которое миграция гарантированно отрабатывает. Это будет время опроса хелсчека. Далее в конце миграции делаешь && touch /tmp/flag && sleep 10000 и в хелсчеке test -f /tmp/flag

профит

но вообще натягивать это на докер-компоуз - то еще удовольствие

либо тебе нужен внешний оркестратор. В конце-концов, можешь проверять код возврата контейнера в баше

типа #!/bin/bash docker run my_migrations # здесь проверяем код возврата, если ошибка - на выход docker run -d postgres

Ну или просто возьми готовый патрони

Патрони... Кто же мне даст их использовать, вместо того, что на боевой базе? (На мастере)

Сделай чтобы один контейнер можно было запускать сколько угодно раз без слома чего-то

как это сделать с монгой -.- как ее вообще использовать в контейнерах -.-

берёшь готового оператора...

делай наоборот

Если проверять healthy, то да - это работает, хотя и небезопасно - постгрес может в любой момент решить, что всё докачалось и начнёт портить данные, каким-либо способом

я @Andorka рассказывал. Выбери интервал времени за которое миграция гарантированно отрабатывает. Это будет время опроса хелсчека. Далее в конце миграции делаешь && touch /tmp/flag && sleep 10000 и в хелсчеке test -f /tmp/flag

Не проверял, можно ли в entrypoint вписывать &&

Идея нравится

composer: <<: *php-cli working_dir: /var/www/nexus/lib healthcheck: test: test -f /tmp/.composer.done interval: 2s timeout: 1s retries: 120 environment: SLEEP_BEFORE_EXIT: '1' entrypoint: - bash - -e - -c - > rm -f /tmp/.composer.done; case $$0 in install) composer "$$0" --no-interaction "$$@"; ;; *) composer "$$0" "$$@" ;; esac; touch /tmp/.composer.done && ( [[ $$SLEEP_BEFORE_EXIT == 1 ]] && sleep 5 || true ); command: - install

наслаждайся девопс-веем 2019 года

Ой-вей, как говорится ?

Спасибо, попробую

Привет, всем. У меня какая-то невероятная дичь. Есть nodejs програмка, что запускается в контейнере и принимает запроси на конкретном порту. Ей достаточно ресурсоав, она уже даже автоматизирована, но она засыпает и не могу понять почему

Тоесть если бомбить приложение запросами, то ему норм, хоть в 100 потоков

Но если его оставить без дела на несколько минут, то вернет 502-ю, а после нескольких обновлений страницы снова заведется

Вы с таким не сталкивались?

У меня какая-то невероятная дичь. Есть nodejs програмкаможно не продолжать было

Вы с таким не сталкивались?

нет, мы с твоим приложением скорее всего не сталкивались

502 само приложение возвращает или реверс-прокси перед ним?

nginx возвращает

о, блокчейн весит 300 гигов?

Не проверял, можно ли в entrypoint вписывать &&

если через sh -c , то да

Парни как сделать что бы после выполнение CMD в dockerfile контенер дальше жил ??

никак

CMD [ cmd; tail -f /bin/bash ] как костыль

sleep infinity

sleep infinity

это делает мой контенер php-fpm недоуступным для nginix

что?

если влили образы докера в хранилище, как их пускать через docker-compose?

(в приватную репу)

если влили образы докера в хранилище, как их пускать через docker-compose?

указать их

так же как и для публичного реджистри

я так понимаю, надо тогда писать другой докер-компоуз..

имя образа будет другое, очевидно

docker tag kamailio:latest 1.1.1.1:5000/kamailio docker push 1.1.1.1:5000/kamailio

жесть

что?

2019 год на дворе, а они ip-адреса хардкодят

что?

502 bad request logi говорят что не может до fpm достучаться, убераю CMD с sleep infinity и все работает

502 bad request logi говорят что не может до fpm достучаться, убераю CMD с sleep infinity и все работает

диагностика 80 уровня прям у тебя и так php-fpm запускается и висит, если он выходит, значит ты делаешь что-то не так

2019 год на дворе, а они ip-адреса хардкодят

ну могу домен вписать..

сути не меняет

сейчас есть компоуз файл где запускается сборка из папки

kamailio: build: context: kamailio dockerfile: Dockerfile ports: - "5080:5080"

если добавишь туда image то при сборке компоуз сам будет вешать тег на имдж

останется только сделать push

хм, спасибо