Эффективное развертывание образа Docker для подключения с низкой пропускной способностью

В этой статье описывается решение для развертывания контейнерных пограничных модулей Интернета вещей (IoT) между временными или низкоскоростными интернет-подключениями.

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

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

У компании возникли проблемы с обновлением устройств по сравнению с недавно разработанной платформой Azure IoT Edge. Основными точками боли были:

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

Для решения этих проблем команда разработчиков создала решение, которое:

• Сводит к минимуму размер развертывания на каждом устройстве, уменьшая пропускную способность.
• Реализует стандартизированное развертывание контейнера Docker с платформы IoT Edge на разнородные удаленные устройства Интернета вещей.
• Обеспечивает надежный мониторинг развертывания.
• Использует различные службы Azure DevOps и облачные службы и использует предпочитаемые средства клиента.

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

Требования клиента

У клиента были следующие требования:

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

Существуют также следующие подробные требования:

• Файлы изображений передаются через низкую пропускную способность, периодические спутниковые подключения.
• Объем передаваемых данных должен быть сведен к минимуму.
• Передача файлов на устройства использует предпочтительное стороннее приложение клиента.
• Рабочие нагрузки устройств используют образы Docker в IoT Edge.
• Размеры изображения варьируются от десятков МБ до нескольких ГБ.
• Модули IoT Edge записываются в .NET Core 2.2.

Потенциальные варианты использования

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

• Удаленный мониторинг добычи нефти, газа и горнодобывающей промышленности
• Обновления по беспроводной связи для автомобилестроительной отрасли.
• Нигде не гарантируется надежное подключение

Архитектура

В сценариях с высокой пропускной способностью Azure IoT Edge извлекает образы непосредственно из реестра Docker, доступного к Интернету, либо центра Docker, либо частного концентратора, например Реестр контейнеров Azure. Эта функция аналогична выполнению docker pull <image_name> команды.

При потенциально прерывистом сетевом доступе, таком как спутниковое подключение к Интернету, метод извлечения Docker является ненадежным. Ход выполнения не кэшируется, если подключение к Интернету удаляется, пока Docker извлекает изображение. Когда подключение к Интернету возобновляется, Docker должен снова начать извлечение изображения с самого начала.

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

Поток данных

1. Разработчики взаимодействуют с исходным кодом модуля edge в репозитории исходного кода.
2. Реестр контейнеров хранит образы Docker каждого модуля.
3. Репозиторий манифестов содержит манифесты развертывания для всех рабочих потоков.
4. Каждый модуль имеет конвейер сборки Azure Pipelines, использующий универсальную сборку Docker для автоматического создания и регистрации модулей.
5. Конвейер образа к устройству развертывает образы Docker на целевых устройствах, как определено в файле манифеста.
6. Конвейер манифеста к устройству отправляет манифест развертывания в соответствующую Центр Интернета вещей Azure для обновляемого устройства.
7. Стороннее решение для быстрой передачи файлов передает файлы из учетной записи служба хранилища Azure на устройство.
8. Модуль Восстановления образа IoT Edge применяет полученные исправления на устройствах.
9. Центр Интернета вещей получает сообщения о состоянии из модуля восстановления образа и задает манифест развертывания для устройства. Остальная часть потока конвейера использует этот манифест развертывания.
10. Функции Azure отслеживает поток сообщений Центр Интернета вещей, обновляет базу данных SQL и уведомляет пользователя об успешном выполнении или сбое.
11. База данных SQL Azure отслеживает вхождения на целевых устройствах и службах Azure во время и после развертывания.

Компоненты

