Self hosted что это

Network Software Solutions

Простыми словами — это сервер мессенджера, установленный внутри вашей компании.

Как устроены интернет-мессенджеры?

Любой популярный мессенджер — это, в первую очередь, программа для iPhone или Android-смартфона. Практически никто не задумывается, а как оно работает, ведь, чтобы отправить сообщение от одного пользователя другому, нужны две вещи:

Интернет: только через него происходит передача и приём данных.
Сервер: к нему ваше приложение подключается, на него отправляет сообщения и файлы и от него же получает входящие сообщения и звонки.

Схема очень утрирована, на самом деле всё гораздо сложнее (есть ещё третья сторона, Google или Apple со своими PUSH-сервисами, и четвёртая — сотовый оператор), но, если свести к минимуму деталей, то дело обстоит именно так.

Получается, если у вас нет интернета, но есть локальная сеть, например, WiFi — то Viber, Telegram, Skype и WhatsApp работать не будут.

Что хранят серверы WhatsApp, Telegram, Viber и Skype?

Вторая, и, самая важная часть — это сервер. Все серверы популярных публичных мессенджеров находятся в закрытых дата-центрах и принадлежат компаниям-разработчикам. Там же сохраняются все ваши сообщения, файлы, звонки, картинки и полный граф ваших контактов. И ещё куча другой мета-информации, типа географических перемещений, отметок на карте, где и когда были сделаны фотографии, кто и что на них изображено, рекламных профилей и бог знает чего, что захотелось хранить про вас владельцу мессенджера, чтобы показывать рекламу внутри мессенджера или где-то в другом месте. Как это делает, например, владелец WhatsApp, компания Meta (Facebook).

Эти серверы недоступны для контроля и проверки, как, например, open source проекты. Разработчики просто говорят: верьте нам, мы не читаем ваши сообщения, никому их не показываем и не продаём ваши личные данные. И если к нам придут ФСБ (серверы вайбера находятся в РФ) или АНБ (серверы WhatsApp в США), то, мы, конечно, как Павел Дуров, никому ничего гордо не скажем и не дадим. Ну, кроме террористов и плохих людей, конечно. Их мы обязательно сдадим кому следует. Ведь спецслужбы же только плохих людей ищут, а хороших не трогают и переписку их не читают.

И, конечно же, нас никогда и никто не взломает и в открытый доступ ничего про вас и вашу компанию не попадёт. Это злой сарказм, но утверждения разработчиков, как минимум — не очень правдивы. Потому что количество сливов уже исчисляется десятками и они будут продолжаться.

Как надёжно защитить переписку в чате от третьих лиц?

Адекватные люди, понимая риски, хотят, чтобы их данные хранились у них же в компании, а не у третьей стороны. В локальной сети или в приватном облаке — но под контролем. Не нужно пояснять, что софт, который обслуживает миллионы людей, не может быть простым и его нельзя просто взять и поставить каким-нибудь инсталлятором на свой Windows Server. Да и не нужен он для корпоративного использования малым и средним бизнесом. Сервера, способного обработать до 2-3 тысяч одновременных подключений хватит для 99.9% любых бизнесов и компаний.

Также свой сервер решает проблему утечки данных, когда человек увольняется из компании и забирает свой смартфон с собой. Учётная запись в корпоративном мессенджере просто блокируется. С телеграмом или вотсапом такой «фокус» не пройдёт, функции администрирования вам недоступны.

Так вот, сервер мессенджера, который устанавливается внутри вашей компании — и называется self-hosted.

Какой self-hosted корпоративный чат лучше использовать?

Что использовать — тут уже выбор за вами. Кому-то надо просто сообщениями кидаться, а кому-то — нужны видеозвонки и интеграция с Active Directory и Asterisk. И приложения для macOS и Linux. Как говорится, «аппетит приходит во время еды». Можно взять бесплатный OpenFire и прикручивать к нему сторонний софт для Android/iOS смартфонов. А можно поставить MyChat (бесплатный до 20 устройств онлайн), и горя не знать.

