Скрипт развертывания против Rultor

Когда я объясняю, как Rultor автоматизирует процессы развертывания / выпуска, очень часто я слышу что-то вроде:

Но у меня уже есть скрипт, который развертывает все автоматически.

Этот ответ очень распространен, поэтому я решил обобщить три основных аргумента для автоматизированных процессов развертывания / выпуска Rultor в одной статье:

1. изолированные док-контейнеры,
2. видимость журналов и
3. безопасность учетных данных.

Прочтите о них и посмотрите, что Rultor дает вам поверх существующих сценариев развертывания.

Чарли и Шоколадная Фабрика (2005) Тимом Бертоном

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

Изолированные Docker контейнеры

Первое преимущество, которое вы получаете, когда начинаете вызывать скрипты развертывания из 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 и настроить их. Только после этого я могу развернуть это незначительное исправление.

Это раздражает, если не сказать больше.

Докер дает мне возможность автоматизировать все это вместе. Мой существующий сценарий развертывания получит преамбулу, которая установит и настроит все необходимые пакеты, связанные с PHP, в чистом контейнере Ubuntu. Эта преамбула будет выполняться при каждом запуске моего сценария развертывания внутри контейнера Docker. Например, это может выглядеть так:

Мой сценарий развертывания выглядел так до того, как я начал использовать Rultor:

Всего две строчки. Первый — это полный цикл юнит-тестов. Второй — развертывание FTP на производственном сервере. Очень простой. Но этот скрипт будет работать, только если установлены PHP 5.3, MySQL, phing, xdebug, phpcs и phpunit. Опять же, это большая работа по их установке и настройке каждый раз, когда я обновляю MacOS или меняю ноутбук.

Нет необходимости говорить, что если / когда кто-то присоединится к проекту и попытается запустить мои сценарии, ему / ей придется снова выполнить эту предустановочную работу.

Итак, вот новый скрипт, который я сейчас использую. Он выполняется внутри нового контейнера Docker каждый раз:

Очевидно, что запуск этого скрипта на моем MacBook (без виртуализации) вызовет много проблем. Ну, у меня даже нет apt-get сюда!

Таким образом, первое преимущество, которое дает вам Rultor, — это изоляция сценария развертывания в его собственной виртуальной среде. У нас это в основном благодаря Докеру.

Видимость журналов

Традиционно мы храним сценарии развертывания в некотором каталоге ~/deploy и запускаем их с волшебным набором параметров. В небольшом проекте вы делаете это самостоятельно, и этот каталог находится на вашем ноутбуке. В более крупном проекте есть сервер «развертывания», который имеет этот магический каталог с набором сценариев, которые могут быть выполнены только несколькими доверенными старшими разработчиками. Я видел эту установку много раз.

Самая большая проблема здесь — отслеживаемость. Почти невозможно определить, кто и что развернул, и почему не удалось выполнить какое-то конкретное развертывание. Старшие гуру развертывания просто SSH к серверу и запускают эти магические сценарии с магическими параметрами. Журналы обычно теряются, а отслеживание проблем очень сложно или невозможно.

Рултор предлагает что-то другое. С Rultor больше нет SSH-доступа к сценариям развертывания. Все сценарии остаются в .rultor.yml конфигурации .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 свой db.ini с помощью ключа Rultor GPG и безбоязненно db.ini.asc в хранилище. Никто не сможет открыть и прочитать этот файл, кроме самого сервера Rultor, непосредственно перед запуском сценария развертывания.

Таким образом, третье преимущество Rultor по сравнению с автономным сценарием развертывания — надлежащая защита конфиденциальных данных.

Похожие сообщения

Вы также можете найти эти сообщения интересными:

• Как опубликовать в Rubygems, в один клик
• Как выполнить развертывание в CloudBees в один клик
• Как выпустить в Maven Central, в один клик
• Рултор + Трэвис
• Каждая сборка в своем собственном Docker-контейнере