Meerdere omgevingen voor meerdere projecten op één machine?

Laten we eens kijken naar een typische werkomgeving in een softwarebedrijf. Je hebt een paar klanten die verschillende omgevingen hebben. Sommigen geven de voorkeur aan MySQL, anderen aan Postgres. Eén versie van uw applicatie heeft nodig Java 11 en een andere Java 17. Frontend heeft npm 12 of 16 nodig omdat je verschillende versies van hoekig. Uiteindelijk heb je die driedimensionale matrix die combinaties bevat van al je DB's, backend- en frontend-versies. Klinkt slecht, maar op een dag zegt je baas...

De wortels van een multiversum-omgeving

De hierboven beschreven situatie is niet ongewoon. Migratie tussen taal- of frameworkversies, updates van databases of gewoon andere eisen van klanten kunnen alle configuraties op hun kop zetten. We zouden een oplossing moeten hebben die ons helpt die veranderingen te beheren, een oplossing die overeenkomt met een aantal aannames en/of vereisten en/of doelen:

• gemakkelijk te gebruiken - Eén commando om een configuratie of versie te wijzigen,
• rijke bibliotheek - moet meerdere technologieën en "dingen" (bibliotheken, frameworks, apps) ondersteunen,
• uitbreidbaar - je moet de mogelijkheid bieden om je plugins toe te voegen.

In dit artikel zal ik me richten op drie gebieden. Ten eerste hulpmiddelen voor Java en JVM. De tweede is tools voor algemeen gebruik. De derde is hoe we docker kunnen gebruiken om onze doelen te bereiken.

​

Ik ben Java en ik werk op JVM

Wanneer je een Java-ontwikkelaar of, meer in het algemeen, je werkt met JVM-technologieëndan kun je het volgende gebruiken SDKMAN!. Dit is een zeer mooie en eenvoudig te gebruiken tool die veel bibliotheken, frameworks en talen ondersteunt.

Het installatieproces van SDKMAN! Is vrij eenvoudig. Je moet rennen:

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

en dan

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

Nu kunt u uw Java, Scala en Maven versies.

Versies beheren - voorbeeld

In dit voorbeeld zullen we de versie van een paar tools installeren en bijwerken. Dit is slechts een kleine subset van beschikbare tools.

Installatie

Laten we aannemen dat je nieuwe project gebruikt Java 17. Je hebt geen Java versie geïnstalleerd. Je wilt het installeren en daarnaast een Maven Daemon tool toevoegen om de builds sneller te maken. Je moet dus ook Maven installeren. Om dat te doen, moet je drie eenvoudige commando's uitvoeren:

$ sdk installeer java 17-open

$ sdk installeer maven 3.8.4

$ sdk installeer mvnd 0.7.1

Aan het einde van de installatie van elk hulpprogramma wordt u gevraagd of u het als standaard wilt instellen:

Wil je dat Java 17-open als standaard wordt ingesteld? (J/N):

Dit is belangrijk wanneer je een nieuwe versie van een bibliotheek of een taal installeert, omdat SDKMAN! die standaardversie zal instellen als globaal voor alle terminals van de huidige gebruiker.

Versies controleren en bijwerken

Van tijd tot tijd moet SDKMAN! indexen bijwerken. Tijdens dit proces kun je een melding krijgen dat er nieuwe versies zijn van tools die je gebruikt. We kunnen controleren welke versies beschikbaar zijn door te typen sdk ls. Voor sdk ls maven:

Beschikbare Maven versies

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

    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



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

lokale versie

momenteel in gebruik

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

Zoals we hierboven zien, heeft Maven een nieuwere versie dan degene die wij gebruiken. Hetzelfde geldt voor mvnd (0.8.2) en Java (19-open). Laten we alles bijwerken. Om dat te doen, hoeven we alleen maar het installatiecommando aan te roepen, maar deze keer gebruiken we geen versiespecificatie:

$ sdk installeren maven

$ sdk installeren mvnd

$ sdk installeer java

Maar er gebeurde iets verkeerds. Maven en mvnd hebben correcte versies, maar Java heeft versie 17.0.5-tem. Dat komt omdat "de nieuwste" versie van de tool wordt beheerd door de leverancier en niet door de lokale SDKMAN! Wie is deze leverancier? Een leverancier in SDKMAN! is iemand die een versie kan publiceren. Laten we echter zeggen dat we uiteindelijk het volgende installeren 19-openen we hebben het standaard gemaakt, maar om de een of andere reden moeten we gebruik maken van 17-open.

Lokale versies en versiebeheer per terminal

​
We kunnen een standaard versie van een tool die globaal is voor alle projecten en terminals. Maar als we een specifieke versie nodig hebben, hebben we twee manieren om dat te doen. De eerste is om de sdk gebruik commando elke keer als we een specifieke versie van een gereedschap in de huidige terminal willen gebruiken. De tweede is om een versielijst te maken in een .sdkmanrc bestand dat bij het project is opgeslagen.

Terwijl de eerste optie voor eenmalig gebruik is, is de tweede ontworpen voor het werken met teams en het delen van configuraties tussen team leden.

