Tfautomv

Автоматическое создание перемещенных блоков Terraform для безболезненного рефакторинга

https://github.com/padok-team/tfautomv

👉 @devops_star

По мотивам ... 😀

👉 @devops_star

Kubectl-foreach

Параллельное выполнение команд kubectl во всех/некоторых контекстах (аналогично GNU xargs+parallel).

Usage:
kubectl foreach [OPTIONS] [PATTERN]... -- [KUBECTL_ARGS...]

Patterns can be used to match context names from kubeconfig:
(empty): matches all contexts
NAME: matches context with exact name
/PATTERN/: matches context with regular expression
^NAME: remove context with exact name from the matched results
^/PATTERN/: remove contexts matching the regular expression from the results

Options:
-c=NUM Limit parallel executions (default: 0, unlimited)
-I=VAL Replace VAL occurring in KUBECTL_ARGS with context name
-q Disable and accept confirmation prompts ($KUBECTL_FOREACH_DISABLE_PROMPTS)
-h/--help Print help

https://github.com/ahmetb/kubectl-foreach

👉 @devops_star

Лучшие практики Docker

Используйте многоступенчатые сборки, чтобы уменьшить размер продакшен-образа.

👉 @devops_star

Сервисы Kubernetes: ClusterIP, Nodeport и LoadBalancer

Поды эфемерны. Так и должно быть. Их можно легко уничтожить и заменить при использовании развертывания. Или они могут быть масштабированы в определенный момент при использовании горизонтального автомасштабирования (Horizontal Pod Autoscaling, HPA).

Это означает, что мы не можем полагаться на IP-адрес Pod для подключения к приложениям, запущенным в наших контейнерах внутри или снаружи, поскольку в будущем Pod может не существовать.

Вы могли заметить, что подкатам Kubernetes присваивается IP-адрес:

https://sysdig.com/blog/kubernetes-services-clusterip-nodeport-loadbalancer/

👉 @devops_star

Полный рабочий процесс CI/CD с Skaffold для вашего приложения

Современный способ построения полного рабочего процесса от локального до продакшена с помощью Skaffold и Gitlab на кластере Kubernetes для снижения когнитивной нагрузки и операционной сложности в стеках приложений.

(Часть I)
https://blog.equationlabs.io/cicd-workflow-with-skaffold-for-your-application-part-i

(Часть II)
https://blog.equationlabs.io/how-to-build-a-cicd-workflow-with-skaffold-for-your-application-part-ii

(Часть III)
https://blog.equationlabs.io/how-to-build-a-cicd-workflow-with-skaffold-for-your-application-part-iii

👉 @devops_star

5 советов начинающему DevOps Engineer

DevOps не понаслышке понимает все циклы разработки, процессы планирования работ командами и управления ожиданиями заказчика.
А что же делать, если ты только вначале своего пути? Как вникнуть во все процессы и понять все тонкости? Донт вори!

Ярослав Обиход, DevOps Engineer Boosta, поможет разобраться.
Какая база лежит в основе работы DevOps инженера? Какие системы можно использовать для мониторинга и логирования?
Досмотри до конца и ты узнаешь, сколько может зарабатывать junior DevOps и как бонус- получишь список книг, которые помогут прокачаться в профессии.

источник

👉 @devops_star

Эволюция Terraform: Как мы безопасно отделили дюжину сервисов от монолита

Если вы используете terraform для управления облачной инфраструктурой, то по мере роста проекта вы могли столкнуться с некоторыми проблемами. Возможно, код terraform становится слишком сложным и запутанным. Возможно, развертывание занимает слишком много времени и приводит к ошибкам. Возможно, ваша команда боится вносить изменения, потому что не знает, что может сломаться.

https://medium.com/@susovan87/lesson-learned-after-decoupling-a-dozen-of-services-from-terraform-monolith-safely-with-no-downtime-404e503f6cb6

👉 @devops_star

Haskell Dockerfile Linter

Интеллектуальный распаковщик Dockerfile, помогающий создавать лучшие образы Docker. Линтер разбирает Docker-файл на AST и выполняет правила поверх AST. Он опирается на поддержку ShellCheck для проверки Bash-кода внутри инструкций RUN.

