#aws #vanta #ai #azure

На этом моём скриншоте прекрасно всё.
Добро пожаловать в 2025 год.

Vanta, компания, которая за огромные деньги позволяет проходить аудит от SOC2 до PCIDSS, при помощи AI генерирует рекомендации с несуществующими ресурсами терраформ.

У меня всё.

#kubernetes

Настройка пула соединений для базы данных в Kubernetes.

А как же правильно настроить пул соединений при работе с приложениями в Kubernetes?
У нас же много nodes, PODs, всё динамически, везде скейлинг количества подов.
Не будет ли проблем с тем, что закончились коннекшны к базе и новые поды не смогут подключится?
Проблемы будут, надо считать.

Для начала нам надо понять какая база данных у нас.
Допустим реляционная база данных MySQL.
В зависимости от железа(CPU/Memory) у нас есть разное значение параметра max_connections
Сам параметр этот динамический, значение можно рассчитать и установить самому, либо взять дефолтное(например в облачной базе данных).
Для простоты расчётов будем считать, что у нас max_connections = 1000. Вы берёте свою цифру своего сервера.
- Первым делом нам надо зарезервировать 5 коннекшнов под административные нужды.
Например в случае проблем у нас будет шанс, что мы(инженеры/SRE) сможем к базе подключение сделать.

max_connections_db = max_connections - 5
max_connections_db = 1000 - 5 = 995

- У нас так же включен скейлинг приложений-клиентов через KEDA/HPA со значениями

min PODs = 2, max PODs = 30.

- Для расчета размера пула соединений на под (pool_size_per_pod) используется формула

pool_size_per_pod = floor(max_connections_db / N)

где N текущее количество подов (2 ≤ N ≤ 30).

pool_size_per_pod = floor(995 / 30) ≈ 33 соединения на под

Можно было бы на этом остановится, но это будет ошибка.

У нас время от времени проходит деплой и поднимаются новые реплики, которые тоже занимают пул соединений.
Предположим, что у нас Rolling Update + maxSurge = 25%.
Это означает, что во время деплоя может быть создано до 25% дополнительных подов сверх текущего количества.
Максимальное количество подов с учетом maxSurge

N_max_with_surge = ceil(N × (1 + 0.25)) = ceil(N × 1.25)

и для худшего случая в режиме максимальной нагрузки N=30

N_max_with_surge = ceil(30 × 1.25) = ceil(37.5) = 38

Тогда размер пула соединений на под с учетом maxSurge:

pool_size_per_pod = floor(max_connections_db / N_max_with_surge) = floor(995 / 38) ≈ 26

Итак, мы получили цифру 26.
Теперь мы можем добавить её в переменные окружения нашего golang аппликейшна.

poolSizeStr := os.Getenv("DB_POOL_SIZE")

и в ваш yaml/values файл типа

env:
- name: DB_POOL_SIZE
  value: "26"

Итого: расчет пула соединений это простая арифметика, которая не зависит напрямую от Kubernetes, но требует учета его особенностей (KEDA, maxSurge, несколько дата центров например - не рассматривал в примере выше). Настройка пула соединений обеспечивает стабильную работу системы без превышения лимита соединений даже при максимальном масштабировании и деплое.
Наш расчёт пула соединений на POD (26) учитывает maxSurge = 25%, KEDA (2–30 подов) и резерв в 5 соединений, гарантируя стабильность системы.

* традиционно я мог забыть о чём то и не учесть, могут быть специфичные случаи(например несколько разных микросервисов к одной единой для них БД), я лишь рассматриваю базовый, чтобы вам ну хоть от чего-то отталкиваться в расчётах.

#docker #devsecops #paranoia #devops

Что у нас есть в пайплайнах?
Линтер питон скриптов, валидация YAML, tflint для терраформа, checkov для безопасности, git-leaks, sonarqube, скоринг кода, sast, dast и многое другое. Миллионы всего.
Всем и всё это знакомо.

А что по Dockerfile?
Есть великолепный проект для простых проверок:
https://github.com/hadolint/hadolint

Его можно добавить в pre-commit hook
https://github.com/hadolint/hadolint/blob/master/.pre-commit-hooks.yaml
Можно добавить в pipeline.
Что он умеет?
- проверка и анализ Docker на соответствие лучшим практикам
- интеграция с ShellCheck (моя любовь ❤️), но нужно не для всех
- гибкий конфиг через .hadolint.yaml
- поддержка игнора
- интеграция с CICD

Всё-всё, хватит пустых слов, что он умеет можно почитать и в документации, давайте к практике и примеру.

Добавляем его в наш основной канико(да когда ж ты умрёшь?!) имадж, используемый для сборок:

FROM gcr.io/kaniko-project/executor:v1.23.1-debug

ENV TRIVY_VERSION=0.61.0 \
  CRANE_VERSION=0.19.0 \
  HADOLINT=v2.12.0

RUN wget --no-verbose https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz && \
  tar -zxvf trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz -C /kaniko && \
  rm -f trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz

