В этом обзоре мы расскажем о новых проектах, которые появились в CNCF в 2024 году в категориях Runtime и App Definition & Development (Проектирование и разработка приложений). Эти проекты предлагают свежие решения для разработки и управления облачными приложениями. Давайте посмотрим, что нового и интересного они предлагают.

В статье разберём следующие проекты:

• OpenEBS;

• openGemini;

• OVN-Kubernetes;

• Radius;

• Score;

• Shipwright;

• Stacker;

• youki.

OpenEBS

• Local PV HostPath — замена для In-Tree Kubernetes CSI HostPath, содержит всё, что есть в Kubernetes HostPath, плюс динамическое выделение ресурсов, нулевая конфигурация и отсутствие драйвера CSI;

• Local PV ZFS — механизм хранения для управляемого внутреннего хранилища ZFS;

• Local PV LVM — механизм хранения для управляемого внутреннего хранилища LVM2;

• Local PV Rawfile — экспериментальный движок для использования файла экстентов в качестве блочного хранилища;

• Replicated PV Mayastor — реплицированное корпоративное хранилище общего назначения.

Основные возможности:

• постоянные динамически выделяемые тома хранилища с сохранением состояния для Kubernetes;

• высокопроизводительный транспорт хранения NVMe-oF и NVMe/RDMA, оптимизированный для твердотельных флеш-носителей;

• блочные устройства, LVM, ZFS, ext2/ext3/ext4, XFS, BTRFS;

• полностью облачная декларативная платформа хранения данных K8s;

• кластерная блочная структура vSAN, которая предоставляет контейнерам/подам отказоустойчивый доступ к хранилищу во всём кластере;

• локальные для узла K8s PV и n-way реплицированные K8s PV;

• возможность развёртывания локально и в облаке: (AWS EC2/EKS, Google GCP/GKE, Azure VM/AKS, Oracle OCI, IBM/RedHat OpenShift, Civo Cloud, Hetzner Cloud и др.);

• возможности управления данными корпоративного уровня, такие как снапшоты, клоны, реплицированные тома, DiskGroups, VolumeGroups, Aggregates, RAID.

Особенности:

• высокопроизводительный стек хранения SPDK (проект NVMe с открытым исходным кодом, инициированный Intel);

• современный интерфейс ввода-вывода IO_Uring Linux Kernel Async polling-mode (самый быстрый возможный режим ввода-вывода ядра);

• встроенные возможности для RDMA и ввода-вывода с нулевым копированием;

• хранилище блоков NVMe-oF TCP;

• репликация томов на уровне блоков;

• управление данными на основе логических томов и Diskpool;

• встроенное высокопроизводительное хранилище Blobstore;

• встроенное тонкое выделение ресурсов на уровне блоков;

• встроенные снапшоты и клоны на уровне блоков.

OpenEBS управляет хранилищем, доступным на каждом из узлов Kubernetes, и использует это хранилище для предоставления локальных или реплицированных постоянных томов для рабочих нагрузок с отслеживанием состояния:

В случае локальных томов:

• может создавать постоянные тома или использовать подкаталоги в hostPath, использовать локально подключённое хранилище или разреженные файлы поверх существующего стека LVM или ZFS;

• локальные тома монтируются непосредственно в Stateful Pod, без дополнительных накладных расходов со стороны OpenEBS на пути данных, что снижает задержку;

• предоставляет дополнительные инструменты для мониторинга, резервного копирования/восстановления, аварийного восстановления, снапшотов при поддержке стека LVM или ZFS, планирования на основе ёмкости и многого другого.

В случае реплицированных томов:

• OpenEBS Replicated Storage создаёт целевой объект NVMe, доступный по протоколу TCP, для каждого постоянного тома;

• Stateful Pod записывает данные в целевой объект NVMe-TCP, который синхронно реплицирует данные на несколько узлов в кластере. Сам движок OpenEBS развёртывается как под и оркестрируется Kubernetes. Когда узел, на котором запущен Stateful Pod, выходит из строя, под будет перепланирован на другой узел в кластере, и OpenEBS предоставляет доступ к данным, используя доступные копии данных на других узлах.

OpenEBS состоит из множества компонентов, которые можно сгруппировать в две основные категории:

• движки данных;

