Ostatnia sobota była bardzo pracowita. Wybrałam się na devWarsztaty zorganizowane przez PGS Software i prowadzone przez Piotra Gankiewicza i Łukasza Pyrzyka. Dotyczyły one frameworka .NET Core i Dockera. Dokładnym celem warsztatów było:

Celem warsztatów jest nabycie wiedzy dotyczącej pracy z najnowszą wersją frameworka ASP.NET Core oraz automatyzacji procesu budowy, jak i wdrożenia usługi na własną maszynę wirtualną w chmurze obliczeniowej.

Warsztaty były bardzo intensywne, prelegenci w dobry sposób przekazali swoją wiedzę i starali się pomóc każdemu, kto miał jakiekolwiek problemy (a problemów nie brakowało). Ale oczywiście jeśli coś jest dobre, to nie znaczy, że nie może być lepsze:)

Poniżej moje uwagi dotyczące każdej części warsztatów:

 CZĘŚĆ – „Stworzenie systemu rozproszonego na zasadzie API + serwis, komunikujący się za pomocą szyny danych RabbitMQ”

Ta część obejmowała utworzenie od zera aplikacji .NET Core, której celem miało być wyliczanie danej liczby ciągu Fibonacciego. Wykorzystaliśmy w tym celu WebApi – wysyłaliśmy metodą POST zapytanie z liczbą będącą podstawą wyliczeń, a następnie za pomocą metody GET pobieraliśmy wynik obliczeń. Sam algorytm nie był skomplikowany, ale… napisanie od zera logiki i konfiguracji 3 projektów było bardzo pracochłonne. Każda linijka miała bardzo duże znaczenie. Wydaje mi się, że jeśli autorzy utworzyliby wcześniej repozytorium z gotowymi kolejnymi krokami, przez które przechodziliśmy, to byłoby to lepsze rozwiązanie. Mianowicie można by mieć pobrane repo oryginalne i w razie niepowodzenia naszego kodu w dowolnym momencie dojść do właściwego wyniku danego etapu. Prelegenci pisali kod na bieżąco i wrzucali zmiany co jakiś czas (również na slacka) – było więc jednak pewne opóźnienie w dostawie aktualnego kodu. Korzystając z gotowego repozytorium wszyscy mogliby się skupić bardziej na sensie poszczególnych linijek kodu, a nie na samym klepaniu kodu i poprawiania miliona literówek (tak jak w moim przypadku, ale nie tylko). Dzięki temu osoby zainteresowane (np. ja) zdążyłyby zrobić notatki na temat np. właściwej konfiguracji RabbitMQ. Wg mnie zbyt dużo czasu i energii marnowałam na pisanie i ewentualne poprawianie kodu zamiast na zrozumieniu jego sensu.

 CZĘŚĆ – „Zbudowanie własnego obrazu za pomocą Dockera, a następnie wykorzystanie narzędzia docker-compose”

Przejście do części DevOps podgrzało atmosferę. Okazało się, że co rusz coś nie działało – a to na Windowsie, a to na Linuksie… Prelegenci krążyli więc po sali pomagając wszystkim potrzebującym. Koniec końców większości osób chyba udało się zakończyć z sukcesem ten etap – czyli uruchomienie aplikacji na Dockerze. Mi się niestety nie udało, pomimo wielu prób i pomocy prowadzących. O dziwo, nawet pobranie prawidłowego repozytorium autorów nie poprawiło u mnie sytuacji. No ale trudno, to był tylko ostatni element tego etapu. Wiedziałam, jak do niego dojść i to chyba było najważniejsze.

 CZĘŚĆ – „Wykorzystanie Docker Hub oraz Travis CI w celu wdrożenia aplikacji na maszynę wirtualną”

W tej części mogliśmy założyć konto na DockerHub (który zawiera sporą liczbę gotowych już obrazów Dockerowych) i wrzucić nasze aplikacje na udostępnione przez sponsora maszyny wirtualne. Natomiast Travis CI pozwala na automatyczny deploy po przejściu builda.

 CZĘŚĆ – „Konfiguracja Rancher do zarządzania infrastrukturą kontenerów”

Na koniec Piotr pokazał pokrótce, jak łatwo używać DigitalOcean do korzystania z gotowych maszyn wirtualnych w chmurze obliczeniowej i  Rancher do zarządzania kontenerami.

Gdyby ktoś był zainteresowany, to wersja ostateczna projektu jest dostępna na GitHub Piotra. Dodatkowo część związaną z Dockerem Piotr opisuje również u siebie na blogu.

Pomimo niezbyt łatwej tematyki warsztatów i braku 100% sukcesu mojej aplikacji, uważam, że bardzo dużo się na nich nauczyłam. Brawa dla Piotra i Łukasza za chęć organizacji takich warsztatów oraz oczywiście podziękowania dla sponsora PGS Software.