🚀 GitOps: революция в управлении инфраструктурой

GitOps — это подход к управлению инфраструктурой и развертыванию приложений, основанный на использовании Git как единственного источника правды. Все изменения проходят через pull request'ы, что дает прозрачность, контроль версий и автоматизацию.

🔹 Как это работает?
1️⃣ Вся конфигурация хранится в Git-репозитории.
2️⃣ Изменения происходят через коммиты и pull request'ы.
3️⃣ Автоматические агенты (ArgoCD, FluxCD) следят за репозиторием и применяют изменения в кластер.

🔹 Преимущества GitOps:
✅ Полная история изменений — легко откатиться назад.
✅ Автоматизация CI/CD — минимум ручной работы.
✅ Единая точка правды — все изменения в Git.
✅ Повышенная безопасность — политика pull request'ов предотвращает случайные ошибки.

🔹 Лучшие инструменты для GitOps:
🔸 ArgoCD — мощный инструмент с UI для визуального управления деплоями.
🔸 FluxCD — легковесное решение, полностью интегрируемое с Kubernetes.
🔸 Terraform + GitHub Actions — для инфраструктуры как кода.

GitOps — это не просто хайп, а будущее управления инфраструктурой! А ты уже внедрил его в проде?

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

🔥 Kubernetes: Как уменьшить время старта подов? 🔥

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

🚀 1. Используйте лёгкие образы
Выбирайте образы с минимальным количеством зависимостей. Вместо ubuntu:latest лучше взять alpine или distroless.

⚡ 2. Настройте readinessProbe и livenessProbe
Некорректные пробки могут заставить Kubernetes перезапускать поды или считать их неготовыми дольше, чем нужно. Используйте их осознанно.

🎯 3. Предзагружайте образы (Image Pull Policy)
Если ваши поды используют публичные образы, включите ImagePullPolicy: IfNotPresent или Never, чтобы не скачивать образ при каждом старте.

containers:
  - name: app
    image: my-registry/app:latest
    imagePullPolicy: IfNotPresent

💾 4. Используйте InitContainers для подготовки окружения
Если поду требуется что-то до старта (например, миграции БД), лучше использовать InitContainers, чтобы основное приложение стартовало быстрее.

📦 5. Настройте ресурсы
Ограничения CPU и памяти (requests и limits) могут повлиять на скорость старта пода. Если ресурсов мало, контейнеру придётся ждать, пока Kubernetes выделит ему место.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

🏎 6. Используйте preStopHook для graceful shutdown
Чтобы уменьшить задержки при перезапуске подов, обрабатывайте завершение работы приложения через preStopHook.

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 5"]

🔄 7. Включите startupProbe для долгозапускающихся сервисов
Если приложение стартует долго, лучше использовать startupProbe, чтобы Kubernetes не убивал его раньше времени.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 5

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

🚀 Зачем DevOps инженеру уметь писать код?

Часто можно услышать мнение, что DevOps — это про инфраструктуру, пайплайны и кубер, а кодить должны разработчики. Но на практике хороший DevOps инженер неизбежно сталкивается с кодом и скриптингом. Почему это важно?

🔹 Автоматизация всего
Ручные операции = баги и потери времени. Написание CI/CD пайплайнов, автоматизация деплоя, инфраструктура как код (IaC) — все это требует хорошего знания Python, Bash, Go или даже Ruby.

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

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

🔹 Разработка внутренних инструментов
Часто приходится писать собственные тулзы: CLI утилиты, API сервисы для инфраструктуры, кастомные плагины для Kubernetes, Terraform или Ansible.

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

💡 Вывод: кодинг — это не просто полезный навык, а must-have для современного DevOps. Если еще не кодишь — самое время начать!

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

🔥 Как мониторить логи в реальном времени?

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

🔹 tail -f и less +F
Классика UNIX. tail -f позволяет следить за последними строками лога, а less +F даёт возможность как мониторить в реальном времени, так и быстро пролистывать вверх для анализа.

🔹 multitail
Продвинутый вариант tail -f, который позволяет следить за несколькими логами одновременно в одном терминале.

🔹 journalctl -f
Если у вас systemd, используйте journalctl -f -u <service> для слежения за логами конкретного сервиса.