В любом случае, self-hosted решение — это правильный и осознанный выбор для владельца бизнеса, системного администратора и сотрудников любой компании.

Как перестать велосипедить или 4 self-hosted сервиса для начинающего СТО

Я знаю многое о велосипедах в Enterprise-разработке. Видел издали, катался на них, собирал сам, но наступают моменты, когда типичные задачи пора перевести на типичные решения. В статье расскажу о 4 self-hosted сервисах, которые освобождают уйму времени на действительно важные вещи.

Мы в «Искусство Автоматизации» занимаемся заказной разработкой MVP (мобильных приложений, веб-сервисов, чат-ботов) со средним сроком цикла разработки 2 месяца. Это срок, в который нужно уже запустить готовое решение для новых пользователей. Об общих подходах к стабильной разработке ИТ-продуктов рассказал в прошлой статье, а в этой статье расскажу про инструменты.

За 4 года ведения ИТ-продакшена ярко выделись следующие однотипные запросы к проекту:

показывать метрики, что происходит с проектом;
мониторить доступность сервисов;
шарить статичные файлы (отчеты, сборки);
интегрироваться с соседними сервисами.

Итак, переходим к самим сервисам.

Данные интересны всем. Почти все сервисы сохраняют / агрегируют сведения о нас. Наши проекты тоже не исключение. Типичные запросы на старте разработки: сколько пользователей сейчас в проекте (новых / активных), сколько сделано заказов, какие ресурсы проекта самые посещаемые etc.

Выбора становится два: либо пилить что-то кастомное, либо предоставить клиенту пульс-дашборд на готовом решении.

Вот уже два года в каждом нашем проекте мы используем BI-утилиту Metabase.

Вкратце о возможностях продукта:

подключение к почти любым источникам данных (SQL/noSQL)
уровень входа в продукт крайне низкий; собрать дашборд может менеджер, без привлечения программистов;
шеринг дашбордов и показателей по ссылке, встраиваемые фреймы.

Килл-фича, о которой мало кто говорит. Metabase можно использовать как API для доступа к вашей БД. Больше не нужно писать контроллеры, поднимаем Metabase, открываем консоль хрома, копируем запросы к бэкенду и используем их в своих проектах. И это все, не написав ни строчки кода.

Self-Hosted, или Kubernetes для богатых: почему самостоятельное развертывание кластера — не всегда способ сэкономить

Идея самостоятельно развернуть кластер Kubernetes на собственных серверах или в облаке выглядит привлекательной: кажется, что это дешевле, чем платить за Managed-решение от провайдера. На самом деле все не так однозначно: на практике можно обнаружить скрытые расходы и подводные камни.

При этом для крупных компаний Self-Hosted может быть вариантом, так как у них есть условно бесплатные ресурсы и штат специалистов для поддержки технологии, а иногда еще горячее желание построить и развивать свою платформу во что бы то ни стало. А вот с малым и средним бизнесом ситуация немного другая, решение нужно взвесить со всех сторон.

Я Дмитрий Лазаренко, директор по продукту облачной платформы Mail.ru Cloud Solutions (MCS). В статье расскажу, в чем особенности развертывания Self-Hosted-кластера Kubernetes и о чем нужно знать перед запуском.

Для старта понадобятся время, деньги и администраторы, разбирающиеся в Kubernetes

Первая статья расходов — на специалистов, которые умеют работать с этой системой и смогут обслуживать кластер. Это дорогие ребята, на рынке их немного, и нанять трудно.

Почему Kubernetes сильно увеличивает расходы на специалистов? Вроде бы развернуть кластер несложно, для этого есть официальная документация и инсталляторы, например Kubespray или Kubeadm. Однако если в компании есть инженер, который может прочитать строчку документации и разобраться, как поставить Kubernetes на серверы с помощью одной команды, это еще не все, этим его работа не ограничится.