Voor- en nadelen van SDKMAN!

SDKMAN! is heel gemakkelijk te gebruiken en heeft een rijke bibliotheek met ondersteunde tools, frameworks en talen. Het werkt op Linux, MacOS en Windows. Aan de andere kant is deze tool JVM-georiënteerd en moet de auteur een leverancier accepteren. Bovendien is de monteur van .sdkmanrc is erg slecht en kan het proces van het wijzigen van mappen aanzienlijk vertragen.

Ik wil graag veel andere talen gebruiken

Als je veel talen en tools moet gebruiken, kijk dan eens naar asdf. Deze tool is gericht op "high-level" tools. Terwijl je in SDKMAN! veel Java-specifieke tools kunt vinden, zoals Bpipe of Znai, biedt asdf veel meer tools, maar niet zo specifiek. Natuurlijk overlappen sommige van deze tools elkaar, bijvoorbeeld Java, Tomcat of mvnd zijn beschikbaar in beide.

Wanneer u asdfmoet je het volgende hebben git en krul geïnstalleerd. Daarna hoef je alleen nog maar:

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

en voeg deze regels toe in ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Nu kun je plugins en tools installeren in je favoriete versies.

Plugin-gebaseerd beheer

In tegenstelling tot SDKMAN! asdf gebruikt plugins om tools te beheren. Dus voordat je een tool kunt installeren, moet je een plugin installeren. Laten we teruggaan naar ons voorbeeldproject en proberen de omgeving te configureren met behulp van asadfsdf.

Eerst moeten we plugins installeren:

asdf plugin toevoegen java

asdf plugin toevoegen maven

asdf plugin toevoegen mvnd

Daarna kunnen we onze gereedschappen installeren:

asdf installeer java openjdk-17

asdf maven 3.8.4 installeren

asdf installeer mvnd 0.7.1

En nogmaals, in tegenstelling tot SDKMAN! asdf verandert niets in onze omgeving. Wanneer we java proberen te gebruiken, krijgen we een foutmelding zoals:

Er is geen versie ingesteld voor opdracht Java

Overweeg om een van de volgende versies toe te voegen aan je configuratiebestand in ~/.tool-versions

java openjdk-17

We moeten bestand .tool-versies in de homedirectory om standaardversies te beheren.

Lokale en globale versies

Softwareversies bijwerken met asdf is vrij eenvoudig. We installeren gewoon een nieuwe versie. Omdat dit proces geen invloed heeft op de omgeving, kunnen we dat op elk moment en op elke plaats in het bestandssysteem doen. Als we een specifieke versie van bepaalde software willen gebruiken, moeten we in de projectmap een .tool-versies bestand dat gedeeld kan worden tussen teamleden. Onthoud dat je moet garanderen dat alle teamleden asdf en plugins geïnstalleerd. De lijst met plugins is als volgt hier.

Versieconflicten

asdf ondersteunt niet alleen programmeertalen, frameworks en tools zoals vim of kubernetess. Het ondersteunt ook databases. In zo'n geval zouden we meerdere versies van bijvoorbeeld Postgres kunnen installeren, maar slechts één instantie zou kunnen draaien. Dat komt omdat asdf voert commando's direct uit op je OS zonder enige scheidingslaag. Dat leidt tot problemen zoals "poort al in gebruik" en conflicten over bronnen.

Voor- en nadelen

asdf is een heel goed hulpmiddel als je in een polyglot omgeving wilt werken. Het ondersteunt veel tools, talen en frameworks. De plugin-gebaseerde architectuur maakt het erg gemakkelijk om uit te breiden. Sommige gereedschappen in de bibliotheek vereisen echter extra werk tijdens de installatie om alle vereiste afhankelijkheden aan te bieden. asdf werkt niet op Windows, zelfs niet op WSL.

Last but not least - Docker

Toen ik hierboven sprak over het havenconflict, kenden velen van jullie de oplossing.

Docker zou ons in sommige gevallen kunnen helpen. Ik noem het uit plichtsbesef, omdat deze tool zo groot en complex is dat we het niet in één artikel kunnen bespreken.

Samen met Docker moeten we een docker-compose gereedschap dat ons de mogelijkheid geeft om omgevingen met meerdere containers te coördineren.

Voor- en nadelen van Docker

Docker helpt ons bij het beheren van tools die specifieke bronnen nodig hebben, zoals poorten of bestanden. Het scheidt instanties in containers en geeft ons er volledige controle over. Desondanks is Docker een tool die veel complexiteit toevoegt aan onze werkomgeving en in sommige gevallen problematisch kan zijn. Een van die gevallen van het gebruik van Docker in een test is beschreven in een van onze vorige artikel.

Samenvattend

Ik weet dat ik niet alle tools heb beschreven die gebruikt kunnen worden voor het beheren van toolversies. Er zijn er nog veel meer, zoals jEnv die SDKMAN zou kunnen vervangen,

of NVM die we kunnen gebruiken om npm of RVM voor Ruby. Ik heb me gericht op tools die ik "op het slagveld heb getest" en aan iedereen kan aanbevelen.