-
Rekomendowany: Linux (Ubuntu) / MacOS
-
Zainstalowane:
- azure-cli (instalacje)
- azure functions core tools (instalacja)
- httpie albo curl
- AWS SAM (instalacja)
- serverless - poniżej instrukcja
- terraform (opcjonalnie)
Trochę powtórki z ostatnich zajęć, jak logujemy się za pomocą kluczy ssh.
-
Utwórz swój klucz ssh:
ssh-keygen -f ~/.ssh/wsb_id_rsa -t rsa -b 4092 ls ~/.ssh
-
Utwórz maszynę wirtualną dodając nasz klucz ssh (patrz ostatnie ćwiczenia 01_exercise):
az vm create \ --resource-group <nazwa-grupy-zasobów> \ --name <nazwa-maszyny> \ --size "Standard_B1ls" \ --image "Canonical:0001-com-ubuntu-server-focal:20_04-lts-gen2:latest" \ --public-ip-sku Standard \ --admin-username ubuntu \ --ssh-key-value ~/.ssh/wsb_id_rsa.pub
-
zaloguj się z uzyciem klucza ssh:
ssh ubuntu@<IP_ADDRESS> # jak debugować? ssh ubuntu@<IP_ADDRESS> -vvv # a teraz ze wskazaniem klucza, # który chcemy uzyc ssh ubuntu@<IP_ADDRESS> -i ~/.ssh/wsb_id_rsa
-
A co gdy mamy sporo maszyn i chcemy w różny sposób się do nich logujemy, tutaj z pomocą przychodzi nam
~/.ssh/config
:# code atom ~/.ssh/config
Host <IP_ADDRESS> IdentityFile ~/.ssh/wsb_id_rsa
-
Jeszcze jedno, jak to mawiał... ssh agent. Zamiast specyfikować klucz lub wybierać konfigurację, możemy dodać klucz do agenda ssh:
eval "$(ssh-agent -s)" ssh-add ~/.ssh/wsb_id_rsa ssh-add -L # teraz możemy się spokojnie zalogować ssh ubuntu@<IP_ADDRESS>
-
Co jeśli chcemy mieć dostęp z lokalnej maszyny do usługi na VM? Z pomocą przychodzi
ssh -L
, aka ssh tunneling. -
Zainstaluj
nginx
na VM, sprawdź czy lokalnie na VM działa za pomocącurl
. -
Teraz udostępnijmy serwis działający na porcie 80 (VM) na lokalnym porcie 8080:
ssh -L 8080:127.0.0.1:80 ubuntu@<IP_ADDRESS>
# sprawdzmy na naszym # komputerze curl 127.0.0.1:8080
-
Dostarczyciele chmury oferują lepszą alternatywę do logowania się, na przykład dla AWS, AWS EC2 Instance Connect lub, zdecydowanie bardziej bezpieczny, AWS SSM.
-
Usuń maszynę wirtualną z której korzystaliśmy w tym ćwiczeniu.
Upewnij się czy masz zainstalowane Azure Function Core CLI:
func --version
Ćwiczenie na podstawie Your first Function in Py:
-
Jak to na każdego dobrego dewelopera Python, zaczynamy od wirtualnego środowiska:
python3 -m venv .venv source .venv/bin/activate
-
Utwórz twój pierwszy projekt:
func init YourProjectName --python # na przyklad func init WsbHelloWorld --python
-
Zapoznaj się z plikami:
ls # atom code YourProjectName
-
Utwórz pierwszy HTTP handler:
cd YourProjectName func new --name HttpHelloMsg --template "HTTP trigger" --authlevel "anonymous" # powinienes zobaczyc nowy folder: ls ... HttpHelloMsg ...
-
Lokalne testowanie:
func start # w osobnym oknie: curl 'http://localhost:7071/api/HttpHelloMsg?name=Natalia'
-
Zmodyfikuj zwracaną wiadomość i przetestuj, że działa.
-
Login:
# lub po prostu az login az login --use-device-code # dosc pomocne az config param-persist on
-
Czas utworzyć zasoby:
export AZ_RESOURCE_GROUP=<YOUR GROUP NAME FOR FUNCTION> az group create \ --name ${AZ_RESOURCE_GROUP} \ --location eastus # potrzebny dla umieszczenia naszego kodu # zauwaz STORAGE_NAME musi być unikalną globalnie nazwą export AZ_STORAGE_ACCOUNT=<storage name for function> az storage account create \ --name ${AZ_STORAGE_ACCOUNT} \ --sku Standard_LRS \ --location eastus \ --resource-group ${AZ_RESOURCE_GROUP} # zauwaz: APP_NAME musi być globalnie unikalną nazwą export AZ_FUNC_APP_NAME=<YOUR APP NAME> az functionapp create \ --consumption-plan-location eastus \ --runtime python \ --runtime-version 3.8 \ --functions-version 3 \ --os-type linux \ --resource-group ${AZ_RESOURCE_GROUP} \ --storage-account ${AZ_STORAGE_ACCOUNT} \ --name ${AZ_FUNC_APP_NAME}
Więcej o Consumption Plans w dokumentacji Azure.
-
Szybkie spojrzenie do portalu, przejdź do zakładki
Function App
.
Zauważ, mógłbyś utworzyć powyższe zasoby posługując się terraformem.
Teraz czas, aby naszą funkcję opublikować:
func azure functionapp publish ${AZ_FUNC_APP_NAME}
i smoke test:
# jesli nie `httpie` to `curl` oczywiscie
http <INVOKE URL>
Możesz teraz usunąć aplikację:
az functionapp delete --name ${AZ_FUNC_APP_NAME}
az functionapp list
Jak wszystko działa to czas, wykasować:
az group delete --resource-group ${AZ_RESOURCE_GROUP}
Najpopularniejszym frameworkiem/narzędziem pracy z serverless jest serverless. Inspiracją dla ćwiczenia jest oficjalny quickstart dla Azure.
-
Zainstaluj:
- upewnij się, że masz node zainstalowany, w wersji wspieranej przez Azure-a (dokumentacja),
- jeśli nie, zainstaluj node za pomocą nvm,
- serverless według instrukcji.
-
Przejdź do katalogu w których chcesz utworzyć projekt.
-
Utwórz projekt:
# wybierz swoją nazwę sls create -t azure-nodejs -p WsbHelloWorld npm install
-
Lokalnie:
sls offline
-
dry-run
, we like:sls deploy --dryrun # arn? sls deploy --dryrun --arn
-
Deployment:
sls deploy sls info
-
Przetestuj czy możesz się połączyć za pomocą
curl
albohttp
. -
Zapoznaj się jak możemy wywoływać naszą funkcję z użyciem
sls invoke
isls invoke local
korzystając z tutoriala. -
Wykasuj nasz serwis:
sls remove
Zauważ, serverless ma wsparcia dla stage-ów. Przykłady znajdziesz na githubie.
Na AWSie publikujemy naszą aplikację zazwyczaj za AWS API Gateway, jeśli chodzi o obsługę ruchu http:
-------- --------
User -> | API | -> | AWS |
| Gateway | | Lambda |
--------- --------
- Z Serverless:
# zobaczmy jakie mamy opcje
serverless create -t aws
#
serverless create -t aws-nodejs --path HelloWorldAWS
cd HelloWorldAWS
# tradycyjnie, najpierw sprawdzamy czy wszystko dziala
sls invoke local -f hello
sls invoke local -f hello -d '{"name": "wojtek"}'
- Z AWS SAM, pierwszy krok to oczywiście instalacja narzędzia:
# wygenerujmy przykladowy serwis
# wybierajac domyslne wartosci
sam init
# wywolanie lokalne lambdy (1)
cd FOLDER_Z_TWOJA_APP
sam local start-api
curl http://127.0.0.1:3000/hello
# wywolanie lokalnie lambdy (2)
sam local invoke -e events/event.json
# zauwaz, ze mozesz wygenerowac rozne eventy
# dla testowania lambdy, ktora reaguje na eventy
# z roznych serwisow AWSa
sam local generate-event apigateway authorizer
Ćwiczenie zainspirowane quickstart for Python.
-
Przejdź do py_hello_world. Znajdziesz tutaj prostą aplikację flask.
-
Uruchom ją według poleceń w pliku README.md.
-
Utwórz dedykowaną grupę, a następnie uruchom naszą bardzo złożoną aplikację w chmurze:
export AZ_RESOURCE_GROUP=<NAZWA DLA TWOJEJ GRUPY> # tu tworzenie twojej resource group # deploy aplikacji az webapp up --sku B1 \ --plan eastus \ --resource-group ${AZ_RESOURCE_GROUP} \ --name <app-name> az webapp list -o table
-
Przejdźmy do portalu, znajdźmy naszą aplikację (w App Services).
-
Testujemy, jak coś nie działa, sprawdź kod http odpowiedzi. Możesz również sprawdzić logi (komendę znajdziesz w dokumentacji Azure).
-
Zmień output serwisu, zrób deployment i przetestuj.
-
... i kasujemy:
az group delete --resource-group ${AZ_RESOURCE_GROUP}
Zobaczmy jak wygląda deployment na Heroku, jeden z pierwszej platformie PaaS, która odniosła komercyjny sukces (obecnie część Salesforce). To inżynierowi z Heroku spisali 12factor apps.
-
Załóż konto na heroku.com
-
Będziemy robić deployment prostej aplikacji w Pythonie, którą znajdziesz py_hello_world, uruchom ją według wskazówek w pliku py_hello_world/README.md.
-
Przekopiuj aplikację i zainicjuj repozytorium gita.
-
Dodaj plik Procfile, służy on do przekazania informacji Heroku, jak uruchomić twoją aplikację:
web: gunicorn hello:app
-
Zainstaluj Heroku CLI, korzystając z instrukcji na stronie devcenter.heroku.com/articles/heroku-cli
-
Umieśćmy aplikację na platformie Heroku:
heroku login -i # create the app at the heroku side heroku create # aplikacja pojawi się w heroku dashboard # (przeglądarka internetowa) # heroku działa używając git-a: git remote -v # sprawdź czy wszystko jest dodane do gita: git status # deploy git push heroku master # w logach zobaczysz url swojej aplikacji heroku logs
- Cloudflare workers i Cloudflare Pages - warto poznać
- AWS CloudFront Lambda@Edge
- AWS serverless getting-started
- https://www.netlify.com/ - również bardzo popularna platforma PaaS
- Azure Functions Triggers
- https://ngrok.com/