Библиотека девопса | DevOps, SRE, Sysadmin

📦 Зачем DevOps'у уметь читать Dockerfile, даже если он не пишет их сам Даже если ты не автор образов, в проде ты всё равно будешь отвечать за их поведение. А это значит — как минимум, уметь читать Dockerfile. Вот зачем это важно: 🔍 Диагностика проблем Падает контейнер — надо понять, что внутри. Логов нет, трассировки нет, только Dockerfile. И если там на 5-й строке COPY ./random.sh /init.sh && chmod +x /init.sh && /init.sh — ты уже знаешь, где копать. 🛡 Безопасность Ты удивишься, сколько «готовых» образов тянут curl/bash скрипты из интернета в рантайме. Это мина под твоим кластером. Умение распознать такую «закладку» спасёт прод. ⚡ Оптимизация CI/CD Каждый RUN apt-get update && install — это дополнительный слой. А если таких RUN-ов 10? Билд будет долгим, кэш бесполезным. Умеешь читать — можешь подсказать разработчику, как сделать быстрее. 🔁 Обновления и патчи Часто нужно просто пропатчить образ: обновить версию пакета или заменить base image. Без понимания Dockerfile ты будешь звать разработчика. А мог бы уже закатить фикс и спать спокойно. Так что даже если ты не пишешь Dockerfile — читай их. Это как чтение кода: не надо быть гуру, чтобы понимать, что происходит. Подпишись 👉@devopslib

🚀 Как настроить мониторинг SLO/SLA с Prometheus и Grafana В любой современной инфраструктуре важно не просто собирать метрики, а строить на их основе понятные цели уровня обслуживания (SLO) и соглашения об уровне обслуживания (SLA). Вот несколько ключевых шагов: 1. Определите ключевые сервисные метрики 🟢Время отклика API 🟢Доля успешных запросов (error rate) 🟢Задержки базы данных Сфокусируйтесь на показателях, которые прямо влияют на пользовательский опыт. 2. Собирайте метрики в Prometheus 🟢Используйте node_exporter для базового мониторинга хостов. 🟢Внедрите client_golang или client_python в ваши сервисы для экспорта бизнес-метрик. 🟢Настройте alertmanager для уведомлений при выходе за пороговые значения. 3. Проектируйте дашборды в Grafana 🟢Создайте отдельные панели для каждой SLO-метрики. 🟢Используйте графики «Burn rate» для визуализации скорости деградации системы. 🟢Настройте плагины для вычисления ошибок в процентах и «time in state». 4. Устанавливайте целевые уровни и оповещения 🟢Определите допустимую ошибку, например, 99.9% успешных запросов в месяц. 🟢Настройте алерты на 85% и 95% пороги, чтобы предупредить о приближении к SLA-линии. 🟢Включите эскалацию в случае длительных нарушений. 5. Периодически пересматривайте SLO 🟢Анализируйте реальные данные и корректируйте пороги. 🟢Обсуждайте результаты с командой разработки и бизнес-стейкхолдерами. Хорошо выстроенный мониторинг SLO/SLA позволяет увидеть узкие места до того, как они станут инцидентами, и обеспечить стабильность пользователей на нужном уровне. Подпишись 👉@devopslib

🛳️ Канареечные релизы в Kubernetes: безопасный путь к обновлениям В мире SRE и DevOps стремительные релизы — это не просто плюс, а необходимость. Но как выкатывать новые версии сервисов без риска «сломать» продакшн? Ответ — канареечные релизы. Что такое канареечный релиз? Это поэтапный rollout, при котором новая версия приложения сначала попадает на небольшой процент трафика. Если всё OK — долю постепенно увеличивают до 100 %, а при проблемах быстро «откатываются» к старому состоянию. Почему это круто? 🟢 🔍 Минимизируем риски: ошибки затронут лишь небольшой сегмент пользователей. 🟢 ⚡ Быстрый фидбек: метрики сразу покажут, как новая версия ведёт себя под нагрузкой. 🟢 ⏪ Моментальный откат: rollback проще и безопаснее, чем при монолитном апгрейде. Как настроить канареечный релиз в Kubernetes с Argo Rollouts? 1. Установите CRD и контроллер:

   kubectl apply -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
   

