docker контейнер "post start" активность

Question

Я новичок в docker, и я начинаю создавать, развертывать и поддерживать службы, подобные телеметрии (графана, Прометей, ...). Одна вещь, с которой я столкнулся, это то, что мне нужно запустить графану с некоторыми настройками по умолчанию / предварительно сконфигурированными (приборная панель, пользователи, org, источники данных, ...). Grafana допускает некоторую конфигурацию запуска в своем конфигурационном файле, но не со всеми его функциями (пользователи, org, ...). За пределами (если я не использовал) docker я использую сценарий ansible для настройки не поддерживаемых частей графана. Однако, когда я создаю свой собственный образ графаны (с разрешенной конфигурацией запуска) и позже запускаю контейнер графана этого образа, есть ли способ указать команды или шаги после запуска в файле docker? Я представляю его так, как будто каждый раз при развертывании контейнера моего образа возникают некоторые проблемы при настройке этого контейнера. Какие-либо предложения? Нужно ли мне использовать ansible или другие подобные инструменты для управления им?

Answer 1

Это сложнее, чем кажется. Продолжение использования Ansible для его настройки после запуска, вероятно, является хорошим компромиссом между простотой, кодом, который у вас уже есть, и использованием стандартных инструментов и изображений Docker.

Если это для тестовой среды, Одна из возможностей - сохранить эталонную копию конфигурации и каталогов Grafana. Вам придется распространять их отдельно от Docker образов.

mkdir grafana
docker run \
  -v $PWD/grafana/config:/etc/grafana \
  -v $PWD/grafana/data:/var/lib/grafana \
  ... \
  grafana/grafana
...
tar cvzf grafana.tar.gz grafana

Получив файл tar, вы можете перезапустить систему с известной конфигурации:

tar xvzf grafana.tar.gz
docker run \
  -v $PWD/grafana/config:/etc/grafana \
  -v $PWD/grafana/data:/var/lib/grafana \
  ... \
  grafana/grafana

---

Некоторые из стандартных Docker образов базы данных-концентратора имеют возможность выполнять первоначальную настройку с помощью сценария точки входа; Я буду ссылаться на сценарий точки входа mysql изображения здесь. Техника basi c включает в себя:

1. Определить, является ли команда, поданная для запуска контейнера, на самом деле запустить сервер и , если это первый запуск .
2. Запустить сервер в фоновом режиме, записав его pid.
3. Подождите , пока сервер не станет доступным.
4. Фактически выполните инициализацию в первый раз.
5. Остановите сервер, который был запущен как фоновый процесс.
6. Go на exec "$@" как обычно, чтобы запустить сервер «по-настоящему».

Основное ограничение c здесь заключается в том, что вы хотите, чтобы серверный процесс был единственным, выполняющимся в контейнере, когда все сделано. Это означает, что такие команды, как docker stop, будут напрямую сигнализировать серверу, а в случае сбоя сервера это будет основной процесс контейнера, что приведет к выходу контейнера. После того, как сценарий точки входа заменил себя сервером в качестве основного процесса контейнера (exec img it), вы больше не сможете выполнять работу после запуска. Это приводит к последовательности запуска временной копии сервера для выполнения работы по инициализации.

После выполнения этой работы по инициализации, когда соответствующий контент обычно сохраняется в постоянных каталогах данных или внешних базах данных.

У вопросов SO есть общий путь запуска серверного процесса в фоновом режиме, а затем использование чего-то вроде tail -f /dev/null в качестве фактического процесса основного контейнера. Это означает, что docker stop будет сигнализировать о процессе tail, но не сообщит серверу, что он собирается завершить работу; это также означает, что в случае сбоя сервера, так как процесс tail все еще выполняется, контейнер не завершится. Я бы не рекомендовал этот ярлык.