Czasem zdarza się, że dysponujemy gotową albo w jakimś tam stopniu ukończona aplikacją Django i musimy ją uruchomić w nowym środowisku. Dzieje się tak w co najmniej trzech przypadkach. Po pierwsze gdy swoją aplikację chcesz uruchomić na serwerze produkcyjnym. Po drugie kiedy zaczynasz współdzielić kod i ty albo twój współpracownik ma pobrać kod aplikacji z repozytorium Git i utworzyć dla niej lokalne środowisko wirtualne. Po trzecie kiedy potrzebujesz kopii aplikacji do testowania rożnych bibliotek i nie chcesz “bałaganić” w swoim środowisku, w bazie i w aplikacji nad którą pracujesz.
Tak czy siak załóżmy że masz kod aplikacja Django i potrzebujesz dla niej środowiska wirtualnego. Jest to w sumie niezbyt skomplikowane zagadnienie pod warunkiem, że system operacyjny nam tego nie utrudni z powodu jakiejś niezgodności bibliotek czy ich baku, ale to już inna kwestia.
Tworzenie takiego środowiska wirtualnego zaczynamy dokładnie tak samo jak to jest opisane we wszystkich tutorialach mówiących o tym jak w ogóle zacząć pracę z aplikacją Django. Jedyne na co trzeba zwrócić uwagę to wymuszenie odpowiedniej wersji Pythona (identycznej z oryginalnym środowiskiem). Ja swoim katalogu z projektami tworzonymi w Pythonie mam osobne katalogi dla wirtualnych środowisk, których nazwy zaczynają się od przedrostka ‘ven_‘ i osobne katalogi w których przechowuję same aplikacje, których nazwy zaczynają się od ‘app_‘. Lubię mieć porządek, ale każdy może mieć taki porządek jak jemu pasuje więc inna organizacja nie jest wykluczona.
Żeby zrobić to “po mojemu” przechodzę do katalogu z projektami Python:
$ cd /sciezka/do/projetow/Python
Tworzę katalog dla środowiska wirtualnego:
$ mkdir ven_nazwasrodowiska
Następnie tworzę środowisko środowisko wirtualne wskazując katalog w którym ma się znaleźć oraz wymuszając wybraną wersją pythona:
$ virtualenv ven_nazwasrodowiska -p python3.6
Jeśli wszystko przebiegło prawidłowo, należy uruchomić środowisko wirtualne.
$ source /sciezka/do/projetow/Python/ven_nazwasrodowiska/bin/activate
O powodzeniu świadczy zmiana znaku zachęty, który w tym wypadku będzie wyglądał następująco: (ven_nazwasrodowiska)$
Następnie Należy przejść do katalogu z kopią aplikacji Django (na przykład sklonowaną z Git) i uruchomić reqiurements.txt
(ven_nazwasrodowiska)$ pip install -r requirements.txt
Oczywiście jest kilka warunków:
- Mamy zainstalowany pip
- W pliku reqiurements.txt mamy listę wszystkich wymaganych przez aplikację pakietów
- Pakiety, które chcemy doinstalować w wybranej wersji nie kolidują z jakimiś pakietami znajdującymi się w systemie.
Oczywiście o tym wszystkim dowiemy się z komunikatów, szczególnie jeśli instalacja nie od razu się powiedzie.
Kiedy już uda się doprowadzić instalację reqiurements.txt do szczęśliwego końca, kiedy mamy odpowiednią kopię bazy danych i aplikacja ma skonfigurowane połączenie z nią (Ściąga z tworzenia i konfiguracji aplikacji), nie pozostaje nic innego jak ją uruchomić.
(ven_nazwasrodowiska)$ python manage.py runserver
Jeśli chcemy prawdziwie przenaszalne środowisko niezbędny będzie Docker. Kilka linii w Dockerfile i docker-compose.yml i mamy działające środowisko, które bez większego problemu można uruchomić na produkcji.
Jeśli jednak z jakiegoś połowu decydujemy się na wirtualne środowisko, to gorąco polecam pyenv – https://github.com/pyenv/pyenv. Narzędzie to pozwala w bardzo łatwy sposób instalować równe wersje pythona oraz tworzyć wirtualne środowiska.
Nie rozumiem dlaczego tylko Dockera uważasz, za prawdziwie przenaszalne środowisko. Używałam Dockera również jak trzeba było i uważam że do wielu z stosowań to jak wyciąganie armaty przeciw muchom.
Książkę można napisać na ten temat :) Posłużę się przykładem. Pracowałem nad aplikacją korzystającą w AWS Lambda, język – python 3.8. Wszystko ładnie działało lokalnie, ale po odpaleniu na serwerze CI (stary klamot stojący na CentOS 6) dostawałem masę błędów. Python najpierw instalowany był przez SCL, a potem przy pomocy pyenv. Okazało się, że w systemie był mały bajzel i niektóre zmienne środowiskowe zawierały niepoprawne dane oraz niektóre zależności instalowane przez pip były zainstalowane z wykorzystaniem pythona 2.7.
To spowodowało, że posprzątałem server CI i zamiast bawić się w instalację zależności, odpalam kontener (tem sam, którego używam lokalnie), przeprowadzam wszelkiej maści testy i nie przejmuje się co jest zainstalowane/skofigurowane w systemie.
Co więcej, żaden developer, który pracował nad tym projektem, nie musiał niczego zmieniać w swoim systemie. Nie wszyscy mają zainstalowanego pythona 3.8, a był to wymóg, aby móc pracować nad tym projektem (nie da się zbudować aplikacji Lambda na innej wersji pythona niż ta zdefiniowana w projekcie).
Na koniec tylko dodam, że ten sam kontener nieraz jest wykorzystywany w środowisku produkcyjnym, co oznacza, że na każdym etapie mam to samo środowisko i przeboje w stylu “u mnie działa”, przestały być problemem :)
Jeśli w pyenv jakieś zależności instalowane przez pip zainstalowane zostały z wykorzystanie, pythona 2.7 to to oznacza, że źle było przygotowane środowisko a nie że pyenv jest do kitu :P to raz. Dwa to samo środowisko wirtualne może być wykorzystane jako interpreter na serwerze produkcyjnym. I efekt jest dokładnie taki sam.
Nigdzie nie pisałem, że pyenv jest do kitu, wręcz przeciwnie. Jest to świetne narzędzie i każdego dnia z niego korzystam. Po drugie przyznałem, że na serwerze był bajzel i że miało to wpływ na to, jak aplikacja na nim działała :)
Co do produkcyjnego wykorzystania wirtualnego środowiska. Nie mam w tym nic złego i w części projektów korzystam z tego rozwiązania. Ale to nie takie proste aby zachować zgodność między wszystkimi (większością) środowisk – dev, test, uat, prod. Jednym z najczęstszych problemów z jakimi się spotykam jest ustawienie daty/strefy czasowej. Innym problemem jest różna architektura. Kilka razy już się przejechałem na tym i musiałem kombinować z kompilacją paczek. Czasami zdarza się, że na produkcyjnym serwerze nie można nic doinstalować.
Wszystkie te problemy można rozwiązać przy pomocy dockera. Raz budujesz obraz i na jego podstawie tworzysz kontenery dla różnych środowisk.
Zdaję sobie sprawę, ze korzystanie z dockera przy każdej okazji może mijać się z celem, ale w przypadku skomplikowanych projektów, nie wyobrażam sobie pracy bez dockera (lub innego rozwiązania bazującego na kontenerach).