#azure #metrics #aks
А какие же есть преимущества у ажура?
Всратость❤️.
Взять, к примеру, метрики контрол плейна.
На одном кластере оно может показать нормальную метрику
На другом кластере показать 500.000 рпс.
А на третьем кластере прыгать от 30 до 300.000 рпс.
Завтра везде будет уже по нулям.
Добро пожаловать в ажур❤️.
* реальное значение около 50-60
А какие же есть преимущества у ажура?
Всратость❤️.
Взять, к примеру, метрики контрол плейна.
На одном кластере оно может показать нормальную метрику
apiserver_request_total - ожидаемое около 30 рпс.На другом кластере показать 500.000 рпс.
А на третьем кластере прыгать от 30 до 300.000 рпс.
Завтра везде будет уже по нулям.
Добро пожаловать в ажур❤️.
* реальное значение около 50-60
😁10😱4🤡1
#пятница
Я:
Выйду, пожалуй, на улицу.
Потрогать траву, посмотреть на людей и стены, подышать воздухом.
Лишь бы ничего не напоминало о работе. Забыть обо всём.
Улица:
Ага, ну давай🤣
Я:
Выйду, пожалуй, на улицу.
Потрогать траву, посмотреть на людей и стены, подышать воздухом.
Лишь бы ничего не напоминало о работе. Забыть обо всём.
Улица:
Ага, ну давай
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣11🐳1💯1
#caddy #nginx
Какой же веб/прокси/реверс-прокси сервер выбрать в 2025 для мелких/простых/пет задач?
Я люблю Caddy последние месяцы. У него много вещей "из коробки" - по дефолту.
Caddy автоматически настраивает HTTPS через Let's Encrypt, в отличие от Nginx, где нужны ручные настройки сертификатов и поддерживает WebSocket без явного указания.
Сильно упрощает жизнь.
Спросите меня, а чем же упрощение?
Отвечу вам просто двумя файлами конфигурацией с идентичной функциональностью.
- конфиг на
- конфиг на
Выбор за вами что вам удобнее и проще.
* не является рекомендацией.
** не тестировалось на хайлоаде, где Nginx обычно эффективнее.
*** Caddy может потреблять больше ресурсов, чем с Nginx (go-based vs С-based)
Какой же веб/прокси/реверс-прокси сервер выбрать в 2025 для мелких/простых/пет задач?
Я люблю Caddy последние месяцы. У него много вещей "из коробки" - по дефолту.
Caddy автоматически настраивает HTTPS через Let's Encrypt, в отличие от Nginx, где нужны ручные настройки сертификатов и поддерживает WebSocket без явного указания.
Сильно упрощает жизнь.
Спросите меня, а чем же упрощение?
Отвечу вам просто двумя файлами конфигурацией с идентичной функциональностью.
- конфиг на
Nginxserver {
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;
}- конфиг на
Caddyexample.com {
reverse_proxy 127.0.0.1:5003
}Выбор за вами что вам удобнее и проще.
* не является рекомендацией.
** не тестировалось на хайлоаде, где Nginx обычно эффективнее.
*** Caddy может потреблять больше ресурсов, чем с Nginx (go-based vs С-based)
👍17
#curl #troubleshooting
История из жизни.
Как-то переводили с одного домена на другой проект.
Доменов много, рулсов много, в одном из пунктов плана перехода была организация редиректов.
Ну типа запилили новый домен, а со старого домена прямо в CloudFlare сделали редирект (+ rules).
Сильно застрял при проверке старого домена с редиректом на новый.
Ну не проходят POST запросы с пейлоад до конечного бекэнда при помощи curl.
Признаюсь честно - долго просидел и тогда не было нейронок, чтобы попробовала бы помочь при дебагинге.
Сейчас бы я сам себя тогдауволил дал леща за тупость и бессмысленную трату времени.
Копал в редиректы, новый домен, неверную архитектуру, терраформ, DNS клауд провайдера и многое другое.
Оказалось дело было не в самом редиректе или домене, а в curl.
То есть всё итак работало, но сами тесты при помощи curl были неправильными.
Ведь обидно, всё облазил, все интернеты, а ответ, как всегда, был на видном месте - в документации
В моем случае надо было добавить два флага:
Source:
https://curl.se/docs/manpage.html#--post301
https://curl.se/docs/manpage.html#--post302
Почему так?
Согласно RFC 7231, при 302 редиректе клиент (например, curl) может по умолчанию изменить метод с POST на GET.
И ваш пейлоад просто аннигилируется, тесты не проходят.🚶♀
Чтобы избежать этого, нужно явно указывать --post302 или же использовать 307 редирект* , который сохраняет метод запроса.
Source:
https://www.ietf.org/rfc/rfc7231.txt
Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.
Вывод: Перед переключением доменов читайте документацию и проверяйте, как редиректы влияют на запросы и разные методы.
* Некоторые DNS/CDN провайдеры имеют лишь ограниченный список поддерживаемых кодов редиректа.
История из жизни.
Как-то переводили с одного домена на другой проект.
Доменов много, рулсов много, в одном из пунктов плана перехода была организация редиректов.
Ну типа запилили новый домен, а со старого домена прямо в CloudFlare сделали редирект (+ rules).
Сильно застрял при проверке старого домена с редиректом на новый.
Ну не проходят POST запросы с пейлоад до конечного бекэнда при помощи curl.
Признаюсь честно - долго просидел и тогда не было нейронок, чтобы попробовала бы помочь при дебагинге.
Сейчас бы я сам себя тогда
Копал в редиректы, новый домен, неверную архитектуру, терраформ, DNS клауд провайдера и многое другое.
Оказалось дело было не в самом редиректе или домене, а в curl.
То есть всё итак работало, но сами тесты при помощи curl были неправильными.
Ведь обидно, всё облазил, все интернеты, а ответ, как всегда, был на видном месте - в документации
В моем случае надо было добавить два флага:
- --location (чтобы курл последовал за редиректом)
- --post302 (not convert POST requests into GET requests when following a 302 redirection)
Source:
https://curl.se/docs/manpage.html#--post301
https://curl.se/docs/manpage.html#--post302
Почему так?
Согласно RFC 7231, при 302 редиректе клиент (например, curl) может по умолчанию изменить метод с POST на GET.
И ваш пейлоад просто аннигилируется, тесты не проходят.
Чтобы избежать этого, нужно явно указывать --post302 или же использовать 307 редирект* , который сохраняет метод запроса.
Source:
https://www.ietf.org/rfc/rfc7231.txt
Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.
Вывод: Перед переключением доменов читайте документацию и проверяйте, как редиректы влияют на запросы и разные методы.
* Некоторые DNS/CDN провайдеры имеют лишь ограниченный список поддерживаемых кодов редиректа.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🔥7❤1
Forwarded from DevOps & SRE notes (tutunak)
Kaniko is dead
https://github.com/GoogleContainerTools/kaniko
🧊 This project is archived and no longer developed or maintained. 🧊https://github.com/GoogleContainerTools/kaniko
GitHub
GitHub - GoogleContainerTools/kaniko: Build Container Images In Kubernetes
Build Container Images In Kubernetes. Contribute to GoogleContainerTools/kaniko development by creating an account on GitHub.
🤯13🔥2🕊1💔1
#мысли
В DevOps-практиках не хватает* термина
Это состояние, когда инженеры и операторы перегружены тысячами уведомлений от систем мониторинга, 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, которые уже умеют коррелировать алерты.
Чего ждать в будущем?
Думаю мы всё же должны прийти к группировке алёртов в единые инциденты.
Что получится в итоге мы узнаем лишь спустя время.
* Скорее всего этот термин уже есть, возможно его придумали миллиард лет до моего рождения, но во всяком случае мы в компании и все мои коллеги/приятели уделяем ему слишком мало времени и не понимаем реальной угрозы бизнесу.
В 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, которые уже умеют коррелировать алерты.
Чего ждать в будущем?
Думаю мы всё же должны прийти к группировке алёртов в единые инциденты.
Что получится в итоге мы узнаем лишь спустя время.
* Скорее всего этот термин уже есть, возможно его придумали миллиард лет до моего рождения, но во всяком случае мы в компании и все мои коллеги/приятели уделяем ему слишком мало времени и не понимаем реальной угрозы бизнесу.
🤔6👍4❤3😱1🤡1🙈1
#docker #troubleshooting #одинденьизжизни
"Тревога-тревога, волк унёс зайчат!"
"Алекс, не работает VPN"
И сразу от нескольких человек.
Ну не работает, ну ладно.
Чего хоть не работает? Спрашиваем.
Ага, с ресолвами.
Ага, с доступом до ресурсов. Снова днс.
Пробую сам сделать коннект - ошибка.
Захожу в аминку впн - ошибка в UI.
Ладно.
Хер знает как у нас работает впн, сам никогда не лез.
Сам только тыкал мышкой в "коннект" на клиенте и всё.
Заходим в репозиторий с VPN/infra.
Ага, виртуальная машина, внутри докеры-полупокеры, юзердата шелл скрипт и tailscale админка.
Ну в целом понятно.
Всё на виртуалке, никаких кубернетисов.
Логи вряд ли мне, несведущему, чему-то помогут, пойдём сперва попроще.
Что может быть? Может диск заполнился.
Графана, дашборд node exporter - всё ок. Ни скачков по диску, ни по IOPS, ни по сети.
Эм, ну ок.
Может ажур поднасрал? Ни автоапдейтов, ни ивентов, ничего по ажуру.
Жаль, а так хотелось поху*сосить ажур снова.
Ну чо, впн это блокер для команды, нет времени разбираться.
Семь бед - один ресет.
Захожу в ажур, выбираю VM, делаю рестарт.
Помогло, но лишь частично - админка UI заработала и начали работать коннекты, но проблема с днс осталась.
Копаем дальше.
Дальше нырнув в код, вижу есть и пара других VM в инфре для впн.
У них так же явный трабл с DNS.
Ну я же синёр - повторяем семь бед - один ресет обеих тачек.
После рестарта всё заработало, клиенты довольны, команда больше не в блокере, днс ресолвит.
Теперь можно налить чай и дебажить "а чо было", да и надо куда-то часы трекера списать.
На час окунулся в логи приложения - ничего особо не понял, я половины терминов и компонентов даже не знаю, ну так же про днс что-то.
Пошли на виртуалки. Джампхост, ссш, шелл.
Смотрим какие у нас services есть, доступны ли все.
Все есть, все доступны.
Однако логи докера(компоуз) дали наводку.
И так по кругу на миллион сообщений.
Значит проблема не со стороны аппликейшна в докере(компоузе), а с сетью - уровень докер лейера или операционной системы(скорее всего).
Ладно, а чо у нас с остальными логами.
Видим, что утром начался авто апдейт (
То есть авто апдейт не на уровне ажура, а самой операционке.
И.. и всё, компонент
"Алекс, не работает 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
🔥8👍3👀3😨2❤1😁1
* аригато Павел Дуров, половина сообщения пропала в предыдущем посте, но ладно.😭
В общем что у нас есть:
- пришёл автоапдейт пакетов операционной системы
- после апдейта не поднялся
- на вм начались проблемы, впн не работает
- все кричат про неработающий впн
Что будем делать? А ничего.
Это такой уровень шизы контроля, что делать ничего не будем.
Автоапдейты не хочется отключать.
Ставить какие-то алерты, автофайловеры, отслеживание логов - всё это бред.
Бизнес никогда не примет и не поймет все часы, которые уйдут на превентивные меры подобной задачи.
За два года аптаймов этих ВМ это впервые. Маловероятно, что это повторится ещё года два.
Поэтому просто пишем коллегам о кейсе, пишем postmortem и идём дальше жить и работать.
Трекаем часы и возвращаемся к своим кубернетисам.
****** 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 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
****** 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[2663737]: Could not create manager: Permission denied
****** 10 06:17:24 ******-vm-us-3 systemd[1]: systemd-resolved.service: Main process exited, code=exited, status=1/FAILURE
****** 10 06:17:24 ******-vm-us-3 systemd[1]: systemd-resolved.service: Failed with result 'exit-code'.
****** 10 06:17:24 ******-vm-us-3 systemd[1]: Failed to start Network Name Resolution.
****** 10 06:17:24 ******-vm-us-3 systemd[1]: systemd-resolved.service: Scheduled restart job, restart counter is at 1.
В общем что у нас есть:
- пришёл автоапдейт пакетов операционной системы
unattended-upgrades- после апдейта не поднялся
systemd-resolved- на вм начались проблемы, впн не работает
- все кричат про неработающий впн
Что будем делать? А ничего.
Это такой уровень шизы контроля, что делать ничего не будем.
Автоапдейты не хочется отключать.
Ставить какие-то алерты, автофайловеры, отслеживание логов - всё это бред.
Бизнес никогда не примет и не поймет все часы, которые уйдут на превентивные меры подобной задачи.
За два года аптаймов этих ВМ это впервые. Маловероятно, что это повторится ещё года два.
Поэтому просто пишем коллегам о кейсе, пишем postmortem и идём дальше жить и работать.
Трекаем часы и возвращаемся к своим кубернетисам.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥3💯3🤡1
#security #git #devops
Часть 1 из 2.
Рано или поздно все инженеры начинают расти профессионально.
Мы узнаем лучшие практики, оптимизируем существующий стек или инфру, внедряем новые технологии.
В какой-то момент мы даже следуем бест практис по security.
Добавление сканеров, проверки на бесящие всех CVE, пайплайны, pre-commit hooks и selinux/securitycontext.
Перечислять всё не буду, это невероятно огромная область.
Ноинтернет git всё помнит.
Git is the source of truth, как говорит мой коллега.
Это сейчас мы внедрили все практики и больше нет утечек паролей и токенов в гит, а храним всё в vault/aws sm/azure sa.
А что же в истории git?
В гите у нас могут остаться:
- токены
- private keys
- пароли
Давайте проверим и почистим за собой в репозитории.
Экспериментировать мы будем на публичных репах, чтобы вы сперва потренировались, ДО того, как будете ломать свои реальные репозитории🤣 .
Предварительная подготовка
- установить
Эта штука позволяет найти секреты во всех ветках всех файлах всей гит истории.
Описание есть в ридми.
- устанавливаем
- устанавливаем
я просто сделал так
Эта штука помогает удалить лишнее найденное из гита.
- устанавливаем
эта штука нам нужна для разового парсинга
- ну и
Приступаем к поиску и очистке.
- форкаем себе рандом популярный проект, а почему бы и да
Ищём тут https://github.com/trending?since=monthly
есть какой-то
- клонируем себе форкнутый проект (у вас путь другой будет само собой)
- запускаем сканер утечки чувствительных данных не меняя директорию
Результатом будет джейсон файл с детальным описанием кто, когда, что и за тип секретов.
Можете открыть и посмотреть, что там утек 1 токен от разработчика(он может быть и реальным и фейком).
- Для удобства очищаем его от всего лишнего
Для чего мы это делаем?
Чтобы сгенерить и проверить содержимое файла passwords.txt и ЕСЛИ в нём есть то, чего НЕ НАДО удалять из гита и оно бы осталось в гите, надо убрать из этого файла.
В этом файле то, что будет в последствии удалено из гита.
- заходим в гит репозиторий
- запускам
Видим длинную простыню текста, типа
- ещё раз смотрим чего же мы там меняем(если есть хоть любые сомнения, прерывайте процесс! операция без бекапов не поддаётся восстановлению!!!)
Часть 1 из 2.
Рано или поздно все инженеры начинают расти профессионально.
Мы узнаем лучшие практики, оптимизируем существующий стек или инфру, внедряем новые технологии.
В какой-то момент мы даже следуем бест практис по security.
Добавление сканеров, проверки на бесящие всех CVE, пайплайны, pre-commit hooks и selinux/securitycontext.
Перечислять всё не буду, это невероятно огромная область.
Но
Git is the source of truth, как говорит мой коллега.
Это сейчас мы внедрили все практики и больше нет утечек паролей и токенов в гит, а храним всё в vault/aws sm/azure sa.
А что же в истории git?
В гите у нас могут остаться:
- токены
- private keys
- пароли
Давайте проверим и почистим за собой в репозитории.
Экспериментировать мы будем на публичных репах, чтобы вы сперва потренировались, ДО того, как будете ломать свои реальные репозитории
Предварительная подготовка
- установить
gitleaks https://github.com/gitleaks/gitleaksЭта штука позволяет найти секреты во всех ветках всех файлах всей гит истории.
Описание есть в ридми.
- устанавливаем
java- устанавливаем
bfg https://rtyley.github.io/bfg-repo-cleaner/я просто сделал так
wget https://repo1.maven.org/maven2/com/madgag/bfg/1.14.0/bfg-1.14.0.jar
Эта штука помогает удалить лишнее найденное из гита.
- устанавливаем
jq https://github.com/jqlang/jqэта штука нам нужна для разового парсинга
- ну и
gitПриступаем к поиску и очистке.
- форкаем себе рандом популярный проект, а почему бы и да
Ищём тут https://github.com/trending?since=monthly
есть какой-то
microsoft/qlib- клонируем себе форкнутый проект (у вас путь другой будет само собой)
git clone git@github.com:kruchkov-alexandr/qlib.git
- запускаем сканер утечки чувствительных данных не меняя директорию
>gitleaks detect --source qlib --log-opts="--all" --report-path findings.json
○
│╲
│ ○
○ ░
░ gitleaks
12:23PM INF 1790 commits scanned.
12:23PM INF scan completed in 696ms
12:23PM WRN leaks found: 1
Результатом будет джейсон файл с детальным описанием кто, когда, что и за тип секретов.
Можете открыть и посмотреть, что там утек 1 токен от разработчика(он может быть и реальным и фейком).
- Для удобства очищаем его от всего лишнего
cat findings.json | jq -r '.[].Secret' > passwords.txt
Для чего мы это делаем?
Чтобы сгенерить и проверить содержимое файла passwords.txt и ЕСЛИ в нём есть то, чего НЕ НАДО удалять из гита и оно бы осталось в гите, надо убрать из этого файла.
В этом файле то, что будет в последствии удалено из гита.
- заходим в гит репозиторий
cd qlib
- запускам
bfg>java -jar ../bfg-1.14.0.jar --replace-text ../passwords.txt
Видим длинную простыню текста, типа
Commit Tree-Dirt History
------------------------
Earliest Latest
| |
.........................................................DDm
D = dirty commits (file tree fixed)
m = modified commits (commit message or parents changed)
. = clean commits (no changes to file tree)
Before After
-------------------------------------------
First modified commit | 21f0b394 | b3d34764
Last dirty commit | 63021018 | abf5a1bf
Changed files
-------------
Filename Before & After
---------------------------------------------------
data.py | 8de32f3f ⇒ 82298fe3, f6bd7809 ⇒ 8bd16038
In total, 159 object ids were changed. Full details are logged here:
/home/***/GIT/INTERNET/qlib.bfg-report/2025-06-12/12-24-52
- ещё раз смотрим чего же мы там меняем(если есть хоть любые сомнения, прерывайте процесс! операция без бекапов не поддаётся восстановлению!!!)
cat /home/***/GIT/INTERNET/qlib.bfg-report/202*-0*-**/12-24-52/changed-files.txt
8de32f3f6c0373ca1b41fe6d3f4dbd4c23685d71 82298fe3811f0c36aa982a1ff23ee92289cc9346 data.py
f6bd780905649d8d004c13bd98a91044958b9573 8bd160386147b2007172e618dbe049b02cd4bcc3 data.py
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6😨2
#security #git #devops
Часть 2 из 2.
- теперь мы выдыхаем, принимаем решение и чистим
Это мы почистили ЛОКАЛЬНО гит, пока на ремоут сервер не заливали.
- проверяем, что локально всё чисто
То есть проверка показала, что все токены и пароли были удалены.
- крестимся и пушим в ремоут
Всё, история в нашем форке почищена.
Можно ещё раз проверить всё
- удаляем локальный репозиторий
- клонируем с ремоута
- проверяем на утечки
- радуемся, что даже в истории гита нет утечек
Инструкция написана максимально подробно, чтобы те, кто подобного раньше никогда не делали, не допустили бы глупых ошибок. Сперва потренируйтесь на паблик репозиториях, отточите все действия до полного понимания и только потом надо чистить реальные репозитории на работе.
На реальных боевых репозиториях в идеале сделать бекап, прям gzip файлом, до всех изменений, если опыта мало и только потом приступать.
Инструкция длинная, кажется сложно, но на самом деле это лишь 5 команд и всё.
Не бойтесь. Вы - инженер.
Часть 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 команд и всё.
Не бойтесь. Вы - инженер.
👍16
#docker #troubleshooting #одинденьизжизни
Иногда нам всем нужна Лицензия наУбийство Костыль.
Как в одном из фильмов про Бонда.
Ситуация: резко к вам прибегают и говорят "У НАС ПРОБЛЕЕЕМА".
Нырнув внутрь "проблемы", понимаю, что 19 из 20 разных микросервисов на разных стеках начали ругаться на один из веб-сайтов партнёров. Что-то не так с сертификатом.
Проверяем изнутри пода
Проверяю локально - всё ок с сайтом(он не наш).
Ладно.
Лезем в гугл спрашиваем в чате девопс_ру чего есть ныне для анализа SSL.
Дали рекомендацию - https://www.ssllabs.com/
Проверяю сайт - ранг B, в целом всё ок, но есть вопросики.
Они обновили новый серт, у нового серта новый УЦ(я так понял).
Созвон с коллегами, говорю так и так, сайт чужой, проблема с ним, у нас вроде всё ок.
Однако бизнес не согласен со мной(и, наверное, прав на 100%).
Говорят "да, мы знаем, что проблема скорее всего не у нас. Да, мы поняли, что это надо им писать. Но у нас бизнес и денежки, Пока они(владельцы сайта-партнёра) отреагируют, у нас не ок работает НАШ бизнес.
А где НАШ бизнес - там проблема у нас. Возможно ли быстро решить нашими средствами эту проблему?"
Чуток поэкспериментировал локально, за пять минут нашёл пару очевидных решений.
Спрашиваю лицензию на костыль, мне дают карт-бланш.
Ну ок, лицензия получена, пилим фиксы.
В одном имадже (где старые from имаджи)
В другом имадже залепить, если ещё нет, и пересобрать
(показываю одним слоём, но вообще он был добавлен к один длинный run).
Да, было добавление ca-certificates, но не было команды на апдейт 🐒
И так далее.
Пересобираем, деплоим, проблема ушла.
Ура, бизнес ликует.
Выводы:
А кто тут виноват? Я не знаю.
Владелец сайта и новый УЦ?
Наши "устаревшие сервисы" со старым списком со старыми сертами?
Отсутствие регулярных пересборок имаджей и скачивание всех новых сертов?
Чёрт его знает.
Иногда нам всем нужна Лицензия на
Как в одном из фильмов про Бонда.
Ситуация: резко к вам прибегают и говорят "У НАС ПРОБЛЕЕЕМА".
Нырнув внутрь "проблемы", понимаю, что 19 из 20 разных микросервисов на разных стеках начали ругаться на один из веб-сайтов партнёров. Что-то не так с сертификатом.
Проверяем изнутри пода
> curl https://*******.com/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Проверяю локально - всё ок с сайтом(он не наш).
Ладно.
Дали рекомендацию - https://www.ssllabs.com/
Проверяю сайт - ранг B, в целом всё ок, но есть вопросики.
Они обновили новый серт, у нового серта новый УЦ(я так понял).
Созвон с коллегами, говорю так и так, сайт чужой, проблема с ним, у нас вроде всё ок.
Однако бизнес не согласен со мной(и, наверное, прав на 100%).
Говорят "да, мы знаем, что проблема скорее всего не у нас. Да, мы поняли, что это надо им писать. Но у нас бизнес и денежки, Пока они(владельцы сайта-партнёра) отреагируют, у нас не ок работает НАШ бизнес.
А где НАШ бизнес - там проблема у нас. Возможно ли быстро решить нашими средствами эту проблему?"
Чуток поэкспериментировал локально, за пять минут нашёл пару очевидных решений.
Спрашиваю лицензию на костыль, мне дают карт-бланш.
Ну ок, лицензия получена, пилим фиксы.
В одном имадже (где старые from имаджи)
FROM node:*****
...
# temporary fix for https://*****.com/
RUN wget https://sectigo.tbs-certificats.com/SectigoPublicServerAuthenticationRootR46.crt -O /usr/local/share/ca-certificates/sectigo-root.crt && update-ca-certificates
...
В другом имадже залепить, если ещё нет, и пересобрать
...
RUN update-ca-certificates
...
(показываю одним слоём, но вообще он был добавлен к один длинный run).
И так далее.
Пересобираем, деплоим, проблема ушла.
Ура, бизнес ликует.
Выводы:
А кто тут виноват? Я не знаю.
Владелец сайта и новый УЦ?
Наши "устаревшие сервисы" со старым списком со старыми сертами?
Отсутствие регулярных пересборок имаджей и скачивание всех новых сертов?
Чёрт его знает.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤1🤡1
#одинденьизжизни
Факапы и сроки.
А вот мало когда мне удавалось в своей жизни спланировать сроки.
Задача А - 2 часа, задача Б - 2 дня.
Ну не, к сожалению, у меня так не работает.
Допустим задача "установить впн сервер".
Казалось бы простая задача. Возьми да установи.
Для начала мы сравниваем что есть на рынке, смотрим фичи(платные, бесплатные), потом спрашиваем бизнес чего он сам хочет, какие есть требования аудитов сейчас и в будущем. Количество сотрудников, кто будет пользоваться.
В общем составляем картину задачи. На это уходит время.
Все требования собраны, все софты сведены в табличку(опенсорс и платные).
По ходу принято решение руководства/коллег/заказчика/лида, что опенсорс не для нас, потому как если не будет того, кто это поддерживает, то такое решение никому не нужно.
Допустим выбираем два решения - потестировать.
Пока идём по плану времени на задачу.
Приступаем к тестам. тестируем оба решения на базовые вещи из требований - SSO, routing, monitoring, audit etc.
На это снова уходит время, уже начинаю отклонятся от плана.
Опустим требования, которые были от компании/коллег/заказчика, но в итоге выбрали совместными усилиями
Ок, он так он.
Начинаю пилить боевую инфру - терраформ, днс, секьюрити груп и прочие компоненты для инсталляции.
Почти всё готово (базовая инсталляция, без настройки).
Несколько раз гоняю планы/апплаи, то сперва работало, то теперь не работает.
Начал ковыряться в логах - оказывается у встроенного certbot с ssl сертификатом есть ограничения.
https://letsencrypt.org/docs/rate-limits/#new-certificates-per-exact-set-of-hostnames
И следующая регистрация только через сутки🤦♂️
Ок, хочется настроить уже с нормальным сертом (+ ажур аппликейшн адрес), ждём сутки.
Пулл реквест не стал пилить, оставил на завтра, ушел спать.
Пришёл утром - сервера нет. Ночью была авария, коллеги с другого часового пояса делали срочные изменения инфры, перетерли стейт с моей ветки. Проблемы терраформа и одного стейта.
Ладно. Мержим с мастера, снова апплаим с ветки, настроили, с сертом уже проблем нет.
Однако всплыла другая проблема - при вводе лицензии мы видим, что у нас УЖЕ используется одна лицензия.
С удаленного сервера.
Ну типа и платить двое больше, пробуем поиграться с кнопочкой удаления лицензии, кнопка есть, а лицензия не удаляется из аккаунта.
Ладно, потом разберёмся. ПР, аппрув, мерж в мастер, всё раскатывается.
Хочу уже на "боевом" сервере начать вносить правки, но теперь активны две лицензии, и если введу в третий раз - будет третья лицензия и будет прайс х3.
Пишу имейл в саппорт, жду ответа.
Снова ждать.
И я даже не приступил к настройке роутинговой таблицы, пирингам, группам, организации, а на детских ошибках - лимитах сертбота и что гонял на одном и том же домене несколько раз, что проблема с удалением/вводом лицензии, что перетёрли стейт (ну это прям скажем надо менять конечно же на отдельный стейт, тред не про это) и что делал тесты с удалением сервера не удаляя лицензии. И таких вещей было море, я лишь о самых ярких говорю.
Вот так задача в условные 8 часов превратилась в 20+ часов и ещё не закончена.
Не все 20 часов её делал, и трекать надо меньше, но финальный срок "когда впн будет готов для всех" сильно отличается от первоначальной оценки.
Не знаю как у других, но планирование у меня частенько хромает. Увы.
Факапы и сроки.
А вот мало когда мне удавалось в своей жизни спланировать сроки.
Задача А - 2 часа, задача Б - 2 дня.
Ну не, к сожалению, у меня так не работает.
Допустим задача "установить впн сервер".
Казалось бы простая задача. Возьми да установи.
Для начала мы сравниваем что есть на рынке, смотрим фичи(платные, бесплатные), потом спрашиваем бизнес чего он сам хочет, какие есть требования аудитов сейчас и в будущем. Количество сотрудников, кто будет пользоваться.
В общем составляем картину задачи. На это уходит время.
Все требования собраны, все софты сведены в табличку(опенсорс и платные).
По ходу принято решение руководства/коллег/заказчика/лида, что опенсорс не для нас, потому как если не будет того, кто это поддерживает, то такое решение никому не нужно.
Допустим выбираем два решения - потестировать.
Пока идём по плану времени на задачу.
Приступаем к тестам. тестируем оба решения на базовые вещи из требований - SSO, routing, monitoring, audit etc.
На это снова уходит время, уже начинаю отклонятся от плана.
Опустим требования, которые были от компании/коллег/заказчика, но в итоге выбрали совместными усилиями
pritunl.Ок, он так он.
Начинаю пилить боевую инфру - терраформ, днс, секьюрити груп и прочие компоненты для инсталляции.
Почти всё готово (базовая инсталляция, без настройки).
Несколько раз гоняю планы/апплаи, то сперва работало, то теперь не работает.
Начал ковыряться в логах - оказывается у встроенного certbot с ssl сертификатом есть ограничения.
https://letsencrypt.org/docs/rate-limits/#new-certificates-per-exact-set-of-hostnames
И следующая регистрация только через сутки
Ок, хочется настроить уже с нормальным сертом (+ ажур аппликейшн адрес), ждём сутки.
Пулл реквест не стал пилить, оставил на завтра, ушел спать.
Пришёл утром - сервера нет. Ночью была авария, коллеги с другого часового пояса делали срочные изменения инфры, перетерли стейт с моей ветки. Проблемы терраформа и одного стейта.
Ладно. Мержим с мастера, снова апплаим с ветки, настроили, с сертом уже проблем нет.
Однако всплыла другая проблема - при вводе лицензии мы видим, что у нас УЖЕ используется одна лицензия.
С удаленного сервера.
Ну типа и платить двое больше, пробуем поиграться с кнопочкой удаления лицензии, кнопка есть, а лицензия не удаляется из аккаунта.
Ладно, потом разберёмся. ПР, аппрув, мерж в мастер, всё раскатывается.
Хочу уже на "боевом" сервере начать вносить правки, но теперь активны две лицензии, и если введу в третий раз - будет третья лицензия и будет прайс х3.
Пишу имейл в саппорт, жду ответа.
Снова ждать.
И я даже не приступил к настройке роутинговой таблицы, пирингам, группам, организации, а на детских ошибках - лимитах сертбота и что гонял на одном и том же домене несколько раз, что проблема с удалением/вводом лицензии, что перетёрли стейт (ну это прям скажем надо менять конечно же на отдельный стейт, тред не про это) и что делал тесты с удалением сервера не удаляя лицензии. И таких вещей было море, я лишь о самых ярких говорю.
Вот так задача в условные 8 часов превратилась в 20+ часов и ещё не закончена.
Не все 20 часов её делал, и трекать надо меньше, но финальный срок "когда впн будет готов для всех" сильно отличается от первоначальной оценки.
Не знаю как у других, но планирование у меня частенько хромает. Увы.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20❤2😁1🤡1
#slack
Незаметно для меня(но, возможно, очевидно для всех остальных внимательных людей в мире), slack incoming WebHooks стал deprecated и больше не поддерживает добавление новых каналов.
Ни в одном из моих спейсов не даёт добавить себя ни в один из каналов.😭
Переходим на slack app.
Опять переписывать все интеграции и скрипты.🤡
Незаметно для меня(но, возможно, очевидно для всех остальных внимательных людей в мире), slack incoming WebHooks стал deprecated и больше не поддерживает добавление новых каналов.
Ни в одном из моих спейсов не даёт добавить себя ни в один из каналов.
Переходим на slack app.
Опять переписывать все интеграции и скрипты.
Please open Telegram to view this post
VIEW IN TELEGRAM
👀5🤡3👍1😈1🫡1
#aws
Абсурд и наркомания.
Однажды какой-то безопасник скажет.
Везде и всем всё запретить.
Задачу надо как-то выполнять.
Закрываем одно, второе, третье.
Наступает момент лютейшего бреда, когда тебе говорят ограничить доступ, оставить только для гитхаб раннеров.
Задачу надо как-то выполнять.
Ты идёшь и смотришь, а чего с пулом
Ух, пробрало, как сладко.
А потом читаешь
https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html
Оказывается на один уникальный порт в рамках одной секьюрити группы можно повесить лишь 60 правил.
Задачу надо как-то выполнять.
А это значит тебе надо создать примерно сотню SG, по 60 правил в каждом чтобы поддержать желание инфобезы/аудитора... Стоп-стоп, какой сюр, прекрати.
Задачу надо как-то выполнять.
На этом моменте тебя тошнит от бреда, ты пишешь аудитору/инфобезе "я не смогу это сделать, технически нельзя выдать доступ только для гитхаб раннеров и больше никому, вот пруфы".
Смело закрываешь таску и идёшь заниматься настоящей работой, а не Великими фантазиями Великих Всезапрещальщиков.
* Не знаю есть ли вообще решение, но мне проще порт нахрен закрыть, чем 5.3к рулсов куда-то запиливать.
Абсурд и наркомания.
Однажды какой-то безопасник скажет.
Везде и всем всё запретить.
Задачу надо как-то выполнять.
Закрываем одно, второе, третье.
Наступает момент лютейшего бреда, когда тебе говорят ограничить доступ, оставить только для гитхаб раннеров.
Задачу надо как-то выполнять.
Ты идёшь и смотришь, а чего с пулом
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к рулсов куда-то запиливать.
❤14😁8👍3👎1🤡1
#aws #пятница #terraform
Магия "у меня локально всё работает".
Пишет мне мой приятель, у которого я какое-то короткое время менторил(а такое слово вообще есть?)
"Алекс, Алекс, спасити памагити, у меня беда".
Сегодня он вносил небольшие правки в терраформ.
Запустил план на дев, на стейдж, на прод - все ок.
Аппрув, мерж в мастер и.. а терраформ план и апплай перенакатывает ему виртуалку с ec2🐒
Я помог ему восстановить сервис(вне этой заметки, отдельная стори и причина звонка), а затем мы начали разбираться, а как так вышло то, эй.
Шарит экран, говорит вот локально с мастера делаю план на дев, стейдж, проде, - всё ок.
Выдохнув, спрашиваю, а что ты знаешь про
Ну он, конечно же, ничего не знал.
Скидываю ему пример
Смотрим его код, а там есть
Лезем в
https://github.com/hashicorp/terraform-provider-aws/releases/tag/v6.0.0
Приятель пилит сам у себя все версии в лок, проблема решена.
Он проверял локально и провайдер брался из
В CI/CD при каждом запуске запускался
Дальше была проверка всего кода
Ну зато узнал что-то новое, чо.
Магия "у меня локально всё работает".
Пишет мне мой приятель, у которого я какое-то короткое время менторил(а такое слово вообще есть?)
"Алекс, Алекс, спасити памагити, у меня беда".
Сегодня он вносил небольшие правки в терраформ.
Запустил план на дев, на стейдж, на прод - все ок.
Аппрув, мерж в мастер и.. а терраформ план и апплай перенакатывает ему виртуалку с ec2
Я помог ему восстановить сервис(вне этой заметки, отдельная стори и причина звонка), а затем мы начали разбираться, а как так вышло то, эй.
Шарит экран, говорит вот локально с мастера делаю план на дев, стейдж, проде, - всё ок.
Выдохнув, спрашиваю, а что ты знаешь про
version constraints у терраформа?Ну он, конечно же, ничего не знал.
Скидываю ему пример
= X.Y.Z - точная версия: version = "= 4.0.0" (только 4.0.0).
>= X.Y.Z - минимум и выше: version = ">= 4.0.0" (4.0.0 и выше).
<= X.Y.Z - максимум и ниже: version = "<= 4.0.0" (до 4.0.0 включительно).
> X.Y.Z - выше указанной: version = "> 4.0.0" (4.0.1 и выше).
< X.Y.Z - ниже указанной: version = "< 4.0.0" (до 4.0.0, не включая).
~> X.Y - в пределах мажорной: version = "~> 4.0" (4.0.x, но не 5.0).
>= X.Y.Z, < X.Y.Z - диапазон: version = ">= 4.0.0, < 5.0.0" (4.x.x, но не 5.x.x).
Смотрим его код, а там есть
...
version = ">= 5.0"
...
Лезем в
https://github.com/hashicorp/terraform-provider-aws/releases/tag/v6.0.0
охреневаем от брейкинг чейнджевПриятель пилит сам у себя все версии в лок, проблема решена.
Он проверял локально и провайдер брался из
кеша - проблемы не видел.В CI/CD при каждом запуске запускался
terrafrom init, что подтянул ему новую версию, которая триггернула пересоздание виртуалки. Дальше была проверка всего кода
tflint, checkov и другими утилитами, нашли ещё 4 места, где версии были плавающими, поправили и это.Ну зато узнал что-то новое, чо.
Please open Telegram to view this post
VIEW IN TELEGRAM
👏15🤡6
#docker #aws
Я решил отказаться от долгих часов, проведенных за оптимизацией размера Docker-образов.
Несмотря на провокационный заголовок, который мог показаться кликбейтом, я действительно перестал уделять этому столько времени.
Хочу поделиться своими размышлениями - возможно, они окажутся правильными, а может, и нет.
Я не топлю, что мои размышления правильные, я лишь ими делюсь.
Давайте попробую обосновать свою позицию.
Все дальнейшие расчеты будут основаны на работе с облачными провайдерами, хотя, как мне кажется, на bare metal затраты могли бы быть ниже.
Выпущено миллиард книг, написано сотни утилит и опубликовано гигадзиллион статьей по теме оптимизации размера имаджа.
А зачем?
Вспомним основные причины оптимизации размера Docker-образа:
- Ускорение развертывания: Меньшие образы быстрее загружаются и передаются по сети.
- Экономия ресурсов: Снижение потребления дискового пространства и памяти.
- Безопасность: Уменьшение количества компонентов снижает уязвимости.
- Эффективность CI/CD: Ускорение сборки и доставки в конвейерах.
- Снижение затрат: Меньше данных для хранения и передачи в облаке.
и так далее.
Скачивание имаджа.
Когда в основном скачивается имадж:
- при скейле ноды
- при релизе
Есть ещё редкие случаи связок imagePullPolicy Always, скейлинге приложения и антиаффинити, но мы о не будем говорить, они редкие.
А сколько скачивается имадж?
Начиная с версии 1.30 кубера у нас есть метрика
Мы говорим про средние имаджи, допустим в 900 мегабайт.
Построим график
Скорость варьируется от 6 секунд до 16 секунд за последние 7 дней.
Я лично считаю это небольшой цифрой для добавления времени к релизу или скейлингу.
Нода или само приложение порой дольше проходит хелсчеки.
Специально ставил
Экономия ресурсов.
А сколько сейчас стоит в облаках ресурс дискового пространства?
Например у AWS так https://aws.amazon.com/ecr/pricing/
Ну или просто в биллинг можно залезть и посчитать сколько тратим в месяц на ECR.
В среднем за последний год тратим 35-50 долларов в месяц.
Диски для самих нод выходят так мало, что их почти не видно в прайсе
https://aws.amazon.com/ebs/pricing/
Ну то есть в самый пик на дисковое пространство тратим не больше 50 долларов в месяц.
Безопасность.
Я и согласен и несогласен.
Безопасность в последнее время перешла границы от разумного до параноидального бреда, лишь бы мы покупали решения от крупных вендоров и мастурбировали на CVE, которая вышла 0.000001мс назад.
Простые решения в виде "не добавлять ничего лишнего в имадж" + trivy вполне покрывают этот пункт для нас.
Да и уменьшение размера диска не гарантирует безопасность, лишь снижает вероятность инцидентов.
К сожалению в некоторых моих проектах невозможно использовать подходы с SBOM+distroless.
Разработчики пилят микросервисы, макросервисы, сейчас один только nodejs и python тянет за собой миллиард депенденси и отказаться от них невозможно, совершенно невозможно.
А этот софт в отличии от меня приносит деньги.
Эффективность CI/CD
Тот же пункт, что и пул имаджей с нод.
6-16 секунд для несжатых имаджей.
Снижение затрат
Тот же пункт, что и с костами для ECR, но тут за трафик.
Трата за трафик небольшая. Не больше 5 долларов в месяц.
Я решил отказаться от долгих часов, проведенных за оптимизацией размера Docker-образов.
Несмотря на провокационный заголовок, который мог показаться кликбейтом, я действительно перестал уделять этому столько времени.
Хочу поделиться своими размышлениями - возможно, они окажутся правильными, а может, и нет.
Я не топлю, что мои размышления правильные, я лишь ими делюсь.
Давайте попробую обосновать свою позицию.
Все дальнейшие расчеты будут основаны на работе с облачными провайдерами, хотя, как мне кажется, на bare metal затраты могли бы быть ниже.
Выпущено миллиард книг, написано сотни утилит и опубликовано гигадзиллион статьей по теме оптимизации размера имаджа.
А зачем?
Вспомним основные причины оптимизации размера Docker-образа:
- Ускорение развертывания: Меньшие образы быстрее загружаются и передаются по сети.
- Экономия ресурсов: Снижение потребления дискового пространства и памяти.
- Безопасность: Уменьшение количества компонентов снижает уязвимости.
- Эффективность CI/CD: Ускорение сборки и доставки в конвейерах.
- Снижение затрат: Меньше данных для хранения и передачи в облаке.
и так далее.
Скачивание имаджа.
Когда в основном скачивается имадж:
- при скейле ноды
- при релизе
Есть ещё редкие случаи связок imagePullPolicy Always, скейлинге приложения и антиаффинити, но мы о не будем говорить, они редкие.
А сколько скачивается имадж?
Начиная с версии 1.30 кубера у нас есть метрика
kubelet_image_pull_duration_seconds_sum и лейбл image_size_in_bytes (не сжатый!!!! размер) с 4 значениями ( 0-10MB, 10MB-100MB, 100MB-500MB, 500MB-1GB).Мы говорим про средние имаджи, допустим в 900 мегабайт.
Построим график
avg(kubelet_image_pull_duration_seconds_sum{image_size_in_bytes="500MB-1GB"} / kubelet_image_pull_duration_seconds_count{image_size_in_bytes="500MB-1GB"})
(и для сравнения мелкие имаджи)
avg(kubelet_image_pull_duration_seconds_sum{image_size_in_bytes="100MB-500MB"} / kubelet_image_pull_duration_seconds_count{image_size_in_bytes="100MB-500MB"})
Скорость варьируется от 6 секунд до 16 секунд за последние 7 дней.
Я лично считаю это небольшой цифрой для добавления времени к релизу или скейлингу.
Нода или само приложение порой дольше проходит хелсчеки.
Специально ставил
blackbox exporter + релейбл с путем до проб и навешивал на поды, чтобы рассчитать probe_duration_seconds. Пробы в среднем стартуют с 25 секунд.Экономия ресурсов.
А сколько сейчас стоит в облаках ресурс дискового пространства?
Например у AWS так https://aws.amazon.com/ecr/pricing/
Ну или просто в биллинг можно залезть и посчитать сколько тратим в месяц на ECR.
В среднем за последний год тратим 35-50 долларов в месяц.
Диски для самих нод выходят так мало, что их почти не видно в прайсе
https://aws.amazon.com/ebs/pricing/
Ну то есть в самый пик на дисковое пространство тратим не больше 50 долларов в месяц.
Безопасность.
Я и согласен и несогласен.
Безопасность в последнее время перешла границы от разумного до параноидального бреда, лишь бы мы покупали решения от крупных вендоров и мастурбировали на CVE, которая вышла 0.000001мс назад.
Простые решения в виде "не добавлять ничего лишнего в имадж" + trivy вполне покрывают этот пункт для нас.
Да и уменьшение размера диска не гарантирует безопасность, лишь снижает вероятность инцидентов.
К сожалению в некоторых моих проектах невозможно использовать подходы с SBOM+distroless.
Разработчики пилят микросервисы, макросервисы, сейчас один только nodejs и python тянет за собой миллиард депенденси и отказаться от них невозможно, совершенно невозможно.
А этот софт в отличии от меня приносит деньги.
Эффективность CI/CD
Тот же пункт, что и пул имаджей с нод.
6-16 секунд для несжатых имаджей.
Снижение затрат
Тот же пункт, что и с костами для ECR, но тут за трафик.
Трата за трафик небольшая. Не больше 5 долларов в месяц.
👍9❤1
#docker #aws
Итого, что мы имеем:
Средняятемпература по больнице зарплата синёра это $4000-6000 (*ЕС, Россия, без США само собой), если верить словам приятелей моего круга общения и статьям в интернете и статистике, которую нашёл час назад, а значит в час, при 168 часовой неделе, это $23-35. Ну, наверное, самые крутые получают $50h.
Средняя время оптимизации докерфайла (постоянный запуск, смена слоёв, подгон под аппликейшн, убирание лишнего и так далее) это 2-3 часа в моей практике. Лишь за счёт долгого ковыряния.
То есть чтобы "сэкономить" бизнесу 5-10 долларов в месяц(!) за трафик сети и хранение и 3-5 секунд при деплое я потрачу $50-105. И это лишь на один имадж. 30 имаджей-микросервисов и всё, я потратил несколько тысяч долларов.
Оптимизировать чтобы что? Только лишь потому, что это правильно?
Да, оптимизация размера имаджа это правильно, я согласен с этим тезисом. не оспариваю его ни в коем случае.
Как минимум это приятно для глаз инженера.
Стоит ли делать это? Да, но только в том случае, когда освободилось время от всех других задач по работе.
Приоритет у этой задачи один из самых низких на мой взгляд.
У меня сейчас нет времени, чтобы тратить деньги бизнеса на оптимизацию.
Безусловно если мне коллеги выкатят имадж на 5 гигабайт я брошу всё и займусь им.
Образы до 900 мегабайт считаю оптимизировать пока не надо.
В данный момент развития технологий в 2025 году(привет хелл депенденси питона и ноджс и все ML фреймворки), с ценами облачных провайдеров за трафик, реджистри и диск для нод, средней зарплатой инженера в час, считаю полностью нецелесообразным тратить часы на оптимизацию размера имаджа.
Бизнес не выигрывает ничего, во всяком случае наш.
В каком же случае оптимизация всё же нужна?
Когда важная каждая секунда при деплое и скейлинге и когда этого просто хочется.
* Данная заметка не является рекомендацией, не является советом, лишь поделился своими размышлениями.
Итого, что мы имеем:
Средняя
Средняя время оптимизации докерфайла (постоянный запуск, смена слоёв, подгон под аппликейшн, убирание лишнего и так далее) это 2-3 часа в моей практике. Лишь за счёт долгого ковыряния.
То есть чтобы "сэкономить" бизнесу 5-10 долларов в месяц(!) за трафик сети и хранение и 3-5 секунд при деплое я потрачу $50-105. И это лишь на один имадж. 30 имаджей-микросервисов и всё, я потратил несколько тысяч долларов.
Оптимизировать чтобы что? Только лишь потому, что это правильно?
Да, оптимизация размера имаджа это правильно, я согласен с этим тезисом. не оспариваю его ни в коем случае.
Как минимум это приятно для глаз инженера.
Стоит ли делать это? Да, но только в том случае, когда освободилось время от всех других задач по работе.
Приоритет у этой задачи один из самых низких на мой взгляд.
У меня сейчас нет времени, чтобы тратить деньги бизнеса на оптимизацию.
Безусловно если мне коллеги выкатят имадж на 5 гигабайт я брошу всё и займусь им.
Образы до 900 мегабайт считаю оптимизировать пока не надо.
В данный момент развития технологий в 2025 году(привет хелл депенденси питона и ноджс и все ML фреймворки), с ценами облачных провайдеров за трафик, реджистри и диск для нод, средней зарплатой инженера в час, считаю полностью нецелесообразным тратить часы на оптимизацию размера имаджа.
Бизнес не выигрывает ничего, во всяком случае наш.
В каком же случае оптимизация всё же нужна?
Когда важная каждая секунда при деплое и скейлинге и когда этого просто хочется.
* Данная заметка не является рекомендацией, не является советом, лишь поделился своими размышлениями.
❤16👌5💯1🤝1
Правило пяти.
Последние годы я выработал в себе привычку "правила пяти" - обновлять на новые версии только с 6 патча.
Сколько же я разных проблем находил: Argo CD, Apache Superset, Kubernetes, Debezium, Trino, Laravel и сотни их было.
И большая их часть именно в 1-5 патч версиях.
Теперь я стараюсь не спешить и не обновляться до новой версии сразу после релиза.
Даже в AWS EKS я две проблемы находил - с сетевым плагином с и ООМ metrics сервера.
Не знаю как у остальных, но конкретно меня правило пяти последнее время спасает, оберегая от новых багов на которые просто банально тратится множество времени для траблшутинга.
Последние годы я выработал в себе привычку "правила пяти" - обновлять на новые версии только с 6 патча.
Сколько же я разных проблем находил: Argo CD, Apache Superset, Kubernetes, Debezium, Trino, Laravel и сотни их было.
И большая их часть именно в 1-5 патч версиях.
Теперь я стараюсь не спешить и не обновляться до новой версии сразу после релиза.
Даже в AWS EKS я две проблемы находил - с сетевым плагином с и ООМ metrics сервера.
Не знаю как у остальных, но конкретно меня правило пяти последнее время спасает, оберегая от новых багов на которые просто банально тратится множество времени для траблшутинга.
👍18😁5
#aws
Короткая, но важная заметка о предстоящих изменениях.
AWS CDK планируют собирать телеметрию.
Важно тем, у кого CDK и GDRP или подобное.
- https://github.com/aws/aws-cdk-rfcs/blob/main/text/0732-cdk-cli-telemetry.md
- https://github.com/aws/aws-cdk/issues/34892
Короткая, но важная заметка о предстоящих изменениях.
AWS CDK планируют собирать телеметрию.
Важно тем, у кого CDK и GDRP или подобное.
- https://github.com/aws/aws-cdk-rfcs/blob/main/text/0732-cdk-cli-telemetry.md
- https://github.com/aws/aws-cdk/issues/34892
👍3❤1🤡1