Builder

Это платформа компоновщика в DINP, основная задача которой — преобразование предоставленных пользователем пакетов кода в образ Docker и отправка его в Docker Registry.

Концепция дизайна

• Платформа не занимается компиляцией; пользователи сами должны скомпилировать свой код, а затем передать его платформе.
• Независимо от того, какой язык программирования используется, конечный продукт всегда будет представлять собой один Docker-образ, который будет использоваться для нормализации.

Вопросы компиляции

Код пользователя должен быть развернут на PaaS-платформе. Для этого сначала необходимо передать этот код платформе. Но как это сделать? Через Git? Или напрямую загрузить? Будет ли это исходный код или уже скомпилированный? Интерпретируемые языки, конечно, не требуют компиляции, но что делать с компилируемыми языками, такими как Go или Java? Должны ли мы просить пользователей предоставить нам .go или .java файлы, чтобы мы могли скомпилировать их самостоятельно? Или же пользователи должны будут скомпилировать свои программы и передать нам готовый бинарник (.class файл)?Платформа находится на ранней стадии развития, поэтому мы хотим выполнять минимальное количество действий, чтобы минимизировать вероятность ошибок. По мере развития платформы можно будет добавлять новые возможности. Поэтому мы выбрали вариант, при котором пользователи передают нам уже скомпилированный код. Например, если это Java, то они могут передать нам WAR-файл; если это Go, то потребуется скомпилированный бинарник (скомпилированный для 64-битной Linux, так как платформа работает на 64-битной Linux).Некоторые PaaS-системы, такие как tsuru, требуют, чтобы пользователи загружали свой код в определенный репозиторий и в определенную ветку, после чего запускается скрипт сборки и развёртывания. Это выглядит хорошо, но такой подход довольно сложен и имеет множество проблем, поэтому пока оставим это на потом.

Далее следует вопрос о том, через какие методы код будет передан платформе. Мы поддерживаем два способа: прямую загрузку файла на странице и загрузку файла по HTTP-адресу, доступному для скачивания.

Использование Docker для нормализации пакетов

Код пользователя может быть написан на различных языках, таких как Java, PHP или Python. Пользователи предоставляют tar.gz-пакет, и наша задача — преобразовать его в docker-образ.

Наиболее простой способ реализации: dinp предоставляет базовый образ, содержащий только среду Ubuntu или CentOS. Пользователи должны обеспечивать зависимости runtime, такие как JDK, Tomcat и webapp для Java. Также требуется наличие запускаемого скрипта, такого как control-файла в корневой директории, который можно запустить командой ./control start. Если код пользователя написан на PHP, то необходим nginx, php-fpm и сам код. Этот способ слишком усложнен. Если это GoLang, можно использовать вышеописанный метод, так как GoLang статически компилируется и имеет мало зависимостей. Java, PHP, Python, Ruby — если заставишь пользователей делать так, они точно расплачутся...Можно создать различные базовые образы для разных языков программирования. Например, для Java можно создать базовый образ с заранее установленной JDK и Tomcat, чтобы пользователи могли просто загружать WAR-файлы. Для PHP можно создать базовый образ с заранее настроенными Nginx и php-fpm, чтобы пользователи могли загружать свои PHP-коды.

Да, это тот же подход, который используется в Builder платформе. Мы подготовили несколько базовых образов, позволяющих пользователям выбирать нужный им на странице. Выбор базового образа автоматически указывает нам на тип используемого кода (например, Java-приложение обязательно будет использовать Java-образ). Затем мы генерируем Dockerfile для различных типов приложений, объединяя код пользователя с базовым образом, что решает проблему!

Установка

Код доступен здесь. Это проект на GoLang, использует Beego framework, установка проста, как обычно для GoLang-проектов:

mkdir -p $GOPATH/src/github.com/dinp # Предполагается, что вы уже настроили GOROOT и GOPATH
cd $GOPATH/src/github.com/dinp
git clone https://github.com/dinp/builder.git
cd builder
go get ./...
go build
mv conf/app.conf.example conf/app.conf
# Измените conf/app.conf
./builder

Проект использует UIC как единую систему аутентификации, поэтому перед запуском тестов вам потребуется настроить UIC.Простое описание конфигураций в conf/app.conf:

• appname, httpport — ничего особенного
• runmode может принимать значения dev или prod, подробнее можно узнать в документации Beego
• Параметры с префиксом db относятся к конфигурации базы данных, скрипт инициализации базы данных находится в schema.sql
• tmpdir, logdir — это временные директории, объяснять нечего
• buildtimeout — время ожидания завершения сборки, если сборка не завершилась за этот период времени, она будет прервана, единицы измерения — минуты
• uicinternal, uicexternal — конфигурация UIC. Почему они разделены? Builder и UIC обычно находятся в одной внутренней сети, поэтому между ними используется внутренняя сеть, что отражено в uicinternal. Однако иногда внутренний адрес UIC недоступен для пользователя, поэтому при входе через SSO происходит переадресация на внешний адрес UIC
• registry — это приватный источник Docker, который можно использовать для создания Docker registry
• buildscript — это путь к скрипту, используемому внутри Builder, достаточно использовать значение по умолчанию
• tplmapping очень важен, это конфигурация base образа, если вы добавили новый base образ в registry, его следует также указать здесь, чтобы пользователи могли видеть его на странице
• token — это токен для взаимодействия с UIC, его следует настроить таким образом, чтобы он совпадал с токеном UICПри настройке конфигурации пользователи должны просматривать логи, что приводит к созданию точки отказа. В настоящее время эту проблему можно решить с помощью монтирования распределенной файловой системы.