• плоскость управления.

OpenEBS использует модель микросервисов для обработки данных, разделяя функциональность на различные уровни. Это обеспечивает гибкость при замене уровней и готовность механизмов обработки данных к будущим изменениям в технологиях приложений и центрах обработки данных. Основные уровни показаны на схеме ниже:

Плоскость управления в контексте OpenEBS — это набор инструментов или компонентов, развёрнутых в кластере и отвечающих за:

• управление хранилищем, доступным на рабочих узлах Kubernetes;

• настройку и управление механизмами обработки данных;

• взаимодействие с CSI для управления жизненным циклом томов;

• взаимодействие с CSI и другими инструментами, выполняющими такие операции, как снапшоты, клонирование, изменение размера, резервное копирование, восстановление и т. д.;

• интеграцию с другими инструментами, такими как Prometheus/Grafana, для телеметрии и мониторинга;

• интеграцию с другими инструментами для отладки, устранения неполадок или управления журналами.

Компоненты системы можно установить в кластер с помощью Helm-чарта. Все функции управления в OpenEBS могут быть реализованы посредством kubectl, поскольку OpenEBS использует кастомные ресурсы для управления всеми своими конфигурациями и составления отчётов о состоянии компонентов.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

openGemini

openGemini — это облачная распределённая база данных временных рядов. Она предназначена для хранения и анализа больших объемов телеметрических данных. По сравнению с другими базами данных временных рядов openGemini имеет следующие преимущества:

• Быстрое и эффективное хранение и запрос данных обеспечиваются благодаря автоматическому секционированию, методам хранения на основе LSM и улучшенной разработке процессов обработки данных.

• Архитектура MPP, поддержка развёртывания распределённого кластера и возможность гибкого расширения по мере роста бизнеса для удовлетворения более высоких требований к нагрузке.

• Новый механизм хранения решает проблемы чрезмерного использования памяти индекса и низкой производительности чтения и записи.

• Встроенная платформа анализа данных на основе искусственного интеллекта обеспечивает возможности обнаружения аномалий в реальном времени для данных временных рядов и реализует управление замкнутым циклом от хранения данных до анализа данных.

• Метрики, журналы и трассировки хранятся в openGemini, что упрощает хранение и анализ.

• Хранилище на основе столбцов обеспечивает эффективный алгоритм сжатия данных: при том же объёме данные требуют всего 1/20 затрат реляционных баз данных и 1/10 затрат NoSQL.

openGemini использует архитектуру MPP:

Она состоит из трёх компонентов:

• ts-sql — унифицированный интерфейс чтения и записи данных:

  • во время записи проверяет формат полученных данных, затем хеширует и распределяет их в соответствии с именем временной шкалы, а затем пересылает данные в соответствующий узел ts-store для хранения;

  • во время запроса доступа к данным генерирует распределённый план запроса и распределяет каждый план подзапроса по каждому узлу ts-store, а затем суммирует данные и возвращает их клиенту.

• ts-meta — управляет метаданными, такими как базы данных, таблицы, разделы данных, политики хранения и узлы кластера в системе баз данных;

• ts-store — обеспечивает эффективное хранение данных и запросов, использует LSM Tree, и данные записываются в дополненном виде.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

OVN-Kubernetes

Основные функции и возможности:

• Соответствие основным сетевым стандартам Kubernetes:

  • создаёт сетевое взаимодействие подов, включая распределение IP-адресов (IPAM) и виртуальный интерфейс Ethernet (veth) для пода;

  • реализует сетевые функции на основе наложения программ для кластеров Kubernetes с использованием туннелей Generic Network Virtualization Encapsulation (GENEVE), обеспечивающих связь между подами;

  • реализует Services Kubernetes и EndpointSlices через балансировщики нагрузки OVN;

  • реализует сетевые политики Kubernetes и административные сетевые политики с помощью списков контроля доступа (ACL) OVN;

  • поддерживает кластеры IPv4/IPv6 Dual-Stack.