В реальности развернуть кластер только половина дела. В таком виде он будет работать до первой проблемы, которая неизбежно возникнет через неделю или месяц. Например, перестанут создаваться поды из-за неверной конфигурации ресурсов на controller-manager. Или кластер начнет работать нестабильно из-за проблем с дисками у etcd. Или запущенные СronJob из-за ошибок controller-manager начнут бесконечно плодить новые поды. Или в кластере будут возникать сетевые ошибки из-за неправильного выбора конфигурации DNS.

В общем, проблем может быть много, поэтому нужен отдельный человек, знающий, как развернуть кластер, как дебажить, как запускать приложения в производственной среде.

Кроме того, вместе с Kubernetes в компании появляются новые потребности, например мониторинг для выявления ошибок, система хранения данных, сбор логов. Кластер нужно развивать, чтобы получить от технологии ожидаемый профит. Это требует времени, поэтому даже опытному администратору не получится выделить неделю для настройки кластера и какие-то часы для администрирования.

Скорее всего, понадобится человек на фултайм, который будет заниматься только Kubernetes, поддержкой и развитием кластера. В большой компании может родиться отдел для поддержки инфраструктуры.

Конечно, если запускать Kubernetes только ради деплоя контейнеров, то можно не разбираться и не развивать кластер. Но тогда возникает вопрос: зачем вам Kubernetes? Можно взять более простой в настройке и поддержке инструмент, тот же Docker Swarm. Если вы хотите от Kubernetes что-то простое, просто его не используйте. Нет смысла тратить время на развертывание кластера лишь ради запуска простого кода. Эта технология предназначена для проектов, где постоянно идет разработка, часто запускаются новые релизы и нужно выдерживать требования HighLoad.

По этой причине Self-Hosted Kubernetes в большинстве случаев могут успешно запустить только крупные компании, где есть возможность выделить сотрудников для обслуживания кластера и нет потребности экономить ресурсы.

Кроме того, самостоятельное развертывание кластера — дело небыстрое. Если понадобится запустить кластер в короткие сроки для проекта или тестовых сред, то на Self-Hosted это не выйдет: развертывание займет несколько часов, а то и недель. К этому стоит быть готовыми. Для сравнения: в облаке вы запустите кластер KaaS за 10 минут и сможете сразу его использовать, но это получается потому, что над инфраструктурной частью уже заранее поработали специалисты провайдера.

Kubernetes требует прокачки: он не работает сам по себе

Как я уже говорил выше, Kubernetes — отдельная экосистема, которой нужно заниматься и подключать к ней дополнительные инструменты. Если брать Self-Hosted, то все это придется делать самостоятельно.

Все инструменты, дополняющие Kubernetes, — Open Source-решения, которые нужно настраивать. В кластер потребуется установить систему мониторинга, реализовать балансировку нагрузки, сбор и хранение логов, настройки безопасности и авторизации пользователей, сети и многое другое.

Например, понадобится мониторить и сам кластер, и приложения в нем. Причем стандартного мониторинга через Zabbix вам не хватит, потребуется специфический — Prometheus или Telegraph.

С логами аналогичная ситуация: из коробки вы получите только историю логов для уже запущенных приложений, при передеплое она исчезнет. Вручную собирать логи с Kubernetes не получится, нужно подключать сборщики логов вроде Fluentd и систему хранения, например Elasticsearch или Loki. Отдельно придется заниматься балансировкой нагрузки: понадобится отказоустойчивый балансер вроде MetalLB.

Системы хранения для Self-Hosted Kubernetes — еще одна головная боль

Kubernetes изначально разработан для Stateless-приложений — они ничего не хранят внутри контейнеров. При работе со Stateful-приложениями, хранящими данные, встает вопрос подключения внешних хранилищ.

Самый простой вариант, к которому часто прибегают, — поднять один NFS-сервер, но это решение для бедных: оно не обеспечит высокую доступность и сохранность данных. Если в медленный и ненадежный NFS будут ходить продакшен-сервисы с важными данными, могут возникнуть большие проблемы.

