В рамках нашей небольшой организации по разработке мы стараемся максимально автоматизировать развертывание / обновление нескольких служб. Эти сервисы в основном находятся в контейнерах Docker (и в нескольких блоках Vagrant для вещей, которые не могут напрямую работать в Linux, например, для узла сборки macOS).
Текущий статус
Мы полагаемся на файлы Docker и файлы Compose (развернутые с docker stack) для достижения значительной части автоматизации: отдельные виртуальные машины устанавливаются воспроизводимым образом путем создания Dockerfiles, а затем напрямую зависимые службы запускаются вместе через compose. файлы.
Тем не менее, становится очевидным, что заключительные этапы настройки среды и развертывания инфраструктуры не одинаково хорошо формализованы. Чтобы проиллюстрировать это, давайте представим, что наша цель - развернуть два стека (Jenkins и Artifactory) в заданной среде.
В настоящее время мы хотели бы рассмотреть последние шаги, создав частный репозиторий A для этого целевого развертывания. Этот репозиторий будет содержать конфигурации, включая секреты, и отдельный сценарий bash для развертывания каждого стека, предоставляя ему соответствующую конфигурацию. Общий мастер-скрипт просто отвечал бы за остановку стеков, если они уже работали, а затем выполнял отдельные скрипты в последовательности.
Затем, чтобы фактически развернуть (или обновить), нужно выполнить SSH в целевой среде, клонировать репозиторий A и запустить мастер-сценарий.
Ограничения
Этот подход не кажется адекватным по сравнению с элегантным подходом контейнеризации. Некоторые из наших горя:
- Это очень нерегулярно, мы должны поддерживать несколько специализированных сценариев, которые связаны с интерфейсом контейнера («как контейнер ожидает, что будет предоставлена конфигурация?» «Какие параметры?»), А также структура данных конфигурации («Является ли конфигурация файлом для монтирования в контейнере? Файл .env, который должен быть получен до развертывания стека или внутри одного из контейнеров стека?»)
- Нарушение принципа СУХОЙ: если мы хотим развернуть подмножество стеков в другой среде или тот же стек с другой конфигурацией, необходимо создать отдельный репозиторий, и он будет перекрываться.
- Не существует чистого способа первого развертывания в тестовой среде (чтобы проверить, что обновление не нарушает функциональность, тест выполняется автоматически или вручную), кроме поддержки отдельного репозитория
A-test, как указано выше.
- Секреты хранятся в открытом виде в приватном
A хранилище.
- Реализация функций обслуживания означала бы больше специальных сценариев bash: например, резервное копирование всех служб в развертывании будет более или менее означать один дополнительный сценарий на стек.
- Нет простого мониторинга
- На самом деле для развертывания по-прежнему требуется несколько шагов вручную (подключение к нужной среде, клонирование репозитория, запуск сценария и проверка статуса его возврата)
Ответы могут принимать несколько форм, с учебными ресурсами, общими советами о том, как решать этот последний шаг с точки зрения разработчика, или рекомендованными инструментами и программным обеспечением, обычно рекомендуемым для этой проблемы.