Pull to refresh
46
0
Дмитрий Мельник @mitro

User

Send message
Одной статьи, где описывается весь процесс, нет. Собирал из разных источников и экспериментировал. Я планирую сделать публикацию, но позже.

Вот ссылка на проект, где реализован пайплайн gitlab.com/drim-consulting/public/devops/git-flow-ci-cd. Это проект для тренинга, который я на текущий момент готовлю. Там реализован автоматический деплой в рамках git flow, включая, как раз, динамический деплой review apps. Проект еще не полностью отполирован (в частности, не проработано версионирование), но он работает и демонстрирует связку технологий, примененную для CI/CD.

Если концептуально, то каждое окружение деплоится из helm chart в отдельный k8s namespace. Для формирования имен используется $CI_COMMIT_REF_SLUG — очищенное имя ветки, предоставляемое GitLab CI. Оно же используется для создания ingress с правилом роутинга по поддомену типа feature1.myapp.com. В каждом пространстве имен создается отдельный ingress, который потом используется для формирования общего набора правил nginx для роутинга по поддоменам.

Плюс используется концепция dynamic environments, позволяющая интегрировать развернутые окружения в GitLab UI. К примеру, можно прям со страницы с деталями merge request перейти на развернутое приложение. Также настроено автоматическое удаление приложения после удаления environment, которое автоматически происходит после удаления ветки.

Для выполнения jobs я использую shell executor. Изначально пробовал Docker executors, но потом наткнулся на проблему переиспользования слоев при сборке образов, и отложил эту задачу, чтобы не усложнять процесс на первом этапе. Образы собираются на машине с executors, потом пушатся в GitLab Container Registry. Креды для логина GitLab CI предоставляет в виде переменных окружения.

Если после изучения проекта останутся вопросы, пишите или здесь, или в личку, с удовольствием отвечу на них.
Есть опыт настройки деплоя review apps в GitLab CI — когда на каждую feature ветку динамически создается отдельный инстанс системы с изменениями из этой ветки. Тут k8s + helm хорошо помогли. Создали helm chart для системы, в процессе CI из него устанавливаем систему, указывая значения из контекста пайплайна (имя ветки и т.п.). Добавляем ingress с роутингом по поддомену (feature1.myapp.com) и всё работает. Конечно, другими средствами это тоже можно сделать, но с k8s это весьма элегантно и понятно получилось.
Для хранения данных k8s использует Persistent Volumes, которые через Persistent Volume Claims монтируются в контейнеры. Это абстракции. Непосредственно тип хранилища надо выбирать из списка поддерживаемых плагинов и настраивать руками. Вот список: kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes
Да, эта схема требует больше ресурсов. Каждый пуш в origin ведёт к запуску всего пайплайна, сборке образов, прогону тестов (если есть), обновлению приложения на окружении. Но железо/виртуалки сейчас недорогие, зачастую ради удобства процесса проще их докупить. Ну и схема с kubernetes хороша тем, что если веток станет слишком много, то просто добавляем узлов в кластер и всё, ничего больше донастраивать не надо. Kubernetes сам позаботиться от том, чтобы распределить контейнеры по узлам.
Еще полезная вещь — динамическое развертывание окружений из feature branches. То есть кто-то создал ветку, пушнул её в репозиторий и CI/CD автоматически развернул систему из этой ветки. Я сделал такое решение на основе GitLab Review Apps. Адресация происходит по поддомену с именем ветки. К примеру, если пушится ветка с названием new-cool-feature, приложение разворачивается по адресу new-cool-feature.example.com. Эта ссылка автоматически указывается в описании пул-реквеста. То есть, кроме ревью кода можно также производить ревью непосредственно работающего приложения. После удаления ветки окружение полностью удаляется.

Технически реализовал с помощью GitLab CI, Kubernetes и Helm. В исходниках лежит helm chart для разворачивания всей системы. При пуше изменений в ветку создается k8s namespace, если он еще не был создан. И потом происходит установка/обновление helm release. При удалении ветки и namespace и release удаляются.

