Hantera flera miljöer för flera projekt på en och samma maskin?

Låt oss ta en titt på en typisk arbetsmiljö i ett programvaruhus. Du har några kunder som har olika miljöer. Vissa föredrar MySQL, andra föredrar Postgres. En version av din applikation behöver Java 11, och en annan Java 17. Frontend behöver npm 12 eller 16 eftersom du använder olika versioner av vinklad. Slutligen har du den tredimensionella matrisen som innehåller kombinationer av alla dina DB-, backend- och frontend-versioner. Låter illa, men en dag säger din chef...

Rötterna till en multiversum-miljö

Situationen som beskrivs ovan är inte ovanlig. Migration mellan språk- eller ramverksversioner, uppdateringar av databaser eller helt enkelt olika krav från kunder kan vända upp och ner på alla konfigurationer. Vi bör ha en lösning som hjälper oss att hantera dessa förändringar, en lösning som matchar några antaganden och/eller krav och/eller mål:

• lätt att använda - ett enda kommando för att ändra en konfiguration eller en version,
• rikt bibliotek - bör stödja flera olika tekniker och "saker" (bibliotek, ramverk, appar),
• utdragbar - du bör erbjuda möjligheten att lägga till dina plugins.

I den här artikeln kommer jag att fokusera på tre områden. Det första är verktyg för Java och JVM. Det andra är verktyg för allmänna ändamål. Det tredje är hur man använder docker för att uppnå våra mål.

​

Jag är Java och jag arbetar på JVM

När du är en Java-utvecklare eller, mer allmänt, du arbetar med JVM-teknikdå kan du använda SDKMAN!. Det här är ett mycket trevligt och lättanvänt verktyg som stöder många bibliotek, ramverk och språk.

Installationsprocessen för SDKMAN! Det är ganska enkelt. Du måste köra:

curl -s "https://get.sdkman.io" | bash

och sedan

källa "$HOME/.sdkman/bin/sdkman-init.sh"

Nu kan du hantera dina Java, Scala och Maven versioner.

Hantera versioner - exempel

I det här exemplet kommer vi att installera och uppdatera versionen av några verktyg. Detta är bara en liten delmängd av de tillgängliga verktygen.

Installation

Låt oss anta att din nya projekt användningsområden Java 17. Du har inte någon Java version installerad. Du vill installera den och dessutom lägga till ett Maven Daemon-verktyg för att göra byggnaderna snabbare. Så du måste också installera Maven. För att göra det måste du utföra tre enkla kommandon:

$ sdk installera java 17-öppen

$ sdk installera maven 3.8.4

$ sdk installera mvnd 0.7.1

I slutet av installationen av varje verktyg får du en fråga om du vill göra det till standard:

Vill du att Java 17-open ska ställas in som standard? (J/N):

Detta är viktigt när du installerar en ny version av ett bibliotek eller ett språk, eftersom SDKMAN! kommer att ställa in standardversionen som global för alla terminaler för den aktuella användaren.

Kontroll av versioner och uppdatering

Från tid till annan behöver SDKMAN! uppdatera index. Under detta kan du få ett meddelande om att det finns några nya versioner av verktyg som du använder. Vi kan kontrollera vilka versioner som finns tillgängliga genom att skriva sdk ls. För sdk ls maven:

Tillgängliga Maven-versioner

================================================================================

    3.8.6 3.3.3

    3.8.5 3.3.1

3.8.4 3.2.5

    3.8.3 3.2.3

    3.8.2 3.2.2

    3.8.1 3.2.1

    3.6.3 3.1.1

    3.6.2 3.1.0

    3.6.1 3.0.5

    3.6.0 3.0.4

    3.5.4

    3.5.3

    3.5.2

    3.5.0

    3.3.9



================================================================================

lokal version

används för närvarande

================================================================================

Som vi ser ovan har Maven en nyare version än den vi använder. Detsamma gäller för mvnd (0.8.2) och Java (19-open). Låt oss uppdatera allt. För att göra det behöver vi bara anropa kommandot install, men den här gången använder vi inte en versionsspecifikator:

$ sdk installera maven

$ sdk installera mvnd

$ sdk installera java

Men något fel inträffade. Maven och mvnd har korrekta versioner, men Java har version 17.0.5-tem. Det beror på att "den nyaste" versionen av verktyget kontrolleras av dess leverantör, inte av SDKMAN! Vem är denna leverantör? En leverantör i SDKMAN! är någon som kan publicera en version. Men låt oss säga att vi äntligen installerar 19-öppenoch vi gjorde det till standard, men av någon anledning behöver vi använda 17-öppen.

Lokala versioner och versionshantering per terminal

​
Vi kan konfigurera en standard version av ett verktyg som är global för alla projekt och terminaler. Men när vi behöver en specifik version har vi två sätt att göra det på. Det första är att använda sdk-användning kommandot varje gång vi vill använda en specifik version av ett verktyg i den aktuella terminalen. Det andra är att förbereda en versionslista i en .sdkmanrc fil som lagras tillsammans med projektet.

