Obsługa wielu środowisk dla wielu projektów na jednym komputerze?

Przyjrzyjmy się typowemu środowisku pracy w software house. Masz kilku klientów, którzy mają różne środowiska. Niektórzy preferują MySQL, inni Postgres. Jedna z wersji aplikacji wymaga Java 11, a kolejna Java 17. Frontend wymaga npm 12 lub 16, ponieważ używasz różnych wersji kątowy. Wreszcie masz tę trójwymiarową tablicę, która zawiera kombinacje wszystkich baz danych, wersji zaplecza i frontendu. Brzmi źle, ale pewnego dnia twój szef mówi...

Korzenie środowiska multiwersum

Sytuacja opisana powyżej nie jest niczym niezwykłym. Migracja między wersjami językowymi lub frameworkami, aktualizacje baz danych lub po prostu inne wymagania klientów mogą wywrócić wszystkie konfiguracje do góry nogami. Powinniśmy mieć rozwiązanie, które pomoże nam zarządzać tymi zmianami, takie, które pasuje do kilku założeń i/lub wymagań i/lub celów:

• łatwy w użyciu - pojedyncze polecenie do zmiany konfiguracji lub wersji,
• bogata biblioteka - powinien obsługiwać wiele technologii i "rzeczy" (bibliotek, frameworków, aplikacji),
• rozszerzalny - powinieneś oferować możliwość dodawania swoich wtyczek.

W tym artykule skupię się na trzech obszarach. Pierwszy to narzędzia dla Javy i JVM. Drugi to narzędzia ogólnego przeznaczenia. Trzeci to sposób wykorzystania dockera do osiągnięcia naszych celów.

​

Jestem Java i pracuję na JVM

Kiedy jesteś Programista Java lub, bardziej ogólnie, pracujesz z Technologie JVMmożna użyć SDKMAN!. Jest to bardzo przyjemne i łatwe w użyciu narzędzie, które obsługuje wiele bibliotek, frameworków i języków.

Proces instalacji SDKMAN! To całkiem proste. Musisz biegać:

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

a następnie

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

Teraz możesz zarządzać Java, Scala i Maven wersje.

Zarządzanie wersjami - przykład

W tym przykładzie zainstalujemy i zaktualizujemy wersję kilku narzędzi. To tylko niewielki podzbiór dostępnych narzędzi.

Instalacja

Załóżmy, że twój nowy projekt zastosowania Java 17. Nie masz żadnych Java wersja zainstalowana. Chcesz ją zainstalować i dodatkowo dodać narzędzie Maven Daemon, aby przyspieszyć kompilacje. Musisz więc również zainstalować Mavena. Aby to zrobić, należy wykonać trzy proste polecenia:

$ sdk install java 17-open

$ sdk install maven 3.8.4

$ sdk install mvnd 0.7.1

Pod koniec instalacji każdego narzędzia zostaniesz zapytany o ustawienie go jako domyślnego:

Czy chcesz, aby Java 17-open była ustawiona jako domyślna? (T/n):

Jest to ważne podczas instalowania nowej wersji biblioteki lub języka, ponieważ SDKMAN! ustawi tę domyślną wersję jako globalną dla wszystkich terminali dla bieżącego użytkownika.

Sprawdzanie wersji i aktualizacja

Od czasu do czasu SDKMAN! musi aktualizować indeksy. W tym czasie może pojawić się komunikat o nowych wersjach narzędzi, z których korzystamy. Możemy sprawdzić, które wersje są dostępne, wpisując sdk ls. Dla sdk ls maven:

Dostępne wersje Maven

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

    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



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

wersja lokalna

obecnie używana

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

Jak widzimy powyżej, Maven ma nowszą wersję niż ta, której używamy. To samo dotyczy mvnd (0.8.2) i Java (19-open). Zaktualizujmy wszystko. Aby to zrobić, wystarczy wywołać polecenie install, ale tym razem nie używamy specyfikatora wersji:

$ sdk install maven

$ sdk install mvnd

$ sdk install java

Ale stało się coś złego. Maven i mvnd mają poprawne wersje, ale Java ma wersję 17.0.5-tem. Dzieje się tak, ponieważ "najnowsza" wersja narzędzia jest kontrolowana przez jego dostawcę, a nie lokalny SDKMAN! Kim jest ten dostawca? Sprzedawca w SDKMAN! to ktoś, kto może opublikować wersję. Załóżmy jednak, że w końcu zainstalujemy 19-otwartyi ustawiliśmy ją jako domyślną, ale z jakiegoś powodu musimy użyć 17-otwarty.

Wersje lokalne i zarządzanie wersjami dla poszczególnych terminali

​
Możemy skonfigurować domyślny wersja narzędzia, która jest globalna dla wszystkich projektów i terminali. Ale gdy potrzebujemy konkretnej wersji, mamy dwa sposoby, aby to zrobić. Pierwszym z nich jest użycie sdk use za każdym razem, gdy chcemy użyć konkretnej wersji narzędzia w bieżącym terminalu. Drugim jest przygotowanie listy wersji w pliku .sdkmanrc który jest przechowywany wraz z projektem.

Podczas gdy pierwsza opcja jest przeznaczona do jednorazowego użytku, druga została zaprojektowana do pracy w zespołach i udostępniania konfiguracji między sobą. zespół członków.

Plusy i minusy SDKMAN!

