Schlagwort: Docker

ASP.NET MVC, Codespace & Docker

Webanwendungen mit ASP.NET MVC und Razor Ein kompakter und praxisnaher EinstiegIch habe eine neue Webseite erstellt. Das ist nicht ungewöhnlich und kaum eines Posts wert. Zumal die  Webseite nicht der Burner ist. Weder vom Design, noch dem Inhalt. Es ist im Grunde nur etwas Werbung für mein Buch zu „Webanwendungen mit ASP.NET MVC und Razor – Ein kompakter und praxisnaher Einstieg„, das ich vor einiger Zeit beim Springer-Verlag veröffentlicht habe. Also wozu der Hussle?

Nun – wenn man den Link zu der Webseite anklickt, fällt vielleicht der ungewöhnliche Port auf (33333). Der eigentliche Anlass für die neue Webseite war die Vorbereitung für eine Schulung mit ASP.NET im kommenden Januar. Ich will einfach einige Praxisseiten zum Zeigen von ein paar Sachen haben.

Ich betreibe meine Webseiten nun aber mit einem Apache-Webserver unter Linux. Die neue Webseite ist jedoch – aus besagten Gründen – mit ASP.NET MVC und Razor gemacht. Und das braucht – eigentlich – einen Windows-Server mit IIS oder so. Also auf jeden Fall .NET. Lokal auf einem Windows-PC bzw. direkt aus Visual Studio kein Problem. Aber wenn man „In-the-wild“ nur Linux verwendet? „ASP.NET MVC, Codespace & Docker“ weiterlesen

Vor Ort – oder doch lieber remote?

Aktuell bereite ich gerade für nächste Woche eine Cobol-Schulung vor. Auch wenn ich die letzten Wochen Vor-Ort-Schulungen gehalten habe – die Sache wird wieder remote laufen. Ebenso wie meine Videoaufnahmen für LinkedIn Learning in der übernächsten Woche. Für mich stellt sich mittlerweile die Frage, ob und wann meine Arbeit wieder ganz oder zumindest überwiegend auf „Präsenz“ umgestellt wird? Denn ich habe für die kommenden Wochen und Monate wieder Schulungsanfragen, die zwingend Vor-Ort laufen sollen. Zum Teil habe ich sie schon zugesagt. Aber Corona, die aktuell katastrophalen Rahmenbedingungen beim Fliegen (heute wird zusätzlich zu den total chaotischen Flughafenbedingungen durch den Urlaubswahnsinn sogar noch in FFM gestreikt), die permanent unzuverlässige Bahn sowie die explodierenden Benzinpreise bzw. allgemeinen Reisekosten lassen mich meine Zusagen bereuen und  überlegen, ob ich nicht konsequent auf „Remote“ bestehe? Vielleicht mit Ausnahme von Schulungen hier in der Umgebung, die ich u.U. sogar mit dem Rad anfahren kann (wie die letzten Wochen) und Videoaufnahmen bei LinkedIn Learning in Graz, denn ich will da unbedingt mal wieder hin. Aber ansonsten?

Ich muss Ende September nach Hamburg. Wie soll ich denn da hinkommen?

  • Inlandsflug? Theoretisch billig, gut und schnell. In der Praxis eine Umweltsauerei und besagtes Chaos an den Flughäfen lassen das im Grunde als Option nicht zu.
  • Bahn? Das klappt bei mir einfach nie. Mein Sohn hat letzte Woche wieder 5,5 Stunden für eine Strecke gebraucht, die nach Plan 90 Minuten dauern sollte, ich habe mein letztes Ziel vor 3 Wochen (Marburg) gar nicht erreicht, weil es einfach in Giessen nicht mehr weiterging, Anschlusszüge erreiche ich sowieso fast nie und ich kann nicht mehr zählen, wie oft meine Fernzüge unterwegs stehengeblieben sind.
  • Auto? Bei den Kosten, den Staus durch die vielen Baustellen und auch wegen der Umwelt wirklich nicht gut. Nach HH sind es weit über 500 Km und da brauche ich ja 6 – 7 Stunden einfach.

Ich liebe HH und das war mit ein Grund, warum ich diese Maßnahme Vor-Ort zugesagt habe, aber ich hoffe dennoch, dass Corona die Sache auch für den Kunden auf Remote zwingt. Doch die Kunden wollen eben wieder verstärkt von Remote weg. Gestern habe ich von einem Schulungspartner, für den ich die letzten Wochen UML und Java bei Fachinformatikern geschult habe, einen Hilferuf bekommen. Denn rein zufällig soll er in einigen Tagen für einen Teil dieser Gruppe eine Cobol-Schulung halten. Mein Schulungspartner ist nun Cobol-Spezialist und macht das seit gut 35 Jahren – früher Host und mittlerweile unter Linux. Er ist also in Cobol fitter wie ich und der Hilferuf ging nicht um konkrete Cobol-Fragen und auch nicht darum, ob ich das übernehmen könne.

Es ging darum, dass beim Kunden neue Corona-Regeln in Kraft getreten sind. Die Gruppe, die Cobol in den Räumlichkeiten des Kunden (einer Bank) lernen soll, besteht aus 4 Fachinformatiker-Azubis und dem Trainer (besagtem Schulungspartner). Wenn in der Schulungszeit auch nur ein Corona-Fall bei einem der 5 Leute auftritt, besteht für die gesamte Gruppe ein Betretungsverbot der Räumlichkeiten des Kunden für die kommenden 5 Tage. Nun hatte ich die Azubis ja über die letzten 5 Wochen immer 2 Tage die Woche in einer Berufsschule unterrichtet und ständig hat jemand wegen Corona gefehlt. Ich selbst habe am letzten Tag auch ein Andenken mitgenommen – trotzt Mehrfachimpfung/Boostern. Was mir nur zufällig aufgefallen war, denn meine Symptome waren so, dass ich normalerweise nie auf die Idee gekommen wäre, mich zu testen oder gar krankzufeiern. Rein die Sensibilität aufgrund des Corona-Hotspots Schule hat dazu geführt, dass mir die Möglichkeit überhaupt in den Sinn gekommen ist. Aber sei es drum – auch wenn die aktuelle Corona-Variante wohl bei 99,9% der Infizierten entweder nicht bemerkt wird oder nicht an die Auswirkungen eines Sommerschnupfens heranreicht – wenn so strikte Zugangsregeln bzw. Isolationsregeln etc. gelten – wie soll man dann noch Maßnahmen vor Ort planen können?

In dem Fall meines Schulungspartners ist die Planung einfach – sie werden vor Ort beginnen (erzwungen vom Kunden) und dann ist es nur die Frage, an welchen Tag abgebrochen wird. Der einzige Grund, warum das im besten Fall durchgehen kann ist, dass die Azubis Ihre Corona-Infektion bei mir in der Schulung bereits hatten und gerade immun sind. Bis zur nächsten Variante des Virus. Aber wie gesagt – vermutlich wird die Schulung abgebrochen und dann muss halt auf remote umgestellt werden. Theoretisch. Denn im Fall von Cobol wird das auf dem Host verwendet oder unter Linux, die Azubis müssen aber im Remote-Fall Notebooks der Firma verwenden, unter denen dann ein Host-Zugriff oder Linux und die verwendete Cobol-Distribution nicht laufen. Der Kunde lässt also Remote quasi technisch scheitert, verbietet aber Vor-Ort mit hoher Wahrscheinlichkeit. Quadratur des Kreises.

