Блог компании gitlab

Большинство из нас, подмечая очередной новый термин в IT блогосфере или конференции, рано или поздно задается подобным вопросом: Что это? Очередное модное слово, buzzword или действительно что-то стоящее пристального внимания, изучения и обещающее новые горизонты? Точно также вышло у меня и с термином GitOps некоторое время назад. Вооружившись множеством уже существующих статей, а также знанием коллег из компании GitLab, я попытался разобраться, что же это за зверь, и как его применение может выглядеть на практике.

Кстати, о новизне термина GitOps также говорит недавно проведенный нами опрос: более половины опрошенных еще не начинали работы с его принципами.

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

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

Так в чем собственно отличие GitOps от IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:

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

С другой стороны, появилась возможность автоматизировать процессы управления инфраструктурой. Теперь это можно сделать быстрее, надежнее и дешевле. Тем более принципы CI / CD уже были известны и популярны среди разработчиков программного обеспечения. Необходимо было только перенести и применить уже известные знания и навыки в новую область. Эти практики однако выходили за рамки стандартного определения Инфраструктуры как кода, отсюда и родилось понятие GitOps.

Любопытность GitOps, конечно, еще и в том, что это не продукт, плагин или платформа, связанная с каким бы то ни было вендором. Это скорее парадигма и набор принципов, аналогично с другим знакомым нам термином: DevOps.

В компании GitLab мы выработали два определения этого нового термина: теоретический и практически. Начнем с теоретического:

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

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

С практической же точки зрения мы описываем GitOps следующим образом:

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

Merge Request (альтернативное название Pull Request). В плане процесса MR - это запрос на применение изменений кода и последующее слияние веток. Но в плане инструментов, которыми мы пользуемся - это скорее возможность для получения полной картины всех вносимых изменений: не только code diff, собранный из какого-то количества коммитов, но и контекст, результаты тестов, конечный ожидаемый результат. Если мы говорим про инфраструктурный код, то нам интересно, как именно изменится инфраструктура, сколько новых ресурсов будет добавлено или удалено, изменено. Желательно в каком-то более удобном и легко читаемом формате. В случае с облачными провайдерами неплохо было бы знать, какие финансовые последствия понесет это изменение.

Но MR - это еще и средство совместной работы, взаимодействия, общения. То место, где вступает в действие система сдержек и противовесов. От простых комментариев до формальных одобрений и утверждений.

Ну и последняя составляющая: CI/CD, как мы уже знаем, дает возможность автоматизировать процесс внесения инфраструктурных изменений, тестирования (от простой проверки синтаксиса до более сложного статического анализа кода). А также и в последующем обнаружения дрейфа: отличий реального и желаемого состояния системы. Например, в результате несанкционированных ручных изменений или же отказа систем.

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

А если вам вдруг станет интересно, как это все выглядит на практике, то приглашаю посмотреть наш мастер-класс, в котором я пошагово рассказываю, как при помощи GitLab:

• Реализовать основные принципы GitOps

• Создавать и вносить изменения в облачную инфраструктуру (на примере Yandex Cloud)

• Автоматизировать обнаружение дрейфа системы от желаемого состояния при помощи активного мониторинга

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

В компании GitLab мы очень внимательно следили за этими изменениями, так как они затрагивали практически всех наших пользователей и клиентов. Сегодня я хотел бы рассказать о том, какие изменения мы внесли и как адаптировались к новым правилам.

Что же произошло?

Публичный регистр контейнеров Docker Hub очень широко и часто используется сообществом DevOps для достижения разнообразных целей: запуска CI/CD задач, стандартизации процессов, выката контейнерных приложений как в sandbox, так и в production. Как только мы узнали о введении новых ограничения по количеству запросов, мы начали анализ новых правил, чтобы понять, как они повлияют на работу наших пользователей, и как мы можем почем решить возможные проблемы.

Согласно новым правилам после 100 запросов за 6 часов с одного клиентского IP адреса каждый новый docker pull вернет ошибку 429 - too many requests, что несомненно приведет к сломанным CI/CD конвейерам, невозможности выкатить приложения и целому букету ошибок в ваших Kubernetes кластерах. Вполне понятно, что этот лимит может быть очень быстро достигнут, особенно если все задачи выполняются с одного и того же GitLab Runner агента, или если команда из нескольких инженеров работает с одного и того же публичного адреса.

Аутсорсинг Dependency Proxy

Как отметил мой коллега Tim Rizzi "Нам следует срочно всем рассказать о Dependency Proxy", который изначально создавался для проксирования и кэширования образов Docker Hub. Этот функционал существует в GitLab уже довольнейший давно (начиная с версии 11.11), но до сегодняшнего дня был доступен только для пользователей Enterprise подписки уровня Premium. Перед продуктовой командой встал вполне резонный вопрос: "Стоит ли нам вынести Dependency Proxy в open source версию продукта, помогая таким образом широкому сообществу пользователей минимизировать проблемы из-за новых ограничений Docker Hub?"

