🔥 Скидка 50% на выделенные серверы в Казахстане

Получите скидку 50% на аренду выделенных серверов от Servercore на все время, пока вы арендуете сервер. Акция действует на все готовые конфигурации, количество серверов ограничено!

Что вы получаете:

▪️ Полный контроль над ресурсами (запуск до 60 минут) на базе дата-центра в Алматы с минимальными задержками для Казахстана и Центральной Азии

▪️ Высокую производительность: мощные процессоры Intel Xeon (серий E, W, Silver) и AMD EPYC, различные варианты оперативной памяти (DDR4 ECC и DDR4 ECC Reg), а также любые комбинации накопителей — скоростные SSD NVMe, базовые SSD SATA и вместительные HDD SATA.

▪️ Безопасность и надежность: физическую изоляцию, приватную сеть, удаленное управление через KVM-консоль и бесплатную техподдержку 24/7.

▪️ Оптимизацию бюджета: аренду сервера от 35 000 тенге/мес (с учетом скидки) без затрат на закупку собственного оборудования.

Как получить скидку?

👉 Оставьте заявку на странице акции

Технические специалисты Servercore свяжутся с вами в течение 3 рабочих дней, помогут подобрать оптимальную конфигурацию под ваши нагрузки и активируют скидку.

🔥 10 DevOps-трендов 2026: что меняется прямо сейчас

TechTarget опросил аналитиков Forrester, CompTIA и ScrumОrg — вот куда движется DevOps в этом году. Простите, но мы снова про AI 🫡

1. AI везде в SDLC

Главный мета-тренд, из которого вытекают все остальные. Больше AI, больше AI-агентов, больше автоматизации на каждом этапе — от требований до деплоя.

2. Скорость разработки ×2

Vibe coding и AI-ассистенты сжимают цикл разработки на 50–60%. Теперь узкое место — не код, а всё, что вокруг него.

3. Platform teams как стандарт

Отдельная команда, которая строит и поддерживает инфраструктуру, инструменты и сервисы для DevOps-команд. Убирает дубли, стандартизирует стек. Всё это становится нормой.

4. Переосмысление процессов

AI меняет не только инструменты, но и сам процесс: как собираются требования, как код идёт в прод, что считается best practice. То, что работало вчера — пересматривается.

5. Консолидация тулинга

Вместо зоопарка специализированных инструментов — один или несколько платформенных. Проще поддерживать, проще управлять.

6. Смарт-инструменты с самовосстановлением

AI в мониторинге уже умеет ловить проблемы до того, как они привели к инцидентам. Следующий шаг — автоматически их чинить (self-healing).

7. Intent-driven инфраструктура

Вместо «описываю конфиг руками» будет «описываю намерение, AI сам определяет окружение». IaC как концепция никуда не денется, но форма изменится.

8. Cost-awareness в деплое

Бизнес хочет предсказуемые расходы на облако. DevOps-команды теперь должны думать не только о работоспособности, но и о стоимости каждого деплоя.

9. Новые роли и скиллы

AI берёт рутину — инженеры уходят в более высокоуровневую работу. Растёт спрос на data skills (чтобы правильно обучать и контролировать AI), системное мышление и умение работать с абстракциями.

10. Геополитика и суверенитет данных

Всё больше компаний обязаны держать серверы, платформы и данные внутри своей страны. Регуляторные требования становятся частью DevOps-архитектуры.

@DevOpsKaz 😛

🔥 Kubernetes Bad Practices

Сегодня у нас партнерский пост от DevOps FM. Замечали, что определенные ошибки в настройке подов неизбежно ведут к инцидентам? Собрали для вас подборку плохих практик, которые ни в коем случае нельзя повторять в работе с оркестратором.

⚪️ Не учитывайте тип трафика при балансировке нагрузки для подов

По умолчанию поведение Kubernetes при трафике HTTP/2 отличается от HTTP/1. Без настройки маршрутизации на L7 один под берет на себя всю нагрузку CPU, в то время как другие простаивают.

Good practices:

⁃ При HTTP/2 заранее проверяйте балансировку в кластере (L4 vs L7)
⁃ Проводите нагрузочное тестирование с теми же настройками (connection pooling/keep-alive), что будут в проде
⁃ Отслеживайте распределение connections и latency по pod-ам

⚪️ Kubernetes сам синхронизируется с внешними сервисами