В итоге команде стало очень удобно тестировать разрабатываемый функционал. Пишешь код, пушишь в ветку, ждешь 5 минут и можешь пользоваться приложением на окружении.
Я использовал GitLab Review Apps для решения подобной задачи. На каждую ветку создается динамическое окружение, которое отображается в общем списке окружений GitLab. Плюс ссылка указывается в данных пул-реквеста, что позволяет быстро посмотреть реализованный в ветке функционал. На текущий момент развертывание происходит автоматически при пуше в origin ветки в рамках общего CI конвейера. Собираются образы, гоняются тесты, образы складываются в GitLab Registry, потом оттуда разворачиваются в контейнеры. Развертывание происходит посредством Helm в Kubernetes кластер. То есть, если окружениям станет тесно, можно решить добавлением ноды. Адресация происходит по субдомену — имени ветки. Маршрутизируется через ingress. При удаления ветки (после мержа или руками) окружение полностью удаляется. Либо можно по кнопке удалить.
Спасибо! Я полон решимости продолжать эту серию. Формат кажется мне удачным и я намерен его развивать.
Я приведу аналогию с текстом. Если вы посмотрите на структуру моих статей, то увидите, что она состоит из небольших абзацев примерно равного размера, каждый из которых несет некую законченную мысль. И эти абзацы постепенно раскрывают ту картину и историю, которую я задумал. Может быть не всегда получается, но я иду по этому пути. И многие отмечают, что статьи читаются легко.

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

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

Это мое метафорическое и субъективное восприятие. Было бы очень хорошо услышать такое видение от других людей, чтобы более полно раскрыть тему.
Это еще раз доказывает, что еще есть люди, не сильно понимающие, как нужно проектировать системы. И значит тема развития в этой области весьма актуальна. Я тоже насмотрелся на такой софт. Но после того, как мы плотно взялись за практики разработки и проектирования, много проблем ушло.

У нас есть команда, которую мы практически полностью сформировали из стажеров. Несколько месяцев интенсивного обучения и они разработали систему, которая сейчас весьма успешно внедрена в одном из городов Казахстана. Поддержка ее не доставляет особых проблем, так же как и развитие.
Кстати, с «Идеальным программистом» произошла интересная ситуация. Ребята из издательства «Питер» прочитали мою первую статью про Валеру, ссылка на которую есть в этом посте. И после этого оперативно выпустили электронную версию русского издания книги. Вот пост, где они про это говорят habrahabr.ru/company/piter/blog/245345 Так что теперь можно без проблем купить электронную книгу.
Тот же самый «Идеальный программист» Роберта Мартина написан в похожем формате. Автор рассказывает истории, правда про себя. Еще «Принципы, паттерны и методики гибкой разработки на языке C#» того же автора. Там истории вперемешку с обычным стилем. А кроме этого подобных книг не встречал.

Я написал две статьи в этом стиле и планирую писать дальше. Кто знает, может постепенно появится и книга про Валеру :)
Кстати, одна из идей статьи заключалась в том, что этот текст можно давать новым сотрудникам. И за 3 минуты, потраченные на прочтение, они смогут понять, как начать, и на чем лучше концентрироваться.
Тут акцент на казахстанских реалиях. К сожалению, они таковы, что в большей части случаев люди узнают про эти вещи только когда приходят на производство.
Спасибо за отзыв! Если в Москве нет, приезжайте в Астану ;)
Спасибо за отзыв! Я постарался изложит кратко и в необычной форме. Считаю, такой способ подачи весьма эффективным.
В статье не ставилось цели придумать новые идеи. Она больше ориентирована на то, чтобы в интересной форме дать основную информацию и замотивировать молодых специалистов на развитие. Плюс я описываю свое видение, как нужно работать со стажерами. Очень часто их садят на баги и успокаиваются на этом. Я применяю другой подход, который, на мой взгляд, хорошо работает.
Да, согласен с вами. Думал про нее, когда выбирал, какие книги упомянуть.
Тут я полностью опираюсь на свой опыт. Как раз джуниором читал «Совершенный код» и он помог мне значительно улучшить качество кода. И в своей нынешней работе советую эту книгу приходящим к нам молодым разработчикам. Они высоко оценивают эту книгу.
Когда я готовил свою статью «Умей говорить „да“ и умей говорить „нет“», я использовал оригинальную версию книги. Электронного варианта на русском языке не нашел. Рад, что мой пост повлиял на ваше решение по выпуску электронной версии! Кстати, сама статья переехала на Мегамозг вместе с клоном моего аккаунта, когда редакция отпочковала этот ресурс.
Насколько я помню, он банально не успевал доехать к началу своего доклада. Москва и High Availability, это взаимоисключающие понятия, судя по всему :)
1

Information

Rating
Does not participate
Location
Астана, Акмолинская обл. (Целиноградская обл.), Казахстан
Date of birth
Registered
Activity