Рубрика «gitlab» - 4

GitLab CI: 6 фич из последних релизов, которых мы так ждали - 1

В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.

GitLab CI: 6 фич из последних релизов, которых мы так ждали - 2
Агрегация по месяцам и тегам репозитория GitLab

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

О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.Читать полностью »

Я обычно всегда обходился без докера и думал, что докер нужен только для больших проектов в больших компаниях. Но однажды я увидел как работает докер в паре с гитлабом у моего товарища и понял, что мне все таки стоит его изучить. Однако, как обычно это бывает, одной подходящей статьи я не нашел — они были либо слишком сложные, либо не полные, либо подразумевали, что вы все знаете само собой. Мне пришлось долго искать различные источники, соединять все это вместе и в итоге у меня получилось сделать простенький проект и CI/CD для него.

Всю работу можно разделить на три части: на локальной машине, на гитлабе и на сервере.

Итак, для реализации проекта нам понадобится аккаунт gitlab и удаленный сервер с виртуализацией KVM или XEN.

Часть 1. Локальная машина

На локальной машине необходимо установить docker.

Замечание

Тут небольшое отступление. Docker можно поставить как на Linux системах (как Ubuntu, например), так и на Windows и MacOS. По поводу macos я ничего сказать не могу, а вот установка под Windows не самая хорошая идея для начинающего. Как минимум из-за того, что все мануалы и документации написаны для linux систем. Так и из-за того, что можно нажить проблем с доступом к различным папкам и файлам. Также докер конфликтует с виртуальной машиной VirtualBox. Поэтому проще и быстрее будет сделать виртуальную машину с Ubuntu и работать под ней

Читать полностью »

Переменные в Gitlab можно задать в нескольких местах:

  1. В настройках групп
  2. В настройках проекта
  3. Внутри .gitlab-ci.yml

При этом переменные в настройках групп и проекта можно задать как "файл"или "обычную переменную" и поставить галочки "защищено" и "маскировать".

Как Gitlab-CI наследует переменные окружения? - 1

Начнем с простого наследования и будет постепенно усложняться.

С конечным списком уровней приоритетов можно ознакомиться в конце документа.

Читать полностью »

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

Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.

В общем суть метода уже изложена, ниже лишь немного подробностей.

Читать полностью »

Недавно на стендапе коллега внес рацпредложение: автоматизировать сборку релизов, взяв за основу готовые уже наработки по взаимодействию с Jira, написанные на Python.

Процесс деплоя у нас следующий: когда накапливается достаточное количество задач, прошедших тестирование из них собирается Релиз-кандидат (RC) в каждом проекте, затронутом задачами, затем задачи тестируются в составе RC. После этого RC заливается на стейджинг сервер, где в близком к боевому окружении все еще раз тестируется и проводится полный регресс. И затем, после необходимых деплойных действий свежий релиз заливается в мастер.

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

В общем, приступил я к задаче, и она оказалась очень интересной и увлекательной. А что еще надо для удовольствия от работы, как не увлекательных проектов?
Читать полностью »

Наша команда любит эксперименты. Каждый Слёрм — это не статичное повторение предыдущих, а осмысление опыта и переход от хорошего к лучшему. Но со Слёрмом SRE мы решили применить абсолютно новый формат — дать участникам условия, максимально приближённые к «боевым».

Если кратко обрисовать, чем мы занимались на интенсиве: «Строим, ломаем, чиним,
изучаем». SRE мало чего стоит в голой теории — только практика, реальные решения, реальные проблемы.

Участники были поделены на команды, чтобы бодрый соревновательный дух не дал никому заснуть или запустить «Angry Birds» на iPhone по примеру Дмитрия Анатольевича.

Проблемы, глюки, баги и задачи обеспечивали участникам четыре ментора. Иван Круглов, Principal Developer в Booking.com (Нидерланды). Бен Тайлер, Principal Developer в Booking.com (США). Эдуард Медведев, CTO в Tungsten Labs (Германия). Евгений Варавва, разработчик широкого профиля в Google (Сан-Франциско).

Да ещё и участники поделены на команды — и соревнуются друг с другом. Интересно?

Слёрм SRE. Сплошной эксперимент c экспертами из Booking.com и Google.com - 1
Иван, Бен, Эдуард и Евгений с добрым ленинским прищуром смотрят на бедных участников Слёрм SRE перед началом соревнования.

Читать полностью »

В продолжение предыдущей статьи про инструменты деплоя в Kubernetes, хочу рассказать вам про то как можно использовать Jsonnet для упрощения описания джоб в вашем .gitlab-ci.yml

Как описать 100 Gitlab джоб в 100 строк - 1

Дано

Есть монорепа, в которой:

  • 10 Dockerfiles
  • 30 описанных деплоев
  • 3 окружения: devel, staging и production

Задача

Настроить пайплайн:

  • Сборка Docker-образов должна производиться по добавлении git-тэга с версией.
  • Каждая операция деплоя должна выполняться при пуше в ветку окружения и только по изменении файлов в конкретной директории
  • В каждом окружении установлен свой gitlab-runner с отдельным тэгом, который выполняет деплой только в своём окружении.
  • Не все приложения должны быть задеплоены в каждое из окружений, мы должны описать пайплайн так, чтобы иметь возможность делать исключения.
  • Некоторые деплойменты используют git submodule и должны запускаться с установленной переменной GIT_SUBMODULE_STRATEGY=normal

Как видите, описать это всё может показаться настоящим адом, но мы не отчаиваемся и вооружившись Jsonnet сделаем это легко и непринуждённо.

Читать полностью »

Пробуем новые инструменты для сборки и автоматизации деплоя в Kubernetes - 1

Привет! За последнее время вышло много классных инструментов автоматизации как для сборки Docker-образов так и для деплоя в Kubernetes. В связи с этим решил поиграться с гитлабом, как следует изучить его возможности и, конечно же, настроить пайплайн.

Вдохновлением для этой работы стал сайт kubernetes.io, который генерируется из исходных кодов автоматически, а на каждый присланный пул реквест робот автоматически генерирует preview-версию сайта с вашими изменениеми и предоставляет ссылку для просмотра.

Я постарался выстроить подобный процесс с нуля, но целиком построенный на Gitlab CI и свободных инструментах, которые я привык использовать для деплоя приложений в Kubernetes. Сегодня я, наконец, расскажу вам о них подробнее.

В статье будут рассмотрены такие инструменты как:
Hugo, QBEC, Kaniko, Git-crypt и GitLab CI с созданием динамических окружений.

Читать полностью »

Как я неделю был стажером SRE-инженера. Дежурство глазами инженера ПО - 1

SRE-инженер — стажер

Для начала позвольте представиться. Я — @tristan.read, фронтэнд-инженер в группе Monitor::Health GitLab'а. На прошлой неделе мне выпала честь побыть стажером у одного из наших дежурных SRE-инженеров. Целью было ежедневное наблюдение за тем, как дежурный реагирует на инциденты, и получение реального опыта работы. Нам бы хотелось, чтобы наши инженеры лучше понимали потребности пользователей функций Monitor::Health.

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

Читать полностью »

Рисунок 2

Эта статья является продолжением цикла публикаций об использовании PVS-Studio в облачных системах. На этот раз мы рассмотрим работу анализатора совместно с GitLab CI — продуктом от GitLab Inc. Интеграция статического анализатора в CI систему позволяет выявить баги сразу после этапа сборки проекта и является очень эффективным способом сократить затраты на обнаружение ошибок.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js