• Контроль выходного трафика кластера:

  • несколько Multiple External Gateways (MEG) позволяют использовать несколько динамически или статически назначаемых выходных шлюзов следующего перехода с использованием функций маршрутизации OVN ECMP;

  • реализует Quality of Service (QoS) Differentiated Services Code Point (DSCP) для трафика, исходящего из кластера через OVN QoS;

  • позволяет отправлять исходящий трафик из рабочих нагрузок кластера, используя настроенный администратором исходный IP-адрес (EgressIP), за пределы кластера с применением политик логического маршрутизатора OVN и трансляций сетевых адресов;

  • обеспечивает возможность отправки исходящего трафика из рабочих нагрузок кластера с использованием IP-адреса балансировщика нагрузки сервиса (EgressService) за пределы кластера (также с применением политик логического маршрутизатора OVN и трансляций сетевых адресов);

  • позволяет ограничивать исходящий трафик от рабочих нагрузок кластера (исходящий межсетевой экран) с помощью списков контроля доступа OVN.

• Расширенные сетевые функции:

  • реализует гибридную сеть для поддержки смешанных кластеров Windows/Linux с использованием туннелей VXLAN;

  • обеспечивает многоадресную IP-рассылку с использованием отслеживания и ретрансляции OVN IGMP;

  • обеспечивает возможность разгрузки сетевых задач с ЦП на сетевую карту с помощью OVS Hardware Offload, тем самым повышая производительность data-plane;

  • добавляет поддержку создания вторичных и локальных сетей в дополнение к основным сетям по умолчанию.

Существуют два режима развёртывания ovn-kubernetes, в зависимости от которых архитектура кардинально отличается:

• режим по умолчанию (архитектура централизованной плоскости управления);

• режим межсоединения (архитектура распределённой плоскости управления).

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

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

На каждом узле присутствуют:

• node-local-switch — все порты логического коммутатора для созданных на узле подов привязаны к этому коммутатору. Также на нём размещены балансировщики нагрузки, которые отвечают за DNAT-распределение трафика сервиса;

• distributed-ovn-cluster-router — отвечает за туннелирование оверлейного трафика между узлами, а также за маршрутизацию трафика между коммутаторами узлов и маршрутизаторами шлюзов;

• distributed-Join-Switch — подключает маршрутизатор кластера к маршрутизаторам шлюза;

• node-local-gateway-router — отвечает за маршрутизацию трафика «север-юг» и подключает коммутатор присоединения к внешнему коммутатору, а также размещает балансировщики нагрузки, которые отвечают за DNAT-распределение трафика сервиса;

• node-local-external-switch — подключает шлюз-маршрутизатор к внешнему мосту.

Архитектура межсоединений выглядит следующим образом (предполагается, что каждый узел находится в собственной зоне):

На каждом узле присутствуют те же компоненты, что и при централизованной архитектуре, плюс transit-switch, который распределяется по узлам в кластере и отвечает за маршрутизацию трафика между различными зонами.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Radius

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

Ключевые особенности Radius:

• Совместная работа в команде — приложения и среды Radius позволяют разработчикам работать с отделом эксплуатации над определением и доставкой приложений.

• Рецепты инфраструктуры — по умолчанию заменяемая инфраструктура, соответствующая лучшим практикам организации и ИТ-политике.

• График приложения — понимание того, как взаимосвязаны службы и инфраструктура в приложении.

• Нейтральность к облаку — развёртывание в средах разработки, локальных и облачных средах с единообразным интерфейсом.

• Поэтапное внедрение — интеграция Radius в существующие рабочие процессы и существующие каталоги шаблонов Infrastructure-as-Code.

Radius состоит из набора инструментов и сервисов:

Radius предоставляет API на основе HTTP и вспомогательные инструменты, которые могут развёртывать и управлять облачными приложениями, а также локальными или облачными ресурсами. Компоненты API на стороне сервера также называют плоскостью управления. API Radius может размещаться внутри кластера Kubernetes или как автономный набор процессов или контейнеров. Инструменты, которые используются с Radius, например утилита командной строки rad, взаимодействуют с API.

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

Общая архитектура Radius состоит из трёх частей:

• API общего управления ресурсами;

• поставщики ресурсов для облачных приложений;

• инструменты (rad, Bicep) для развёртывания и управления приложениями с использованием API.

Radius API использует централизованную архитектуру hub-and-spoke. Он предоставляет единую точку входа для аутентификации, авторизации, маршрутизации и других задач обслуживания. Весь HTTP-трафик в Radius API проходит через эту центральную точку, чтобы его можно было проверить перед направлением в соответствующий микросервис поставщика ресурсов.

