#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

#security #git #devops

Часть 2 из 2.

- теперь мы выдыхаем, принимаем решение и чистим

git reflog expire --expire=now --all && git gc --prune=now --aggressive

Это мы почистили ЛОКАЛЬНО гит, пока на ремоут сервер не заливали.
- проверяем, что локально всё чисто

cd ..
>gitleaks detect --source qlib --log-opts="--all" --report-path findings.json

    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks

12:29PM INF 1790 commits scanned.
12:29PM INF scan completed in 722ms
12:29PM INF no leaks found

То есть проверка показала, что все токены и пароли были удалены.
- крестимся и пушим в ремоут

cd qlib
git push origin --force

Всё, история в нашем форке почищена.
Можно ещё раз проверить всё
- удаляем локальный репозиторий

cd ..
sudo rm -r qlib

- клонируем с ремоута

git clone git@github.com:kruchkov-alexandr/qlib.git

- проверяем на утечки

gitleaks detect --source qlib --log-opts="--all" --report-path findings.json

    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks

12:33PM INF 1790 commits scanned.
12:33PM INF scan completed in 731ms
12:33PM INF no leaks found

- радуемся, что даже в истории гита нет утечек

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

Инструкция длинная, кажется сложно, но на самом деле это лишь 5 команд и всё.
Не бойтесь. Вы - инженер.

#aws

Абсурд и наркомания.

Однажды какой-то безопасник скажет.
Везде и всем всё запретить.
Задачу надо как-то выполнять.
Закрываем одно, второе, третье.
Наступает момент лютейшего бреда, когда тебе говорят ограничить доступ, оставить только для гитхаб раннеров.
Задачу надо как-то выполнять.
Ты идёшь и смотришь, а чего с пулом

curl -s https://api.github.com/meta | jq '.actions | length'
5265

Ух, пробрало, как сладко.
А потом читаешь
https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html
Оказывается на один уникальный порт в рамках одной секьюрити группы можно повесить лишь 60 правил.
Задачу надо как-то выполнять.
А это значит тебе надо создать примерно сотню SG, по 60 правил в каждом чтобы поддержать желание инфобезы/аудитора... Стоп-стоп, какой сюр, прекрати.
Задачу надо как-то выполнять.
На этом моменте тебя тошнит от бреда, ты пишешь аудитору/инфобезе "я не смогу это сделать, технически нельзя выдать доступ только для гитхаб раннеров и больше никому, вот пруфы".
Смело закрываешь таску и идёшь заниматься настоящей работой, а не Великими фантазиями Великих Всезапрещальщиков.

* Не знаю есть ли вообще решение, но мне проще порт нахрен закрыть, чем 5.3к рулсов куда-то запиливать.

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