#devops, #gitlab, #cicd

🦊 GitLab CI/CD: облегчаем работу с кодом для пайплайнов

☝️ GitLab это отличное решение при выборе системы управления репозиториями. Кроме этого, GitLab также позиционирует себя, как инструмент DevOps, имеющий в своём арсенале CI/CD, Container Registry и много других полезных инструментов. Остановимся на GitLab CI/CD. А именно на полезных штуках, которые могут облегчить вашу жизнь.

🏕 1) Окружения (environments)
Часто случается так, что у вас может быть несколько окружении. Для каждого, соответственно, используется своя ветка (develop, stage, main, etc).

🤓 С помощью GitLab окружении можно указать переменные с одинаковыми ключами, но при этом с разными значениями. Окружение для переменной назначается при её созданий, затем в Job-е необходимо указать, какое окружение вы будете использовать:

stages:
  - build

Build For Development:
  stage: setup
  environment: development   # !
  image: ubuntu:22.04
  only:
    - develop
  script:
    - echo "Building project for development...."
    - echo $KUBE_TOKEN   # !

Build For Production:
  stage: setup
  environment: production  # !
  image: ubuntu:22.04
  only:
    - main
  script:
    - echo "Building project for production...."
    - echo $KUBE_TOKEN  # !

🙋‍♂️ Для Build Develop используется KUBE_TOKEN для подключения к девовскому кластеру, для Build Prod - продовскому. Но не всё так идеально...


👥 2) Переменные для группы (Group Variables)

Одна и та же переменная нужна для нескольких репозиториев. Что делать? Определить переменную на уровне группы!
Тут также есть окружения, но если у вас Free версия GitLab, то доступа к ним на уровне групп у вас не будет 🙁.

🤠 Но никто не мешает вам использовать префиксы! PROD_, STAGE_, DEVELOP_. При этом вы можете совмещать переменные на уровне репозиториев с переменными на уровне групп!


3) include и скрытые джобы

💭 Вы любитель разносить повторяющийся код по классам и обожаете DRY, но при этом вам приходится регулярно смотреть на ужасы, которые творятся в .gitlab-ci.yml файлах?

😵‍💫 Всё замечательно, пока у вас два-три репозитория. Но когда у вас их больше, при этом содержимое .gitlab-ci.yml повторяется, то приходят проблемы: в случае необходимости, нужно редактировать все файлы, чтение таких ямлов становится невыносимой задачей, код растягивается на тысячи строк. И тут мы можем воспользоваться include!

🔨 Он позволяет импортировать джобы для CI/CD в ваш текущий файл. Таким образом, вы можете переиспользовать одни и те же куски кода!

Сразу к примеру! В репозиторий 'my-templates' есть файл base-build.yml со следующим содержимым:

.build:
  image: ubuntu:22.04
  
  variables:
    KUBE_URL: ""
    KUBE_TOKEN: ""
  script:
    - echo "Set up connection to cluster $KUBE_URL with token $KUBE_TOKEN" 

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

Теперь мы можем использовать эту скрытую джобу в других файлах или даже репозиториях!

🧑🏻‍💻 К примеру, есть репозиторий my-app-repo-1. "Заинклюдим" джобы из ранее созданного файла, при этом укажем путь до репозитория (группу/репо):

include:
  - project: '<group_name>/my-templates'
    ref: main
    file: '/base-build.yml'

🙋 Теперь создадим таски для текущего проекта. Переопределим переменные и при помощи extends укажем в качестве шаблона .build джобу:

Build For Development:
  extends: .build
  stage: build
  only:
    - develop
  variables:
    KUBE_URL: DEVELOP_KUBE_URL
    KUBE_TOKEN: DEVELOP_KUBE_TOKEN
    
Build For Production:
  extends: .build
  stage: build
  only:
    - main
  variables:
    KUBE_URL: PROD_KUBE_URL
    KUBE_TOKEN: PROD_KUBE_TOKEN

Обратите внимание на переменные: мы можем их переопределять. Похоже на аргументы функций, не так ли?)

📌 Вы можете переопределить любое поле. Если вам нужно добавить какой-то дополнительный скрипт, то вы можете воспользоваться полями before_script и after_script, что также очень удобно!

