🔧 Почему systemd – это не только про запуск сервисов

Многие до сих пор думают, что systemd нужен только для того, чтобы стартовать сервисы. Но на деле он — как швейцарский нож для линуксоидов.

Вот несколько его «скрытых» возможностей, которые ты, возможно, упускаешь:

🔹 systemd timers — альтернатива cron. Более гибкая, с логами, юнитами, и возможностью зависимости от других сервисов.

🔹 systemd-run — запускай любые команды как временный сервис. Отлично подходит для тестов, отложенного выполнения или запуска с нужными лимитами ресурсов.

🔹 Resource control (cgroups) — через systemd можно ограничить CPU, память, IO для любого юнита. Прям как в Kubernetes, только локально.

🔹 journalctl — лог-менеджер, которого ты заслуживаешь. Фильтры по юниту, по времени, по PID, по приоритету — goodbye, grep.

🔹 User units — можно писать юниты не только для root, но и для обычных пользователей. Отлично для изоляции окружений.

Если ты до сих пор относишься к systemd как к init-процессу — попробуй копнуть глубже. Он вполне может заменить кучу сторонних тулзов и сделать твою систему чище.

Подпишись 👉@devopslib

Kubernetes: не клади всё в один namespace 🧠

Кажется мелочью, но namespace — один из ключевых инструментов для поддержания порядка в проде. Правильное разделение — это безопасность, изоляция и удобство поддержки. Разберём, как использовать namespace’ы по-взрослому.


Зачем это вообще нужно?

Namespace в Kubernetes — способ логической изоляции ресурсов. Если не следить за этим, вы рискуете:
- словить конфликт имён между сервисами
- дать доступ тем, кому не надо
- усложнить отладку и мониторинг


Что стоит выносить в отдельные namespace'ы:

1. По окружениям
Создайте dev, staging, prod — и не пересекайте. Это основа безопасного и предсказуемого CI/CD.

2. По командам или микросервисам
Например, team-a, team-b, billing, auth. Удобно для разграничения прав и алертов.

3. По системным компонентам
Например, monitoring, logging, infra. Не мешайте Prometheus и Nginx Ingress с боевыми сервисами.


Бонусы от правильной изоляции:

- RBAC на namespace — это 🔐 DevSecOps must-have
- Снижается blast radius при ошибках (kubectl delete all --all -n wrong-namespace — и прод цел)
- Упрощается мониторинг: фильтрация по namespace в Grafana — как отдельный дешборд
- Логи в Loki, метрики в Prometheus — нагляднее и чище


Антипаттерны, которых стоит избегать:

🚫 Один namespace на всё (особенно default)
🚫 Генерация namespace в CI (ns-392839) без чистки
🚫 Namespace без resource quotas и limit ranges


Вывод:
Разделяй и властвуй. Namespace — не просто "для красоты", а фундамент для масштабируемого, безопасного и поддерживаемого кластера. Если вы до сих пор всё кидаете в default — пора рефакторить 🛠


📚 Дополнительно:
- https://kubernetes.io/ru/docs/concepts/overview/working-with-objects/namespaces/
- https://github.com/kubernetes-sigs/kustomize

Подпишись 👉@devopslib

🛠 Как DevOps превращается в саппорта: незаметный дрейф

Инфра стабильна. Мониторинг молчит. Алёрты — тишина.
Ты думаешь: «Ну наконец-то! Можно позакрывать долги, потрогать Terraform, почитать про eBPF…»

И тут приходит тикет:
> «Что-то не работает»
> «Перезапустите под»
> «Очистите кеш в Redis»
> «Можно дать доступ другу моего кота в Kubernetes?»

И ты уже не инженер. Ты саппорт. Уровень 0.
С каждым таким тикетом ты немного забываешь, как настраивать Helm-чарты и лочить версии в Ansible.