Служба, которая отвечает за эту центральную функциональность, называется Universal Control-Plane (UCP). UCP получает весь входящий в Radius API HTTP-трафик и либо самостоятельно обслуживает запрос и формирует ответ, либо перенаправляет запрос поставщику ресурсов. UCP также является центральной точкой для расширяемости: каждый поставщик ресурсов регистрируется централизованно, поэтому UCP знает, куда отправлять запросы для этого типа ресурсов.

UCP — это масштабируемый REST API, который может работать как с одним глобальным сегментом, так и с использованием регионального сегментирования. UCP основан на принципах проектирования плоскости управления Azure Resource Manager (ARM), но обобщается для работы в нескольких облаках и системах. Кодовая база UCP полностью открыта и была создана с нуля в рамках проекта Radius. UCP написан на Go.

Radius предлагает следующих поставщиков ресурсов в установке по умолчанию:

• Applications.Core — основные ресурсы приложения, включая само приложение, контейнеры, шлюзы и маршруты.

• Applications.Dapr — интеграция с моделью программирования Dapr. Поддерживает управление строительными блоками и конфигурацией Dapr.

• Applications.Datastores — абстракции для хранилищ данных, которые можно использовать в приложении.

• Applications.Messaging — абстракции для систем обмена сообщениями, которые можно использовать в приложении.

• Bicep.Deployments — функциональность для обработки развёртываний Bicep.

Поставщики ресурсов Applications.* реализуют бо́льшую часть функциональных возможностей Radius, ориентированных на пользователя, включая:

• создание и управление ресурсами платформы, используемыми для запуска приложения, например развёртывания и службы Kubernetes;

• ответы на запросы из CLI, например список всех приложений, отображение конфигурации контейнера;

• хранение и извлечение информации о зависимостях, такой как строки подключения, имена хостов и пароли;

• реализация рецептов по созданию облачной инфраструктуры.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Score

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

Score запускает одну и ту же рабочую нагрузку на разных технологических стеках.

Файл score.yaml можно расширить и настроить в соответствии с вашими потребностями. Спецификация Score оставляет место для переопределений, специфичных для среды, а также для расширений, специфичных для платформы, которые позволяют перечислять дополнительные свойства или требования.

Score позволяет разработчикам определять ресурсы, необходимые для их рабочих нагрузок, декларативным способом. Например, о том, что рабочей нагрузке необходимо прослушивать порт для получения запросов, объявляется один раз. И больше не нужно беспокоиться о том, где и как определён точный порт, например, в удалённой среде Kubernetes. Объявляя, «что» рабочей нагрузке необходимо запустить, «как» становится деталью реализации, специфичной для среды, о которой заботится Score.

Score вносит одно изменение, добавляя файл score.yaml в репозиторий рабочих нагрузок. Все остальное остаётся как есть. После настройки Score можно продолжать его использовать, даже если базовый технический стек изменится.

Например, файл score.yaml описывает рабочую нагрузку с контейнером busybox, зависящим от базы данных PostgreSQL и объявляющим два общедоступных порта — 80 и 8080:

apiVersion: score.dev/v1b1

metadata:
  name: example-service

containers:
  container-id:
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo Hello friend!; sleep 5; done"]
    variables:
        CONNECTION_STRING: postgresql://${resources.db.username}:${resources.db.password}@${resources.db.host}:${resources.db.port}/${resources.db.name}

resources:
  db:
    type: postgres

service:
  ports:
    www:
      port: 80
      targetPort: 8080
    admin:
      port: 8080
      protocol: UDP

Созданный файл можно конвертировать в любую нужную сущность — docker-compose.yml или манифест для сущности в кластере Kubernetes:

Преимущества Score:

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

• Устраняет возможность нестыковок при конфигурировании запуска рабочих нагрузок. Например, если тестовая среда использует Docker Compose, а продакшен-среда — Kubernetes, поддержание синхронизации конфигурации может быть сложной задачей из-за различных API, семантики, синтаксиса и конструкций конфигурации каждой платформы. С помощью Score разработчики описывают свои рабочие нагрузки один раз, а необходимая конфигурация для конкретной платформы автоматически генерируется с помощью реализации Score. Это значительно снижает риск несоответствия конфигурации между средами.