RUN wget --no-verbose https://github.com/google/go-containerregistry/releases/download/v${CRANE_VERSION}/go-containerregistry_Linux_x86_64.tar.gz && \
  tar -zxvf go-containerregistry_Linux_x86_64.tar.gz -C /kaniko && \
  rm -f go-containerregistry_Linux_x86_64.tar.gz && \
  rm -f /kaniko/LICENSE /kaniko/README.md

RUN wget --no-verbose https://github.com/hadolint/hadolint/releases/download/${HADOLINT}/hadolint-Linux-x86_64 && \
  mv hadolint-Linux-x86_64 /kaniko/hadolint && \
  chmod +x /kaniko/hadolint

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

# Lint the Dockerfile
echo "Executing hadolint check on $dockerfilePath"
/kaniko/hadolint $dockerfilePath --error DL3006 --error DL3007 --failure-threshold error

Что тут проверяем?
- чтобы всегда стоял тег бейз имаджа
https://github.com/hadolint/hadolint/wiki/DL3006
- чтобы тег бейз имаджа был НЕ latest
https://github.com/hadolint/hadolint/wiki/DL3007

Выше пример лишь для двух проверок(полный список есть на гитхабе).
Можно использовать всё и игнорировать что-то(в комментах докерфайла например).
Как вам надо, так и делайте. Конкретно для себя мне нравятся лишь эти две проверки.

Ещё один инструмент в нашем бесконечном списке бесконечных инструментов.

#caddy #nginx

Какой же веб/прокси/реверс-прокси сервер выбрать в 2025 для мелких/простых/пет задач?
Я люблю Caddy последние месяцы. У него много вещей "из коробки" - по дефолту.
Caddy автоматически настраивает HTTPS через Let's Encrypt, в отличие от Nginx, где нужны ручные настройки сертификатов и поддерживает WebSocket без явного указания.
Сильно упрощает жизнь.

Спросите меня, а чем же упрощение?
Отвечу вам просто двумя файлами конфигурацией с идентичной функциональностью.

- конфиг на Nginx

server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    location / {
        proxy_pass http://127.0.0.1:5003;
        proxy_set_header Host $host;
        # websockets
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
server {
    listen 80;
    server_name example.com;
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    }
    return 404;
}

- конфиг на Caddy

example.com {
    reverse_proxy 127.0.0.1:5003
}

Выбор за вами что вам удобнее и проще.

* не является рекомендацией.
** не тестировалось на хайлоаде, где Nginx обычно эффективнее.
*** Caddy может потреблять больше ресурсов, чем с Nginx (go-based vs С-based)

Kaniko is dead
🧊 This project is archived and no longer developed or maintained. 🧊

https://github.com/GoogleContainerTools/kaniko

#мысли

В DevOps-практиках не хватает* термина alert fatigue.

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

Что с этим делать?
Пока точного решения нет.
Есть общие идеи, которые кажутся очевидными всем:
- Сократить количество алертов, настраивая их на основе SLA/SLO, чтобы фокусироваться только на метриках, - влияющих на бизнес-цели и пользовательский опыт.
- Группировать связанные уведомления в единые инциденты.
- Регулярно пересматривать и удалять устаревшие алерты.
- Автоматизировать рутинные действия для низкоприоритетных проблем.

Мне кажется, что наше будущее - за группировкой алертов в единые инциденты.

Рассмотрим пару примеров.
Представьте ситуацию: на одном из подов с базой данных закончилось место на диске (PV).
В результате мы получаем множество алертов:
- Ошибка репликации между нодами кластера.
- Нехватка места на PV.
- Рестарт проб на поде (не всегда).
- Ошибки от приложений, подключающихся к базе данных (до 50 алертов).
- Высокий IOPS (честно говоря не понимаю природу почему IOPS растёт, когда диск резко в 0 уходит, возможно, из-за интенсивных попыток записи при заполненном диске).
- Ошибки самого приложения (около 4-6 алертов), не связанные с инфраструктурой.
- Status Page тоже сигнализирует о проблеме.
И это далеко не всё.

Добавим вторую ситуацию.
Выпустили новую версию приложения и допустили ошибку в работе с API.
В результате мы видим алерты:
- Повышенная латентность API (ответы >500 мс)
- Увеличение количества HTTP 500 ошибок
- Превышение лимита времени ожидания (timeout) на стороне клиента
- Высокая загрузка CPU на серверах приложения из-за бесконечного цикла в коде
- Ошибки в логах приложения, связанные с некорректной обработкой запросов(opensearch monitor).
- Status page сервиса пишет о деградации

В единичном случае такая картина полезна: мы видим полную информацию и быстро понимаем источник проблемы. Но при масштабировании или повторении подобных инцидентов количество алертов становится неуправляемым, и мы начинаем их игнорировать.
При группировке алертов, например, в Slack, логично создавать отдельный тред для каждого инцидента.
Все связанные алерты отправляются в этот тред. Внутрь одного инцидента
Если в компании есть дежурный (on-call), он автоматически подписывается на тред (современные инструменты, такие как PagerDuty или Opsgenie, это поддерживают) и видит все уведомления в контексте.
Остальные инженеры и продакт-оунеры не отвлекаются на шум.