• Azure IoT Edge выполняет контейнерные рабочие нагрузки на устройствах, обеспечивая подключение с низкой задержкой и экономию пропускной способности.
• Центр Интернета вещей Azure — это управляемая облачная служба, которая выступает в качестве центрального центра сообщений между приложениями Интернета вещей и устройствами, которыми они управляют.
• Реестр контейнеров Azure — это облачная служба частного реестра для хранения частных образов контейнеров Docker и связанных артефактов.
• Azure Pipelines объединяет непрерывную интеграцию (CI) и непрерывную доставку (CD) для автоматического тестирования и сборки кода и отправки его в любой целевой объект.
• Функции Azure — это бессерверная вычислительная платформа, которая позволяет запускать код, инициируемый событиями, не подготавливая или управляя инфраструктурой.
• служба хранилища Azure обеспечивает высокомасштабируемое, безопасное, производительное и экономичное хранилище для всех типов бизнес-данных, объектов и файлов.
• База данных SQL Azure — это полностью управляемая мультимодельная реляционная база данных, созданная для облака.
• Docker — это открытая платформа для разработки, доставки и запуска контейнерных приложений.

Альтернативные варианты

Команда разработчиков оценила несколько вариантов перед решением о полной передаче образа Docker. В следующих разделах описаны альтернативные варианты оценки и результаты.

Команда рассмотрела следующие критерии оценки для каждого варианта:

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

Эффективность пропускной способности включала сценарии, в которых:

• На устройстве не существовали образы.
• Изображение с той же базой, что и на устройстве.
• На устройстве существовал образ предыдущей версии приложения.
• На устройстве существовал образ приложения, созданного на предыдущем базовом изображении.

Команда использовала следующие сценарии для оценки эффективности пропускной способности:

Параметр "Передача слоев Docker"

Образ контейнера Docker — это подключение UnionFS к различиям файловой системы только для чтения, а другой доступный для записи уровень изменений, внесенных во время работы контейнера. Файловые системы называются слоями, которые в основном являются папками и файлами. Стек слоев для формирования базы корневой файловой системы контейнера. Так как слои доступны только для чтения, различные изображения могут совместно использовать один и тот же слой, если они имеют общий уровень.

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

Недостатки этого метода включают:

• Оркестратор должен поддерживать сведения о том, какие слои существуют на каких устройствах.
• Изменения базового уровня приводят к изменению хэшей всех производных от него уровней.
• Для сравнения требуются хэши согласованного слоя.
• Могут быть зависимости от сохранения Docker и загрузки Docker.

Изменение параметра клиента Docker

Этот параметр фокусируется на изменении или оболочке клиента Docker, поэтому он возобновляет загрузку слоя после прерывания. По умолчанию вытягивание Docker возобновляет скачивание, если подключение к Интернету восстанавливается в течение около 30 минут после прерывания. В противном случае клиент завершает работу и теряет все ход загрузки.

Этот метод жизнеспособн, но у него были осложнения, в том числе:

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

Сборка на пограничном устройстве

Этот подход перемещает среду сборки образа на устройства. На устройство отправляются следующие данные:

• исходный код для создаваемого приложения;
• Копия всех пакетов NuGet, от которой зависит код
• базовые образы Docker для среды сборки и среды выполнения .NET Core;
• Метаданные о конечном изображении

Агент сборки на устройстве затем создает образ и регистрирует его в диспетчере Docker.

Это решение было отклонено по следующим причинам:

• Вам по-прежнему потребуется переместить большие образы Docker на устройства. Образы для создания приложений .NET больше, чем сами образы приложений.
• Этот метод работает только для приложений, в которых команда имеет исходный код, поэтому не может использовать сторонние образы.
• Для этого параметра требуется упаковка пакетов NuGet и отслеживание их перемещения на устройства.
• Если образ не удалось создать на устройстве, команде придется удаленно отлаживать среду сборки и созданный образ. Для удаленной отладки потребуется высокий уровень использования потенциально ограниченного подключения к Интернету.

Параметр передачи разностных изображений полного изображения

Выбранный подход обрабатывает образ Docker как один двоичный файл. Команда Docker save экспортирует изображение в виде файла .tar . Решение экспортирует существующие и новые образы Docker и вычисляет двоичную дельту, которая при применении преобразует существующий образ в новый.

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