Для нормальной работы приложения без изменения его логики понадобятся Persistent Volumes — хранилища, связанные с подами. Они подключаются внутрь контейнеров как локальные директории, позволяя приложению хранить данные «под собой». Среди рабочих вариантов — CephFS, Glusterfs, FC (Fiber Channel), полный список СХД можно посмотреть в официальной документации.

Интеграция Kubernetes c Persistent Volumes — нетривиальная задача. Чтобы развернуть тот же Ceph, недостаточно взять мануал с Хабра и выполнить ряд команд. Плюс в дальнейшем СХД должен кто-то заниматься — опять нужен отдельный инженер, а то и несколько.

Если же Self-Hosted-кластер развернут не на железе, а на виртуальных машинах в облаке, то все немного проще — собственный кластер Ceph поднимать не нужно. Можно взять кластер хранилища у провайдера и научить его работать с кластером K8s, если провайдер готов предоставить вам API к своей системе хранения данных, что есть не везде. Писать интеграцию при этом придется самостоятельно.

Правда, у провайдеров, предоставляющих IaaS, можно арендовать объектное хранилище или облачную СУБД, но только если логика приложения позволяет их использовать. А в Managed-решениях Kubernetes уже «из коробки» есть интегрированные Persistent Volumes.

Отказоустойчивость кластера — отдельная проблема

С Kubernetes проще обеспечить отказоустойчивость приложений, однако потребуется еще и реализовать отказоустойчивость кластера.

В Kubernetes есть мастер-нода, непосредственно управляющая кластером и содержащая его конфигурацию, метаданные и статусы объектов Kubernetes. Отказоустойчивый кластер включает три мастер-ноды, отдельные от самого кластера и дублирующие друг друга. Каждая нода — отдельный сервер или виртуальная машина, их не могут использовать бизнес-приложения. То есть их нужно отдельно подключать и обслуживать либо оплачивать аренду в облаке.

Это создает сложности для малого бизнеса: раньше для всех приложений требовалось всего два сервера, а с Kubernetes только ради отказоустойчивости нужно три дополнительных сервера.

Также в кластере Kubernetes есть прекрасная фича — встроенный механизм самовосстановления. Если одна из нод выходит из строя, то все процессы, ранее работающие на этой ноде, автоматически перезапускаются на других нодах кластера. Вот только чтобы это произошло, на остальных нодах нужен резерв по ресурсам. И его нельзя ничем занимать, иначе приложения не смогут переехать в случае проблем.

Резерв зависит от того, какое количество вышедших из строя нод вероятно в вашем случае:

Если у вас одна стойка с серверами в одном дата-центре, то одномоментно, скорее всего, выйдет из строя максимум одна нода на одном сервере, например из-за ошибок ОС. Значит, нужен резерв на одну ноду. Конечно, может сломаться стойка, но тут уже нужно резервирование не средствами Kubernetes.
Если у вас несколько стоек с серверами, то есть вероятность потери одной стойки, например из-за проблем со свичем, когда все серверы в ней станут недоступны. Значит, нужен резерв в размере количества серверов в одной стойке.
Если у вас несколько дата-центров, то в каждом нужно держать резерв по размеру другого дата-центра, чтобы приложения работали в случае его выхода из строя.

Если проще, то это выглядит так: когда в кластере 10 нод и вы хотите без проблем пережить потерю одной ноды, то вам потребуется 10-процентный запас ресурсов. Если же приложения должны работать даже при потере 50% кластера, значит, на всех нодах нужен запас в 50%.

При этом лучше, если ноды в кластере небольшие по объему, но их много. Допустим, у вас есть пул ресурсов — 100 ГБ оперативной памяти и 100 ядер CPU. Такой объем позволяет запустить 10 виртуалок и 10 нод кластера Kubernetes. И в случае выхода из строя одной ноды вы теряете только 10% кластера.

