Håndtere flere miljøer for flere prosjekter på én maskin?

La oss ta en titt på et typisk arbeidsmiljø i en programvarehus. Du har noen få kunder som har forskjellige miljøer. Noen foretrekker MySQL, andre foretrekker Postgres. Én versjon av applikasjonen din trenger Java 11, og en annen Java 17. Frontend trenger npm 12 eller 16 fordi du bruker forskjellige versjoner av kantete. Til slutt har du den tredimensjonale matrisen som inneholder kombinasjoner av alle dine DB-er, backend- og frontend-versjoner. Det høres ille ut, men en dag sier sjefen din...

Røttene til et multivers-miljø

Situasjonen beskrevet ovenfor er ikke uvanlig. Migrering mellom språk- eller rammeverksversjoner, oppdateringer av databaser eller rett og slett ulike krav fra kundene kan snu opp ned på alle konfigurasjoner. Vi bør ha en løsning som hjelper oss med å håndtere disse endringene, en løsning som samsvarer med noen forutsetninger og/eller krav og/eller mål:

• enkel å bruke - enkeltkommando for å endre en konfigurasjon eller en versjon,
• rikt bibliotek - bør støtte flere teknologier og "ting" (biblioteker, rammeverk, apper),
• utvidbar - bør du tilby muligheten til å legge til dine plugins.

I denne artikkelen vil jeg fokusere på tre områder. Det første er verktøy for Java og JVM. Det andre er verktøy for generelle formål. Det tredje er hvordan vi kan bruke docker for å nå målene våre.

​

Jeg er Java og jobber på JVM

Når du er en Java-utvikler eller, mer generelt, du jobber med JVM-teknologier, så kan du bruke SDKMAN!. Dette er et veldig fint og brukervennlig verktøy som støtter mange biblioteker, rammeverk og språk.

Installasjonsprosessen for SDKMAN! Det er ganske enkelt. Du må løpe:

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

og deretter

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

Nå kan du administrere din Java, Scala og Maven versjoner.

Administrere versjoner - eksempel

I dette eksemplet vil vi installere og oppdatere versjonen av noen få verktøy. Dette er bare et lite utvalg av tilgjengelige verktøy.

Installasjon

La oss anta at din nye prosjekt bruksområder Java 17. Du har ikke noe Java versjon installert. Du ønsker å installere den og i tillegg legge til et Maven Daemon-verktøy for å gjøre byggingen raskere. Derfor må du også installere Maven. For å gjøre det må du utføre tre enkle kommandoer:

$ sdk install java 17-open

$ sdk install maven 3.8.4

$ sdk install mvnd 0.7.1

På slutten av installasjonen av hvert verktøy blir du spurt om du vil gjøre det til standard:

Vil du at Java 17-open skal være standardinnstilling (J/N)?

Dette er viktig når du installerer en ny versjon av et bibliotek eller et språk, fordi SDKMAN! vil angi standardversjonen som global for alle terminaler for den aktuelle brukeren.

Kontrollerer versjoner og oppdaterer

Fra tid til annen må SDKMAN! oppdatere indekser. I løpet av dette kan du få en melding om at det finnes nye versjoner av verktøyene du bruker. Vi kan sjekke hvilke versjoner som er tilgjengelige ved å skrive sdk ls. For sdk ls maven:

Tilgjengelige Maven-versjoner

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

    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 versjon

for øyeblikket i bruk

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

Som vi ser ovenfor, har Maven en nyere versjon enn den vi bruker. Det samme gjelder for mvnd (0.8.2) og Java (19-open). La oss oppdatere alt. For å gjøre det trenger vi bare å kalle install-kommandoen, men denne gangen bruker vi ikke en versjonsspesifikator:

$ sdk install maven

$ sdk install mvnd

$ sdk install java

Men noe galt skjedde. Maven og mvnd har riktige versjoner, men Java har versjon 17.0.5-tem. Det er fordi "den nyeste" versjonen av verktøyet kontrolleres av leverandøren, ikke lokalt SDKMAN! hvem er denne leverandøren? En leverandør i SDKMAN! er noen som kan publisere en versjon. La oss imidlertid si at vi endelig installerer 19-åpenog vi gjorde den til standard, men av en eller annen grunn må vi bruke 17-åpen.

Lokale versjoner og versjonshåndtering per terminal

​
Vi kan konfigurere en standard versjon av et verktøy som er global for alle prosjekter og terminaler. Men når vi trenger en spesifikk versjon, har vi to måter å gjøre det på. Den første er å bruke sdk use kommandoen hver gang vi ønsker å bruke en bestemt versjon av et verktøy i den aktuelle terminalen. Det andre er å lage en versjonsliste i en .sdkmanrc filen som er lagret sammen med prosjektet.

Mens det første alternativet er for engangsbruk, er det andre designet for å jobbe med team og dele konfigurasjoner mellom team medlemmer.

