Некий набор операций которые необходимы для преобразования исходников в артефакты для запуска на тестовых или продуктивных серверах: получение, сборка, упаковка, прогон тестов. Все они могут принадлежать разным источникам и иметь разную природу.
Полностью согласен с таким определением.
Девопсам или сисадминам, как минимум, могут потребоваться конкретные инструкции по настройке сложного процесса полностью понимать который будет только разработчик.
Да. Но мне ещё здесь хочется добавить, что удобнее общаться в стиле декларативных зависимостей, а не инструкций. "Мне нужен доступ в интернет с общего раннера, чтобы скачать образ с gradle и jdk; мне нужен docker, чтобы собирать образы; мне нужен registry, чтобы хранить их; мне нужен shell-runner на таком-то стенде с тегом prod, чтобы деплоить туда". Если процесс убер-сложный, нужно его документировать, обсуждать, чтобы обе стороны понимали, что и как работает. Тогда это и есть DevOps.
Смотря, что вы имеете ввиду под этими словами. Сборка — скрипт, запускаемый в джобе? Часто это минимум команд, которые можно просто запустить из IDE, например та же сборка спринговым плагином сразу образа. Если сложнее, можно вынести все команды в .sh, и запускать его. Вариантов очень много, на самом деле.
Что значит отладить пайплайн? Если вы отлаживаете их на локальном инстансе, вы гарантируете, что настройки раннеров и всех других важных административных настроек идентичны тем, что на удаленной среде?
1. Гитлаб, по моему опыту, - самое беспроблемное приложение, не требующее особого ухода. По крайней мере в команде из 10 человек. Я трачу на его сопровождение всего 10 минут в неделю: делаю бэкап, скачиваю новую версию образа (если успела выйти) и перезапускаю на новом образе.
Имея достаточно устаревший опыт (развёртывание omnibus в 2015-2017), я, скорее, соглашусь с этим. Действительно, установка и администрирование были простыми и времени особо не требовали.
Встроенный container registry появился в 2016 году и сразу был доступен для всех. А вот package registry (maven, npm и прочие) был изначально платным, но переехал во free tier в 2020 году. Видимо, автор в 2015 настроил CI до состояния "работает - не трожь" и теперь делится хоть и готовым, но, увы, устаревшим рецептом. А может он поленился узнать какими фичами вообще обладает гитлаб. Или просто теряется в имеющейся документации (как он пишет в комментарии выше).
Ну вообще нет, т.к. я перестал регулярно читать ежемесячные дайджесты по 22 числам только год назад, и сейчас читаю их просто нерегулярно.
Но хочу отметить, что я не являюсь сис.админом, в данный момент я исключительно разработчик. И считаю избыточным для разработчика самостоятельно развёртывать и поддерживать GitLab.
Я продолжаю придерживаться мысли, что GitLab в компании должен быть один и управляться сис.админами, их не должно быть по штуке на разработчика (локально в докере), и разделять инстансы гитлаба на дев/прод среду тоже не нужно. Если речь в статье про разработчика-одиночку, почему бы ему не воспользоваться облачным GitLab.com? Если статья написана про ещё более узкую ситуацию, то, имхо, это должно быть обозначено, а не приведено как универсальный quickstart для любой ситуации.
1.1. Ваше предложение не масштабируется. Придется переделывать, когда возникнет необходимость деплоить более чем на один сервер. Плюс есть проблемы с безопасностью - прод не должен иметь доступ к деву, а в вашей схеме потребуется пробить дырку из прода к гитлабу.
Извините, но не вижу, где оно не масштабируется. Я применяю эту схему на разных проектах. GitLab это не часть ни dev-среды, ни prod-среды, это инфраструктурный компонент, такой же, как и вероятно установленный где-то рядом Registry. Поэтому речь о пробитии дырки прод->дев некорректна, это дырка prod->infra.
Деплойте на сколько угодно серверов, из каких угодно веток. Разделите ветки стендов на protected и нет, чтобы обезопасить прод. Собирайте и пуште образы на общих раннерах, деплойте на "стендовых" раннерах, фильтруя джобы деплоя через фильтры only:refs и tags. Запретите Dev мержить в protected, только Maintainer.
Я дико извиняюсь, но, имхо, вся эта статья пропитана костылями.
Попробую защитить своё мнение.
Итак, мы получили пайплайн, который при фиксации изменений в репозитории запускает сборку проекта и затем докер-образа, публикует его в отдельном реестре, забирает и деплоит докером целевой машины. Благодаря гибкости докера все это мы проделали на локальном компьютере, но теперь, отладив процессы, легко сможем перенести их в производственную среду.
1) Я сторонник DevOps, но самостоятельное развёртывание и администрирование инстанса GitLab, имхо, не должно касаться стороны Dev. Это задача исключительно инфраструктурной команды. Я развёртывал в НИИ в 2015 году инстанс и пару лет админил его, так что это не диванная аналитика =)
1.1) Однако, ничего не имею против развёртывания своих раннеров. Настолько, что мне кажется более стройной идея установки раннера на целевой хост и запуск джобы с деплоем прямо на нём, без всех этих приключений с SSH-ключами.
2) Про поднятие своего реестра -- не уверен, кто-нибудь ниже мб меня поправит. Но если инстанс GitLab развёрнут нормально, в нём же есть встроенный и Image Registry, и Maven / npm Registry и т.п. (честно не помню, может что-то в платных Tier, но образы точно есть в бесплатном).
3) Зачем нам игнорировать базовый функционал раннера по скачиванию репы? Ради чего? Потому что у нас кривая среда?
4) У вас only.refs: main, а если MR из фича ветки в main кривой и всё ломает?
5) В таком виде процессы не "отлажены", я бы на прод это не допускал =)
Раз уж покритиковал, напишу свой вариант. Он, конечно, может быть к вашей ситуации неприменим, я не знаю всех тонкостей.
1) GitLab у нас один и управляется специалистами нужного профиля. Они же предоставляют общие раннеры (и желательно не privileged).
2) У нас есть джоба, которая собирает приложение, прогоняет тесты, пакует всё в образ и пушит в registry под управлением специалистов нужного профиля. На общем раннере, для любой ветки.
3) Для веток, соответствующим стендам (тест/прод), запускаются джобы с тегами раннеров, стоящих в этих средах. Раннеры на месте делают pull нового образа и рестарт приложа.
Поделитесь в комментариях: какие методики модульного тестирования используете вы?
Используем эти:
Высокоуровневые — проверка бизнес‑процесса системы и логики работы программы.
Как-то так вышло, эмпирически, что низкоуровневые тесты всё-таки гарантируют с меньшей степенью отсутствие багов. Высокоуровневые проверяют и то, что сценарий ОКъ, и низкоуровневые моменты.
Не отрицаю, что (1) нет, но пирамида тестирования перевёрнутая выходит в реальности: больше всего (3), есть (2), меньше всех (1).
До того, как я удалил ещё тогда Сбер, он жрал немыслимое кол-во места на телефоне (чуть менее 700 Мб). Подумать только, целый CD! Для меня это было достаточно зловредно :)))
У меня на проекте монорепо с 2019 года, однозначно, что есть свои плюсы. Есть и минусы, как-то: код пайплайнов становится никому непонятным, кроме автора.
П.С. У нас в монорепо в основном java, но есть и nodejs fe / be :)
Считается, что с зависимостями лучше работать через собственные абстракции. Если в какой-то момент придется заменить либу/внешний сервис A на B, то изменения будут только в адаптере, но не просочатся в остальной код.
И вот у меня дошли руки тоже это реализовать у себя :) Делюсь прогрессом.
Подход выбран близкий, но с отличиями в деталях. Поднимается контекст Spring, считаем sha256 от папки с миграциями liquibase, часть первых символов в hex это тег образа. Если образа нет, собираем: подняли стандартный контейнер postgresql, запустили миграции liquibase, стопнули контейнер, скопировали /var/lib/postgresql/data в отдельный .tar.gz, создаём на основе стандартного postgresql новый образ с нужным тегом, закидывая туда файлы в другую папку (/var/lib/postgresql-migrated/data) + обновлённый migrated-entrypoint.sh. Скрипт делает только перемещение в изначальную папку, и запуск оригинального docker-entrypoint.sh, это нужно для того, чтобы файлы в контейнере разместились на tmpfs.
При запуске одного произвольного теста время на поднятие контекста срезалось в два раза.
Как-то, уже наверное 15 лет назад, мы в НИИ купили себе стойку в комнату. Прям небольшой кабинет, 4 стола, 3-4 человека.
Сперва с одним сервером, постепенно выросли до 3. Для каждого сервера понемногу внизу стойки вставили по ИБП. Свитч. Напруга — был силовой щиток рядом, всё ОК. Чутт выше поставили полку, на неё МФУшка влезла :) Над стойкой кондёр на стену.
Цель — фундаментальные исследования, числомолотилка. В целом всё нормально было, кроме ещё одного фактора, который выше никто не отметил. Последний, третий supermicro, несмотря на толщину 2U, был ужасно шумный. Первый брали Интел, 4u, он был тих. Второй 1U, шумоват. А вот третий нас просто добил. В итоге включали вычисления на нём, только уходя домой.
Ну и оно до сих пор стоит и работает. Не представляю, сколько денег это бы сожрало при разных вариантах аренды.
Если держать в голове, что у нас его виртуальные треды, можно завести бесконечный тредпул, их плодить бесщадно на каждый запрос запрошенное N число, а в потоках блокироваться на семафоре. В зависимости от обсуждения с собеседующим можно семафор сделать или глобальный, если хочется честно лимитировать число запросов от нашего сервиса к целевому, или на внешний запрос, если "чуть более честно следовать букве ТЗ".
Если виртуальных тредов нет, можно поинтересоваться, не предполагается ли, что у нас всегда достаточно памяти под треды, и авось их тоже можно плодить.
В общем, мой коммент скорее про то, что перед реализацией можно ещё больше деталей уточнить, которые могут дать пространство для манёвра.
Полностью согласен с таким определением.
Да. Но мне ещё здесь хочется добавить, что удобнее общаться в стиле декларативных зависимостей, а не инструкций. "Мне нужен доступ в интернет с общего раннера, чтобы скачать образ с gradle и jdk; мне нужен docker, чтобы собирать образы; мне нужен registry, чтобы хранить их; мне нужен shell-runner на таком-то стенде с тегом prod, чтобы деплоить туда". Если процесс убер-сложный, нужно его документировать, обсуждать, чтобы обе стороны понимали, что и как работает. Тогда это и есть DevOps.
Смотря, что вы имеете ввиду под этими словами. Сборка — скрипт, запускаемый в джобе? Часто это минимум команд, которые можно просто запустить из IDE, например та же сборка спринговым плагином сразу образа. Если сложнее, можно вынести все команды в .sh, и запускать его. Вариантов очень много, на самом деле.
Что значит отладить пайплайн? Если вы отлаживаете их на локальном инстансе, вы гарантируете, что настройки раннеров и всех других важных административных настроек идентичны тем, что на удаленной среде?
Имея достаточно устаревший опыт (развёртывание omnibus в 2015-2017), я, скорее, соглашусь с этим. Действительно, установка и администрирование были простыми и времени особо не требовали.
Ну вообще нет, т.к. я перестал регулярно читать ежемесячные дайджесты по 22 числам только год назад, и сейчас читаю их просто нерегулярно.
Но хочу отметить, что я не являюсь сис.админом, в данный момент я исключительно разработчик. И считаю избыточным для разработчика самостоятельно развёртывать и поддерживать GitLab.
Я продолжаю придерживаться мысли, что GitLab в компании должен быть один и управляться сис.админами, их не должно быть по штуке на разработчика (локально в докере), и разделять инстансы гитлаба на дев/прод среду тоже не нужно. Если речь в статье про разработчика-одиночку, почему бы ему не воспользоваться облачным GitLab.com? Если статья написана про ещё более узкую ситуацию, то, имхо, это должно быть обозначено, а не приведено как универсальный quickstart для любой ситуации.
Извините, но не вижу, где оно не масштабируется. Я применяю эту схему на разных проектах. GitLab это не часть ни dev-среды, ни prod-среды, это инфраструктурный компонент, такой же, как и вероятно установленный где-то рядом Registry. Поэтому речь о пробитии дырки прод->дев некорректна, это дырка prod->infra.
Деплойте на сколько угодно серверов, из каких угодно веток. Разделите ветки стендов на protected и нет, чтобы обезопасить прод. Собирайте и пуште образы на общих раннерах, деплойте на "стендовых" раннерах, фильтруя джобы деплоя через фильтры only:refs и tags. Запретите Dev мержить в protected, только Maintainer.
Я дико извиняюсь, но, имхо, вся эта статья пропитана костылями.
Попробую защитить своё мнение.
1) Я сторонник DevOps, но самостоятельное развёртывание и администрирование инстанса GitLab, имхо, не должно касаться стороны Dev. Это задача исключительно инфраструктурной команды. Я развёртывал в НИИ в 2015 году инстанс и пару лет админил его, так что это не диванная аналитика =)
1.1) Однако, ничего не имею против развёртывания своих раннеров. Настолько, что мне кажется более стройной идея установки раннера на целевой хост и запуск джобы с деплоем прямо на нём, без всех этих приключений с SSH-ключами.
2) Про поднятие своего реестра -- не уверен, кто-нибудь ниже мб меня поправит. Но если инстанс GitLab развёрнут нормально, в нём же есть встроенный и Image Registry, и Maven / npm Registry и т.п. (честно не помню, может что-то в платных Tier, но образы точно есть в бесплатном).
3) Зачем нам игнорировать базовый функционал раннера по скачиванию репы? Ради чего? Потому что у нас кривая среда?
4) У вас only.refs: main, а если MR из фича ветки в main кривой и всё ломает?
5) В таком виде процессы не "отлажены", я бы на прод это не допускал =)
Раз уж покритиковал, напишу свой вариант. Он, конечно, может быть к вашей ситуации неприменим, я не знаю всех тонкостей.
1) GitLab у нас один и управляется специалистами нужного профиля. Они же предоставляют общие раннеры (и желательно не privileged).
2) У нас есть джоба, которая собирает приложение, прогоняет тесты, пакует всё в образ и пушит в registry под управлением специалистов нужного профиля. На общем раннере, для любой ветки.
3) Для веток, соответствующим стендам (тест/прод), запускаются джобы с тегами раннеров, стоящих в этих средах. Раннеры на месте делают pull нового образа и рестарт приложа.
Терминал и Far это боль :)
Но если добавить фольги, кажется, должен получится хороший конденсатор )
Жаль, что ни слова про Новосибирск, вдруг тоже какие-нибудь интересные факты нашлись бы :)
Используем эти:
Как-то так вышло, эмпирически, что низкоуровневые тесты всё-таки гарантируют с меньшей степенью отсутствие багов. Высокоуровневые проверяют и то, что сценарий ОКъ, и низкоуровневые моменты.
Не отрицаю, что (1) нет, но пирамида тестирования перевёрнутая выходит в реальности: больше всего (3), есть (2), меньше всех (1).
До того, как я удалил ещё тогда Сбер, он жрал немыслимое кол-во места на телефоне (чуть менее 700 Мб). Подумать только, целый CD! Для меня это было достаточно зловредно :)))
А зачем таскать 300 Гб артефактами? Может надо что-то из них выпилить?
У меня на проекте монорепо с 2019 года, однозначно, что есть свои плюсы. Есть и минусы, как-то: код пайплайнов становится никому непонятным, кроме автора.
П.С. У нас в монорепо в основном java, но есть и nodejs fe / be :)
Прошу прощения, что комментарием (пишу с телефона), но Supplier, а не Suplier.
Ещё надо отметить переиспользование кусков SQL из разных файлов :)
Точно крутая технически штука, но почему она звучит как зло?)
Но, действительно, статья не отвечает на вопрос из заголовка...
Считается, что с зависимостями лучше работать через собственные абстракции. Если в какой-то момент придется заменить либу/внешний сервис A на B, то изменения будут только в адаптере, но не просочатся в остальной код.
Эта статья была написана как ответ на переписку в комментариях к моей статье: https://habr.com/ru/articles/742552/
И вот у меня дошли руки тоже это реализовать у себя :) Делюсь прогрессом.
Подход выбран близкий, но с отличиями в деталях. Поднимается контекст Spring, считаем sha256 от папки с миграциями liquibase, часть первых символов в hex это тег образа. Если образа нет, собираем: подняли стандартный контейнер postgresql, запустили миграции liquibase, стопнули контейнер, скопировали /var/lib/postgresql/data в отдельный .tar.gz, создаём на основе стандартного postgresql новый образ с нужным тегом, закидывая туда файлы в другую папку (/var/lib/postgresql-migrated/data) + обновлённый migrated-entrypoint.sh. Скрипт делает только перемещение в изначальную папку, и запуск оригинального docker-entrypoint.sh, это нужно для того, чтобы файлы в контейнере разместились на tmpfs.
При запуске одного произвольного теста время на поднятие контекста срезалось в два раза.
Ну, если бы не Майнкрафт, я бы не перешёл из плюсов в джаву :) Так что у меня к нему личная благодарность :)
Как-то, уже наверное 15 лет назад, мы в НИИ купили себе стойку в комнату. Прям небольшой кабинет, 4 стола, 3-4 человека.
Сперва с одним сервером, постепенно выросли до 3. Для каждого сервера понемногу внизу стойки вставили по ИБП. Свитч. Напруга — был силовой щиток рядом, всё ОК. Чутт выше поставили полку, на неё МФУшка влезла :) Над стойкой кондёр на стену.
Цель — фундаментальные исследования, числомолотилка. В целом всё нормально было, кроме ещё одного фактора, который выше никто не отметил. Последний, третий supermicro, несмотря на толщину 2U, был ужасно шумный. Первый брали Интел, 4u, он был тих. Второй 1U, шумоват. А вот третий нас просто добил. В итоге включали вычисления на нём, только уходя домой.
Ну и оно до сих пор стоит и работает. Не представляю, сколько денег это бы сожрало при разных вариантах аренды.
Если держать в голове, что у нас его виртуальные треды, можно завести бесконечный тредпул, их плодить бесщадно на каждый запрос запрошенное N число, а в потоках блокироваться на семафоре. В зависимости от обсуждения с собеседующим можно семафор сделать или глобальный, если хочется честно лимитировать число запросов от нашего сервиса к целевому, или на внешний запрос, если "чуть более честно следовать букве ТЗ".
Если виртуальных тредов нет, можно поинтересоваться, не предполагается ли, что у нас всегда достаточно памяти под треды, и авось их тоже можно плодить.
В общем, мой коммент скорее про то, что перед реализацией можно ещё больше деталей уточнить, которые могут дать пространство для манёвра.