🛠 Что происходит, когда вы вводите curl google.com?

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

1. DNS-резолвинг
curl сначала узнаёт IP-адрес для google.com. Для этого он обращается к системному резолверу, который опрашивает DNS-сервер (например, 8.8.8.8).

2. Установление TCP-соединения
Как только IP получен, curl инициирует TCP Handshake (SYN → SYN-ACK → ACK) на порт 80 (или 443 для HTTPS).

3. TLS Handshake (если HTTPS)
Если вы не указали http://, curl по умолчанию стучится по HTTPS (порт 443). Тогда идёт обмен сертификатами, проверка CA, установка сессионных ключей.

4. Отправка HTTP-запроса
После установления соединения curl отправляет HTTP-запрос вида:
GET / HTTP/1.1
Host: google.com
User-Agent: curl/7.79.1
...

5. Получение ответа
Google возвращает HTTP-ответ (200 OK, 301 Redirect и т.д.) и тело страницы, если оно есть.

6. Закрытие соединения
curl может держать соединение открытым или закрыть его в зависимости от заголовков (Connection: keep-alive / close).

🧠 Это базовый сценарий. Но вы можете добавить -v для отладки, --resolve для подмены DNS, --http2 для тестов HTTP/2, и кучу всего ещё.


Используете curl только для запросов? Пора качнуть скилл: тест API, дебаг прокси, TLS-тесты, даже работа с SOCKS5 — это всё в арсенале curl.

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

🎯 Почему логи — твои лучшие друзья (или враги)

Сегодняшний кейс: одна из прод — JVM-аппка начала резко жрать CPU.
Люди в панике, мониторинг орёт, прод выдыхает. Что первым делом? Лезем в логи.

Но вот нюанс: логи в формате
INFO 2025-07-22 14:33:12,987 [thread-1] com.example.Class - Doing something
— это как искать иголку в стоге syslog’ов. А когда они ещё и с ротацией без Retention Policy, то удачи…

🔍 Что помогает в таких случаях:

Structured Logging: JSON-формат рулит, особенно когда поверх — ELK или Loki.
Correlation ID: у каждой операции — уникальный ID, без него в микросервисной каше ты слеп.
Уровни логов: DEBUG, INFO, WARN, ERROR — это не просто украшение, а ориентиры.
Контроль verbosity: хочешь логировать всё — логируй в dev, но не тащи это в прод.

🧠 Плохие логи — как плохая карта: вроде дорога есть, но ты всё равно заблудишься.
Делай так, чтобы твою систему можно было "прослушать" без шаманства.

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

Коллеги, поздравляю вас с Днём системного администратора!

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

Как не сойти с ума, если у тебя 50+ сервисов в проде

В какой-то момент любой проект превращается в зоопарк: десятки микросервисов, разные стеки, свои деплой-пайплайны и непонятно, что вообще сейчас где крутится.

Что помогает выжить:

- Единый шаблон для сервисов. Helm-чарты, Terraform-модули, пайплайны — всё должно быть максимально унифицировано. Новая фича? Меняешь в одном месте, обновляешь все.
- Service Catalog. Даже если это просто таблица в Confluence/Notion, где описано: кто владелец сервиса, где код, как деплоится и где алерты.
- Алерты с приоритетами. Не всё, что сломалось, нужно чинить ночью. Разделяйте: что критично (P1), что можно отложить (P3).
- Автоматизация рутины. Никаких ручных деплоев, ручных настроек в проде. Автообновления, автоалерты, автодеплой.

Если при виде нового сервиса ты не чувствуешь паники — значит, система построена правильно.

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

Как понять, что пора переписать свой Ansible playbook?

Все мы знаем, что конфигурация - это живой организм. Когда-то ты писал маленький playbook на пару тасков, а через полгода он превратился в монстра на 500 строк, который страшно трогать. Вот признаки, что пора остановиться и переписать:

1. Copy-paste вместо ролей.
Если в нескольких playbook-ах повторяется один и тот же блок задач - это крик о помощи. Вынеси это в роль.

2. Нет структуры.
Папка playbooks/ превращается в свалку из файлов с именами new.yml, fix2.yml. Пора завести нормальную структуру с ролями и группировкой по окружениям.

3. Много условностей.
Когда в тасках появляются километровые when, это знак, что playbook делает слишком много за раз. Лучше разделить.

