Это пост от гостя Дрю Мозли, архитектора технических решений в Toradex, в котором объясняется, как компания обновляет прошивку Linux IoT-устройств с помощью инструмента для сборки и развертывания операционной системы с открытым исходным кодом OSTree (также известного как libostree), а также программных контейнеров Docker.
Каждый день на рынок выводится все больше и больше подключенных устройств, а общий размер рынка Интернета вещей (IoT) к 2027 году по прогнозам достигнет 1,5 триллиона долларов. Бензиновые насосы, медицинские устройства и системы торговых точек все чаще подключаются друг к другу, что делает практически невозможным избежать взаимодействия с этими устройствами даже для тех, кто абсолютно даек от современных технологий. В домашних условиях такие устройства, как измерители мощности, выключатели света и камеры видеонаблюдения, как правило, подключены к Интернету, что обеспечивает функциональность умного дома.
Уровень сложности программного обеспечения для этих устройств увеличивается с увеличением функциональности, а количество устройств с дефектами программного обеспечения на местах растет. Во многих случаях эти системы проектируются, производятся и поставляются без учета предоставления обновлений программного обеспечения сверх начальной загрузки программы. Это серьезная проблема, и она может выходить далеко за рамки причинения проблем владельцу устройства, добавления гарантии или расходов на отзыв для производителя. Во многих случаях IoT-устройства можно объединить в большие ботнеты IoT, которые из-за большого количества использовались для крупномасштабных атак на критически важные части инфраструктуры, таких как распределенная атака отказа в обслуживании (DDOS) против Dyn Domain Name Service (DNS), что приводит к перебоям в обслуживании крупных организаций, таких как Twitter и Github.
Зачем обновлять устройства?
Самая очевидная причина для предоставления обновлений программного обеспечения устройствам в полевых условиях – устранение уязвимостей программного обеспечения. Не все уязвимости превращаются в эксплойты, приводящие к крупномасштабным атакам, как упоминалось выше, но риск значительный. А поскольку в домах ваших пользователей становится все больше и больше устройств, возможно, появится возможность связать уязвимости с нескольких устройств вместе, чтобы получить более широкий доступ к данным ваших пользователей. На ум приходит один инцидент в неназванном казино была взломана база данных хайроллеров из-за уязвимости в термометре для аквариума с подключением к Интернету. В самолете 787 Dreamliner примерно 14 миллионов строк кода (вероятно, данные ограниченны системой авионики и не включают такие вещи, как бортовые развлекательные системы), по сравнению с примерно 28 миллионами строк кода только в ядре Linux (по состоянию на январь 2020 года). Имейте в виду, что ядро Linux – это только одна часть системы Linux, что указывает на масштаб проблемы. Эти многочисленные строки кода, несомненно, будут содержать множество ошибок, требующих исправления на протяжении всего срока службы вашего продукта.
Предоставление возможности обновления для ваших устройств также позволяет вам предоставлять новые функции вашим пользователям. В зависимости от вашей бизнес-модели это может быть полезно для долгосрочного удержания клиентов или просто для обеспечения возможностей дополнительных продаж и увеличения доходов. Учитывая преимущества возможности обновления, вы можете задаться вопросом, почему какое-либо устройство будет поставляться без этого. Мы с трудом можем определить вариант использования, при котором обновления программного обеспечения были бы совершенно ненужными.
OTA сервер
Любое полностью автоматизированное решение для обновления OTA требует сервера, который управляет парком и позволяет операционному персоналу управлять устройствами. Подробное обсуждение серверной части выходит за рамки этой статьи, но существует множество вариантов. В общем, вы захотите выбрать комплексное решение, означающее, что и сервер обновлений, и клиенты обновлений были разработаны как полное решение, или, по крайней мере, комбинация сервера и клиента была хорошо протестирована и интегрированы друг с другом.
Методы обновления
Существует несколько распространенных методов обновления программного обеспечения.
- Обновления на основе пакетов на месте : это механизм, используемый большинством операционных систем для настольных ПК. Обычно приложение-установщик или система упаковки запускаются в текущем активном образе ОС. Это может установить все, что необходимо системе, но должно быть сложно гарантировать, что все устройства в вашем парке работают с теми же двоичными файлами, которые вы тестировали в своих конструкторских лабораториях.
Асимметричные обновления образов: этот метод обычно использует отдельный раздел установщика, который может загружать соответствующие образы и перезаписывать основной раздел ОС. Это устраняет проблему частично установленных наборов пакетов, которая возникает при обновлении на месте, но может привести к длительным простоям ваших пользователей. Это метод, который до недавнего времени использовался для большинства обновлений мобильных телефонов, и мы уверены, что всех нас раздражало количество времени, которое занимает эти обновления. - Симметричные обновления образов (обычно называемые двойными обновлениями A / B): этот метод использует полностью избыточные разделы, содержащие активный и пассивный разделы. Во время работы в активном разделе клиент обновления может загрузить и установить полный образ в пассивный раздел. Поскольку все это может происходить в фоновом режиме, пока код вашего приложения активен, это устраняет проблемы простоя, связанные с асимметричными образами. Однако, поскольку он использует полностью избыточные разделы, он обычно занимает больше места на блочном устройстве, чем другие методы.
- Обновления на основе OSTree : это тема следующего раздела и обеспечивает хорошее сочетание функций, позволяющих минимизировать время простоя устройства и не требуя дополнительного хранилища для размещения избыточных разделов.
OSTree
В документации к проекту OSTree определяется следующим образом:
libostree – это и общая библиотека, и набор инструментов командной строки, которые объединяют в себе «git-подобную» модель для фиксации и загрузки деревьев загрузочных файловых систем, а также уровень для их развертывания и управления конфигурацией загрузчика.
Определение немного туманно, поэтому давайте рассмотрим пример. Сначала мы создадим пустой репозиторий в подкаталоге на нашей рабочей станции разработки. OSTree обычно используется для целых файловых систем, но для простоты мы будем использовать каталог для этого примера.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$ ostree init --repo repo $ tree -F repo repo ├── config ├── extensions/ ├── objects/ ├── refs/ │ ├── heads/ │ ├── mirrors/ │ └── remotes/ ├── state/ └── tmp/ └── cache/ 9 directories, 1 file |
Мы инициализировали пустой репозиторий. Вы можете видеть, что он создал несколько пустых каталогов и один файл конфигурации. Метаданные репозитория имеют много общего с git. Вы видите знакомые каталоги, такие как refs/head, которые используются аналогичным образом. Теперь добавим файл в репозиторий:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
$ mkdir -p rootfs/etc $ echo 'enabled=1' > rootfs/etc/config_file.txt $ ostree --repo=repo commit --branch=main rootfs 1d0f1459b634bfbd5f573ae56a55a03a35b8941d4c45ab07dbdd6edc462c3e77 $ tree -F . . ├── repo/ │ ├── config │ ├── extensions/ │ ├── objects/ │ │ ├── 1d/ │ │ │ └── 0f1459b634bfbd5f573ae56a55a03a35b8941d4c45ab07dbdd6edc462c3e77.commit │ │ ├── 2a/ │ │ │ └── 28dac42b76c2015ee3c41cc4183bb8b5c790fd21fa5cfa0802c6e11fd0edbe.dirmeta │ │ ├── 92/ │ │ │ └── d6c7afcaedabd4504d2e16de3ffc200cd156ac733306cf7b8991f56859bcd5.file │ │ ├── af/ │ │ │ └── 98568126959bb302d2b86a25646360bd7f4fafa657490da635edf1450b32d4.dirtree │ │ └── ef/ │ │ └── 8396cb2291fe95f7b187a90fce5c6c973388c793730be1f698143bf7b01eb0.dirtree │ ├── refs/ │ │ ├── heads/ │ │ │ └── main │ │ ├── mirrors/ │ │ └── remotes/ │ ├── state/ │ └── tmp/ │ └── cache/ └── rootfs/ └── etc/ └── config_file.txt |
Мы видим, что создано много новых объектов. Файлы .dirmeta, .dirtree и .commit представляют собой метаданные, которые отслеживают метаданные файлов и каталогов (разрешения, владение и т. д.), древовидную структуру каталогов и метаданные фиксации соответственно. Файл refs/Heads/main file содержит хэш фиксации для новой фиксации:
|
1 2 3 4 5 |
$ ostree --repo=repo show $(cat repo/refs/heads/main) commit 1d0f1459b634bfbd5f573ae56a55a03a35b8941d4c45ab07dbdd6edc462c3e77 ContentChecksum: f34528e7549c000b13abceb403b65298f9d54b1c2987bd02ab0a3ea1169fec27 Date: 2021-05-27 20:21:01 +0000 (no subject) |
Также обратите внимание, что объект, созданный с расширением .file, идентичен файлу, который мы создали. Это обычно называется хранилищем с адресацией по содержимому, что просто означает, что файлы в хранилище объектов именуются на основе их содержимого. Имя объекта (в данном случае 92/d6c7afcaedabd4504d2e16de3ffc200cd156ac733306cf7b8991f56859bcd5.file) генерируется из sha256sum самого файла, а также атрибутов файла.
|
1 2 3 |
$ sha256sum rootfs/etc/config_file.txt $(find repo -name *.file) 16f4affa3003cb1ae3f22d5e0be86a5b6fc16bbf40662629df0aa5ad0ff52e15 rootfs/etc/config_file.txt 16f4affa3003cb1ae3f22d5e0be86a5b6fc16bbf40662629df0aa5ad0ff52e15 repo/objects/92/d6c7afcaedabd4504d2e16de3ffc200cd156ac733306cf7b8991f56859bcd5.file |
Важно отметить, что эти файлы на самом деле являются жесткими ссылками на одни и те же блоки файловой системы. Это важный принцип OStree, который показывает, что он будет очень экономным; любые файлы, которые не меняются между версиями, не будут дублироваться, что приведет к значительной экономии места как для блочного хранилища на устройстве, так и для пропускной способности загрузки при получении новых ревизий.
|
1 2 3 |
$ stat rootfs/etc/config_file.txt repo/objects/92/d6c7afcaedabd4504d2e16de3ffc200cd156ac733306cf7b8991f56859bcd5.file | grep Inode: Device: 10301h/66305d Inode: 58746231 Links: 2 Device: 10301h/66305d Inode: 58746231 Links: 2 |
Как и в случае с git, мы можем удалить файл, а затем снова проверить его из репозитория.
|
1 2 3 4 5 6 7 |
$ rm -rf rootfs $ ostree --repo=repo checkout main rootfs && tree -F rootfs rootfs └── etc/ └── config_file.txt 1 directory, 1 file |
Теперь давайте добавим в репозиторий полную корневую файловую систему. Мы создали простую файловую систему для устройства QEMU Arm с помощью Buildroot.
|
1 2 3 4 5 6 7 8 9 |
$ git clone git://git.buildroot.net/buildroot -b 2021.02.2 $ cd buildroot $ make qemu_arm_versatile_defconfig $ make $ sudo mount output/images/rootfs.ext2 /mnt $ rm -rf rootfs $ mkdir rootfs $ sudo tar -C /mnt -cf - . | tar -C rootfs/ -xf - $ ostree --repo=repo commit --branch=main --subject="Initial Linux system" rootfs |
Теперь мы создадим вторую версию файловой системы. Мы использовали предыдущую конфигурацию Buildroot и добавили служебную программу bc, которая указана в разделе Целевые пакеты\Разное при запуске конфигуратора make menuconfig.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
$ rm -rf rootfs $ mkdir rootfs $ sudo tar -C /mnt -cf - . | tar -C rootfs/ -xf - $ ostree --repo=repo commit --branch=main --subject="Added bc binary" rootfs $ ostree --repo=repo show main commit e4568293f591b80cdf68451f6329683fbecd42ec9a5915ea44b8c77bbbf47a41 ContentChecksum: 4a9765852b6134a39444751734cc0d70ee207999b73216919644cd69ad0b3d50 Date: 2021-05-28 13:24:47 +0000 Added bc binary $ ostree --repo=repo diff main M /usr/bin/bc M /usr/bin/dc |
Теперь предположим, что мы решили, что нам больше не нужен двоичный файл bc. Без перестройки мы можем просто вернуться к предыдущему выпуску. Сначала мы проверяем, существует ли bc в нашей текущей файловой системе; потом откатываемся; наконец, мы проверяем, что bc снова является символической ссылкой на busybox:
|
1 2 3 4 5 6 |
$ ls rootfs/usr/bin/bc -l .rwxr-xr-x 63k dmoseley 27 May 17:18 rootfs/usr/bin/bc* $ rm -rf rootfs $ ostree --repo=repo checkout 819beafa993f254adc0fc4f80bbc417a59099271317e9d3e0fe7768234dfacc3 rootfs $ ls rootfs/usr/bin/bc -l lrwxrwxrwx 17 dmoseley 27 May 17:14 rootfs/usr/bin/bc -> ../../bin/busybox |
Последняя функция, которая важна для системы обновления по воздуху, – это удаленные репозитории. Подобно тому, как git использует репозитории – удаленно доступные хранилища данных, содержащие метаданные OSTree. Этот пример выполняется в системе Toradex Verdin i.MX8M Mini под управлением Torizon, который представляет собой промышленную встраиваемую систему Linux, основанную на OSTree. Мы подключаем его к репозиторию Toradex TorizonCore OSTree и проверяем последний ночной выпуск. Есть дополнительные подробности, не описанные здесь, связанные с переключением на новую версию файловой системы при загрузке, так что это атомарная операция.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
root@verdin-imx8mm-06759464:~# ostree admin status * torizon 8c514a595469283bb69603f2fa32395b5dbbc3d80a8f9d824dc661f1b68c4d82.0 Version: 5.1.0+build.1 origin refspec: torizon:5/verdin-imx8mm/torizon/torizon-core-docker/release root@verdin-imx8mm-06759464:~# ostree remote add --no-gpg-verify torizon root@verdin-imx8mm-06759464:~# ostree pull torizon:5/verdin-imx8mm/torizon/torizon-core-docker/nightly 403 metadata, 2772 content objects fetched; 170803 KiB transferred in 54 seconds root@verdin-imx8mm-06759464:~# ostree log 5/verdin-imx8mm/torizon/torizon-core-docker/nightly commit befaaa1691c26881cbcbf804509761dffc767da5679fba895fdcf8d3cc898b80 ContentChecksum: 8f6aec54c23fa0e453526d44c5d03f759af512d24e303e5f43b1fa8ea19e356a Date: 2021-05-26 04:02:04 +0000 Version: 5.3.0-devel-20210525+build.308 5.3.0-devel-20210525+build.308 <> |
С набором функций, показанным OSTree, у нас есть основные функции, необходимые для системы обновления OTA:
- Возможность хранения нескольких версий всей файловой системы.
- Сохранение старых версий используется для обеспечения надежной возможности отката.
- Жесткие ссылки используются для оптимизации места для хранения.
- Удаленные репозитории позволяют подключенным устройствам загружать обновления «по воздуху».
Контейнеры
Контейнеры – это форма виртуализации на уровне ОС, позволяющая запускать приложения в изолированных средах. Они отличаются от виртуальных машин тем, что не виртуализируют всю аппаратную платформу и не запускают полную операционную систему. Их основной вариант использования – инкапсулировать приложение со всеми зависимостями, библиотеками и т. д., которые необходимы ему для работы. Настройка приложения в контейнере позволяет гарантировать соблюдение всех зависимостей без необходимости установки дополнительных пакетов в базовую ОС. Например, если вы запускаете приложение NodeJS, вы упаковываете его в контейнер со средой выполнения JavaScript и всеми другими необходимыми компонентами. Вы можете указать версии каждой зависимости, протестировать все вместе, а затем развернуть точную комбинацию; это избавляет от опасений, что базовый образ ОС может иметь другую версию определенного пакета. Кроме того, он позволяет различным контейнерам при необходимости содержать разные версии компонентов; например, вы можете запустить один пакет с приложением Python с Python v2, а другой контейнер с пакетом, которому требуется Python v3.
В дополнение к управлению зависимостями контейнеры могут изолироваться от других компонентов системы, потенциально повышая безопасность. Используя стандартные функции ядра базовой ОС, контейнеры могут быть ограничены только определенными частями файловой системы, определенными устройствами и даже конкретным процессором в многоядерной системе. В зависимости от используемой среды выполнения контейнера вы можете ограничить общее использование ЦП или памяти отдельными контейнерами, позволяя вашей системе настраиваться в зависимости от шаблонов использования.
Третья главная особенность контейнерных систем – это встроенный механизм доставки. Используя docker, один из самых популярных контейнерных движков, вы можете создавать новые контейнеры, которые наследуют функциональность многих базовых образов, предоставляемых различными поставщиками программного обеспечения. Если у вас есть приложение, написанное на Python v3, и вы хотите запустить его в среде стиля Debian, вы можете создать Dockerfile, который будет выглядеть следующим образом:
|
1 2 3 |
FROM python:buster COPY myapp.py /myapp.py CMD python /myapp.py |
Затем вы создаете файл myapp.py в том же каталоге, где находится ваше приложение. В качестве тестового приложения мы будем использовать следующее:
|
1 |
print("Hello from myapp") |
Теперь вы можете собрать и запустить этот контейнер прямо в вашей системе сборки, выполнив следующие действия:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
$ docker build . -t myapp:latest Sending build context to Docker daemon 404.5kB Step 1/3 : FROM python:buster ---> a6a0779c5fb2 Step 2/3 : COPY myapp.py /myapp.py ---> f8e6a139e325 Step 3/3 : CMD python /myapp.py ---> Running in 408690452f74 Removing intermediate container 408690452f74 ---> 179d244081b9 Successfully built 179d244081b9 Successfully tagged myapp:latest $ docker run --rm myapp Hello from myapp |
Первая команда создает образы и теги с именем myapp и последней версией. Вторая команда запускает контейнер с командой start, как указано в Dockerfile с оператором CMD. Обратите внимание, что на данном этапе мы не работаем на нашем встроенном устройстве. Вы можете использовать контейнеры для разработки и устранения неполадок на рабочем столе. Для многих задач разработки приложений это более эффективно, чем разработка непосредственно на встроенном устройстве. Когда вы будете готовы запустить контейнер на своем встроенном устройстве, вы можете скопировать весь рабочий каталог на свое устройство и повторно запустить указанные выше команды. Это сработает, когда вы тестируете или имеете дело с небольшим количеством устройств, однако по мере увеличения размера вашего парка вам понадобится лучший механизм доставки. Docker предоставляет удобный механизм для обмена образами. Мы уже использовали это, когда указывали оператор FROM в нашем Dockerfile. Это указывает докеру, что в основе нашего образа лежит образ python: buster, доступном в концентраторе docker. Вы также можете отправить свои образы в концентратор docker или любой другой репозиторий docker, что полезно, если вы хотите, чтобы ваши контейнеры оставались конфиденциальными. После того, как вы создали учетную запись Docker Hub, вы можете создать собственный образ для целевой архитектуры и опубликовать его, используя следующее:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ docker login Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to to create one. Username: myuser Password: Login Succeeded $ docker buildx create --name mybuilder --use mybuilder $ docker buildx build --platform linux/arm64,linux/amd64,linux/arm/v7 -t myuser/myapp:latest --push . [+] Building 200.2s (16/16) FINISHED => pushing layers 176.3s => pushing manifest for docker.io/drewmoseley/myapp:latest 1.3s => [auth] myuser/myapp:pull,push token for registry-1.docker.io 0.0s |
Поскольку мы создали версии для Arm32, Arm64 и AMD64, вы можете запустить свой образ из любой системы, основанной на этих архитектурах, следующим образом:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
colibri-imx8x-06748684:~$ docker run --rm myuser/myapp:latest Unable to find image 'myuser/myapp:latest' locally latest: Pulling from myuser/myapp c54d9402d498: Already exists a91bbb3592d6: Already exists 08d8c28b9129: Already exists c70b3803033b: Already exists 4d0a70a69a4a: Already exists c35b5a95ec3d: Already exists 45d8b9f6ef0c: Already exists 07fa13da7fc4: Already exists f87548a0f8e2: Already exists ccc4c71f2e3a: Pull complete Digest: sha256:099010e9ad1a7719a418422b29eecc2bafdd4c95edff6bc36d7dbb8f98f303c1 Status: Downloaded newer image for myuser/myapp:latest Hello from myapp |
Обновление OTA
Комбинация OStree и контейнеров обеспечивает богатый набор функций, на основе которых мы можем разработать полные возможности обновления OTA. Взятые вместе, эти два проекта представляют собой мощную систему, способную удовлетворить потребности разрабатываемых сегодня подключенных устройств.
Как обсуждалось выше, OSTree обеспечивает:
- Стабильный, устойчивый к энергопотреблению механизм для управления двоичными файлами вашей операционной системы.
- Эффективное использование хранилища и пропускной способности загрузки с возможностью повторного использования любых неизмененных файлов.
- Функция отката, чтобы гарантировать, что ломанное обновление не нанесет вред вашему парку устройств.
Использование контейнеров для размещения вашего стека приложений обеспечивает:
- Гибкую и знакомую среду разработки программного обеспечения. Ваши разработчики могут продолжать использовать инструменты, с которыми они уже знакомы, в своих настольных системах Linux.
- Вам не придется изобретать велосипед, и вы сможем воспользоваться проверенными в отрасли решениями.
- Активное сообщество разработчиков. Количество документации, сообщений в блогах и готовых контейнеров, доступных для повторного использования, огромно, и их можно использовать в качестве отправной точки для ваших усилий по разработке.
Использование такой системы позволяет обновлять любой компонент в системе, включая ядро, дерево устройств и код приложения. При правильном развертывании вы можете гарантировать работоспособность парка устройств на протяжении всего срока его службы.
Чтобы возможность обновления была наиболее полезной, она должна быть автоматической, автономной и доступной через какое-либо сетевое соединение; обычно называется беспроводным (OTA), но это не обязательно подразумевает беспроводное соединение. Пользователи этих устройств не думают о них как о компьютерах, требующих обслуживания, а скорее как о устройствах, которые должны «просто работать». Если обновление требует вмешательства пользователя, то, вероятно, в вашем парке будет много устаревших устройств. Среди сфер применения, такие как медицинские устройства, где возможность подключения устройств может быть намеренно ограничена, но даже в этих случаях обновление должно быть автоматизировано настолько, насколько это возможно, например, когда устройство подключено к своей док-станции для зарядки.
Безопасность
Хотя безопасность не является целью этой статьи, было бы упущением, если бы мы не обсуждали ее хотя бы немного. Одна из самых больших угроз для любой программной системы – это возможность запускать произвольный код. Поскольку весь смысл системы обновлений OTA состоит в том, чтобы установить и запустить новый код в системе, необходимо проявлять особую осторожность, чтобы убедиться, что устанавливаемый код не был изменен и является ожидаемым образом для вашей системы.
Обратите внимание на следующие моменты:
- Физическая безопасность : у вас, вероятно, есть контроль над серверной инфраструктурой, поэтому убедитесь, что вы максимально заблокировали физический доступ. Однако учтите, что это вряд ли возможно для клиентских устройств.
- Шифрование транспорта : необходимо убедиться, что транспорт между клиентом и сервером правильно зашифрован. В идеале вы должны использовать правильную проверку сертификата TLS на обеих конечных точках, чтобы убедиться, что вы разговариваете с ожидаемым устройством.
- Проверка образа : вашим клиентским устройствам необходим механизм для проверки устанавливаемых образов. Для защиты от произвольной установки программного обеспечения следует использовать криптографическую проверку.
- Управление ключами безопасности : любая архитектура безопасности будет полагаться на какие-то ключи. Архитектура должна обеспечивать механизмы истечения срока действия старых ключей и смены новых ключей, а также соответствующую защиту ключей.
Существуют платформы с открытым исходным кодом, которые обеспечивают чрезвычайно безопасный дизайн, который вы можете использовать при реализации своей системы обновлений OTA. Framework Update и Uptane два заметных проекта, которые вы должны рассмотреть, если вам необходимо разработать систему пользовательских обновлений.
Существует множество проектов с открытым исходным кодом, которые реализуют системы обновления OTA, которые вы можете интегрировать в свой дизайн, чтобы избежать накладных расходов и рисков, связанных с проектированием вашей системы. Платформа Torizon – это проект, в котором мы сейчас участвуем, и он реализует полную систему OTA, как описано в этом посте. OStree предоставляет ограниченные функции безопасности, такие как криптографическая фиксация подписи и дельта-объектов. Torizon основан на архитектуре Uptane, обеспечивающей готовое высокозащищенное решение для сквозного обновления OTA.
Заключение
Мы обсудили, как объединить несколько проектов с открытым исходным кодом в качестве инфраструктуры для создания полностью автоматизированного комплексного решения для обновления OTA.
Использование OSTree в качестве основного хранилища операционной системы позволяет получить очень компактное решение и не требует использования полностью избыточных разделов. Он обеспечивает атомарные транзакционные обновления, что сокращает время простоя для пользователей устройства. OSTree был тщательно разработан, чтобы быть устойчивым к непредсказуемым циклам включения питания и допускать откат при обнаружении проблем с обновлением.
Использование контейнеров для стека приложений обеспечивает удобный механизм упаковки и доставки, которым можно управлять независимо от базовой операционной системы. Контейнеры относительно просты в использовании, и многие разработчики уже имеют навыки работы с ними. Вы можете выбрать базовый образ, соответствующий вашему настольному дистрибутиву Linux, что позволит вам работать в знакомой среде с богатым набором инструментов в вашем распоряжении. Или вы можете выбрать базовый образ, оптимизированный для контейнеров (например, Alpine Linux ), который должен быть небольшим и изначально более безопасным; в конце концов, самое безопасное программное обеспечение – это то, что не установлено.
Комбинирование контейнеров и OSTree дает разработчикам лучшее из всех возможных при рассмотрении воспроизводимости сборки, удобства сопровождения и гибкости. Использование системы, такой как Torizon, предоставляет готовое решение, использующее описанную здесь архитектуру. Это позволяет вам быстро приступить к разработке приложения, не беспокоясь о деталях обновлений OSTree, контейнеров и OTA, и при этом быть уверенным в том, что у вас есть надежное решение для управления сроком службы вашего парка устройств.
Обеспечение надлежащих обновлений для ваших устройств должно считаться обязательным для любого современного дизайна подключенных устройств. Риск для ваших пользователей и вашего бренда слишком велик, чтобы его игнорировать.
Выражаем свою благодарность источнику из которого взята и переведена статья, сайту cnx-software.com.
Оригинал статьи вы можете прочитать здесь.