Ook embedded software past in een container


Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13

Author:

Reading time: 6 minutes

Softwarecontainers zijn de afgelopen jaren snel populair geworden in de server- en pc-werelden, vooral omdat ze een lichtgewicht alternatief bieden voor virtualisatie en uitstekend binnen de devops-beweging passen. De aanpak begint ook door te dringen in het embedded-domein, echter met andere overwegingen.

Tiobe merkte eerder dit jaar een interessante trend op. Het bedrijf probeert, zo goed en kwaad als het gaat, de populariteit van programmeertalen te schatten door allerhande bronnen te combineren, zoals zoekopdrachten bij zoekmachines als Google en webwinkels als Amazon. En in die statistieken had het ineens een klein piekje zien verschijnen voor assembly, de primitiefste der talen.

Niet dat de taal in absolute termen een grote duit in het zakje doet, maar de ontwikkeling is opmerkelijk. De aanpak staat al jaren op hetzelfde niveau in de index. Steeds krachtigere hardware en voortschrijdende ontwikkeling van programmeertalen maken bovendien de noodzaak steeds kleiner om op zo’n laag niveau bezig te zijn met software. Paul Jansen, de beheerder van de lijst, heeft echter wel een verklaring: de opkomst van het internet of things. Die zorgt voor een grote toestroom aan low-level hardware waar soms teruggegrepen moet worden op assembly om er voldoende prestaties uit te persen.

Volgens de Tiobe-index wint assembly het laatste jaar plotseling aan populariteit.

Het omgekeerde is echter ook gaande: er komt steeds meer ‘low-level’ hardware beschikbaar die juist wel forse hardwarebronnen tentoonspreidt. Voor een paar tientjes zijn embedded bordjes te koop die op Linux draaien, via het netwerk benaderbaar zijn en de gpio-pinnen of spi-interface benaderbaar maken via scriptingtalen als Python of Javascript. Dergelijke hardware brengt veel programmeurs zonder expertise in het embedded-domein naar de embedded-wereld, en daarmee technieken uit de pc- en webwereld.

Een van die technieken is het concept van softwarecontainers. De afgelopen jaren maakte deze aanpak furore binnen de serverwereld als ‘lichtgewicht virtualisatie’. Kort door de bocht is een container een pakket waarin een applicatie met al zijn afhankelijkheden zoals bibliotheken en runtimes is verpakt, en voert het gastsysteem deze software uit in een afgeschermde omgeving.

In dat opzicht zijn containers dus vergelijkbaar met virtualisatie via een hypervisor. Technisch is het echter een compleet ander beestje. Een hypervisor is een softwaretoepassing die alle systeemaanroepen vertaalt naar het onderliggende os, waardoor het bijvoorbeeld mogelijk is om een Windows-kernel te draaien op een Linux-gastsysteem. In een container draait de software echter direct op het gastsysteem.

Dat heeft een aantal voordelen. Met containers is het niet nodig om een hele eigen kernel met softwarestack op te starten, wat een forse impact kan hebben op geheugen- en processorgebruik. Er is ook geen kostbare vertaalslag nodig van de systeemaanroepen. Bovendien laadt een os zoals Linux identieke kopieën van bibliotheken in verschillende containers slechts eenmaal in het geheugen – vaak worden containers op dezelfde basis gebouwd. Het nadeel is uiteraard dat alle software in de container geschikt moet zijn voor het onderliggende systeem. Linux kan alleen een container draaien als deze Linux-software bevat, voor de juiste processorarchitectuur.

Anders dan bij virtualisatie draait een toepassing bij containers direct op het gast-os, maar net als bij een hypervisor wel in een eigen afgeschermde omgeving.

Hoewel de techniek bepaald niet nieuw is, nam de populariteit de afgelopen jaren een hoge vlucht op Linux. Met name in de vorm van Docker, een opensource gereedschapskist voor containers ontwikkeld door het gelijknamige bedrijf. Ondertussen zijn daar diverse alternatieven bij gekomen.

Een belangrijke reden voor de populariteit is dat containers in veel gevallen een beter alternatief bieden voor virtualisatie: hetzelfde resultaat met minder belasting voor de hardware. Dat klinkt natuurlijk ook aantrekkelijk voor embedded systemen, die het met een stuk minder rekenkracht en geheugen moeten stellen. Maar het scenario is eigenlijk niet zo relevant voor de embedded-wereld.

In tegenstelling tot bij servers wordt virtualisatie namelijk slechts mondjesmaat toegepast in het embedded-domein. Als het al gebeurt, is dat doorgaans om een rijk os zoals Linux of Windows te combineren met realtime of missiekritieke functies. Het uitgebreide os draait dan als gastsysteem op een bare-metal hypervisor die rtos-functionaliteit biedt of nog een echt rtos als tweede gastsysteem draait. Traditionele embedded functies zijn hierdoor te combineren met een volledig os dat zorgt voor grafische interfaces, netwerkafhandeling en dergelijke. De container-aanpak werkt hier niet; containers draaien immers op een rijk os.

Uitgebreide boekhouding

