В этой статье мы поговорим о процессе настройки проектов с продолжающейся интеграцией/доставкой за счет ряда интересных решений, которые стали доступны благодаря появлению автоматизированного ПО и контейнеров.
Разделим процесс на этапы. Всего их будет три:
- Настройка контейнеров 101;
- Как использовать контейнер для других циклов разработки ПО;
- Как интегрировать контейнеры в Continuous Delivery.
Настройка контейнеров 101
Сначала сделаем небольшую ремарку и поговорим о самих контейнерах. По сути, это инструмент, который позволяет виртуализировать объекты, разделяя их таким образом, чтобы ядро системы могло управлять ими по-отдельности. Наглядный пример:
Не стоит путать контейнер с виртуальной машиной!
Почему именно контейнеры?
Они обладают несколькими существенными преимуществами:
- Обеспечение портативности: если вы создадите контейнер, то вам не нужно будет беспокоиться насчет повторной настройки отдельных его элементов, так как все зависимости уже заложены внутри. Это касается даже тех случаев, когда вы переносите контейнер на другую ОС.
- Повышение эффективности и производительности: с помощью контейнера вы можете значительно улучшить работу многих программ, так как они остаются изолированными от ненужных процессов. Это позволяет отключить все лишнее и сэкономить ресурсы всей системы, хотя контейнеры и без того не требуют дополнительных мощностей ОС.
- Высокий уровень изолирования отдельных объектов: как уже говорилось выше, контейнеры изолированы от всего лишнего. Тем не менее, вы можете настроить их таким образом, чтобы необходимые внешние элементы синхронизировались с ним. Еще одной полезной функцией является то, что подобная связь реализуется и между самими контейнерами. Стоит ли говорить, что такой метод работы серьезно усложняет жизнь злоумышленникам, которые хотели бы похитить ваши данные?
- Скорость: контейнеры очень экономно относятся к аппаратным ресурсам, что позволяет им быть удивительно быстрыми в работе. Так, рутинные процедуры перезапуска или настройки займут у вас всего несколько секунд.
- Постоянство/Неизменность: одно из главных достоинств, позволяющих избежать проблем в перспективе разработки, так как каждый контейнер не позволяет обновлять отдельные компоненты. Вам придется только заново их устанавливать, удаляя устаревшие. При кажущейся сложности процесса, на самом деле, это лишь ускоряет работу.
Дополнительные возможности
А теперь разберем еще ряд интересных функций, которые позволяют взглянуть на разработку и управление инфраструктурой под иным углом.
Процесс оркестрации
Как бы вы не старались, виртуальную машину очень тяжело поддерживать в рабочем состоянии длительное время. Будто, она начинает жить по-своему. С помощью метода IoC вы можете избавиться от этого, так как на помощь придет система контроля версий.
IoC можно сопоставить с наблюдателем, который следит за состоянием вашей системы, и приводит все в изначально требуемый вид, если какой-либо из элементов начал вести себя не так. За счет этого инструмента, ваша команда сможет описывать все изменения и проводить более эффективную модернизацию в будущем.
Возможность масштабирования
Помимо оркестрации, вы можете подключить и горизонтальное масштабирование. То есть, количество контейнеров, необходимое для работы, будет увеличиваться ровно в том количестве, в каком вам это нужно, распределяя ресурсы системы более эффективно.
Как использовать контейнер для других циклов разработки ПО
Основные преимущества контейнеров проявляются и на различных этапах разработки.
- Процесс разработки: В первую очередь, вы ускорите старт этого процесса. Docker очень легко настраивается и позволяет не отвлекаться от основной задачи.
- Процесс отладки: команда docker pull позволяет моментально проинспектировать интересующий вас элемент контейнера.
- Процесс тестирования: контейнер можно отправить на инспекцию целиком, чтобы протестировать его работу со всеми элементами.
- Процесс доставки: с помощью доступных инструментов, вам понадобиться провести сборку лишь раз.
Continuous Delivery
А теперь поговорим о самой реализации. Начнем работу следующим решением:
Здесь тоже все делится на три основных этапа:
- Сборка проекта
- Процесс доставки
- Запуск проекта
Еще один взгляд на реализацию:
Итак, начнем.
Docker
Здесь все просто: запускаем Docker на любой удобной для вас ОС. Мы используем Linux.
Docker Registry
Подходим к запуску нового контейнера. Это понадобится, чтобы реализовать контроль образов и иметь полное управление над сервером, где они хранятся. Также, это упрощает интеграцию контейнеров в процессе разработки.
Docker Registry и GitLab
Теперь подключаем Docker Registry к GitLab. Для этого используем на фирменной утилите Docker HTTPS, а затем интегрируем сам GitLab. Нам было достаточно подключить сертификат по пути /etc/gitlab/ssl и добавить несколько строчек кода в /etc/gitlab/gitlab.rb:
registry_external_url ‘https://docker.domain.com’
gitlab_rails [‘registry_api_url’] = «https://docker.domain.com»
Заметьте, что теперь вам откроется раздел Registry со всеми подробными инструкциями.
Домен
Нам необходимо создать образ под все отдельно взятые ветки, чтобы синхронизировать элементы между собой и публиковать обновления в Docker Registry. Также, можно разместить версии по разным адресам. Чтобы это реализовать, нужно настроить перенаправление запросов к основному домену docker.domain.com.
Nginx
Теперь нам пригодится Nginx, который сможет осуществить перенаправление на поддомены при отправке запроса.
GUI Инструменты
Для тех, кто предпочитает использовать графический интерфейс, будет полезен такой инструмент, как Rancher. Вот как он выглядит:
В ином случае, под рукой всегда есть командная строка.
GitLab runner
Это решение понадобится для управления скриптами, которые так или иначе будут встречаться при использовании дополнительных серверов. Для развертывания, используйте executor Shell вместо Docker.
Настройка Continuous Delivery
После сборки, приступаем непосредственно к настройке.
Сборка
Соберем образ, используя gitlab-ci.yml. Все файлы стоит хранить на том же сервере, чтобы обезопасить систему от взлома.
GitLab.xml
Этот файл состоит из коллбэков для CD. По сути, она позволит проводить тестирования без дополнительных обращений и содержит основные коды для GitHub. Вы можете использовать и другой вариант реализации.
iris.key
В данном файле содержится ключ лицензии, который загружается для самой сборки. Его можно хранить и в другом месте, но только не в репозитории.
pwd.txt
Здесь вы найдете пароль, который также не стоит размещать в репозитории.
load_ci.script
Файл со скриптом, позволяющий подключить аутентификацию для InterSystems IRIS, подгрузить файл GitLab.xml и инициализировать настройку коллбэков, после чего запустится основной код:
gitlab-ci.yml
Настроим непрерывную доставку:
Теперь реализуем Docker Image:
Обратите внимание, что под $CI_COMMIT_REF_NAME мы подразумеваем название самой ветки.
Dockerfile
Создадим Dockerfile, который используется для предыдущего процесса:
Запуск
Запускаем сам образ. Перед этим вы можете удалить ненужные контейнеры:
А теперь запускаем новый контейнер-окружение:
Отметим, что Nginx, размещенный в отдельном контейнере, самостоятельно будет перенаправлять поступающие запросы, используя VIRTUAL_HOST.
Отдельные данные нужно держать в InterSystems IRIS. Это реализуется с помощью следующей конфигурации:
- Реализуем iris.cpf как основной файл.
- Размещаем приложения в /csp.
- Размещаем настройки Apache в /httpd/httpd.conf
- Создаем /mgr, куда размещаем базы данных IRISSYS, IRISTEMP, IRISAUDIT, IRIS, USER, файл IRIS.WIJ. Также перемещаем журналы в /journal хранящую журналы, временные файлы в /temp, а логи в messages.log, journal.log, SystemMonitor.log.
Вот что должно получиться в итоге:
Теперь нам понадобится еще одна БД с маппингом области приложения. То есть, используем %Installer, чтобы создать ее и загрузить туда код. Затем создаем маппинг в области пользователя и выполняем остальные настройки:
Тестирование
Запускаем процесс тестирования:
Процесс доставки
Осуществляем публикацию:
Образ доступен на GitHub:
