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

Привет, друзья! Сегодня хочу поделиться своим опытом настройки мониторинга 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

🔥 Helm как оружие массового деплоя: лучшие практики и грабли Helm — неотъемлемый инструмент в арсенале любого DevOps-инженера, работающего с Kubernetes. Но с ростом количества чартов и окружений легко наступить на старые грабли. Разберём, как использовать Helm эффективно и безопасно. 🧩 1. Разделяй и властвуй: структура чартов Многие начинают с одного монолитного чарта, но это быстро выходит из-под контроля. Рекомендации: - Используй umbrella chart для сложных сервисов - Выноси повторяемые компоненты в зависимые чарты (shared ingress, redis, etc.) - DRY: общие шаблоны в _helpers.tpl Пример:

{{- define "myapp.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

🔐 2. Конфиденциальность прежде всего Не храни secrets в values.yaml. Используй: - Sealed Secrets - External Secrets Operator - Шаблонизацию из Vault через helm template + envsubst 🚀 3. CI/CD и Helm: как подружить Интеграция Helm в GitHub Actions или GitLab CI: - Используй helm lint и helm template для проверки - Делай dry-run перед деплоем - Храни versioned values-файлы в Git для окружений GitLab пример:

deploy:
  script:
    - helm upgrade --install myapp ./chart --values values-prod.yaml --atomic

🧠 4. Версионирование и откаты Каждый деплой — новая версия: - helm rollback — must-have в инцидентах - Храни changelog в Chart.yaml (appVersion, version) - Применяй GitOps-подход: Helmfile, ArgoCD, Flux ✅ Вывод: Helm — мощный инструмент, если его не превращать в набор костылей. Избегай хранения конфиденциалки в явном виде, поддерживай структуру чартов чистой и используй Helm как часть CI/CD, а не вручную. И не забывай про helm diff перед обновлениями 😉 Подпишись 👉@devopslib

🚀 Как правильно выбрать образ для контейнера в продакшн Погнали! Выбираешь образ для своего контейнера — казалось бы, что тут сложного? ubuntu:latest, node:alpine, python:3.11 — звучит знакомо, да? Но на проде каждая мелочь имеет значение. 🧩 Вот чеклист, как выбрать правильный образ: 1. Минимализм решает - Меньше образ — меньше поверхность атаки. - alpine, distroless, scratch — отличные кандидаты. - Но не забывай: в alpine может не быть нужной тебе библиотеки. Проверь заранее. 2. Понимание зависимостей - Не ставь лишнего. Не нужен тебе curl, vim, gcc — не ставь. - Чем меньше зависимостей, тем проще отлаживать, меньше шансов на уязвимости. 3. Только стабильные теги - Никогда не используй latest в продакшене. - Всегда указывай конкретную версию: python:3.11.3, node:18.16.0. 4. Сканируй образы - Используй trivy, grype, dockle. - Встроенные инструменты в CI — мастхэв. 5. Собирай свои образы - Не бойся билдить свои минимальные образы на базе scratch или distroless. - Так ты точно знаешь, что внутри. 💡 Микро-лайфхак: если тебе нужно просто что-то запустить в минималистичном окружении — посмотри на busybox. Это магия. Контейнеры — это не просто “запустить что-то”. Это часть твоей безопасности, скорости и стабильности. Подпишись 👉@devopslib

🛠 Как DevOps превращается в саппорта: незаметный дрейф Инфра стабильна. Мониторинг молчит. Алёрты — тишина. Ты думаешь: «Ну наконец-то! Можно позакрывать долги, потрогать Terraform, почитать про eBPF…» И тут приходит тикет: > «Что-то не работает» > «Перезапустите под» > «Очистите кеш в Redis» > «Можно дать доступ другу моего кота в Kubernetes?» И ты уже не инженер. Ты саппорт. Уровень 0. С каждым таким тикетом ты немного забываешь, как настраивать Helm-чарты и лочить версии в Ansible. 📌 Как не утонуть: - Фильтруй. Не всё требует DevOps-инженера. Делегируй. - Автоматизируй. Скрипты, self-service, боты. - Защищай фокус. Оповести команду: есть баг — пиши в багтрекер, а не в личку. - Заводи «тихие часы» без чатов — только код. DevOps — не helpdesk. Напоминай об этом не только другим, но и себе. Подпишись 👉@devopslib