Toch begint ook in het embedded-domein de interesse voor containers toe te nemen. Zo haalde de Britse start-up Resin.io eerder dit jaar negen miljoen dollar aan groeikapitaal op. Dit bedrijf heeft een systeem om iot-devices centraal te beheren gebaseerd op zijn Docker-versie voor embedded Arm- en Intel-platforms. Het heeft onder meer partnerschappen met Samsung en Microsoft.

Er zijn hier en daar wel meer voorbeelden. De Duitse specialist in industriële technologie Harting heeft een lijn van robuuste programmeerbare sensoren waarin containers een hoofdrol spelen. Qnap zet containers in voor platforms die met allerlei verschillende iot-sensoren moeten communiceren. Netwerkgigant Cisco wil via containers ‘apps’ mogelijk maken op zijn routers. Montavista biedt zelfs al jaren de mogelijkheid om containers te gebruiken op zijn automotive-Linux-platform.

Relatief nieuw is het initiatief van Canonical, de maker van de populaire Linux-distributie Ubuntu. Het bedrijf is in embedded Linux geen speler in de traditionele zin, zoals Montavista, Wind River of Mentor Graphics. Maar, meeliftend op zijn populariteit voor pc’s en servers, is het een belangrijke partij in doelgebieden zoals iot, robotica en drones.

Canonical heeft onlangs een iot-versie van Ubuntu uitgebracht waarin containers een hoofdrol spelen voor het distribueren van toepassingen. Dat vormt een breuk met de gebruikelijke gang van zaken op Linux, waarbij een uitgebreide boekhouding wordt bijgehouden van alle afhankelijkheden met hun versies die nodig zijn om een specifieke applicatie te installeren op het systeem. In Ubuntu Core worden applicaties als containers verscheept, samen met alle afhankelijkheden. Op den duur moeten ook de desktop- en serverversies aan deze aanpak geloven.

Harting biedt rugged sensoren die dankzij softwarecontainers intelligent gemaakt kunnen worden.

Barrières

Het container-concept brengt dan ook merites mee die niet gelijk opvallen als het alleen wordt gezien als alternatief voor hypervisors. Een andere reden voor Dockers succes is de devops-trend. Ontwikkel- en productieomgevingen kunnen nog weleens uiteenlopen: bibliotheken en ondersteunde tools hebben vaak niet dezelfde versie, instellingen kunnen uit veiligheidsoverwegingen verschillen, de software moet andere toepassingen tolereren, enzovoorts. Daardoor kan een applicatie die werkt op de ontwikkel-pc dienst weigeren op een productieserver.

Docker en consorten maken een einde aan deze problematiek – en de eeuwigdurende conflicten tussen ontwikkelaar en systeembeheerder. Afhankelijkheden en instellingen worden namelijk exact omschreven in scripts en configuratiebestanden. Identieke kopieën van de ontwikkelomgeving zijn geautomatiseerd aan te maken en draaien netjes naast alle andere containers. Bovendien is het zo een fluitje van een cent om servers bij te schakelen naargelang dat nodig is, al dan niet ingekocht bij een clouddienst.

Dit voordeel rond deployment is slechts in beperkte mate van toepassing op iot-omgevingen. Embedded systemen worden doorgaans toch wel volledig ingericht op een enkele specifieke toepassing en hoeven geen rekening te houden met vereisten van anderen. Bovendien zijn er doorgaans architectuurverschillen tussen de ontwikkel-pc en het doelplatform en ontbreekt de doelhardware in de ontwikkelomgeving.

Maar de vergaande vorm van automatisering en de mogelijkheid om alles vast te leggen in configuratiebestanden bieden wel een groot voordeel. Bijvoorbeeld om een team van ontwikkelaars allemaal met dezelfde configuratie van een embedded platform te laten werken, of gewoon om het platform uit te rollen naar tienduizenden targets. De tekstgebaseerde bestanden kunnen bovendien traceerbaar worden opgenomen in het versiebeheersysteem – ze worden min of meer onderdeel van de broncode.

Ook kan het container-concept de beveiliging van iot-devices verbeteren. In vergelijking met hypervisors bieden containers minder goede isolatie; toepassingen spreken het systeem op het laagste niveau aan en een beveiligingslek kan zich makkelijker uitspreiden naar andere toepassingen. Maar containers zijn op een heel andere manier te gebruiken. Doordat ze zo licht zijn, kunnen ze per applicatie worden ingezet. Communicatie met het systeem is alleen via gedefinieerde interfaces mogelijk, waardoor er barrières worden opgeworpen tussen de toepassingen in.

Nog een potentieel voordeel voor embedded systemen die verspreid in het veld staan, vaak op lastig bereikbare plaatsen: containers bieden de mogelijkheid tot atomic upgrades, zolang de kernel van het systeem niet vervangen hoeft te worden althans. Een container die de update bevat, wordt eerst in zijn geheel binnengehaald, en vervolgens wordt de oude versie stopgezet en de nieuwe gestart. Gevaar dat een half uitgevoerde upgrade het device brickt, is er zo niet meer.

Containers bieden dus ook in het embedded-domein een interessante gereedschapskist voor softwareontwikkelaars. Het is echter nog vroeg dag, en het zal moeten blijken op welk gebied ze precies een voordeel zullen opleveren. Daarvoor kan de embedded-wereld een beetje spieken bij zijn server-broertje, maar de vertaalslag naar het eigen domein moet wel worden gemaakt.