Håndtere flere miljøer til flere projekter på én maskine?

Lad os tage et kig på et typisk arbejdsmiljø i en Softwarehus. Du har et par kunder, som har forskellige miljøer. Nogle foretrækker MySQL, andre foretrækker Postgres. En version af din applikation har brug for Java 11, og en anden Java 17. Frontend har brug for npm 12 eller 16, fordi du bruger forskellige versioner af kantet. Endelig har du det tredimensionelle array, som indeholder kombinationer af alle dine DB'er, backend- og frontend-versioner. Det lyder slemt, men en dag siger din chef ...

Rødder til et multivers-miljø

Den situation, der er beskrevet ovenfor, er ikke ualmindelig. Migration mellem sprog- eller rammeversioner, opdateringer af databaser eller simpelthen forskellige krav fra kunder kan vende op og ned på alle konfigurationer. Vi bør have en løsning, der hjælper os med at håndtere disse ændringer, en løsning, der matcher nogle få antagelser og/eller krav og/eller mål:

• nem at bruge - enkelt kommando til at ændre en konfiguration eller en version,
• rigt bibliotek - skal understøtte flere teknologier og "ting" (biblioteker, frameworks, apps),
• udvidelig - bør du tilbyde muligheden for at tilføje dine plugins.

I denne artikel vil jeg fokusere på tre områder. Det første er værktøjer til Java og JVM. Det andet er værktøjer til generelle formål. Det tredje er, hvordan vi bruger docker til at nå vores mål.

​

Jeg er Java, og jeg arbejder på JVM

Når du er en Java-udvikler eller, mere generelt, du arbejder med JVM-teknologierså kan du bruge SDKMAN!. Det er et meget flot og brugervenligt værktøj, som understøtter mange biblioteker, frameworks og sprog.

Installationsprocessen af SDKMAN! Det er ret enkelt. Du er nødt til at løbe:

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

og derefter

source "$HOME/.sdkman/bin/sdkman-init.sh"

Nu kan du styre din Java, Scala og Maven versioner.

Håndtering af versioner - eksempel

I dette eksempel vil vi installere og opdatere versionen af nogle få værktøjer. Dette er kun en lille delmængde af de tilgængelige værktøjer.

Installation

Lad os antage, at din nye projekt anvendelser Java 17. Du har ikke nogen Java version installeret. Du vil gerne installere den og derudover tilføje et Maven Daemon-værktøj for at gøre builds hurtigere. Så du skal også installere Maven. For at gøre det skal du udføre tre enkle kommandoer:

$ sdk install java 17-open

$ sdk installerer maven 3.8.4

$ sdk install mvnd 0.7.1

I slutningen af installationen af hvert værktøj bliver du spurgt, om du vil gøre det til standard:

Vil du have Java 17-open indstillet som standard (J/N):

Dette er vigtigt, når du installerer en ny version af et bibliotek eller et sprog, fordi SDKMAN! vil indstille standardversionen som global for alle terminaler for den aktuelle bruger.

Kontrol af versioner og opdatering

Fra tid til anden er SDKMAN! nødt til at opdatere indekser. I den forbindelse kan du få en besked om, at der er nye versioner af de værktøjer, du bruger. Vi kan tjekke, hvilke versioner der er tilgængelige, ved at skrive sdk ls .. For sdk ls maven:

Tilgængelige 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

aktuelt i brug

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

Som vi ser ovenfor, har Maven en nyere version end den, vi bruger. Det samme gælder for mvnd (0.8.2) og Java (19-open). Lad os opdatere det hele. For at gøre det skal vi bare kalde kommandoen install, men denne gang bruger vi ikke en versionsangivelse:

$ sdk installer maven

$ sdk installer mvnd

$ sdk installer java

Men der skete noget forkert. Maven og mvnd har korrekte versioner, men Java har version 17.0.5-tem. Det skyldes, at "den nyeste" version af værktøjet styres af leverandøren og ikke af den lokale SDKMAN! Hvem er denne leverandør? En leverandør i SDKMAN! er en person, der kan udgive en version. Men lad os sige, at vi endelig installerer 19-åbenog vi gjorde den til standard, men af en eller anden grund er vi nødt til at bruge 17-åben.

Lokale versioner og versionsstyring pr. terminal

​
Vi kan konfigurere en standard version af et værktøj, som er global for alle projekter og terminaler. Men når vi har brug for en specifik version, har vi to måder at gøre det på. Den første er at bruge sdk brug hver gang vi vil bruge en bestemt version af et værktøj i den aktuelle terminal. Det andet er at forberede en versionsliste i en .sdkmanrc fil, der er gemt sammen med projektet.

Mens den første mulighed er til engangsbrug, er den anden designet til at arbejde med teams og dele konfigurationer mellem hold medlemmer.

Fordele og ulemper ved SDKMAN!