• Позволяет чётко разделить задачи между конфигурацией рабочей нагрузки, принадлежащей разработчику, и конфигурацией инфраструктуры, принадлежащей платформе: разработчики указывают требования для своей рабочей нагрузки, а необходимые для запуска в нужной среде конфигурации генерируются автоматически.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Shipwright

Shipwright — расширяемая среда для создания образов контейнеров в Kubernetes. Она поддерживает такие популярные инструменты, как Kaniko, Cloud Native Buildpacks, Buildah и другие.

Shipwright базируется на четырёх элементах для каждой сборки:

• исходный код — то, «что» нужно собрать;

• выходной образ — «куда» доставить приложение;

• стратегия сборки — «как» собирается приложение;

• вызов — «когда» создать приложение.

API сборки Shipwright состоит из трёх основных CustomResourceDefinitions (CRD):

• Build — определяет, что именно собирать и куда следует доставлять приложение;

• BuildStrategyиClusterBuildStrategy — определяет, как собирать приложение для инструмента создания образов;

• BuildRun — вызывает сборку.

Объект Build предоставляет описание того, как собирать конкретное приложение. Простейшая сборка состоит из исходного кода Git, стратегии сборки и выходного образа:

apiVersion: build.dev/v1alpha1
kind: Build
metadata:
  name: kaniko-golang-build
  annotations:
    build.build.dev/build-run-deletion: "true"
spec:
  source:
    url: https://github.com/sbose78/taxi
  strategy:
    name: kaniko
    kind: ClusterBuildStrategy
  output:
    image: registry.mycompany.com/my-org/taxi-app:latest

Build можно расширять для отправки в приватные registry, использования другого Dockerfile и многого другого.

BuildStrategy и ClusterBuildStrategy определяют, как будет собираться объект. Они различаются по своей области действия: BuildStrategy-объекты имеют область действия пространства имён, а ClusterBuildStrategy-объекты работают во всём кластере.

Описание BuildStrategy и ClusterBuildStrategy состоит из buildSteps, похожих на описание контейнеров в Kubernetes. Ниже приведён пример спецификации для Kaniko, который может создать образ из Dockerfile внутри контейнера:

# This is a fragment of a manifest.
spec:
  buildSteps:
    - name: build-and-push
      image: gcr.io/kaniko-project/executor:v1.3.0
      workingDir: /workspace/source
      securityContext:
        runAsUser: 0
        capabilities:
          add:
            - CHOWN
            - DAC_OVERRIDE
            - FOWNER
            - SETGID
            - SETUID
            - SETFCAP
      env:
        - name: DOCKER_CONFIG
          value: /tekton/home/.docker
      command:
        - /kaniko/executor
      args:
        - --skip-tls-verify=true
        - --dockerfile=$(build.dockerfile)
        - --context=/workspace/source/$(build.source.contextDir)
        - --destination=$(build.output.image)
        - --oci-layout-path=/workspace/output/image
        - --snapshotMode=redo
      resources:
        limits:
          cpu: 500m
          memory: 1Gi
        requests:
          cpu: 250m
          memory: 65Mi

Каждый BuildRun-объект вызывает сборку в кластере. Они представляют рабочую нагрузку в кластере, в итоге приводя к запуску подов.

Также система предоставляет метрики, с помощью которых можно мониторить состояние сборки приложений.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Stacker

Stacker — это инструмент для создания образов OCI с помощью декларативного формата YAML.

Основные особенности проекта:

• один статически собранный бинарный файл, выполняющий все задачи;

• работа без повышения привилегий на хосте;

• есть подготовленная интеграция с GitHub Actions;

• работает на базе контейнеров LXC, что гарантирует повторяемость сборки в любых окружениях;

• инкрементальная сборка — позволяет пересобирать только изменившиеся образы.

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

cat > env_stacker.yaml << EOF
env-stacker:
  from:
    type: docker
    url: docker://zothub.io/tools/busybox:stable
  run: |
    env
  build_only: true
EOF

