Добавляем datasource prompp и дашборды в графану

В прошлом посте мы добавили систему мониторинга в наш кластер. Сегодня будем подключать ее к графане и импортировать дашборды, с помощью которых можно отслеживать состояние серверов и k8s. Другие компоненты в dev кластере мониторить не будем, иначе пост получится слишком объемным. Более подробно мониторинг всех компонентов рассмотрим при создании production кластера

Немного о том как принято организовывать мониторинг в кластерах k8s:

Создатели софта, который нативно работает в кубе обычно предоставляют в своих helm чартах специальную prometheus сущность. Это может быть ServiceMonitor или PodMonitor. В них описано куда и как стучаться, чтобы получить метрики. Prometheus автоматически подхватывает такие описания и начинает сохранять к себе метрики данного софта. Так же у сервиса или пода можно еще указать специальные аннотации, чтобы prometheus понял, что нужно получать с них метрики - prometheus.io/scrape: "true" и prometheus.io/port: "10254"

Давайте приступим к настройке:

1. В прошлом посте мы забыли выдать для prompp необходимые права для получения метрик. Давайте исправляться. Добавляем rbac.yaml и прописываем service account, который в нем создается в prompp.yaml. Также указываем прометею получать данные из всех service monitor и pod monitor. Сами мониторы уже были созданы при установке kube-prometheus-stack в прошлом посте. Их список можно получить командой kubectl get servicemonitor -n monitoring

2. Тюним kube-state-metrics, чтобы можно было получать данные по daemonset в дашборде по кубу

3. Добавляем в графану datasource prompp

4. Определяем дашборд провайдер для тех дашбордов, которые мы будем добавлять из кода

5. Ну и наконец добавляем сами дашборды. Здесь используется два пути. Популярный дашборд по мониторингу железа на нодах мы добавляем по ID с официальной страницы дашборда на сайте графаны.
Дашборд для k8s добавляем по URL с гитхаба от Артура Крюкова, советую заглянуть к нему на канал, там тоже много полезного по кубу. В production кластере мы еще будем получать дашборды из ConfigMap, но в dev кластере не вижу смысла заморачиваться

Пушим всё в репо. Дожидаемся применения. Если все прошло хорошо, то вы увидите картину как на картинке к посту. И оба дашборда будут работать

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

Stay tuned!

PHP 30 лет!

В этом году исполняется 30 лет языку программирования, без которого современный веб был бы совсем другим — PHP!

PHP переживал взлёты и падения, «пророчества о смерти», но каждый раз доказывал свою актуальность и способность к развитию.
Сегодня мы живем в мире неумирающей модели запуска, кажется вот-вот в языке появится true async.
Язык остаётся востребованным, понятным и живым.

💬 Спасибо всем, кто писал, пишет и будет писать на PHP.
🛠 Спасибо сообществу, которое делает его лучше.
🚀 И вперёд — к новым 30 годам стабильности, скорости и простоты.

С днём рождения, PHP! 🐘💙

Теперь можно раскрыть карты :) Я в программном комитете и курирую DevOps трек. Приходите обязательно!

Добавляем метрику к приложению

В прошлых постах мы добавили мониторинг в наш кластер. Сегодня мы добавим свою метрику в демо-приложение.
В данном случае будем просто записывать рандомное число как значение метрики при обращении к определенному эндпоинту.
Для хранения метрик используем плагин metrics из поставки RoadRunner

Давайте приступать:

1. Устанавливаем пакет для работы с метриками RoadRunner из приложения - composer require spiral/roadrunner-metrics
2. Прописываем в .env файл адрес, куда будем подключаться для отправки метрик
3. В конфиге .rr.yaml включаем дополнительные http метрики для самого RR
4. Добавляем в конфиг нашу метрику. Ее можно определять и из приложения, но для демо я сделал как в примере из документации и определил все в конфиге RR
5. Делаем команду для установки значения метрики и хэндлер для нее. Тут можно было бы сделать более правильно, вынести подключение к RR за пределы хэндлера, но для демонстрации я не стал усложнять
6. Прописываем настройки DI, передаем в хэндлер адрес для подключения к RR из env переменной
7. Добавляем эндпоинт, обращаясь к которому, будет происходить запись значения в метрику

Все готово! Локально можно поднять проект, подергать наш эндпоинт, зайти в контейнер и посмотреть записывается ли метрика - curl http://127.0.0.1:8081/metrics