На железных серверах такую конфигурацию не создашь. Например, используя 300 ГБ оперативной памяти и 50 ядер CPU, вы развернете всего 2–3 ноды кластера. И в случае выхода из строя одной ноды рискуете сразу потерять 30–50% кластера.

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

Автомасштабирование кластера — нетривиальная задача

Чтобы кластер всегда был готов к любой нагрузке и новые ноды подключались и отключались по необходимости, нужно реализовать автомасштабирование. То есть сделать так, чтобы ваши приложения автоматически получали нужные ресурсы в необходимом объеме.

Автоскейлинг приложений в кластере возможен на любой инфраструктуре — это делается средствами Kubernetes. А вот автоскейлинг кластера, который позволяет автоматически подключать и отключать ноды при изменении нагрузки, на Bare Metal реализуется только покупкой дополнительных серверов. Значит, заказываем их и ждем — сразу масштабироваться не выйдет.

Плюс если мы говорим о Self-Hosted на Bare Metal, то все серверы, необходимые для работы приложений на случай нагрузки, придется держать в рабочем состоянии и постоянно за них платить.

Если Self-Hosted-кластер развернут на IaaS, то схема похожая: инженер добавляет новую виртуальную машину и вносит ее в кластер. Другой вариант — взять API провайдера, если он его предоставляет, подключить через него кластер Kubernetes, научить его запускать для себя новые серверы и так реализовать автомасштабирование. Но потребуется разрабатывать отдельное решение — это сложная задача, предполагающая высокий уровень экспертности в Kubernetes и облаках.

Кроме того, для быстрого масштабирования Self-Hosted-кластера на IaaS придется резервировать нужное количество ресурсов провайдера и создавать из них новые виртуальные машины по мере надобности. И за эти зарезервированные ресурсы придется платить: практика брать плату за выключенные ресурсы бывает у реселлеров VMware. На нашей платформе в случае отключенных ВМ вы не платите за ресурсы, только за диски. В некоторых Managed-решениях автоскейлинг включается по кнопке, уточните эту возможность у вашего провайдера.

Подводные камни Self-Hosted Kubernetes

Для самостоятельной эксплуатации кластера нужен специалист на фултайм, который хорошо знает технологию и понимает, как все работает внутри Kubernetes.
В кластере потребуется настроить мониторинг, сбор логов, балансировку нагрузки и многое другое.
Отдельная проблема — развернуть и интегрировать с кластером систему хранения данных.
Чтобы обеспечить отказоустойчивость кластера, потребуются дополнительные серверы или виртуалки — это дополнительные затраты.
Для масштабирования кластера под нагрузкой нужен запас серверов или виртуалок — это еще одна статья дополнительных расходов.

Рассчитывайте ваши возможности при старте проекта. То, какие ресурсы есть у вашей компании, ваш бэкграунд, навыки и другие детали сильно влияют на выбор решения, насколько вам будет выгодно разворачивать Kubernetes самостоятельно или лучше это сделать в облаке с помощью готового сервиса. И не забываем главный вопрос всего Kubernetes: нужна ли вообще эта технология на вашем проекте, как и для чего вы собираетесь ее использовать?

Тут можно почитать, как устроен наш Kubernetes aaS на платформе Mail.ru Cloud Solutions: что у него под капотом и что в него еще входит, кроме собственно Kubernetes.

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

vk cloud solutions
vk cloud
mail.ru cloud solutions
kubernetes
контейнеризация
оркестрация
сисадминство

Блог компании VK
Системное администрирование
Облачные вычисления
DevOps
Kubernetes

Опыт использования self-hosted continuous integration систем

Сложно представить современную разработку без Continuous Integration. Многие компании выпускают по нескольку релизов в день и прогоняют тысячи тестов. Со времен Jenkins и Travis CI на рынке появилось много самых разнообразных инструментов. Большинство из них работают по модели SaaS — вы платите фиксированную плату за использование сервиса, или за количество пользователей.