При использовании внешних тулзов и сервисов, таких как Argo CD, возникают проблемы. Используйте скейлинг для обнаружения.

Good practices:

⁃ В GitOps-кластерах не правьте поля, которые управляются контроллерами (HPA, VerticalPodAutoscaler)
⁃ В работе избегайте client-side внедрений и удаляйте реплики из манифестов деплоя при использовании HPA

⚪️ Всегда задавайте лимиты CPU — троттлинг лишним не бывает

В приложении возникают таймауты из-за CFS троттлинга.

Good practices: не задавайте CPU лимиты без необходимости, а при использовании проводите тест нагрузки

⚪️ Не задавайте приоритет нагрузкам

Если приоритет не задан, kubelet избавится от любого пода.

Good practices:

⁃ Всегда задавайте PriorityClass для системных контроллеров
⁃ Отслеживайте приоритет и его использование
⁃ Тестируйте поведение в staging

⚪️ Удаляйте контроллеры до управляемых ресурсов, поды скажут «спасибо»

Смело удаляйте контроллер, если хотите очередей. Поды застревают в «Terminating» из-за финализаторов, в EKS они по-прежнему удерживают IP-шники и исчерпывают пул адресов подсети.

Good practices:

⁃ Никогда не удаляйте контроллер, пока не удалили управляемые им ресурсы
⁃ Относитесь к финализаторам как к «постоянным» до удаления
⁃ Настройте мониторинг и алерты на: число Terminating подов, долю занятых IP в подсети, количество подов в обработке

⚪️ Храните большие логи локально

Если хранить логи на локальном диске ноды, их станет слишком много, диск заполнится, нода уйдет в DiskPressure. Kubelet удалит поды, а новые просто не запустятся.

Good practices:

⁃ Не храните временные логи только на локальном диске. Используйте централизованную систему: Fluentd, Logstash, облако
⁃ Устанавливайте запросы и лимиты для ephemeral-storage у контейнеров, чтобы избежать неограниченного потребления диска
⁃ Включите ротацию логов и ограничение размера
⁃ Настройте алерты на рост использованного диска в связке с подами — disk usage per pod

Какие худшие практики в работе с Kubernetes встречались вам? Отправляйте свои идеи предложенным постом через бота — если соберем достаточно, опубликуем подборку здесь.

@DevOpsKaz 😛

🔥 Self-hosted платформы для разработки и инфраструктуры

Мы привыкли, что GitLab делает почти всё: репозиторий, CI/CD, реестр контейнеров, задачи, вики. Но GitLab Enterprise дорогой для больших команд, а у Community Edition есть слабые места: Package Registry беднее специализированных решений, Wiki — не всегда для серьёзной документации. Для сложных распределенных транзакций с сохранением состояния (Stateful) и детального учета железа его встроенных модулей уже недостаточно.

Инструменты, которыми можно усилить разработку и инфру:

⚪️ Nexus Repository Community Edition

Замена слабому Package Registry GitLab'а. Поддерживает 15+ форматов: Maven, npm, Docker, NuGet, PyPI, Helm, Go, RubyGems, Apt, Yum, Cargo и другие. Проксирует внешние репозитории, хранит внутренние сборки.

⚪️ Temporal

То, чего пока нет в GitLab: оркестрация распределённых рабочих процессов за пределами CI/CD пайплайнов. Берёт на себя бизнес-логику с автоматическими повторными попытками, сохранением состояния и масштабированием. MIT-лицензия,
self-hosted.

⚪️ NetBox

DCIM/IPAM — единая модель инфраструктуры: устройства, соединения, IP-адреса, VLAN, кабели. NetBox закрывает учёт физической и сетевой инфраструктуры в одном источнике.

⚪️ Outline

Замена GitLab Wiki для тех, кому важна удобная документация со сложной иерархией. Markdown-редактор, быстрый поиск, интеграция со Slack, совместная работа. Self-hosted использование бесплатно, но это не классический open source.

@DevOpsKaz 😛

🔥 Наурыз мейрамы құтты болсын!

Поздравляем с праздником Наурыз всё сообщество и ваших родных. Желаем, чтобы ваша проектная инфраструктура процветала, подрядчики радовали, работа приносила удовольствие, а человеческие ценности и знания предков сохранялись.

Пусть изобилие придет в каждую сферу вашей жизни!