Um kurz abzuschweifen – ich habe OpenCobolIDE, MinGW und ein Docker-Image für Cobol als Lösung vorgeschlagen, um Cobol dann unter Windows bei den Azubis zum Laufen zu bringen und gerade die Sache mit dem Docker-Image gestern erstmal selbst getestet, um das nächste Woche selbst neu in meine Schulung zu integrieren. Geht wunderbar und ist quasi die Verbindung der Vergangenheit (Cobol) mit der Gegenwart (Docker). Genau da sehe ich auch in meiner sehr Laienhaften Betrachtungsweise den Hauptsinn von Docker, denn so nutze ich Docker ja auch für Cordova bei meinen Vorlesungen an der TH Bingen.

Aber um die Sache zum Abschluss zu bringen – ich habe die letzten Wochen Kundenwünschen nach Vor-Ort-Maßnahmen wieder zugestimmt, werde das aber beenden. Solange ich es mir leisten kann, werde ich wieder auf reines Remote zurückgehen. Die fehlende Planungssicherheit, die aktuell unmöglichen Reiseumstände und auch, dass mich Corona trotz Boostern und extremer Vorsicht erwischt hat (auch wenn ich keine wirklichen Symptome mitgenommen habe), geben mir keine andere Wahl. Freiberufliche Arbeit muss extrem flexibel sein und richtig planen kann man nie – aber so extreme Unsicherheit ist mir zu viel. Zumal auch das gesamte Risiko bei mir liegt. Wenn ich Corona bekomme, muss ich die Maßnahme abbrechen. Entweder weil es der Kunde oder die Politik immer noch 5 Tage Isolation fordert – auch ohne Symptome (da ist Deutschland leider noch nicht so weit wie etwa Österreich, wo diese Maßnahme endlich abgeschafft wurde). Remote arbeite ich einfach weiter. Oder die Maßnahme wird abgebrochen, weil irgendjemand in der Gruppe Corona hat. Das explodierende Risiko von Reiseproblemen muss ich auch noch tragen. Nein, so geht es einfach nicht, wenn auf der anderen Seite Remote alles einfach und sicher macht.

Flottenzuwachs – oder nicht?

Ab heute gibt es einen LKW in meinem Flottenbestand. Oder auch nicht. Zu dem Forester, den ich als Geschäftswagen verwenden, und dem Trek-MTB sowie dem eBike (von der W800 will ich gar nicht reden) nenne ich jetzt einen Dacia Docker mein. Genaugenommen wollen den meine Söhne überwiegend fahren, aber ich schaue mal, ob ich den auch als 2. Geschäftswagen ansetzen kann. Der Einsatzzweck von dem Dokker, der als LKW zugelassen ist, ist ja definitiv ein anderer als der Einsatzzweck eines PKW. Aber das muss ich mit dem Steuerberater klären. Durch Corona fahre ich ja sowieso nicht mehr so viel und da muss das alles durchkalkuliert werden – auch wegen der beiden Fahrräder, mit denen ich immer mehr zwischen meinen beiden Standorten pendle.

Meine Söhne wollen aus dem Dacia einen Minicamper machen und mir schwebt in der Tat vor, dass ich bei externen Jobs, bei denen die Übernachtung nicht vom Kunden übernommen wird, darin auf dem Campingplatz übernachte. Das spart Geld, aber vor allen Dingen hat das was von Urlaub, wie ich ihn früher ausschließlich gemacht habe. Und das mit Enten (2 CV), Motorrad oder gar Fahrrad und Zelt. Da wäre ein Mini-Camper auf dem Level sogar Luxus und zudem ein Argument, warum ich ihn auch steuerlich anrechnen lasse. Denn die Kosten für Hotelübernachtungen sind höher und das wäre dann sogar im Sinn des Finanzamtes. Mal sehen.

Aber so richtig ausgegoren ist das noch nicht, wenngleich im August ein Auftrag in der Schweiz in Aussicht steht, bei dem sich das ideal anbieten würde – wenn der Auftrag denn kommt. Auch als mobiles Büro könnte das ausgebaute Fahrzeug Sinn machen, wenn ich private Dinge erledige und zwischenzeitlich was arbeiten muss.

Das Teil hat zwar schon unendlich viele Kilometer auf dem Tacho, ist aber noch recht neu, 1. Hand und super gepflegt. Dazu zwar technisch und im Inneren altbacken und „preiswert“, aber im Grunde absolut vollständig ausgestattet. Da wir ihn für kleines Geld bekommen haben, sollte das kein Fehlkauf sein und da das auch hauptsächlich das 1. Auto meiner Kidds wird – so luxuriös war mein erstes Auto damals nicht. Auch wenn der Komfort in der Tat etwas an einen kleinen LKW erinnert, was ich bei der Überführungsfahrt nach Hause gerade gemerkt habe.

Was ein Gefuddel für Android

Nachdem mir die Raspberry PIs als auch vergleichbare Platinen im Moment einfach zu teuer sind, habe ich mich daran gemacht, ein uraltes Notebook, dass ich vor einigen Monaten mit Deepin Linux neu eingerichtet habe, für die Cordova-Entwicklung einzurichten. Das ist zwar fertig, liegt aber sowieso da rum und einen Test war es mir wert.

Im Grunde geht das Einrichten von Cordova ja auch recht einfach, wenn es nicht die elenden Fallen geben würde.
Einmal ist da im Fall von Android das Problem mit der Java-Version. So richtig geht es – falls man für Android die App erstellen will – nur mit Java 8 bzw. dem JDK 8. Das Problem habe ich schon vor gefühlten Ewigkeiten bemerkt und mir immer damit geholfen, dass ich eben Java 8 installiert habe. Neben den aktuellen Versionen. Leider ist es dann aber blöde, weil man für Gradle-Skripte (zumindest die vorgefertigten von Cordova) die Default-Version von Java auch auf eben dieses Java 8 umstellen muss. Das geht in Linux (Debian, Ubuntu, Mint und Derivate) so:

sudo update-alternatives --config java

In der Folge kann man zwischen den installierten Java-Versionen auswählen und eine davon zur Default-Version machen. Aber dann muss man dann auch noch JAVA_HOME korrekt setzen. Etwa so:

env JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

export JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

Ging unter Deepin als normaler User, aber komischer Weise hat das als root nicht funktioniert bzw. die Einstellungen wurden nicht übernommen. Letztendlich habe ich viel rumgebastelt, wieder viel gelernt, bin aber wie so oft im Grunde gescheitert.
Wobei das Problem mit Java 8 ist vermutlich ein ganz anderes, als man vermutet. Denn vor einigen Monaten hatte ich eine Schulung rund um Java EE gehalten und da hatten wir bei JSF ein ähnliches Problem. Die Meldung sah so aus als wäre die Version von Java nicht passend bzw. zu alt, obwohl sie neuer als die geforderte/angezeigte Version war. Ganz wie hier bei Cordova. Aber dann ist mir aufgefallen, dass die Versionsnummern in dem Framework nur einstellig (!) evaluiert wurden. Also Java 11 oder Java 17 werden als Java 1 interpretiert. So was vermute ich mittlerweile auch bei Cordova bzw. den Gradle-Skripten. Man müsste es mal mit Java 9 testen, aber dazu habe ich im Moment keine Zeit.
Letztendlich ist aber sowieso das Hauptproblem dieses elende Android-Gefuddel. Das Android-SDK und die Android-Tools etc. habe ich nach und nach alle installiert, aber ständig kam die Meldung, dass das Zeug nicht da wäre. Genaugenommen hat das Gradle-Skript diese Meldung gebracht. Letztendlich habe ich sogar das Android Studio auf dem uralten Notebook mit Deepin installiert, dort diverse Fernzugriffservice eingerichtet und gestartet, alle möglichen SDK-Versionen nachinstalliert und sogar ein Cordova-Template im Android Studio als Plugin eingerichtet.
Resultat – das Gradle-Skript weigert sich, die Android-Ressourcen zu finden. Und selbst das Android Studio nimmt dieses Gradle-Skript und kennt sich quasi dann selbst nicht mehr.