2. Описываем Rollout-манифест:

   apiVersion: argoproj.io/v1alpha1
   kind: Rollout
   metadata:
     name: my-app
   spec:
     replicas: 5
     strategy:
       canary:
         steps:
         - setWeight: 10
         - pause: {duration: 60s}
         - setWeight: 50
         - pause: {duration: 60s}
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: my-app
           image: myregistry/my-app:v2
   

3. Запустите Rollout:

   kubectl apply -f rollout.yaml
   argo rollouts get rollout my-app --watch
   

4. Мониторинг и автоматизация: Подключите Prometheus и Grafana — настройте метрики (латентность, ошибки) для автоматической паузы или отката. Советы по продвинутому использованию 🟢 Используйте Webhooks в Argo Rollouts для интеграции с внешними системами тестирования. 🟢 Настройте AnalysisTemplates для автоматической оценки качества релиза по набору SLO. 🟢 Применяйте TrafficRouting через Istio или NGINX Ingress для более гибкого управления трафиком. Такой подход поможет вам выкатывать фичи без лишнего стресса и без полунощных тревог от неожиданного падения сервисов. Подпишись 👉@devopslib

Привет, друзья! Сегодня хочу поделиться своим опытом настройки мониторинга Kubernetes-кластеров с помощью связки Prometheus + Grafana. Это один из самых востребованных сценариев в современных DevOps-стэках, и правильная реализация позволит вам оперативно реагировать на сбои и проседание производительности. 1. Развертывание Prometheus в Kubernetes Я использую официальный Helm-чарт prometheus-community/prometheus. Он сразу поднимает основные компоненты: prometheus-server, alertmanager, node-exporter, kube-state-metrics. Чтобы установить чарт:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack

После этого Prometheus автоматически начинает собирать метрики с узлов и pod’ов. 2. Сбор метрик с приложений Помимо стандартных метрик Kubernetes (CPU, память, статус pod’ов), часто нужно мониторить собственные сервисы. Для этого я внедряю в приложения клиентскую библиотеку Prometheus (например, prometheus_client в Go или prom-client в Node.js) и экспонирую endpoint /metrics. В Kubernetes достаточно описать ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-monitor
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: http
    path: /metrics
    interval: 15s

Так Prometheus начнёт подтягивать кастомные метрики. 3. Настройка alerting’а через Alertmanager Важно не просто собирать метрики, но и уметь вовремя получать уведомления. С помощью Alertmanager я настраиваю правила в Prometheus:

groups:
- name: pod-alerts
  rules:
  - alert: PodCrashLooping
    expr: kube_pod_container_status_restarts_total > 5
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} в состоянии CrashLoopBackOff"
      description: "Контейнер {{ $labels.container }} перезапускался более 5 раз за последние 10 минут."

Эти алерты отправляются в Slack или Telegram-бота, чтобы команда всегда была в курсе. 4. Визуализация данных в Grafana Helm-чарт сразу разворачивает Grafana с готовыми дашбордами: Kubernetes Cluster Monitoring, Node Exporter, Kube State Metrics и т.д. Я дорабатываю эти дашборды под свои нужды: добавляю графики latency запросов, ошибок HTTP-кодов, значение очередей в RabbitMQ и другие ключевые метрики нашего окружения. 5. Советы по оптимизации производительности ▪️Увеличьте retention данных в Prometheus, если у вас достаточно дискового пространства. Например, --storage.tsdb.retention.time=30d. ▪️Настройте сервисы сбора метрик так, чтобы они не генерировали слишком «шумные» метрики (агрегация по нужным лейблам). ▪️Используйте Thanos или Cortex для долгосрочного хранения метрик, если у вас мультидатацентровая архитектура. Надеюсь, эта инструкция поможет вам быстро поднять качественный мониторинг Kubernetes. Если есть вопросы или примеры ваших реализаций — пишите в комментариях! Подпишись 👉@devopslib

