Prosty problem z wdrożeniem Pythona - cały świat bólu

Mamy kilka aplikacji Pythona 2.6 uruchomionych na Linuksie. Niektóre z nich są aplikacjami webowymi pylonów, inne są po prostu długotrwałymi procesami, które uruchamiamy z linii poleceń za pomocą nohup. Używamy również virtualenv, zarówno w rozwoju, jak i w produkcji. jaki jest najlepszy sposób wdrożenia tych aplikacji na serwerze produkcyjnym?

W rozwoju po prostu dostajemy drzewo źródłowe do dowolnego katalogu, konfigurujemy virtualenv i uruchamiamy-łatwo. Możemy zrobić to samo w produkcji i być może jest to naprawdę najbardziej praktyczne rozwiązanie, ale wydaje się trochę niewłaściwe uruchamianie svn update w produkcji. Próbowaliśmy również fab, ale to nigdy nie działa za pierwszym razem. Dla każdej aplikacji coś innego idzie nie tak. Wydaje mi się, że cały proces jest po prostu zbyt trudny, biorąc pod uwagę, że to, co staramy się osiągnąć, jest zasadniczo bardzo proste. Oto, czego chcemy od procesu wdrażania.

  1. powinniśmy być w stanie uruchomić jedno proste polecenie, aby wdrożyć zaktualizowany wersja aplikacji. (Jeśli początkowe wdrożenie wymaga trochę dodatkowej złożoności, to w porządku.)
  2. kiedy uruchamiamy to polecenie, powinno ono skopiować pewne pliki, albo z repozytorium Subversion, albo z lokalnej kopii roboczej, do określonego "środowiska" na serwerze, co prawdopodobnie oznacza inny virtualenv. Mamy zarówno wersję stagingową, jak i produkcyjną aplikacji na tym samym serwerze, więc muszą być w jakiś sposób oddzielone. Jeśli instaluje się w site-packages, to dobrze też, o ile to działa.
  3. na serwerze mamy kilka plików konfiguracyjnych, które powinny być zachowane (np. nie nadpisane lub usunięte przez proces wdrażania).
  4. niektóre z tych aplikacji importują moduły z innych aplikacji , aby mogły się w jakiś sposób odnosić do siebie jako pakiety. To jest ta część, z którą mieliśmy najwięcej problemów! Nie obchodzi mnie, czy działa Poprzez względny import, Pakiety witryn lub cokolwiek, o ile działa niezawodnie w obu rozwój i produkcja.
  5. najlepiej, aby proces wdrażania automatycznie instalował zewnętrzne Pakiety, od których zależą nasze aplikacje (np. psycopg2).
To jest to! Jak trudne to może być?
Author: EMP, 2010-04-30
Source

8 answers

Tworzenie i wdrażanie kodu Pythona jest znacznie łatwiejsze dzięki setuptools w połączeniu z virtualenv i pip.

Podstawowe idee

Najtrudniejszą częścią, jaką znalazłem, jest uruchomienie środowiska programistycznego, które odzwierciedla wdrożoną konfigurację tak ściśle, jak to możliwe, przy jednoczesnym poszanowaniu narzędzi Pythonic i idiomów. Ale okazuje się, że jest to bardzo łatwe do osiągnięcia z pip i setuptools, które razem pozwalają "zainstalować" a tworzenie drzewa w środowisku Pythona bez przenoszenia plików. (W rzeczywistości setuptools robi to wszystko samo, ale pip działa jak zależnościowy interfejs front-end lepiej.)

Kolejnym kluczowym problemem jest przygotowanie czystego środowiska ze znanym zestawem pakietów w obu środowiskach. Virtualenv Pythona jest god-send pod tym względem, pozwalając na skonfigurowanie całkowicie spersonalizowanego środowiska Pythona z własnym wyborem pakietów, bez konieczności dostępu do roota lub pakietów systemu operacyjnego (rpm lub dpkg), i bez ograniczeń przez pakiety i ich wersje, które zdarzyły się być zainstalowane na twojej dystrybucji.