Irgendwann hatte ich die Faxen dicke, denn so schön Deepin Linux von der Oberfläche auch ist – es hat so ein paar Macken, die ich von der administrativen Seite nicht wirklich gut finde. Und der VNC- als auch RDP-Zugriff haben darauf ums Verrecken nicht funktioniert. Nur ssh – auch mit X-Umleitung von einem anderen Linux-Rechner.
Apropos anderer Linux-Rechner – das ist mein Terra-Notebook, auf dem ich Windows 10 und Mint Linux im Dualboot betreibe. Unter Windows habe ich das Cordova (auch für Android) mit Visual Studio 2017 im Griff (und im Prinzip auch mit dem Android Studio – das macht aber keinen Spass). Die Linux-Version kann ich aber seit Monaten nicht mehr aktualisieren oder da ein Programm installieren. Die Sache hier war für mich der Anlass, dass Problem mal anzugehen. Denn egal was ich probiert habe die letzte Zeit – mit der Fehlermeldung, dass die Quellen nicht zu lesen wären, haben sämtliche Aktualisierungsversuche als auch Installationsversuche abgebrochen.
Ich bin nun auf den Lösungsansatz gestoßen, dass man die Datei mit einem geeigneten Repo füllen sollte. Etwa das:

sudo nano /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu bionic main restricted

Habe ich gemacht – keine Wirkung!
Dann habe ich endlich die Meldung genauer angesehen – Linux hat nicht die Datei /etc/apt/sources.list beim Installieren/Aktualisieren ausgelesen, sondern die Datei /etc/apt/sources.list.d/vivaldi.list.
Aus irgendeinem Grund wurde der Pfad umgebogen. Wo genau, habe ich noch nicht raus, aber einfach das Repo da reingeschrieben. Und gut ist es – aktualisieren und installieren geht wieder.
Jetzt kann ich auch mal den Linux-Rechner nutzen und versuchen, da Cordova-Apps für Android zu kompilieren. Wenn das auch da nicht geht, habe ich ja immer noch Visual Studio 2017 und meinen Docker-Container.

Und so ganz unwahrscheinlich ist es nicht, dass ich darauf beschränkt bleibe. Denn bei dem Mint-Linux ist node.js und damit auch npm in einer alten Version dabei. Was nicht schlimm wäre, wenn nicht jede Art der Installation, die ich versucht habe, immer diese uralte Version 8 installiert hätte. Mit apt bzw. apt-get entfernt, neu installiert, andere Quellen genommen, verschiedene Package-Manager ausprobiert -> immer die Version 8, obwohl es schon die Version 18 gibt. Ein Problem führt bei den ganzen Aktionen – wie eigentlich immer – zum nächsten.

Ich bin jetzt auf das Level zurückgegangen, dass ich die Quellcodes von Git geholt und dann bei mir neu kompiliert und installiert habe.

Also klassisch

git clone https://github.com/joyent/node.git

Und dann:

./configure
make
make install

Dazu gibt es im Netz eine ziemlich gute Anleitung.

Der kleine Hinweis dort, dass das Kompilieren ein „bisschen länger“ dauert, war aber untertrieben. Ich bin mit der Erwartung von vielleicht 30 Minuten maximal in den make-Befehl rein und nach gut 5 Stunden war noch kein Ende zu sehen. Das Zeug ist dann über Nacht durchgelaufen und heute morgen war es erledigt. Das dauert also brutal lang, wobei mein Terra-Notebook auch schon in die Jahre gekommen ist.

Anyway – die Sache ging durch und nun habe ich node.js bzw. npm in der Version 18. Cordova ist damit auch eben fix installiert und wie es mit Android aussieht, schaue ich mir später an. Das ist ja die einzige kritische Stelle.

 

Preisexplosion beim Raspi

Ich muss zugeben, dass ich mir lange keine Preise für Hardware angesehen habe. Und schon gar nicht für den Raspberry Pi. Hin und wieder krame ich meinen alten Raspi der Version 1 raus und experimentiere damit rum. Aber die Version 1 ist wirklich so schwach auf der Brust, dass man damit eigentlich nur testen kann, welche Minimalhardware für gewisse Dinge notwendig ist und dabei braucht man viel Zeit und Geduld, bis die Programme starten bzw. fertig sind. Und wirklich nützliche Anwendungen habe ich in dem Bereich wenig gefunden, weil ich keine Hardwaresteuerung programmiere. Einzig die Ausführung von einem Python-Skript zur Spamabwehr ist derzeit eine produktive Anwendung des kleinen Raspi. Aber obwohl ich immer noch unter massivem Spambeschuss stehe, haben sich mittlerweile wohl die Antispam-Cloud-Dienste und die internen Spam-Abwehrmechanismen auf die neue Art des Spams eingestellt, die vor einigen Wochen wie eine Schlammlawine durchs Netz gewalzt ist. Der Raspi hat also als Torwächter wieder weniger zu tun. Bei einer anderen Anwendung hat aber die extrem schwache Hardware die Hürden nicht geschafft. Ich wollte für die kommende Cordova-Vorlesung, die ich an der TH Bingen ab übernächster Woche halte, ein Linux-System so konfigurieren, dass Cordova-Android-Apps kompiliert und nach Möglichkeit auch in einem Emulator (oder zur Not auf einem per USB angeschlossenen SmartPhone) ausgeführt werden. Da für Cordova eine ganze Reihe an recht alten Bibliotheken (JDK 8) auf der einen Seite und den elend vielen Ressourcen im Fall von Android auf der anderen Seite verlangt werden, ist meine Workstation nicht passenden konfiguriert – von meinem Matebook mit der kleinen SSD ganz zu schweigen. Und ich habe keine Lust, nur für die Vorlesung meine gesamten Konfigurationen durcheinander zu bringen und zig Sachen da zu installieren, die ich sonst nicht mehr brauche.

Zwar habe ich einen passenden Docker-Container noch von der letzten Vorlesung vorbereitet und auf den neusten Stand gebracht und auch mein altes Terra-Notebook hat Cordova sogar mit Visual Studio verfügbar (das geht maximal bis Visual Studio 2017 und das habe ich aus dem Grund auch noch auf dem alten Notebook gelassen). Aber unter meinen Linux-Systemen klappt die Installation von Cordova und den Android-Ressourcen nicht so richtig. In dem parallel auf dem alten Notebook installierten Linux ist irgendwas zerschossen und ich kann gar keine Aktualisierungen vornehmen. Das muss ich vermutlich komplett neu aufsetzen. Und bei den virtuellen Maschinen habe ich sowohl bei VM Ware als auch VirtualBox eine Reihe von anderen – und ganz verschiedenen – Problemen. Alles nix Tragisches, aber es kostet Zeit und wenn ein Problem gelöst ist, kommt das nächste. Unbefriedigend und es raubt Zeit.

