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 и аналогичные безопасные методы в других языках.

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

Привет!
Коллеги проводят исследование, чтобы понять, что реально происходит внутри ИТ-команд и какие закономерности можно в этом увидеть.

Уже нащупаны интересные корреляции:
– между скоростью пайплайнов и качеством code review,
– между алертингом и стабильностью релизов,
– между ролями в команде и удовлетворённостью релизным процессом.

Но нужно больше данных, чтобы отделить закономерности от шума.

Пройти анкету можно за 10 минут. Её же можно использовать как мини-чек-лист для самооценки зрелости инженерной культуры.

Принять участие: https://forms.gle/NszR7VDuXL9sBbVAA

P.S. Вчера прошел сам, довольно интересно будет посмотреть на результаты, коими обязательно поделюсь, после того как ребята завершат исследование

P.P.S. Довольно давно не выходило моих постов про инфру — подготовка идет полным ходом. Скоро возобновлю регулярные посты про кубер в проде

Создание production кластера kubernetes под управлением Talos Linux

Начинаем цикл видео про production ready k8s кластер

YouTube — https://youtu.be/_QwJRZa52QU
ВКВидео — https://vkvideo.ru/video-232188619_456239018
Ну и буду прикреплять к посту в Telegram

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

P.S. Забыл в видео удалить токен после flux bootstrap. Не забудьте это сделать!

Полезные ссылки и информация, которые вам потребуются при просмотре видео:

Proxmox terraform provider. Документация по добавлению пользователя для terraform

Репозиторий с конфигами для terraform

Установка talosctl

Установка kubectl

Установка helm

Установка flux

Talos Image Factory

Установка cilium в кластер talos

Flux Bootstrap Gitlab

Доклад про Talos от Дмитрия Рыбалки

Список разрешений для пользователя terraform:

SDN.Use, VM.Monitor, Datastore.AllocateSpace, VM.Clone, VM.Allocate, VM.Config.Options, VM.Config.Memory, VM.Config.HWType, VM.Config.CPU, VM.Config.Cloudinit, VM.Config.Disk, VM.PowerMgmt, Datastore.Audit, VM.Config.Network, VM.Config.CDROM, VM.Audit

.terraformrc:

provider_installation {
  network_mirror {
    url = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

Команда для flux bootstrap:

GITLAB_TOKEN=<токен> flux bootstrap gitlab \
  --owner=<repo_group> \
  --repository=<repo_name> \
  --path=cluster \
  --hostname=gitlab.example.com \
  --components-extra='image-reflector-controller,image-automation-controller' \
  --read-write-key \
  --deploy-token-auth

Процесс обновления Talos Linux

YouTube — https://youtu.be/ikiPtVs78YI
ВКВидео — https://vkvideo.ru/video-232188619_456239020

Команды, которые вам потребуются:

Просмотр списка доступных нод — kubectl get nodes -o wide

Обновление Talos — talosctl -n <ip ноды> upgrade -i registry.example.com/talos:1.11.3

Talos Dashboard - talosctl -n <ip ноды> dashboard

Обновление image в конфигах Talos — sed -i "s|factory.talos.dev/metal-installer/6adc7e7fba27948460e2231e5272e88b85159da3f3db980551976bf9898ff64b:v1.11.2|registry.example.com/talos:1.11.3|" *.yaml

Поднятие локального docker registry — docker run -d -p 5000:5000 --restart always --name registry registry:3

А вот и результаты опроса подъехали!