Но использование hosted платформ не всегда возможно, например, если нельзя передавать код приложения, или не хочется зависеть от внешних сервисов. В таком случае выручают системы, которые можно установить на своих серверах (self-hosted). Бонусом вы имеете полный контроль над ресурсами и можете масштабировать их согласно вашим потребностям используя, к примеру, amazon ec2.

В этой статье представлен личный опыт использования нескольких opensource self-hosted continuous integration систем. Если вы использовали другие системы, расскажите об этом в комментариях.

Основные понятия

Основой любого CI является билд (build) — единичная сборка вашего проекта. Билд может собираться по различным триггерам — пуш в репозиторий, pull-request, по расписанию. Билд состоит из набора задач (jobs). Задачи могут выполняться как последовательно, так и параллельно. Набор задач задается перечислением всех задач или матрицей билда (build matrix) — характеристиками, по которым происходит разделение. Например, указанием версий языка программирования и переменных окружения — для каждой версии языка и каждого значения переменной будет создана своя задача.

В некоторых ci системах также есть конвейер задач (pipeline) — задачи объединяются в группы (stage), все задачи в текущей группе исполняются параллельно, следующая группа выполняется только если предыдущая группа завершилась успешно. Например, конвейер test — deploy: если все задачи в test завершились успешно, то можно запускать задачи из группы deploy.

Для эффективной работы ci важно наличие кэша — данных, которые используются для ускорения сборки. Это могут быть apt-пакеты, кэш npm, composer. Без кэша при запуске каждой задачи нужно будет заново скачивать и устанавливать все зависимости, что может занять времени больше, чем сам прогон тестов. Чем ближе расположен кэш к серверам, на которых выполняются задачи, тем лучше, например, если вы используете amazon ec2, то хорошим вариантом будет хранить кэш в amazon s3.

При выполнении билда могут генерироваться артефакты — результаты сборки, отчеты о чистоте кода, логи. CI-система, позволяющая просматривать и скачивать эти артефакты, существенно облегчает жизнь.

Если у вас большой проект с большим количеством одновременно запущенных задач, то вам не обойтись без масштабирования. Масштабирование бывает ручным и автоматическим. При ручном масштабировании вы сами запускаете и останавливаете runner-ы на свободных серверах. В случае автоматического масштабирования система сама решает, нужно ли создавать новые виртуальные машины и в каком количестве. Разные ci-системы поддерживают разных провайдеров — обычно это amazon, google compute, digital ocean и т.д.

Важным является то, как система запускает команды, указанные в конфигурации билда (executors). Есть несколько способов: непосредственное выполнение (на хосте, где запущен runner), выполнение в виртуальной машине, в docker-контейнере, через ssh. У каждого способа есть особенности, которые нужно учитывать при выборе ci-системы, например, при запуске задачи в docker-контейнере отсутствует сессия и терминал, из-за чего некоторые вещи не получится протестировать. А при выполнении на хосте не забывать о очистке ресурсов после окончания выполнения — удаления данных из бд, docker-образов и т.д.

Наконец, есть параметры, которые не критически важные, но делают работу с ci приятнее. Вывод лога — работает ли он в realtime режиме, или с каким-то интервалом? Можно ли прервать билд в случае проблем? Можно ли посмотреть конфигурацию билда и задачи?

Drone

Drone — система непрерывной интеграции, основанная на docker-контейнерах. Написана на языке Go. Текущая версия — 0.4, версия 0.5 находится в бете. В обзоре рассматривается версия 0.5.

Drone умеет работать с большим количеством git-репозиториев — GitHub, Bitbucket, Bitbucket Server, GitLab, Gogs. Конфигурация билдов настраивается в файле .drone.yml в корне репозитория.

