Перед контрольной сборкой любого продукта, будь то простое приложение, состоящее из 100-ни строчек и 10-ки файлов в одном контейнере, или будь то массивная система на кластере, включающий глубокую иерархию компонентов и множественные узлы, DevOps-разработчики обязаны сначала ознакомиться со всеми материалами, провести тестовые операции, написать инструкцию, и лишь после приступить к процессам конечной сборки и развёртки на рабочих машинах.
Идеальная первая итерация.
На моей практике, эти шаги и инструкции никто, увы, никогда не исполняет и даже не записывает. Постоянно самим надо разбираться во всём. Проводить глубокий анализ скриптов. Выстраивать логические связи между блоками. Систематизировать. Произвести в итоге 100 подходов, 10 приседов, 20 отжиманий, - убить драгоценное время на ненужный research.
Ибо DevOps считает, что комментировать не «царское дело», а лучше заниматься своей работой дальше.
Я же разработчик, а не технический писатель!
Давайте посмотрим на простой фрагмент кода в скрипте приложения:
Задача поставлена следующим образом: нужно добавить при установке системы новые глобальные переменные сервиса валидации.
Что мы делаем в первую очередь? Находим скрипт. Находим требуемый блок. Видим, что после создания директории с файлами переменных окружений env (от полного слова «Environment») идёт рекурсивное копирование. Хотя, я считаю, опция -r лишняя, так как мы копируем конкретные файлы в конкретную директорию.
Что нам нужно сделать? Добавить соответствующую строчку на подобие остальных. Выполнили. И можем компилировать и проверять deploy? Не так быстро.
Разумеется, не стоит забывать и проверять другие вхождения в проекте. Находим новый блок во втором скрипте.
В директории systemd в файле юнита нашей системы идёт указание глобальных переменных в блоке [Service], отвечающего за запуск служб и поддерживающий вызов интерпретаторов для исполнения пользовательских скриптов. Поле EnvironmentFile отвечает за файлы переменного окружения.
Если кратко сжать выше информацию, то при наличии файла в директории наша служба должна зафиксировать все глобальные переменные сервиса валидации.
Кстати, подобное проворачивал, когда настраивал подключение по WebDAV домашнего облака к директории на Linux Mint. Но об этом расскажу, пожалуй, в следующий раз.
Вернёмся к нашим баранам, как любил говорить начальник УМО на моей первой работе в медвузе.
Проверили все вхождения, где явно указываются глобальные переменные. И опять не конец решения задачи!
Помимо установки системы в проекте есть ещё скрипты, отвечающие за сценарий обновления с текущей версии до новой.
Разберем кратко команды скрипта.
Первые строки фиксируют абсолютные пути по соответствующим переменным. Далее проверяем целевую директорию устанавливаемого продукта prodname, и при отсутствии фиксируем значение в переменной. Также поступаем с сервером приложений Wildfly. А потом самое интересное:
- Проверяем условное название продукта prodnamepostfix2.product с переменной, где postfix2 - постфикс модуля системы.
- Создаём родительскую директорию переменных с опцией -p, не выдавая ошибок.
- Копируем файл переменных в директорию.
- Фиксируем права доступа с рекурсией.
- После 9-ой строчки добавляем путь до файла переменных в службу.
- Обновляем файл службы.
- Перезагружаем демон процесса systemd, чтобы он более не ссылался на старые файлы переменных.
Заметили подвох?! Наша система не монолитная, а разделена на два больших модуля, которые должны собираться и разворачиваться на разных рабочих стендах. Обычно используем виртуальные машины, но я дома использую старые железки на Core 2 Duo.
Мы ничего не забыли? Вы всё запомнили?! Если да, то пьём валерьянку, и снова двигаемся дальше.
Финишная прямая. Осталось не забыть вместо 197-ой строчки удалить 198-ую для скрипта internal_install.sh внутри другого файла. Это необходимо, ведь в начале разработки системы файлы инсталляции решили сделать общими для двух основных модулей, а только потом высекать из них лишнее на этапе сборки пакетов. А именно это я и забыл.
Никогда ничего не держите в голове!
При передаче на контрольную установку заказчику очень неожиданно и ожидаемо посыпался весь deploy. Благо я уже не паникёр. Запив валерьяну ромашковым чаем, внёс минорное исправление в новую hotfix-ветку. Запушил. Всё успешно собралось.
Поэтому не сбрасывайте со счетов обычные комментарии в коде, заметки, создавайте свою базу знаний, фрагменты в виде «сниппетов». Уделяйте хотя бы час в день написанию инструкций. Вам скажут спасибо в будущем и команда, и руководство, да и вы себе сами.
Документируйте, товарищи разрабы!