Jak wdrożyć aplikację Flask + Python na Windows Azure?

Question

Niedawno opracowałem aplikację w Flask + Python z bazą danych PostgreSQL.

Jak mogę przesłać aplikację na Windwos Azure? Czy system Windows Azure obsługuje Flask? Czy warto instalować aplikację Flask na maszynie wirtualnej Windows Azure?

Wiele tutoriali zaleca używanie Visual Studio i IPython z Django, ale to nie jest mój wybór.

Czy jest jakiś przewodnik lub samouczek, aby rozpocząć?

Answer 1

Zakładając, że chcesz utworzyć usługę w chmurze, najprostszym sposobem na rozpoczęcie będzie korzystanie z usługi Windows Azure PowerShell i nowej funkcji szablonu - pozwala to tworzyć niestandardowe rusztowania dla własnych ról. Użytkownik umieści konfigurację ról niezbędnych do zainstalowania środowiska wykonawczego Python i Flask w folderze szablonu, a następnie użyje narzędzia Publish-AzureServiceProject do opublikowania na platformie Azure.

Jest wbudowana obsługa ról internetowych Django, więc możesz zacząć od tego miejsca i wprowadzić modyfikacje niezbędne do obsługi Flask.

Inną opcją byłoby użycie maszyny wirtualnej Linux, którą można skonfigurować za pośrednictwem SSH. PowerShell lub wieloplatformowy interfejs CLI byłby tu bardzo pomocny, zobacz: http://www.windowsazure.com/en-us/develop/nodejs/tutorials/linux-virtual-machine/ , aby przejść na wirtualnych maszynach.

Answer 2

Od lipca 2013 r. Na platformie Azure znajduje się szablon Flask.

Uruchom z tym. Sklonuj go do swojego komputera. W katalogu głównym jest trochę rzeczy IIS, a w kolektorze FlaskApplication znajduje się Flara z cześć świat. Możesz przetestować aplikację Flask na swoim komputerze python __init__.py. Nie wiem, jak przetestować lokalnie witrynę IIS.

Nie wiem, jak działają zależności. W szablonie znajduje się Pip requirements.txt, a także drzewa źródłowe Flask i kilka innych bibliotek.

Skopiowałem aplikację z Heroku do Azure. W końcu to działa. Największą trudność stanowiło znajdowanie i odczytywanie dzienników (musisz włączyć wszystkie rejestrowanie w menedżerze usług IIS, a następnie przeglądać witrynę FTP, a następnie logi są głęboko w jakimś dziwnym pliku xml), co spowodowało, że dwa drobne problemy trwały dłużej. niż powinny rozwiązać

1. katalog roboczy różni się Heroku (w katalogu głównym witryny IIS, zamiast katalogu głównego serwisu kolbę)
2. szablon ma podejrzanie web.config że dyskretnie usuwa ciągi zapytań z gET

To był problem

<action type="Rewrite" url="handler.fcgi/{R:1}" appendQueryString="false" />