Wreszcie, jednym z denerwujących błędów jest trudność tworzenia skryptów wiersza poleceń, które dobrze grają z PYTHON_PATH. Jest to również traktowane dość elegancko przez setuptools.

Tworzenie

(aby wszystko było proste, jest to dość nakazowe. Proszę się rozchodzić.)

  1. przygotować katalog roboczy, który twój Python może zadzwonić do domu.
  2. Pobierz najnowszy virtualenv z dołu tej strony i odinstaluj go (nie ma znaczenia gdzie).

  3. Z katalogu roboczego Skonfiguruj nowe środowisko wirtualne Pythona: 

    $ python <untarred_directory>/virtualenv.py venv

  4. Będziesz chciał wykonywać większość swojej pracy z wnętrza tego wirtualnego środowiska. Użyj do tego polecenia ({[6] } jest skrótem dla source):

    $ . venv/bin/activate

  5. Zainstaluj pip: 

    $ easy_install pip

  6. Tworzenie katalogów dla każdy instalowalny pakiet, który chcesz utworzyć.

  7. w każdym katalogu będziesz potrzebował setup.py to określa zawartość i strukturę pakietu. Dokumentacja setuptools jest bardzo dobrym źródłem informacji na ten temat. Warto poświęcić trochę czasu.

Rozwój

Gdy twoja struktura drzewa jest gotowa, jesteś prawie gotowy do rozpoczęcia kodowania. Ale w tej chwili pakiety, które zależą od siebie, nie widzą siebie jako będą w środowisku wdrożonym. Ten problem jest rozwiązany za pomocą zgrabnej sztuczki, którą oferuje setuptools i z której pip korzysta. Dla każdego pakietu, który tworzysz, uruchom następujące polecenie (upewnij się, że jesteś w środowisku wirtualnym dla Twojego projektu, jak w kroku 3, powyżej):

$ pip install -e pkg1

To polecenie zainstaluje pkg1 w Twoim wirtualnym środowisku i robi to bez kopiowania Twoich plików. Po prostu dodaje link do katalogu site-packages wskazującego na pakiet tworzy katalog egg-info w tym katalogu głównym. Można to również zrobić bez pip, w następujący sposób: 

$ cd pkg1
$ python setup.py develop

I zazwyczaj będzie działać, ale jeśli masz zależności stron trzecich (które powinny być wymienione w setup.py jak wyjaśniono tutaj w dokumentacji setuptools), pip jest mądrzejszy w ich znajdowaniu.

Należy zauważyć, że ani setuptools, ani pip nie mają żadnego sprytu co do znajdowania zależności pomiędzy własnymi pakietami. Jeżeli PkgB w katalogu B, zależy od PkgA w katalogu a, wtedy pip install -e B zakończy się niepowodzeniem, ponieważ pip nie ma możliwości dowiedzenia się, że PkgA można znaleźć w katalogu a; zamiast tego spróbuje pobrać PkgA ze swoich źródeł online repozytorium. Obejściem jest po prostu zainstalowanie każdego pakietu po jego zależnościach.

W tym momencie możesz uruchomić Pythona, załadować jeden ze swoich modułów i zacząć się nim bawić. Możesz edytować kod i będzie on natychmiast dostępny przy następnym imporcie.

Wreszcie, jeśli chcesz utworzyć narzędzia wiersza poleceń ze swoimi pakietami. Nie pisz ich ręcznie. Skończysz z okropnym bałaganem hacków PYTHON_PATH, które nigdy nie działają poprawnie. Po prostu przeczytaj automatyczne tworzenie skryptów w dokumentacji setuptools. Oszczędzi ci to wiele smutku.

Wdrożenie

Kiedy twoje pakiety będą gotowe do działania, możesz użyć setup.py aby utworzyć Pakiety wdrożeniowe. Istnieje zbyt wiele opcji, aby przejść do tutaj, ale następujące powinny na początek: 

