DevOps

💻Мультирегиональная репликация Apache Kafka: кластерные топологии Неплохая статья о том, какую топологию может иметь кластер Apache Kafka при межрегиональной репликации по нескольким ЦОД и как это реализовать. Плюс описывается, чем брокеры-наблюдатели отличаются от подписчиков в Confluent Server и при чем здесь конфигурация подтверждений acks в приложении-продюсере. Для репликации в нескольких регионах кластер Kafka может иметь следующую топологию: ⏩растянутые кластеры (stretched clusters), когда один кластер Kafka устанавливается в нескольких ЦОД. При этом используется протокол синхронной репликации Kafka. ⏩связанные кластеры (connected clusters) с асинхронной репликацией в нескольких регионах. В этом случае может использоваться внешняя система для копирования данных из одного или нескольких кластеров в другой. Преимущество растянутого кластера в том, что он сохраняет смещения, а также обеспечивает быстрое аварийное восстановление и автоматическое переключение клиента при сбое без дополнительного кода. 📎Статья @DevOPSitsec

🖥Уязвимость в runc, позволяющая выбраться из контейнеров Docker и Kubernetes ⏩В инструментарии для запуска изолированных контейнеров runc, применяемом в Docker и Kubernetes, найдена уязвимость CVE-2024-21626, позволяющая получить доступ к файловой системе хост-окружения из изолированного контейнера. В ходе атаки злоумышленник может перезаписать некоторые исполняемые файлы в хост-окружения и таким образом добиться выполнения своего кода вне контейнера. ⏩Уязвимость устранена в выпуске runc 1.1.12. В runtime LXC, crun и youki, альтернативных runc, проблема не проявляется. ⏩В случае использования инструментариев Docker или Kubernetes атака может быть совершена через подготовку специально оформленного образа контейнера, после установки и запуска которого из контейнера можно обратиться к внешней ФС. При использовании Docker имеется возможность эксплуатации через специально оформленный Dockerfile. Уязвимость также может быть эксплуатирована в случае запуска в контейнере процессов командой runc exec через привязку рабочего каталога к пространству имён хостового окружения ⏩Уязвимость вызвана утечкой внутренних файловых дескрипторов. Перед запуском кода внутри контейнера в runc выполняется закрытие файловых дескрипторов при помощи флага O_CLOEXEC. Однако, после последующего выполнения функции setcwd() остаётся открытым файловый дескриптор, указывающий на рабочий каталог и продолжающий оставаться доступным после запуска контейнера. Предложено несколько базовых сценария атаки на хост-окружение, используя оставшийся файловый дескриптор ⏩Например, атакующий может указать в образе контейнера параметр process.cwd, указывающий на "/proc/self/fd/7/", что приведёт к привязке к процессу pid1 в контейнере рабочего каталога, находящегося в пространстве монтирования хост-окружения. Таким образом, в образе контейнера можно настроить запуск "/proc/self/fd/7/../../../bin/bash" и через выполнение shell-скрипта перезаписать содержимое "/proc/self/exe", которое ссылается на хостовую копию /bin/bash. 📎Читать подробнее @DevOPSitsec

🖥Как устроены конвейеры CI/CD💻 Схема взаимодействия контейнерных технологий в рамках работы с привычными инструментами может быть представлена так: 1️⃣Утилита podman с помощью Libpod API обращается к библиотеке libpod, которая вызывает низкоуровневый container runtime (по умолчанию утилиту runc) containers/podman Podman Commands 2️⃣Утилита docker с помощью Docker API вызывает сервис dockerd docker/cli Docker CLI reference Docker architecture Docker API 3️⃣Сервис dockerd вызывает сервис containerd Dockerd reference 4️⃣Сервис containerd вызывает низкоуровневый container runtime (по умолчанию утилиту runc) containerd/containerd Containerd Scope and principles 5️⃣Сервис kubelet с помощью протокола CRI вызывает сервис container runtime (например, containerd или crio) Container Runtime Interface Container Runtimes CRI: the Container Runtime Interface 6️⃣Сервис containerd вызывает низкоуровневый container runtime (по умолчанию runc) Containerd CRI 7️⃣Сервис cri-o вызывает низкоуровневый container runtime (по умолчанию runc) cri-o/cri-o 8️⃣Утилита OCI container runtime (по умолчанию runc): 🔘runc с помощью библиотеки libcontainer создает контейнер по runtime-spec, взаимодействуя с подсистемами ядра Linux – пространствами имен (namespaces) и контрольными группами (cgroups) opencontainers/runc runc man opencontainers/runc/libcontainer 🔘crun создает контейнер по runtime-spec, взаимодействуя с подсистемами ядра Linux – пространствами имен (namespaces) и контрольными группами (cgroups) containers/crun @DevOPSitsec

📌CI/CD pipeline с помощью Jenkins Отличное видео, в нём говорится про: ⏩Создание образа Docker и отправка его в Docker Hub ⏩Развертывание образа Docker в кластере Kubernetes ⏩Создание проекта и настройка Jenkins ⏩Сборка и развертывание в Kubernetes ⏩Тестирование приложения 📎Кликабельный план ролика 📎Видео @DevOPSitsec

💻Wasm vs Docker containers vs Kubernetes vs serverless: битва за первенство Держите годную статью О чём она: ⏩WebAssembly (Wasm) — новая технология, которая может заменить контейнеры в некоторых сценариях использования. ⏩Wasm имеет преимущества в размере, скорости, безопасности и переносимости. ⏩Контейнеры имеют экосистему, такую как Kubernetes, которая предоставляет множество инструментов и сервисов. • Wasm может стать жизнеспособной альтернативой контейнерам, если создаст свою экосистему или станет частью экосистемы Docker и Kubernetes. ⏩Wasm может быть использован в serverless-сервисах и на edge-устройствах, где существуют проблемы с размером, скоростью, безопасностью и экосистемой. ⏩Выбор использования Wasm зависит от конкретных потребностей и сценариев использования. 📎А вот сама статья @DevOPSitsec