С любовью,
@DevOpsKaz 😛

👀 Trivy взломали снова. И на этот раз — серьёзно

Пока мы отдыхали, стало известно: злоумышленники скомпрометировали официальный GitHub Action aquasecurity/trivy-action — тот самый, которым все сканируют уязвимости в CI/CD.

➖ Что произошло

Атакующие форс-пушнули 76 из 77 тегов версий в репозитории. Если ваш workflow ссылается на action по тегу типа @0.34.2, @0.33.0 или @0.18.0 — вы запускаете вредоносный код. Единственный нетронутый тег — @0.35.0.

Малварь выполняется ДО запуска настоящего Trivy, поэтому визуально всё выглядит штатно.

➖ Что делает малварь

Дампит память раннера, ворует SSH-ключи, AWS/GCP/Azure credentials, Kubernetes service account токены. Классический инфостилер для CI/CD окружений.

➖ Масштаб

Более 10 000 workflow-файлов на GitHub ссылаются на этот action. Потенциально — тысячи проектов под ударом.

➖ Что делать прямо сейчас

1. Проверьте, не используете ли вы aquasecurity/trivy-action по тегу (не по SHA)
2. Если да — считайте CI/CD секреты скомпрометированными. Ротируйте AWS ключи, SSH, K8s токены
3. Перейдите на пиннинг по commit SHA вместо тегов — теги можно перезаписать
4. Пересмотрите permissions в GitHub Actions — используйте принцип минимальных привилегий

➖ Главный урок

Это второй инцидент с Trivy за месяц (первый был с VS Code расширением). Пиннинг по версии не защищает — только полный commit SHA. И да: инструмент безопасности сам стал вектором атаки.

@DevOpsKaz 😛

🔥 Безопасность Kubernetes в 2026 году

В феврале 2026 TeamPCP развернула payload, который перечислял поды и namespace'ы, выполнял команды во всех доступных нагрузках и ставил привилегированный DaemonSet для контроля над кластером. 185 серверов подтверждено. Один скомпрометированный под — и весь кластер в ботнете.

При этом главная проблема — мисконфигурации. Мы написали подробное руководство, где разобрали все слои по модели 4C:

⚪️ Cloud — почему 81% EKS-кластеров до сих пор на устаревшей аутентификации, и что проверить в Yandex Cloud / VK Cloud
⚪️ Cluster — RBAC без cluster-admin, Pod Security Admission вместо мёртвых PSP, защита etcd и API-сервера
⚪️ Container — сканирование образов в CI/CD, подпись через cosign, Seccomp-профили, runtime detection через Falco
⚪️ Code — deny-all Network Policy как стартовая точка, секреты через volumes вместо env, mTLS между сервисами

Также внутри 5 YAML-примеров и чеклист из 20 действий по приоритету.

👉 Читать

@DevOpsKaz 😛

🔥 Supply chain атака на LiteLLM: один pip install — и все секреты утекли

24 марта в PyPI были загружены отравленные версии LiteLLM (1.82.7 и 1.82.8). Простой pip install litellm — и с машин сливались: SSH-ключи, креды AWS/GCP/Azure, kubeconfig, git-токены, все переменные окружения (читай — все API-ключи), история шелла, крипто-кошельки, SSL-сертификаты, секреты CI/CD, пароли от баз данных. Пост Andrej Karpathy об этом посмотрели 62 млн (!) раз, так как его ретвитнул Илон Маск.

⚪️ Что произошло

Группировка TeamPCP сначала скомпрометировала Trivy GitHub Action, через него украла PyPI-токен мейнтейнера LiteLLM и опубликовала вредоносные версии. Малварь внедрили через .pth-файл, который выполняется при старте любого Python-процесса — даже если вы не импортируете библиотеку.

LiteLLM — это ~3,4 миллиона скачиваний в день. Но страшнее другое: это транзитивная зависимость. Если ваш проект зависит от dspy, какого-нибудь MCP-плагина или LLM-оркестратора, который тянет litellm — вы тоже под ударом. Вы могли даже не знать, что litellm у вас установлен.

⚪️ Как нашли

Малварь содержала баг: .pth-файл порождал дочерние процессы, которые при инициализации снова запускали тот же .pth, создавая экспоненциальную форк-бомбу, которая роняла машину. Исследователь из FutureSearch заметил, что у него закончилась RAM после обновления MCP-плагина в Cursor. Если бы атакующие не допустили эту ошибку — обнаружение могло затянуться на дни или недели.