🔹 lnav
Очень мощный CLI-инструмент для логов с синтаксическим разбором, цветовой разметкой и возможностью фильтрации.

🔹 Grafana Loki + Promtail
Если нужен централизованный сбор и визуализация логов, то связка Loki + Promtail отлично подойдёт. Loki индексирует метаданные логов, а Promtail забирает их с серверов.

🔹 ELK (Elasticsearch + Logstash + Kibana)
Если нужно что-то мощнее и удобнее для анализа, то ELK-стек — отличный вариант. Kibana позволяет гибко фильтровать и строить дашборды по логам.

🔹 Vector
Современная альтернатива Logstash и Fluentd, очень эффективен для передачи логов в S3, Kafka, Elasticsearch и другие хранилища.

🔹 Sentry и New Relic
Если нужна агрегация логов и ошибок приложений, используйте Sentry или New Relic. Они позволяют быстро находить проблемные места в коде.


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

🔹Как DevOps может ускорить CI/CD?

Каждый DevOps-инженер рано или поздно сталкивается с проблемами долгих сборок и развертываний. Чем больше микросервисов, тем сложнее их быстро катить в прод. Давай разберем ключевые методы ускорения CI/CD!

🚀 Кэширование артефактов
Используй кэш для зависимостей и промежуточных сборок. Например, в GitHub Actions можно хранить кэш NPM-модулей или Docker-образов.

⚡ Параллельные джобы
Запускай тесты и сборки в параллель, если твой CI/CD позволяет. Например, в GitLab CI можно указать parallel: 4, чтобы запустить 4 одинаковых джобы.

🐳 Оптимизация Docker-образов
1. Правильный порядок команд в Dockerfile – сначала COPY package.json и RUN npm install, потом сам код.
2. Меньше слоев – объединяй команды RUN через &&.
3. Используй легковесные базовые образы – Alpine вместо Debian.

🔄 Incremental Builds
Используй механизмы buildx в Docker и Bazel для сборки только измененных частей кода. Это снижает нагрузку на CI/CD.

🌍 Локальные runner'ы
Если GitHub Actions или GitLab CI тормозят из-за облачных ресурсов, разворачивай self-hosted runners. Это особенно полезно для проектов с высокой нагрузкой на CI.

📊 Мониторинг CI/CD
Включай метрики (Prometheus + Grafana) и анализируй узкие места пайплайна. Иногда проблема – не в коде, а в ресурсах билд-агентов.

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

🔥 DevOps-антипаттерны, которые мешают вашей инфраструктуре

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

🔹 Хрупкая инфраструктура
Вы выкатываете изменения в прод без тестов, мониторинга и резервных копий? Поздравляю, у вас хрупкая инфраструктура, которая рухнет при первом же сбое.

🔹 Один DevOps-инженер на все задачи
"У нас есть DevOps, он все делает". Такой подход быстро приводит к выгоранию и техническому долгу. DevOps — это культура, а не человек.

🔹 Отсутствие IaC (Infrastructure as Code)
Если вы настраиваете серверы руками, вы уже проиграли. Terraform, Ansible, Pulumi — вот ваши лучшие друзья.

🔹 Логирование в "черную дыру"
Вы собираете логи, но никто их не смотрит? Или, что еще хуже, нет нормального логирования? Тогда успехов в поиске багов "на ощупь".

🔹 "Работает — не трогай"
Этот принцип может убить ваш прод. Обновления закрывают уязвимости, повышают стабильность и улучшают производительность. Если у вас все еще Kubernetes 1.18 или Ubuntu 16.04 — пора задуматься.

🔹 CI/CD с кучей ручных шагов
Если ваш деплой требует 10 шагов в Confluence и ручного одобрения от трех человек, это не CI/CD, а боль. Автоматизируйте!

🚀 Что делать?
Пересмотрите свою инфраструктуру, уберите устаревшие практики и не допускайте этих ошибок. DevOps — про эффективность, а не про героизм в 3 часа ночи.

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

Как бороться с конфигурационным дрейфом в инфраструктуре?

Конфигурационный дрейф – это скрытый враг стабильности инфраструктуры. Он возникает, когда фактическое состояние системы начинает расходиться с описанным в коде (IaC). Причины могут быть разные: ручные правки, неучтённые обновления, забытые изменения.

