Käsitleda mitut keskkonda mitme projekti jaoks ühes masinas?

Vaatleme tüüpilist töökeskkonda ühes tarkvaramaja. Teil on mõned kliendid, kellel on erinevad keskkonnad. Mõned eelistavad MySQL-i, teised eelistavad Postgres'i. Üks teie rakenduse versioon vajab Java 11 ja teine Java 17. Frontend vajab npm 12 või 16, sest te kasutate erinevaid versioone nurgeline. Lõpuks on teil see kolmemõõtmeline massiivi, mis sisaldab kõigi teie andmebaaside, backend- ja frontend-versioonide kombinatsioone. Kõlab halvasti, kuid ühel päeval ütleb teie ülemus...

Multiversumi keskkonna juured

Eespool kirjeldatud olukord ei ole midagi haruldast. Migratsioon keele või raamistiku versioonide vahel, andmebaaside uuendamine või lihtsalt klientide erinevad nõuded võivad kõik konfiguratsioonid pea peale pöörata. Meil peaks olema lahendus, mis aitab meil neid muutusi hallata, mis vastab mõnele eeldusele ja/või nõuetele ja/või eesmärkidele:

• lihtne kasutada - üks käsk konfiguratsiooni või versiooni muutmiseks,
• rikkalik raamatukogu - peaks toetama mitmeid tehnoloogiaid ja "asju" (raamatukogud, raamistikud, rakendused),
• laiendatav - peaksite pakkuma võimalust lisada oma pistikprogramme.

Käesolevas artiklis keskendun kolmele valdkonnale. Esimene on Java ja JVMi tööriistad. Teine on üldotstarbelised tööriistad. Kolmas on see, kuidas kasutada dokkerit meie eesmärkide saavutamiseks.

​

Ma olen Java ja töötan JVMi peal.

Kui olete Java arendaja või üldisemalt, te töötate koos JVM tehnoloogiad, siis saate kasutada SDKMAN!. See on väga kena ja kergesti kasutatav tööriist, mis toetab paljusid raamatukogusid, raamistikke ja keeli.

Paigaldusprotsess on SDKMAN! See on üsna lihtne. Sa pead jooksma:

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

ja siis

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

Nüüd saate hallata oma Java, Scala ja Maven versioonid.

Versioonide haldamine - näide

Selles näites paigaldame ja uuendame mõne tööriista versiooni. See on vaid väike osa olemasolevatest tööriistadest.

Paigaldamine

Oletame, et teie uus projekt kasutab Java 17. Sul ei ole ühtegi Java paigaldatud versioon. Te soovite selle paigaldada ja lisaks lisada Maven Daemon tööriista, et muuta koostamine kiiremaks. Seega tuleb paigaldada ka Maven. Selleks tuleb täita kolm lihtsat käsku:

$ sdk install java 17-open

$ sdk paigaldada maven 3.8.4

$ sdk install mvnd 0.7.1

Iga tööriista paigaldamise lõpus küsitakse, kas see on vaikimisi seadistatud:

Kas soovite, et Java 17-open oleks vaikimisi määratud? (Y/n):

See on oluline, kui paigaldate uue raamatukogu või keele versiooni, sest SDKMAN! seab selle vaikimisi versiooni globaalseks kõigi terminali jaoks praeguse kasutaja jaoks.

Versioonide kontrollimine ja ajakohastamine

Aeg-ajalt peab SDKMAN! uuendama indekseid. Selle käigus võite saada teate, et on olemas mõned uued versioonid tööriistadest, mida te kasutate. Saame kontrollida, millised versioonid on saadaval, kui sisestame sdk ls. Sest sdk ls maven:

Saadaolevad Maven versioonid

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

    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



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

kohalik versioon

praegu kasutusel

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

Nagu eespool näha, on Mavenil uuem versioon kui see, mida me kasutame. Sama kehtib ka mvnd (0.8.2) ja Java (19-open). Uuendame kõike. Selleks peame lihtsalt kutsuma käsu install, kuid seekord me ei kasuta versiooni täpsustajat:

$ sdk paigaldada maven

$ sdk install mvnd

$ sdk installida java

Kuid midagi juhtus valesti. Maven ja mvnd on õiged versioonid, kuid Java on versioon 17.0.5-tem. Seda seetõttu, et tööriista "uusimat" versiooni kontrollib selle müüja, mitte kohalik SDKMAN! kes on see müüja? SDKMAN! müüja on keegi, kes saab avaldada versiooni. Oletame aga, et me lõpuks installeerime 19-avatud, ja me tegime selle vaikimisi, kuid mingil põhjusel peame kasutama 17-avatud.

Kohalikud versioonid ja terminali versioonihaldus

​
Me saame konfigureerida vaikimisi tööriista versioon, mis on globaalne kõigi projektide ja terminalide jaoks. Kui aga vajame konkreetset versiooni, on meil selleks kaks võimalust. Esimene on kasutada sdk use käsk iga kord, kui me tahame kasutada mingi tööriista konkreetset versiooni praeguses terminalis. Teiseks tuleb koostada versioonide nimekiri .sdkmanrc faili, mis on salvestatud koos projektiga.

Kui esimene variant on mõeldud ühekordseks kasutamiseks, siis teine on mõeldud meeskonnatööks ja konfiguratsioonide jagamiseks järgmiste seadmete vahel. meeskond liikmed.

