Konteneryzacja środowisk kompilacji i wykonania dla testowania sprzętu w pętli

Ostatnio otrzymuję wiele pytań na temat konteneryzacji środowisk do automatycznego testowania przy użyciu systemów Continuous Integration. Jeśli nie rozumiesz większości tego zdania, nie martw się, ponieważ zamierzamy dokładnie przyjrzeć się kontenerom, Dockerowi i jak wykorzystać je w Twoim środowisku wbudowanym oraz testowaniu sprzętu w pętli.

Czym są kontenery?

Istnieje wiele doskonałych opracowań na temat kontenerów, w tym to od Dockera (jednego z najpopularniejszych silników uruchomieniowych kontenerów). Kontenery w środowiskach budowania (np. systemy wbudowane) i środowiskach testowych (np. testowanie sprzętu w pętli) dają nam możliwość abstrakcji od całego bałaganu związanego z konfiguracją za każdym razem, gdy chcemy uruchomić nową maszynę. Nie chodzi tylko o nowe maszyny testowe, ale także o skalowanie naszej operacji w chmurze również do budowania wbudowanego firmware.

Niezależnie od wielkości operacji, wiele firm obecnie wykorzystuje chmurę, aby nie musieć zajmować się fizycznymi serwerami. W zasadach DevOps zawsze chcemy zapewnić, aby każde oprogramowanie, które piszemy, mogło być budowane i uruchamiane w dowolnym miejscu i czasie. Ciągłe uruchamianie nowych maszyn w chmurze i instalowanie oprogramowania kompilacyjnego, bibliotek i innych pakietów oprogramowania nie skaluje się dobrze. Właśnie dlatego konteneryzacja stała się tak popularna. Możemy wziąć nasze środowisko budowania (lub środowisko uruchomieniowe), spakować je do bardzo lekkiej maszyny wirtualnej i dostarczyć je do dowolnej maszyny do uruchomienia, czy to w chmurze, czy na naszym własnym komputerze osobistym.

Tworzenie i używanie kontenerów

Przyjrzyjmy się, jak faktycznie tworzyć i używać tych kontenerów w twoich projektach. Gdy zaczynamy tworzyć obraz kontenera, musimy zacząć od istniejącego „obrazu bazowego”. W większości przypadków wystarczy jakaś wersja systemu operacyjnego Linux, takiego jak Debian, Ubuntu lub Alpine. Po utworzeniu Dockerfile odwołujesz się do obrazu w następujący sposób:

FROM ubuntu:latest

To wskazuje, że systemem operacyjnym bazowym będzie najnowszy obraz Ubuntu Docker. Po tym będziemy musieli zainstalować wszystkie niezbędne biblioteki dla naszego środowiska budowania lub testowania. W jednym przykładowym repozytorium zainstalowałem środowisko Arduino IDE za pomocą menedżera pakietów Debian (Apt), a następnie dodałem więcej warstw, instalując sterowniki płyty Arduino Sam. Uruchamiając ten kontener w trybie uprzywilejowanym (lub przekazując punkt montowania woluminu do urządzenia) mogę kompilować i przesyłać szkic Arduino za pomocą linii poleceń na zupełnie nowej maszynie, która zawiera tylko Docker (tj. bez IDE lub sterowników).

Możemy zrobić to samo z maszynami, które są połączone z naszymi urządzeniami testowymi. W tym kontenerze Docker, który przygotowałem, instaluję wszystkie zależności i oprogramowanie potrzebne do uruchomienia urządzenia Analog Discovery 2. W teorii mogę uruchomić kontener Docker na zupełnie nowej maszynie (która zawiera tylko Docker) i zacząć komunikować się z Analog Discovery 2 bez żadnych problemów. Dzięki Analog Discovery 2 mogę pisać testy do walidacji moich ADC, DAC lub wysyłać komendy I2C/SPI do różnych układów na mojej płytce (wraz z mnóstwem innych możliwości).

Skalowanie z Continuous Integration

Teraz, porozmawiajmy o tym, jak kontenery mogą zwiększyć efektywność i skalowalność systemów Continuous Integration. Prawdziwa magia zaczyna się, gdy zaczynamy używać kontenerów w połączeniu z systemami Continuous Integration (CI). Możemy mieć dziesiątki, jeśli nie setki fizycznych maszyn testowych lub dostęp do tysięcy maszyn w chmurze dla naszych serwerów testowych i budujących. Aby skalować praktycznie, jak wspomniano powyżej, nie możemy konfigurować każdej pojedynczej maszyny, gdy są one uruchamiane. Dostarczanie kontenera z każdym uruchomieniem CI daje nam nie tylko systematyczny, powtarzalny sposób na przeprowadzanie kompilacji i testów, ale także uwalnia nas od konieczności rekonfiguracji maszyny za każdym razem, gdy jest ona uruchamiana (co w chmurze zdarza się prawie przy każdym uruchomieniu CI). Wykorzystując kontenery do wbudowanych kompilacji i testowania sprzętu fizycznego, zapewniamy sobie i naszym firmom pewien poziom skalowalności, o którym poprzednie pokolenia mogły tylko marzyć.

Podsumowanie

W tym artykule podkreśliliśmy kluczową rolę kontenerów w rozwoju systemów wbudowanych, szczególnie dla spójnych środowisk kompilacji i testowania na różnych typach infrastruktury. Ich integracja z systemami continuous integration nie tylko usprawnia rozwój, ale także zwiększa skalowalność i niezawodność produktu. W miarę postępów technologii kontenerowej, jej adopcja stanie się coraz ważniejsza dla deweloperów. Zanurz się głębiej i eksperymentuj z różnymi konfiguracjami, odwiedzając niektóre przykładowe repozytoria na https://gitlab.com/docker-embedded.