Не вдаваясь в подробности, ответ на этот вопрос был ДА. При принятии решения, в какой уровень подписки должен попадать тот или иной функционал продуктовая команда GitLab всегда руководствуется вопросом "Кто является целевым пользователем?". Согласно этому принципу те возможности, которые чаще всего запрашивает индивидуальный участник или разработчик, попадают в Core или Open Source версию продукта. Скачивание образов с Docker Hub вполне соответсвует этому описанию. Более того аутсорсинг Dependency Proxy поможет большому количеству разработчиков повысить надежность и производительность их CI/CD конвейеров.

Как результат, начиная с версии 13.6 вышедшей 22 ноября 2020 года, проксирование и кэширование образов в GitLab стало абсолютно бесплатным для всех наших пользователей!

Что дальше?

К сожалению, идеальные решения не появляются мгновенно. Мы как никто другой знаем, что нашему продукты есть куда расти, поэтому активно работаем над улучшением функционала Dependency Proxy и уже в ближайших релизах планируем добавить новые возможности / решить имеющиеся проблемы:

• 13.7 (22 декабря, 2020)

  • gitlab-#11582 сделает возможным использование Dependency Proxy для приватных групп в GitLab (сегодня работает только для публичных проектов)

  • gitlab-#241639 позволит использовать закэшированный образ даже если Docker Hub недоступен. На сегодня это невозможно, так как даже при наличии закэшированного образа, его манифест всегда скачивается из конечного регистра

  • gitlab-#21619 добавит новый параметр pull_policy в YAML описании CI/CD задач, позволяющий разработчикам самим указывать политику скачивания контейнера (always, if-not-present, never) вместо того, чтобы полагаться на настройки GitLab Runner

  • gitlab-runner-#26558 позволит конфигурировать GitLab Runner с набором политик для скачивания образов (always, if-not-present)

Мониторинг ограничений

Решения обозначенные выше, а также в блог посте моего коллеги Steve Azzopardi, помогут упростить работу с новыми ограничениями, но не избавят от них на все 100%. Поэтому мы также выработали набор советов и инструментов, цель которых - помочь широкому сообществу адаптироваться к новым лимитам за счет их мониторинга.

Как проверить текущее значение лимита?

Документация Dockerрекомендует использовать HTTP запрос для проверки текущего значения ограничений запросов в Docker Hub.

Начнем с определения образа, для которого мы хотим получить текущее ограничение и получения токена для авторизации:

$ IMAGE="ratelimitpreview/test"$ TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:$IMAGE:pull" | jq -r .token)$ echo $TOKEN

Следующий шаг - симуляция запросаdocker pull. Вместо использования методаGETотправляемHEADзапрос (он не учитывается при подсчете ограничений). Ответ на этот запрос содержит параметрыRateLimit-Limit и RateLimit-Remaining.

$ curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/$IMAGE/manifests/latest

В примере ниже количество запросов ограничено2500, из которых2495еще доступны.21600определяет шестичасовой период (в секундах)

RateLimit-Limit: 2500;w=21600RateLimit-Remaining: 2495;w=21600

Автоматизация проверки лимитов

Michael Friedrich, один из евангелистов GitLab, поделился готовым решением на Python для проверки ограничений. Проект включает подробную документацию по установке и использованию

$ python check_docker_hub_limit.py --helpusage: check_docker_hub_limit.py [-h] [-w WARNING] [-c CRITICAL] [-v] [-t TIMEOUT]Version: 2.0.0optional arguments:  -h, --help            show this help message and exit  -w WARNING, --warning WARNING                        warning threshold for remaining  -c CRITICAL, --critical CRITICAL                        critical threshold for remaining  -v, --verbose         increase output verbosity  -t TIMEOUT, --timeout TIMEOUT                        Timeout in seconds (default 10s)

Скрипт возвращает следующие exit коды в зависимости от указанных параметров

• 0- OK

• 1- WARNING

• 2- CRITICAL

$ python3 check_docker_hub_limit.pyOK - Docker Hub: Limit is 5000 remaining 4997|'limit'=5000 'remaining'=4997$ echo $?0$ python3 check_docker_hub_limit.py -w 10000 -c 3000WARNING - Docker Hub: Limit is 5000 remaining 4999|'limit'=5000 'remaining'=4999$ echo $?1$ python3 check_docker_hub_limit.py -w 10000 -c 5000CRITICAL - Docker Hub: Limit is 5000 remaining 4998|'limit'=5000 'remaining'=4998$ echo $?2

Экспортер Prometheus

Кроме этого мы подготовили и выпустили экспортер для Prometheus, который позволит экспортировать метрики ограничений и реализовать их полноценный мониторинг.

Репозиторий проекта включает демо контейнер, включающий себе экспортер, Prometheus, Grafana, и docker-compose инструкции для его выката

$ cd example/docker-compose$ docker-compose up -d

Перейдите по адресу http://localhost:3000 для доступа к дэшборду Grafana

Надеюсь, наш опыт и рекомендации окажутся для вас полезными!