🔥 Как выявить и устранить дрейф?

1️⃣ Используйте периодический аудит
• Terraform: terraform plan поможет выявить разницу между текущим состоянием и кодом.
• Ansible: запустите с флагом --check для проверки соответствия.

2️⃣ Внедрите GitOps-подход
• Используйте ArgoCD или Flux для автоматического применения изменений и приведения системы в соответствие с репозиторием.

3️⃣ Логируйте и мониторьте изменения
• AWS Config, HashiCorp Sentinel, Open Policy Agent помогут отслеживать отклонения от желаемого состояния.

4️⃣ Ограничьте ручные изменения
• Доступ только через IaC.
• Обязательное ревью кода через PR в Git.

5️⃣ Автоматизируйте откат
• Автофиксы через CI/CD при обнаружении дрейфа.
• Используйте immutable-инфраструктуру (замена вместо правок).

Конфигурационный дрейф – это не баг, а особенность живой инфраструктуры. Но держать его под контролем можно и нужно!

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

🔧 Популярные средства оркестрации

1. Kubernetes
- Описание: Де-факто стандарт оркестрации контейнеров.
- Кейсы:
- Микросервисная архитектура.
- Автоматическое масштабирование на основе нагрузки.
- Blue-Green и Canary-развертывания.
- Высокая отказоустойчивость.

2. Docker Swarm
- Описание: Встроенная система оркестрации в Docker.
- Кейсы:
- Простая кластеризация Docker-контейнеров.
- Быстрые POC и MVP без лишней сложности.
- Небольшие команды или проекты.

3. Nomad (от HashiCorp)
- Описание: Легковесная альтернатива Kubernetes, поддерживает разные типы нагрузок (не только контейнеры).
- Кейсы:
- Микс контейнеров, VMs и standalone-приложений.
- Высоконагруженные и распределённые системы.
- Интеграция с Consul и Vault.

4. Apache Mesos / Marathon
- Описание: Платформа для запуска распределённых приложений.
- Кейсы:
- Big Data ворклоады (Hadoop, Spark).
- Оркестрация большого количества различных ресурсов.

5. OpenShift
- Описание: Коммерческая PaaS от Red Hat на базе Kubernetes.
- Кейсы:
- Корпоративные решения с сильной безопасностью и интеграцией.
- Платформа для CICD.
- Разработка в приватных облаках.


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

🛠 Git в проде: 5 команд, которые спасут тебе жизнь

1. git reflog
Забыл, куда ушёл твой коммит после git reset или rebase?
reflog покажет все твои перемещения по репозиторию. Это как история браузера, только для Git.

2. git cherry-pick
Нужно вытащить один нужный коммит из другой ветки?
git cherry-pick <hash> — и он уже у тебя. Удобно, когда прод живёт отдельно.

3. git bisect
Ломаешь голову, когда что-то отвалилось?
git bisect помогает найти коммит, где всё пошло не так. Работает как бинарный поиск.

4. git clean -fdx
Убрать весь мусор, кроме того, что под Git?
Особенно полезно, если после сборки остаётся куча временных файлов.
⚠️ Осторожно: удалит всё незакоммиченное.

5. git worktree
Параллельная работа с несколькими ветками без лишних клонов.
Хочешь протестить фичу и багфикс в одной папке?
git worktree add ../branch-folder branch-name

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

🚀 Почему стоит отказаться от latest в Docker

Кажется удобно: FROM nginx:latest, docker pull redis:latest, но это ловушка. Вот почему:

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

🔍 Проблемы с отладкой
У тебя что-то ломается в проде. Образ — latest. Как узнать, какая версия реально использовалась? Где искать баг? Непонятно.

📦 Кэш и CI/CD
CI может закешировать один latest, ты локально — другой. Поведение отличается. В проде — третий вариант. Гемор.

🧩 Советы
- Всегда пингуй версии: postgres:14.10, node:20.11.1.
- Используй digest, если нужно железобетонно зафиксировать образ:
nginx@sha256:abc123...
- Храни список используемых версий в Makefile или .env для контроля.

