👨‍💻 Штатный SRE бесплатно

Когда «горит», а времени и ресурса ноль — используйте промпт ниже. Он за минуты выдаст гипотезы, точные проверки и безопасные фиксы.

Промпт:

Ты — дежурный SRE на on‑call. Я дам исходные данные ниже; составь максимально конкретный пошаговый план (не более 10 шагов). Для каждого шага обязательно укажи: гипотезу, точные проверки с командами и пример ожидаемого вывода или паттерна в логах, какие метрики/пороги проверять, критерии завершения шага, безопасный фикс (точные команды и изменения конфига если нужно), команду для отката, уровень риска (низкий/средний/высокий) и примерное время выполнения. В конце дай краткий итог и шаблон инцидентного отчёта.

Заполни следующие поля вместо <> перед выполнением:
- Симптомы: <что наблюдаем — метрики, ошибки, поведение сервиса>
- Сервис/имя Pod/Deployment/VM: <имя сервиса или ресурс>
- Среда: <K8s/VMs> (укажи версию k8s/OS, namespace, количество нод)
- Время начала и SEV: <время, SEV1/2/3>
- Лог-кусок: <фрагмент лога — несколько строк>
- Доступы/ограничения: <можно ли рестартить поды/вносить изменения, maintenance window, контактные лица>

Требования к выходу (формат):
1) Нумерованный список шагов (1..N up to 10). Для каждого шага поля: {гипотеза; проверки: команды и ожидаемый вывод; метрики/логи и пороги; критерии завершения; безопасный фикс (команды/patch) ; команда отката; риск; время}
2) Если даётся kubectl-команда — используй явные флаги (namespace, -o json/yaml, --field-selector) и безопасные опции (например --dry-run=client для изменений) там, где применимо.
3) Метрики указывай конкретно: metric_name (источник, e.g. Prometheus) и порог (например error_rate > 5% за 5m).
4) Включи дополнительные рекомендованные команды для диагностики сети/IO/сторонних зависимостей (curl, ss, top, iostat) по необходимости.
5) В конце — краткое резюме с рекомендуемым порядком действий после инцидента (postmortem checklist).

🐸Библиотека devops'a

#буст

🔍 Ракетный поиск по файлам

Когда вы запускаете grep для поиска по проекту, он будет по умолчанию искать во всех файлах, включая большие бинарные файлы, временные файлы или скрытые директории, такие как .git, что может замедлить поиск.

А Ripgrep автоматически игнорирует:

• Файлы и директории, указанные в .gitignore
• Файлы, указанные в .ignore и .rgignore
• Скрытые файлы и директории
• Бинарные файлы

Когда вы запускаете команду rg, она проверяет файлы и папки, которые вы хотите включить в поиск, и игнорирует все файлы и каталоги, которые находятся в списках игнорирования.

🐸Библиотека devops'a

#буст

🔑 Разбор SSH-ошибок

SSH — любимый инструмент админов и разработчиков. Но бывает: запускаешь «ssh user@server», и вместо приветствия получаешь красное сообщение об ошибке. Давайте разберём самые частые кейсы и что делать в каждом.

1. Timeout при подключении

ssh: connect to host X.X.X.X port 22: Operation timed out

Что проверить:

• Сервер реально запущен и доступен (ping, curl).
• Порт 22 открыт в firewall (ufw status, iptables -L).
• На сервере работает sshd
• Нет ли блокировки со стороны провайдера.

2. Connection refused

ssh: connect to host X.X.X.X port 22: Connection refused

Что делать:

• Запустить SSH-демон:

sudo systemctl start ssh
sudo systemctl enable ssh

• Проверить конфиг /etc/ssh/sshd_config: порт и ListenAddress.

3. Permission denied (publickey)

Permission denied (publickey)

Причины:
• Неверное имя пользователя
• Не тот приватный ключ
• Ключ в неправильном формате (.ppk вместо OpenSSH)

4. Host key verification failed

Host key verification failed.

Фикс: удалить старую запись:

ssh-keygen -R server_ip

и подключиться заново.

В 90% случаев SSH-проблемы кроются в трёх местах: сеть, демон sshd, ключи и права.

🐸Библиотека devops'a

#буст

💻 Работа с Kubernetes без шума

kubectl-neat — инструмент для очистки выводов команд kubectl get в k8s. Он удаляет избыточную информацию из YAML и JSON манифестов, оставляя только важные данные.

