В чем разница stateful и stateless?
Stateful-приложение сохраняет данные внутри себя во время работы, например, сессии пользователей на сервере. Ответ на запрос пользователя зависит от состояния сессии. Такие приложения сложнее масштабировать горизонтально, так как для развертывания нескольких экземпляров необходимо переносить состояния на новые машины и синхронизировать их.
Stateless-приложения не хранят состояние и гарантируют, что каждый запрос обрабатывается независимо от других. Они легко масштабируются горизонтально и упрощают автоматизированное тестирование, поскольку не требуется воспроизводить состояние приложения.
#devops #девопс
Подпишись 👉@i_DevOps
Stateful-приложение сохраняет данные внутри себя во время работы, например, сессии пользователей на сервере. Ответ на запрос пользователя зависит от состояния сессии. Такие приложения сложнее масштабировать горизонтально, так как для развертывания нескольких экземпляров необходимо переносить состояния на новые машины и синхронизировать их.
Stateless-приложения не хранят состояние и гарантируют, что каждый запрос обрабатывается независимо от других. Они легко масштабируются горизонтально и упрощают автоматизированное тестирование, поскольку не требуется воспроизводить состояние приложения.
#devops #девопс
Подпишись 👉@i_DevOps
👍9
Тренировки по DevOps. Часть 2
Лекция 7: Сети. Часть 2. Коробки и коты
Лекция 8: Как запустить «облако»
Разбор домашнего задания: Linux инструменты командной строки. Итоговый проект
Разбор домашнего задания 6: Базы данных
Разбор домашнего задания 7: Сети. Часть 2. Коробки и коты
Разбор домашнего задания 2: Облако. Кто виноват и что делать?
источник
#devops #девопс
Подпишись 👉@i_DevOps
Лекция 7: Сети. Часть 2. Коробки и коты
Лекция 8: Как запустить «облако»
Разбор домашнего задания: Linux инструменты командной строки. Итоговый проект
Разбор домашнего задания 6: Базы данных
Разбор домашнего задания 7: Сети. Часть 2. Коробки и коты
Разбор домашнего задания 2: Облако. Кто виноват и что делать?
источник
#devops #девопс
Подпишись 👉@i_DevOps
👍6
Wireguard-ui
Фичи
⚫️ Дружественный интерфейс
⚫️ Аутентификация
⚫️ Управление дополнительной информацией о клиентах (имя, email и т.д.)
⚫️ Получение конфигурации клиента с помощью QR-кода / файла / email / Telegram
https://github.com/ngoduykhanh/wireguard-ui
#devops #девопс
Подпишись 👉@i_DevOps
Фичи
https://github.com/ngoduykhanh/wireguard-ui
#devops #девопс
Подпишись 👉@i_DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
etcd в Kubernetes: разбираемся с задержками
Эта статья будет полезна DevOps-инженерам, SRE-специалистам и всем, кто работает с Kubernetes и хочет глубже понять его внутренние механизмы. Если вы настраиваете, масштабируете или устраняете неполадки в кластере K8s, важно разобраться в etcd — распределенном key-value-хранилище, которое лежит в основе отказоустойчивости Kubernetes.
Надо отметить, что etcd обеспечивает консистентность и надежное хранение критически важных данных: состояния нод, конфигураций, секретов и другой информации кластера. Без него Kubernetes не мог бы гарантировать высокую доступность и согласованность данных.
В этой статье мы разберем распространенные мифы о etcd, а также дадим практические рекомендации по его настройке и эксплуатации.
https://habr.com/ru/companies/chislitellab/articles/934526/
original https://www.redhat.com/en/blog/a-guide-to-etcd
#devops #девопс
Подпишись 👉@i_DevOps
Эта статья будет полезна DevOps-инженерам, SRE-специалистам и всем, кто работает с Kubernetes и хочет глубже понять его внутренние механизмы. Если вы настраиваете, масштабируете или устраняете неполадки в кластере K8s, важно разобраться в etcd — распределенном key-value-хранилище, которое лежит в основе отказоустойчивости Kubernetes.
Надо отметить, что etcd обеспечивает консистентность и надежное хранение критически важных данных: состояния нод, конфигураций, секретов и другой информации кластера. Без него Kubernetes не мог бы гарантировать высокую доступность и согласованность данных.
В этой статье мы разберем распространенные мифы о etcd, а также дадим практические рекомендации по его настройке и эксплуатации.
https://habr.com/ru/companies/chislitellab/articles/934526/
original https://www.redhat.com/en/blog/a-guide-to-etcd
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Успех секрета: как доставлять секреты в приложения безопасно и без головной боли
Мы видели много инфраструктур и встречали самые разные способы доставки секретов в приложения, развёрнутые в кластерах 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