🔥Лучшие бесплатные ресурсы для изучения этичного хакинга и кибербезопасности 🔗Смотреть Linux Academy

⭐️ Проекты с открытым исходным кодом, которые изменили мир ▪Веб: Node.js, React, Apache ▪ Базы данных: PostgreSQL, Redis, Elasticsearch ▪ Инструменты разработчика: Git, VSCode, Jupyter Notebook ▪ ML и Big Data: Tensorflow, Apache Spark, Kafka ▪ DevOps: Docker, Kubernetes, Linux @DevOPSitsec

💻Будущее Kubernetes и DevOps: строим прогнозы на 10 лет Полезная статья, в ходе которой опросили инженеров «Фланта» и экспертов из индустрии, как, по их мнению, будут развиваться Kubernetes, DevOps, Ops и Cloud Native-экосистема в ближайшее десятилетие. Цель статьи — спрогнозировать будущее на основе тенденций в настоящем. Вот вопросы, которые освещаются: ⏩Будет ли еще популярен Kubernetes через 5–10 лет? Какие технологии могут прийти ему на смену? Какие вызовы ему придется решать? ⏩Будет ли ещё DevOps? Как изменится его понимание? Как изменится культурный аспект, стоящий за DevOps-практиками? Как могут измениться сами практики? ⏩Какие интересные, необычные Ops'ы могут появиться? Какие задачи они будут решать? ⏩Что станет с Cloud Native-экосистемой и программами внутри нее? Какие проблемы она должна будет научиться решать? Какие новые программы могут появиться в ней? Что станет с облаками? Как они изменятся? Придет ли какая-то другая технология на смену облакам, и если да, то какой примерно она будет? 📎Статья @DevOPSitsec

💻Лучшие практики работы с Kubernetes Держите, остаётся самое сложное — следовать этим практикам) 📎А вот полезная статья в тему, где подробно рассказывается о каждом из правил @DevOPSitsec

💻Flagger — инструмент для автоматизации развёртывания приложений на Kubernetes • Flagger автоматизирует процесс выпуска приложений на Kubernetes, снижая риск внедрения новой версии. • Flagger реализует стратегии развертывания, включая Canary, A/B тестирование и Blue/Green deployments. • Flagger интегрируется с различными входными контроллерами Kubernetes и решениями для мониторинга. • Является проектом фонда облачных вычислений Native Computing Foundation и частью семейства инструментов GitOps от Flux. • Документация по флаггеру доступна на fluxcd.io/flagger. • Flagger отслеживает конфигурационные карты и секреты и запускает анализ Canary при изменении этих объектов. 🖥GitHub⭐️4.7K Лицензия Apache 2.0 @DevOPSitsec

📌20 полезных, но малоиспользуемых команд Git Держите, это кликабельный список: ⏩Git Web — открыть встроенный графический интерфейс ⏩Git Notes — прикрепить дополнительную информацию к коммитам ⏩Git Bisect — дебажить как про ⏩Git Grep — найти что угодно ⏩Git Archive — сжать проект для шеринга ⏩Git Submodules — импортировать другие репозитории в ваш ⏩Git Bugreport — скомпилировать баг-репорт с информацией о системе ⏩Git Fsck — проверить и восстановить недоступные объекты ⏩Git Stripspace — удалить пробелы в конце текста ⏩Git Diff — сравнить изменения между двумя файлами ⏩Git Hooks — выполнить скрипт при запуске команды git ⏩Git Blame — показать, кто написал данную строку ⏩Git Large File Storage — сохранить большие файлы в git ⏩Git Garbage Collection — оптимизировать git-репо ⏩Git Show — легко просмотреть любой объект git ⏩Git Describe — дать читаемое имя на основе последнего тега ⏩Git Tag — создать метки версий в определенных точках ⏩Git Reflog — список всех действий, выполненных над репозиторием ⏩Git Log — просмотреть журнал коммитов и диаграммы ветвей ⏩Git Cherry Pick — вытащить фичу в вашу ветку ⏩Git Switch — быстро переключиться между ветками Пользуйтесь) @DevOPSitsec

🌟Вышел WingetUI (UnigetUI) 3.0 ⏩13 марта 2024 года состоялся релиз WingetUI (UnigetUI) 3.0. Это графический инструментарий с открытым исходным кодом, который позволяет устанавливать, удалять и обновлять приложения на устройствах Windows с помощью наиболее распространённых консольных менеджеров (CLI) для Windows 10 и Windows 11, включая Windows Package Manager (winget), Scoop и Chocolatey, а также Pip, Npm, .NET Tool и PowerShell Gallery. ⏩Фактически WingetUI превратился в поддержку различных менеджеров пакетов, а не только Winget, что привело к тому, что имя WingetUI сбивает с толку новых пользователей и не отражает основную суть этого приложения. В настоящее время в WingetUI доступно более 14 тыс. пакетов (Winget, Scoop и Chocolatey). Автор проекта Марти Климент пояснил, что он с каждым днём наблюдает, как пользователи всё чаще путают WingetUI и winget, что вполне ожидаемо, учитывая небольшую разницу между этими двумя названиями. Поэтому WingetUI скоро будет переименован в UnigetUI. @DevOPSitsec