Self hosted что это

Опыт использования 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 систем, средств для тестирования и деплоя

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

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

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

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

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

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

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

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

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

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

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

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

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 решение — это правильный и осознанный выбор для владельца бизнеса, системного администратора и сотрудников любой компании.

Пачка vs Self-host мессенджеры

Self-host мессенджеры — отличное решение, куда можно быстро перейти после блокировок Slack или MS-Teams. Но на длительной дистанции работать в них становится сложнее, а на поддержку open-source нужно тратить все больше и больше ресурсов. Пачка не уступает им по функционалу и сразу решает несколько самых больших проблем таких мессенджеров.

Записаться на демо →
Условная бесплатность, дорогая поддержка

Одна из главных причин, почему многие компании делают выбор в пользу open-source мессенджеров — это низкая стоимость. За саму программу не нужно платить, поэтому остаются траты только на сервера, куда установлен сервис. Но после начала работы в self-host мессенджере появляется много других трат: команда, которая занимается установкой и поддержкой решения, доработка функционала под свои запросы и т.д.

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

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

Добровольный отказ от развивающегося сервиса

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

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

Вся ответственность за проблемную работу сервиса на вас

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

При работе по договору в Пачке мы гарантируем SLA 99,9%, но такая доступность сервиса распространяется на всех наших пользователей. Убедиться же в ней можно по этой ссылке.

Нет поддержки для обычных пользователей

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

В Пачке поддержка отвечает на все обращения в течение 15-20 минут и она бесплатна. Также у нас есть большая база знаний, где мы собрали более 100 статей по тому, как работает наше решение.

Теги сотрудников

В Пачке есть мощный инструмент для администрирования — теги. С их помощью можно группировать людей по разным параметрам («команда_маркетинга», «офис_Москва» и тд.), а после использовать их для добавления в чаты. Чтобы пригласить сотрудников в новый чат, достаточно добавить в этот чат нужные теги и в нем автоматически появятся все юзеры, у кого они проставлены. Это работает и в обратную сторону: если в компанию приходит новый сотрудник, можно присвоить ему нужные теги и он сразу добавится во все нужные чаты.

Каждый может повлиять на развитие мессенджера

Каждый пользователь Пачки может оставить свой фидбек по работе мессенджера и мы обязательно к нему прислушаемся. Более того, мы формируем и приоритизируем развитие продукта, отталкиваясь от запросов пользователей. Такая гибкость возможна благодаря тому, что Пачка — фокусный продукт независимой компании и мы можем развивать сервис так, как будет лучше его пользователям.

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