The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Когда я объясняю, как Rultor автоматизирует процессы развертывания/релиза, очень часто я слышу что-то вроде:
Этот ответ очень распространен, поэтому я решил суммировать мои три основных аргумента в одной статье для автоматизированных процессов развертывания/выпуска в Rultor: 1) изолированные контейнеры Docker, 2) видимость журналов и 3) безопасность учетных данных.
Прочтите о них и посмотрите, что дает вам Rultor поверх ваших существующих сценариев развертывания.
Прежде чем мы приступим к аргументам, позвольте мне подчеркнуть, что Rultor - это полезный интерфейс для ваших собственных сценариев. Когда вы решаете автоматизировать развертывание с помощью Rultor, вы не выбрасываете ни один из ваших существующих сценариев. Вы просто обучаете Rultor, как их вызывать.
Первое преимущество, которое вы получите после того, как начнете вызывать свои сценарии развертывания из Rultor, - это использование Docker. Я уверен, что вы знаете, что такое Docker, но для тех, кто не знает - это менеджер виртуальных “машин” Linux. Это командный сценарий, который вызывается, когда вам нужно запустить какой-то сценарий в новой виртуальной машине (так называемом “контейнере”). Docker запускает контейнер почти мгновенно и выполняет ваш сценарий. Преимущество Docker заключается в том, что каждый контейнер является полностью изолированной средой Linux со своей собственной файловой системой, памятью, процессами и т. д.
Когда вы говорите Rultor’у запустить ваш сценарий развертывания, он запускает новый Docker контейнер и выполняет ваш сценарий там. Но в чем же преимущество, спросите вы?
Главное преимущество заключается в том, что контейнер уничтожается сразу после завершения вашего сценария. Это означает, что вы можете выполнять всю предварительную настройку внутри контейнера без какого-либо страха конфликта с вашей основной рабочей платформой. Позвольте мне привести пример.
Я разрабатываю на MacBook, где устанавливаю и удаляю пакеты, которые мне нужны для разработки. В то же время у меня есть проект, который для развертывания требует PHP 5.3, MySQL 5.6, Phing, PHPUnit, PHPCS и xdebug. Каждая версия MacOS должна быть настроена специально для запуска этих приложений, и это занимает много времени.
Я могу менять ноутбуки и версии MacOS, но проект остается тем же. Ему все равно требуется тот же набор пакетов для успешного выполнения сценария развертывания. И проект больше не находится в активной разработке. Мне просто не нужны эти пакеты для моей повседневной работы, так как я сейчас работаю больше с Java. Но когда мне нужно внести незначительное исправление в тот PHP-проект и развернуть его, мне приходится устанавливать все необходимые PHP-пакеты и настраивать их. Только после этого я могу развернуть это незначительное исправление.
Это просто раздражает.
Docker дает мне возможность автоматизировать все это вместе. Мой существующий сценарий развертывания получит преамбулу, которая установит и настроит все необходимые пакеты, связанные с PHP, в чистом контейнере Ubuntu. Эта преамбула будет выполняться при каждом запуске моего сценария развертывания, внутри Docker контейнера. Например, она может выглядеть так:
Мой сценарий развертывания выглядел так до того, как я начал использовать Rultor:
Всего две строки. Первая - это полная проверка модульных тестов. Вторая - развертывание через FTP на продакшн-сервере. Очень просто. Но этот скрипт будет работать только если установлены PHP 5.3, MySQL, Phing, xdebug, PHPCS и PHPUnit. Опять же, установка и настройка их каждый раз, когда я обновляю MacOS или меняю ноутбук, требует много работы.
Само собой разумеется, что если/когда кто-то присоединяется к проекту и пытается запустить мои скрипты, он/она должны снова выполнить эту предварительную установку.
Итак, вот новый скрипт, который я сейчас использую. Он выполняется внутри нового контейнера Docker каждый раз:
Очевидно, запуск этого скрипта на моем MacBook (без виртуализации) вызовет множество проблем. Впрочем, у меня даже нет apt-get здесь.
Таким образом, первое преимущество, которое предоставляет вам Rultor, - это изоляция вашего скрипта развертывания в собственной виртуальной среде. Мы обязаны этому в основном Docker.
Традиционно мы храним скрипты развёртывания в директории ~/deploy и запускаем их с помощью волшебных параметров. В небольших проектах вы делаете это самостоятельно, и эта директория находится на вашем собственном ноутбуке. В больших проектах есть “сервер развёртывания”, на котором находится эта волшебная директория со скриптами, которые могут выполнять только несколько доверенных старших разработчиков. Я видел такую настройку множество раз.
Самая большая проблема здесь - отслеживаемость. Почти невозможно выяснить, кто и что развернул и почему произошла конкретная ошибка развёртывания. Старшие гуру развёртывания просто подключаются к серверу через SSH и запускают эти волшебные скрипты с волшебными параметрами. Журналы обычно теряются, и проблемы с отслеживанием становятся очень сложными или даже невозможными.
Rultor предлагает нечто другое. С Rultor больше нет доступа по SSH к скриптам развёртывания. Все скрипты находятся в конфигурационном файле .rultor.yml, и вы запускаете их, отправляя сообщения в вашей системе отслеживания ошибок (например, GitHub, JIRA или Trac). Rultor выполняет скрипт и публикует его полный журнал прямо в вашем тикете. Журнал остаётся с вашим проектом навсегда. Вы всегда можете вернуться к тикету, с которым работали, и проверить, почему развёртывание не удалось и какие инструкции были фактически выполнены.
Например, посмотрите на этот тикет в GitHub, где я развёртывал новую версию самого Rultor и несколько раз ошибался: yegor256/rultor#563. Все мои неудачные попытки протоколируются. Я всегда могу вернуться к ним и изучить причины. Для большого проекта эта информация важна.
Таким образом, второе преимущество Rultor по сравнению с автономным скриптом развёртывания - видимость каждой операции.
Когда у вас есть пользовательский скрипт, находящийся на вашем ноутбуке или на тайном сервере для развертывания команды, ваши учетные данные для продукции остаются рядом с ними. Просто нет другого способа. Если ваше программное обеспечение работает с базой данных, оно должно знать данные для входа (имя пользователя, пароль, имя БД, номер порта и т. д.). Ну, в худшем случае, некоторые люди просто жестко кодируют эту информацию прямо в исходный код. Мы даже не собираемся обсуждать этот случай, насколько плохо это.
Но предположим, что вы отделяете данные для входа в БД от исходного кода. У вас будет что-то вроде файла db.properties или db.ini, который будет прикрепляться к приложению прямо перед развертыванием. Вы также можете хранить этот файл непосредственно на сервере продукции, что еще лучше, но не всегда возможно, особенно с развертыванием PaaS, например.
Аналогичная проблема существует с развертыванием артефактов в репозитории. Допустим, вы регулярно разворачиваете на RubyGems.org. В вашем ~/.gem/credentials будут содержаться ваш ключ API.
Таким образом, очень часто ваши скрипты для развертывания сопровождаются некоторыми файлами с конфиденциальной и защищенной информацией. И эти файлы имеют эту информацию в открытом формате. Никакого шифрования, никакой защиты. Просто имена пользователей, пароли, коды и токены в виде обычного текста.
Почему это плохо? Что ж, для одного разработчика с одним ноутбуком это не звучит как проблема. Хотя мне не нравится идея потери ноутбука где-то в аэропорту со всеми открытыми и готовыми к использованию учетными данными. Вы можете возразить, существуют инструменты защиты диска, такие как FileVault для MacOS или BestCrypt для Windows. Да, возможно.
Но давайте посмотрим, что происходит, когда у нас есть команда разработчиков, работающих вместе и совместно использующих скрипты развертывания и файлы с учетными данными. Как только вы предоставляете доступ к своим скриптам развертывания новому члену команды, вам нужно передать всю эту конфиденциальную информацию. Просто нет возможности обойти это. Чтобы использовать скрипты, ему/ей нужно иметь возможность открывать файлы с учетными данными.
Это проблема, если вам важна безопасность ваших данных.
Rultor решает эту проблему, предлагая дешифрование ваших конфиденциальных данных в режиме реального времени с помощью GPG, непосредственно перед использованием скриптов развертывания. В файле конфигурации .rultor.yml вы просто указываете:
Затем вы шифруете свой db.ini с помощью Rultor GPG-ключа и смело фиксируете db.ini.asc в репозитории. Никто не сможет открыть и прочитать этот файл, кроме самого сервера Rultor, непосредственно перед запуском сценария развертывания.
Таким образом, третье преимущество Rultor по сравнению с отдельным сценарием развертывания - это надежная безопасность конфиденциальных данных.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:04