Как использовать:

kubectl get pod mypod -o yaml | kubectl neat

В результате вывод будет очищен от ненужных временных меток, идентификаторов и данных о статусах, что упрощает восприятие манифестов.

kubectl-neat помогает быстрее анализировать конфигурации и сокращает объем выводимой информации, делая её более читабельной.

➡️ Репозиторий проекта

🐸Библиотека devops'a

#буст

🐳 Фишки Docker Compose

Нашли для вас видео с фишками по Docker Compose.

От чёткой структуры каталогов и использования .env файлов для безопасности до Docker Labels для фильтрации контейнеров и health checks для проверки их работоспособности.

➡️ Смотреть видео

🐸Библиотека devops'a

#буст

🧩 Алиасы для повседневной работы

Если вы устали каждый раз набирать километровые команды в Docker, самое время завести алиасы.

В ~/.bashrc или ~/.zshrc:

alias dps="docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'"
alias dclean="docker system prune -af --volumes"
alias dexec="docker exec -it"
alias dlogs="docker logs -f --tail=100"

• dps → красиво покажет список контейнеров,

• dclean → очистит неиспользуемые контейнеры, образы и volume,

• dexec my_container bash → войдёт в контейнер,

• dlogs my_container → выведет последние 100 строк логов и будет стримить новые.

🐸Библиотека devops'a

#буст

🐳 Прямая доставка Docker-образов на сервер

Сколько раз вам приходилось публиковать Docker-образ в удалённый registry только для того, чтобы потом его скачать на сервер?

Часто это неудобно: публичные реестры — риск для приватности, собственные — дополнительная инфраструктура, docker save/load — копирует весь образ, даже если изменились лишь последние слои.

Unregistry решает эту задачу просто и эффективно: он запускает на сервере временный контейнер-реестр и позволяет отправить образ напрямую с вашего локального Docker через SSH, передавая только отсутствующие слои.

Пример:

docker pussh myapp:latest user@server

За кулисами это происходит так:

1. По SSH создаётся туннель на сервер.
2. Там запускается временный контейнер Unregistry.
3. Через туннель пробрасывается локальный порт и происходит docker push в Unregistry.
4. Передаются лишь слои, которых нет на сервере.
5. После завершения — контейнер удаляется, SSH-сессия закрывается.

➡️ Репозиторий проекта

🐸Библиотека devops'a

#буст

🚀 Миграция с облака на землю

Для многих компаний облачные технологии — это идеальный старт, но когда они достигают новых масштабов, возникает потребность в большей автономии и контроле.

Нужно быть наготове, поэтому мы составили промпт для переезда с облаков.

Промпт:

Ты — опытный DevOps инженер, известный своей экспертизой в области облачной инфраструктуры, развертывания на «голом» оборудовании и безупречных стратегий миграции.

Твоя цель — разработать комплексный план по миграции существующей облачной инфраструктуры в среду с использованием "голого" оборудования. Этот план должен охватывать все ключевые аспекты, включая архитектуру, миграцию данных, безопасность, автоматизацию и дальнейшее обслуживание.

Вот задача, с которой тебе предстоит справиться:
<Описание инфраструктуры>

🐸Библиотека devops'a

#буст

⚙️ Миграция Ingress-контроллера

NGINX выкатили две части гайда по переезду на ingress контроллер.

🧩 Часть 1 — зачем и на что переходить

Разграничить что у вас сейчас: ingress-nginx, аннотации, сниппеты; и чего не хватает: производительность, безопасность, наблюдаемость, продвинутые маршруты.

Понять ценность NGINX Ingress Controller: CRD вместо зоопарка аннотаций, гибкие L7/L4-сценарии, интеграции c Prometheus/Grafana/OTel, опции безопасности: mTLS, WAF, JWT.

Решение: «оставаться» vs «переезжать» — исходя из требований к SLA, масштабированию и управляемости конфигураций.

🚚 Часть 2 — как мигрировать без боли

Инвентаризация: собрать все Ingress-объекты, аннотации, кастомные директивы.

Параллельный запуск: поднять NGINX IC с иным ingressClassName, не трогая прод.

Трансляция в CRD: перевести ключевые правила маршрутизации/безопасности в VirtualServer, Policy, и т. п.

Тестирование: функционал, нагрузка, мониторинг; убедиться в паритете поведения.