$ cd pkg1
$ python setup.py --help
$ python setup.py --help-commands

Loose ends

Ze względu na szeroki charakter pytania, odpowiedź ta jest koniecznie niekompletna. Nie zajmowałem się długo działającymi serwerami, frameworkami sieciowymi ani samym procesem wdrażania (w szczególności używaniem instalacji pip --index-url do zarządzania prywatnym repozytorium pakietów zewnętrznych i wewnętrznych oraz -e vcs+..., które będzie wyciągać pakiety z svn, git, hg lub bzr). Ale mam nadzieję, że dałem ci wystarczająco dużo liny, aby związać to wszystko razem (tylko nie powiesić siebie z nim : -).

 23
Author: Marcelo Cantos,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-11 00:18:51

To naprawdę nie jest trudne. Musisz grać głównie z buildout I supervisord IMO.

Podczas nauki buildout może zająć trochę czasu, ale warto, biorąc pod uwagę ilość bólu zmniejsza się w powtarzających się setupach.

O nohup: podejście nohup nie pasuje do poważnych wdrożeń. Mam bardzo dobre doświadczenie z supervisord. Jest to doskonałe rozwiązanie do uruchamiania aplikacji produkcyjnych Pythona. Jest bardzo łatwy w konfiguracji.

Kilka konkretnych odpowiedzi poniżej.

  1. pojedyncze polecenie wdrożenia: Buildout jest odpowiedzią. Używamy go od kilku lat z niewielkimi problemami
  2. zazwyczaj jest tak, jakbyś sprawdzał źródło. Więc biegnij. Co więcej, może to nie być dobry pomysł, aby pozwolić kopię instalacyjną do site-packages. Lepiej trzymać środowiska oddzielnie.
  3. Configs nie zostałby nadpisany.
  4. możesz / powinieneś rozważyć zbudowanie jajek dla wspólnych pakietów. Jak można zbudować jajko na paczkę (powiedzmy commonlib) i przesłać go do repozytorium kodu. Następnie możesz określić to jako zależność w buildoucie.cfg
  5. Buildout jest w stanie zbudować najbardziej istotne Pakiety całkowicie oddzielone od instalacji centralnego/najwyższego poziomu. Jednak z mojego doświadczenia Pakiety Pythona z rozszerzeniem c, jeśli są instalowane jako pakiety systemu operacyjnego, jest to znacznie łatwiejsze.
 6
Author: Shekhar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-08-08 17:36:06

Pracowałem nad wdrożeniem tego do naszych projektów. Chodzi o kilka różnych części.

Najpierw dostosowujemy virtualenv.py korzystanie z ich zdolności bootstrap do dodawania własnych niestandardowych funkcji i FLAG Post-creation. Pozwala nam to definiować typowe typy projektów, a także daje nam jedną komendę do tworzenia nowego virtualenv, checkout projektu z repozytorium git, i zainstalować wszelkie wymagania do virtualenv za pomocą pip i wymagania.txt pliki.

Więc nasze polecenia wyglądają jak: python venv.py --no-site-packages-g $git_proj-t $tag_num $venv_dir

Http://pypi.python.org/pypi/virtualenv http://pip.openplans.org/

Teraz to pozwala nam na wstępne sprawdzenie istniejącego projektu. Podczas pracy i aktualizacji projektu używamy poleceń fabric w każdym projekcie do budowania wydań, a następnie ich wdrażania:

Http://docs.fabfile.org/0.9.0/

I ' ve got a fab command: make_tag, który sprawdza nieużywane zmiany, otwiera pliki, które wymagają aktualizacji ciągów wersji, buduje i przesyła dokumenty sphinx, a następnie zatwierdza końcowy znacznik do repozytorium.

Druga strona to polecenie Fab deploy, które poprzez ssh wykona git co o podanym tagu, uruchomi aktualizację pip na wszelkie nowe wymagania, uruchomi wszelkie potrzebne migracje baz danych, a następnie resetuje serwer WWW, jeśli jest to aplikacja internetowa.