Как это реализовать?
Пока идей немного.
Можно разработать собственную систему управления инцидентами(Incident Management System) или использовать готовое решение с поддержкой AI, таких как PagerDuty или Splunk On-Call, которые уже умеют коррелировать алерты.

Чего ждать в будущем?
Думаю мы всё же должны прийти к группировке алёртов в единые инциденты.
Что получится в итоге мы узнаем лишь спустя время.

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

#docker #troubleshooting #одинденьизжизни

"Тревога-тревога, волк унёс зайчат!"
"Алекс, не работает VPN"
И сразу от нескольких человек.

Ну не работает, ну ладно.
Чего хоть не работает? Спрашиваем.
Ага, с ресолвами.
Ага, с доступом до ресурсов. Снова днс.
Пробую сам сделать коннект - ошибка.
Захожу в аминку впн - ошибка в UI.
Ладно.

Хер знает как у нас работает впн, сам никогда не лез.
Сам только тыкал мышкой в "коннект" на клиенте и всё.
Заходим в репозиторий с VPN/infra.
Ага, виртуальная машина, внутри докеры-полупокеры, юзердата шелл скрипт и tailscale админка.

Ну в целом понятно.
Всё на виртуалке, никаких кубернетисов.
Логи вряд ли мне, несведущему, чему-то помогут, пойдём сперва попроще.
Что может быть? Может диск заполнился.
Графана, дашборд node exporter - всё ок. Ни скачков по диску, ни по IOPS, ни по сети.
Эм, ну ок.
Может ажур поднасрал? Ни автоапдейтов, ни ивентов, ничего по ажуру.
Жаль, а так хотелось поху*сосить ажур снова.

Ну чо, впн это блокер для команды, нет времени разбираться.
Семь бед - один ресет.
Захожу в ажур, выбираю VM, делаю рестарт.
Помогло, но лишь частично - админка UI заработала и начали работать коннекты, но проблема с днс осталась.
Копаем дальше.
Дальше нырнув в код, вижу есть и пара других VM в инфре для впн.
У них так же явный трабл с DNS.
Ну я же синёр - повторяем семь бед - один ресет обеих тачек.
После рестарта всё заработало, клиенты довольны, команда больше не в блокере, днс ресолвит.

Теперь можно налить чай и дебажить "а чо было", да и надо куда-то часы трекера списать.
На час окунулся в логи приложения - ничего особо не понял, я половины терминов и компонентов даже не знаю, ну так же про днс что-то.
Пошли на виртуалки. Джампхост, ссш, шелл.
Смотрим какие у нас services есть, доступны ли все.
Все есть, все доступны.
Однако логи докера(компоуз) дали наводку.

~$ sudo journalctl -u docker
...
****** 02 14:41:32 ******-vm-us-3 dockerd[1989830]: time="20**-06-02T14:41:32.495924354Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:57484" dns-server="udp:12>
****** 05 05:43:42 ******-vm-us-3 dockerd[1989830]: time="20**-06-05T05:43:42.432809963Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:60244" dns-server="udp:12>

И так по кругу на миллион сообщений.
Значит проблема не со стороны аппликейшна в докере(компоузе), а с сетью - уровень докер лейера или операционной системы(скорее всего).
Ладно, а чо у нас с остальными логами.
Видим, что утром начался авто апдейт (unattended-upgrades в убунту).
То есть авто апдейт не на уровне ажура, а самой операционке.

******-06-10 06:17:03,994 INFO Starting unattended upgrades script
******-06-10 06:17:03,995 INFO Allowed origins are: o=Ubuntu,a=jammy, o=Ubuntu,a=jammy-security, o=Docker,a=jammy, o=UbuntuESMApps,a=jammy-apps-security, o=UbuntuESM,a=jammy-infra-security
******-06-10 06:17:03,995 INFO Initial blacklist: 
******-06-10 06:17:03,995 INFO Initial whitelist (not strict): 
******-06-10 06:17:09,777 INFO Packages that will be upgraded: apport libnss-systemd libpam-systemd libsystemd0 libudev1 python3-apport python3-problem-report systemd systemd-sysv udev
******-06-10 06:17:09,777 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
******-06-10 06:18:00,563 INFO All upgrades installed

И.. и всё, компонент systemd-resolved не захотел подниматься после апдейта.

****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: Positive Trust Anchors:
****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: . IN DS 20326 8 2 e06d44b80b8f1d3457104237c7f8ec8d
****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: Negative trust anchors: home.arpa *.in-addr.arpa *.172.in-addr.arpa ***.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: Using system hostname '******-vm-us-3'.
****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: Failed to connect to system bus: Permission denied
****** 10 06:17:24 ******-vm-us-3 systemd-resolved