📌 Как не утонуть:
- Фильтруй. Не всё требует DevOps-инженера. Делегируй.
- Автоматизируй. Скрипты, self-service, боты.
- Защищай фокус. Оповести команду: есть баг — пиши в багтрекер, а не в личку.
- Заводи «тихие часы» без чатов — только код.

DevOps — не helpdesk.
Напоминай об этом не только другим, но и себе.

Подпишись 👉@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

🔥 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

🚀 Этапы построения надёжного 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

Как не убить свой продакшн в пятницу вечером

Есть старое правило: "Не выкатывай релизы в пятницу". Но почему, если всё автоматизировано и тесты зелёные?

Потому что:
- Даже идеальный код может сломаться на реальных данных.
- Даже самая крутая инфраструктура может повести себя неожиданно.
- Даже если баг фиксится быстро — собрать всех нужных людей в пятницу вечером сложно.

Что делать:
- Планируй релизы на начало недели.
- Делай канареечные выкаты — сначала на часть пользователей.
- Пиши чёткие план отката (rollback plan) к каждому релизу.
- Настраивай алертинг и мониторинг заранее.

И помни: лучше провести вечер за пиццей, чем за дебагом продакшна через VPN в кафе.

Подпишись 👉@devopslib

⚙️ Терраформ: сколько состояний нужно проекту?

Когда проект начинает разрастаться, многие допускают ошибку, оставляя одно общее состояние (terraform.tfstate) для всего. Это удобно в начале, но с ростом инфраструктуры приводит к хаосу: блокировки, медленные планы и катастрофические обновления.

✅ Лучшие практики:
- Делить состояния по компонентам: база данных отдельно, приложения отдельно, сети отдельно.
- Использовать backend с поддержкой блокировок (например, S3 + DynamoDB для AWS).
- Организовать рабочие каталоги по окружениям: prod, staging, dev.
- Автоматизировать через рабочие пространства (workspaces) или модули, если структура требует.

И помни: хорошее управление состояниями — это не роскошь, а вопрос выживания проекта.

Подпишись 👉@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

🛠 Как не облажаться с 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

Почему у тебя в 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

🔥 Как я чуть не уронил прод из-за 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

🔥 Как я ускорил сборку 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

🔥 Как мы убили 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 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

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

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

Почему не стоит гнаться за «идеальным» CI/CD

Многие начинают выстраивать CI/CD пайплайн с мыслью: «Сделаю один раз – и будет идеально». Но реальность другая: пайплайн всегда живой. Всегда что-то меняется — появляются новые требования, новые сервисы, кто-то меняет окружение, версии зависимостей и так далее.

Совет: начни с простого, а дальше итеративно развивай.
Лучше иметь рабочий, пусть даже костыльный, пайплайн, чем месяцами строить «идеал», который никому не нужен.
CI/CD — это не храм, а стройка с постоянным ремонтом.
Автоматизируй то, что болит сейчас, не бойся переделывать завтра.

P.S. И помни, хороший пайплайн тот, который команда понимает, а не тот, который ты один настроил по красоте.

Подпишись 👉@devopslib

Топ-3 ошибки при автоматизации деплоя в Kubernetes, которые я встречал чаще всего:

1. Слишком сложные Helm-чарты.
Helm — это здорово, но если твой чартик уже напоминает анекдот про многоножку, пора задуматься. Многоуровневые шаблоны, тонны conditionals и переменных — через месяц никто не разберётся, что тут происходит. Минимализм — твой друг.

2. Забыли про resource limits.
Запускаешь поды без ограничений? Поздравляю, твой кластер быстро превратится в поле битвы за CPU и память. Всегда прописывай requests/limits, даже если кажется, что нагрузка минимальная.

3. CI/CD пушит всё подряд без валидации.
“Ну, тесты же зелёные!” — говорили они. Но лейблы невалидные, namespace перепутан, секреты не обновились... GitOps и pre-deploy проверки (например, kubeval, kube-score) помогут избежать многих слёз.

Что бы ты добавил к этому списку?

Подпишись 👉@devopslib