4. Сложно тестировать.
Если каждый прогон - это боль и сюрпризы на проде, самое время добавить Molecule и хотя бы минимальные тесты.

5. Никто не хочет трогать.
Если команда боится открывать файл, значит, он уже не решает задачи, а создает их.

Совет: не бойся переписывать. В Ansible, как и в коде, рефакторинг - это норма. Маленькие, модульные роли проще поддерживать, тестировать и читать.

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

Мониторинг — это не только графики

Мы все любим красивые дашборды: CPU, RAM, диск, трафик… Но сколько раз вы смотрели на Grafana, а проблему всё равно приходилось искать вручную?

Вот что реально делает мониторинг полезным:

- Алерты с контекстом. Сообщение “CPU > 90%” бесполезно, если не понятно на каком сервисе, с чем связано и что делать.
- Трассировка. Логи и метрики без распределённого трейса — как карта без маршрута. Jaeger, Tempo и OpenTelemetry — must have.
- SLO, а не SLA. Забудьте про “uptime 99.9%”. Важно понимать, что реально чувствует пользователь, и строить алерты на основе опыта, а не железа.
- Автоматизация реакции. PagerDuty и OpsGenie хорошо, но скрипт, который сам перезапустит упавший сервис, иногда спасает нервы.

Мониторинг — это не про цифры. Это про быстрое понимание: что сломалось, почему и что делать прямо сейчас.

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

💡 Почему devops-ам важно уметь читать чужой Terraform

Многие любят писать свой код IaC с нуля — «я же всё делаю правильно». Но реальность другая: половину времени DevOps проводит, разбираясь в чужих модулях, которые писали люди с разным опытом, стилем и, иногда, без особой любви к документации.

👉 Что важно при чтении чужого Terraform:

1. Понять архитектуру целиком
Не лезь сразу в main.tf. Сначала посмотри, как устроены модули, переменные (variables.tf) и выходные значения (outputs.tf). Это даст картину, что и куда деплоится.

2. Следить за провайдерами
Версии провайдеров часто ломают совместимость. Если ты видишь ~> 3.0, проверь changelog — иначе можно «внезапно» словить падение пайплайна.

3. Где переменные и секреты
Иногда секреты лежат в terraform.tfvars или вообще в репозитории (да, это ужасно, но встречается). Убедись, что конфиденциальное вынесено в Vault или хотя бы в CI/CD переменные.

4. Понять логику окружений
Terraform любят разбивать на env/prod, env/stage. Но бывает, что переменные переопределяются через -var-file в пайплайне. Если пропустишь этот момент, в прод может уехать конфиг от стейджа.

🛠 Мастерство DevOps — не только писать, но и быстро разбирать чужие хаотичные конфиги, чтобы не потратить на это неделю.


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

🛠 DevOps-лайфхак: как не потерять вечер на docker pull

Если у вас на сервере при каждом деплое идёт медленный docker pull, а сеть вроде нормальная — проблема может быть не в интернет-канале, а в layer cache.

🔍 Почему так бывает

- Docker Registry (особенно приватный) иногда не поддерживает эффективные Range-запросы. Тогда даже небольшой слой тянется целиком.
- Если образы лежат в разных регионах, latency сильно бьёт по скорости загрузки.
- Частая ошибка — переупаковка слоёв при сборке, из-за чего кэш на нодах не используется.

⚡ Что можно сделать

1. Локальный кэш-реестр

- Запускаем маленький registry:2 рядом с нодами.
- Настраиваем Docker daemon через registry-mirrors.
- При деплое тянем образы сначала из локального кэша.

2. Слои без изменений — без перекачки

- Следите за порядком инструкций в Dockerfile:

     RUN apt-get update && apt-get install -y deps
     COPY . .
     

Так базовые слои останутся закэшированы.

3. Предзагрузка образов

- В k8s можно использовать imagePullPolicy: IfNotPresent.
- Для больших апдейтов — cronjob, который тянет образы на все ноды заранее.

💡 Итог: пару простых правок — и вместо 5 минут на деплой у вас будет 20 секунд.

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

🚦Проблемы с readinessProbe в Kubernetes

Часто бывает так: деплой прошёл, pod поднялся, но сервис не отвечает. Смотрим kubectl get pods - статус Running. Но трафик всё равно не идёт. Почему?

