Успех секрета: как доставлять секреты в приложения безопасно и без головной боли
Мы видели много инфраструктур и встречали самые разные способы доставки секретов в приложения, развёрнутые в кластерах Kubernetes. Но ни один из этих способов не был одновременно удобным и по-настоящему безопасным. В статье расскажем про существующие варианты, посмотрим на их плюсы и минусы и поделимся тем, как мы решали задачу доставки секретов в Deckhouse Kubernetes Platform.
https://habr.com/ru/companies/flant/articles/932862/
#devops #девопс
Подпишись 👉@i_DevOps
Мы видели много инфраструктур и встречали самые разные способы доставки секретов в приложения, развёрнутые в кластерах Kubernetes. Но ни один из этих способов не был одновременно удобным и по-настоящему безопасным. В статье расскажем про существующие варианты, посмотрим на их плюсы и минусы и поделимся тем, как мы решали задачу доставки секретов в Deckhouse Kubernetes Platform.
https://habr.com/ru/companies/flant/articles/932862/
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Docker изнутри: исчерпывающее руководство. Механизмы контейнеризации + примеры, эксперименты и реализация
Docker — не магия, а грамотное применение механизмов Linux. Разбираем инструмент, который пугает своей сложностью не меньше блокчейна. Показываем на пальцах как работают: Namespaces, Cgroups, OverlayFS – основные компоненты любого контейнера, и как стандарт OCI объединяет их в единую экосистему. Об этом и не только в статье.
https://habr.com/ru/articles/935178/
#devops #девопс
Подпишись 👉@i_DevOps
Docker — не магия, а грамотное применение механизмов Linux. Разбираем инструмент, который пугает своей сложностью не меньше блокчейна. Показываем на пальцах как работают: Namespaces, Cgroups, OverlayFS – основные компоненты любого контейнера, и как стандарт OCI объединяет их в единую экосистему. Об этом и не только в статье.
https://habr.com/ru/articles/935178/
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Как динамически рассчитывать CPU для контейнеров в Kubernetes
Включена возможность динамического изменения CPU для контейнеров в Kubernetes с помощью фичи
Раньше подбор CPU был трудоемким: если установить слишком много — ресурс тратится впустую, слишком мало — приложение тормозит. Давайте рассмотрим подходы к динамическому изменению CPU.
Стратегия 1: всегда использовать 80% CPU
Если приложение загружено на 50%, увеличиваем до 80% — оставляем запас в 20 % для безопасности.
Работает отлично при уменьшении, но при увеличении — вопрос: если используем 100 %, стоит ли удвоить CPU или немного прибавить? Ответ неизвестен.
Стратегия 2: всегда использовать 80%, плюс экспоненциальный рост
Как и в стратегии 1 при уменьшении. При увеличении (при нагрузке между 80 и 100 %) используется формула:
Экспоненциальное увеличение: сильно растем, если нагрузка 100 %, и умеренно — если 90 %. Эту стратегию легко применять: она используется в инструменте Kondense для подбора ресурсов в Kubernetes.
Стратегия 3: целевое использование 100% с учетом CPU-pressure
При уменьшении — устанавливаем на 100%, чтобы не терять ресурсы. При увеличении — смотрим на CPU pressure в микросекундах (время, которое контейнер не мог получить CPU). Чем выше давление, тем сильнее нужно увеличить CPU.
Теоретически это оптимально. Но на практике не всегда работает: порой CPU pressure высок, но увеличение CPU не помогает — зависит от характера приложения. Потребуется доработка формулы под конкретные кейсы.
Итог:
Динамическое изменение CPU — значительный шаг для Kubernetes. В будущем это позволит экономить ресурсы и развязывать руки администраторам. Уже сейчас стоит ознакомиться с инструментом Kondense, если планируете автоматизацию подбора ресурсов.
https://medium.com/@mathieuces/how-to-calculate-cpu-for-containers-in-k8s-dynamically-47a89e3886eb
#devops #девопс
Подпишись 👉@i_DevOps
Включена возможность динамического изменения CPU для контейнеров в Kubernetes с помощью фичи
InPlacePodVerticalScaling.Раньше подбор CPU был трудоемким: если установить слишком много — ресурс тратится впустую, слишком мало — приложение тормозит. Давайте рассмотрим подходы к динамическому изменению CPU.
Стратегия 1: всегда использовать 80% CPU
Если приложение загружено на 50%, увеличиваем до 80% — оставляем запас в 20 % для безопасности.
Работает отлично при уменьшении, но при увеличении — вопрос: если используем 100 %, стоит ли удвоить CPU или немного прибавить? Ответ неизвестен.
Стратегия 2: всегда использовать 80%, плюс экспоненциальный рост
Как и в стратегии 1 при уменьшении. При увеличении (при нагрузке между 80 и 100 %) используется формула:
new_cpu = average_cpu / 0.8 + (average_cpu / 0.8 * coeff)²
Экспоненциальное увеличение: сильно растем, если нагрузка 100 %, и умеренно — если 90 %. Эту стратегию легко применять: она используется в инструменте Kondense для подбора ресурсов в Kubernetes.
Стратегия 3: целевое использование 100% с учетом CPU-pressure
При уменьшении — устанавливаем на 100%, чтобы не терять ресурсы. При увеличении — смотрим на CPU pressure в микросекундах (время, которое контейнер не мог получить CPU). Чем выше давление, тем сильнее нужно увеличить CPU.
Теоретически это оптимально. Но на практике не всегда работает: порой CPU pressure высок, но увеличение CPU не помогает — зависит от характера приложения. Потребуется доработка формулы под конкретные кейсы.
Итог:
Динамическое изменение CPU — значительный шаг для Kubernetes. В будущем это позволит экономить ресурсы и развязывать руки администраторам. Уже сейчас стоит ознакомиться с инструментом Kondense, если планируете автоматизацию подбора ресурсов.
https://medium.com/@mathieuces/how-to-calculate-cpu-for-containers-in-k8s-dynamically-47a89e3886eb
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Winbox in docker
Запуск Mikrotik Winbox в контейнере Docker для упрощенного и портативного управления маршрутизатором
Используя KasmVNC, этот докер запускает Winbox с помощью Wine и делает его доступным в любом браузере.
Docker
https://github.com/obeone/winbox-docker
#devops #девопс
Подпишись 👉@i_DevOps
Запуск Mikrotik Winbox в контейнере Docker для упрощенного и портативного управления маршрутизатором
Используя KasmVNC, этот докер запускает Winbox с помощью Wine и делает его доступным в любом браузере.
Docker
docker run -d --shm-size=512m -p 6901:6901 -e VNC_PW=password -v winbox_wine:/home/kasm-user/.wine ghcr.io/obeone/winbox:latesthttps://github.com/obeone/winbox-docker
#devops #девопс
Подпишись 👉@i_DevOps
👍5
GitButler
GitButler - это git-клиент, позволяющий работать с несколькими ветками одновременно. Он позволяет быстро организовать изменения файлов в отдельные ветки, сохраняя их в рабочей директории. Затем вы можете отправлять ветки по отдельности на ваше удалённое хранилище или напрямую создавать запросы на получение.
В двух словах, это более гибкая версия git add -p и git rebase -i, позволяющая эффективно работать в нескольких ветках.
https://github.com/gitbutlerapp/gitbutler
#devops #девопс
Подпишись 👉@i_DevOps
GitButler - это git-клиент, позволяющий работать с несколькими ветками одновременно. Он позволяет быстро организовать изменения файлов в отдельные ветки, сохраняя их в рабочей директории. Затем вы можете отправлять ветки по отдельности на ваше удалённое хранилище или напрямую создавать запросы на получение.
В двух словах, это более гибкая версия git add -p и git rebase -i, позволяющая эффективно работать в нескольких ветках.
https://github.com/gitbutlerapp/gitbutler
#devops #девопс
Подпишись 👉@i_DevOps
👍5🔥1
В Ansible роли есть директории file и templates. Что они содержат и чем отличаются?
files — содержит файлы, которые будут скопированы на настраиваемые хосты; так же — может содержать скрипты, которые позже будут запускаться на хостах.
templates — содержит шаблоны файлов с переменными.
#devops #девопс
Подпишись 👉@i_DevOps
files — содержит файлы, которые будут скопированы на настраиваемые хосты; так же — может содержать скрипты, которые позже будут запускаться на хостах.
templates — содержит шаблоны файлов с переменными.
#devops #девопс
Подпишись 👉@i_DevOps
👍6
🚀 GitHub Actions + Terraform: автоматизация деплоя с ревью плана изменений
Terraform стал стандартом для управления инфраструктурой как кодом (IaC). Но просто запускать
В статье показано, как интегрировать Terraform с GitHub Actions так, чтобы каждый pull request автоматически запускал
Таким образом:
- при открытии PR → генерируется план, прикрепляется к обсуждению;
- после ревью и мержа → автоматически выполняется
Это позволяет:
✅ повысить прозрачность изменений в инфраструктуре
✅ избежать ошибок при деплое
✅ упростить командную работу с IaC
Отличный пример того, как CI/CD можно использовать не только для приложений, но и для инфраструктуры.
https://itnext.io/github-actions-terraform-deployments-with-a-review-of-planned-changes-30143358bb5c
#devops #девопс
Подпишись 👉@i_DevOps
Terraform стал стандартом для управления инфраструктурой как кодом (IaC). Но просто запускать
terraform apply в CI/CD — не лучший вариант. Важно видеть план изменений до деплоя, чтобы избежать неожиданных последствий.В статье показано, как интегрировать Terraform с GitHub Actions так, чтобы каждый pull request автоматически запускал
terraform plan. Результаты работы добавляются прямо в PR, где команда может просмотреть и обсудить изменения до их применения.Таким образом:
- при открытии PR → генерируется план, прикрепляется к обсуждению;
- после ревью и мержа → автоматически выполняется
terraform apply.Это позволяет:
✅ повысить прозрачность изменений в инфраструктуре
✅ избежать ошибок при деплое
✅ упростить командную работу с IaC
Отличный пример того, как CI/CD можно использовать не только для приложений, но и для инфраструктуры.
https://itnext.io/github-actions-terraform-deployments-with-a-review-of-planned-changes-30143358bb5c
#devops #девопс
Подпишись 👉@i_DevOps
👍7❤1😱1
SSO через Keycloak для инфраструктурных сервисов: часть 1, теория
Если вы хоть раз настраивали доступ к Grafana, Argo CD, Vault или Prometheus и сталкивались с аутентификацией «на костылях», значит, тоже задавались вопросом: почему бы не сделать это один раз и правильно — через SSO?
Эта первая часть разбора мастер-класса с DevOpsConf 2025 от Алексея Цыкунова, CTO Hilbert Team.
https://habr.com/ru/companies/oleg-bunin/articles/936338/
#devops #девопс
Подпишись 👉@i_DevOps
Если вы хоть раз настраивали доступ к Grafana, Argo CD, Vault или Prometheus и сталкивались с аутентификацией «на костылях», значит, тоже задавались вопросом: почему бы не сделать это один раз и правильно — через SSO?
Эта первая часть разбора мастер-класса с DevOpsConf 2025 от Алексея Цыкунова, CTO Hilbert Team.
https://habr.com/ru/companies/oleg-bunin/articles/936338/
#devops #девопс
Подпишись 👉@i_DevOps
👍12❤4
SSO через Keycloak для инфраструктурных сервисов: часть 2, практика
В первой части мы разобрали, как устроен Keycloak, какие у него сущности и зачем вообще нужен SSO в DevOps-инфраструктуре. Теперь — к делу. Во второй части переходим от теории к практике. Разворачиваем Keycloak в Kubernetes, настраиваем Terraform-провайдер, подключаем к нему Grafana, Argo CD и другие сервисы. Разбираемся, как выглядят реальные конфигурации клиентов, scopes и mappings, чтобы SSO действительно работал — с нужными токенами, ролями и группами.
https://habr.com/ru/companies/oleg-bunin/articles/936866/
#devops #девопс
Подпишись 👉@i_DevOps
В первой части мы разобрали, как устроен Keycloak, какие у него сущности и зачем вообще нужен SSO в DevOps-инфраструктуре. Теперь — к делу. Во второй части переходим от теории к практике. Разворачиваем Keycloak в Kubernetes, настраиваем Terraform-провайдер, подключаем к нему Grafana, Argo CD и другие сервисы. Разбираемся, как выглядят реальные конфигурации клиентов, scopes и mappings, чтобы SSO действительно работал — с нужными токенами, ролями и группами.
https://habr.com/ru/companies/oleg-bunin/articles/936866/
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Что такое пейджинг по требованию?
Пейджинг по требованию — это метод управления памятью, при котором страницы загружаются в физическую память только при доступе к ним процесса. Он оптимизирует использование памяти, загружая страницы по требованию, что снижает задержку запуска и накладные расходы на пространство. Однако он вносит некоторую задержку при первом доступе к страницам. В целом, это экономически эффективный подход к управлению ресурсами памяти в операционных системах.
#devops #девопс
Подпишись 👉@i_DevOps
Пейджинг по требованию — это метод управления памятью, при котором страницы загружаются в физическую память только при доступе к ним процесса. Он оптимизирует использование памяти, загружая страницы по требованию, что снижает задержку запуска и накладные расходы на пространство. Однако он вносит некоторую задержку при первом доступе к страницам. В целом, это экономически эффективный подход к управлению ресурсами памяти в операционных системах.
#devops #девопс
Подпишись 👉@i_DevOps
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
ContainerSSH
SSH-сервер, который запускает контейнеры в Kubernetes и Docker
https://github.com/ContainerSSH/ContainerSSH
#devops #девопс
Подпишись 👉@i_DevOps
SSH-сервер, который запускает контейнеры в Kubernetes и Docker
https://github.com/ContainerSSH/ContainerSSH
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Основы компьютерной безопасности
Лекция 1. Основы криптографии
Практика 1. Криптография и её прикладные инструменты
Лекция 2. Основы сетей
Лекция 3. Основы веба
Практика 2. Основы веба
Лекция 4. Атаки на веб
Лекция 5. Безопасность беспроводных сетей Wi-Fi + воркшоп / Wireless security
Лекция 6. Прикладная криптография для самых маленьких. Менеджеры паролей, HTTPS, SSH
источник
#devops #девопс
Подпишись 👉@i_DevOps
Лекция 1. Основы криптографии
Практика 1. Криптография и её прикладные инструменты
Лекция 2. Основы сетей
Лекция 3. Основы веба
Практика 2. Основы веба
Лекция 4. Атаки на веб
Лекция 5. Безопасность беспроводных сетей Wi-Fi + воркшоп / Wireless security
Лекция 6. Прикладная криптография для самых маленьких. Менеджеры паролей, HTTPS, SSH
источник
#devops #девопс
Подпишись 👉@i_DevOps
👍6