DevOps Star (Звезда Девопса)

Настройка LDAP-аутентификации в кластере Kubernetes под управлением Deckhouse Deckhouse — Kubernetes-платформа с открытым кодом, с помощью которой можно создавать идентичные Kubernetes-кластеры в любой инфраструктуре и автоматически управлять ими. Для проверки подлинности в Deckhouse используется модуль user-authn. Он настраивает единую систему аутентификации, интегрированную с Kubernetes и веб-интерфейсами других модулей — например, с Grafana. user-authn поддерживает несколько внешних провайдеров и протоколов аутентификации: GitHub, GitLab, Bitbucket Cloud, Crowd, LDAP и OIDC. В статье расскажу, как развернуть сервер LDAP и настроить через него доступ к приложению. https://habr.com/ru/companies/flant/articles/710010/ 👉 @devops_star

Haskell Dockerfile Linter Интеллектуальный распаковщик Dockerfile, помогающий создавать лучшие образы Docker. Линтер разбирает Docker-файл на AST и выполняет правила поверх AST. Он опирается на поддержку ShellCheck для проверки Bash-кода внутри инструкций RUN. https://github.com/hadolint/hadolint 👉 @devops_star

Реальное собеседования DevOps инженер Junior++ Недавно мне знакомый прислал свое DevOps собеседование. Он DevOps инженер уровня Junior++. Опыт работы больше года. До этого работал сисадмином 2 года. Пришлось изменить голоса и убрать видео чтобы участников собеседования никто не узнал. А так же не узнал в какую компанию собеседовался Девопс инженер. источник 👉 @devops_star

Grafana OnCall — Open Source хаб для алертов и инцидентов Если кратко, OnCall — это инструмент, который поможет организовать надежные оповещения/реагирование на инциденты в команде, соблюдать SLA и не просыпаться ночью от звонков. OnCall — новичок в мире Open Source, но уже совсем не новичок как продукт. Он начался как отдельный SaaS под названием Amixr. IO несколько лет назад. Потом Amixr. IO приобрела Grafana Labs и интегрировала в свою экосистему. И вот недавно, наконец, мы смогли выложить исходный код OnCall в открытый доступ 🎉 А это значит, что он стал доступен большему кругу пользователей — и тем, кто работает в инфраструктуре без интернета, и тем, кто просто любит Open Source. Далее https://habr.com/ru/articles/688794/ 👉 @devops_star

Buildg - Интерактивный отладчик для Dockerfile, с поддержкой IDE (VS Code, Emacs, Neovim и т.д.). Source-level inspection Breakpoints and step execution Interactive shell on a step with your own debugigng tools Based on BuildKit (with unmerged patches) Supports rootless https://github.com/ktock/buildg 👉 @devops_star

Задаём порядок деплоя ресурсов в Kubernetes с помощью werf/Helm При деплое в Kubernetes часто требуется выкатывать ресурсы в определённом порядке, а иногда и дожидаться готовности сторонних ресурсов. Например, сначала нужно запустить БД, дождаться создания динамического Secret’а сторонним оператором, потом выполнить инициализацию/миграции БД, а уже затем запустить само приложение. Рассмотрим, как решать такие задачи с помощью Helm, а также сравним с более быстрым и удобным вариантом, который предлагает Open Source-утилита werf. https://habr.com/ru/companies/flant/articles/682804/ 👉 @devops_star

Нюансы Kubernetes Контейнеризация и, в частности, Kubernetes – стандарт для запуска приложений в бою. Это несложно, но есть нюансы. Вместе с Андреем Новиковым из Evil Martians обсуждаем, что нужно сделать, чтобы приложение работало быстро и надежно. Смотрим, как работают requests и limits на ресурсы, чем должны отличаться liveness и readiness пробы и на что следует обращать внимание в мониторинге. 👉 @devops_star

Как работает Docker 👉 @devops_star