SDKMAN! jest bardzo łatwy w użyciu i posiada bogatą bibliotekę obsługiwanych narzędzi, frameworków i języków. Działa na systemach Linux, MacOS i Windows. Z drugiej strony, narzędzie to jest skoncentrowane na JVM i wymaga akceptacji autora jako dostawcy. Ponadto mechanika .sdkmanrc jest bardzo słaba i może znacznie spowolnić proces zmiany katalogów.

Chciałbym używać wielu innych języków

Jeśli potrzebujesz korzystać z wielu języków i narzędzi, powinieneś rzucić okiem na asdf. Narzędzie to koncentruje się na narzędziach "wysokiego poziomu". Podczas gdy w SDKMAN! można znaleźć wiele narzędzi specyficznych dla Javy, takich jak Bpipe czy Znai, asdf oferuje znacznie więcej narzędzi, ale nie tak specyficznych. Oczywiście niektóre z tych narzędzi pokrywają się, np. Java, Tomcat lub mvnd są dostępne w obu.

Kiedy chcesz użyć asdfmusisz mieć git i zwijać się zainstalowany. Następnie wystarczy:

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

i dodać te linie w ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Teraz możesz instalować wtyczki i narzędzia w swoich ulubionych wersjach.

Zarządzanie oparte na wtyczkach

W przeciwieństwie do SDKMAN! asdf używa wtyczek do zarządzania narzędziami. Tak więc, zanim będzie można zainstalować narzędzie, należy zainstalować wtyczkę. Wróćmy do naszego przykładowego projektu i spróbujmy skonfigurować środowisko za pomocą asadfsdf.

Najpierw musimy zainstalować wtyczki:

asdf plugin add java

asdf plugin add maven

asdf plugin add mvnd

Następnie możemy zainstalować nasze narzędzia:

asdf install java openjdk-17

asdf install maven 3.8.4

asdf install mvnd 0.7.1

I po raz kolejny, w przeciwieństwie do SDKMAN! asdf nie zmienia niczego w naszym środowisku. Kiedy próbujemy użyć java, otrzymujemy komunikat o błędzie, taki jak:

Nie ustawiono wersji dla polecenia Java

Rozważ dodanie jednej z następujących wersji w pliku konfiguracyjnym ~/.tool-versions

java openjdk-17

Musimy utworzyć plik .tool-versions w katalogu domowym, aby zarządzać domyślnymi wersjami.

Wersje lokalne i globalne

Aktualizacja wersji oprogramowania za pomocą asdf jest całkiem proste. Po prostu instalujemy nową wersję. Ponieważ proces ten nie wpływa na środowisko, możemy to zrobić w dowolnym momencie i w dowolnym miejscu w systemie plików. Gdy chcemy użyć konkretnej wersji jakiegoś oprogramowania, musimy utworzyć w katalogu projektu plik .tool-versions plik, który może być udostępniany członkom zespołu. Pamiętaj, że musisz zagwarantować, że wszyscy członkowie zespołu mają asdf i zainstalowane wtyczki. Lista wtyczek, które można znaleźć tutaj.

Konflikty wersji

asdf obsługuje nie tylko języki programowania, frameworki i narzędzia takie jak vim czy kubernetess. Obsługuje również bazy danych. W takim przypadku moglibyśmy zainstalować wiele wersji np. Postgresa, ale uruchomić tylko jedną instancję. To dlatego, że asdf wykonuje polecenia bezpośrednio w systemie operacyjnym bez żadnej warstwy separacji. Prowadzi to do problemów takich jak "port już używany" i konfliktów zasobów.

Plusy i minusy

asdf jest bardzo dobrym narzędziem, jeśli chcesz pracować w środowisku poliglotycznym. Obsługuje wiele narzędzi, języków i frameworków. Architektura oparta na wtyczkach sprawia, że bardzo łatwo jest ją rozszerzyć. Jednak niektóre z narzędzi, które ma w bibliotece, wymagają dodatkowej pracy podczas instalacji, aby zapewnić wszystkie wymagane zależności. asdf nie działa w systemie Windows, nawet na WSL.

Ostatni, ale nie mniej ważny - Docker

Kiedy mówiłem o konflikcie portów powyżej, wielu z was zna rozwiązanie.

Docker może nam pomóc w niektórych przypadkach. Wspominam o tym z obowiązku, ponieważ narzędzie to jest tak duże i złożone, że nie sposób omówić go w jednym artykule.

Wraz z Dockerem, powinniśmy użyć pliku docker-compose narzędzie, które daje nam możliwość koordynowania środowisk wielokontenerowych.

Plusy i minusy platformy Docker

Docker pomaga nam zarządzać narzędziami, które wymagają określonych zasobów, takich jak porty lub pliki. Oddziela instancje w kontenerach i daje nam nad nimi pełną kontrolę. Niemniej jednak, Docker jest narzędziem, które wprowadza wiele złożoności do naszego środowiska pracy i może być problematyczne w niektórych przypadkach. Jeden z takich przypadków użycia Dockera w teście został opisany w jednym z naszych poprzednich artykułów. artykuł.

Podsumowanie

Wiem, że nie opisałem wszystkich narzędzi, które można wykorzystać do zarządzania wersjami narzędzi. Jest ich znacznie więcej, np. jEnv który mógłby zastąpić SDKMAN,

lub NVM którego możemy użyć do zarządzania npm lub RVM dla Ruby. Skupiłem się na narzędziach, które "przetestowałem na polu bitwy" i mogę polecić każdemu.