https://github.com/hadolint/hadolint

👉 @devops_star

Skipper

Skipper - это HTTP-маршрутизатор и обратный прокси для построения сервисов. Он разработан для обработки >300 тысяч HTTP-маршрутов с подробными условиями поиска и гибким дополнением потока запросов фильтрами. Его можно использовать из коробки или расширить с помощью пользовательского поиска, логики фильтрации и конфигурации.

https://github.com/zalando/skipper

👉 @devops_star

Как выбрать подходящий путь для внутренней платформы разработки?

Приглашаем на вебинар, посвящённый ключевым аспектам платформенной инженерии.

🗓 20 июня | 🕒 12:00

На вебинаре обсудим:
🔸 3 варианта построения платформы (плюсы/минусы каждого).
🔸 Почему растёт спрос на платформы разработки – глобальные тренды и локальные особенности.
🔸 Как оценить риски внедрения разных видов платформ?
🔸 Что такое модель 7С и как применить DORA-метрики в вашем случае.

Формат: плотный разбор темы за 40 мин + ответы на ваши вопросы. 

Спикер: Алексей Зимонин, старший техлид по практикам DevOps в бизнес-юните «Экспресс 42» (АО «Флант»).
💪 14 лет в ИТ, строил highload-инфраструктуру в телекоме, запускал платформу, которая масштабировалась до уровня «фабрики».

🔗 Зарегистрироваться

Для кого: CTO, DevOps, Platform Engineers, ИТ-менеджеры, разработчики.

P.S. Во время эфира всем участникам подарим готовую памятку для платформенной команды с лучшими практиками Platform Engineering.

#реклама
О рекламодателе

👉 @devops_star

Как я ищу себе сотрудников в команду DevSecOps и AppSec

Привет! Меня зовут Михаил Синельников. Я DevSecOps TeamLead в РСХБ‑Интех. Тружусь в ИТ‑сфере уже 25 лет, немалую часть из которых — на руководящих должностях. Сегодня расскажу, как я ищу специалистов к себе в команду DevSecOps и AppSec, на что обращаю внимание и как общаюсь с соискателями, которые на собеседовании пытаются приукрасить собственные достижения.

Сразу отмечу, что мой опыт в основном касается найма сотрудников в регионах на удаленку. И тут есть свои сложности. Специалисты боятся уйти из местных компаний, потому что это, во-первых, гарантия трудоустройства и, во-вторых, очень стабильное место. Я тоже прошел этот путь и решился перейти из маленькой компании в большую, но об этом, наверное, расскажу в следующий раз.

https://habr.com/ru/companies/rshb/articles/802807/

👉 @devops_star

Руководство по Kubernetes для хейтеров Kubernetes

Есть среди программистов такая фракция, в которой Kubernetes пользуется дурной репутацией как чрезмерно сложный пожиратель времени и технология, которой следует сторониться стартапам. Использовать Kubernetes в рамках небольшой команды — явный признак инженерного переусложнения.

Я и сам замешан в перемывании косточек на эту тему.

https://habr.com/ru/companies/timeweb/articles/804259/

Original https://paulbutler.org/2024/the-haters-guide-to-kubernetes/

👉 @devops_star

Настраиваем CI/CD с GitHub Actions и werf: инструкция для новичков

В этой статье мы рассмотрим, как настроить пайплайн CI/CD в GitHub: подготовим репозиторий, зальём туда приложение, создадим файлы конфигурации GitHub Actions, в которых опишем, как собирать наше приложение и деплоить его в кластер Kubernetes, развёрнутый под управлением Deckhouse Kubernetes Platform. Деплоить будем с помощью Open Source CLI-утилиты werf. Она помогает организовать полный цикл доставки приложений в Kubernetes и рассматривает Git как единый источник истины для состояния развёрнутого приложения. Статья рассчитана на тех, кто только начинает свой путь в мире облаков и кластеризации.

https://habr.com/ru/companies/flant/articles/803251/

👉 @devops_star

Автоматизируем сборку и деплой приложения в GitLab CI/CD: подробное руководство с примерами