Пушим изменения в репо (Там помимо добавляения самой метрики еще обновлены зависимости проекта и рантайма)

Вот так просто с помощью RR можно отдавать метрики приложения в prometheus формате

В следующем посте рассмотрим как это все подключить с инфраструктурной точки зрения и посмотреть в графане

Коллега сегодня скинул любопытную статью. Советую ознакомиться и применить советы по предотвращению подобных атак у себя

https://habr.com/ru/articles/918570/

Прикручиваем метрику приложения к Grafana

В прошлом посте мы добавили метрику в наше приложение. Пришла пора написать ServiceMonitor для сбора данной метрики и метрик RoadRunner, а также добавить необходимые дашборды в Grafana

Давайте приступать:

Первым делом мы должны поправить helm chart приложения. Мы добавим в service порт для сборка метрик, чтобы prompp мог их собирать

— Добавляем label app.kubernetes.io/component, чтобы ServiceMonitor мог найти нужный сервис по данному лэйблу

— Добавляем описание самого порта

— Прописываем дефолтные здачения в values.yaml. Метрики приложения отдаются по порту 8081 согласно конфигу RR

Пушим всё в репо приложения

В инфраструктурном репозитории нам нужно для начала добавить кастомные ресурсы для prometheus operator. Это необходимо сделать в самом начале установки кластера, так как ServiceMonitor приложения будет применен раньше, чем установится kube-prometheus-stack и если кастомных ресурсов не будет — применение манифестов app-example завершится неудачей

1. Добавляем 00-prometheus-operator-crds.yaml

2. Прописываем его в kustomization.yaml

3. Делаем зависимость установки MetalLB от prometheus-operator-crds

4. Добавляем в app-example service-monitor.yaml. Тут указываем по какому порту будем обращаться к приложению, чтобы получить метрики. Указывается имя порта, которое было задано в helm chart. Указываем, что забираем метрики по http, используем для этого путь /metrics. Этого файла достаточно, чтобы начать собирать метрики RR и нашу метрику приложения

5. Остается метрики отобразить в графане. Будем использовать еще один способ добавления дашбордов. Создаем ConfigMap grafana-dashboards-cm.yaml, который будет содержать dashboard RoadRunner HTTP, взятый отсюда, и dashboard метрики приложения, который я накликал в web-интерфейсе графаны и экспортировал в json

6. Добавляем в настройки графаны dashboard provider, который будет добавлять дашборды из ConfigMap

7. Говорим графане из какой именно ConfigMap брать дашборды

Вот и всё. Осталось запушить изменения в инфраструктурный репозиторий и дождаться применения их в кластере. В результате в графану добавится dashboard для RR и для нашей метрики. Несколько раз повызывайте эндпоинт set-random-metric, чтобы в дашборде метрики что-то менялось

Мы молодцы! В следующем посте начнем подключать алертинг в систему мониторинга

Подключаем алерты с помощью Prometheus Alertmanager

У нас настроен мониторинг, рисуются красивые графики, но мы не можем сидеть и смотреть на них целый день

Чтобы быть осведомленным о проблемах — нам нужны оповещения об аномалиях или алерты

Настраивать мы их будем с помощью компонента Prometheus Alertmanager

Погнали:

1. Добавляем 16-alertmanager.yaml. Указываем, что тут у нас будут шифрованные секреты и нужно их расшифровывать с помощью sops

2. Прописываем его в kustomization.yaml

3. Добавляем компонент — alertmanager.yaml. Он разворачивается с помощью Prometheus Operator из состава kube-prometheus-stack

Из важного — указываем имя секрета, из которого будет браться конфиг алертменеджера:

configSecret: alertmanager-config

4. Дальше берем конфиг следующего содержания

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.example.com:465'
  smtp_require_tls: false
  smtp_auth_username: "mail@example.com"
  smtp_auth_password: "суперпуперпароль"
route:
  group_interval: 5m
  group_wait: 10s
  repeat_interval: 3h
  group_by: ['alertname', 'priority']
  receiver: mail

  routes:
    - matchers:
        - severity=~critical|warning
      receiver: mail

receivers:
- name: mail
  email_configs:
  - to: 'alert@example.com'
    from: 'mail@example.com'
    send_resolved: true

