План развития containerd

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

Для получения более актуальной информации просмотрите вехи на github.

Существуют различные этапы разработки:

• Не начато — работа или планирование по достижению цели не проводились;
• В разработке — началась работа над дизайном компонента, документы можно найти в папке design;
• Выполняется — дизайн в основном завершён, началась разработка;
• Завершено — разработка завершена;
• Стабильно — API для этого этапа полностью функционален и считается стабильным.

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

Этап 1

Статус: Выполняется

GRPC API

Документы:

Мы переходим от нисходящего проектирования для заполнения недостающих частей containerd и проектирования API.

Дизайн

Документы:

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

Сборка и тестирование

Документы:

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

Этап 2

Этап 2 включает большую часть проектной и конструкторской работы для уровней выполнения и хранения containerd. Он будет включать перенос существующих «графических драйверов» из Docker Engine и поиск общей модели для представления снимков многоуровневых файловых систем.

Также будет перенесён существующий код выполнения для поддержки OCI Runtime Spec и существующего кода выполнения containerd.

Статус: В разработке

Выполнение

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

Хранение

Документы: https://github.com/containerd/containerd/blob/master/design/snapshots.md

Существующие графические драйверы были созданы, когда у нас были только оверлейные файловые системы, такие как aufs. Мы заставили модель быть разработанной вокруг оверлейных файловых систем, и это внесло много сложностей для создания снимков графических драйверов, таких как btrfs и devicemapper thin-p. Наш текущий подход заключается в том, чтобы смоделировать наш уровень хранения после создания снимков драйверов вместо оверлейных драйверов, поскольку мы можем получить те же результаты, и это чище и надёжнее иметь модель оверлейной файловой системы для снимков, чем иметь модель снимков файловой системы с оверлеем.

Этап 3

Этот этап включает поддержку спецификации OCI Image, встроенную в containerd.

Статус: Не начат

Распространение

Этап 4

Этап 4 включает переход к версии 1.0 и смещение фокуса с функций на обслуживание. Переход к 1.0 подразумевает:

— завершение всех вышеперечисленных этапов; — покрытие функциональных возможностей, необходимых большинству контейнерно-ориентированных платформ; — предложение паритета функций, насколько это возможно технически, между Linux и Windows; — демонстрацию того, что containerd соответствует требованиям хотя бы одной вышестоящей платформы через полную интеграцию в качестве восходящего потока.

Статус: Не начат