👉 Ответ - неправильно настроенный readinessProbe.
Pod может быть «живым» (liveness ок), но ещё не готов принимать трафик. Например, приложение стартует 30 секунд, а проба выставлена на 5 - kube-proxy считает pod готовым слишком рано.

🔧 Что делать:

- Настраивайте initialDelaySeconds под реальное время старта.
- Проверяйте, что endpoint для probe быстрый и стабильный (не делайте запросы в БД).
- Используйте timeoutSeconds и failureThreshold, чтобы учесть сетевые лаги.
- Логи pod’а и kubectl describe pod — лучшие друзья для диагностики.

📊 Хорошая практика — сначала запускать приложение без probe, замерять время старта, а потом добавлять проверки с запасом.


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

⚡️ Чтение чужого Terraform - кода: боль и радость DevOps

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

Что обычно встречается:

- 100500 переменных в variables.tf, половина из которых нигде не используется.
- "Универсальный" модуль: и под AWS, и под GCP, и под Azure - но работает только в одном.
- Output-хаос: чтобы понять, откуда берётся IP, нужно пройти 5 вложенных модулей.
- Нет документации — комментарии? README? Не, не слышали.

👉 Как выжить:

1. Начни с terraform graph | dot -Tpng > graph.png — визуализация сильно помогает понять связи.
2. Используй terraform console — можно проверить выражения прямо на лету.
3. Включи TF_LOG=DEBUG при планировании — увидишь, что реально под капотом.
4. И не стесняйся переписать модуль под себя — часто это быстрее, чем поддерживать чужую магию.

💡 Совет: заведите внутренний гайд по стилю Terraform (структура папок, нейминг, обязательный README). Это спасает нервы всей команды.

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

🚀 Kubernetes: зачем вообще нужны операторы?

Обычный Deployment или StatefulSet хорошо справляется с запуском подов. Но вот что делать, если у тебя есть сложная система - например, база данных с репликацией, кластер Kafka или Redis с шардингом? Просто манифестов будет мало.

Тут приходят Kubernetes Operators.
Оператор - это контроллер + CRD (Custom Resource Definition), который понимает, как управлять конкретным приложением:

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

👉 По сути, оператор превращает знания SRE/админа в код, который работает прямо внутри кластера.

Примеры:

- Prometheus Operator - автоматом деплоит Prometheus, Alertmanager, ServiceMonitor.
- Postgres Operator - умеет поднимать кластера PostgreSQL с репликацией и бэкапами.
- Cert-Manager - автоматически выдает TLS-сертификаты.

🔑 В итоге операторы позволяют управлять сложными системами так же просто, как подами. Главное - не городить «свой велосипед», а искать готовые CRD, которые уже сделали другие.

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

🇷🇺 100% российская разработка

INFRAX — платформа all-in-one для управления ИТ-инфраструктурой:

✅ Мониторинг инфраструктуры (ITOM)
✅ Удаленный доступ для сотрудников и привилегированных пользователей
✅ Обработка заявок пользователей (ServiceDesk)
✅ База знаний с разграничением доступа к категориям (публичные и закрытые)
✅ Автоматизация (скрипты и планировщик)
✅ Контроль привилегированных пользователей. Видеозапись сессий RDP/SSH/VNC. (PAM)
✅ Управление доступами. Доступ ко всем корпоративным сервисам через одну учетку (IAM)

БЕСПЛАТНО до 100 пользователей! 🎁

👉 Попробовать INFRAX

Реклама. ООО «АУДИТ-ТЕЛЕКОМ», ОГРН 1167746696776, erid: 2Vtzqv8Ag74

🔥 CI/CD пайплайны: боль или спасение?

Любой DevOps рано или поздно сталкивается с тем, что пайплайн превращается в монстра: шаги на 2000 строк, десятки if-ов, и полдня на разбор «почему не задеплоилось».

Но по сути CI/CD - это не только «запустить тесты и выкатить в прод», а целая философия:

🔹 CI (Continuous Integration)

- каждое изменение мержится быстро и проверяется автоматически;
- цель - держать main-ветку в «рабочем» состоянии всегда;
- меньше конфликтов и сюрпризов при релизах.

🔹 CD (Continuous Delivery/Deployment)