Отправлять алерты будем на почту и только уровня warning и critical. Алертменеджер умеет отправлять уведомления также в телеграм и другие источники. Полный список можно найти здесь

Берем данный конфиг, записываем в файл и делаем base64 file.txt. Полученный текст вставляем в kubernetes secret config-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-config
  namespace: monitoring
data:
  alertmanager.yaml: |
    Z2xvYmFsOgogIHJlc29sdmVfdGltZW91dDogNW0KICBzbXRwX3NtYXJ0aG9zdDogJ3NtdHAuZXhh
    bXBsZS5jb206NDY1JwogIHNtdHBfcmVxdWlyZV90bHM6IGZhbHNlCiAgc210cF9hdXRoX3VzZXJu
    YW1lOiAibWFpbEBleGFtcGxlLmNvbSIKICBzbXRwX2F1dGhfcGFzc3dvcmQ6ICLRgdGD0L/QtdGA
    0L/Rg9C/0LXRgNC/0LDRgNC+0LvRjCIKcm91dGU6CiAgZ3JvdXBfaW50ZXJ2YWw6IDVtCiAgZ3Jv
    dXBfd2FpdDogMTBzCiAgcmVwZWF0X2ludGVydmFsOiAzaAogIGdyb3VwX2J5OiBbJ2FsZXJ0bmFt
    ZScsICdwcmlvcml0eSddCiAgcmVjZWl2ZXI6IG1haWwKCiAgcm91dGVzOgogICAgLSBtYXRjaGVy
    czoKICAgICAgICAtIHNldmVyaXR5PX5jcml0aWNhbHx3YXJuaW5nCiAgICAgIHJlY2VpdmVyOiBt
    YWlsCgpyZWNlaXZlcnM6Ci0gbmFtZTogbWFpbAogIGVtYWlsX2NvbmZpZ3M6CiAgLSB0bzogJ2Fs
    ZXJ0QGV4YW1wbGUuY29tJwogICAgZnJvbTogJ21haWxAZXhhbXBsZS5jb20nCiAgICBzZW5kX3Jl
    c29sdmVkOiB0cnVlCg==

Ну и шифруем его с помощью sops:

sops --encrypt --encrypted-regex '^(data|stringData)$' --pgp 'B1B740FC8FCA25D9BE0C118CED0FB16FAF7A8471' --in-place config-secret.yaml

5. Отключаем дефолтные правила алертов из kube-prometheus-stack, так как многие относятся к prod ready кластеру и в dev будут просто постоянно висеть и раздражать нас

6. Говорим prompp, что нужно собирать все правила алертов во всех неймспейсах и отправлять их на сервис нашего alertmanager

7. Ну и добавим одно простое правило для алертов в prometheus-rules.yaml. Если количество подов Deployment равно нулю в течении одной минуты — будем присылать алерт. Правило тут задается с помощью PromQL, в секции expr. В описании потом можно использовать все labels, которые можно получить, выполнив promql запрос

Готово! Пушим всё в репо, дожидаемся применения и проверяем наш алерт:

Отскейлим наше приложение до нулевого кол-ва реплик

kubectl -n app-example scale deployment/app-example-deployment --replicas=0

Дождемся уведомления

Отслейклим обратно

kubectl -n app-example scale deployment/app-example-deployment --replicas=1

Все прекрасно работает!

На этом цикл постов, посвященный dev кластеру почти завершен, дальше начнем готовить prod кластер

Нам осталось рассмотреть еще одну тему — обновление кластера до свежих версий k8s

Скорее всего данный процесс я продемонстрирую в виде стрима или запишу видео

Stay tuned!

PHP_INI_DIR

Я тут немного приболел, поэтому постов давно не было

Голос еще не очень нормальный, видео по обновлению куба будет позже

Ловите пока маленький лайфхак, о котором мне рассказал Валентин Удальцов

Раньше я prod конфиг в докерфайле копировал примерно так:

RUN cp /usr/local/etc/php/php.ini-production /usr/local/etc/php/php.ini

Но оказалось, что есть в PHP образах переменная среды PHP_INI_DIR и можно сделать так:

RUN cp ${PHP_INI_DIR}/php.ini-production ${PHP_INI_DIR}/php.ini

На этом на сегодня все. Не переключайтесь!

Корректный инкремент версии при публикации Helm chart

