”Ändringen är klar!” …men hur blir det med deployen?
Tre månader efter att jag började på företaget, precis när min provanställning höll på att ta slut, fick jag för första gången en riktig uppgift från det dagliga arbetet. Det var bara en mycket enkel funktionsändring, men jag var ändå halvt nervös och halvt förväntansfull medan jag ändrade koden och körde klart alla tester på min egen maskin, på localhost.
”Teamlead, alla lokala tester gick igenom!”
Teamleaden nickade och sa åt mig att deploya. ”Bra jobbat. Commita det till GitLab, ett källkodsrepo som liknar GitHub, och deploya sedan till produktionsservern.”
Deploy? Jag började febrilt bläddra i överlämningsdokumentet jag fått under introduktionen. Det var fullt av ord jag inte kände igen.
Jag laddade först upp koden som jag hade blivit tillsagd. Nu återstod bara sista steget: att ansluta till produktionsservern. Jag började faktiskt resa mig från stolen. Precis som i tv-serier trodde jag att jag behövde gå in i ett iskallt serverrum, ett IDC, och skriva direkt på ett tangentbord kopplat till servern.
Min senior såg det och började skratta. ”Vart är du på väg? Sitt bara kvar och anslut via SSH.”
Mitt första möte med den svarta skärmen
Jag öppnade ett program som hette SSH(Secure Shell), skrev in IP-adressen och lösenordet som min senior hade gett mig och tryckte Enter. Om det hade varit Windows skulle ett färgglatt skrivbord ha mött mig. Men på min skärm syntes bara en blinkande markör mot en kolsvart bakgrund.
ubuntu@ip-172-31-0-1:~$ _
Det fanns inga ikoner att klicka på med musen och inget högerklicksmenyval för att skapa en ny mapp. I panik tryckte jag på slumpmässiga tangenter, skrev sedan ls, och direkt rullade en lista med filer fram i ren text.
”Aha, så det här är den där CLI(Command Line Interface) som jag bara hade hört talas om.”
Men den riktiga rädslan kom när jag försökte köra en fil. Jag körde skriptet update som stod i manualen, och det som i Windows hade varit ett enkelt dubbelklick kom här tillbaka som ett rött felmeddelande.
Permission denied (behörighet nekad)
Det var min egen server, och ändå kunde jag inte köra den. Varför var Linux så ogästvänligt?
Lagerförvaltaren i ett digitalt logistikcenter
Låt oss återvända till vår metafor om det ‘digitala logistikcentret’. Om min Windows-laptop är ett bekvämt privat kontor, då är en Linux-server ett enormt lager byggt enbart för logistikhantering. I det lagret finns tiotusentals lådor, alltså filer.
Om lagerförvaltaren skulle behöva gå runt och kontrollera varje låda en efter en, GUI, och öppna varje dörr med en nyckel, klick för klick, skulle arbetet gå alldeles för långsamt. Därför använder Linux en kommunikationsradio som heter kommandon.
”Visa hela listan över lådor i zon 1!” (ls) ”Flytta låda 3 till zon 5!” (mv) ”Kör den här lådan!” (./start.sh)
Det är inte obekvämt för att det saknas mus. Grafiken togs bort med avsikt, eftersom man när man väl vant sig kan styra tusentals filer hundra gånger snabbare än med en mus.
[Code Verification] Behörigheternas absoluta lag
Det som plågar Linux-nybörjare mest är just behörighetsfrågan. I Windows löser ett klick på ‘Kör som administratör’ nästan allt. Linux däremot kontrollerar strikt för varje enskild fil vem som får göra vad.
För att överleva måste man kunna läsa det utomjordiska språk som dyker upp med ls -l i terminalen.
$ ls -l myscript.sh
-rwxr-xr-- 1 owner group 1024 Jan 1 12:00 myscript.sh
Analys: nyckeln är -rwxr-xr-- allra längst fram. Om man bortser från första -, som betyder fil, måste resten läsas i grupper om tre.
Går inte ett skript du själv skrivit att köra? Nio gånger av tio saknas bara körbehörighet, x. Då brukar nybörjare, i frustration, uttala den förbjudna trollformeln chmod 777.
# Vad du aldrig far gora
$ chmod 777 myscript.sh
777 betyder: ”Låt mig, dig och varje förbipasserande hund ändra och köra den här filen.” Det är samma sak som att slå upp säkerhetsgrinden på vid gavel. I verkligt arbete är det helt förbjudet. Man måste vänja sig vid att bara ge de minimala behörigheter som faktiskt behövs, som chmod +x.
chmod 777 är bekvämt, men det gör det också bekvämt för angripare.Praktiskt råd: övervinna terminalskräck
När jag började på företaget sa min senior åt mig att använda PuTTY som verktyg för serveranslutning. Men när jag sökte runt på nätet hittade jag ett bättre verktyg: MobaXterm. Så fort man ansluter via SSH visar programmet en fillista till vänster genom SFTP, nästan som filutforskaren på min egen dator.
Tack vare det kunde jag, även utan att egentligen kunna terminalkommandon, dubbelklicka på filer för att redigera och spara dem. Men om man bara förlitar sig på sådana genvägar blir man aldrig riktigt vän med Linux. Vid en akut driftstörning har man inte tid att vänta på att ett GUI-verktyg ska starta.
Avslutning: den som behärskar miljön
Att lämna växthuset som heter Windows och anpassa sig till vildmarken som heter Linux är smärtsamt. Men när man väl tagit sig igenom den smärtan får man en nivå av kontroll som en mus aldrig kan ge.
Linux är inte längre okänt territorium. Men ett grundläggande problem återstår. Vad händer om Java 17 är installerat på min laptop, alltså i utvecklingsmiljön, medan Linux-servern, alltså deploymiljön, bara har Java 8? Eller om det finns ett bibliotek på Linux som inte finns på min Windows-maskin?
Ursäkten ”Men det fungerar ju på min dator” kommer från skillnader i operativsystem och biblioteksversioner. Går det inte att helt ta bort den miljöskillnaden? Går det inte att frysa min laptopmiljö som den är och ta med den direkt till servern?
Det finns en teknik som gjorde just den till synes absurda idén till verklighet. Nästa gång ska vi prata om Docker, tekniken som gick bortom virtualisering och satte igång containerrevolutionen.