- всё, что прошло CI, можно выкатывать хоть в прод;
- ручная кнопка или автодеплой — зависит от зрелости команды;
- уменьшает время «от коммита до продакшна».

⚡️ Где ломается магия?

- Если пайплайны начинают жить своей жизнью, а разработчики боятся их трогать.
- Если тесты гоняются по часу, и команда снова жмёт «на выходных зарелизим».
- Если нет нормальной стратегии отката.

💡 Совет: держи пайплайн простым, модульным и прозрачным. Лучше несколько коротких пайплайнов, чем один гигант.

А у тебя пайплайн больше похож на швейцарские часы или на «дженкинс на костылях»? 😅

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

🔥 GitOps - next level для DevOps

Раньше деплой выглядел так: написали Helm-чарт → закинули kubectl apply → надеемся, что всё взлетит. Но у такого подхода куча минусов: ручные действия, нет прозрачного аудита, легко ошибиться.

🛠 Решение - GitOps.

👉 Суть: всё, что крутится в кластере, описано в Git.

- Изменения вносим через Pull Request.
- CI прогоняет проверки.
- Спец-оператор (ArgoCD или Flux) синхронизирует кластер с Git-репозиторием.

📌 Преимущества:

- Истина всегда в Git → легко откатиться.
- Аудит и история изменений из коробки.
- Меньше доступа к самому кластеру → безопаснее.
- Автоматическая самовосстановляемость: если кто-то руками изменит деплой, GitOps всё вернёт.

💡 По сути, Git становится "центральным управлением инфраструктуры".
Если раньше у вас был ssh и kubectl, то теперь всё решает git push.

❓А у вас уже есть GitOps в проде или пока классические пайплайны?

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

🛠️ GitHub Actions: секреты и подводные камни

GitHub Actions сегодня используют все - от пет-проектов до продакшн пайплайнов. Но даже у опытных инженеров часто встречаются ошибки при работе с секретами.

❌ Типичные ошибки:

- Хранение токенов в коде или .env файлах, которые случайно попадают в репозиторий.
- Вывод секретов в логи (например, через echo). GitHub заменяет их на ***, но иногда этого недостаточно.
- Использование одного общего токена для разных окружений (dev, staging, prod).

✅ Лучшие практики:

1. Secrets vs. Environments
Используй Environments с разными наборами секретов для разных стадий. Например: STAGING_DB_PASS и PROD_DB_PASS.

2. OIDC вместо токенов
GitHub поддерживает OIDC Federation. Это значит, что пайплайн может получать временные креды от AWS, GCP или Azure без хранения ключей.

3. Проверяй разрешения по умолчанию
В permissions: указывай минимально необходимые. Например:

   permissions:
     contents: read
     id-token: write
   

4. Secrets scanning
Включи secret scanning и push protection, чтобы случайно не залить ключи.

💡 Маленький трюк:
Если нужно временно отладить пайплайн с секретом - лучше использовать ::add-mask:: в логах, чем echo.

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

🔥 GitHub Actions и секреты: как не словить утечку

Многие думают, что положить секреты в Secrets в настройках репозитория - это всё, можно расслабиться. Но есть нюансы:

1️⃣ Secrets = env vars
В рантайме GitHub Actions подставляет секреты как переменные окружения. Их легко случайно вывести в лог, если бездумно делать echo $SECRET_KEY. Логи сохраняются, а доступ к ним могут получить коллеги с правами на Actions.

2️⃣ Маскирование работает не всегда
GitHub пытается автоматически маскировать значения секретов в логах. Но если у тебя секрет - это, например, base64 строка или JSON, маскировка может сработать криво. Тут уже сам контролируешь вывод.

3️⃣ Не храни много секретов в репозитории
Лучше использовать GitHub OIDC (OpenID Connect) и получать временные креды от AWS, GCP или Azure прямо в рантайме. Так ты избежишь постоянных ключей в Secrets.

4️⃣ Используй environments
В GitHub есть Environments с отдельными секретами и правилами доступа. Можно разграничить staging/prod, включить approvals перед деплоем. Это must-have.

5️⃣ Проверяй permissions у Actions
По умолчанию GitHub даёт job полный доступ к GITHUB_TOKEN. Иногда достаточно permissions: read-only, а не write-all. Меньше прав → меньше дыр.