Отравленные версии провисели на PyPI около 3 часов. При таком объёме скачиваний — этого более чем достаточно.

⚪️ Что делать

Проверьте: pip show litellm | grep Version. Если видите 1.82.7 или 1.82.8 — считайте машину полностью скомпрометированной. Ротируйте все секреты: SSH, облачные токены, kubeconfig, API-ключи, пароли БД. Проверьте kube-system на подозрительные поды (node-setup-*).

⚪️ Выводы

Это не единичный инцидент — это третий удар в координированной кампании TeamPCP: сначала Trivy, затем Checkmarx KICS, теперь LiteLLM.

Supply chain атаки — самый страшный вектор в современном софте. Каждый pip install может тянуть отравленный пакет из глубины дерева зависимостей. Классическая инженерная мантра «не изобретай велосипед, используй библиотеку» нуждается в переосмыслении. Пинните версии, проверяйте чексуммы, минимизируйте зависимости.

@DevOpsKaz 😛

🔥 Первый спикер Cloud Native Community Day 3 апреля — Мирас Байгашев, DevOps-инженер в Core 24/7

Если вы работаете с Kubernetes, то знаете боль: аннотации Ingress растут, конфиги становятся непереносимыми между контроллерами, а canary-деплой без костылей невозможен. Плюс Ingress NGINX официально уходит в архив — без обновлений безопасности и багфиксов.

Gateway API — это не просто «Ingress v2». Это другая архитектура: разделение ролей между платформой и командами, нативный traffic splitting, поддержка gRPC и TCP без единой аннотации.

Мирас расскажет:

— как устроены сервисы и ингрессы «изнутри»
— какие конкретные проблемы решает переход на Gateway API
— AI трафик: инференс и межагентное взаимодействие через Gateway API

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше.

👉 Вход бесплатный — регистрация (login to RSVP)

@DevOpsKaz 😛

🔥 Инструмент для диагностики и observability приложений в Kubernetes

Podtrace работает на базе eBPF, «приклеивается» напрямую к указанному поду (или нескольким) и в реальном времени собирает информацию сразу на нескольких уровнях:

⚪️ Ядро и ОС: TCP/UDP-соединения (RTT, ретрасмиссии, состояние), файловые операции (read/write/fsync + пути), page faults, OOM, scheduling, lock contention, syscalls
⚪️ Прикладной уровень: HTTP, DNS, PostgreSQL, MySQL, Redis, Memcached, gRPC, Kafka, FastCGI/PHP-FPM и TLS-handshake. Всё это через uprobes/kprobes без изменения кода
⚪️ Distributed tracing: автоматически вытаскивает trace-контекст (W3C, B3, Splunk) и коррелирует события между сервисами. Можно экспортировать в OpenTelemetry (OTLP), Jaeger или Splunk HEC.

Дополнительно:

➖ Режим diagnose — собирает данные за заданное время и выдаёт красивый summary-отчёт.
➖ Alerting (webhook, Slack, Splunk) с дедупликацией и rate limiting.
➖ Prometheus-метрики + готовый Grafana-дашборд.
➖ Автоматическое обнаружение USDT-точек в бинарниках.
➖ Редактирование PII по regex-правилам.

⚡️ Всё запускается одной командой, без предварительной настройки подов и sidecar’ов.

@DevOpsKaz 😛

🔥 Второй спикер Cloud Native Community Day 3 апреля — Абдухаликов Асир, DevOps Engineer | SRE | Cloud Engineer

Когда начинается отладка сетевых политик в Kubernetes, traffic shaping или мультикластерная связность, у многих появляются вопросы. CNI (Container Network Interface) — это слой, который решает, как поды вообще разговаривают друг с другом. От выбора CNI зависит: видимость трафика, сетевые политики, производительность и то, что вы сможете сделать с сетью завтра.

Асир разберёт:

➖ как CNI устроен изнутри: что происходит между «под запущен» и «pod-to-pod трафик идёт»
➖ почему Cilium — это не просто «ещё один CNI», а другой уровень наблюдаемости и контроля
➖ eBPF под капотом: как Cilium обходит iptables и что это даёт на практике
➖ сетевые политики без боли: L3/L4/L7 в одном месте

