Контейнеризация сред сборки и выполнения для тестирования в аппаратурном замкнутом цикле

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

Что такое контейнеры?

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

Независимо от размера операции, которую вы ведете в настоящее время, многие компании используют облако, чтобы не заниматься поддержкой физических серверов. В принципах DevOps мы всегда хотим гарантировать, что любое программное обеспечение, которое мы пишем, может быть собрано и запущено в любое время, в любом месте. Постоянное создание новых машин в облаке и установка программного обеспечения для компиляции, библиотек и других программных пакетов не масштабируется хорошо. Именно поэтому контейнеризация стала такой популярной. Мы можем взять нашу среду сборки (или среду выполнения), упаковать ее в очень легковесную виртуальную машину и доставить ее на любую машину для выполнения, будь то облако или наш личный компьютер.

Создание и использование контейнеров

Давайте рассмотрим, как на самом деле создавать и использовать эти контейнеры в ваших проектах. Когда мы впервые начинаем создавать образ контейнера, нам нужно начать с существующего «базового образа». В большинстве случаев подойдет какой-либо вариант операционной системы Linux, такой как Debian, Ubuntu или Alpine. Как только вы создадите свой Dockerfile, вы укажете образ так:

FROM ubuntu:latest

Это указывает, что в качестве базовой операционной системы будет использоваться последний образ Ubuntu Docker. После этого нам нужно будет установить все необходимые библиотеки для нашей среды сборки или тестирования. В одном примере репозитория я установил среду разработки Arduino с помощью менеджера пакетов Debian (Apt), а затем добавил дополнительные слои, установив драйверы платы Arduino Sam. Запуская этот контейнер в привилегированном режиме (или передавая точку монтирования устройства в качестве тома), я могу компилировать и загружать скетч Arduino через командную строку на совершенно новой машине, на которой установлен только Docker (т.е. без IDE или драйверов).

Part Insights Experience

Access critical supply chain intelligence as you design.

Learn More

Мы можем делать то же самое с машинами, которые подключены к нашим устройствам, подлежащим тестированию. В этом Docker контейнере, который я собрал, я установил все зависимости и программное обеспечение, необходимое для работы с устройством Analog Discovery 2. Теоретически, я могу запустить Docker контейнер на совершенно новой машине (на которой установлен только Docker) и начать общение с Analog Discovery 2 без всяких проблем. С помощью Analog Discovery 2 я могу писать тесты для проверки моих АЦП, ЦАП или отправлять команды I2C/SPI на разные чипы на моей плате (наряду с множеством других возможностей).

Масштабирование с помощью непрерывной интеграции

Теперь давайте обсудим, как контейнеры могут улучшить системы непрерывной интеграции, чтобы повысить эффективность и масштабируемость. Настоящая магия начинается, когда мы начинаем использовать контейнеры в сочетании с системами непрерывной интеграции (CI). У нас может быть десятки, если не сотни физических тестовых машин или доступ к тысячам облачных машин для наших серверов тестирования и сборки. Чтобы масштабироваться на практике, как упоминалось выше, мы не можем настраивать каждую отдельную машину по мере их подключения. Поставка контейнера с каждым запуском CI дает нам не только систематический, повторяемый способ выполнения сборок и тестов, но и освобождает нас от необходимости перенастраивать машину каждый раз, когда мы ее запускаем (что в облаке происходит почти при каждом запуске CI). Используя контейнеры для встроенных сборок и тестирования физического оборудования, мы обеспечиваем себе и нашим компаниям определенный уровень масштабируемости, о котором предыдущие поколения могли только мечтать.

Заключение

В этой статье мы подчеркнули критически важную роль контейнеров в разработке встроенных систем, особенно для обеспечения согласованных сред сборки и тестирования на различных типах инфраструктуры. Их интеграция с системами непрерывной интеграции не только упрощает разработку, но и повышает масштабируемость и надежность продукта. По мере развития технологии контейнеров их принятие станет все более важным для разработчиков. Погрузитесь глубже и экспериментируйте с различными настройками, посетив некоторые примеры репозиториев на https://gitlab.com/docker-embedded.