В посте про упаковку приложения в Helm chart я использовал переменную гитлаба CI_JOB_ID как patch версию чарта. Это не совсем корректно и на больших инсталляциях гитлаба там будут не очень разумные цифры

Давайте исправляться. Совместно с ChatGPT насочинял скрипт, который делает следующее:

1. Пытается получить последнюю версию опубликованного в гитлабе helm чарта приложения
2. Если мы еще ничего не публиковали — берет версию из Chart.yaml
3. Инкрементирует патч версию
4. Пакует и публикует чарт в gitlab package registry

На раннере нам потребуется утилита jq (Она доступна в большинстве репозиториев популярных linux дистрибутивов) и yq (тут нужна версия 4.x, поэтому ставьте любым доступным методом, описанным в секции Installation. В репозитории вашего дистрибутива скорее всего будет 3.x)

Ну и собственно сам коммит с изменениями. Коммитим, пушим, проверяем, что все корректно работает

Enjoy!

Используем GitVersion для получения версии helm chart

В комментариях к посту про версию helm chart @ebugusey предложил считать версию из истории коммитов при публикации чарта. И посоветовал софт GitVersion

Это еще более правильный и простой способ определения версии и он не требует похода в API гитлаба

Нам понадобится скачать версию для linux x64 на машину с gitlab-runner (Или вы можете использовать docker образ), также будем использовать jq — для получения нужного нам значения из выхлопа GitVersion

Давайте вносить правки:

1. Говорим гитлаб раннеру при запуске джобы склонировать репозиторий со всей историей коммитов (Это может замедлить джобу на больших репозиториях при первом запуске)

2. Добавляем в корень репозитория конфиг для GitVersion. Взял его из примеров в документации

3. Получаем новую версию для упаковки чарта

Вот и все правки. Мы получили более стабильный вариант расчета версии, не требующий похода в API. Спасибо @ebugusey за совет

Обновление dev кластера k8s до актуальной версии

Вот наконец и дошли руки записать видео по обновлению dev кластера. На этом про кластер для разработки всё. Вскоре начнем собирать production ready инсталляцию

YouTube — https://www.youtube.com/watch?v=_C5DLcAtQMA
ВКВидео — https://vkvideo.ru/video-232188619_456239017

Пых.Конф всё ближе, свободного времени всё меньше, поэтому с постами пока затык

Раз так — буду шарить полезное от коллег. Сегодня нововведения и изменения в недавно вышедшем кубе 1.34 от компании Флант

Приятного чтения — https://habr.com/ru/companies/flant/articles/940394/

Опасные места в YAML

YAML позиционируется как человекочитаемый формат данных, но при этом это склад подводных камней. Рассмотрим самые тупые особенности, которые могут привести к неожиданным ошибкам.

Шестидесятеричные числа

port_mapping:
  - 22:22
  - 80:80
  - 443:443

Что вы ожидаете увидеть? Скорее всего, список строк для настройки портов. Но YAML 1.1 интерпретирует 22:22 как шестидесятеричное число и превращает его в 1342. В YAML 1.2 эту "фичу" убрали, но многие парсеры до сих пор используют старую версию.

Проблема Норвегии

countries:
  - dk
  - fi 
  - is
  - no  
  - se

Код страны Норвегии no будет интерпретирован как булево значение false. То же самое произойдет с off, n, yes, on, y в различных вариантах написания. Классическая ловушка, получившая название "Norway Problem".

Случайные числа

versions:
  - 9.5.25  # строка
  - 9.6.24  # строка
  - 10.23   # Число!
  - 12.13   # Тоже число!

Строки без кавычек могут неожиданно стать числами. 10.23 превратится в float, а 9.5.25 останется строкой, потому что имеет "слишком много" точек.

Ключи не только строки

settings:
  on: [push, deploy]
  priority: high

Здесь on интерпретируется как булево true, поэтому ключом становится не строка "on", а логическое значение. В JSON это может превратиться в "True" или вызвать ошибку.

Теги и небезопасность

user_data: !python/object/apply:subprocess.check_output [['rm', '-rf', '/']]

Теги, говорят, иногда полезны, но при определенных условиях позволяют выполнять произвольный код при загрузке. Всегда используйте safe_load вместо load в Python и аналогичные безопасные методы в других языках.

Получил свой первый сертификат по кубу. Теперь я сертифицированный кубовод)