🛡️ Инфраструктура должна быть предсказуемой. latest — враг детерминизма.

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

🚀 Чеклист для продакшн-сервера на Linux

Проверяешь ли ты каждый новый сервер перед выкатыванием в прод? Вот тебе мини-чеклист, чтобы ничего не забыть:

1. 🔐 Безопасность
- Отключен root-доступ по SSH
- Включен firewall (например, ufw, firewalld)
- Обновлены все пакеты (apt upgrade / yum update)
- Установлены fail2ban / sshguard
- Развернута система логирования (rsyslog, journald + shipping в Loki/ELK)

2. 🛠️ Система
- Настроен NTP / systemd-timesyncd
- hostname прописан в /etc/hosts
- Правильно выставлены лимиты в /etc/security/limits.conf
- swap включен/отключен по требованиям
- Разделение дисков по best practice (/var, /tmp, /home и т.д.)

3. 📈 Мониторинг и алерты
- node_exporter или другой агент установлен
- alertrules настроены
- Логи собираются (Promtail, Filebeat, и т.д.)
- Проверка доступности (blackbox, ICMP, TCP)

4. ⚙️ DevOps ready
- CI/CD агент установлен (GitLab Runner, Jenkins agent, и т.д.)
- SSH ключи от CI добавлены
- Конфиги под контроль версий
- .env файлы спрятаны, secrets — в vault

5. 🧪 Smoke тесты
- Проверка CPU/RAM/Disk через stress-ng
- Проверка открытых портов ss -tuln
- curl и ping до нужных сервисов (внутренних/внешних)

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

🚀 Зачем DevOps-инженеру уметь читать ядро Linux?

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

📌 Когда это нужно:
- 🐛 Твой сервис падает на проде с segfault, и strace`/`gdb не дают внятной картины.
- 🔥 Системные лимиты или поведение cgroup'ов не совпадают с документацией.
- ⏱ Ты хочешь точно понять, что делает epoll_wait() или почему OOM killer прибивает твой процесс.

📖 Как начать:
1. Выбери версию ядра, с которой работаешь (uname -r тебе в помощь).
2. Клонируй исходники:

   git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
   cd linux
   git checkout v5.x.x  # нужная версия
   

3. Ищи интересующие syscalls или подсистемы:
- fs/, kernel/, mm/, net/, ipc/ — ключевые директории.
- grep -rn "do_fork" или grep -rn "epoll_wait" — твои друзья.

🧠 Советы:
- Начинай с высокоуровневого понимания — читай документацию kernel.org, LWN.net, статьи от разработчиков.
- Используй cscope, ctags или LSP в редакторе — иначе заблудишься.
- Комментируй код для себя: через неделю забудешь, что понял.

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

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

🚀 Твоя система тормозит? А может, просто iowait шалит?

Очень часто мы жалуемся на "тормоза" в Linux, но глядим в top — а CPU загружен всего на 10%. Где подвох? А подвох в iowait.

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

Как диагностировать:

1. Открываем top или htop
Смотрим на строку Cpu(s): — там будет wa (wait):

   %Cpu(s):  5.3 us,  1.0 sy,  0.0 ni, 90.2 id,  3.5 wa, ...
   

2. Проверяем с iostat (из пакета sysstat):

   iostat -xz 1
   

Обрати внимание на await и util.
- await — среднее время ожидания операций I/O (чем выше, тем хуже).
- util — насколько загружен диск (100% = забит под завязку).

3. Используем dstat для наглядности:

   dstat -cdlmn --disk-util
   

Причины высокого iowait:
- Убитые HDD (с долгими seek time)
- Недостаточно RAM → активный swap
- NFS или медленные блочные устройства (ceph, iscsi)
- Базы данных без индексов или с большим кол-вом random I/O

Что делать:
- Проверить SMART у дисков: smartctl -a /dev/sdX
- Убедиться, что swap не используется без нужды: free -h, vmstat 1
- Настроить кэширование или перенести данные на SSD
- Мониторить в динамике: atop, netdata, grafana + node_exporter

🧠 Не забывай: низкая загрузка CPU не всегда значит, что всё хорошо. Иногда система просто ждёт диск.


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

🧠 Зачем set -e в bash-скриптах — и почему он может вас подставить

