Мы создали инструмент, который интегрирует Docker и Maven для того, чтобы помочь сотням наших разработчиков управлять сложными средами разработки, состоящими из сотен сервисов, при этом прилагая минимум усилий. Это история о том, как сумасшедшая идея стала реальностью. Это история создания Carnotzet.
Все началось около пяти лет назад (прим. дата публикации 3 Августа 2017), Swissquote быстро рос и развивался. На тот момент у нас было около 70 разработчиков, работающих на больших (прим. монолитных) Java проектах, требующих от каждого из них тратить от 1 до 2-х дней, чтобы настроить запуск проекта локально. Мы ненавидим тратить время на повторяющиеся задачи! Итак, было принято решение усовершенствовать этот процесс путем использования Vagrant и Chef для автоматизации развертывания нашей локальной среды разработки. Этим было положено начало нашего первого проекта Sandbox (Песочница, прим.)
Мы хотели бы делиться легкими, воспроизводимыми, изолированными и портируемыми средами разработки и тестированияКакое-то время, все было гладко. Разработчики могли просто скачать проект, выполнить “vagrant up” и приступать к работе. Мы использовали этот подход около двух лет и были вполне довольны.
Впоследствии, работать над этими большими приложениями становилось все сложнее ввиду того, что бизнес логика становилась более сложной (white-labeling нашей трейдинговой платформы). И мы решили сделать то, что большинство организаций сделали еще в 2014: разбить логику на микросервисы.
Все шло хорошо, и к 2016 году у нас было около 150 (микро, прим.) сервисов в продакшене. Но Chef скрипты, используемые для конфигурации виртуальных машин, разрослись, и вышли из под контроля. Среды разработки стали значительно сложнее для некоторых приложений с около 30-ю зависимостями. Также мы выяснили, что знание Chef не входило в стандартный набор скилов наших разработчиков. По этой причине многие люди просто делали так, чтобы скрипт работал, временами, копируя плохие примеры. В попытках не сломать конфигурацию для других команд, они создавали долгоживущие бранчи для собственных командных нужд, и, в результате, код конфигурации среды разработки больше не был общедоступным.
Мы должны были это исправить.
Были идентифицировать следующие слабые стороны нашего “sandbox”:
- Необходимость знать Chef. И для существующих разработчиков, и для новичков изучение этого фреймворка было достаточно дорогим удовольствием.
Также это было излишним только для среды разработки/тестирования. - Не было способа для легкой абстракции/композиции или повторного использования части конфигурации среды. Это приводило к тому, что люди должны были вникнуть во все детали и нюансы конфигурации зависимостей их проектов, которые обычно поддерживались другими командами. Это приводило к разногласиям и ненужному взаимодействию между командами.
Для того, чтобы исправить первый пункт было решено перейти к использованию Docker. Он имеет меньший порог вхождения, а также дает другие преимущества, такие как стандартизация, поддержка PaaS и более простое развертывание на разных средах.
Мы так же рассматривали использование только docker-compose. Он выглядел очень многообещающим, но несмотря на его название, ему не хватало таких вещей, как возможность композиции, и, вместе с тем, абстракции и повторного использования. Именно тех аспектов, которые нам были нужны. Мы мечтали иметь возможность взяв существующую среду разработки/тестирования, добавить к ней один сервис, и опционально переопределить часть его конфигурации. Мы хотели добиться этого без необходимости копировать конфигурацию добавляемого сервиса или вникать в детали транзитивных зависимостей и их конфигурации.
Именно тогда у нас возникла эта идея: “Что если мы возьмем Maven, систему управления зависимостями, которую мы используем для сборки наших java приложений, и начнем использовать ее же для сборки наших сред?”. Это позволило бы нам абстрагировать наши транзитивные зависимости, упаковывать конфигурации, создавать их версии и переиспользовать. Также не будет необходимости изучать новую систему управления зависимостями.
Спустя некоторое количество попыток, мы пришли к следующему решению:
- Каждый Maven артефакт представляет полностью функциональную среду, которая может быть использована как зависимость в других средах. (минимальная среда может быть представлена одним сервисом, например, базой данных)
- JAR файлы содержат конфигураци. Переменные среды, конфигурационные файлы приложения, имя Docker образа, и т.д.
- Эта конфигурация может быть переопределена в модулях, находящейся выше по иерархии зависимостей, если это необходимо.
- Java-библиотека может поднять полную среду (используя docker-compose под капотом) из одного Maven модуля (GAV или pom.xml)
Maven дает возможность распространять и версионировать эти артефакты (“environment artifacts”) и мы можем легко разделить исходный код между командами. Процесс стал проще и разработчики начали использовать модули других команд. А также создавать и поддерживать собственные.
Как бонус, все инструменты, облегчающие работу с Maven, могут быть использованы и тут. Как пример, граф зависимостей, сгенерированный с помощью IntelliJ IDEA, теперь показывает нам схему архитектуры взаимодействия наших зависимостей:)
Архитектура примера voting application из docker-compose
В то же время, были некоторые трудности внедрения, такие как заставить все команды упаковывать приложения с помощью Docker (докеризировать) и упаковывать конфигурации в отдельные Maven модули. По общему мнению, стало проще импортировать приложения других команд и поддерживать сложные среды разработки.
Мы начали работать в этом направлении около года назад, и сейчас у нас около 200 таких модулей, используемых для разработки и тестирования. Мы пришли к выводу, что эта библиотека также отлично подходит для управления временной средой для end-to-end тестирования на нашей CI платформе.
В данный момент мы изучаем как можно переиспользовать эту технологию для управления нашими UAT/интеграционными средам, запуская контейнеры в Kubernetes вместо docker-compose и обеспечить таким образом, непрерывные обновления (rolling-updates) и эластичные вычисления (computing elasticity) на значительно больших средах.
Надеюсь, Вы будете рады узнать, что наш проект был открыт под лицензией Apache 2.0 и доступен на Github: github.com/swissquote/carnotzet
Пользуйтесь :)
