Добавляем grafana в кластер

Мы добавили loki для хранения логов, fluentbit для отправки логов в loki. Теперь пришел черед добавить графану, чтобы логи можно было смотреть

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

1. Добавляем файл 13-grafana.yaml. Указываем, что устанавливать будем после fluentbit и добавляем раздел decryption, так как нам потребуются секреты

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

3. В компонентах создаем namespace.yaml

4. Добавляем cert.yaml. Он нам понадобится для защищенного доступа к графане через ingress

5. Создаем admin-password-secret.yaml. Здесь прописываем две ENV переменные для графаны, которые содержат имя пользователя и пароль администратора для доступа через веб-интерфейс

Шифруем через sops:

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

6. Добавляем ingress.yaml, чтобы получить доступ к графане извне. Не забываем прописать tls секцию и имя секрета с сертификатом

7. Ну и наконец hr-grafana.yaml. Здесь обратите внимание на раздел envValueFrom, где задаются env переменные, содержащие логин и пароль к графане. Мы указываем, что брать их нужно из нашего секрета, созданного на 5 шаге. Также в разделе datasource мы сразу указываем loki и не даем его изменять из веб-интерфейса

8. Пушим всё в репозиторий. Дожидаемся применения в кластере. Если все прошло по плану - по адресу grafana.example.com (само собой нужно заменить на свой домен) вы увидите веб-интерфейс графаны. Логинимся с указанным нами логином и паролем. Заходим в раздел Explore, в разделе Label filters выбираем namespace, по подам которого мы хотим посмотреть логи и нажимаем Run Query. Получаем картину со скрина к посту

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

Stay tuned!

Добавляем Prom++ в кластер

Праздники закончились. Пора снова писать посты :) Графана есть. Логи собираются. Теперь нужно настроить маломальский мониторинг

Раньше для этого использовался Prometheus, сейчас модно использовать Victoria Metrics, так как эта система потребляет меньше ресурсов. Но не так давно ребята из компании Флант зарелизили свой prometheus совместимый инструмент, еще более экономичный. В прод его тащить рановато, но ничто нам не мешает попробовать запустить prompp в dev кластере

Начнем:

Первым делом нам нужно поставить kube-prometheus-stack. Данный helm чарт включает в себя много всего, но мы будем пока что использовать следующий набор компонентов:

kube-state-metrics - отвечает за сбор разных метрик кластера
prometheus-operator - управляет созданием инстансов прометеуса. Им мы будем создавать инстанс prompp
prometheus-node-exporter - экспортер метрик хостовой системы на нодах нашего кластера

1. Добавляем 14-kube-prometheus-stack.yaml

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

3. Добавляем namespace.yaml. В этом namespace у нас будут жить все компоненты мониторинга

4. Добавляем kube-prometheus-stack.yaml

Здесь отключаем установку графаны, алертменеджера (алертами займемся позже) и самого prometheus, так как мы будем ставить prompp через оператор

Теперь мы можем установить сам prompp:

5. Добавляем 15-prompp.yaml. Он будет устанавливаться после kube-prometheus-stack

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

7. Добавляем prompp.yaml. Указываем storage class и объем места под хранение метрик

Пушим всё в репо, дожидаемся выполнения через flux. По итогу в namespace monitoring должны появиться поды всех компонентов. Node exporter запустится в кол-ве двух штук, по одному на ноду кластера

Вот и всё! В следующем посте будем подключать это добро к графане и добавлять необходимые дашборды

Ребрендинг :)

Как вы уже заметили - у меня небольшой ребрендинг. Привел название канала в соответствии с контентом и наконец-то сделал логотип.

P.S. Следующий пост немного задержался в пути, но в выходные должен доехать!

Добавляем 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 за совет