Плавный cutover: canary / blue-green / DNS-переключение с возможностью быстрого отката.

Деактивация legacy: убрать старый контроллер, почистить артефакты и документацию.

Cначала стратегия потом «параллельный мост» и поэтапный перенос. Минимум даунтайма, максимум контроля и наблюдаемости.

🐸Библиотека devops'a

#буст

👨‍💻 Автоматизация соблюдения требований

HashiCorp вводит концепцию Policy as Code — автоматизированного подхода к проверке соблюдения требований в инфраструктуре.

Вместо традиционного использования документов и тикетов, политики описываются как код, что позволяет интегрировать их в процесс развертывания и получать обратную связь за секунды.

Это повышает продуктивность, снижает риски и уменьшает затраты, обеспечивая соответствие стандартам безопасности, соответствия и архитектуры.

➡️ Блог HashiCorp

🐸Библиотека devops'a

#буст

🚀 Хороший образ, плохой образ

Docker — это не только про контейнеры, но и про грамотный подход к их созданию. Собрали советы, которые сделает ваши образы безопаснее, легче и быстрее.

1. Лейблы важны

Добавляйте метаданные LABEL maintainer="dev@company.com" version="1.2.0", чтобы понимать: кто собрал образ, зачем он нужен и какой это релиз. Это упростит отладку и автоматизацию в CI/CD.

2. Сканируйте образы на уязвимости

Перед выкладкой прогоняйте образы через Trivy или Grype:

trivy image myapp:1.0.0

3. Запускайте контейнеры от непривилегированного пользователя

Не используйте root без необходимости.

RUN adduser --disabled-password appuser
USER appuser

4. Используйте .dockerignore

Не надо тащить в образ .git, тестовые файлы и кэш IDE.

.git
node_modules
*.log

5. Мультистейдж-сборка

Стройте, а потом очищайте.

FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

FROM alpine:3.18
COPY --from=builder /app/main .
CMD ["./main"]

6. Используйте конкретные версии образов

FROM python:3.11.4 лучше, чем FROM python:latest.
Это делает сборки предсказуемыми и исключает сюрпризы при апдейтах.

7. Следите за порядком слоёв

Сначала копируйте файлы, которые редко меняются (requirements.txt), а уже потом код.
Так кэширование будет работать эффективнее.

8. Используйте переменные окружения

Они упрощают деплой на разных средах:

ENV APP_ENV=production

9. Используйте официальные образы

Начинайте с доверенных источников — они безопаснее и поддерживаются сообществом.
Например:

FROM nginx:1.25-alpine

Профессиональный Docker — это не про магию, а про дисциплину.

🐸Библиотека devops'a

#буст

📌 Команда для проверки порта

Вы запускаете сервис, а терминал отвечает, что адрес уже занят.

Эта команда покажет, какой процесс слушает нужный порт:

lsof -i :8080

В ответ вы увидите PID процесса и имя бинаря, который держит порт.

🐸Библиотека devops'a

#буст

🔒 4 преимущества гибридной миграции

Booking поделились опытом гибридной миграции в облако, подчеркнув четыре ключевых выигрыша в безопасности:

• Централизованное управление секретами — все креденшалы, токены и ключи хранятся безопасно и управляются единым инструментом.

• Повышенный контроль доступа — точные политики и роли для пользователей и сервисов уменьшают риск несанкционированного доступа.

• Автоматизация и аудит — процессы деплоя и изменения инфраструктуры автоматизированы и полностью логируются для проверки безопасности.

• Снижение человеческих ошибок — инфраструктура как код и проверенные шаблоны минимизируют ручные операции, которые часто приводят к уязвимостям.

🐸Библиотека devops'a

#буст

⚙️ Как работать с .env файлами в Kubernetes

В Kubernetes можно использовать .env файлы для хранения переменных окружения, которые затем можно применить в контейнерах. Вместо того чтобы вручную прописывать каждую переменную в Kubernetes, можно использовать стандартные .env файлы

Как это работает

1. Создаём .env файл

# app.env
APP_NAME=MyCoolApp
APP_ENV=production
APP_DEBUG=false

2. Применяем .env в Pod через ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-env
data:
  # Kubernetes автоматически прочитает строки из файла app.env
  # в v1.34 можно указать директорию с .env файлами через envFrom
  APP_NAME: MyCoolApp
  APP_ENV: production
  APP_DEBUG: "false"