Сегодня поговорим о том, как облегчить жизнь при масштабировании инфраструктуры с помощью Terraform и GitLab CI/CD. Если вы еще не пробовали объединять возможности инфраструктурного кода и конвейера сборки, самое время начать! ➡️ 1. Почему Terraform + GitLab CI? 🔵Terraform позволяет описать состояние вашей инфраструктуры в виде кода. Это не просто создание ресурсов, а контроль версий, ревью изменений и откат к любому предыдущему состоянию. 🔵GitLab CI/CD же отвечает за автоматизацию. Каждый коммит в ветку может запускать планирование изменений (terraform plan), согласование и применение (terraform apply) без участия человека. В итоге – стабильность и предсказуемость. ➡️ 2. Структура проекта: 🔵В корне репозитория размещаем директорию infra/, где храним модули Terraform для разных сред (staging, production). 🔵Создаем файл .gitlab-ci.yml, который запускает этапы в этом порядке: 1. terraform:init – инициализация рабочего каталога. 2. terraform:validate – проверка синтаксиса и форматирование. 3. terraform:plan – составление плана изменений. 4. По результатам plan – ручной approval (при необходимости) и terraform:apply для production. ➡️ 3. Пример простого конвейера на скрине В этом примере при каждом мердж-реквесте проверится валидность и отформатированность кода Terraform, а также будет сформирован план. Чтобы внести изменения в production, нужно вручную нажать “Play” на этапе apply. ➡️ 4. Секреты безопасности и best practices: 🔵Храните состояние (state) в надежном бекенде. Лучше всего – в S3 (или аналогах) с включенным шифрованием и версионированием. GitLab CI переменными задайте AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY, а файлы с учетными данными не храните в репозитории. 🔵Use workspaces для параллельных проверок: если у вас одно и то же окружение нужно тестировать для нескольких веток, включите поддержку разных Terraform workspaces (например, terraform workspace select feature-xyz). 🔵Разбейте инфраструктуру на модули. Один модуль – один кластер Kubernetes, другой – базы данных, третий – сеть. Это упростит поддержку и переиспользование кода. 🔵Политики и проверки. Интегрируйте с Terraform Sentinel или подобными инструментами (например, Open Policy Agent) для проверки соответствия стандартам (тэги, размеры инстансов и т. д.) перед применением. ➡️ 5. Переезд в Kubernetes под защитой Terraform Если вы используете EKS/GKE/AKS, можно описать кластер как ресурс Terraform, а потом — Helm-релизы через Terraform-Helm-провайдер. Тогда при пуше манифестов в репозиторий вы не только строите образ и пушите его в реестр, но и обновляете Helm-релиз в кластере. Конвейер превращается в единый источник правды для всего стека. ➡️ 6. Мониторинг и оповещения Не забудьте о интеграции с Prometheus и Alertmanager. Как только кластер Terraform появится, автоматизируйте развертывание необходимых Exporter’ов и настройку Alertmanager (через Terraform). В результате – сразу готовая к работе система мониторинга. ➡️ 7. Советы для ускорения CI/CD: 🔵Кешируйте плагины Terraform с помощью cache:key: files(...), чтобы избежать повторного скачивания провайдеров. 🔵Параллелите проверки: валидация, форматирование и статический анализ (такие инструменты, как tfsec) можно запускать в отдельных job’ах. 🔵Для крупных коммитов разбивайте apply на несколько этапов: сначала создаете ресурсы инфраструктуры (СУБД, сеть), потом — аппликацию, чтобы быстрее получить feedback. 💡 Совет от профи:

При масштабировании команды заведите отдельный GitLab-проект только для Terraform-модулей. В нем реализуйте строгие правила merge request’ов (например, обязательное ревью от тимлида и автоматический запуск tfsec). После этого подключайте эти модули как module в основном репозитории с приложением. Так вы централизуете контроль и снижаете риск несанкционированных правок.

