чем docker commit не катит?

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

А если остановка для сервиса не критична? Разве бекап контейнера не является более правильным вариантом?

вся суть докера в том, что у него фс с ревизиями

чем больше изменений, тем больше слоев, а это очень интересная игра

можешь попробовать поиграться с docker export/import

дык разве база не в памяти висит? Правильная остановка базы должна положить разницу от предыдущего слоя на диск. Docker-commit сделает снапшот-разницу между прошлым состоянием диска и текущим.

насколько я помню у докера есть дефолтный лимит на память используемую контейнером

А всё что не влезло в своп?

вот на докхабе есть прям образ https://hub.docker.com/r/wetransform/dockup/

кто-нибудь использует keepalived? есть смысл его в контейнер сувать и потом с маршрутизацией private-public IP париться?

вот на докхабе есть прям образ https://hub.docker.com/r/wetransform/dockup/

Спасибо

1) Подсмотреть команду, которой этого демона запускает инит-скрипт (или кто там его запускает сейчас) 2) Именно эту команду задать в докерфайле (можно с модификациями по вкусу) 3) Если апач по каким-то причинам умирает, то для этой проблемы не нужны никакие супервизоры, в самом докере есть restart policy

Чот не нагуглилось толковой темы для docker-compose, в частности не ясно как там сделать docker run --restart=always redis

restart: always

services: nginx: build: ./nginx restart: always

О, спс

у докера все еще есть та детская болезнь на запуск зависимых сервисов?

Что за болезнь?

помню, делали в докер-композе wait4mysql

потому что вебморда стартовала раньше чем инициализировалась база

Есть depends_on: services: nginx: build: ./nginx restart: always depends_on: - data

а не помогает)

А, ну наверное база стартует долго, докер запускает процесс - и считает его "запущенным"

это в первый раз, когда мне понадобился restart: always и я его быстро загуглил

но это не спасло от написания скрипта на ожидание

Есть depends_on: services: nginx: build: ./nginx restart: always depends_on: - data

dockerproject_drupal_1 exited with code 137 =(((

137 это убийство kill 9

command: apachectl -f /etc/httpd/conf/httpd.conf -e info -DFOREGROUND restart: always

Для проверки жму ctrl+c

И оно просто умирает по 137

на деле это означает что что-то есть в CMD

и кто-то пытается что-то запустить помимо этого)

Вам не нужен restart: always. вам нужен restart: on-failure

CMD watch netstat -nlpt КОторое не работает вообще

Вам не нужен restart: always. вам нужен restart: on-failure

Оно предполагает ограниченное число перезапусков

а зачем рестарт?

Чтоб жило всегда же

тогда unless-stopped или что-то в эту степь

Чтоб жило всегда же

даже если остановили руками ?

и советую поменять CMD на родное CMD ["nginx", "-g", "daemon off;"]

Оно предполагает ограниченное число перезапусков

если у вас все падает надо не подорожник прекладывать рестартом а баги исправить)

оно запускает именно то, что ожидается от контейнера

контейнер не делает магии, если вы пишете свой докерфайл - делайте красиво)

можно еще затюнить и выставить симлинки логов на /dev/stderr

но это не спасло от написания скрипта на ожидание

делал так — разносил по разным композ-файлам и писал фаб таску, которая сначала поднимала первым композ файлом, запускала скрипт, который чекал, все ли поднялось, а потом поднимала вторую часть

увы, красивее не придумалось

даже если остановили руками ?

Ну какая разница чем? Упало, рестартани, как это делает supervisord

контейнер не делает магии, если вы пишете свой докерфайл - делайте красиво)

Вот за этим я сюда и пришёл.Чтобы подсказали бестпрактис

но это не спасло от написания скрипта на ожидание

https://github.com/vishnubob/wait-for-it

спасибо, но меня и тогда смутило его решение, в проде используется dockerize https://github.com/jwilder/dockerize/

https://cs7051.userapi.com/c638316/v638316370/3a65f/hvJV3S7Dtvg.jpg

https://github.com/vishnubob/wait-for-it

интересный подход. а если мне монгу ждать, то мне дергать 27017 что ли?

интересно, что она ответит когда будет готова

интересный подход. а если мне монгу ждать, то мне дергать 27017 что ли?

хз, в монге можно было простой сервис накатать внутри нее? вот когда он ответит тогда норм

ну или просто спрашивать какой нибудь ключ

видел варианты сложнее чем просто ждать порт

хз, в монге можно было простой сервис накатать внутри нее? вот когда он ответит тогда норм

это костыль страшный)

мой скрипт чекал логи и ждал строчку конкретную. типа "Ready and waiting for connections on 27017"

Костыль - это монга в проде! Все остальное не запрещено)

мой скрипт чекал логи и ждал строчку конкретную. типа "Ready and waiting for connections on 27017"

хрупко, в следующем билде изменять формат сообщения и оппа

ну так я фиксирую версию монги

она же тоже в контейнере

докер создан чтобы умирать)

Мисиксы)))

интересный подход. а если мне монгу ждать, то мне дергать 27017 что ли?

вроде как links и health checking должны решать эту проблему, но это не точно

да, но жаль health check может сказать только что все плохо или нет. вот бы хук повесить

чтот я пропустил с докер клаудом https://blog.maddevs.io/continuous-deployment-with-docker-cloud-1f19ac454781

вроде платный был

вернее early access потом платный

да, но жаль health check может сказать только что все плохо или нет. вот бы хук повесить

Я может извращенец, но переделывая архитектуру на новый лад, как раз заморочился с этим. В итоге: есть healthchek'и контейнера, event докера об их состоянии прокидываются в events consul, а оттуда в sensu

Я к тому что хук повесть как раз можно, по крайней мере у consul

Вот такое в конфиге: frontend: (...) deploy: mode: replicated replicas: 2 placement: constraints: - node.labels.host.role == front update_config: parallelism: 1 delay: 2s monitor: 2s Обновляю образы, делаю docker stack deploy, в итоге перезапускается только одна реплика: COMMAND CREATED STATUS "nginx -c /nginx.conf" 11 minutes ago Up 11 minutes "nginx -c /nginx.conf" 19 hours ago Up 19 hours Почему так может происходить?

Причем это не всегда так подвисает, а примерно 1 раз из десяти деплоев

Причем это не всегда так подвисает, а примерно 1 раз из десяти деплоев

А логи есть? docker.log может помочь

А логи есть? docker.log может помочь

посмотрел журнал — ничего про этот сервис

щас еще прикол был другой — на одной из нод сервис перестал быть доступным, остальные узлы его будто не видели, docker service ls показывал 1/1 хотя должно быть /2

убил контейнер — он не перезапускался

перезапускал dockerd — ничего

помогло только сделать docker swarm leave, и снова join

может не стоит мне юзать версию 17.03 и поставить 1.13 как более стабильную

Debugging a Docker Heisenbug in production https://medium.com/@loginoff/debugging-a-docker-heisenbug-in-production-586ccb265f7c#.iu5ezrhph