Если вы устали объяснять «что происходит в сети» по логам приложения — этот доклад про то, как видеть трафик напрямую.

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше.

👈 Вход бесплатный — регистрация (login to RSVP)

@DevOpsKaz 😛

🚀 Подкаст про CI/CD — как раз под обед

Что происходит, когда нужно настроить CI/CD для 10 000 разработчиков, которые коммитят в одну ветку и хотят выпускать релизы каждый час? Звучит пугающе. Однако есть люди, которые построили такое и живут с этим каждый день. Подкаст с этими людьми мы и предлагаем.

👈 Слушать подкаст

Про что:

⚪️Почему обычный CI/CD разваливается, когда команда перерастает сотню человек
⚪️Монорепа на десятки тысяч разработчиков — как не скачивать весь мир себе на диск
⚪️Flaky-тесты и почему это враг номер один для доверия к пайплайну
⚪️Зачем нужна своя билд-система и при чём тут виртуальная файловая система
⚪️Агрессивный откат — это не авария, а штатная стратегия
⚪️Что из практик гигантов можно утащить к себе, даже если у вас не миллион серверов

@DevOpsKaz 😛

🔥 Алгоритмы балансировки нагрузки

Даем шпаргалку по балансировке трафика между серверами, которая помогает разделять трафик, масштабировать приложения, улучшать производительность и доступность. Алгоритм выбирает, на какой сервер уйдёт следующий запрос. Выбор зависит от архитектуры приложения и характера нагрузки.

⚪️Round Robin

Запросы идут по очереди: сервер A → B → C → A → ... Подходит, если серверы одинаковые по мощности, а запросы примерно равной длительности. REST API без состояния — типичный кейс.

⚪️Stickу Round Robin

Это Round Robin с памятью. Sticky добавляет привязку: первый запрос от клиента распределяется по Round Robin, но потом все следующие его запросы идут на тот же сервер. Обычно через cookie или IP. Нужно там, где сессия хранится на сервере — старые PHP-приложения, корзины без Redis, любой стейт in-memory. Если такого клиента пустить на другой сервер, он потеряет сессию и вылетит из-под авторизации.

⚪️Weighted Round Robin

То же, что Round Robin, но с весами. Сервер с весом 0,8 получает 80% запросов. Используют при постепенном масштабировании: новый сервер входит с весом 0,1, растёт по мере проверки.

⚪️IP / URL Hash

Клиент по IP-адресу привязывается к конкретному серверу. Пока IP не меняется — пользователь всегда попадает на один бэкенд. Нужен, если сессия хранится in-memory (старые PHP-приложения, некоторые WebSocket-серверы). У URL Hash та же логика, но хэш считается по URL. Полезно для кэширующих серверов: один и тот же URL всегда идёт на один сервер — кэш не дублируется.

⚪️Least Connections

Новый запрос идёт на сервер с наименьшим числом активных соединений. Работает там, где запросы живут по-разному: один занимает 10 мс, другой — 30 секунд. WebSocket-соединения, SSH-туннели — сюда.

⚪️Least Response Time

Трафик направляется туда, где сервер отвечает быстрее прямо сейчас. Балансировщик замеряет latency в реальном времени. Полезно при неравномерной нагрузке: перегретый сервер получает меньше запросов, пока не восстановится.

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

👈 Читать статью

@DevOpsKaz 😛

🔥 Третий спикер Cloud Native Community Day 3 апреля — Иван Кабанов, Solutions Architect, Yandex Cloud

Тема доклада: О чем мы говорим, когда говорим об Observability

В докладе Иван разберет, что на практике означает Observability и почему классический стек из разрозненных инструментов (Prometheus, лог-агенты, трейсинг) перестаёт справляться с ростом сложности систем. Поговорим про три столпа — мониторинг, логгинг и трейсинг — и как объединение телеметрии в едином контексте помогает быстрее находить причины инцидентов и работать с SLO.

Разберём, как устроена Observability Platform в Яндексе: какие архитектурные решения позволяют работать с метриками, логами и трейсами в одной системе без ручной «склейки», и как выглядит пайплайн сбора и обработки телеметрии на базе OpenTelemetry.

Отдельно обсудим мониторинг AI/LLM-агентов: какие данные попадают в трейсы и как с помощью OpenTelemetry наблюдать поведение агентов — от латентности и ошибок до качества ответов.

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше.