Надеюсь, эти советы помогут вам выстроить надежный, безопасный и быстрый процесс управления инфраструктурой. Пробуйте, тестируйте и не бойтесь экспериментировать! Подпишись 👉@devopslib

Топ-3 ошибки при автоматизации деплоя в Kubernetes, которые я встречал чаще всего: 1. Слишком сложные Helm-чарты. Helm — это здорово, но если твой чартик уже напоминает анекдот про многоножку, пора задуматься. Многоуровневые шаблоны, тонны conditionals и переменных — через месяц никто не разберётся, что тут происходит. Минимализм — твой друг. 2. Забыли про resource limits. Запускаешь поды без ограничений? Поздравляю, твой кластер быстро превратится в поле битвы за CPU и память. Всегда прописывай requests/limits, даже если кажется, что нагрузка минимальная. 3. CI/CD пушит всё подряд без валидации. “Ну, тесты же зелёные!” — говорили они. Но лейблы невалидные, namespace перепутан, секреты не обновились... GitOps и pre-deploy проверки (например, kubeval, kube-score) помогут избежать многих слёз. Что бы ты добавил к этому списку? Подпишись 👉@devopslib

Почему не стоит гнаться за «идеальным» CI/CD Многие начинают выстраивать CI/CD пайплайн с мыслью: «Сделаю один раз – и будет идеально». Но реальность другая: пайплайн всегда живой. Всегда что-то меняется — появляются новые требования, новые сервисы, кто-то меняет окружение, версии зависимостей и так далее. Совет: начни с простого, а дальше итеративно развивай. Лучше иметь рабочий, пусть даже костыльный, пайплайн, чем месяцами строить «идеал», который никому не нужен. CI/CD — это не храм, а стройка с постоянным ремонтом. Автоматизируй то, что болит сейчас, не бойся переделывать завтра. P.S. И помни, хороший пайплайн тот, который команда понимает, а не тот, который ты один настроил по красоте. Подпишись 👉@devopslib

Привет, коллеги! Сегодня поговорим о том, как снизить MTTR (Mean Time To Recovery) в Kubernetes-кластере с помощью энд-то-энд алертинга и автоматических реакций. 1. Построение цепочки от метрик до оповещений * Собираем метрики с помощью Prometheus (Kube-state-metrics, node-exporter, cAdvisor). * Группируем латентные проблемы (высокая задержка, OOMKilled, CrashLoopBackOff) в единые алерты. * Настраиваем Alertmanager: маршрутизация по severity, дедупликация, ингибирование «шумных» оповещений. 2. Автоматическая диагностика * При срабатывании критического алерта запускаем вебхук в сервис диагностики (написанный на Python или Go). * Сервис получает метаданные инцидента, анализирует логи через Loki и трассировки из Jaeger, собирает первичные выводы. 3. Автофикс и эскалация * Если диагностика указывает на перезапуск пода или откачку к предыдущему рабочему ревизии, автоматически вызываем Job в Kubernetes. * Если проблема не решилась — мгновенная эскалация в командный чат (Slack/Telegram) с подробным дашбордом и ссылками на логи. 4. Результат * Благодаря такой цепочке MTTR уходит от часов к минутам. * Команда остается в курсе и получает готовую к расследованию сводку, а не десятки рассылаемых алертов. Подпишись 👉@devopslib

Привет, друзья! Сегодня разберём, как выстроить надёжный GitOps-процесс с помощью Argo CD и Kubernetes. 1. Архитектура репозитоpиев * Monorepo vs Multirepo: в зависимости от масштаба проектов выбирайте единое или раздельное хранилище манифестов. * Разделяйте окружения (prod/stage/dev) по разным папкам или веткам. 2. Декларативность * Храните все Kubernetes-манифесты (Deployment, Service, Ingress, ConfigMap, Secret) в Git. * Все изменения проходят через MR/PR с обязательным код-ревью и автоматическим CI-проверками (lint, kubeval). 3. Установка и конфигурация Argo CD

   kubectl create namespace argocd
   kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
   