Многие пишут в баш-скриптах в начале:

#!/bin/bash
set -e

Типа: пусть скрипт падает при первой ошибке. Звучит здраво. Но есть нюанс.

Вот такой код:

set -e
mkdir /tmp/test || true
echo "Продолжаем..."

Что произойдёт, если /tmp/test уже существует?

👉 mkdir вернёт ошибку, но || true спасёт нас. Скрипт пойдёт дальше.

А теперь так:

set -e
if some_command; then
  echo "OK"
fi

Если some_command завершится с ненулевым кодом — всё, скрипт упадёт до входа в if.

🧨 И таких подводных камней с set -e хватает.

💡 Решение — аккуратнее: либо продуманные конструкции вроде if, ||, &&, либо использовать trap и обрабатывать ошибки осознанно.


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

🚨 Как быстро вычислить утечку памяти в Linux?

Когда система начинает “подтормаживать” без видимой причины — пора заподозрить утечку памяти. Вот как можно быстро найти виновника.

🔍 1. Проверяем использование памяти:

free -h

Если available стремится к нулю, есть повод копнуть глубже.

🔧 2. Сортируем процессы по потреблению RAM:

ps aux --sort=-%mem | head -n 10

Тут видно, кто больше всех ест память.

🧠 3. Следим за slab-объектами:

cat /proc/meminfo | grep Slab

Если значение растёт со временем — это сигнал утечки в ядре или драйверах.

🧪 4. Используем smem для точной оценки:

smem -r | sort -k 4 -nr | head

smem учитывает shared memory — оценка куда точнее, чем просто ps.

🎯 5. Если подозрение на конкретный процесс:
pmap — покажет, что именно грузит память:

pmap -x <PID>

🔥 Совет:
Запусти htop, нажми F6, выбери колонку RES, отсортируй. Увидишь — кто на самом деле обжора.

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

🧵 Чеклист перед выкладкой инфраструктурного кода в прод

Инфраструктура как код — мощная штука. Но даже один криво закоммиченный main.tf может повалить пол-продакшена. Вот мини-чеклист, который стоит прогонять перед мержем в main.


✅ 1. План применён?
terraform plan или pulumi preview должен быть свежим и понятным. Никаких сюрпризов в духе «удаляется продовая БД».

✅ 2. Есть backend?
Убедись, что состояние хранится не локально. Используй S3, GCS или аналог — иначе в один день ты потеряешь всё.

✅ 3. -target не попал в CI/CD
Временно использовать -target ок, но не коммить это в pipeline. Это костыль, а не стратегия.

✅ 4. Защищён ли state?
Шифрование включено? Доступ только у нужных людей? terraform state show — часто недооценённый источник чувствительных данных.

✅ 5. Модули не обновились «магически»?
Проверь, что версии всех модулей и провайдеров зафиксированы. Плавающие версии — путь к хаосу.

✅ 6. Документация и комментарии есть?
Ты можешь помнить, зачем это поле у S3, но через месяц ты же сам себе не поверишь. Пиши сразу.

✅ 7. Прогонен tflint / checkov / terraform validate?
Линтеры и валидация — это как spellcheck, но для продакшена. Лишними не будут.

✅ 8. Обратная совместимость учтена?
Изменения в ресурсах типа ALB, IAM policy или security group могут незаметно порушить весь трафик.

✅ 9. Всё в Git?
Terraform code без Git — это как сервер без мониторинга. Безответственно.

✅ 10. Apply сначала в staging!
Если у тебя нет stage-среды — ты и есть stage. Надеюсь, у тебя хорошая страховка.


🛠 Ты можешь автоматизировать почти всё из этого списка. Но думать всё равно придётся. Хотя бы пока.


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

🚀 Проверка сетевых подключений с помощью ss

Команда ss — мощный инструмент для диагностики сетевых соединений в Linux. Она быстрее и информативнее старого доброго netstat. Вот несколько фишек, которые стоит знать:

🔸 Все соединения:

ss -tunap

Покажет TCP/UDP соединения, номера портов, PID процесса и имя.

🔸 Слушающие сокеты:

ss -tuln

Флаг -l фильтрует только те сокеты, которые находятся в состоянии LISTEN.