Oto przykład tagowania funkcja: http://www.google.com/codesearch/p?hl=en#9tLIXCbI4vU/fabfile.py&q=fabfile.py%20git%20tag_new_version&sa=N&cd=1&ct=rc&l=143

Istnieje mnóstwo dobrych plików tkanin, które można przeglądać za pomocą wyszukiwarki kodów google. Wiem, że oszukałem kilka na własny użytek.

To jest zdecydowanie skomplikowane i ma kilka części, aby wszystko działało gładko. Gdy już go uruchomisz, elastyczność i szybkość działania są po prostu niesamowite.

 5
Author: Rick,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-04-30 11:43:16

Spójrz na Buildout dla powtarzalnych wdrożeń.

 2
Author: Oddthinking,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-04-30 08:24:04

Kolejny głos na fabric (jeszcze nie próbowałem Buildout). Używamy go z powodzeniem od kilku miesięcy.

Jeśli masz problemy z tkaniną, inną opcją jest Capistrano . Działa świetnie (nawet dla aplikacji innych niż rails). Przestałem go używać tylko dlatego, że dziwnie jest używać Ruby do wdrażania aplikacji Pythona;)

 0
Author: Chris Reid,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-06 02:31:32

Użyłbym rsync do synchronizacji Na zewnątrz z twojego produkcyjnego serwera "prime" do innych i z twojej platformy " beta testowej "do twojego produkcyjnego serwera" prime".

Rsync ma tę zaletę, że kopiuje tylko te pliki, które się zmieniły, i kopiuje tylko części plików, które uległy częściowej zmianie, i weryfikuje integralność i identyczną zawartość na końcu na wszystkich maszynach. Aktualizacja, która przechodzi część i zostaje przerwana, może być z łatwością kontynuowana później, dzięki czemu wdrożenie będzie bardziej solidny.

Subversion lub Mercurial również nie byłby złym pomysłem w tym przypadku. Mercurial ma zaletą jest możliwość "ciągnięcia" lub "pchania" zamiast aktualizowania z jednego centralnego źródła. Możesz znaleźć interesujące przypadki, w których model zdecentralizowany (mercurial) działa lepiej.

 0
Author: Warren P,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-10 19:00:33

Jeśli jesteś osobą budującą, powinieneś wiedzieć o miniage.przepis.Skrypty możliwość wygenerowania pliku do Ustawienia środowiska Pythona. Źródło do serwera WWW i buildout jest całkowicie przenośny.

 0
Author: chiggsy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-11 00:28:02

To brzmi jak to, co chcesz jest skrypt budowania. Więc napisz jeden, używając powłoki, Pythona, ant lub ulubionego narzędzia do budowania. Jeśli nie lubisz pisać w XML, pant pozwala na pisanie skryptów ant w Pythonie. Kilka osób wspomniało buildout , ale ja nie mam z tym żadnego doświadczenia.

Najpierw określ swoje kroki. Brzmi jakbyś chciał:

  1. eksport SVN z tagu produkcyjnego (nie chcesz mieć kopii roboczej w prod)
  2. Zestaw virtualenv
  3. easy_install lub pip instalują wymagane pakiety (lub prawdopodobnie używają wstępnie pobranych i przetestowanych wersji)
  4. skopiuj pliki konfiguracyjne produkcji do celu (nie jest dobrym pomysłem, aby zachować te informacje w repo źródłowym -- choć można je wersjonować osobno)
  5. uruchom ponownie serwer i wykonaj inne zadanie konfiguracji
  6. uruchom testy dymu i wycofaj po awarii

Jeśli wykonujesz równoważenie obciążenia lub w zależności od innych usług produkcja możesz chcieć wymyślić sposób na wprowadzenie ograniczonego zakresu, aby wszyscy twoi klienci nie zostali dotknięci jednocześnie. Jeśli masz środowisko inscenizacyjne podobne do produkcji, które może również zaspokoić tę potrzebę.

 0
Author: fijiaaron,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-01-29 17:25:25