Da kam mir die Idee, entgegen meiner bisherigen Planungen vielleicht doch einen neuen Raspi zu kaufen und den als Linux-System ins lokale Netz zu hängen und je nach notwendigem Ziel immer wieder neu aufzusetzen. Also so eine Art Hardware-Docker-Container-VM-Ersatz. Ich hatte für den ersten Raspi so um die 35 – 40 EUR ausgegeben, bin mit der Erwartung gerade auf die Suche gegangen und fast vom Glauben abgefallen. Die wollen ja teils weit über 200 EUR für die Platine mit ein bisschen Krimskrams dazu. Ne, wirklich nicht. Das hat ja gar nichts mehr mit der ursprünglichen Idee einer möglichst billigen Platine zu tun. Ich schaue mal weiter oder vielleicht gebe ich doch alternativen Platinen eine Chance, bei denen nicht noch zusätzlich ein Hype die Preise hochtreibt. Oder lasse es.

Derzeit kann man wohl weder Sprit bzw. Öl als auch Hardware kaufen. Benzin muss leider ab und zu sein (auch wenn ich weniger fahre und zudem wenn möglich auf das Rad oder eBike umsteige), aber Hardwarekauf kann verschoben werden, bis die Preise wieder normal sind.

Der erste neue Tipp des Jahres

Nachdem es zwischen den Jahren keinen neuen Tipp gab, wurde heute bei LinkedIn Learning wieder der nächste regelmäßige Entwickler-Tipp zu Python freigeschaltet. Der erste Tipp im Jahr 2022. Dieses Mal verbinde ich die Themen Python und Docker. Gerade mit Docker habe ich ja Anfang letzten Jahres etwas mehr beschäftigt, um eine Cordova-Umgebung für meine Vorlesung bei der TH Bingen bereitzustellen. Damit kann man ja alle möglichen verschiedenen Konfigurationen und Systeme bereitstellen, ohne immer wieder seinen Rechner umkonfigurieren zu müssen. Auch für Python.

Wenn man Docker installiert hat, dann kann man ein Python-Image laden und auf dem Rechner installieren. Das heißt, man hat eine virtuelle Laufzeitumgebung für Python. Das ist vor allen Dingen dann interessant, wenn man verschiedene Versionen von Python benötigt. Dazu muss allerdings auf dem Rechner Docker installiert sein. Das Zusammenspiel zwischen Python und Docker geht in zwei Richtungen. Nicht nur kann man mit Docker eine Python-Umgebung, eine virtuelle Python-Umgebung schaffen, es gibt auch die Möglichkeit, ein Docker-SDK für Python zu installieren.

JSF/MyFaces, Microservices, Maven & Co

Ich habe die ersten drei Tage der Woche eine Einzelschulung zu erweiterten Java-Themen gehalten. Es ist kaum zu glauben, aber das war die erste Live-Schulung seit 1,5 Jahren. Obwohl ich in der Zeit sogar sehr viele Schulungen gehalten habe, waren sie allesamt online.
Bei der Schulung ging es grob gesagt um Java. Aber keine Einsteiger-Themen, sondern um eine Betrachtung diverser Themen im Java-Umfeld samt Web für einen erfahrenen Programmierer, der sich mit den Techniken bereits auskennt. So Sachen wie

  • JUnit, Git und Github,
  • Maven und andere Build-Tools wie Gradle und Ant,
  • Docker,
  • Übersicht neue Java-Techniken (vor allen Dingen Lambda-Ausdrücke, Closures und das Modulsystem)
  • JavaFX/OpenJFX/FXML
  • Ausblick Mobile, Android Studio, Cordova
  • Tomcat bzw. Java-Container als Server (Wildfly)
  • JSP/Servlets/JSF
  • Refactoring
  • Microservices (Spring)

Bei der Anfrage hat mich allerdings das Thema JSF (Java Server Faces) doch schwer verwundert. Ich hatte in der Vergangenheit JSF durchaus mehrfach geschult, aber seit Jahren eigentlich nichts mehr damit zu tun. Und ich bin davon ausgegangen, dass das Thema JSF eigentlich ziemlich out ist. So hatte ich das auch schon vor einigen Jahren beurteilt und mich deshalb aus dem Themenkomplex weitgehend zurückgezogen. Die vereinzelten Anfragen zu JSF-Kursen habe ich auch immer abgelehnt. Überhaupt sah und sehe ich bei den Java-Frameworks für das Web eigentlich nicht (mehr) das große Potential. Weder bei JSF (oder gar Servlets/JSP), noch Spring oder Struts.

Aber mein Teilnehmer wechselt demnächst beruflich als IT-Leiter in eine Behörde, die wohl mit JSF 2.3 arbeitet. Alttechnologien halten sich oft ewig. Ich habe ja auch einen Standardkunden, der noch mit Cobol arbeitet.

Da diese Schulung als eine Art Workshop mit Wissensaustausch gewünscht war und JSF etc. nur einen Teil der Agenda ausgemacht hat, habe ich die Sache angenommen. JSF und Web haben wir dann auch geschlossen am dritten Tag abgearbeitet.

Rückblickend war es auch verdammt spannend, sich wieder in die Welt von JSF einzuarbeiten. Wobei dabei uns beim Voranarbeiten ganz interessante Phänomene untergekommen sind, von denen mir immer noch nicht ganz klar ist, ob wir auf den Grund der Tatsachen getaucht sind oder uns verirrt haben.

Gerade bei Java im Web-Umfeld ist m.E. erst einmal die Konfiguration die größte Einstiegshürde. Vor allen Dingen, wenn man da nicht täglich am Schaffen ist. Das fängt schon mit der Konfiguration der Server an. Ganz banal bei der lästigen Tomcat-Einstellung in der Datei tomcat-users.xml, wo mit

<role rolename="manager-gui"/>

<user username="admin" password="admin" roles="standard,manager-script,manager-gui" />

erst einmal freigeschaltet werden muss, dass der Server über das Webinterface administriert werden kann und war-Dateien überhaupt deployed werden dürfen. Mit Wildfly ist es auch nicht einfacher bzw. bequemer.

Da Maven in der Schulung ein großes Thema war, haben wir viel mit Architypes gearbeitet. Auch bei JSF, was wir in der Version 2.3 als Basis genommen haben. Neben den Schablonen in Netbeans und Eclipse, die mit Maven, Ant oder Gradle arbeiten.

