Docker sowie Docker-Compose sind auch f\u00fcr die ARM-Architektur und damit den Raspberry Pi verf\u00fcgbar. Meist werden sie zwar auf x86-Hardware eingesetzt. Doch auch auf dem Raspberry hat man zunehmend mehrere Anwendungen im Einsatz: Beispielsweise einen Anwendungs- oder API-Server, der in vielen F\u00e4llen nicht ohne Datenbank auskommt. Nicht selten m\u00f6chte man diese Daten auch noch grafisch darstellen, sodass eine Benutzerschnittstelle dazu kommt. Schnell haben wir mehrere Container, die bisher direkt auf dem Pi installiert wurden – wie auf einem klassischen Linux-Server.<\/p>\n
Durch die Verwendung von Containern k\u00f6nnen wir diese Anwendungen besser voneinander isolieren. Die Vorteile sind identisch wie auch auf klassischen x86 Systemen. <\/p>\n
Zun\u00e4chst legen wir einen Basisordner f\u00fcr das Projekt an und navigieren mit cd dort hin<\/p>\n
mkdir my-project\ncd my-project<\/code><\/pre>\nDie Trennung von Quellcode und weiteren Dateien wie Konfigurationsdateien hat sich bew\u00e4hrt. Daher ist zu empfehlen, einen weiteren Unterordner f\u00fcr den Source Code anzulegen. Oft wird er src<\/strong> genannt. Ich empfehle diese Konvention zu \u00fcbernehmen. Grunds\u00e4tzlich kann er aber frei benannt werden.<\/p>\nIn diesem Szenario handelt es sich um eine einzelne Anwendung, die wir selbst entwickeln. Dazu kommen Drittanbieter-Abh\u00e4ngigkeiten wie z.B. eine Datenbank. An dieser Stelle sollte man sich \u00fcberlegen, welche Komponenten die eigene Anwendung ben\u00f6tigt. M\u00f6chte man beispielsweise Backend und Frontend trennen (Eigenentwicklung der grafischen Oberfl\u00e4che) oder ben\u00f6tigt zus\u00e4tzliche Dienste wie einen Cron, macht es Sinn, diese direkt in Unterordnern aufzuteilen. Im folgenden Beispiel halten wir es einfach und legen nur einen src-Ordner an, der mit index.ts<\/strong> den Einstiegspunkt der Anwendung enth\u00e4lt. <\/p>\nmkdir src\necho "console.log('Hello World')" > src\/index.ts<\/code><\/pre>\nDocker-Compose Datei erstellen<\/h2>\n
In der ersten Ordnerebene (hier my-project<\/strong>) legen wir zun\u00e4chst eine docker-compose.yml<\/strong> Datei mit einem frei w\u00e4hlbaren Texteditor (z.B. vim) an. Sie definiert alle Dienste, die zu unserer Anwendung geh\u00f6ren und in getrennten Docker-Containern gestartet werden.<\/p>\nversion: '2'\nservices:\n app:\n build:\n context: src\n mem_limit: 256MB\n ports:\n - 80:80\n - 443:443\n<\/code><\/pre>\nHier definieren wir zun\u00e4chst nur einen Dienst f\u00fcr die Anwendung selbst. Diese k\u00f6nnte z.B. eine API bereitstellen. Weitere Container wie beispielsweise Datenbanken k\u00f6nnen nat\u00fcrlich hinzugef\u00fcgt werden, je nachdem was man ben\u00f6tigt.<\/p>\n
TypeScript mittels package.json installieren<\/h2>\n
NodeJS unterst\u00fctzt TypeScript nicht automatisch. Zun\u00e4chst muss der TypeScript-Kompiler installiert werden. Er erzeugt JavaScript, das NodeJS ausf\u00fchren kann. Der Kompiler ist im NPM-Paket typescript<\/strong> zu finden. Man kann ihn entweder mit<\/p>\nnpm i -g typescript<\/code><\/pre>\nglobal innerhalb des Containers installieren. Oder \u00fcber die lokale package.json<\/strong>. Ich empfehle letzeres, da man die package.json oft ohnehin f\u00fcr weitere Bibliotheken ben\u00f6tigt. Dadurch befinden sich alle Abh\u00e4ngigkeiten zentral an einer Stelle, statt in package.json und Dockerfile.<\/p>\nEine package.json Datei l\u00e4sst sich einfach mit npm init anlegen:<\/p>\n
npm init -y<\/code><\/pre>\nDurch den Schalter -y<\/strong> \u00fcberspringen wir die zahlreichen Nachfragen nach diversen Metadaten. Diese sind im Moment nicht wichtig und werden erst relevant, wenn ein NPM-Paket in einer Registry publiziert werden soll. F\u00fcr Bibliotheken ist das Standard, bei Anwendungen eher die Ausnahme. Soll dies sp\u00e4ter dennoch geschehen, k\u00f6nnen die betroffenen Felder einfach h\u00e4ndisch mit einem Texteditor in der erzeugten package.json Date erg\u00e4nzt werden.<\/p>\nNachdem die Datei angelegt ist, k\u00f6nnen wir TypeScript hinzuf\u00fcgen. Im einfachsten Falle ist auf dem Entwicklungssystem npm installiert, sodass wir einfach folgenden Befehl im gleichen Verzeichnis ausf\u00fchren:<\/p>\n
npm i --save typescript<\/code><\/pre>\nIst das nicht der Fall, einfach auf npmjs.com nach der aktuellsten stabilen Version des Paketes suchen. Zum Erstellungszeitpunktes dieses Artikels ist das 3.9.6 . Im Bereich dependencies<\/strong> der package.json folgende Zeile einf\u00fcgen:<\/p>\n"typescript": "^3.9.6"<\/code><\/pre>\nDadurch wird TypeScript in der angegebenen Version installiert, wenn wir sp\u00e4ter innerhalb unseres Containers npm install<\/strong> zur Aufl\u00f6sung der Abh\u00e4ngigkeiten ausf\u00fchren.<\/p>\nDockerfile f\u00fcr TypeScript\/NodeJS<\/h2>\n
Das Herzst\u00fcck unseres Containers ist das selbst erstellte Dockerfile<\/strong>. Es erzeugt die Umgebung, installiert alle notwendigen Abh\u00e4ngigkeiten und richtet diese passend zu unserer Anwendung ein. Im src<\/strong> Ordner \u00f6ffnen wir dazu die gleichnamige Datei ohne Endung und f\u00fcgen folgendes ein:<\/p>\nFROM node:lts-alpine\nWORKDIR \/app\nCOPY package.json .\nRUN npm install\n\nCOPY src .\nRUN npx tsc index.ts\nENTRYPOINT ["node", "index.js"]<\/code><\/pre>\nZeile 1 <\/strong>legt das offizielle NodeJS-Image als Basis fest. Die LTS-Version ist stabil und erh\u00e4lt am l\u00e4ngsten Updates. Wer m\u00f6chte, kann alternativ auch nat\u00fcrlich auch die neuste stabile Version einsetzen. Gerade f\u00fcr ein RPI-Projekt w\u00fcrde ich jedoch besser zur LTS-Version raten, sofern man nicht zwingend die dort fehlenden brandneuen Funktionen ben\u00f6tigt. Oft ist dies nicht der Fall.<\/p>\nDar\u00fcber hinaus verwende ich nicht das auf Debian bzw. Raspbian aufbauende Image, sondern Alpine. Dabei handelt es sich um ein minimalistisches Linux. Es ist mit wenigen MB deutlich schlanker als die anderen Distributionen. Das spart Speicher, verk\u00fcrzt Ladezeiten und reduziert auch die potenzielle Angriffsfl\u00e4che. Auch hier w\u00fcrde ich Alpine dem Vorzug geben, sofern nicht aufgrund von Abh\u00e4ngigkeiten explizit Debian\/Raspbian ben\u00f6tigt wird.<\/p>\n
In Zeile 2<\/strong> definieren wir das aktuelle Arbeitsverzeichnis im Container – vergleichbar mit dem cd Verzeichniswechsel. Der Ordner \/app<\/strong> hat sich als Quasi-Standard etabliert. Grunds\u00e4tzlich kann man den Pfad frei w\u00e4hlen. Er beeinflusst den Host nicht, da er nur innerhalb des Images und damit dem Container zur Verf\u00fcgung steht.<\/p>\nZeile 3<\/strong> kopiert die zuvor angelegte package.json Datei mit den Abh\u00e4ngigkeiten, w\u00e4hrend Zeile 4<\/strong> diese installiert. Das geschieht bewusst getrennt, weil Docker in mehreren Schichten arbeitet. W\u00fcrden wir es uns einfacher machen und den gesamten Ordner mit COPY . .<\/strong> kopieren, funktioniert das zwar. H\u00e4tte allerdings folgenden Seiteneffekt: Sobald eine Quellcode-Datei ge\u00e4ndert wird, m\u00fcssten auch die NPM-Pakete neu installiert werden – obwohl die package.json Datei unver\u00e4ndert ist. Als Folge erh\u00f6ht sich die Erstellungszeit deutlich. Den gesamten src-Ordner kopieren wir daher erst im Anschluss. <\/p>\nIn der vorletzten Zeile<\/strong> wird der TypeScript-Kompiler ausgef\u00fchrt. Er erzeugt aus index.ts<\/strong> eine JavaScript-Datei, die von NodeJS gestartet werden kann. NPX <\/strong>ist ein praktisches Werkzeug, um CLI-Pakete aus dem lokalen node_modules<\/strong> Ordner auszuf\u00fchren. Es erspart uns die h\u00e4ndische Suche im gleichnamigen Ordner. Au\u00dferdem kann es als Fallback auf global installierte Pakete zur\u00fcckgreifen, falls das gew\u00fcnschte nicht lokal verf\u00fcgbar ist.<\/p>\nDie letzte Zeile<\/strong> legt fest, welcher Befehl beim Start des Containers ausgef\u00fchrt werden soll. Standardm\u00e4\u00dfig erzeugt der TypeScript-Kompiler gleichnamige Dateien, die auf .js statt .ts enden.<\/p>\nImage erzeugen und Container starten<\/h2>\n
Mithilfe des Dockerfiles k\u00f6nnen wir nun ein Image bauen. Dies enth\u00e4lt alle Abh\u00e4ngigkeiten und Dateien, so wie von uns definiert. Es kann daher zum Starten eines (oder auch mehrerer identischer) Container verwendet werden. Hierzu f\u00fchren wir folgenden Befehl aus:<\/p>\n
docker-compose up --build<\/code><\/pre>\nEs dauert einen Moment, bis alle Schichten erstellt und der Container gestartet wurde. Am Ende sollte man folgende Ausgabe sehen k\u00f6nnen:<\/p>\n
Attaching to test_app_1\ntest_app_1 | Hello World\ntest_app_1 exited with code 0<\/code><\/pre>\nAn diesem Punkt wurde unsere index.ts Datei ausgef\u00fchrt. Das anschlie\u00dfende Beenden des Containers ist kein Fehler: Unser Skript erh\u00e4lt keinerlei weitere Anweisungen. Oft startet man hier einen l\u00e4nger laufenden Dienst, wie etwa einen Webserver. Im Gegensatz zu einer VM l\u00e4uft der Container nicht weiter, wenn es nichts zutun gibt. In dem Fall ist das kein Problem, weil es so beabsichtigt ist – der Container soll nur die Ausgabe t\u00e4tigen, nicht mehr und nicht weniger.<\/p>\n
Problematisch ist dies erst, wenn der Container einen lang laufenden Prozess starten sollte. Ein Datenbank-Container d\u00fcrfte sich beispielsweise nicht beenden, sondern muss dauerhaft laufen. Beendet er sich dennoch, besteht ein Konfigurationsfehler. <\/p>\n
Weitere Schritte und Verbesserungen<\/h2>\n
Nun haben wir eine einfache TypeScript-Anwendung containerisiert auf dem Raspberry Pi gestartet. Dies ist ein praktisches Beispiel f\u00fcr den Einstieg in Docker auf einem Einplatinencomputer. <\/p>\n","protected":false},"excerpt":{"rendered":"
Docker sowie Docker-Compose sind auch f\u00fcr die ARM-Architektur und damit den Raspberry Pi verf\u00fcgbar. Meist werden sie zwar auf x86-Hardware eingesetzt. Doch auch auf dem Raspberry hat man zunehmend mehrere Anwendungen im Einsatz: Beispielsweise einen Anwendungs- oder API-Server, der in vielen F\u00e4llen nicht ohne Datenbank auskommt. Nicht selten m\u00f6chte man diese Daten auch noch grafisch …<\/p>\n","protected":false},"author":5,"featured_media":6855,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[671],"tags":[167,817,639,816],"class_list":["post-6852","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-raspberry-pi","tag-javascript","tag-nodejs","tag-raspberry-pi","tag-typescript"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6852","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=6852"}],"version-history":[{"count":3,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6852\/revisions"}],"predecessor-version":[{"id":6856,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6852\/revisions\/6856"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/6855"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=6852"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=6852"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=6852"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}