Вопрос или проблема
У меня есть встроенное устройство с Linux (сохранено в EMMC). Когда мне нужно обновить образ Linux (у меня есть один .img файл), я подключаюсь через последовательный терминал, редактирую boot_targets, чтобы запустить систему с SD-карты, а затем переписываю EMMC с хоста через команду dd. Но что если устройство находится в другом городе, и я могу подключиться к нему только через удаленный SSH?
Как я могу тогда обновить новый образ Linux?
Я попытался сделать копию существующей fs в tmpfs, но застрял на переносе существующей fs в tmpfs…
…только использовать удаленный SSH для подключения к нему.
Как я могу тогда обновить новый образ Linux?
Вы практически близки к решению. Вам нужно:
- система, способная работать с SSH, и
- не зависит от того, чтобы разделы данных были в рабочем состоянии.
Классическое встраиваемое решение для этого — иметь место, где можно подготовить новую систему, а затем перезагрузить для использования этой системы.
Вы можете подойти к этому разными способами; один из способов — “просто” иметь A/B загрузку, т.е. два разных корневых раздела. Один, с которого ваш Linux в настоящее время работает, “активный”. Обновление — это замена содержимого раздела, который в данный момент не используется (т.е. “пассивного”), затем указание загрузчику загрузиться с другого в будущем, затем перезагрузка, таким образом обмен ролей “активного” и “пассивного” раздела. (Или LVM тома, или чего-то еще, загрузчики Linux могут быть довольно гибкими в этом плане.)
Существует готовые решения для этого, или вы сами можете это запрограммировать. Есть механизмы, которые масштабируют этот принцип на целые флоты устройств, например https://mender.io, что позволяет вам выбирать, какие устройства обновлять, выполняя обновления волнами (чтобы в случае возникновения неожиданной проблемы вы не “бриковали” все устройства сразу).
Другие способы включают такие вещи, как капсулы обновлений, когда вы загружаетесь в конкретную, меньшую систему, которая обновляет один корневой раздел, который у вас есть — это может сэкономить много места, если обновления редко происходят в виде полного образа, но в основном представляют собой различия, применяемые к последнему образу.
Более современный подход для больших устройств, подключенных к интернету, — это образные ОС. Вы определяете наложения, содержащие файлы, которые затрагивает ваше обновление (включая такие вещи, как ядро и системные службы, а также их конфигурацию), развертываете их на встроенных устройствах, просто выполняя команду на них, которая извлекает наложение с вашего сервера, и устройства переключаются на них. Если что-то не получилось, просто удалите наложение, создав видимость, что ничего не произошло, а если все хорошо, вы консолидируете наложение и экономите место, имея только одну версию структуры каталогов, сохраненную на устройстве. В экосистеме Fedora, фреймворком для этого является rpm-ostree, а для встроенных устройств вы бы использовали дистрибутив Fedora IoT, портированный на ваше устройство.
Я предлагаю вам попробовать запрограммировать то, что вы обычно делаете. Скопируйте файлы (один из них может быть самим скриптом) на устройство, а затем запустите скрипт на устройстве, который делает то, что вы бы сделали вручную в противном случае.
Когда вам удастся это сделать, все, что останется, это:
- копировать файлы с помощью
scp/sftpвместо последовательного порта - вызвать скрипт через SSH
Ответ или решение
Обновление образа Linux на удалённом устройстве через Ethernet, особенно когда у нас есть только доступ по SSH, предъявляет определённые требования и ограничения. В основе задачи лежит необходимость одного обновления системы на устройстве, которое может находиться в другой географической зоне. Ваша текущая практика состоит в использовании последовательного терминала для редактирования загрузочной конфигурации, но давайте рассмотрим, как этого можно избежать, действуя лишь с помощью SSH.
Теория
Для обновления изображения операционной системы на удалённом устройстве с Linux (хранящемся в EMMC), важно, чтобы наше решение позволяло:
-
Управление доступом по SSH: Средства доступа позволяют изменять файлы и скрипты на удалённом устройстве, обеспечивая гибкость при выполнении различных команд.
-
Механизм безопасного обновления: Гибридный механизм, сочетающий возможность отката (rollback) в случае неудачного обновления, особенно важен для критических систем.
-
Обработка сбоя обновления: Необходимо предусмотреть средства мониторинга и отката, чтобы минимизировать влияние неудачных обновлений.
-
Скриптовое развертывание: Создание автоматизированных скриптовых решений, которые моделируют привычные физические действия через SSH и обеспечивают обновление системы без физического присутствия.
Пример
Один из практических методов, который можно привести в пример, это использование подхода A/B обновления. Этот подход состоит в использовании двух отдельных корневых разделов на устройстве: активного и пассивного. При подготовке обновления производится замена содержимого пассивного раздела. Затем устройство конфигурируется для загрузки из нового обновленного раздела при следующем перезапуске.
Этапы работы данной системы могут включать:
- Создание резервных копий данных или состояние системы перед началом обновления для возможности возврата.
- Копирование обновленного образа в пассивный раздел устройства.
- Изменение конфигурации загрузчика для загрузки с обновленного раздела.
- Перезагрузка устройства для проверки обновления.
Приложение
-
Подготовка удаленного устройства:
- Настройка SSH доступа и обеспечение стабильного подключения к сети.
- Убедитесь, что у вас есть все необходимые права для выполнения изменений на системе.
-
Разработка и создание скрипта:
- Разработайте скрипт, который автоматизирует шаги обновления, включая команды, которые вы обычно выполняете вручную. Это может включать команды для копирования файлов, изменения конфигураций загрузчика и перезагрузки устройства.
-
Безопасное копирование файлов:
- Используйте
scpилиsftpдля передачи обновлённого образа системы на устройство. Команда может выглядеть так:scp new_image.img user@device:/desired/path.
- Используйте
-
Запуск обновления:
- Подключитесь к устройству по SSH и выполните предварительно созданный скрипт. Это можно сделать следующей командой:
ssh user@device 'bash /path/to/update_script.sh'.
- Подключитесь к устройству по SSH и выполните предварительно созданный скрипт. Это можно сделать следующей командой:
-
Мониторинг и проверка:
- После выполнения скрипта и перезагрузки устройства проверьте, правильно ли работает обновлённое устройство. Важно проверить все основные функции, чтобы убедиться, что обновление прошло успешно.
-
План rollback в случае проблем:
- Настройте механизм отката для возврата к предыдущему рабочему состоянию в случае, если обновление приводит к ошибкам или неустойчивой работе системы. Это может быть реализовано через перегрузку устройства с предыдущего раздела.
Системы, которые поддерживают обновления по схемам A/B или используют решения, такие как mender.io, позволяют автоматизировать и обезопасить процессы обновлений, устраняя необходимость физического вмешательства при работе с большим количеством устройств. Такой подход особенно полезен в архитектурах, где устройства распределены по разным городам или даже странам, минимизируя риск человеческой ошибки и обеспечивая стабильность работы систем.