Docker справочник cli docker images — показать все локальные образы docker docker rmi [-f] <id|label> — удалить образ c локальной машины docker rmi -f $(docker images -q) — удалить все докер образы docker build [-t <label>] <path> — построить образ на основе докерфайла docker run [-dt] [--name <name>] [-v <path:path>] [-p <port:port>] [--...] <id|label> [cmd] — запустить образ в контейнере c cmd-командой (необязательно) -d — в фоновом режиме -t — прикрепляет к контейнеру терминал -i — перенаправляет ввод/вывод на текущий терминал --name — явно указать имя контейнера, по которому можно будет обращаться к нему (иначе будет сгенерировано рэндомно) -p <external_port:internal_port> — проброс портов -v --volume <external_path:internal_path> — монтирует папки хоста в контейнер --rm — удаляет контейнер после завершения работы --memory <n> — позволяет указать количество ОЗУ, доступной контейнеру -P — пробрасывает все порты контейнера в хост-систему --expose — позволяет пробросить несколько портов из контейнера в хост-систему -e <"FOO=bar"> — добавляет переменную окружения в контейнер docker ps [-a] — показать все запущенные [существующие] докер контейнеры `docker ps -q | xargs docker stats —no-stream` — посмотреть ресурсы, потребляемые запущенными контейнерами docker stop <name> — останавливает указанный образ (с сохранением данных) docker kill <name> — то же самое без сохранения данных docker rm <name> — удаляет указанный контейнер docker attach <name> — подключиться к выбранному докер-контейнеру docker exec [-ti] <name> <cmd> — выполняет команду в докер-контейнере docker push <imagename> — отправить образ в удаленный реестр docker ps -q | xargs docker stats --no-stream — посмотреть нагрузку на процессор и память каждого из контейнеров docker stats — похожа на предыдущую команду, но более короткая docker info --format '{{.LoggingDriver}}' — посмотреть используемый по умолчанию лог драйвер (json-file) docker logs [<container_name>] [-f --tail 100] — показать логи [конкретного контейнера] в терминал [последние 100 строк] docker inspect --format='{{.LogPath}}' <containername> -показать, где хранятся логи для конкретного контейнера 👉 @devops_star

Лекторий по SRE Примеры сбоев Что такое SRE Цели мониторинга, логи и метрики Детектирование проблем до и во время сбоя SLA, SLO, SLI Причины сбоев Устранение сбоев Постмортемы Приемы уменьшения количества сбоев Устойчивый к сбою код источник 👉 @devops_star

Вопросы и ответы на собеседовании по Git для DevOps https://medium.com/@tech.manojk10/git-interview-questions-and-answers-for-devops-5d0b971f8fbb 👉 @devops_star

Шпаргалка по kubectl Автодополнение ввода для Kubectl

source <(kubectl completion bash) # настройка автодополнения в текущую сессию bash, предварительно должен быть установлен пакет bash-completion .
echo "source <(kubectl completion bash)" >> ~/.bashrc # добавление автодополнения autocomplete постоянно в командную оболочку bash.

Вы также можете использовать короткий псевдоним для kubectl, который можно интегрировать с автодополнениями:

alias k=kubectl
complete -F __start_kubectl k

https://kubernetes.io/ru/docs/reference/kubectl/cheatsheet/ 👉 @devops_star

Шпаргалка по CLI-командам Kubernetes Kubectl 👉 @devops_star

Snips.sh ✂️ Безпарольный, анонимный pastebin на основе SSH с удобным текстовым и веб-интерфейсом Фичи: ⚡ Нулевая установка: используйте с любого устройства, где установлен SSH-клиент 🌐 Веб-интерфейс: код с подсветкой синтаксиса, короткие ссылки и поддержка рендеринга Markdown 💻 Текстовый интерфейс: управление и просмотр сниппетов прямо из терминала 🔑 Без паролей: всё, что вам нужно — это SSH-ключ 🕵️ Анонимность: без регистрации, без логинов, без необходимости указывать email ⏰ URL с временем жизни: ограниченный по времени доступ для безопасного обмена 📦 Возможность самостоятельного хостинга: контейнеризированный и малозатратный в плане ресурсов 🧠 Определение языка с помощью ИИ: интеллектуальное распознавание исходного кода https://github.com/robherley/snips.sh 👉 @devops_star