* Подключите репозиторий: * URL: ваш Git-сервер * Type: Git * Auth: SSH-ключ или токен * Создайте приложение (Application), где укажете target-кластер и путь к манифестам. 4. Автосинхронизация и управление откатом * Включите syncPolicy.automated для мгновенного применения изменений. * Настройте pruneResources: true, чтобы удалять неактуальные объекты. * Активируйте selfHeal: true — Argo CD будет восстанавливать конфигурацию при ручных правках. 5. Мониторинг и оповещения * Подключите Prometheus и Grafana к Argo CD через метрики и вебхуки. * Настройте оповещения в Slack или Telegram о неудачных синках и drift’ах. 6. Секреты и конфигурации * Используйте Sealed Secrets или HashiCorp Vault для безопасного хранения. * Аргокаталоги монтируйте через CSI-драйверы, чтобы не держать секреты в Git. 7. Best Practices * Разделяйте права доступа через RBAC — кто может мёржить изменения в prod. * Периодически пересматривайте Git-историю и чистите устаревшие ветки. * Проводите тренировку «chaos engineering» — симулируйте сбои при помощи LitmusChaos или Chaos Mesh. Небольшой чеклист перед деплоем: * [ ] CI-лейблы зелёные * [ ] Артефакты в артефактном репозитории * [ ] Инфраструктурные тесты пройдены * [ ] Определён ответственный за rollback Успешного вам релиза и минимальных «рывков» в проде! Подпишись 👉@devopslib

💡 Когда docker system prune спасает твой диск... но не всё так просто Все мы знаем, что Docker любит кушать диск. Особенно, если часто собирать образы, поднимать временные контейнеры или играться с volume'ами. Рано или поздно ты ловишь No space left on device, и начинается пляска с du -sh * в /var/lib/docker. И вот тут на сцену выходит герой — docker system prune.

docker system prune -a --volumes

🔪 Удалит всё: * остановленные контейнеры * неиспользуемые образы * все dangling volume'ы * неиспользуемые networks Но вот в чём засада: он удалит и то, что тебе может быть нужно. Например, образы, которые не используются сейчас, но могут быть нужны через 5 минут. ⚠️ Советы по выживанию: * Перед запуском — проверь, что ты точно хочешь всё вычистить. * Если нужны только образы без volume'ов — не добавляй --volumes. * Лучше сначала посмотреть, что будет удалено:

docker system df

или

docker images --filter dangling=true

🧼 А ещё можно настроить регулярную очистку через cron или systemd timers, но аккуратно — лучше вручную, чем потерять нужное. Подпишись 👉@devopslib

🔥 Как мы убили latency на CI в 3 раза История из жизни. Был у нас CI-пайплайн, который стабильно занимал 15-20 минут. И вроде всё нормально: тесты, линтеры, билд, деплой. Но скорость фидбэка — как у черепахи в отпуске. 📍 Что тормозило: * docker build без кэша * установка зависимостей из публичных реп * линтеры и тесты гонялись в одном джобе * каждый merge запускал фулл CI, даже если правка в README 📍 Что сделали: 1. Разделили джобы на линт, тесты и билд — теперь они гоняются параллельно. 2. Кэш на зависимости — pip/npm/go modules теперь качаются за секунды. 3. Docker layer caching — включили в GitLab CI, теперь билдит только изменённое. 4. Path filters — мелкие коммиты типа в документацию не гоняют все джобы. 5. Pre-commit hook'и — половина косяков ловится до пуша. ⚡️Результат: пайплайн стабильно укладывается в 5-7 минут. А когда просто фиксим орфографию — вообще ничего не запускается. Идеально. Подпишись 👉@devopslib