Det första alternativet är för engångsbruk, medan det andra är utformat för att arbeta med team och dela konfigurationer mellan Team medlemmar.

För- och nackdelar med SDKMAN!

SDKMAN! är mycket lätt att använda och har ett rikt bibliotek med verktyg, ramverk och språk som stöds. Det fungerar på Linux, MacOS och Windows. Å andra sidan är detta verktyg JVM-fokuserat och kräver författarens acceptans för att vara en leverantör. Dessutom är mekanikern i .sdkmanrc är mycket dålig och kan avsevärt fördröja processen med att byta kataloger.

Jag skulle vilja använda många andra språk

Om du behöver använda många språk och verktyg bör du ta en titt på asdf. Detta verktyg är inriktat på verktyg på "hög nivå". Medan du i SDKMAN! kan hitta många Java-specifika verktyg, som Bpipe eller Znai, erbjuder asdf mycket fler verktyg men inte så specifika. Naturligtvis överlappar vissa av dessa verktyg varandra, t.ex. Java, Tomcat eller mvnd finns tillgängliga i båda.

När du vill använda asdfbehöver du ha git och krulla installerad. Efter det är det bara att..:

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.10.2

och lägg till dessa rader i ~/.bashrc file:

. $HOME/.asdf/asdf.sh

. $HOME/.asdf/kompletteringar/asdf.bash

Nu kan du installera plugins och verktyg i dina favoritversioner.

Plugin-baserad hantering

Till skillnad från SDKMAN! asdf använder plugins för att hantera verktyg. Så innan du kan installera ett verktyg måste du installera ett plugin. Låt oss gå tillbaka till vårt exempelprojekt och försöka konfigurera miljön med hjälp av asadfsdf.

Först måste vi installera plugins:

asdf plugin add java

asdf plugin lägga till maven

asdf plugin add mvnd

Sedan kan vi installera våra verktyg:

asdf installera java openjdk-17

asdf installera maven 3.8.4

asdf installera mvnd 0.7.1

Och än en gång, till skillnad från SDKMAN! asdf ändrar ingenting i vår miljö. När vi försöker använda java får vi ett felmeddelande som:

Ingen version har angetts för kommandot Java

Överväg att lägga till någon av följande versioner i din konfigurationsfil i ~/.tool-versions

java openjdk-17

Vi måste skapa filen .verktygs-versioner i hemkatalogen för att hantera standardversioner.

Lokala och globala versioner

Uppdatering av programvaruversioner med asdf är ganska enkelt. Vi installerar bara en ny version. Eftersom den här processen inte påverkar miljön kan vi göra det när som helst och var som helst i filsystemet. När vi vill använda en specifik version av någon programvara måste vi i projektkatalogen skapa en .verktygs-versioner fil som kan delas mellan teammedlemmarna. Kom ihåg att du måste garantera att alla teammedlemmar har asdf och plugins installerade. Listan över plugins som du kan hitta här.

Versionskonflikter

asdf stöder inte bara programmeringsspråk, ramverk och verktyg som vim eller kubernetess. Den stöder även databaser. I ett sådant fall skulle vi kunna installera flera versioner av t.ex. Postgres, men bara en instans skulle kunna köras. Det beror på att asdf kör kommandon direkt på ditt operativsystem utan något separationslager. Det leder till problem som "port redan i bruk" och konflikter om resurser.

För- och nackdelar

asdf är ett mycket bra verktyg om du vill arbeta i en polyglott miljö. Det stöder många verktyg, språk och ramverk. Den plugin-baserade arkitekturen gör det mycket enkelt att utöka detta. Vissa av de verktyg som finns i biblioteket kräver dock extra arbete under installationen för att tillhandahålla alla nödvändiga beroenden. asdf fungerar inte på Windows, inte ens på WSL.

Sist men inte minst - Docker

När jag talar om hamnkonflikten ovan känner många av er till lösningen.

Docka kan hjälpa oss i vissa fall. Jag nämner det av plikt, eftersom det här verktyget är så stort och komplext att vi inte kan diskutera det i en artikel.

Tillsammans med Docker bör vi använda en docker-compose verktyg som ger oss möjlighet att samordna miljöer med flera containrar.

För- och nackdelar med Docker

Docker hjälper oss att hantera verktyg som behöver vissa specifika resurser, som portar eller filer. Det separerar instanser i containrar och ger oss full kontroll över dem. Docker är dock ett verktyg som gör vår arbetsmiljö mycket komplex och som kan vara problematiskt i vissa fall. Ett av dessa fall av att använda Docker i ett test beskrivs i ett av våra tidigare artikel.

Sammanfattningsvis

Jag vet att jag inte har beskrivit alla verktyg som kan användas för att hantera verktygsversioner. Det finns många fler av dem, till exempel jEnv som kan ersätta SDKMAN,

eller NVM som vi kan använda för att hantera npm eller RVM för Ruby. Jag fokuserade på verktyg som jag "testade på slagfältet" och kan rekommendera till vem som helst.