Neben dem elenden Konfigurieren über die web.xml und die faces-Konfigurationsdateien gab es ganz ungewöhnliche Probleme mit dem Kompilieren bzw. Deployen der Projekte. Vor allen Dingen Projekte, die ich schon zum Laufen gebracht hatte, als auch die generierten Projekte aus den POM-Dateien wurden vielfach nicht übersetzt oder konnten nicht auf den Tomcat depoyed werden. Teils gingen auch die SSI-Dateien mit den Tag-Libs, aber alleine die Existenz einer Java-Datei im Projekt hat die Übersetzung blockiert. Nicht einmal als Bean oder Controller gebaut, sondern eine leere Klasse im source-Verzeichnis hat genügt, um einen Fehler zu erzwingen.
Andere Projektkonfigurationen haben die Java-Controler und -Beans übersetzt, aber die xhtml-Dateien wurden auf dem Server nicht geparst und damit die Tag-Libs nicht verarbeitet.
In Netbeans gab es bei dem Problemen mit dem Java-Code die unverständige Fehlermeldung, dass source in der Version 6 nicht mehr unterstützt wird und wir die Version 7ff nehmen sollten. Nach diversen Problemen habe ich auf mein Matebook als Ursache getippt, aber auf dem Teilnehmerrechner waren die Fehler exakt reproduzierbar.
Irgendwann hatte ich die Faxen dicke und habe auf einem alten Linux-Rechner die Geschichte von Grund auf neu aufgesetzt. Also zuerst Maven, was noch nicht da installiert war, und dann einen Architype für JSF mit der Konsolenanwendung mvn aus dem Internet gezogen. Damit hat die Sache von A bis Z funktioniert und mir ist aufgefallen, dass ich auf dem Linux-Rechner das OpenJDK 8 installiert habe. Auf unseren beiden anderen Rechnern allerdings das JDK 16 und bei meinem Teilnehmer das JDK 15. Und danach haben wir endlich in einer Konfigurationsdatei zu den JSF 2.3 die XML-Tags gefunden, dass die Entwickler- als auch Zieldatei auf Java 8 festgelegt ist.
Unter dem Gesichtspunkt macht auch die Fehlermeldung von Netbeans Sinn – es müsste bei mir eigentlich heißen source in der Version 16, aber das Feld für die Versionsnummer wurde wohl nur einstellig konzipiert. Aus der 16 wurde die 6 und damit eine vollkommen unsinnige Fehlermeldung. Aber zum Zeitpunkt, wo die JSF 2.3 konzipiert wurden, hatte man vermutlich nicht an Inkompatibilitäten in so hohen Folgeversionen, sondern nur älteren Versionen, gedacht. Wir sind nicht so ganz sicher, ob die JSF bis zur Version 2.3 mit den neuen JDK nicht mehr klar kommen, aber ich denke schon. In der Doku steht explizit auch die Version 8. Das deckt sich mit der Tatsache, dass Cordova auch nur bis zur JDK-Version 8 funktioniert. Das habe ich ja in meiner Vorlesung an der TH Bingen die Tage behandeln müssen.
Die JSF werden wohl als Apache MyFaces weiterentwickelt und stehen mittlerweile in der Version 4.0 zur Verfügung, aber die haben wir uns dann nicht mehr genauer angesehen.

Rund um das Thema habe ich auch noch ein paar nützliche Anleitungen gefunden:

JSF Tutorial
https://www.javawebtutor.com/articles/jsf/
https://www.tutorialspoint.com/jsf/jsf_overview.htm

JSF in Tomcat zum Laufen bringen
https://www.byteslounge.com/tutorials/how-to-configure-jsf-in-tomcat-example

Webanwendungen als Docker-Images herstellen
https://jaxenter.de/apache-tomcat-meets-docker-webanwendungen-als-docker-images-herstellen-23213

Grundsätzlich hat sich mein Eindruck gefestigt, dass im Web Java nicht (mehr) der Bringer ist. Irgendwie reihen sich JSF/MyFaces in andere Projekte wie JavaFX/OpenJFX oder auch Cordova ein, bei denen die Originalhersteller die Entwicklung abgetreten haben und wo es aus meiner Sicht nicht sicher ist, dass diese Projekte auf Dauer sich halten und/oder zuverlässig weiterentwickelt werden.

Wobei die Erstellung eines Spring-Microservice für Tomcat wirklich genial einfach war und die mit einer Anleitung erstellte Version des Microservice absolut flexibel und einfach an beliebige Bedürfnisse anzupassen ist.

Server-Umzug abgeschlossen

Der Umzug meines V-Servers sollte jetzt fertig sein. Der E-Mail-Server läuft und ist hinreichend konfiguriert. Der Spamschutz scheint besser wie vorher zu sein und auch die Kommunikation mit einer E-Mail-Adresse, die bisher nie durchging, hat eben funktioniert.