Fordeler og ulemper med SDKMAN!

SDKMAN! er svært enkelt å bruke og har et rikt bibliotek med verktøy, rammeverk og språk som støttes. Det fungerer på Linux, MacOS og Windows. På den annen side er dette verktøyet JVM-fokusert og krever forfatterens aksept for å være en leverandør. I tillegg er mekanikeren av .sdkmanrc er svært dårlig og kan forsinke prosessen med å endre kataloger betydelig.

Jeg vil gjerne bruke mange andre språk

Hvis du har behov for å bruke mange språk og verktøy, bør du ta en titt på asdf. Dette verktøyet er fokusert på "høynivåverktøy". Mens du i SDKMAN! kan finne mange Java-spesifikke verktøy, som Bpipe eller Znai, tilbyr asdf mye flere verktøy, men ikke så spesifikke. Noen av disse verktøyene overlapper hverandre, f.eks. Java, Tomcat eller mvnd er tilgjengelige i begge.

Når du ønsker å bruke asdfmå du ha git og krøll installert. Etter det er det bare å..:

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

og legg til disse linjene i ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Nå kan du installere programtillegg og verktøy i favorittversjonene dine.

Plugin-basert administrasjon

I motsetning til SDKMAN! asdf bruker plugins til å administrere verktøy. Så før du kan installere et verktøy, må du installere en plugin. La oss gå tilbake til eksempelprosjektet vårt og prøve å konfigurere miljøet ved hjelp av asadfsdf.

Først må vi installere plugins:

asdf plugin add java

asdf-plugin add maven

asdf-plugin add mvnd

Så kan vi installere verktøyene våre:

asdf install java openjdk-17

asdf install maven 3.8.4

asdf install mvnd 0.7.1

Og nok en gang, i motsetning til SDKMAN! asdf endrer ikke noe i miljøet vårt. Når vi prøver å bruke java, får vi en feilmelding som:

Ingen versjon er angitt for kommandoen Java

Vurder å legge til en av følgende versjoner i konfigurasjonsfilen din på ~/.tool-versions

java openjdk-17

Vi må opprette filen .verktøyversjoner i hjemmekatalogen for å administrere standardversjoner.

Lokale og globale versjoner

Oppdatering av programvareversjoner med asdf er ganske enkelt. Vi installerer bare en ny versjon. Fordi denne prosessen ikke påvirker miljøet, kan vi gjøre det når som helst og hvor som helst i filsystemet. Når vi ønsker å bruke en bestemt versjon av en programvare, må vi opprette en .verktøyversjoner fil som kan deles mellom teammedlemmene. Husk at du må sørge for at alle teammedlemmene har asdf og plugins installert. Listen over plugins du kan finne her.

Versjonskonflikter

asdf støtter ikke bare programmeringsspråk, rammeverk og verktøy som vim eller kubernetess. Den støtter også databaser. I et slikt tilfelle kan vi installere flere versjoner av for eksempel Postgres, men bare én instans kan kjøre. Det er fordi asdf kjører kommandoer direkte på operativsystemet ditt uten noe separasjonslag. Det fører til problemer som "port allerede i bruk" og konflikter om ressurser.

Fordeler og ulemper

asdf er et svært godt verktøy hvis du ønsker å jobbe i et polyglott miljø. Det støtter mange verktøy, språk og rammeverk. Den plugin-baserte arkitekturen gjør det svært enkelt å utvide det. Noen av verktøyene som finnes i biblioteket, krever imidlertid ekstra arbeid under installasjonen for å levere alle nødvendige avhengigheter. asdf fungerer ikke på Windows, selv ikke på WSL.

Sist, men ikke minst - Docker

Når jeg snakker om havnekonflikten ovenfor, vet mange av dere løsningen.

Docker kan hjelpe oss i noen tilfeller. Jeg nevner det av plikt, fordi dette verktøyet er så stort og komplekst at vi ikke kan diskutere det i én artikkel.

Sammen med Docker bør vi bruke en docker-compose verktøy som gir oss muligheten til å koordinere miljøer med flere containere.

Fordeler og ulemper med Docker

Docker hjelper oss med å administrere verktøy som trenger bestemte ressurser, for eksempel porter eller filer. Det separerer instanser i containere og gir oss full kontroll over dem. Docker er imidlertid et verktøy som introduserer mye kompleksitet i arbeidsmiljøet vårt og kan være problematisk i noen tilfeller. Et av disse tilfellene med bruk av Docker i en test er beskrevet i en av våre tidligere artikkel.

Oppsummering

Jeg vet at jeg ikke har beskrevet alle verktøyene som kan brukes til å administrere verktøyversjoner. Det finnes mange flere av dem, for eksempel jEnv som kan erstatte SDKMAN,

eller NVM som vi kan bruke til å administrere npm eller RVM for Ruby. Jeg fokuserte på verktøy som jeg har "testet på slagmarken" og kan anbefale til alle.