Serverless – Azure Functions w Visual Studio (Azure Function Część 2)

W zeszłym tygodniu dowiedzieliśmy się jak za pomocą UI i co za pomocą UI możemy zrobić z funkcjami w Azure. Do tego chętni poznali je ciutkę głębiej dzięki wzięciu udziału w wyzwaniach. Dziś zaś to co możemy zrobić z poziomu Visual Studio i czego nie możemy zrobić. Oraz co potrzebujemy by to zrobić. A łatwo nie jest :)

---rant mode on---

Do niedawna jedynymi narzędziami dla Visual Studio były narzędzia do VS 2015. Dla VS 2017 nic nie było, teraz MS twierdzi, że jest, ale prawda jest inna (wytłumaczę później). Pomyślałem, że opiszę narzędzia w VS 2015 bo końcu istnieją dłużej i 2015 mam zainstalowany. Jednak po 5 minutach w netcie dowiedziałem się, że narzędzia są, ale w wersji preview i już nie będą rozwijane dla 2015. Więc sorki, jak macie 2015 zapomnijcie do fajnym płynnym, działającym wsparciu dla Azure Function.

No ale ostatni MS się chwalił, że dla VS 2017 są już dostępna narzędzia. No to ściągnąłem VS 2017 i go zainstalowałem. Niestety, MS tylko w niektórych miejscach wspomniał, że to nie VS 2017 ale VS 2017 15.3 Preview nas interesuje. A priview to preview, nie RTM VS. Więc sorki, jak chcecie stabilnego środowiska pracy dla funkcji to zapomnijcie. Jak dla mnie dalej nie ma działającej wersji Azure Functions dla VS. Wszystkie blogi które mówią, że jest inaczej, są w błędzie. Bo zapominają dodać, że tak, narzędzia są w wersji Preview, dla VS w wersji Preview.

---rant mode off---

To co potrzebujemy by pobawić się funkcjami to:

• VS 2017 15.3 Preview
• Azure Function Tools For Visual Studio 2017 (widzicie jak nawet nazwa jest mylna!)

Mając wszystko ściągnięte, instalujemy wszystko powoli w tym dla VS musimy wybrać: Web dev, Azure SDK, .NET Core i wsparcie dla Core. Po prostu jak zobaczycie coś z Azure lub z Core to zaznaczcie, by mieć ;)

Tworzenie

Mając wszystko gotowe (ściągnięte i poinstalowane), pora stworzyć nowy projekt . W tym celu tworzymy nowy projekt i wybieramy Azure Functions i koniec :)

MS stworzy nam szablon projektu funkcji w dwoma plikami:

• json – ustawienia dla WebJobs
• settings.json – connection strings itp.

Ale nas to nie interesuje i nie będziemy tego tykać.  Mając tak przygotowane środowisko, dodajemy nowy element do projektu:

Przed stworzeniem pliku pojawi nam się jeszcze okno wyboru typu funkcji jaką chcemy zainstalować. Nie języka! Ale typu funkcji.

Debuggowanie

Mając tak kodowe środowisko po prostu odpalmy nasz projekt – F5.

Jeżeli macie takiego farta jak ja to dostaniecie najpierw:

A po jakimś czasie:

Nie ma co się przejmować! To standard, pracujecie w końcu na Preview VS i Preview Tools! Restart VS i będzie śmigało! Działa? Jak tak to super jak nie, to może spróbujcie z restartem komputera, to Windows w końcu.

Jeżeli na, się udało odpalić wszystko to naszym oczom pokaże się konsola, w której zostanie odpalony lokalny hosting funkcji.  Jak wiadomo, funkcje w azure są open source i można je stawiać on premise. To jest właśnie przykład takiego postawienia. Ale dzięki temu mamy adres url do testowania naszej funkcji:

Do tego breakpointy działają jak i podgląd wartości też:

Deployment

Mając gotową funkcję możemy spróbować ją deployować. W tym celu mamy dwa kroki do wykonania: Utworzenie i aktualizacja. Utworzenie nie równa się aktualizacja i utworzenie nie równa się wgraniu plików. W celu wgrania funkcji, klikamy prawy przycisk myszy na nazwie projektu i Publish. Naszym oczom pojawi się widok:

By nową funkcję wgrać na Azure, wybieramy opcję Create New:

To możemy natrafić na kolejny problem z Preview, wywalenia się VS:

Na szczęście po restarcie VS śmiga jak powinno. W sensie, powtarzamy kroki, jak nam nie załaduje naszej subskrypcji, to zamykamy i powtarzamy, aż do skutku (3 razy łącznie to robiłem).

Jak się nam uda to po wykonaniu kroków utworzenia funkcji:

Nie dostaniemy, żadnej informacji o zakończeniu procesu jedynie okno się wyłączy/zamknie. Zaraz po tym jak utworzymy funkcje, musimy się podłączyć pod istniejące funkcję w celu zdeployowania naszego kodu.

Jak się nam wszystko uda, to możemy wejść na portal aure, odszukać naszą funkcję i przejrzeć to jak ona wygląda w sieci:

Jak można zaobserwować nie mamy tutaj plików źródłowych, jedynie jakiś json i w edytorze odwołanie do DLL. A no właśnie, nie korzystamy z CScript a jedynie z normalnego C#. Co znaczy, że nasz kod został z budowany przed zdeploymentem a więc jedynie postać DLL została tam wgrana.

Debuggowanie Online

Nie licząc lokalnego debugowania, mamy możliwość debugowania funkcji już wgranej i z deployowanej na azure. Czyli nie tylko możemy debugować lokalnie za pomocą F5 ale także zdalnie. Jest to bardzo fajne i przyjemna funkcjonalność. By zdebugowac taką funkcję musimy być cały czas w naszym projekcie i otworzyć Cloud Explorer. W nim dobrać się do App Services i prawym przyciskiem myszy na nazwie funkcji przyłączyć debugger:

Następnie ustawiamy break point i zaczynamy zabawę:

Fajnie? BARDZO :)

Podsumowanie

I to tyle magii. Możemy w ten sposób budować i deployować funkcję na Azure. Jest to na pewno przyjemniejsze, mamy pełne wsparcie IDE plus całkiem rozsądne środowisko uruchomieniowe. Jak na preview to też działa to nawet stabilnie. Są małe problemy, ale z drugiej strony z poziomu AWS nie mieliśmy tak wygodnych narzędzi.

Ale jak to… tylko tyle? A tak, co mogę więcej powiedzieć, siadać i pisać kod? Nic więcej w tych toolsach naprawdę nie ma. To co nam dają to:

• Intellisense w VS
• Środowisko a la azure przy debuggowaniu
• Środowisko azure przy debuggowaniu
• Wsparcie deploymentu
• Kilka wizzardów pomagających określenie co potrzebujemy podać stworzyć by coś nam zadziałało.

Za tydzień jak się uda, jeszcze jedna rzecz związana z Azure Function Tools Cli.