🔥 Как я ускорил сборку Docker-образов на CI в 3 раза Недавно столкнулся с тем, что пайплайн на GitLab CI начал тормозить при сборке Docker-образов. Типа 7–10 минут на каждый пуш — слишком дорого. Начал копать и нашёл несколько простых, но эффективных трюков: 1. Мультистейдж-сборка Убрал всё лишнее из финального образа. Разделил билд и рантайм. Теперь в конечный образ не попадают dev-зависимости и тулзы типа curl, gcc, make. 2. Кэш на уровне CI Прописал в .gitlab-ci.yml использование docker build --cache-from. Сохраняю промежуточные образы в GitLab Registry — reuse слоёв реально работает. 3. Оптимизация Dockerfile Самое простое: сначала COPY package*.json, потом RUN npm install, и только потом COPY . . — уменьшает количество слоёв, которые нужно пересобирать. 4. Переход на BuildKit Включил DOCKER_BUILDKIT=1. Поддержка параллельных билдов и продвинутый кэш сделали своё дело. 5. Анализ с dive Прогнал образы через dive — нашёл пару мест, где слои были гигантские из-за временных файлов и неправильного порядка команд. 💡 В итоге время сборки упало с ~9 минут до 3. С учётом количества пушей в день - это как снять кирпич с сервера. Подпишись 👉@devopslib

🔥 Как я чуть не уронил прод из-за cronjob Обычное утро. Кофе, стендап, лёгкий PR в репу. И тут в монитор как шарахнет — прод API стал отвечать 5xx. Паника, алерты, PagerDuty в слезах. 📌 Что случилось? Каждый день в 04:00 по UTC запускался innocently выглядящий cronjob в Kubernetes. Он гонял тяжелую агрегацию по БД и триггерил пересчёт данных в Redis. Всё было нормально… пока нагрузка на базу не выросла, а кластер не стал экономить CPU. Результат: * Cronjob выжрал CPU ноды. * Redis улетел в swap. * Лимиты на pod’ах не были прописаны. * Horizontal Pod Autoscaler на проде не догнал ситуацию. * Пользователи увидели 503. 💡 Выводы, которые я сделал и которые сэкономят вам время и нервы: 1️⃣ Cronjob != безобидный скрипт. Он может быть убийцей. 2️⃣ У cronjob должны быть: * resource limits/requests * successfulJobsHistoryLimit * failedJobsHistoryLimit * ttlSecondsAfterFinished 3️⃣ Разделяй traffic и batch workloads. Лучше – на уровне неймспейсов/taints. 4️⃣ Логируй отдельно вывод cronjob, а не в общие логи. 5️⃣ Придумай throttling для тяжелых задач. И используй nice / ionice если запускаешь скрипты. 🛡️ А лучше всего — не доверяй cronjob, пока не докажет, что он не пёс-камикадзе. Подпишись 👉@devopslib

🛠 Кейс из жизни: почему пайплайн деплоя может "висеть" на step'е helm install Недавно заметил, что пайплайн деплоя зависает на шаге helm install. Логи — тишина. Время ожидания — в никуда. Проблема оказалась интересной и довольно редкой: зависание происходило из-за недоступности webhook'а Kubernetes admission controller'а, а не из-за самого Helm. Что происходило под капотом: Helm создаёт ресурсы через kubectl apply, но в кластере был установлен ValidatingWebhookConfiguration, который ожидал ответ от стороннего admission webhook'а. А тот лежал — под был удалён, сервис не восстановился, ingress не поднялся… В итоге API-сервер ждал ответа, который никогда не придёт, и не возвращал ошибку Helm'у. Решение: ▫️Проверить список webhook'ов:

  kubectl get validatingwebhookconfigurations
  

▫️Найти подозрительный и посмотреть, куда он указывает. ▫️Если сервис не работает и не критичен — удалить/отключить webhook. ▫️Альтернатива: установить timeout'ы на webhook'и, чтобы не зависало вечно:

  timeoutSeconds: 5
  

📌 Совет: если helm install висит без логов — не всегда виноват Helm. Иногда виноваты "умные" валидаторы, которые сломались. Подпишись 👉@devopslib