11 советов по повышению безопасности контейнеров 🔐 1 🔒 Используйте официальные образы Для минимизации уязвимостей всегда используйте официальные, проверенные образы контейнеров из надежных источников. Проверяйте подписи образов, чтобы убедиться в их подлинности. 2 📦 Регулярно обновляйте образы Поддерживайте образы контейнеров в актуальном состоянии с помощью последних исправлений и версий, чтобы устранить известные уязвимости. По возможности автоматизируйте обновления. 3 🔍 Сканирование образов на наличие уязвимостей Используйте такие инструменты, как Clair, Trivy или Anchore, для проверки образов контейнеров на уязвимости перед развертыванием. Сделайте это частью вашего CI/CD pipeline. 4 📜 Следуйте принципу наименьших привилегий Запускайте контейнеры с минимально необходимыми привилегиями. Избегайте запуска контейнеров от имени root и используйте пространства имен пользователей для разграничения привилегий. 5 🛠️ Используйте средства обеспечения безопасности на этапе выполнения Используйте инструменты безопасности во время выполнения, такие как Falco или Sysdig Secure, для мониторинга и защиты запущенных контейнеров от угроз и аномалий. 6 🔐 Внедрите сегментацию сети Изолируйте контейнерные сети, чтобы ограничить связь между контейнерами. Используйте инструменты вроде сетевых политик Kubernetes для обеспечения сегментации. 7 📋 Ограничение использования ресурсов Ограничьте ресурсы (процессор, память), которые могут использовать контейнеры, чтобы предотвратить атаки на исчерпание ресурсов. Используйте квоты и лимиты ресурсов Kubernetes. 8 🛡️ Включение контекстов безопасности Определите контексты безопасности в платформе оркестровки контейнеров для контроля доступа и разрешений. Используйте PodSecurityPolicies в Kubernetes. 9 🧩 Используйте решения для управления секретами Безопасное управление и хранение конфиденциальных данных, таких как пароли и ключи API, с помощью таких инструментов, как HashiCorp Vault, AWS Secrets Manager или Kubernetes Secrets. 10 🌐 Регулярные аудиты и проверки на соответствие требованиям Регулярно проводите аудиты безопасности и проверки на соответствие требованиям, чтобы обеспечить соблюдение политик и стандартов безопасности. Автоматизируйте аудиты с помощью таких инструментов, как kube-bench. 11 🔄 Постоянно обучайте свою команду Постоянно информируйте свою команду о последних практиках и тенденциях в области безопасности. Регулярно проводите тренинги и делитесь ресурсами. 👉 @devops_star

Зачем мы сделали собственный контроллер для копирования секретов в Kubernetes Сегодня хочу поделиться нашей внутренней разработкой — Kubernetes-контроллером mirrors. Мы создали его внутри нашего DevOps-отдела для копирования Kubernetes-секретов между неймспейсами кластера. В итоге mirrors превратился в универсальный инструмент синхронизации данных из разных источников. В статье расскажу, с чего все начиналось и к чему мы в итоге пришли. Возможно, статья вдохновит вас на написание собственного контроллера под ваши задачи. 👉 @devops_star

Поднимаем динамические окружения (фича-стенды) для stateless- и stateful-сервисов На связи Игорь Латкин, управляющий партнер и системный архитектор в KTS. Мы на своём опыте разобрались в развертывании stateless- и stateful-сервисов, и теперь хотим поделиться с вами. Мы в KTS не раз создавали подобные инфраструктуры, перепробовали разные решения и выясняли, как построить эффективные процессы. Сегодня мы поговорим о динамических окружениях (фича-стендах) для stateless- и stateful-сервисов, обсудим особенности и проблемы, которые могут возникнуть и возникали у нас. https://habr.com/ru/companies/kts/articles/833354/ 👉 @devops_star

Набор инструментов DevOps🧰 Операционная система → Linux (рекомендуется), Windows Программирование → Go, Python, Groovy, Bash Оркестрация контейнеров → Kubernetes, Docker Swarm Контейнеры → Docker, Podman, Containerd Система управления версиями → Git, Subversion Облака → AWS, GCP, Azure, CivoCloud CI/CD → Jenkins, CircleCI, Bamboo Совместная работа и контроль версий → GitHub, BitBucket, GitLab IaC (Инфраструктура как код) и IP (Развертывание инфраструктуры) → Ansible, Puppet, Chef, Terraform, Pulumi, Stack, Crossplane Непрерывная обратная связь → GetFeedback, Jira, Slack, Pendo Наблюдаемость (мониторинг, логирование и анализ поведения системы) → Nagios, Grafana, Prometheus, New Relic, ELK Stack, Datadog Планирование → Jira Software, Confluence, Slack Автоматизированное тестирование → xray, snyk, JUnit, Selenium, Appium 👉 @devops_star