SDKMAN! er meget let at bruge og har et rigt bibliotek af understøttede værktøjer, frameworks og sprog. Det fungerer på Linux, MacOS og Windows. På den anden side er dette værktøj JVM-fokuseret og kræver forfatterens accept af at være leverandør. Derudover er mekanikeren i .sdkmanrc er meget dårlig og kan forsinke processen med at skifte mappe betydeligt.

Jeg vil gerne bruge mange andre sprog

Hvis du har brug for at bruge mange sprog og værktøjer, bør du tage et kig på asdf. Dette værktøj er fokuseret på værktøjer på "højt niveau". Mens du i SDKMAN! kan finde mange Java-specifikke værktøjer, som Bpipe eller Znai, tilbyder asdf meget flere værktøjer, men ikke så specifikke. Selvfølgelig overlapper nogle af disse værktøjer hinanden, f.eks. er Java, Tomcat eller mvnd tilgængelige i begge.

Når du gerne vil bruge asdfskal du have git og krølle installeret. Derefter skal du bare:

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

og tilføj disse linjer i ~/.bashrc file:

. $HOME/.asdf/asdf.sh

. $HOME/.asdf/completions/asdf.bash

Nu kan du installere plugins og værktøjer i dine foretrukne versioner.

Plugin-baseret administration

I modsætning til SDKMAN! asdf bruger plugins til at administrere værktøjer. Så før du kan installere et værktøj, skal du installere et plugin. Lad os gå tilbage til vores eksempelprojekt og prøve at konfigurere miljøet ved hjælp af asadfsdf.

Først skal vi installere plugins:

asdf-plugin tilføjer java

asdf-plugin tilføj maven

asdf-plugin add mvnd

Så kan vi installere vores værktøjer:

asdf install java openjdk-17

asdf installer maven 3.8.4

asdf install mvnd 0.7.1

Og igen, i modsætning til SDKMAN! asdf ændrer ikke noget i vores miljø. Når vi prøver at bruge java, får vi en fejlmeddelelse som:

Der er ikke angivet nogen version for kommandoen Java

Overvej at tilføje en af følgende versioner i din konfigurationsfil i ~/.tool-versions

java openjdk-17

Vi er nødt til at oprette filen .værktøjs-versioner i hjemmebiblioteket for at administrere standardversioner.

Lokale og globale versioner

Opdatering af softwareversioner med asdf er ret enkelt. Vi installerer bare en ny version. Da denne proces ikke påvirker miljøet, kan vi gøre det når som helst og hvor som helst i filsystemet. Når vi vil bruge en bestemt version af noget software, skal vi i projektmappen oprette en .værktøjs-versioner fil, der kan deles mellem teammedlemmerne. Husk, at du skal garantere, at alle teammedlemmer har asdf og plugins installeret. Listen over plugins kan du finde her.

Versionskonflikter

asdf understøtter ikke kun programmeringssprog, frameworks og værktøjer som vim eller kubernetess. Den understøtter også databaser. I et sådant tilfælde kunne vi installere flere versioner af f.eks. Postgres, men kun én instans kunne køre. Det skyldes, at asdf udfører kommandoer direkte på dit operativsystem uden noget separationslag. Det fører til problemer som "port allerede i brug" og konflikter om ressourcer.

Fordele og ulemper

asdf er et rigtig godt værktøj, hvis du gerne vil arbejde i et polyglot-miljø. Det understøtter mange værktøjer, sprog og frameworks. Plugin-baseret arkitektur gør det meget nemt at udvide det. Men nogle af de værktøjer, der findes i biblioteket, kræver ekstra arbejde under installationen for at levere alle de nødvendige afhængigheder. asdf virker ikke på Windows, selv ikke på WSL.

Sidst men ikke mindst - Docker

Når jeg taler om havnekonflikten ovenfor, kender mange af jer løsningen.

Docker kan hjælpe os i nogle tilfælde. Jeg nævner det af pligt, fordi dette værktøj er så stort og komplekst, at vi ikke kan diskutere det i én artikel.

Sammen med Docker skal vi bruge en docker-compose værktøj, der giver os mulighed for at koordinere miljøer med flere containere.

Fordele og ulemper ved Docker

Docker hjælper os med at administrere værktøjer, der har brug for bestemte ressourcer, f.eks. porte eller filer. Det adskiller instanser i containere og giver os fuld kontrol over dem. Ikke desto mindre er Docker et værktøj, der introducerer en masse kompleksitet i vores arbejdsmiljø og kan være problematisk i nogle tilfælde. Et af disse tilfælde med brug af Docker i en test er beskrevet i en af vores tidligere artikel.

Opsummering

Jeg ved godt, at jeg ikke har beskrevet alle de værktøjer, der kan bruges til at styre værktøjsversioner. Der er mange flere af dem, f.eks. jEnv der kan erstatte SDKMAN,

eller NVM som vi kan bruge til at styre npm eller RVM for Ruby. Jeg fokuserede på værktøjer, som jeg har "testet på slagmarken" og kan anbefale til alle.