Почему у тебя в Kubernetes всё тормозит? Сегодня разберёмся с одной из самых частых причин лагов в Kubernetes — CPU throttling. Ты выделяешь контейнеру 500m CPU, думаешь, что всё окей, а потом он еле шевелится. Почему? Проблема в том, как работает cgroups и как kubelet распределяет ресурсы. Если ты задаёшь limits, но не задаёшь requests, Kubernetes может планировать твой под на перегруженный нод. А если ты задаёшь limits=requests, то любое кратковременное превышение лимита приводит к throttling, даже если на ноде полно свободных ресурсов! Как диагностировать? 1. Запусти kubectl top pod и посмотри, использует ли под меньше CPU, чем ты ожидал. 2. Используй kubectl debug или kubectl exec и глянь в /sys/fs/cgroup/cpu/cpu.stat. Если там много throttled_time — значит, контейнер душится. 3. Можно также использовать cadvisor или metrics-server для наблюдения за метриками. Что делать: • Не задавай limits, если не уверен, что они нужны. • Используй только requests, если хочешь гибкости. • В проде — мониторь метрики throttling и включай алерты. Контейнер, который выглядит занятым, но почти не потребляет CPU — это кандидат номер один на то, чтобы его освободить от удушающих лимитов. Подпишись 👉@devopslib

🛠 Как не облажаться с ansible vault на проде Работать с секретами через Ansible Vault — штука хорошая. Но вот ошибка — и у тебя либо прод лежит, либо пароль в логах. Вот несколько советов, как не сжечь всё к чертям: 🔐 1. Никогда не коммить vault-пароль. Создай .vault_pass.txt локально и добавь его в .gitignore. Или лучше вообще используй --ask-vault-pass и вводи вручную. 🧪 2. Проверяй перед запуском. ansible-vault view vars/secret.yml — убедись, что содержимое адекватное. Особенно если правишь руками. 🚨 3. Разделяй окружения. Разные vault-файлы на dev/stage/prod. И разные пароли. Один пароль на всё = один билет в ад. 📦 4. Не храни бинарные файлы в vault. Vault — для конфигов, токенов, API-ключей. Не надо туда пихать ssh-key в .pem формате. Это зло. Лучше — зашифруй файл gpg’шкой и держи отдельно. 🧯 5. Сделай дешифровку в CI защищённой. Vault-пароль передавай через секреты CI/CD. Никогда — через env переменные в открытом виде. Используй зашифрованные secrets в GitLab/GitHub Actions. И помни: если можешь не хранить секрет в repo — не храни. Подпишись 👉@devopslib

🚨 Когда df -h говорит "всё плохо", но ты не готов к reboot Иногда дисковое пространство заканчивается внезапно, особенно в /var или /tmp. В такие моменты хочется просто удалить всё подряд, но стоп — не забудь про старых врагов: 🧟 Zombie logs

find /var/log -type f -name "*.log" -mtime +7 -exec truncate -s 0 {} \;

Очищаем всё, что старше 7 дней, без удаления файлов (чтобы сервисы не офигели от потери файлов). 📦 Docker не прощает

docker system df
docker system prune -af --volumes

Временные образы и висячие volume'ы могут занимать десятки гигабайт. 📁 Жирные процессы

lsof | grep deleted | awk '{print $2}' | sort -u | xargs -r -n1 -P1 kill -9

Если файл удалён, но его держит процесс — место не освободится, пока не прибьёшь этого жадину. 🔁 Символическая боль