Soweit ich das sehen kann, sind jetzt auch alle Webseiten von mir wiederhergestellt und gleich mal auf den neusten Stand aktualisiert. Die unwichtigste Seite hat – natürlich ;-(  – die meiste Arbeit gemacht. Aber ich habe zumindest wieder etwas zu der Bedeutung von Eigentum und Gruppenzugehörigkeit unter Linux (und auch WordPress) gelernt und diverse Linux-Shell-Befehle geübt. Bisher war ich wirklich so naiv und dachte, dass Dateirechte die entscheidenden Stellen sind und man spätestens mit 755 auf der sicheren Seite hinsichtlich der Ausführung, dem Zugriff und ggfl. Schreiben in entsprechende Verzeichnisse auf dem Server sein sollte, wenn man Webseiten bereitstellt. Ich habe wegen diverser Probleme eine gefühlte Ewigkeit erfolglos mit den Schreibrechten herum experimentiert (sowohl über FTP als auch direkt per SSH mit chmod bis hin zu 777), bis mir aufgefallen war, dass bei den Webseiten ohne Probleme ganz andere Eigentumsrechte und Gruppenzugehörigkeiten da waren als bei denen mit Problemen. Da lag der Hase im Pfeffer und root ist nicht immer root (zumindest nicht im universellen Sinn – der root des SSH ist nicht immer der root der Webserver oder gar irgendeiner Verwaltungssoftware wie Plesk). Admin fuddeln vielleicht da rum – unglaublich.

Mit chown -R für den Eigentümer und chown : für die Gruppenzugehörigkeit haben sich dann aber (fast) alle Probleme in Luft aufgelöst. Nur die Zugriffs- bzw. Rechteprobleme bei der unwichtigsten Seite (einem Joomla!-System) habe ich einfach nicht in Griff bekommen. Die Seite habe ich dann kurzentschlossen komplett neu aufgesetzt (jetzt aber als WordPress-System) und dann einfach die wichtigsten Inhalte aus meiner lokalen Sicherung eingefügt.

Und da ich gerade dabei war, habe ich auf dem neuen V-CordovaServer Docker angeschaltet und gleich mit meinem Cordova-Skript für die kommende Vorlesung an der TH Bingen getestet. Das ging wie Butter durch ein heißes Messer – oder auch umgekehrt. Alle notwendigen Programme und Bibliotheken wurden problemlos (und fix) installiert und der Container ist sofort gelaufen. Das konkrete Erstellen der Cordova-App für eine Android-Plattform ging ebenso perfekt. Ich habe mich dann noch von einem anderen Rechner per SSH auf dem Server eingeloggt und aus dem Terminal die generierte App aus dem Docker-Container auf das Host-System kopiert. Null Problemo. Unter Linux läuft so Zeug die Docker einfach perfekt.

Ich komme immer mehr auf den Geschmack, meine Kenntnisse um Docker etwas zu intensivieren und zudem mehr mit dem Server zu machen als bisher.

Docker unter Windows

Nachdem Docker auf meinem alten Terra-Notebook mit Windows 10 Pro einwandfrei gestartet ist, wollte ich der Sache auf meiner Workstation doch mal auf den Grund gehen. Und siehe da – den Docker Desktop gerade nochmal installiert und die Sache läuft. Keine Ahnung, warum das jetzt durch gegangen ist. Aber umso besser und ich werde morgen mal dran gehen und statt vorgefertigter Images eigene Docker-Skripte zusammenbauen.

Das Cordova-Image, das ich bisher verwende, muss ich ja sowieso innerhalb des Docker-Containers noch anpassen und da macht es Sinn, dass gleich in das Build-Skript auszulagern.

Mc Cordova

Eigentlich wollte ich den Post mit „Mc Docker“ betiteln, aber tatsächlich läuft Docker auf meinem iMac Mini nicht. Was aber daran liegt, dass der iMac Mini verdammt alt ist und nur macOS 10.12 als Betriebssystem hat. Wenn ich nicht ganz falsch liege, verträgt der auch gar kein Update auf eine neuere Version von macOS. Und Docker braucht mindestens die Version 10.13. Was nach nicht Viel klingt, aber wohl entscheidend ist. Aber das trifft auch auf andere Software zu, wie ich gerade beim Versuch des Installierens eines Screenshot-Programms bemerkt habe. Für diverse neue Apple-Programme benötigt es wohl diese Version 10.13 als untere Grenze und da kann ich den iMac Mini anscheinend nicht mehr drüber hiefen. Was nicht schlimm ist, denn außer für die Remoteproben mit meiner Band über JamKazam benutze ich den iMac Mini sowieso nicht. Maximal für die Erstellung von iOS-Apps, wenn es dessen außnahmsweise mal wieder bedarf.

Cordova

Und Cordova hat sich ohne Probleme installieren lassen und läuft „Out-of-the-box“. Bis hin Aktualisieren mit npm und dem Start der App im Simulator geht das wie ein heißes Messer durch die Butter. Damit ist von Seiten der Infrastruktur alles vorbereitet für die kommende Vorlesung zu Cordova im kommenden Sommersemster an der TH Bingen – sofern ich da überhaupt auf den Mac wechseln muss. Auf meinem Linux-Rechner geht Cordova sowieso und unter Windows kann ich mit Visual Studio 2017 oder dem von mir angepassten Docker-Image in meinen Linux-VMs auch gut arbeiten. Also sind auch da alle Voraussetzungen geschaffen.

Wobei gestern die Installation von Docker auf meinem uralten Terra-Notebook mit Windows 10 Pro sogar funktioniert hat und auch das Cordova-Image im zweiten Anlauf installiert und dann sauber gestartet wurde. Heute morgen wollte ich dann frohgemut das Docker-Image anpassen, aber ich hatte nach dem Start von dem Terra-Notebook die gleichen Fehler, die ich schon auf meiner Workstation mit Windows 10 Pro bzw. meinem Mate-Notebook mit Windows 10 Home hatte. Aber interessanter Weise hat auf dem Terra-Notebook der Neustart von Rechner und Docker das Problem beseitigt und ich konnte das Cordova-Image starten und umkonfigurieren. Das ist schon alles sehr rätselhaft.

Docker und Windows – nicht wirklich prickelnd

Je mehr ich mich mit Docker beschäftige, desto mehr macht mir die Sache Spaß. Docker ist verdammt interessant und ich sehe für mich da wirklich einige Anwendungen – auch über Cordova hinaus.

Cordova

Ich werde das Docker-Thema auf jeden Fall vertiefen und wohl auch mein Cordova-Training bei LinkedIn Learning (LiL) dahingehend auf Stand bringen. In meiner Linux-VM habe ich jetzt das Cordova-Image soweit aktualisiert, angepasst und erweitert, dass das Kompilieren einer Android-App sauber durchgeht. Das war ja das ursprüngliche Ziel, warum ich mich wieder mit Docker beschäftigt habe.

Aber unter Windows bekomme ich Docker einfach nicht vernünftig zum Laufen. Ich habe den Standard-Docker-Desktop installiert und Docker läuft im Grunde auch unter Windows. Aber ich kann kein Image laden und nicht einmal den beiliegenden Testcontainer starten. Weder auf meiner Workstation mit Windows 10 Pro noch meinem Mate-Notebook mit Windows 10 Home. Die meisten Fehler deuten darauf hin, dass die Docker-Engine nicht gefunden wird (sowas open \\.\pipe\docker_engine_linux), Rechteprobleme oder das Image nicht geladen werden kann. Fängt man an zu schrauben, gibt es auch leicht Probleme mit dem Daemon etc.

Im Internet findet man zu den Problemen gut 30 – 40 verschiedene Lösungsvorschläge. Leider nur die klassischen Ideen, auf die man auch selbst kommt. So etwas wie

  • Neustart von Daemon, Console, Rechner etc.,
  • Admin-Rechte nutzen,
  • an Hyper-V und WLS2 rumdrehen,
  • Firewall konfigurieren,
  • mit net stop und net start den Service neu starten,
  • die Powershell statt der normalen Konsole verwenden bis hin
  • zur Neuinstallation von Docker.

Also reine Standardware bzw. die üblichen Tipps, die bei mir nicht den geringsten Erfolg gebracht haben.

Nun kam aber das Komische. Auf meinem alten Notebook – auch mit Windows 10 Pro – läuft Docker. Keine Ahnung warum. Sehr seltsam … – aber ich werde auch da dann mal das Cordova-Image versuchen zu installieren. Es scheint im Moment zu laden, aber im ersten Versuch gab es schon nach einer Weile einen Abbruch :-(.

Ich werde Docker wohl morgen auf meinem iMac testen, aber ich gehe davon aus, dass ich auch da keine Probleme bekomme. Ist ja die gleiche Basis wie Linux.

Vorteile und Graus der Virtualisierung – Docker & Co

Cordova

Da ich für das kommende Sommersemester an der Technischen Hochschule Bingen wieder einen Lehrauftrag zum Thema Cordova und plattformneutrale App-Entwicklung angenommen und gerade Zeit für die Vorbereitung habe, habe ich die letzten Tage in den aktuellen Stand von Cordova reingeschaut und meine alten Projekte und Matrialien zusammengetragen. Ich hatte dieses Thema eine ganze Weile schleifen lassen, da Python, Big Data, Web-Programmierung, Cobol, C# & „Was auch sonst immer“ die Arbeit in eine andere Richtung gelenkt hatten.

Die meisten Dinge, die ich die vergangenen Jahre zusammengestellt und programmiert habe, sind jedoch noch weitgehend auf Stand. Allerdings haben sich auch durchaus Sachen geändert. Daher bedarf die neue Vorlesung einiger Vorbereitung und eine Anpassung.

Zudem habe ich auch ganz einfach Lust, meine ganzen Apps zu aktualisieren. Parallel will ich aus einigen Apps  Python-Programme machen. Ohne konkrete Ziele, aber vielleicht kommen mir dabei ein paar neue Ideen und ich lerne natürlich was dazu – auch wenn das im Grunde aktuell ein reines Programmieren aufgrund von Zeit und Lust darstellt.

Anyway – bei Cordova gibt es ein paar Sachen, die mich schon stutzig gemacht und zu einigen Arbeiten im Hintergrund sowie grundsätzlichen Überlegungen genötigt haben. Das reine Installieren der neuen Version von Cordova mit npm geht wie gehabt und das Erstellen von Cordova-Projekten in dem Cordova-CLI auch. Ebenso das Hinzufügen der verschiedenen Plattformen und das Ausführen in dem Browser-Emulator ist unverändert. Die eigentlichen Quellcodes auf Basis von JavaScript & Co sowieso.

Aber wenn man etwa beim konkreten Kompilieren Android als Plattform für die Cordova-Apps haben will, wird das JDK 8 vorausgesetzt. Im Moment ist aber schon das JDK 15 aktuell und damit funktioniert es nicht. Zumindest bekomme ich es im Moment nicht hin, mit der derzeit aktuellen Java-Version Android-Apps zu erstellen. Ehrlich gesagt ist mir nicht einmal klar, ob das an Android (da soll ja Java auch sukzessive abgelöst werden) oder Cordova liegt. Wie angedeutet, habe ich die App-Entwicklung eine Weile aus den Augen verloren.

Und dann hatte ich das Android Studio bzw. das Android SDK als auch Xcode komplett von meinen Rechnern gelöscht, da ich eben das Entwickeln für Android und iOS die letzte Zeit nicht gebraucht hatte. Zumal ich mich sowieso auch dabei auf das Visual Studio committed hatte. Dabei kann man ja wunderbar auch Android- bzw. iOS-Apps erstellen.

Aber um die verschiedenen Möglichkeiten im Vorfeld der Vorlesung mal wieder auszutesten, werde ich auf meinem Mac vermutlich Xcode neu installieren (wenn ich die Sache mit meiner Apple-ID geklärt habe – die habe ich auslaufen lassen) und das Android Studio habe ich mittlerweile wieder neu installiert.

Aber irgendwie hat es bei meinem ersten naiven Versuch nicht funktioniert, damit Cordova-Projekte zu öffnen – oder besser –  zum Laufen zu bringen. Irgendwie mag ich das Android Studio aber auch nicht wirklich. Ich sollte der Sache zwar auf den Grund gehen, aber ich werde ja sowieso Visual Studio nehmen.

Wobei es da auch ein seltsames Problem gibt. In Visual Studio 2019 ist die Erweiterung für Cordova nicht mehr dabei und damit kann man weder Cordova-Projekte anlegen noch vorhandene Cordova-Projekte öffnen. Also musste ich die schon gelöschte Version 2017 von Visual Studio mit der Cordova-Erweiterung wieder auf meine Rechner aufspielen. Damit geht aber alles wunderbar und ich habe mittlerweile diverse Cordova-Apps erstellt, aus Visual Studio in verschiedenen Emulatoren sowie per USB-Debugging sogar direkt auf mehreren Geräten ausgeführt. Auch die Installation auf ein paar Testgeräten funktioniert problemlos. Seltsam sind die Begleiterscheinungen jedoch schon und ich bin nicht sicher, ob Cordova noch lange auf dem Markt bleibt. Was Cordova aber nicht als gute Basis für die kommende Vorlesung diskreditiert, um grundsätzlich die Erstellung von plattformneutralen Apps auf Basis von Webtechnologien zu lernen. Denn im Umfeld von Xamarin sind die gleichen Bedingungen/Probleme vorzufinden. Die Frage ist also wohl eher, ob Apps auf Basis von Webtechnologien sich auf Dauer etablieren oder nicht?

Wie dem auch sei – ich habe eigentlich keine Lust, das alte JDK 8 auf meine Rechner zu installieren und auch nicht die ganzen Emulatoren und SDKs von Android Studio auf Teufel komm raus zu konfigurieren. Entweder es geht „out-of-the-box“ wie bei Visual Studio 2017 oder die Sache kann mir im Grunde gestohlen bleiben. Es geht mir um die eigentlich Programmierung innerhalb des Cordova-Wrappers mit JavaScript und HTML/CSS und nicht um das Geraffel rundherum. Das hat mich schon immer an der App-Programmierung genervt.

Und da kam ich auf die Idee, eine andere Sache mal wieder aufzugreifen, die ich vor einigen Monaten angefangen, dann aber wegen anderer Dinge – wie so oft – beiseite gelegt habe: Docker.

Warum nicht einfach ein gut konfiguriertes Docker-Image für Cordova laden und dann ohne das ganze Installieren und Konfigurieren die Apps bauen? Das war meine Idee. Sollte doch einfach sein.

Und wie immer, wenn etwas auf den ersten Blick so einfach und logisch aussieht, steckt der Teufel im Detail. Genau genommen sind es in dem Fall sogar gleich mehrere Teufel gewesen.

Denn obwohl ich mich schon mit Docker beschäftigt und auch schon Images bzw. Container zum Laufen gebracht hatte, habe ich das Zeug zwischenzeitlich wieder von meinen Rechner gelöscht gehabt. Also musste ich Docker erst einmal „schnell“ installieren. Was (natürlich) wieder gar nicht schnell war und letztendlich sogar auf meinen Windows-Rechnern gescheitert ist. Weder unter Windows 10 Pro noch unter Windows 10 Home ist Docker bei mir richtig gelaufen. Natürlich kam ich bei den Problemen mit Windows 10 Pro sofort auf Hyper-V und diesen ganzen Virtualisierungs-Kram im Hintergrund von Windows, denn damit habe ich schon seit Jahren Ärger im Zusammenspiel mit VirtualBox und dem VMWare Player. Und auch wenn der VMWare Player ab der Version 16 wohl mit dem Hyper-V-Geraffel kann und auch Docker in Windows 10 Pro irgendwas mit Hyper-V macht und ich die Anleitungen für die ganzen Einstellungen umgesetzt habe, hat das Zeug irgendwelche Probleme mit den Rechten. Dazu kommt – bei Windows 10 Home gibt es ja kein Hyper-V und da muss man dann andere Sachen konfigurieren bzw. installieren. Alles doch ein elendes Gefuddel, was ich ja ausdrücklich vermeiden wollte und ich habe nach diversen Versuchen die Lust verloren.

Also auf meinen Linux-Rechner gewechselt, auf dem Docker erwartungsgemäß problemlos läuft. Zwischenzeitlich war ich auch in Eppstein und habe Docker mal auf meinem iMac getestet – auch keine Probleme. Also Docker sollte doch ein lohnenswerter Ansatz sein.

Aber dann bin ich auf das nächste blöde Problem gestoßen, erst einmal ein geeignetes Cordova-Image für Docker zu finden. Auf Git gibt es da was, aber der Git-Zugriff scheitert durch Rechteprobleme. Das Image scheint entweder gesperrt oder verschoben worden zu sein. Dann habe ich noch eine Anleitung gefunden, wie ich mir selbst ein Cordova-Image erstellen kann, aber das ist ja das Gegenteil von dem, was ich eigentlich wollte – keine Arbeit mit der blöden Konfiguration. Letztendlich habe ich nur ein Docker-Image gefunden, dass (angeblich) mit einem einfache Pull vom Docker Hub zu installieren wäre. Also so (vermutlich als root notwendig):

sudo docker pull beevelop/cordova:latest

Das Starten des Image soll dann einfach so funktionieren:

sudo docker run -it beevelop/cordova bash

Unter Windows habe ich wie gesagt Docker nicht stabil zum Laufen gebracht und das Image wurde angeblich nicht gefunden. Beim iMac muss ich es noch probieren, aber auf meinem Linux-Rechner ging der Pull einwandfrei. Bis 98% durch waren. Dann kam reproduzierbar immer wieder der Abbruch.

Mittlerweile war es Krieg – die Technik gegen mich. Oder umgekehrt. Und wenn etwas einfach nicht laufen will, werde ich zum Berserker. Auch wenn im Grunde alles Notwendige zur Vorlesung über Cordova mit Visual Studio bereit gestanden hat – ich lasse mich doch nicht von so einem Mist in die Knie zwingen.

Mein Mint Linux-Rechner ist noch in der Version 19 und das System wollte ich auch nicht verpfuschen. Von daher kam mir die Idee, meine Linux-VM (Mint Linux 20) unter Windows 10 zu verwenden. Nur konnte die plötzlich auf meiner Workstation mit VirtualBox nicht mehr gestartet werden und auch die Installation einer neuen Linux-VM ist gescheitert. Möglicherweise aufgrund der Hyper-V-Einstellungen und dem Kram, aber ich hatte einfach keinen Bock mehr auf das Gefummel. Also eine neue Version von VMWare-Player aufgespielt, dort eine Version von Mint-Linux 20 installiert und da ging dann der Pull des Docker-Images. Ohne Probleme. Wenn man „Von hinten durch das Auge“ wortwörtlich haben will, ist das diese Konstruktion – eine Virtualisierung in einer Virtualisierung.

Wer aber jetzt glaubt, die Sache wäre vorbei, täuscht sich. Denn in dem Cordova-Image war kein passendes JDK 8 dabei. Die Erstellung eines Cordova-Projekts ging damit problemlos, aber das geht ja auch in meiner normalen Cordova-CLI und damit bringt mich ein Docker-Image keinen Millimeter weiter.  Als ich eine Android-App kompilieren wollte, war war auch im Docker-Container Schicht im Schacht.

Aber es war mittlerweile schon lange persönlich und jetzt wollte ich es durchziehen. Also in dem Docker-Container das JDK 8 nachinstalliert. Das geht so:

apt-get update && apt-get install -y openjdk-8-jdk && apt-get install -y ant && apt-get install -y gradle && apt-get clean

Unter Umständen tut ein Update der Zertifikate noch gut (bei mir nicht notwendig gewesen):

apt-get update && apt-get install ca-certificates-java && apt-get clean && update-ca-certificates -f

Und letztendlich müssen u.U. die Umgebungsvariablen gesetzt werden (bei mir auch nicht mehr notwendig gewesen):

ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

set JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

und dann:

export JAVA_HOME

Danach konnte ich endlich eine Android-App im Docker-Container kompilieren. Nur sind Docker-Systeme ja flüchtig und wenn der Docker-Container beendet wird, sind alle Änderungen samt der gespeicherten Daten weg. Also waren Snapshots des aktuellen Stands notwendig. Das geht aus einem zweiten Terminal heraus etwa so:

sudo docker commit -p 532a5b3584e8 container1

Dabei braucht man die ID oder den Namen des Docker-Containers.Bekommt man so:

sudo docker ps

Dann bekommt man was der Art angezeigt:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
532a5b3584e8 container1 „bash“ 19 minutes ago Up 19 minutes eloquent_liskov

Und dann muss die kompilierte App ja auch noch raus aus dem Docker-Container oder man muss was reinkopieren. Also stellte sich die Frage, wie man aus einem zweiten Terminal aus dem Clientsystem auf den Host rauskopiert oder umgekehrt? Das geht formal so (wieder mit sudo):

docker cp <SRC> <DEST>

Also konkret was der Art (in den Container):

sudo docker cp /home/ralph/Schreibtisch/www eloquent_liskov:/tmp/HalloWelt
sudo docker cp /home/ralph/Schreibtisch/rjsedv.jks eloquent_liskov:/tmp/HalloWelt
sudo docker cp /home/ralph/Schreibtisch/build.json 532a5b3584e8:/tmp/HalloWelt

Aus dem Container auf den Host geht für die generierte Android-App etwa so:

sudo docker cp eloquent_liskov:/tmp/HalloWelt/platforms/android/app/build/outputs/apk/debug/app-debug.apk /home/ralph/Schreibtisch

Die späteren Neustarts der Snapshots zeigten, dass noch (weitgehend) alle Daten waren und jetzt schien alles ok.

Pustekuchen. Denn auf meinem Notebook mit Windows 10 Home konnte der VMWare-Player die virtuelle Maschine nicht starten, die ich auf der Workstation erstellt hatte. Und ist auch beim Neuinstallieren eines Linux-Systems gescheitert. Irgendwas mit der Anzeige ging schief. Warum auch immer.

Also habe ich auf dem Notebook VirtualBox genommen, denn das ist dann dort im Gegensatz zum VMWare Player auch mit Linux als Clientsystem sauber gelaufen. In der damit erzeugten VM für Mint-Linux 20 das ganze Zeug mit Docker nochmal gemacht und das hat dann auch funktioniert.

Letztendlich hat das „Mal schnell“ zu gut einem vollen Tag Arbeit geführt, aber ungelöste Probleme lassen mir keine Ruhe und ich habe dabei vor allen Dingen wieder eine Menge gelernt. Vielleicht kann ich das neue Wissen ja nochmal brauchen.

 

Update: Irgendwann habe ich dann festgestellt, dass das Docker-Cordova-Image die Cordova-Version 9 verwendet hat und mittlerweile die Version 10 aktuell ist. Was im Grunde nicht schlimm ist, aber so kann man das dann im Container noch aktualisieren:

npm i -g cordova to update

 

 

Docker & wasm

Im Moment geht es in der IT mit neuen Themen schneller wie beim Bretzelbacken. Und vor allen Dingen gibt es permanent was Neues. Bzw. ich komme einfach nicht hinterher, was die Lage besser trifft.

Aktuell habe ich „Big Data“ und „Maschinelles Lernen“ im Zusammenhang mit Python „in Arbeit“. M.a.W – ich bin gerade am richtigen Einarbeiten, wobei da ja ziemlich viel Überschneidung zu meinem Studium und dem sonstigen täglichen Programmiergeschäft die Sache einfach macht.

Aber irgendwie habe ich zwei andere Megatrends bisher weitgehend ignoriert.

  • Docker
  • Webassemblies

Docker habe ich zumindest am Horizont schon länger wahrgenommen, aber einfach noch nie ausprobiert. Und da Docker mittlerweile auch schon massiv in der Kritik steht, wollte ich da eigentlich nicht ran. Aber die Entwickler auf der letzten Schulung in Köln haben auf Docker-Container geschworen und deshalb bin ich jetzt doch wieder neugierig geworden. Zumal ich eine Anfrage nach einer SQL-Schulung in der Pipeline habe, die aber nicht – wie sonst bei mir üblich – unter MySQL oder zur Not MS SQL-Server, sondern DB2 laufen soll. Ja woher soll ich denn jetzt auch noch eine DB2-Installation haben? Mit dem Teil hatte ich noch nie vorher direkten Kontakt. Antwort – ich installiere mir gerade einen passenden Docker-Container! Es ist wohl doch so, dass meine bisherige geringe Anteilnahme an der Docker-Welt ein Fehler war. Wobei ich die Installation von dem Docker-Desktop unter Windows gleich wieder gelöscht habe. Das läuft ja mit Hyper-V und das wiederum killed mein Virtual Box. No way. Ich will keine permanente Umschaltung der Virtualisierungsumgebungen. Einfach zu lästig. Also wird aus der Not eine Tugend gemacht und Docker in seinem natürlichen Habitat – Linux – betrieben. Entweder auf meinem Notebook mit dem Dualboot oder aber auf der Workstation mit Windows 10 in der Linux-VM in der Virtual Box. Geht wunderbar bei 12 Kernen und 32 Gigabyte RAM.

Das Thema Webassemblies ist dagegen vollkommen an mir vorbeit gegangen. Nur habe ich vor wenigen Tage die Meldung mitbekommen, dass wasm neben HTML, CSS und JavaScript nur die 4. offiziell von W3C abgesegnete Technologie im Web ist. Das erzwingt dringend, dass ich mir das die nächsten Tage mal genauer ansehe.