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

MTC Engineer Hack — хакатон на стыке инженерии и ИТ от МТС. Реши технический кейс онлайн и получи приглашение на финал в Москве, где сможешь познакомиться с экспертами МТС. Призовой фонд — 500 000 рублей. 🗓 Регистрация: https://cnrlink.com/mtsengineerhacklibsre Приглашаем студентов и молодых инженеров в областях сетевых технологий, DevOps, аппаратной разработки, радиоинженерии. Ты сможешь: 🔺 Решить кейсы, основанные на реальной работе инженеров МТС: от проектирования до оптимизации сетей. 🔺 Показать экспертам свои решения и получить обратную связь. 🔺 Попрактиковаться на задачах, которые позволят почувствовать себя частью технологической команды МТС. 🔺 Принять участие в финале в Москве. Билеты и проживание оплатят организаторы. C 3 по 5 октября пройдёт онлайн-этап: участники готовят кейс по своему профилю. 11 октября — финал, где эксперты компании помогут разобраться в деталях и дадут советы по доработке решений, а ты сможешь выиграть мерч и принять участие в Tech Corner с Arduino и роботами. Регистрация до 1 октября на Codenrock: https://cnrlink.com/mtsengineerhacklibsre

🚀 Как DevOps-инженеры мы часто увязаем в задачах автоматизации и забываем про «гигиену» инфраструктуры. А ведь простые проверки могут спасать от неприятных ночных алертов: 🔎 Периодически проверяй лимиты и квоты в облаке. Упёрся в лимит IP-адресов или дисков - и вот у тебя прод простаивает. 🧹 Смотри на orphan-ресурсы — старые volume, неиспользуемые load balancer’ы, забытые секреты в Vault. Всё это стоит денег и иногда может мешать. 🕓 Планируй регулярный audit logs review. Лишние сервисные аккаунты или подозрительная активность легко пропустить, если смотреть только на дашборды. 🛡 Не хардкодь секреты. Даже тестовые ключи лучше сразу класть в менеджер секретов, чтобы не ловить «утечку века» из git. Внедрив маленькие привычки, можно сократить 80% неожиданных проблем и освободить время на то, что реально интересно. Подпишись 👉@devopslib

💡 Многие девопсы недооценивают силу readiness и liveness проб в Kubernetes. Проблема: без них kubelet считает под «живым», даже если приложение давно висит и не отвечает. В итоге у тебя в кластере «зелёные» поды, а пользователи шлют мат в поддержку. 👉 Разница: LivenessProbe — проверяет, живо ли приложение. Если не отвечает - pod рестартует. ReadinessProbe — проверяет, готов ли сервис обрабатывать трафик. Если нет - трафик не идёт, но pod не перезапускается. ⚙️ Частые ошибки: - Делают одинаковый endpoint для обоих проб. В итоге под либо вечно рестартует, либо никогда не попадает в сервис. - Ставят слишком жёсткие таймауты - приложение ещё грузит кэш, а kubelet уже думает «оно мёртвое». - Забывают про startupProbe - и получают вечный рестарт на тяжёлых приложениях (например, Java с долгим стартом). ✅ Хорошая практика: - liveness → простой healthcheck (например, GET /ping). - readiness → что-то посложнее (например, проверка подключения к БД). - startupProbe → обязательно для всего, что стартует дольше пары секунд. Kubernetes умеет заботиться о твоих подах, но только если ты правильно объяснишь ему, что значит «жив» и «готов». Подпишись 👉@devopslib

🔥 kubectl rollout restart - лучший друг девопса Когда нужно быстро перезапустить деплоймент в Kubernetes, многие лезут редактировать манифест или руками удаляют поды. Но есть куда более элегантный способ:

kubectl rollout restart deployment my-app

Что делает эта команда: - Не трогает сам манифест. - Генерирует новый replicaSet с теми же образами. - Аккуратно перезапускает поды по rolling update. ⚡️ Плюсы: - Удобно для обновления конфигов (например, ConfigMap или Secret), если они примонтированы в поды. - Можно применить массово:

kubectl rollout restart deployment -n my-namespace

- Работает и для daemonset / statefulset. 💡 Если хочешь проверить статус перезапуска:

kubectl rollout status deployment my-app

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

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

🔥 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

🔥 Открытый урок «Архитектура развертывания GitLab: от тестовой среды до продакшна». 🗓 10 сентября в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «CI/CD на основе GitLab». 🎯 На вебинаре разберем: ✔️ Как выбрать способ развертывания GitLab: Omnibus, Docker, Kubernetes ✔️ Рекомендации по архитектуре для разных масштабов: от одиночного сервера до распределённой инсталляции ✔️ Сравнение плюсов и минусов подходов: простота, отказоустойчивость, масштабируемость ✔️ Типичные проблемы при развёртывании и как их избежать 👥 Кому будет интересно: - Начинающим DevOps-инженерам — вы получите базовое понимание архитектуры GitLab и научитесь разворачивать его под разные задачи - DevOps-практикам, которые уже используют GitLab и хотят повысить стабильность и отказоустойчивость - Инженерам по внедрению CI/CD, которым важно понять, как масштабировать GitLab в корпоративной среде 🎯 Что вы получите: - Понимание, как развернуть GitLab оптимально под свои задачи - Понимание, как правильно выбрать среду (Docker vs Kubernetes) для развёртывания - Практические советы по стабильности, резервированию и отказоустойчивости GitLab-инсталляций 🔗 Ссылка на регистрацию: https://vk.cc/cPbf0Q Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🛠️ 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