stacker build -f env_stacker.yaml
preparing image env-stacker...
loading docker://zothub.io/tools/busybox:stable
Copying blob f5b7ce95afea skipped: already exists
Copying config 74c82eccc6 done
Writing manifest to image destination
Storing signatures
cache miss because layer definition was changed
+ env
HTTPS_PROXY=http://173.36.224.109:8080
no_proxy=localhost,127.0.0.1,localaddress,.localdomain.com,.cisco.com
SHLVL=1
NO_PROXY=localhost,127.0.0.1,localaddress,.localdomain.com,.cisco.com
container=lxc
https_proxy=http://173.36.224.109:8080
TERM=screen-256color
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
STACKER_LAYER_NAME=env-stacker
PWD=/

Обратите внимание, что только HTTPS_PROXY, https_proxy, NO_PROXY, no_proxy и TERM импортируются с хоста. Остальные переменные являются стандартными переменными оболочки.

Stacker создаёт корневую файловую систему, определённую в разделе from, и запускает скрипт сборки в разделе run, используя эту файловую систему. Он ожидает, что базовом контейнере будет «нормальная» файловая система, чтобы можно было выполнить sh-команды, описанные в разделе run. 

Рассмотрим корневую файловую систему, которую Stacker предоставляет скрипту в следующем примере:

cat > rfs_stacker.yaml << EOF
rfs-stacker:
  from:
    type: docker
    url: docker://zothub.io/tools/busybox:stable
  run: |
    ls -al /
    find /etc
    which cat
  build_only: true
EOF

stacker build -f rfs_stacker.yaml
preparing image rfs-stacker...
loading docker://zothub.io/tools/busybox:stable
Copying blob f5b7ce95afea skipped: already exists
Copying config 74c82eccc6 done
Writing manifest to image destination
Storing signatures
+ ls -al /
total 0
drwxr-xr-x    1 root     root           120 Oct 25 18:30 .
drwxr-xr-x    1 root     root           120 Oct 25 18:30 ..
drwxr-xr-x    2 root     root          8080 Oct  3 22:04 bin
drwxr-xr-x    4 root     root           340 Oct 25 18:30 dev
drwxr-xr-x    1 root     root            60 Oct 25 18:30 etc
drwxr-xr-x    2 nobody   nobody          40 Oct  3 22:04 home
dr-xr-xr-x 2299 nobody   nobody           0 Oct 25 18:30 proc
drwx------    2 root     root            40 Oct  3 22:04 root
drwxr-xr-x    2 root     root            60 Oct 25 18:30 stacker
dr-xr-xr-x   13 nobody   nobody           0 Sep 22 22:12 sys
drwxrwxrwt    2 root     root            40 Oct  3 22:04 tmp
drwxr-xr-x    3 root     root            60 Oct  3 22:04 usr
drwxr-xr-x    4 root     root            80 Oct  3 22:04 var
+ find /etc
/etc
/etc/shadow
/etc/passwd
/etc/network
/etc/network/if-up.d
/etc/network/if-pre-up.d
/etc/network/if-post-down.d
/etc/network/if-down.d
/etc/localtime
/etc/group
/etc/resolv.conf
+ which cat
/bin/cat

Контейнер docker://zothub.io/tools/busybox:stable определяет указанную выше файловую систему, которая содержит необходимые утилиты, такие как /bin/cat, и базовую конфигурацию системы, необходимую для работы большинства утилит Linux.

Stacker создаёт образы контейнеров в пространстве имён хостовой сети. Он пробрасывает /etc/resolv.conf хоста в корневую файловую систему контейнера сборки, чтобы обеспечить правильное разрешение DNS, определённое хостом. Затем он повторно экспортирует настройки прокси в среду, чтобы разрешить доступ на основе прокси к любым артефактам, необходимым для создания образа контейнера. 

Рассмотрим сетевую настройку, которую Stacker предоставляет скрипту в следующем примере:

$ cat > network_stacker.yaml << EOF
network-stacker:
  from:
    type: docker
    url: docker://zothub.io/tools/busybox:stable
  run: |
    echo "HTTPS_PROXY=$HTTPS_PROXY"
    cat /etc/resolv.conf
    ip addr
  build_only: true
EOF

