Введение в Docker для FreeBSD Jail User - Как и как мне запустить контейнер с systemd?

Question

В настоящее время мы переводим сервер комнат в облако для надежности, но у нашего провайдера нет опции FreeBSD. Хотя я готов заплатить и загрузить пользовательский образ системы для развертывания, я все же хочу узнать, как запустить экземпляр системы приложений с помощью Docker.

в FreeBSD Jail , что я сделал для извлечения всей иерархии каталогов base.txz в виде системного содержимого в /usr/jail/app и pkg -r /usr/jail/app install apache24 php perl; затем я настроил /etc/jail.conf для запуска сценария /etc/rc в тюрьме.

Я следовал официальному Руководству по FreeBSD, и это, как правило, то, что я до сих пор работал.

Но Докер - это совсем другой мир.

Чтобы создать образ Docker, есть два варианта: а) импорт из архива, б) использование файла Docker. Последний из них позволяет вам указать «CMD», которая является командой по умолчанию для запуска, но

Q1. почему это не доступно из а)?

Q2. где хранится информация типа "CMD ENV"? на изображении? в контейнере?

Q3. Как запустить систему GNU / Linux в контейнере? Должен ли я просто запустить systemd и позволить ему выяснить остальное из конфигурации? Нужно ли передавать ему какие-то особые аргументы или аргументы?

Answer 1

Вы должны думать о контейнере Docker как о пакете вокруг одного работающего демона. Идеальный контейнер Docker запускает один процесс и только один процесс. В частности, Systemd настолько тяжеловесен и инвазивен, что его трудно запустить в контейнере Docker; если вам нужно несколько процессов в контейнере, то для вас может работать более легкая система инициализации, такая как supervisord, но это, как правило, исключение больше, чем стандартная упаковка.

Docker имеет официальное руководство по созданию и запуску пользовательских образов , которое стоит прочитать; это довольно типичный пример использования Docker. В частности, рекомендуется написать Dockerfile, в котором описано, как создать образ и включить его в систему контроля версий. Контейнеры должны избегать постоянных данных, если они могут (хранение всего во внешней базе данных идеально); если вы меняете изображение, вам нужно удалить и воссоздать все контейнеры на его основе. Если локальные данные неизбежны, то либо тома Docker, либо связывание монтирует , что позволит вам хранить данные "вне" контейнера.

Хотя в Docker есть несколько других способов создания контейнеров и изображений, ни один из них не является настолько воспроизводимым. Вам следует избегать команд import, export и commit; и вы должны использовать save и load, только если вы не можете использовать или настроить реестр Docker и вынуждены перемещать образы между системами через файл tar.

По вашим конкретным вопросам:

Q1. Я подозреваю, что лучшая причина, по которой пути создания изображений, отличные от docker build, не позволяют легко указывать такие вещи, как CMD, это просто деталь реализации: если вы посмотрите на docker history изображения, вы увидите CMD становится его собственным слоем. Не беспокойтесь об этом и используйте Dockerfile.

Q2. Значение по умолчанию CMD, любые установленные переменные ENV и другие связанные метаданные хранятся в изображении вместе с деревом файловой системы. (После запуска контейнера у него появляется обычное дерево процессов Unix с начальным процессом pid 1.)

Q3. Вы не «запускаете систему в контейнере». Обычно запускайте один процесс или службу в контейнере и независимо управляйте их жизненными циклами.