#devops, #monitoring, #k8s

🕵️‍♂️ Не отслеживаете метрики Kubernetes? Фатальная ошибка!

💡В одной из своих статей я писал о том, что мониторинг и логирование запущенных сервисов является одной из задачей в сфере DevOps. Я лишь частично прошёлся по самим метрикам, экспортировав готовый дашборд и уделив большее внимание установке нужных компонентов. Ну что же, на этот раз я решил больше углубиться в создание дашборда с нужными мне метриками. Начнём с полезных фишек и плавно перейдем к самому содержимому дашборда.

1) Используйте переменные.
И это касается не только программирования или GitLab CI. В Grafana для дашборда есть возможность создавать переменные, которые затем могут использоваться в запросах панелей. Зачем это нужно?

☝️ Для гибкости! Самый простой пример: переменные $prom_datasource и $namespace. С помощью первого можно задать источник данных, это полезно, если у вас их несколько (допустим, Prometheus в разных кластерах). $namespace поможет произвести фильтр по пространству имён. В моём дашборде есть и другие переменные, прошу к знакомству! Их практическое применение далее...

2) Используйте Rows.
Row это отдельная сущность дашборда, позволяющая группировать панели. Помимо этого, она позволит сделать ваш дашборд оптимизированным и быстрым!

🏃‍♂️ Если вы когда нибудь пробовали посмотреть кучу панелей одновременно, ваш браузер с большей вероятностью испытывал огромный стресс. Панели, принадлежащие "строкам", будут загружаться только после их раскрытия.

3) Настраивайте алерты
Я собрал именно те метрики, для которых собираюсь настраивать алертинг. Как показала "практика", всегда удобнее создавать алерт на базе панели. Плюсом вы получите сердечко в правом верхнем углу, показывающее статус алерта. ❤️‍🩹

Список Rows
Распределить панели я решил по следующим строкам:
- Logging
- Cluster (Nodes)
- Storage (Volumes)
- Replicas
- Requests/Limits
- Resource Real Usage (RAM/CPU/Network)

Расскажу о каждой по отдельности.

Row I: Logging
Одна панель с источником данных Loki:

{namespace=~"$namespace", container=~"$container"}

Ранее для логов я использовал отдельный дашборд с кучей панелей, где на каждой панели отображались логи для одного конкретного сервиса. Это было крайне неудобно, особенно для разработчиков, которым нужен регулярный доступ к логам. Колхоз! Гораздо удобнее делать это через переменные, как указано в запросе выше и с помощью одной панели.

Row II: Cluster
"Сырая" строка, содержащая совсем небольшую информацию о рабочих узлах, а именно количество узлов и использование CPU/RAM с возможностью фильтра по $namespace.

Row III: Storage
Просто список PVC. В своей работе я их не использую, но есть несколько томов для Loki и Prometheus.

Row IV: Replicas
Строка, содержащая панели, связанные с репликами и контейнерами. Тут целых пять панелей, которые позволят полностью отследить падение сервиса и его причину. Самый простой способ - повесить алерт на Container Restarts Total, тем самым отслеживая количество рестартов, а затем уже просматривать остальные панели. Но можно сделать алерт по Container Phase, чтобы отслеживать контейнеры со статусом "Failed" или "Pending" (об этом чуть дальше). Container Last Terminated Reason помимо проблемного контейнера отобразит метрику reason (например OOMKilled), где будет указана причина падения. Свободный простор для алертов!
P.S. NoData - нормальное состояние для панелей из этой строки. Это показывает, что всё ок

Row V: Requests/Limits
Очень важно отслеживать доступные для запросов и лимитов ресурсы, чтобы избежать неприятностей с запуском и работоспособностью подов! В строке Replicas есть панель, позволяющая отслеживать поды в статусе Pending, но лучше держать отметку свободного Memory на безопасной отметке. (на личном опыте).

Row VI: Resource Real Usage
Отслеживание потребления CPU/Memory подами и пропускной способность сети. Можно оформить в виде таблицы, что я сначала и сделал. Результат убил в прямом смысле слова, но не меня, а графану (до 10 раз возросло потребление RAM, OOMKilled из-за больших нагрузок 😁). Советую оставить в виде Time Series.

Ссылка на Dashboard: тык