Пару недель назад я посмотрела демонстрацию Waypoint— нового инструмента, который представила 15 октября 2020 года компания Hashicorp. Инструмента, который предназначен для создания легкого, интуитивного и настраиваемого под пользователя рабочего процесса сборки, развертывания и релиза.
Эта статья не будет ни учебным руководством, ни инструкцией по использованию продукта, поскольку официальная документация и обучающие материалы прекрасно разъясняют, как настраивать и использовать инструмент. В этой статье я объясню, почему, на мой взгляд, с философской точки зрения модель Waypoint перспективна и имеет большой потенциал.
Чем Waypoint не является
Наверное, будет проще в начале пояснить, чем Waypoint не является.
Waypoint не:
- автоматическая система сборки программ (как make, npm, maven и т.д.)
- диспетчер пакетов (как helm, pip и т.д.)
- система непрерывной интеграции (как Jenkins, GitHub Actions и т.д.)
- registry артефактов (как Artifactory, Docker Registry и т.д.)
- среда выполнения (как OCI images, Docker containers, buildpacks, машинный код, архивы и т.д.)
- кластерный оркестратор или кластерная платформа (как Kubernetes, EC2, EKS и т.д.)
Это ключевой момент, поскольку Waypoint в реальности работает в связке со всеми вышеупомянутыми технологиями, в то же время не являясь и не заменяя ни одну из них.
Что же такое Waypoint?
Согласно описанию производителя, Waypoint — это инструмент, призванный значительно упростить разработку и запуск сервисов. Пользователи могут запустить свои приложения с минимальными трудозатратами на любой облачной платформе, создавая декларативные настройки для развертывания и запуская несколько команд.
Разработчику не нужно делать каких-либо правок или писать дополнительную конфигурацию. Как говорится в документации:
Waypoint был построен для простоты использования. Больше не надо писать Dockerfiles, YAML и т.д.У нас есть дополнения для автоматического определения вашего языка, построения образа и развертывания. Да, вам придется немного настроить его, но мы сейчас говорим примерно о пятнадцати строках текста для одного инструмента в сравнении с сотнями строк в разных инструментах на разных языках программирования.
Лично я бы описала Waypoint как минималистичный, без жестких предписаний, широко кастомизируемый инструмент для построения и развертывания, который снимает наибольшую сложность цикла «разработка–тестирование–развертывание–релиз» в пользу уже имеющихся базовых инструментов и сервисов разработки/тестирования/развертывания, в то же время предлагая конечным пользователям униформный и декларативный интерфейс для описания процессов «разработка–тестирование–развертывание–релиз» в подходящей для упомянутых базовых инструментов манере. Проще говоря, это лучшее ПО для обеспечения связности инфраструктуры.
Довольно много слов, и изрядное их количество требует объяснения. Остаток статьи как раз будет посвящен расшифровке того, что все это значит.
Переосмысление схемы работы «разработка–тестирование–развертывание–выпуск»
Я использую термин «схема работы от разработки до релиза», а не непрерывная интеграция и развертывание программного обеспечения (CI/CD), потому что не каждая организация научилась массово использовать CI/CD, даже если все компании действительно «разрабатывают и выпускают» программное обеспечение с разной периодичностью.
Непрерывно или нет, все схемы работы «от разработки до релиза» традиционно состоят из различный типовых компонентов:
Разработка: включает в себя сборку исполняемых файлов и библиотек, содержащих изменения кода. Большая часть языков программирования имеют собственный набор системы сборки кода. Большинство вычислительных рабочих окружений имеют собственные поддерживаемые форматы артефактов, как Docker/OCI images, ELF binaries, ZIP archives, платформенно-ориентированные артефакты (как AWS Lambda Layers), и это далеко не полный перечень. Любая «схема работы» с комплексом инструментальных средств, которая имеет целью обслуживать максимально обширное сообщество разработчиков, вынуждена приспосабливаться к сборке кода и предпочтительного формата артефакта, по возможности используя уже существующие ориентированные на конкретный язык встроенные инструментальные средства.
Хранение артефактов:наличие артефактов создает потребность в их хранении. В то время как теоретически любое объектное хранилище может быть перепрофилировано в хранилище артефактов, специализированные репозитории артефактов предлагают несметное число функций, как, например, шифрование данных, сканирование на уязвимость, отказоустойчивость, удаление более старых артефактов, кеширование артефактов и другие. Попытки изобрести колесо с помощью других инструментов не особенно нужны. В данном случае существуют хорошо отлаженные продукты, которые берут на себя решение этой конкретной задачи.
Развертывание: чтобы начать обслуживать новый трафик, новые артефакты должны внедряться в эксплуатационную (или тестовую) среду. Часто для этого артефакты «устанавливаются» на сервера, где запускаются соответствующие исполняемые файлы. В своей карьере я работала с инструментами развертывания, которые охватывали весь спектр: начиная от простых развертываний на основе git (Heroku), до лабиринтообразных скриптов оболочки, до безагентных инструментов удаленного выполнения на основе ssh, как Fabric/Capistrano/Ansible, до систем, запускающих агентов на узлах, которые «следят» за новыми развертываниями, до (после 2015) сервисов кластерных оркестраторов, как Nomad или Kubernetes. Новому инструменту нецелесообразно заново изобретать платформу/runtime/механизмы развертывания, уже имеющиеся у поставщика облачных услуг, поскольку поставщики облачных услуг уже предоставляют собственные безапелляционные API специальные инструменты и рабочие процессы для развертывания кода.
Выпуск: я всегда верила, что нельзя отождествлять развертывание кода с его «релизом». Релиз кода включает в себя управление трафиком, обновление DNS или балансировщиков нагрузки, постепенное отключение существующих сервисов, канареечные и зелено-голубые развертывания и прочее. И здесь тоже у большинства платформ уже есть собственные безапелляционные API, программы настройки и парадигмы, чтобы этого достичь.
Hashicorp (я никак с ней не связана) с самого начала была компанией с особым сверхъестественным умением выпускать инфраструктурные проекты, соответствующие (за редким исключением) рынку. Это позволило компании процветать, не ввязываясь в схемы с повторным лицензированием, чем массово занимались другие компании, выпускающие инфраструктуры с открытым исходным кодом, а особенно с open-core.
Специалисты, идущие в ногу со временем и использующие продукты Hashicorp так же долго, как и я, возможно, заметят, что Waypoint — не первый заход Hashicorp в сферу развертывания или рабочих процессов. Одной из предыдущих попыток был проект Otto, который должен был стать «абстракцией высокого уровня для разработки и развертывания приложений». Atlas также был экспериментом для «предоставления интегрированных инструментов и общего рабочего пространства как для разработчиков, так и для операторов; от внедрения кода приложения до создания артефакта развертывания, конфигурирования инфраструктуры и в конечном итоге управления жизненным циклом приложения в процессе его работы».
Теперь, по прошествии времени, становится понятно, почему ни один из инструментов не справился и оба были в итоге свернуты или стали частью других предложений. На мой взгляд, и Otto, и Atlas должны были одни махом решить слишком много разношерстных задач. Хотя такой подход мог сработать в случае Consul, который может использоваться в качестве распределенного хранилища данных типа ключ-значение, сервиса распределенных блокировок, сервисной сетки, системы обнаружения сервисов и многого другого (и я за годы работы действительно использовала Consul для многих из этих разнообразных целей), «рабочий процесс разработчика» или даже «рабочий процесс развертывания», требующий использования полного набора инструментов Hashicorp, был не совсем подходящим продуктом для решения такой серьезной проблемы как «рабочий процесс», и особенно не в то время (начиная с 2015 года), когда индустрия видела невообразимый всплеск в количестве специализированных инструментов инфраструктуры, систем, платформ, API, парадигм и экосистем. Когда у пользователей есть выбор из множества вариантов, продуктам, нацеленным на «объединение» разрозненных проблем, пожалуй, труднее найти соответствие продукта и рынка без интеграции с широким спектром доступных решений.
Здесь напрашивается вопрос, чем же третья попытка одолеть эту проблемную задачу отличается от предыдущих?
Начнем с того, что Waypoint намного более узко сфокусирован, чем были Otto и Atlas за все время своего существования. Waypoint призван унифицировать опыт разработчика, не давая предписаний или обязуя пользователей прибегать к другим продуктам Hashicorp, таким как Vagrant, Terraform или Packer.
Во-вторых, складывается ощущение, что Waypoint перенял кое-что у Terraform. Подобно тому как Terraform успешно абстрагировался от различных облачных провайдеров, облачных API, платформ, систем и инструментов с открытым кодом, предоставил пользователям язык (HCL) для определения, настройки, обновления, поддержки и развития исходных конфигураций инфраструктуры и для интеграции, Waypoint стремится предоставить пользователям ориентированную на HCL декларативную спецификацию и простой CLI-интерфейс для управления и развития рабочего процесса «сборки и развертывания». Как и проводники в Terraform, так и плагины в Waypoint позволяют проводить интеграцию с внешними и API системами.
В-третьих, архитектура Waypoint настолько проста, что разработчик прототипа услуги может довести его до состояния готовности в кратчайшие сроки. Прощупывая почву, я использовала режим локального исполнения, чтобы запустить пробную версию сервиса на моем ноутбуке. Понятие «рабочие пространства» позволяет легко разворачивать один и тот же код в разных средах. Такие функции существенно ускоряют цикл «локальная сборка, локальное тестирование, развертывание на промежуточном этапе, развертывание в производственную среду» для разработчиков.
Наконец, несмотря на то, что доказательство универсальности идет вишенкой на торте, архитектура Waypoint теоретически достаточно гибка, чтобы быть масштабированной до службы целой команде инженеров (создав удаленный сервер Waypoint и удаленных раннеров).
Заключение
В настоящее время развертывание кода является нетривиальной задачей не в связи с недостатком API или систем, особенно хорошо адресующих частные проблемы. Это связано, скорее, с тем, сколько усилий требуется на соединение всех компонентов вместе во что-то пригодное для работы.
Некоторые из самых успешных инфраструктурных компаний недавнего времени были компаниями «клеевой инфраструктуры», чей основной продукт не был революционной технологией, но был соединяющей технологией, которая предлагала новаторский пользовательский интерфейс и феноменальный разработческий опыт.
Ни один из существующих инструментов в сфере развертывания не является тем, что я бы назвала инструментами «с обычного CD». В сущности, инструменты из разряда Spinnaker настолько сложны, что гарантируют потребность в обучающем курсе. Более того, вы можете возразить, что большому количеству компаний просто никогда не потребуется такой сложный инструмент для развертывания, как Spinnaker.
Для меня Waypoint — шаг в нужном направлении. Все еще рано загадывать, но я с радостью буду следить за развитием проекта в следующие 12–18 месяцев.
От редакции: приглашаем на курс Слёрма «CI/CD на примере Gitlab CI». Сейчас курс находится в разработке и его можно купить по цене предзаказа. Кроме того, вы сможете стать консультантом-тестером: получить ранний доступ к урокам, задать свои вопросы спикерам и повлиять на итоговую программу курса.