Результаты оценки

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

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, набор руководящих принципов, которые повышают качество рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Оптимизация производительности

Это решение значительно сократило пропускную способность, используемую обновлениями устройств Интернета вещей. В следующих таблицах показана разбивка различий в эффективности передачи.

Реконструктор изображений в качестве источника:

Предыдущая версия в качестве источника:

Эффективность работы

В следующих разделах приведено подробное пошаговое руководство по решению.

Репозиторий исходного кода

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

\- repository root
    - modulea
    - modulea.csproj
    - module.json
    - Program.cs
    - Dockerfile

\- moduleb
    - moduleb.csproj
    - module.json
    - Program.cs
    - Dockerfile

Рекомендуемое число репозиториев исходного кода:

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

Экземпляры реестра контейнеров

Реестр контейнеров хранит образы Docker каждого модуля. Существует две возможные конфигурации для реестра контейнеров:

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

Репозиторий манифестов

Репозиторий манифестов содержит манифесты развертывания для всех рабочих потоков. Шаблоны находятся в папках на основе их рабочего потока. В этом примере два рабочих потока являются общей инфраструктурой и контейнерным приложением.

\- repository root
     - Workstream1
         - deployment.template.json
     - Workstream2
         - deployment.template.json

Конвейер сборки образа Docker

Каждый модуль имеет конвейер сборки Azure Pipelines. Конвейер использует универсальную сборку Docker для создания и регистрации модулей. Конвейер отвечает за:

• проверка безопасности исходного кода;
• проверка безопасности базового образа для создания образа Docker;
• выполнение модульных тестов для модуля;
• сборка образа Docker из исходного кода; Тег изображения содержит BUILD_BUILDIDтег, поэтому изображение всегда можно связать с исходным кодом, который сделал его.
• Отправка образа в экземпляр реестра контейнеров.
• создание разностного файла;
• Создание файла подписи для образа и сохранение файла в учетной записи хранения Azure.

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

Конвейер "образ — устройство"

Конвейер образа к устройству развертывает образы Docker на целевых устройствах, как определено файлом манифеста. Запуск конвейера вручную запускает развертывание.

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

Изображение содержит код, определяющий, какие исправления необходимо создавать, создавать исправления и распространять их на стороне Azure средства передачи файлов.

Для средства распространения изображений требуются следующие сведения:

• Какие образы необходимо развернуть, предоставляемые манифестом в репозитории.
• Какие устройства необходимо развернуть, предоставленные пользователем, который активирует конвейер.
• Какие образы уже находятся на целевых устройствах, предоставляемых базой данных SQL Azure.

Выходные данные конвейера:

• Пакеты исправлений, отправленные на стороне Azure средства передачи файлов, которые будут распространяться на устройства.
• Записи базы данных SQL, которые помечают, какие образы начали передаваться на каждое устройство.
• Записи базы данных SQL для новых наборов развертывания. Эти записи включают имя и адрес электронной почты пользователя, который заказал развертывание.

Этот конвейер выполняет следующие действия.

1. Определяет необходимые образы на основе манифеста развертывания.
2. Запрашивает SQL, чтобы узнать, какие образы уже находятся на устройствах. Если все образы уже присутствуют, конвейер завершается успешно.
3. Определяет, какие пакеты исправлений необходимо создать. Алгоритм определяет, какой начальный образ создает наименьший пакет исправлений.
   • Входные данные: файл .tar , содержащий новый образ для развертывания, и файлы подписи для существующих образов на устройствах.
   • Выходные данные: ранг существующих образов для определения наименьшего исправления для создания.
4. Создает необходимые пакеты исправлений для каждого устройства. Создает аналогичные исправления один раз и копирует их на все необходимые устройства.
5. Распределяет исправления в учетную запись хранения средства передачи файлов для развертывания.
6. Обновляет SQL, чтобы пометить новые образы на in transit каждом из целевых устройств.
7. Добавляет сведения о наборе развертывания в SQL с именем и контактным адресом для пользователя, развертывающего образ.

