Roman
задача выбрать сбособ для реализации реал-тайм нотификаций на сервере. Я сделал анализ что есть на рынке создал для каждово решения свой контейнер. Нагрузку на запись и чтение проверил, теперь хочу проверить нагрузку железа
Andor
нагрузку железа
Roman
так как реального сервака нет, я хотел узнать метрики контейнера под нагрузкой
Roman
всем спасибо. попробую завтра pramitheurus
Mykyta
так как реального сервака нет, я хотел узнать метрики контейнера под нагрузкой
cadvizor поставь и смотри
Mykyta
какой еще докер статс
George
Во-вторых, говно
Mykyta
Штатная опция, между прочим
штатная опция это забыть что такое ссш на хост, для этого всего есть прометеус )
George
штатная опция это забыть что такое ссш на хост, для этого всего есть прометеус )
Ну, спорить не буду. Но коллега явно разворачивал не автоматизированно
George
а скорее всего через ссш
George
К тому же, вроде как, докер научился экспоузить метрики сам
Andor
он же метрики демона умеет, а не контейнеров
Andor
я
George
он же метрики демона умеет, а не контейнеров
ты про https://medium.com/lucjuggery/docker-daemon-metrics-in-prometheus-7c359c7ff550 ?
George
https://github.com/google/cadvisor/issues/1774
George
я в это влетел
Ruslan
Приветы. Почитал тут про entrypoint (последнюю переписку за несколько месяцев) и решил вопросов задать.
Хочу использовать образ postgres:9.6 и не отказываться от docker-compose.
Ruslan
Если сделать docker-compose up -d, очень быстро запускается ENTRYPOINT, отрабатывает и перезапускается уже как CMD, без ENTRYPOINT.
При этом, выглядит как грязный хак, что слово postgres из команды, используется и как первый параметр в ENTRYPOINT — не только как имя бинаря, но и как юзернейм. Наверное, это очень красиво, но очень ограничивает в возможностях использования.
Ruslan
Есть проблемы с вызовом ENTRYPOINT из docker-compose up -d, нет их в docker-compose run servicename.
За и против одного и второго:
+ первого в том, что можно определять имя контейнера, порты.
- первого в том, что вечный рестарт и ничего не работает (отдельная тема для обсуждения)
+ второго в том, что можно управлять вызовом ENTRYPOINT и делать свои чёрные дела, перед первым запуском postgres как процесса с PID 1
- второго в том, что отваливаются имена контейнеров, порты
Ruslan
Мои хотелки:
0. не пересобирать образ
1. подключить кастомизированный src/docker-entrypoint.sh:/docker-entrypoint.sh:ro вольюмом
2. docker-compose up -d и оно пошло вызывать ENTRYPOINT (главное — предсказуемо)
3. postgres запустился уже с теми данными, которые насоздавались в третьем пункте
Ruslan
И да, это всё для
/usr/lib/postgresql/9.6/bin/pg_basebackup -h "$SRC_HOST" -U "$SRC_USER" -P -v -D "$PGDATA" -w -P
George
И да, это всё для
/usr/lib/postgresql/9.6/bin/pg_basebackup -h "$SRC_HOST" -U "$SRC_USER" -P -v -D "$PGDATA" -w -P
а что мешает pg_basebackup запускать в отдельном контейнере?
George
вся эта магия нафиг не нужна с кубернетесом - подготовили данные и поехали. Почему так странно сделано в докере штатном - он должен заинитить БД, если ее нет.
George
Т.е. образ как бы самодостаточный
George
и еще я рекомендую pg_probackup
Ruslan
Что-то в этом есть. То есть, определить два сервиса?
1. для реплицирования с мастера, рестарт: никогда
2. для работы с этими данными, зависим от первого и не запускается, пока тот не отработает
так?
George
типа того
George
я просто задачу изначальную не знал )
George
касательно порядка запуска в рамках докер-компоуза - это решается, но решается некрасиво
Ruslan
Да, я недостаточно подробно описал кейс. Спасибо
Ruslan
и еще я рекомендую 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!
Так?
George
George
как бы не особо потеря. Главное, чтобы каталог с данными существовал, а то будет подстава
George
т.е. запуск поверх уже существующей БД - не проблема. Проблема создать все необходимые каталоги
Ruslan
тогда получится в момент запуска:
/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
George
достаточно все написать в entrypoint, а cmd оставить пустым
George
я про это
Ruslan
а, ок
Ruslan
сейчас поиграюсь, спасибо
Ильдар
Хлопцы подскажите в чем проблема, прикрепил volume который в авс с данными в контейнер, df -h выдает что содержимое есть, но внутри пусто ((
Версия докера? Ядра? Какой драйвер storage?
Ruslan
В продолжение своего вышеописанного эпоса, родил пару новых вопросов:
1. можно ли использовать что-нибудь вроде order: stop-first, без использования swarm?
2. как использовать depends_on: db-prepare, если хочется не запустить другой сервис сразу после запуска некоего сервиса db-prepare, а дождаться того момента, когда тот отработает и остановится?
Цель: разделить подготовку БД и запуск контейнера с данными, которые подготовил другой контейнер.
Возможно, цель поставлена неверно.
Ruslan
А контейнер с БД запускается без враппера, просто командой postgres, PID=1
Ruslan
как быть?
Ruslan
спасибо, я не сразу понял, что healthcheck — ключевое слово
Ruslan
нет, просто я решил, что хелсчек надо делать перед запуском демона, в скрипте
Ruslan
Похоже, что я пробую какие-то несуществующие кейсы:
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 и надо с ним работать только поочереди, а не надеяться на то, что битая БД будет поводом к останову второго контейнера.
Ruslan
Какие есть предложения, что мне почитать ещё?
Andor
А чо надо-то?
Andor
Запуск постгреса не требует этой херни
Ruslan
Есть потребность выполнить предварительную репликацию с мастера.
Разделил на два контейнера, так как с одним ещё больше печалей
Andor
Сделай чтобы один контейнер можно было запускать сколько угодно раз без слома чего-то
Andor
Ну или просто возьми готовый патрони
George
я @Andorka рассказывал. Выбери интервал времени за которое миграция гарантированно отрабатывает. Это будет время опроса хелсчека. Далее в конце миграции делаешь && touch /tmp/flag && sleep 10000 и в хелсчеке test -f /tmp/flag
George
профит
George
но вообще натягивать это на докер-компоуз - то еще удовольствие
George
либо тебе нужен внешний оркестратор. В конце-концов, можешь проверять код возврата контейнера в баше
George
типа
#!/bin/bash
docker run my_migrations
# здесь проверяем код возврата, если ошибка - на выход
docker run -d postgres
Ruslan
Ну или просто возьми готовый патрони
Патрони... Кто же мне даст их использовать, вместо того, что на боевой базе? (На мастере)
Ilia
Сделай чтобы один контейнер можно было запускать сколько угодно раз без слома чего-то
как это сделать с монгой -.-
как ее вообще использовать в контейнерах -.-
Andor
берёшь готового оператора...
Ruslan
делай наоборот
Если проверять healthy, то да - это работает, хотя и небезопасно - постгрес может в любой момент решить, что всё докачалось и начнёт портить данные, каким-либо способом
Ruslan
Ruslan
Идея нравится
Andor
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
Andor
наслаждайся девопс-веем 2019 года
Ruslan
Ой-вей, как говорится 😅
Ruslan
Спасибо, попробую