При разработке приложений рано или поздно наступает момент, когда заниматься развёртыванием вручную становится затратно и неудобно. Как следствие на помощь приходит автоматизация этого процесса с помощью специально настроенных пайплайнов непрерывной интеграции и непрерывной доставки (Continuous Integration & Continuous Delivery — CI/CD). Для разных систем управления репозиториями исходного кода существуют свои способы настройки CI/CD.

В этой статье мы рассмотрим, как использовать GitLab для организации автоматической сборки и деплоя приложения в кластер Kubernetes. Сам кластер будет работать под управлением Deckhouse Kubernetes Platform (код приложения и процесс настройки кластера мы описывали в предыдущей статье цикла), а автоматизировать процесс будем с помощью werf — Open Source CLI-утилиты, организующей полный цикл доставки приложения в Kubernetes и использующей Git как единый источник истины для состояния приложения, развёрнутого в кластере.

https://habr.com/ru/companies/flant/articles/795475/

👉 @devops_star

Отладка плэйбуков ansible

В этом руководстве я постараюсь рассказать как дебажить playbookи, устраняя потенциальные проблемы, не дожидаясь обезвреживания продакшена. Если вы читаете это, то я уверен что вы, также как и я, прочитали десяток статей о том как установить ansible и запускать (применять - режет слух) плэйбуки для конфигурирования всего до чего дотягивается руки.

https://habr.com/ru/articles/745328/

👉 @devops_star

Пишем роли ansible не ломая прод — особенности check_mode или как правильно его готовить

В данном опусе я попытаюсь рассказать как можно писать роли и плэйбуки такими, чтобы они отыгрывали без падений при запуске с флагом --check. Зачем вот это всё: вы в команде адептов инфраструктуры как код и не только раскатываете свою инфраструктуру, но и обновляете ее и хотите быстро восстанавливать, а это значит что вы должны обеспечивать одну из ключевых концепций ansible - идемпотентность повторных запусков. Для этого вы вынуждены не только писать роли, применяя их в лабораторных условиях, но и применения их на реальной инфраструктуре, о том как дебажить при этом ямлы написано например здесь. Применять код который сделает множество изменений в продакшн - такое себе удовольствие не для слабонервных, поэтому и мы будем пускать его предварительно с флагом --check - в холостую, желая посмотреть те изменения которые будут внесены в целевую инфраструктуру. То есть, если вы собираетесь реконфигурировать сервис в одном конфиге и перезапустить-перегрузить его, то вы должны увидеть только 2 изменения (changed) по итогам запуска.

https://habr.com/ru/articles/746864/

👉 @devops_star

🚀 Тренды в Kubernetes и DevOps 2025

26 июня в 19:00 приглашаем на прямой эфир в Telegram-канале «Кубернетика». Вас ждет экспертная оценка ключевых трендов Kubernetes и DevOps: определим, какие из них реально ждут нас в будущем, а какие — просто хайп.

CTO, инженеры DevOps-практик и архитекторы — приходите узнать о практиках, которые скоро станут повседневностью. 

Разберём:
• AI/ML в DevOps становится стратегическим преимуществом, а не просто инструментом?
• DevSecOps — это опция или необходимость?
• GitOps — стандарт управления инфраструктурой?
• Роль платформ разработки (IDP) в создании эффективной DevOps-культуры.
• Устойчивые (sustainable) практики DevOps.
• Будущее виртуализации в Kubernetes.

20 минут полезного контента + 10 минут ответов на вопросы.

🔹 Подписывайтесь и ставьте напоминание о трансляции, чтобы не пропустить!

GitOps с использованием Flux и Flagger

GitOps как практика используется с 2017 года, когда Алексис Ричардсон придумал этот термин. Он изменил DevOps и автоматизацию. Если посмотреть на его основные принципы, то он расширяет DevOps, рассматривая инфраструктуру как код (IaC). Конфигурация развертывания хранится в системе контроля версий (она же Git), обеспечивая единый источник данных для разработчиков.

https://dev.to/infracloud/gitops-using-flux-and-flagger-15ci

👉 @devops_star