“De wijziging is klaar!” …maar hoe zit het met deployen?
Drie maanden na mijn indiensttreding, net toen mijn proeftijd bijna afliep, kreeg ik voor het eerst een echte taak uit de praktijk. Het was maar een heel eenvoudige functieaanpassing, maar toch voelde ik me half nerveus en half opgewonden terwijl ik de code aanpaste en de tests perfect afrondde op mijn eigen machine, op localhost.
“Teamlead, alle lokale tests zijn geslaagd!”
De teamlead knikte en zei dat ik het moest deployen. “Goed gewerkt. Commit het dan naar GitLab, een broncoderepository zoals GitHub, en deploy het naar de productie-server.”
Deployen? Ik dook haastig in het overdrachtsdocument dat ik bij mijn onboarding had gekregen. Het stond vol onbekende termen.
Ik uploadde de code eerst maar gewoon zoals mij was opgedragen. Nu restte alleen nog de laatste stap: verbinden met de productie-server. Ik stond echt bijna op van mijn stoel. Net als in series dacht ik dat ik een ijskoude serverruimte, een IDC, in moest lopen en daar rechtstreeks op een toetsenbord moest typen dat aan de server hing.
Mijn senior zag dat en moest lachen. “Waar ga je heen? Blijf gewoon zitten en log in via SSH.”
Mijn eerste ontmoeting met een zwart scherm
Ik opende een programma genaamd SSH(Secure Shell), typte het IP-adres en wachtwoord in dat mijn senior me had gegeven, en drukte op Enter. Als het Windows was geweest, had een kleurrijk bureaublad me begroet. Maar op mijn monitor verscheen alleen een knipperende cursor op een pikzwarte achtergrond.
ubuntu@ip-172-31-0-1:~$ _
Er waren geen pictogrammen om met de muis op te klikken, en ook geen rechtermuisknopmenu om een nieuwe map aan te maken. In paniek drukte ik op willekeurige toetsen, typte daarna ls, en meteen rolde een lijst met bestanden in platte tekst over het scherm.
‘Ah, dus dit is die CLI(Command Line Interface) waar ik alleen maar over had gehoord.’
Maar de echte angst begon toen ik een bestand probeerde uit te voeren. Ik startte het update-script uit de handleiding, en wat in Windows met een simpele dubbelklik geregeld zou zijn, kwam hier terug als een rood foutbericht.
Permission denied (toegang geweigerd)
Het was mijn eigen server, en toch kon ik het niet uitvoeren. Waarom was Linux zo onvriendelijk?
De magazijnbeheerder van een digitaal logistiek centrum
Laten we teruggaan naar onze metafoor van het ‘digitale logistieke centrum’. Als mijn Windows-laptop een comfortabel privékantoor is, dan is een Linux-server een gigantisch magazijn dat alleen is gebouwd voor logistieke verwerking. In dat magazijn staan tienduizenden dozen, oftewel bestanden.
Als de magazijnbeheerder elk pakket één voor één lopend moest controleren, GUI, en elke deur met een sleutel apart moest openen, klik voor klik, dan zou het werk veel te traag zijn. Daarom gebruikt Linux een walkietalkie die commando’s heet.
“Print de volledige lijst met dozen in zone 1!” (ls) “Verplaats doos 3 naar zone 5!” (mv) “Voer deze doos uit!” (./start.sh)
Het is niet onhandig omdat er geen muis is. De graphics zijn er bewust uitgehaald, omdat je, zodra je eraan gewend raakt, duizenden bestanden honderd keer sneller kunt aansturen dan met een muis.
[Code Verification] De absolute wet van permissies
Wat Linux-beginners het meest kwelt, is precies het probleem van permissies. In Windows lost één klik op ‘Als administrator uitvoeren’ bijna alles op. Linux controleert daarentegen streng voor elk afzonderlijk bestand wie wat mag doen.
Om te overleven moet je die buitenaards ogende uitvoer van ls -l in de terminal kunnen lezen.
$ ls -l myscript.sh
-rwxr-xr-- 1 owner group 1024 Jan 1 12:00 myscript.sh
Analyse: de kern zit in -rwxr-xr-- helemaal vooraan. Als je de eerste -, dus bestand, buiten beschouwing laat, moet je de rest in groepen van drie lezen.
Wil een script dat je zelf hebt geschreven niet draaien? Negen van de tien keer ontbreekt simpelweg de uitvoerpermissie, x. Op dat moment spreken beginners vaak uit frustratie de verboden spreuk chmod 777 uit.
# Wat je absoluut niet moet doen
$ chmod 777 myscript.sh
777 betekent: “Laat mij, jou en elke langslopende hond dit bestand aanpassen en uitvoeren.” Dat komt overeen met het wagenwijd openzetten van je beveiligingspoort. In echt werk is dat absoluut taboe. Je moet jezelf aanleren om alleen de minimaal noodzakelijke rechten toe te kennen, zoals chmod +x.
chmod 777 is handig, maar het maakt het ook handig voor aanvallers.Praktisch advies: terminalangst overwinnen
Toen ik net begon in het bedrijf, zei mijn senior dat ik PuTTY moest gebruiken als tool om met de server te verbinden. Maar door online te zoeken vond ik een beter hulpmiddel: MobaXterm. Zodra je via SSH verbinding maakt, toont dit programma links een bestandslijst via SFTP, bijna als de verkenner op mijn eigen computer.
Daardoor kon ik, zelfs zonder terminalcommando’s echt te kennen, bestanden dubbelklikken om ze te bewerken en op te slaan. Maar als je alleen op zulke trucs vertrouwt, raak je nooit echt vertrouwd met Linux. In een urgente storing heb je geen tijd om te wachten tot een GUI-tool opstart.
Tot slot: degene die de omgeving beheerst
De kas genaamd Windows verlaten en je aanpassen aan de wildernis genaamd Linux is pijnlijk. Maar als je door die pijn heen gaat, krijg je een niveau van controle dat met een muis nooit mogelijk is.
Linux is geen onbekend terrein meer. Maar er blijft nog één fundamenteel probleem over. Wat als op mijn laptop, dus in de ontwikkelomgeving, Java 17 is geïnstalleerd, terwijl op de Linux-server, dus in de deploymentomgeving, Java 8 staat? Of wat als er een bibliotheek op Linux bestaat die op mijn Windows-machine niet aanwezig is?
Het excuus ‘Maar op mijn machine werkt het wel’ ontstaat door verschillen in besturingssystemen en bibliotheekversies. Zou er geen manier zijn om dat omgevingsverschil volledig weg te nemen? Zou ik mijn laptopomgeving niet gewoon kunnen invriezen en rechtstreeks meenemen naar de server?
Er is een technologie die dat schijnbaar absurde idee werkelijkheid heeft gemaakt. Laten we het de volgende keer hebben over Docker, de technologie die verder ging dan virtualisatie en de containerrevolutie ontketende.