3. Используем ConfigMap в контейнере

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
  - name: demo-container
    image: nginx
    envFrom:
      - configMapRef:
          name: app-env

Теперь контейнер получает переменные окружения напрямую из .env файла.

🐸Библиотека devops'a

#буст

👀 Домашний докер

Наткнулись на видео, где показывается интересный подход к организации Docker контейнеров в домашней лаборатории. Вместо использования решений вроде Kubernetes, в видео предлагается настройка на виртуальной машине с Debian, с привязкой томов.

А ещё в видео демонстрируется использование нескольких полезных Docker контейнеров, таких как Fresh RSS для удобного чтения новостей, Jellyfin для медиастриминга и Netbird для создания безопасных сетевых соединений.

➡️ Смотреть видео

🐸Библиотека devops'a

#буст

🔄 Жизненный цикл пода в Kubernetes

Жизненный цикл пода в Kubernetes — это цепочка процессов, от создания манифеста до завершения работы контейнеров. Сейчас разберем, как происходит запуск, мониторинг и завершение подов в Kubernetes.

1. Отправка манифеста пода и сохранение в etcd

Первым шагом при создании пода является отправка его манифеста в API-сервер Kubernetes. Этот запрос проверяется на корректность, и после успешной проверки информация о поде сохраняется в распределённом хранилище etcd, которое является источником правды для всего кластера.

2. Выбор ноды для пода планировщиком

После того как манифест пода успешно сохранен, наступает этап его размещения. планировщик Kubernetes принимает решение о том, на какую ноду будет размещен под.

Этот процесс основан на нескольких критериях:

• количество доступных CPU и памяти.

• правила, которые могут ограничивать или рекомендовать размещение подов на определённых нодах.

• метки или предпочтения, которые могут влиять на выбор ноды.

3. Подготовка пода на выбранной ноде

После того как нода была выбрана, на ней начинает работать kubelet, агент, который занимается подготовкой пода.

4. Запуск контейнеров и мониторинг их состояния

Как только все подготовительные работы завершены, контейнеры начинают переходить в состояние Running. На этом этапе Kubernetes использует health probes для мониторинга состояния контейнеров.

5. Мониторинг фаз пода

Kubernetes отслеживает состояние пода на высокоуровневом уровне. Изначально под находится в статусе Pending, затем, когда контейнеры начинают свою работу, он переходит в фазу Running.

После завершения работы под может попасть в одну из следующих фаз:

• Succeeded — если контейнеры завершили свою работу без ошибок.

• Failed — если контейнеры завершили работу с ошибками.

• Unknown — если состояние пода не удается определить по каким-либо причинам.

6. Завершение работы пода и очистка ресурсов

Когда контейнеры в поде завершили свою работу, Kubernetes посылает SIGTERM сигнал для корректного завершения их работы. Если контейнеры не успевают завершиться в отведённое время, Kubernetes отправляет SIGKILL, чтобы принудительно их остановить.

🐸Библиотека devops'a

#буст

⚙️10 стратегий снижения рисков в гибридных облаках

Гибридные облака — это для тех, кто хочет гибкость и масштабируемость, но они также приносят с собой уникальные риски. Без корректной стратегии эти риски могут привести к уязвимостям в безопасности, проблемам с управлением ресурсами и даже утечкам данных.

Чтобы эффективно управлять гибридной инфраструктурой, необходимо соблюдать правила, которые помогут снизить эти риски и повысить стабильность.

➡️ Про стратегии минимизации рисков в статье

🐸Библиотека devops'a

#буст

🐳 Шпаргалка по сетям Docker

Docker изолирует контейнеры не только по процессам и файловой системе, но и по сети. От этого зависит, смогут ли контейнеры общаться между собой, будут ли они доступны извне и насколько безопасно это взаимодействие.

Основные типы сетей

• Bridge — сеть по умолчанию.

Контейнеры получают внутренний IP и могут общаться друг с другом. Для связки нескольких сервисов в одной среде лучше создавать свои пользовательские сети (docker network create). Тогда контейнеры будут доступны по имени, например ping db.

• Host — общая сеть с хостом.

Контейнер не имеет отдельного IP: он использует сетевой стек машины. Это снижает изоляцию, но убирает накладные расходы на маршрутизацию. Подходит для сервисов, где важна скорость.