🔸 Фильтрация по порту:

ss -tuln sport = :22

Можно искать соединения по конкретному порту. Например, 22 — SSH.

🔸 Сокеты определённого процесса:

ss -p | grep nginx

Находит все подключения, где участвует nginx.

🔸 Состояния TCP:

ss -tan state established

Показывает только активные установленные TCP-соединения.

🧠 Если ты до сих пор используешь netstat, попробуй ss.

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

🧩 Почему важно использовать .env файлы в DevOps-проектах

Когда проект начинает обрастать конфигурацией, секретами, API-ключами и разными переменными окружения — легко всё потерять или случайно выложить в Git. Именно тут на сцену выходят .env файлы.

📦 Что такое .env?
Это простой текстовый файл с ключ-значениями, например:

DB_HOST=localhost
DB_USER=admin
DB_PASS=secret

Он не исполняется напрямую, но может быть подгружен в окружение с помощью утилит вроде dotenv, source, или встроенных механизмов в Docker, Compose, CI/CD и так далее.

🔐 Почему это круто:

- Безопасность: не хардкодим чувствительные данные в коде
- Гибкость: можно легко переключаться между dev/stage/prod окружениями
- Поддержка: большинство инструментов CI/CD и фреймворков умеют работать с .env
- Удобство: один файл — все переменные

🛡️ Совет:
Добавь .env в .gitignore, иначе можно случайно закоммитить секреты.

📌 Если работаешь с Docker Compose — укажи env_file в docker-compose.yml:

services:
  app:
    env_file:
      - .env

Так контейнеры будут сразу знать, какие переменные им нужны.

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

🚀 История одной фичи: systemd-run
(aka когда надо быстро запустить что-то от другого пользователя)

Ситуация: ты по SSH, нужно срочно что-то запустить от имени другого пользователя. sudo su? su -? screen? tmux? crontab?
Остановись. Посмотри на это:

sudo systemd-run --uid=appuser --pty bash

💡 Что происходит:
Ты создаёшь временный unit в systemd, от имени пользователя appuser, и получаешь интерактивную сессию в его окружении. Всё красиво, под контролем systemd, с логами, cgroup и т.п.

Можно запускать и отдельные команды:

sudo systemd-run --uid=appuser --pty top

Или фоново:

sudo systemd-run --uid=appuser --scope my-command

🔥 Преимущества:
- работает даже если shell пользователя отключён
- не требует входа в сессию
- всё логируется в journald
- systemd сам подчищает за собой

👀 Используй, когда:
- хочешь тестить что-то от другого юзера
- автоматизируешь запуск задач
- нет желания возиться с su/sudo/scripts

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

🧠 Фичи в Kubernetes, которые ты почти точно не используешь (а зря)

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


🚀 Init Containers
Всё ещё пихаешь скрипты и ожидания в основной контейнер? Init containers — твои друзья. Они запускаются до основного контейнера и идеально подходят для всяких подготовительных задач: прогрев кэша, валидация конфигов, ожидание зависимостей и т.д.


🔒 PodSecurityPolicy (PSP) (устарело, но ты знал?)
Да, PSP deprecated, но оно до сих пор используется в куче продакшенов. Если не хочешь мигрировать на OPA/Gatekeeper прямо сейчас — хотя бы убедись, что PSP у тебя не дырявая.


📦 Ephemeral Containers
Идеальны для отладки. Хочешь зайти в прод-под без шелла или нужных утилит? Добавляешь ephemeral контейнер с bash’ем, curl’ом и всем нужным, не перезапуская под.

kubectl debug -it pod-name --image=busybox

🌐 NetworkPolicy
Ты уверен, что твои поды не могут лезть куда угодно? Пока не включены NetworkPolicy, твой кластер — как квартира без дверей. Даже самый кривой Dev может случайно (или не очень) сломать пол интернета изнутри.


⏱ Liveness vs Readiness
Это не одно и то же. Readiness говорит, когда трафик можно пускать. Liveness — когда под умер. Если перепутал — получишь либо DDoS от своих же сервисов, либо перезапуск в вечном цикле.


Пользуешься всеми? Респект. Нет? Самое время попробовать.

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