💡Для управления секретами в масштабах компании лучше интегрировать GitHub с HashiCorp Vault, Doppler или AWS Secrets Manager. Тогда GitHub Secrets будет только точкой входа, а не хранилищем всего подряд.

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

GitHub Actions: секреты без боли и утечек

Вот концентрат практик, чтобы ваши токены и ключи не вываливались в логи и чужие форки.

🔐 Где хранить

- Secrets: шифруются, доступны через secrets.*. Уровни: Repository, Environment, Organization, Dependabot.
- Variables (vars): не для чувствительного — просто конфиг.
- Environment + reviewers: ставьте для production - без апрува шаги с секретами не стартуют.

🪪 GITHUB_TOKEN и права
Явно задавайте права минимально необходимые:

permissions:
  contents: read
  id-token: write   # нужно для OIDC

Не полагайтесь на дефолты. Чем меньше - тем лучше.

🔄 OIDC вместо статических ключей
К облакам — без долгоживущих секретов:

jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: AWS OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: eu-central-1
      - run: aws sts get-caller-identity

Аналогично есть для GCP/Azure. Итог: нулевые постоянные ключи, только краткоживущие токены.

🧪 Секреты и PR из форков
По умолчанию секреты недоступны для pull_request из форков - и это хорошо.
Если нужно выполнить деплой/проверку после мерджа - делайте через workflow_run или отделяйте джобы:

if: github.event.pull_request.head.repo.fork == false

Избегайте pull_request_target для запуска непроверенного кода с секретами.

🧯 Не печатайте секреты

- Никогда не echo $SECRET.
- Прокидывайте через stdin:

echo "${{ secrets.NPM_TOKEN }}" | npm login --registry=https://registry.npmjs.org --scope=@org --auth-type=legacy --password-stdin

- Для временных значений добавляйте маску:

echo "::add-mask::${TOKEN_FROM_API}"

- Не включайте set -x/trace в шагах, где работают секреты.

🗝️ Секрет как файл

- name: Write SSH key
  run: |
    install -m 700 -d ~/.ssh
    printf '%s' "${{ secrets.DEPLOY_KEY }}" > ~/.ssh/id_ed25519
    chmod 600 ~/.ssh/id_ed25519

Если это PEM/JSON — храните в секрете как base64 и декодируйте в рантайме.

🧰 Склады секретов

- Централизуйте в Vault/SM (HashiCorp Vault, AWS/GCP/Azure Secrets Manager) + OIDC.
- В GitHub — используйте Org secrets и environment secrets для переиспользования.

🧹 Ротация и доставка

- Автоматизируйте через CLI:

gh secret set NPM_TOKEN --repo owner/repo --body "$TOKEN"
gh secret set PROD_DB_URL --env production --repo owner/repo --body "$URL"

- Добавьте регулярную ротацию токенов и ключей (календарь + скрипт/бот).

🛡️ Secret scanning
Включите Secret scanning и Push Protection для приватных реп - ловит утечки ещё до пуша/мерджа.

🧩 Шаблон безопасного деплоя

name: deploy
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    environment: production   # защита + секреты проды
    permissions:
      contents: read
      id-token: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login registry
        run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
      - name: Cloud auth (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: eu-central-1
      - name: Deploy
        run: ./scripts/deploy.sh

Чек-лист на дорожку: минимум прав, OIDC > статические ключи, секреты в environment, никакого echo, форки изолируем, сканирование включаем, ротацию автоматизируем.

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

🚀 Как я однажды сломал прод одним kubectl apply

Сидишь себе спокойно, делаешь хотфикс, вроде всё готово. Думаю: "ну ща быстренько закатим" → kubectl apply -f deployment.yaml.
И тут - бах! Вылетает вся продовая нагрузка.

Почему?
А потому что в deployment.yaml был replicas: 1, а в кластере реально крутилось 12 подов. 😅
Kubernetes честно решил: "Ну раз надо 1, значит уберём остальные".
И убрал.

⚡️Вывод:

- Никогда не храните в гите "локальные" конфиги без проверки.
- Сравнивайте diff перед применением (kubectl diff -f ...).
- Лучше юзать GitOps (ArgoCD / Flux), чтобы руками не катать.

Теперь у нас правило: в прод руками через kubectl apply - нельзя. Только через пайплайны.


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