SDKMANi plussid ja miinused!

SDKMAN! on väga lihtne kasutada ja sellel on rikkalik toetatud tööriistade, raamistike ja keelte raamatukogu. See töötab Linuxis, MacOSis ja Windowsis. Teisest küljest on see tööriist JVM-keskne ja nõuab autori nõusolekut müüjale. Lisaks sellele on mehaanika .sdkmanrc on väga halb ja võib kataloogide muutmise protsessi märkimisväärselt aeglustada.

Tahaksin kasutada paljusid teisi keeli

Kui teil on vaja kasutada paljusid keeli ja vahendeid, siis peaksite vaatama asdf. See tööriist keskendub "kõrgetasemelistele" tööriistadele. Kui SDKMAN! leiate palju Java-spetsiifilisi tööriistu, nagu Bpipe või Znai, siis asdf pakub palju rohkem tööriistu, kuid mitte nii spetsiifilisi. Loomulikult kattuvad mõned neist tööriistadest, nt Java, Tomcat või mvnd on mõlemas saadaval.

Kui soovite kasutada asdf, peate olema git ja curl paigaldatud. Pärast seda te lihtsalt:

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

ja lisada need read ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Nüüd saate installida pluginad ja tööriistad oma lemmikversioonides.

Pistikupesa-põhine juhtimine

Erinevalt SDKMANist!, asdf kasutab tööriistade haldamiseks pluginaid. Seega, enne kui saate tööriista paigaldada, peate paigaldama plugina. Lähme tagasi meie näidisprojekti juurde ja proovime seadistada keskkonda kasutades asadfsdf.

Kõigepealt peame paigaldama pluginad:

asdf plugin lisab java

asdf plugin lisada maven

asdf plugin add mvnd

Seejärel saame paigaldada oma tööriistad:

asdf install java openjdk-17

asdf install maven 3.8.4

asdf install mvnd 0.7.1

Ja veel kord, erinevalt SDKMANist!, asdf ei muuda midagi meie keskkonnas. Kui me üritame kasutada java't, saame veateate nagu:

Käskkirja Java jaoks ei ole versiooni määratud

Kaaluge, kas lisada üks järgmistest versioonidest oma konfiguratsioonifaili ~/.tool-versions

java openjdk-17

Me peame looma faili .tool-versioonid kodukataloogis, et hallata vaikimisi versioone.

Kohalikud ja globaalsed versioonid

Tarkvaraversioonide uuendamine koos asdf on üsna lihtne. Me lihtsalt paigaldame uue versiooni. Kuna see protsess ei mõjuta keskkonda, võime seda teha igal ajal ja igas kohas failisüsteemis. Kui me tahame kasutada mingi tarkvara konkreetset versiooni, peame looma projekti kataloogi .tool-versioonid faili, mida saab meeskonnaliikmete vahel jagada. Pidage meeles, et peate tagama, et kõigil meeskonnaliikmetel on asdf ja pluginad paigaldatud. Pistikprogrammide loetelu leiate siin.

Versioonikonfliktid

asdf toetab mitte ainult programmeerimiskeeli, raamistikke ja vahendeid nagu vim või kubernetess. See toetab ka andmebaase. Sellisel juhul võiksime paigaldada mitu versiooni näiteks Postgresist, kuid käivitada saaksime ainult ühe instantsi. Seda seetõttu, et asdf täidab käske otse teie operatsioonisüsteemis ilma eralduskihita. See toob kaasa selliseid probleeme nagu "port on juba kasutusel" ja konfliktid ressurssidega.

Plussid ja miinused

asdf on väga hea vahend, kui soovite töötada mitmekeelses keskkonnas. See toetab paljusid tööriistu, keeli ja raamistikke. Plugin-põhine arhitektuur teeb selle laiendamise väga lihtsaks. Siiski vajavad mõned tööriistad, mis tal raamatukogus on, paigaldamise ajal lisatööd, et tagada kõik vajalikud sõltuvused. asdf ei tööta Windowsis, isegi mitte WSL.

Viimane, kuid mitte vähem oluline - Docker

Kui ma räägin eespool sadamakonfliktist, siis paljud teist teavad lahendust.

Docker võiks meid mõnel juhul aidata. Ma mainin seda kohusetundest, sest see tööriist on nii suur ja keeruline, et me ei saa seda ühes artiklis arutada.

Koos Dockeriga peaksime kasutama docker-compose vahend, mis annab meile võimaluse koordineerida mitme konteineri keskkondi.

Dockeri plussid ja miinused

Docker aitab meil hallata tööriistu, mis vajavad teatavaid ressursse, näiteks porte või faile. See eraldab instantsid konteinerites ja annab meile täieliku kontrolli nende üle. Sellest hoolimata on Docker vahend, mis toob meie töökeskkonda palju keerukust ja võib mõnel juhul olla problemaatiline. Üks sellistest Dockeri kasutamise juhtudest testis on kirjeldatud ühes meie varasemas artikkel.

Kokkuvõte

Ma tean, et ma ei kirjeldanud kõiki vahendeid, mida võiks kasutada tööriistade versioonide haldamiseks. Neid on palju rohkem, näiteks jEnv mis võiks asendada SDKMANi,

või NVM mida me saame kasutada npm või RVM Ruby jaoks. Keskendusin tööriistadele, mida ma "lahinguväljal katsetasin" ja mida võin soovitada kõigile.