Azure Durable Functions, deel 11: App Lifecycle, deel A

We zijn klaar met spelen. Het is tijd voor het echte werk. Tot nu toe hebben we alles lokaal gedaan met de Storage Emulator, maar nu is het tijd om te deployen naar Azure. We gaan de Cloud in! En daar lopen we ook tegen een paar dingen aan:

1. Beheer
2. Monitoring
3. Versioning bij veranderingen (deel B)
4. Security (deel B)

We zullen ze allemaal bekijken!

Deployment

Vanuit Visual Studio is het deployen van je Function App een fluitje van een cent. Je moet wel een Azure subscription hebben (een trial is gratis…). Verder raad ik je aan om alvast een Resource Group aan te maken in de portal. Dan heb je die maar vast.

Deployen gaat zoals altijd gewoon vanuit Visual Studio met de rechter button op het project en dan Publish. Uiteraard kan dit beter, maar we zullen naar CI / CD kijken als het moment daar is. Ik raad sowieso aan om eerst een handmatige deployment te doen.

In VS kunnen we dus Publish kiezen. Dan krijg je deze dialog:

Je hebt verschillende soorten van deployment. Ik raad in dit geval aan om Azure Functions Consumption plan te kiezen. Premium is sneller maar je betaalt een heel stuk meer. Bij Consumption betaal je naar gebruik. Dus als je workflow wacht op de beheerders tot ze eindelijk een keer die link in de email openen, betaal je niets. We blijven Hollanders, niet waar?

Klik op Create Profile.

Ik heb even wat waardes aangepast (naam van de service, location en zo) maar echt spannend is dit allemaal niet.

Click Create. Dit zorgt er niet voor de deployment plaats vindt, maar dat er een profile aangemaakt wordt waar vanuit je kunt gaan deployen. Er is dus nog niets naar Azure toe.

Laten we dat eens veranderen.

Dit scherm verschijnt. Nu kunnen we gaan deployen maar ik raad je aan om eerst op de link voor “Edit Azure App Service settings” te klikken:

Je kunt dit namelijk ook prima achteraf in de Azure Portal doen, maar nu krijg je ook te zien hoe je development settings waren.

Je ziet de settings voor de Usergroups en die voor SendGridAPIKey. Die kun je gewoon kopiëren. De AzureWebJobsStorage is lokaal ingesteld op de emulator, maar remote staat hij ergens anders op (je ziet maar een klein stukje van mijn AccountKey, dus die hoef ik niet zwart te maken). De rest laten we lekker zoals het is.

Klik OK. Klik Publish. Haal koffie…

Het duurt even maar op een gegeven moment is hij wel klaar. Onderin je output window staat iets als Publish: 1 succeeded.

Het wordt tijd om de Portal te bekijken. Ga naar de https://portal.azure.com, vind je Resource Group en kijk wat er allemaal gebeurt is. Bij mij ziet er nu zo uit:

Er zijn 3 resources aangemaakt.

1. meetingregistration: een Storage Account. Deze bevat de queues, TableStorage en meer. Die had ik al handmatig aangemaakt dus deze telt niet
2. MeetingRegistrationAppService: de App Service die de binaries bevat.
3. WestEuropePlan. Mijn App Service plan . Niet zo spannend.

Klik op de App Service om te kijken wat we daar hebben:

Als het goed is, zie je nu waarom ik met de O_ en A_ prefix werk. Zelfs in deze hele kleine flow hebben we al best wat functies. We hebben twee publieke functies (de starter en de cleanup), we hebben 3 orchestrators en we hebben 5 activities.

Kies de starter functie StartRegistration. In het detail window zie je nu </> Get Function URL.. Open die en kopieer de inhoud.

Deze URL kun je nu pasten in de browser. Vervang de standaard dummy waardes {name}, {email} en {wantsTweet} door echte waardes (om te testen geef ik hem even een ongeldige email zodat we niet door de hele flow heen hoeven).

Als ik dan op de statusQueryGetUri klik, krijg ik dit:

// 20191104161833
// https://meetingregistrationappservice.azurewebsites.net/runtime/webhooks/durabletask/instances/287094e6d11e48f8b7b73904c6ea206a?taskHub=DurableFunctionsHub&connection=Storage&code=4CtGP4ZKJJZYQ85RyhZ1PrILDm6zG3quHWOe9pkVtrOq26eCroxNsw==

{
  "name": "O_PerformRegistration",
  "instanceId": "287094e6d11e48f8b7b73904c6ea206a",
  "runtimeStatus": "Completed",
  "input": {
    "$type": "MeetingRegistration.Attendee, MeetingRegistration",
    "Name": "Dennis",
    "Email": "dennisatvroegop.org",
    "WantsTweet": true
  },
  "customStatus": null,
  "output": {
    "IsSucces": false,
    "Reason": "Not a valid email given."
  },
  "createdTime": "2019-11-04T15:18:29Z",
  "lastUpdatedTime": "2019-11-04T15:18:30Z"
}

Alles is goed gegaan. Nou ja, technisch dan. Het email adres was niet geldig, dus die rejecten we. Als je dit nu helemaal gaat uitvoeren, dus met geldig email adres, let er dan even op dat we in onze code hard-coded HTTP gebruiken in de link in de email. Dat moet hier uiteraard HTTPS zijn….

Monitoring

Als je wilt weten hoe het met je functies gaat, is Application Insights de beste methode. Om dat te doen, moet je in je Resource Group een AppInsights instance aanmaken:

Als de App Insights resource gemaakt is, kun je er naar toe navigeren. In het menu links kun je dan kiezen voor API Access.

Hier kun je dan een key genereren. Kies alle opties, voor nu is dat prima. Je krijgt dan een key die je moet kopieren en plaatsen bij de App Service. Dat gaat heel eenvoudig: navigeer naar je App Service en zie bovenin staan “Application Insights is not fconfigured”

Klik daarop en volg de wizard. Het enige wat dit doet, is in je settings van je app service een key toevoegen met de naam APPINSIGHTS_INSTRUMENTATIONKEY met de key die we net hadden aangemaakt erin.

Draai je workflow nog een keer, en ga dan naar die App Insights. Dit keer draai ik hem helemaal.

Dit is de map. Ik heb 1 instance, die doet 5 calls naar de Azure Table en 1 call naar de Queue. En oh ja, iets naar API.SendGrid.com

Als ik naar de Overview ga, zie ik 5 errors:

Dat klopt natuurlijk: dat zijn de exceptions van onze ‘twitter-client’.

Ik kan daarop helemaal inzoomen:

Je ziet: met Application Insights kun je enorm veel informatie verzamelen op een hele makkelijke manier.

En verder?

Ik had je nog een stukje beloofd over versioning en security maar dat doen we in de volgende post wel.

Succes!