• None — полная изоляция.

Контейнер запускается без сети. Применяется редко, в основном для задач, где сеть не нужна (утилиты, тесты).

• Overlay — сеть для кластера.

Объединяет несколько Docker-хостов. Используется в Swarm и Kubernetes. Контейнеры на разных серверах работают так, будто они рядом.

• Macvlan — контейнер как полноценный участник LAN.

Контейнер получает MAC-адрес и «выглядит» в локальной сети как отдельное устройство. Это удобно, если требуется доступ из реальной сети напрямую, например для IoT или legacy-приложений.

Полезные команды

Список сетей:

docker network ls

Подробная информация о сети:

docker network inspect bridge

Создать сеть:

docker network create mynet

Удалить сеть:

docker network rm mynet

Подключить контейнер к сети:

docker network connect mynet app1

Отключить контейнер от сети:

docker network disconnect mynet app1

🐸Библиотека devops'a

#буст

🔄 Как переехать из Kubernetes в Terraform

Когда инфраструктура разрастается — десятки кластеров, множество регионов, разные окружения — управление Kubernetes через локальные манифесты, Helm-чарты, скрипты и ad-hoc утилиты становится болью.

Почему вообще стоит рассматривать Terraform

— Единый подход к инфраструктуре как к коду (IaC). Меньше ad-hoc скриптов, меньше особенных случаев.

— Одинаковые шаблоны, модули, terraform-пакеты можно применять для разных кластеров, регионов, окружений.

— Когда инфраструктура описана декларативно в Terraform, её проще тестировать, планировать изменения и откатывать.

С чего начать переезд

Прежде чем двигать сервисы, стоит договориться о структуре: где хранится код, как выглядят модули, как будут разделены окружения вроде dev, staging и prod.

Важно определиться с управлением состоянием: локальные файлы .tfstate неприемлемы в продакшене, поэтому лучше сразу настроить удалённое хранилище — например, S3 с DynamoDB для блокировок или Terraform Cloud.

Следующий шаг — начать с малого. Не стоит пытаться перенести сразу весь кластер или десятки сервисов. Лучше выбрать один изолированный сервис, у которого нет сложных зависимостей, и попробовать описать его в Terraform.

Так команда поймёт процесс, столкнётся с первыми проблемами импорта и научится проверять планы перед применением.

Когда базовые принципы обкатаны, становится ясно, что без инструментов миграция будет мучительной. Поэтому стоит вложиться в создание шаблонов и модулей. Один модуль может описывать типовой сервис — Deployment, Service и Ingress. Другой — целый namespace или набор ресурсов для окружения.

Самая непростая часть — импорт существующих ресурсов. Kubernetes кластеры редко пустые, в них уже работают десятки объектов. Их нужно постепенно поднимать под контроль Terraform, используя команду terraform import. Но просто импортировать недостаточно — нужно сверять, чтобы конфигурация в HCL совпадала с реальностью.

Когда появляется больше кластеров, возникает вопрос мультикластерного управления. Terraform позволяет описывать несколько провайдеров и работать с ними через алиасы. Это значит, что можно использовать одни и те же модули для разных окружений, меняя только контекст и параметры.

Главная ценность миграции — в стандартизации. Инфраструктура становится предсказуемой и масштабируемой, а команды получают единый язык управления. Это долгий процесс, но итогом становится устойчивая и безопасная платформа.

🐸Библиотека devops'a

#буст

🔄 Миграция пайплайнов

GitHub Actions и GitLab CI/CD похожи по сути, но несовместимы по форме. Просто копипаста из .github/workflows недостаточно — у GitLab свой формат, правила и возможности. Поэтому мы подготовили для вас промпт для удобного переезда.

Промпт:

Перенеси нашу текущую систему CI/CD с платформы GitHub на GitLab CI/CD, включая все workflow, скрипты и конфигурации из .github/workflows. Адаптируй конфигурации под формат .gitlab-ci.yml с учётом особенностей GitLab CI, языков программирования, используемых инструментов и окружений в проекте. Обеспечь корректную работу всех этапов сборки, тестирования и деплоя, а также настрой уведомления и артефакты. В конце опиши поэтапно весь процесс миграции, укажи все необходимые изменения и предоставь рекомендации по проверке и отладке нового CI/CD конвейера.

🐸Библиотека devops'a

#буст