Конвейер манифеста к устройству

Конвейер манифеста к устройству отправляет манифест развертывания в правильное Центр Интернета вещей подключение для обновляемого устройства. Пользователь запускает конвейер вручную и задает переменную среды для целевого экземпляра Центр Интернета вещей.

Функции этого конвейера:

• Определяет, какие образы требуется для развертывания.
• Запрашивает SQL, чтобы убедиться, что необходимые образы находятся на целевых устройствах. В противном случае конвейер завершается состоянием failed .
• Отправляет новый манифест развертывания в правильный Центр Интернета вещей.

Решение для быстрой передачи файлов

Клиент хотел продолжить использование стороннего решения для передачи файлов с именем FileCatalyst, чтобы обеспечить подключение между Azure и их устройствами Интернета вещей. Это решение в конечном итоге согласованное средство передачи файлов, что означает, что передача может занять много времени, но в конечном итоге завершится без потери сведений о файле.

Решение использовало учетную запись служба хранилища Azure на стороне подключения Azure и существующую виртуальную машину узла передачи файлов клиента для каждого устройства, получающего образы. Пакеты исправлений передаются на виртуальную машину Linux, которая выполняется Центр Интернета вещей.

Модуль восстановления изображений

Модуль Восстановления образа IoT Edge применяет полученные исправления на устройствах. Каждое устройство размещает собственный локальный реестр контейнеров с помощью реестра с открытым кодом Docker. Процесс восстановления образа выполняется на виртуальной машине узла, которая совпадает с виртуальной машиной передачи файлов.

Этот модуль выполняет следующее:

1. Получает пакет исправлений в папке, подключенной к контейнеру.
2. Распакует содержимое исправления для чтения файла конфигурации.
3. Извлекает базовый образ из локального реестра контейнеров по хэшу.
4. Сохраняет базовый образ в виде файла .tar .
5. Применяет исправление к базовому изображению.
6. Загружает файл .tar, содержащий новый образ в Docker.
7. Отправляет новый образ в локальный реестр контейнеров с файлом конфигурации, включая понятное имя и тег.
8. Отправляет сообщение об успешном выполнении Центр Интернета вещей.

Если процесс завершается сбоем в любой момент, модуль отправляет сообщение об ошибке в Центр Интернета вещей, поэтому пользователь, активировавший развертывание, может быть уведомлен.

Центр Интернета вещей

Некоторые процессы развертывания используют Центр Интернета вещей. Помимо получения сообщений о состоянии из модуля восстановления образов, Центр Интернета вещей задает манифест развертывания для устройства. Остальная часть потока конвейера использует этот манифест.

Функции Azure

Функции Azure отслеживает поток сообщений, поступающий из Центр Интернета вещей, и выполняет действия в облаке.

Для сообщения об успешном выполнении:

• Функция обновляет состояние записи SQL для образа на устройстве.in transit succeeded
• Если этот образ является последним для прибытия в набор развертывания:
  • Функция уведомляет пользователя об успешном развертывании.
  • Функция обновляет конвейер манифеста к устройству, чтобы начать работу с новыми изображениями.

Для сообщения об ошибке:

• Функция обновляет состояние записи SQL для образа на устройстве.in transit failed
• Функция уведомляет пользователя о сбое передачи изображений.

База данных SQL

База данных SQL отслеживает вхождения на целевых устройствах и службах развертывания на основе Azure во время и после развертывания. Функции Azure и Azure Pipelines используют частный пакет NuGet, созданный для взаимодействия с базой данных.

База данных SQL хранит следующие данные:

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

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Канио Димитров | Главный руководитель по разработке программного обеспечения

Следующие шаги

• Развертывание первого модуля IoT Edge на виртуальном устройстве Linux
• Разработка модулей IoT Edge с контейнерами Linux

Связанные ресурсы

• Эталонная архитектура Azure IoT
• Проектирование конвейера CI/CD с помощью Azure DevOps
• Сетевые подключения с низкой задержкой для промышленности