„Die Änderung ist fertig!“ …aber wie sieht es mit dem Deployment aus?
Drei Monate nach meinem Einstieg, kurz vor dem Ende der Probezeit, bekam ich zum ersten Mal eine echte Aufgabe aus dem Tagesgeschäft. Es war nur eine sehr kleine Funktionsänderung, aber trotzdem war ich halb nervös und halb aufgeregt, als ich den Code auf meinem eigenen Rechner, also auf localhost, anpasste und die Tests erfolgreich abschloss.
„Teamleiter, lokal laufen alle Tests durch!“
Der Teamleiter nickte und gab mir die Anweisung zum Deployment. „Gute Arbeit. Dann committen Sie es in GitLab, also in ein Quellcode-Repository wie GitHub, und deployen Sie es auf den Produktivserver.“
Deployment? Ich wühlte hastig in dem Übergabedokument, das ich während der Einarbeitung bekommen hatte. Es war voller Begriffe, mit denen ich nichts anfangen konnte.
Also lud ich den Code erst einmal wie angewiesen hoch. Jetzt blieb nur noch der letzte Schritt: die Verbindung zum Produktivserver. Ich stand tatsächlich schon auf. Wie in Fernsehserien dachte ich, ich müsse in einen eiskalten Serverraum, ein IDC, gehen und direkt an der am Server angeschlossenen Tastatur tippen.
Mein Senior sah mich, lachte und rief mich zurück. „Wohin wollen Sie? Bleiben Sie einfach sitzen und verbinden Sie sich per SSH.“
Die erste Begegnung mit dem schwarzen Bildschirm
Ich öffnete ein Programm namens SSH(Secure Shell), tippte die IP-Adresse und das Passwort ein, die mir mein Senior gegeben hatte, und drückte Enter. Unter Windows hätte mich vermutlich ein bunter Desktop begrüßt. Auf meinem Monitor erschien jedoch nur ein blinkender Cursor auf schwarzem Hintergrund.
ubuntu@ip-172-31-0-1:~$ _
Es gab keine Icons zum Anklicken und auch kein Rechtsklick-Menü mit „Neuer Ordner“. Aus Verlegenheit drückte ich wahllos Tasten, tippte dann ls ein, und sofort erschien eine reine Textliste mit Dateien.
„Ach so, das ist also diese CLI(Command Line Interface), von der ich immer nur gehört hatte.“
Die eigentliche Angst begann aber erst, als ich eine Datei ausführen wollte. Ich startete das im Handbuch erwähnte update-Skript, und was unter Windows ein einfacher Doppelklick gewesen wäre, kam hier als rote Fehlermeldung zurück.
Permission denied (Berechtigung verweigert)
Es war mein eigener Server, und trotzdem durfte ich das Skript nicht ausführen. Warum war Linux so unfreundlich?
Der Lagerverwalter eines digitalen Logistikzentrums
Kehren wir zu unserer Metapher vom ‘digitalen Logistikzentrum’ zurück. Wenn mein Windows-Laptop ein gemütliches Privatbüro ist, dann ist ein Linux-Server ein riesiges Lager, das ausschließlich für die Abwicklung von Logistik gebaut wurde. In diesem Lager liegen Zehntausende von Kisten, also Dateien.
Wenn der Lagerverwalter jedes einzelne Paket zu Fuß kontrollieren müsste, also GUI, und jede Tür einzeln mit dem Schlüssel öffnen müsste, also klicken, wäre die Arbeit viel zu langsam. Deshalb nutzt Linux ein Funkgerät namens Befehle.
„Geben Sie die vollständige Liste aller Kisten in Bereich 1 aus!“ (ls) „Verschieben Sie Kiste 3 in Bereich 5!“ (mv) „Führen Sie diese Kiste aus!“ (./start.sh)
Es ist also nicht deshalb unbequem, weil keine Maus vorhanden ist. Die Grafik wurde bewusst weggelassen, weil man nach etwas Übung Tausende von Dateien hundertmal schneller steuern kann als mit einer Maus.
[Code Verification] Das absolute Gesetz der Berechtigungen
Was Linux-Anfänger am meisten quält, ist das Thema Berechtigungen. Unter Windows löst „Als Administrator ausführen“ fast alles mit einem Klick. Linux dagegen prüft bei jeder einzelnen Datei streng, wer was tun darf.
Um zu überleben, muss man die scheinbar außerirdische Ausgabe von ls -l im Terminal lesen können.
$ ls -l myscript.sh
-rwxr-xr-- 1 owner group 1024 Jan 1 12:00 myscript.sh
Analyse: Entscheidend ist ganz vorne -rwxr-xr--. Wenn man das erste -, also Datei, ausnimmt, muss man den Rest in Dreiergruppen lesen.
Ein selbst geschriebenes Skript lässt sich nicht ausführen? In neun von zehn Fällen fehlt einfach das Ausführungsrecht, also x. An diesem Punkt sprechen Anfänger frustriert oft den verbotenen Zauberspruch chmod 777.
# Was du niemals tun darfst
$ chmod 777 myscript.sh
777 bedeutet: „Ich, du und jeder vorbeilaufende Hund dürfen diese Datei ändern und ausführen.“ Das kommt dem kompletten Öffnen des Sicherheitstors gleich. Im Berufsalltag ist das absolut tabu. Man sollte sich angewöhnen, nur die wirklich nötigen Rechte zu vergeben, etwa mit chmod +x.
chmod 777 ist bequem, aber es macht den Weg auch für Angreifer bequem.Praxis-Tipp: Die Angst vor dem Terminal überwinden
Am Anfang im Unternehmen sagte mir mein Senior, ich solle PuTTY als Tool für Serververbindungen verwenden. Durch eigene Recherche im Internet fand ich aber ein besseres Werkzeug: MobaXterm. Dieses Programm zeigte schon nach der SSH-Verbindung links eine Dateiliste per SFTP an, fast wie der Explorer auf meinem eigenen Rechner.
Dadurch konnte ich Dateien doppelklicken, bearbeiten und speichern, selbst ohne Terminalbefehle wirklich zu beherrschen. Aber wenn man sich nur auf solche Tricks verlässt, wird man mit Linux nie wirklich vertraut. In einer akuten Störung hat man keine Zeit, erst auf ein GUI-Tool zu warten.
Zum Schluss: Wer die Umgebung beherrscht
Das Gewächshaus namens Windows zu verlassen und sich an die Wildnis namens Linux anzupassen, ist schmerzhaft. Doch wenn man durch diesen Schmerz hindurchgeht, erhält man eine Form von Kontrolle, die mit einer Maus niemals möglich wäre.
Linux ist kein unbekanntes Gebiet mehr. Aber ein grundlegendes Problem bleibt. Was, wenn auf meinem Laptop, also in der Entwicklungsumgebung, Java 17 installiert ist, auf dem Linux-Server, also in der Deployment-Umgebung, aber nur Java 8? Oder wenn es auf Linux eine Bibliothek gibt, die auf meinem Windows-Rechner nicht vorhanden ist?
Die Ausrede „Auf meinem Rechner funktioniert es doch“ entsteht aus Unterschieden im Betriebssystem und bei Bibliotheksversionen. Kann man diese Umgebungsunterschiede nicht komplett beseitigen? Kann man die Umgebung meines Laptops nicht einfrieren und unverändert auf den Server mitnehmen?
Es gibt eine Technologie, die genau diese scheinbar absurde Vorstellung Wirklichkeit gemacht hat. Beim nächsten Mal sprechen wir über Docker, die Technologie, die über Virtualisierung hinausging und die Container-Revolution auslöste.