Мест уже нет, но мы обязательно поделимся докладами с сообществом. Следите за новостями — скоро будем делать более масштабные митапы.

@DevOpsKaz 😛

🔥 Какое облако выбрать для бизнеса в Казахстане?

Мы в Core 24/7 провели независимое исследование — и создали гайд, который поможет сориентироваться на рынке облачных провайдеров (отечественных и зарубежных). Заходите, смотрите, сохраняйте в закладки 🫡

👈 Смотреть гайд

Руководство интерактивное — можно выбрать для сравнения 2 или более провайдера или сразу все.

Что внутри:

⚪️Обзор ключевых характеристик
⚪️Сравнение по возможностям и сервисам
⚪️Сценарии применения
⚪️Примерная стоимость

Core 24/7 — сертифицированный партнёр AWS, Azure, GCP, Yandex Cloud, VK Cloud и Oracle Cloud в Казахстане. Мы помогаем бизнесу выбрать облако под их задачу, мигрировать и настроить с максимальной эффективностью.

@DevOpsKaz 😛

🔥 Cloud Native Community Day — уже завтра

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше. Ждем по адресу 3 апреля к 17:00.

Первый спикер — Мирас Байгашев, «Ingress умер, да здравствует Gateway API»

Второй спикер — Абдухаликов Асир, «CNI в Kubernetes, ценность Cilium и как с ним работать»

Третий спикер — Иван Кабанов, «О чем мы говорим, когда говорим об Observability»

⚪️ Расписание:

17:00-17:30 — регистрация гостей + кофе-брейк
17:30-18:10 — спикер 1 + вопросы
18:10-18:50 — спикер 2 + вопросы
18:50-19:30 — спикер 3 + вопросы
19:30-21:00 — афтепати на крыше с пиццей

🎟️ Ждем всех, кто зарегистрировался ранее.

@DevOpsKaz 😛

🔥 Как OpenAI масштабировала систему мониторинга, чтобы справиться с ростом нагрузки

Не устаем повторять, что масштабирование — это не только про инфру, но и про культуру. OpenAI удалось выжить в период взрывного роста благодаря:

⚪️Выбору правильных инструментов
⚪️Жесткой оптимизации
⚪️Отношению к мониторингу как к сервису, который должен быть удобным и эффективным для каждого в компании

Когда ChatGPT стал популярным, OpenAI столкнулась с проблемой: их система мониторинга на базе Prometheus начала давать сбои под весом миллиардов временных рядов (time series).

Что предприняла компания:

➖ Переход на VictoriaMetrics, которая оказалась более эффективной в использовании дискового пространства и ОЗУ по сравнению с альтернативами.

➖ «Наблюдаемость как продукт» помогла команде мониторинга относиться к своим инструментам не просто как к «поддержке», а как к внутреннему продукту для разработчиков.

➖ Если разработчикам сложно строить графики или понимать алерты, система бесполезна. Команда Observability упростила процесс добавления новых метрик, сохранив при этом контроль над их качеством.

➖ Компания осознала, что хранить все данные — слишком дорого и неэффективно. Те метрики, к которым никто не обращался в течение 30 дней, можно безболезненно удалять или перестать собирать.

➖ Использование сэмплирования для логов и трассировок, потому что просто нет нужды сохранять 100% запросов в системе трассировки при таких масштабах. Достаточно сохранять небольшую часть успешных запросов и 100% ошибок.

👈 Читать детальный разбор

@DevOpsKaz 😛

🔥 Новости мира DevOps, которые вы могли пропустить

⚪️ Terragrunt v1.0

Из беты вышел уже популярный open-source инструмент, который представляет собой «тонкую обертку» для Terraform. Terragrunt помогает масштабировать управление IaC, делая код более чистым, поддерживаемым и соответствующим принципу DRY.

⚪️ Tekton стал incubating проектом в CNCF

Это набор готовых инструментов для систем с CI/CD. Tekton помогает строить, тестировать и развертывать в облаках или on-premise. Работает внутри кластеров Kubernetes и не нуждается в физическом сервере.

⚪️ Атака на Trivy — еще не конец

Последствия прошлой атаки все еще ощущаются. Технологические гиганты подвергаются атаке со стороны компрометированного Trivy GitHub Action. На днях злоумышленники похитили исходный код компании Cisco.

@DevOpsKaz 😛