du -shx /* | sort -h

Следи, чтобы не считать примонтированные FS — -x спасёт от боли "а где всё место". 🧠 Не жди алертов. Сделай себе привычку проверять df, du, и docker system df хотя бы раз в неделю. И да, пора уже настроить auto-clean для journald 😉 Подпишись 👉@devopslib

⚙️ Терраформ: сколько состояний нужно проекту? Когда проект начинает разрастаться, многие допускают ошибку, оставляя одно общее состояние (terraform.tfstate) для всего. Это удобно в начале, но с ростом инфраструктуры приводит к хаосу: блокировки, медленные планы и катастрофические обновления. ✅ Лучшие практики: - Делить состояния по компонентам: база данных отдельно, приложения отдельно, сети отдельно. - Использовать backend с поддержкой блокировок (например, S3 + DynamoDB для AWS). - Организовать рабочие каталоги по окружениям: prod, staging, dev. - Автоматизировать через рабочие пространства (workspaces) или модули, если структура требует. И помни: хорошее управление состояниями — это не роскошь, а вопрос выживания проекта. Подпишись 👉@devopslib

Как не убить свой продакшн в пятницу вечером Есть старое правило: "Не выкатывай релизы в пятницу". Но почему, если всё автоматизировано и тесты зелёные? Потому что: - Даже идеальный код может сломаться на реальных данных. - Даже самая крутая инфраструктура может повести себя неожиданно. - Даже если баг фиксится быстро — собрать всех нужных людей в пятницу вечером сложно. Что делать: - Планируй релизы на начало недели. - Делай канареечные выкаты — сначала на часть пользователей. - Пиши чёткие план отката (rollback plan) к каждому релизу. - Настраивай алертинг и мониторинг заранее. И помни: лучше провести вечер за пиццей, чем за дебагом продакшна через VPN в кафе. Подпишись 👉@devopslib

🚀 Этапы построения надёжного CI/CD пайплайна 1. Определение требований и целей Перед началом нужно понять: - Какие языки и фреймворки используются? - Какие окружения нужны (Dev, Stage, Prod)? - Какие ограничения по безопасности? - Где будут хоститься приложения: AWS, GCP, Azure, on-prem? 2. Выбор инструментов Для надёжного CI/CD стоит выбрать проверенные инструменты: | Этап | Инструменты (примеры) |---------------------| ---------------------------------------| | VCS | Git (GitHub, GitLab, Bitbucket) | CI | GitHub Actions, GitLab CI, Jenkins, CircleCI | CD | ArgoCD, Spinnaker, FluxCD, Helm, Terraform | Контейнеризация | Docker, Podman | Оркестрация | Kubernetes (EKS, GKE, AKS, self-hosted) 3. Организация структуры репозитория Стандартизируйте репозиторий: - src/ — исходники - tests/ — тесты - infra/ — инфраструктура (Terraform, Ansible) - .github/workflows/ или .gitlab-ci.yml — pipeline-файлы 4. CI: Проверка кода Основные этапы CI: - 🧪 Юнит-тесты - 🧼 Линтинг - 🛡️ Security сканеры (например, Trivy, Snyk) - 📦 Сборка артефакта (Docker-образ, binary и т.п.) - 📂 Кэширование зависимостей (ускоряет сборку) Пример шага в GitHub Actions:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install deps
        run: npm ci
      - name: Run tests
        run: npm test

5. CD: Автоматическое развёртывание Продумайте каналы релиза: - Dev: автоматически по каждому пушу в develop - Staging: ручной запуск из CI - Production: только через Pull Request и одобрение CD-инструменты (например, ArgoCD или GitOps подход) автоматически разворачивают приложение из Git-репозитория манифестов. 6. Инфраструктура как код (IaC) Terraform, Ansible, Pulumi — обязательны для управляемости. Пример команды:

terraform init
terraform plan
terraform apply

7. Secrets Management Никаких секретов в коде! ✅ Используйте: - AWS Secrets Manager - HashiCorp Vault - GitHub/GitLab Secrets - Sealed Secrets (в K8s) 8. Мониторинг и оповещения После деплоя: - Мониторинг: Prometheus + Grafana, NewRelic, Datadog - Логи: ELK, Loki, CloudWatch - Алёрты в Slack/Telegram 9. Валидация и откат - Блю/Грин или Канареечный деплой - Автоматический откат при неуспешной health-check проверке 10. Security Best Practices - Автоматическая проверка CVE - Сканирование Docker образов - Ограничение доступа (IAM, RBAC) 🔒 Пример простого пайплайна (GitHub Actions + Docker + Kubernetes) 1. Пуш в main → запускается CI 2. Сборка Docker-образа и пуш в registry 3. Автообновление image в манифесте (kustomize/Helm) 4. ArgoCD замечает изменения и разворачивает новую версию Подпишись 👉@devopslib