Билд состоит из нескольких шагов, каждый шаг исполняется параллельно в отдельном docker-контейнере. Матрица билда задается за счет переменных окружения. Возможно использование сервис-контейнеров — например, если вы тестируете веб-приложение, которое работает с базой данных, то нужно задать docker-образ БД в секции services, и она автоматически будет доступна из build-контейнера. Можно использовать любые образы docker.

Drone состоит из drone server и drone agent. Drone server выполняет роль координатора, а один или несколько drone agent запускают билды. Масштабирование осуществляется за счет запуска дополнительных drone agent-ов. Возможности использовать облачные ресурсы для автозапуска агентов нет. Встроенной поддержки кэша не предусмотрено (есть сторонние плагины для загрузки и сохранения кэша на s3 хранилища).

Команды, указанные в билде, выполняются непосредственно в docker-контейнере интерпретатором sh, что создает проблемы, если нужно выполнять сложные команды с условной логикой.

Gitlab CI

Gitlab CI является частью проекта Gitlab — self-hosted аналога Github. Gitlab написан на ruby, а gitlab runner — на Go. Текущая версия gitlab — 8.15, gitlab runner — 1.9.

Поскольку Gitlab CI интегрирован с gitlab, то он использует только gitlab как репозиторий. Можно зеркалировать сторонние репозитории на gitlab, но на мой взгляд, это не очень удобно. Билд организован по принципу конвейера. Можно настраивать тип запуска задач — автоматически или вручную из веб-интерфейса.

Gitlab CI состоит из веб-интерфейса (координатора) и runner-ов. Координатор распределяет задачи по runner-ам, которые их выполняют. Есть большой выбор executors — shell, docker, docker-ssh, ssh, virtualbox, kubernetes. Лог билда не real-time — веб-интерфейс периодически опрашивает сервер, если появилась новая часть лога, то она добавляется в конец.

Имеется встроенная поддержка кэша, в качестве хранилища может использоваться любое s3-совместимое хранилище. Есть артефакты — можно просматривать отдельные файлы и скачивать артефакт целиком из веб-интерфейса.

Работа с облачными ресурсами организована с помощью docker mashine. При поступлении запроса на новый билд, если нет свободной машины, docker mashine создаст новую машину и запустит билд на ней. При этом образы, требуемые для билда, придется скачать заново, поэтому gitlab рекомендует поднять отдельный docker registry, который был бы в той же сети, что и провайдер docker mashine.

SimpleCI

SimpleCI — система непрерывной интеграции, которая была написана для максимально эффективного использования ресурсов. Frontend написан на php (Symfony3, es6), backend — на java. Текущая версия — 0.6, ведется активная разработка.

SimpleCI поддерживает github и gitlab репозитории. Билд, также, как и в gitlab, организован по принципу конвейера. Если все задачи в рамках одной стадии завершились успешно, то запускается следующая стадия.

Поддерживается работа с кэшэм. Кэш заливается в хранилище только, если в рамках задачи кэш-файлы изменились. Реализована работа с двумя типами хранилищ — s3-совместимым и google storage.

Билд выполняется путем запуска docker-контейнеров, подключения к build-контейнеру по ssh и запуску build-скрипта. Лог билда отображается в реальном времени (с помощью websockets и centrifugo).

Есть возможность автомасштабирования путем использования ресурсов облачных провайдеров (пока только google compute engine). При настройке масштабирования нужно указать snapshot, который будет использоваться при создании виртуальной машины. Это позволяет создать snapshot с необходимыми docker-образами, чтобы не загружать из каждый раз при создании новой машины. Поддержки артефактов пока нет.

Заключение

В обзоре представлено несколько self-hosted open source систем непрерывной интеграции. Кроме рассмотренных, также есть много hosted, коммерческих и открытых систем. Выбирая из всего многообразия CI-систем, обращайте внимание на то, что нужно вам, и тесты скажут вам спасибо.

Ссылки

Drone
Gitlab CI
SimpleCI
Jenkins
awersome ci — список ci систем, средств для тестирования и деплоя