🔥 GitOps - next level для DevOps Раньше деплой выглядел так: написали Helm-чарт → закинули kubectl apply → надеемся, что всё взлетит. Но у такого подхода куча минусов: ручные действия, нет прозрачного аудита, легко ошибиться. 🛠 Решение - GitOps. 👉 Суть: всё, что крутится в кластере, описано в Git. - Изменения вносим через Pull Request. - CI прогоняет проверки. - Спец-оператор (ArgoCD или Flux) синхронизирует кластер с Git-репозиторием. 📌 Преимущества: - Истина всегда в Git → легко откатиться. - Аудит и история изменений из коробки. - Меньше доступа к самому кластеру → безопаснее. - Автоматическая самовосстановляемость: если кто-то руками изменит деплой, GitOps всё вернёт. 💡 По сути, Git становится "центральным управлением инфраструктуры". Если раньше у вас был ssh и kubectl, то теперь всё решает git push. ❓А у вас уже есть GitOps в проде или пока классические пайплайны? Подпишись 👉@devopslib

🔥 CI/CD пайплайны: боль или спасение? Любой DevOps рано или поздно сталкивается с тем, что пайплайн превращается в монстра: шаги на 2000 строк, десятки if-ов, и полдня на разбор «почему не задеплоилось». Но по сути CI/CD - это не только «запустить тесты и выкатить в прод», а целая философия: 🔹 CI (Continuous Integration) - каждое изменение мержится быстро и проверяется автоматически; - цель - держать main-ветку в «рабочем» состоянии всегда; - меньше конфликтов и сюрпризов при релизах. 🔹 CD (Continuous Delivery/Deployment) - всё, что прошло CI, можно выкатывать хоть в прод; - ручная кнопка или автодеплой — зависит от зрелости команды; - уменьшает время «от коммита до продакшна». ⚡️ Где ломается магия? - Если пайплайны начинают жить своей жизнью, а разработчики боятся их трогать. - Если тесты гоняются по часу, и команда снова жмёт «на выходных зарелизим». - Если нет нормальной стратегии отката. 💡 Совет: держи пайплайн простым, модульным и прозрачным. Лучше несколько коротких пайплайнов, чем один гигант. А у тебя пайплайн больше похож на швейцарские часы или на «дженкинс на костылях»? 😅 Подпишись 👉@devopslib

🇷🇺 100% российская разработка INFRAX — платформа all-in-one для управления ИТ-инфраструктурой: ✅ Мониторинг инфраструктуры (ITOM) ✅ Удаленный доступ для сотрудников и привилегированных пользователей ✅ Обработка заявок пользователей (ServiceDesk) ✅ База знаний с разграничением доступа к категориям (публичные и закрытые) ✅ Автоматизация (скрипты и планировщик) ✅ Контроль привилегированных пользователей. Видеозапись сессий RDP/SSH/VNC. (PAM) ✅ Управление доступами. Доступ ко всем корпоративным сервисам через одну учетку (IAM) БЕСПЛАТНО до 100 пользователей! 🎁 👉 Попробовать INFRAX Реклама. ООО «АУДИТ-ТЕЛЕКОМ», ОГРН 1167746696776, erid: 2Vtzqv8Ag74

🚀 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

⚡️ Чтение чужого 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

🔥 Открытый урок «GitLab CI + Ansible: автоматизация инфраструктуры без боли». 🗓 27 августа в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «CI/CD на основе GitLab». 🎯 На вебинаре разберем: ✔️ Как настроить GitLab CI для работы с Ansible ✔️ Организация пайплайна для автоматического запуска Ansible-плейбуков ✔️ Как тестировать и проверять изменения в Ansible до деплоя ✔️ Использование GitLab CI как среды для обучения и отладки Ansible 👥 Кому будет интересно: - DevOps-инженерам, которые осваивают или уже используют GitLab CI и Ansible, и хотят связать их в единый, автоматизированный процесс - Начинающим специалистам, изучающим инфраструктурный код и автоматизацию - Техническим архитекторам, заинтересованным в построении масштабируемых и управляемых CI/CD процессов с Ansible 🎯 Что вы получите: - Практическое понимание интеграции Ansible с GitLab CI - Готовые идеи и примеры для запуска и тестирования Ansible-плейбуков - Уверенность в использовании CI/CD пайплайнов для инфраструктурных задач и конфигурационного менеджмента 🔗 Ссылка на регистрацию: https://vk.cc/cOK1Sl Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🚦Проблемы с 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

🛠 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

💡 Почему 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

Мониторинг — это не только графики Мы все любим красивые дашборды: CPU, RAM, диск, трафик… Но сколько раз вы смотрели на Grafana, а проблему всё равно приходилось искать вручную? Вот что реально делает мониторинг полезным: - Алерты с контекстом. Сообщение “CPU > 90%” бесполезно, если не понятно на каком сервисе, с чем связано и что делать. - Трассировка. Логи и метрики без распределённого трейса — как карта без маршрута. Jaeger, Tempo и OpenTelemetry — must have. - SLO, а не SLA. Забудьте про “uptime 99.9%”. Важно понимать, что реально чувствует пользователь, и строить алерты на основе опыта, а не железа. - Автоматизация реакции. PagerDuty и OpsGenie хорошо, но скрипт, который сам перезапустит упавший сервис, иногда спасает нервы. Мониторинг — это не про цифры. Это про быстрое понимание: что сломалось, почему и что делать прямо сейчас. Подпишись 👉@devopslib