$ stacker build -f network_stacker.yaml
preparing image network-stacker...
loading docker://zothub.io/tools/busybox:stable
Copying blob f5b7ce95afea skipped: already exists
Copying config 74c82eccc6 done
Writing manifest to image destination
Storing signatures
+ echo HTTPS_PROXY=http://173.36.224.109:8080
HTTPS_PROXY=http://173.36.224.109:8080
+ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search cisco.com insieme.local
+ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp97s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
    link/ether 3c:fd:fe:7f:27:a0 brd ff:ff:ff:ff:ff:ff
3: enp97s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
    link/ether 3c:fd:fe:7f:27:a1 brd ff:ff:ff:ff:ff:ff
4: enp97s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
    link/ether 3c:fd:fe:7f:27:a2 brd ff:ff:ff:ff:ff:ff
5: enp97s0f3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
    link/ether 3c:fd:fe:7f:27:a3 brd ff:ff:ff:ff:ff:ff
6: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
    link/ether b4:96:91:a4:44:d4 brd ff:ff:ff:ff:ff:ff
    inet 172.20.61.165/24 brd 172.20.61.255 scope global enp1s0f0
       valid_lft forever preferred_lft forever
    inet6 fe80::b696:91ff:fea4:44d4/64 scope link
       valid_lft forever preferred_lft forever
7: enp1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
    link/ether b4:96:91:a4:44:d5 brd ff:ff:ff:ff:ff:ff
8: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue qlen 1000
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0
       valid_lft forever preferred_lft forever
9: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
    link/ether 02:42:30:0d:77:ad brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

Поскольку Stacker используется только для создания образов, это безопасно и интуитивно понятно для пользователей в корпоративных сетях со сложными настройками прокси и другими.

Рассмотрим пример сборки небольшого Go-приложения:

$ cat > "hello_stacker.go" << EOF
package main

import "fmt"

func main() {
    fmt.Println("Hello Stacker!")
}
EOF

$ cat > "go_build.stacker.yaml" << EOF
go-build-hello-stacker:
  from:
    type: docker
    url: docker://zothub.io/c3/ubuntu/go-devel-amd64:1.19.2
  import:
    - ./hello_stacker.go
  build_only: true
  run: |
    # Source Go toolchain env.
    . /etc/profile

    # Setup Go ENV.
    mkdir -p /go
    export GOPATH=/go
    mkdir -p /go/src
    cd /go/src

    # Copy source code to go path.
    cp /stacker/hello_stacker.go .

    # Build code.
    go build -o hello_stacker hello_stacker.go

    # Test code.
    ./hello_stacker
EOF

$ stacker build -f go_build.stacker.yaml
preparing image hello-go-stacker...
using cached copy of /dev/shm/ravi/hello_stacker.go
loading docker://zothub.io/c3/ubuntu/go-devel-amd64:1.19.2
Copying blob b900f44d647a skipped: already exists
Copying config 3ece5b544e done
Writing manifest to image destination
Storing signatures
cache miss because layer definition was changed
+ . /etc/profile
+ export 'HOME=/go'
+ export 'GOROOT=/opt/go'
+ export 'PATH=/opt/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
+ mkdir -p /tmp/go/cache
+ export 'GOCACHE=/tmp/go/cache'
+ mkdir -p /go
+ export 'GOPATH=/go'
+ mkdir -p /go/src
+ cd /go/src
+ cp /stacker/hello_stacker.go .
+ go build -o hello_stacker hello_stacker.go
+ ./hello_stacker
Hello Stacker!

Приведённый выше скрипт создаёт файл с именем hello_stacker.go, а затем использует контейнер разработки zothub.io/c3/ubuntu/go-devel-amd:1.19.2 для сборки.

На схеме ниже показана взаимосвязь между различными директивами и внутренним состоянием, поддерживаемым в процессе сборки образа:

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

youki

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

Инструмент может работать в двух режимах — rootful и rootless. Основное отличие для пользователя в том, что режим rootless, в отличие от rootful, не требует прав root.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Заключение

Мы кратко рассмотрели новые проекты категорий ландшафта CNCF Runtime и App Definition & Development, добавленные в песочницу фонда за последний год. Надеемся, что они успешно пройдут стадию принятия в CNCF и станут его полноценными членами.

P. S.

Читайте также в нашем блоге:

• 25 новых проектов в песочнице CNCF: мегаобзор