получение контейнеров для работы с конфигурационными файлами путем создания шаблонов

Question

Я использую ansible для отправки пользовательских сервисов, а также шаблонные файлы конфигурации для этих приложений (разные для каждого приложения / сервера / среды)

Я переезжаю в Docker для запуска своих сервисов, но мне все равно нужно использовать файлы конфигурации, которые отправляет ansible.

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

Это хакерское решение требует, чтобы три вещи были выровнены, чтобы все работало (отвечая за толчок файла конфигурации по правильному пути, контейнер, чтобы правильно смонтировать этот путь как том, и приложение, находящее конфигурацию в месте монтирования) - это крики высокого риска, трудно управляемые и трудно меняемые.

Каковы лучшие способы получения доступных для конфигурации файлов конфигурации ANSIBLE? Или мне нужно начать искать альтернативы ansible?

Некоторые мысли:

• У меня много разных виртуальных машин и наборов приложений в dev / qa / prod среды, поэтому я не хочу продолжать настройку выпечки в изображения или я получу сотни изображений
• Я в порядке с загрузкой конфигурации во время выполнения контейнера, но как я могу сделать это таким образом, чтобы по-прежнему использовать ANSISIL, не позволяющий запустить ANSIBLE PlayBook изнутри самого контейнера (каким-то образом?)

Answer 1

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

Поскольку контейнер Docker имеет изолированную файловую систему, контейнеры обычно используют фиксированные «нормальные» пути файловой системы. Например, стандартное изображение nginx изобилует ссылками на /etc/nginx в пространстве контейнера. Целесообразно рассматривать эти пути на стороне контейнера как часть внешнего интерфейса с изображением; Вы должны трактовать путь /etc/nginx/nginx.conf как стабильный, как параметр командной строки -g 'daemon off' (вы не ожидаете, что этот путь будет меняться при обновлении образа).

Чтобы избежать повторения пути к файлу, вы можете использовать переменную Ansible . Это может быть более полезным, если у вас есть роль для запускаемого контейнера. Вы можете указать путь по умолчанию на стороне хоста и переопределить его в Playbook верхнего уровня или в командной строке. Это позволило бы вам написать игровую книгу, запускающую контейнер, как

- name: Copy nginx.conf
  template:
    src: nginx.conf.j2
    dest: "{{ nginx_config_path }}/nginx.conf"

- name: Launch nginx
  docker_container:
    name: nginx
    image: nginx
    volumes:
      - "{{ nginx_config_path }}:/etc/nginx"

Обратите внимание, что эта проблема не является уникальной для Ansible. A kubernetes Объект ConfigMap является наиболее близким к этому эквиваленту, и, как и то, что вы здесь описываете, это также правильный путь для вставки файлов конфигурации в контейнеры (Pod), но он по сути имеет ту же проблему, требуя три пары имен, чтобы соответствовать. Опять же, нет лучшего решения, чем пытаться использовать «переменную» или «константу» в той степени, в которой это позволяет ваша система оркестровки, и надеяться, что проблема будет обнаружена раньше, чем позже.