Aanbevolen procedures voor Azure-app Service
In dit artikel vindt u een overzicht van de aanbevolen procedures voor het gebruik van Azure-app Service.
Colocatie
Een Azure-app Service-oplossing bestaat uit een web-app en een database- of opslagaccount voor het opslaan van inhoud of gegevens. Wanneer deze resources zich in verschillende regio's bevinden, kan de situatie de volgende gevolgen hebben:
- Verhoogde latentie in communicatie tussen resources
- Financiële kosten voor uitgaande gegevensoverdracht tussen regio's, zoals vermeld op de pagina met Prijzen van Azure
Colocatie is het beste voor Azure-resources die een oplossing vormen. Wanneer u resources maakt, moet u ervoor zorgen dat ze zich in dezelfde Azure-regio bevinden, tenzij u specifieke zakelijke of ontwerpredenen hebt om ze niet te hebben. U kunt een App Service-app verplaatsen naar dezelfde regio als uw database met behulp van de App Service-kloonfunctie die beschikbaar is in Premium App Service-abonnementen.
Certificaat vastmaken
Het vastmaken van certificaten is een praktijk waarbij een toepassing alleen een specifieke lijst met acceptabele certificeringsinstanties (CA's), openbare sleutels, vingerafdrukken of een deel van de certificaathiërarchie toestaat.
Toepassingen mogen nooit een vaste afhankelijkheid hebben of vastmaken aan het STANDAARD-TLS-certificaat (*.azurewebsites.netjokerteken). App Service is een PaaS (Platform as a Service), zodat dit certificaat op elk gewenst moment kan worden gedraaid. Als de service het standaard-TLS-certificaat met jokertekens roteert, wordt de connectiviteit voor toepassingen die zijn vastgelegd in een specifieke set certificaatkenmerken verbroken en onderbroken. De periodieke frequentie waarmee het certificaat wordt gedraaid, wordt ook niet gegarandeerd omdat de rotatiefrequentie op elk gewenst moment kan worden gewijzigd.
Toepassingen die afhankelijk zijn van het vastmaken van certificaten, mogen ook geen vaste afhankelijkheid hebben van een door App Service beheerd certificaat. Beheerde App Service-certificaten kunnen op elk gewenst moment worden geroteerd, wat leidt tot vergelijkbare problemen voor toepassingen die afhankelijk zijn van stabiele certificaateigenschappen. Het is een best practice om een aangepast TLS-certificaat te bieden voor toepassingen die afhankelijk zijn van het vastmaken van certificaten.
Als uw toepassing moet vertrouwen op gedrag voor het vastmaken van certificaten, raden we u aan een aangepast domein toe te voegen aan een web-app en een aangepast TLS-certificaat voor het domein op te geven. De toepassing kan vervolgens afhankelijk zijn van het aangepaste TLS-certificaat voor het vastmaken van certificaten.
Geheugenbronnen
Wanneer bewakings- of serviceaanbevelingen aangeven dat een app meer geheugen verbruikt dan verwacht, kunt u de functie voor automatisch herstel van App Service overwegen. U kunt automatisch herstellen configureren met behulp van web.config.
Een van de opties voor de functie voor automatisch herstellen is het uitvoeren van aangepaste acties op basis van een geheugendrempel. Acties variëren van e-mailmeldingen tot onderzoek via geheugendump tot on-the-spot risicobeperking door het werkproces te recyclen.
CPU-resources
Wanneer u aanbevelingen voor bewaking of service bekijkt, geeft u aan dat een app meer CPU verbruikt dan u had verwacht of als er herhaalde CPU-pieken optreden, kunt u overwegen om het App Service-plan omhoog of uit te schalen. Als uw toepassing stateful is, is omhoog schalen de enige optie. Als uw toepassing staatloos is, biedt uitschalen u meer flexibiliteit en een hoger schaalpotentieel.
Socket-resources
Een veelvoorkomende reden voor het uitputten van uitgaande TCP-verbindingen is het gebruik van clientbibliotheken die TCP-verbindingen niet hergebruiken of die geen protocol op een hoger niveau gebruiken, zoals HTTP-keep-alive.
Raadpleeg de documentatie voor elke bibliotheek waarnaar de apps in uw App Service-plan verwijzen. Zorg ervoor dat de bibliotheken zijn geconfigureerd of geopend in uw code voor efficiënt hergebruik van uitgaande verbindingen. Volg ook de richtlijnen voor bibliotheekdocumentatie voor het maken en vrijgeven of opschonen om te voorkomen dat verbindingen worden gelekt. Hoewel dergelijke onderzoeken naar clientbibliotheken worden uitgevoerd, kunt u de impact beperken door uit te schalen naar meerdere exemplaren.
Node.js en uitgaande HTTP-aanvragen
Wanneer u met Node.js en veel uitgaande HTTP-aanvragen werkt, is het belangrijk om http-keep-alive te verwerken. U kunt het agentkeepalive-pakketnpm gebruiken om het eenvoudiger te maken in uw code.
Verhandel altijd het http antwoord, zelfs als u niets in de handler doet. Als u het antwoord niet goed verwerkt, loopt uw toepassing uiteindelijk vast omdat er geen sockets meer beschikbaar zijn.
Hier volgt een voorbeeld van het verwerken van het antwoord wanneer u met het http of https pakket werkt:
const request = https.request(options, function(response) {
response.on('data', function() { /* do nothing */ });
});
Als u uw App Service-app uitvoert op een Linux-computer met meerdere kernen, kunt u PM2 het beste gebruiken om meerdere Node.js-processen te starten om uw toepassing uit te voeren. U kunt dit doen door een opstartopdracht op te geven aan uw container.
Gebruik deze opdracht bijvoorbeeld om vier exemplaren te starten:
pm2 start /home/site/wwwroot/app.js --no-daemon -i 4
Back-up van app
Back-ups worden doorgaans volgens een schema uitgevoerd en vereisen toegang tot opslag (voor het uitvoeren van de back-upbestanden) en databases (voor het kopiëren en lezen van inhoud die in de back-up moet worden opgenomen). Het resultaat van het mislukken van toegang tot een van deze resources is een consistente back-upfout.
De twee meest voorkomende redenen waarom het maken van back-ups van apps mislukt, zijn ongeldige opslaginstellingen en ongeldige databaseconfiguratie. Deze fouten treden doorgaans op na wijzigingen in opslag- of databasebronnen of na wijzigingen in referenties voor toegang tot deze resources. Referenties kunnen bijvoorbeeld worden bijgewerkt voor de database die u hebt geselecteerd in de back-upinstellingen.
Wanneer er back-upfouten optreden, bekijkt u de meest recente resultaten om te begrijpen welk type fout zich voordoet. Controleer en werk de opslaginstellingen in uw back-upconfiguratie bij voor fouten met toegang tot opslag. Controleer en werk uw verbindingsreeks s bij als onderdeel van app-instellingen voor databasetoegang. Ga vervolgens verder met het bijwerken van uw back-upconfiguratie om de vereiste databases correct op te nemen.
Zie Back-ups van uw app maken en herstellen in Azure-app Service voor meer informatie over app-back-ups.
Node.js-apps
De Azure-app Service-standaardconfiguratie voor Node.js-apps is bedoeld om het beste te voldoen aan de behoeften van de meest voorkomende apps. Als u de standaardconfiguratie voor uw Node.js-app wilt aanpassen om de prestaties te verbeteren of het resourcegebruik voor CPU-, geheugen- of netwerkresources te optimaliseren, raadpleegt u de aanbevolen procedures en gids voor probleemoplossing voor Node-toepassingen in Azure-app Service. In dit artikel worden de iisnode-instellingen beschreven die u mogelijk moet configureren voor uw Node.js-app. Ook wordt uitgelegd hoe u scenario's of problemen met uw app kunt oplossen.
IoT-apparaten
U kunt uw omgeving verbeteren wanneer u IoT-apparaten (Internet of Things) uitvoert die zijn verbonden met App Service.
Een veelvoorkomende procedure voor IoT-apparaten is het vastmaken van certificaten. Als u onvoorziene downtime wilt voorkomen vanwege wijzigingen in de beheerde certificaten van de service, moet u nooit certificaten vastmaken aan het standaardcertificaat *.azurewebsites.net of aan een door App Service beheerd certificaat. Als uw systeem afhankelijk moet zijn van gedrag voor het vastmaken van certificaten, raden we u aan een aangepast domein toe te voegen aan een web-app en een aangepast TLS-certificaat voor het domein op te geven. De toepassing kan vervolgens afhankelijk zijn van het aangepaste TLS-certificaat voor het vastmaken van certificaten. Zie de sectie certificaatpinning van dit artikel voor meer informatie.
Als u de tolerantie in uw omgeving wilt vergroten, vertrouwt u niet op één eindpunt voor al uw apparaten. Host uw web-apps in ten minste twee regio's om een single point of failure te voorkomen en gereed te zijn om een failover van verkeer uit te geven.
In App Service kunt u identieke aangepaste domeinen toevoegen aan meerdere web-apps, zolang deze web-apps in verschillende regio's worden gehost. Deze mogelijkheid zorgt ervoor dat als u certificaten wilt vastmaken, u ook kunt vastmaken aan het aangepaste TLS-certificaat dat u hebt opgegeven.
Een andere optie is om een load balancer te gebruiken voor de web-apps, zoals Azure Front Door of Azure Traffic Manager, om hoge beschikbaarheid voor uw web-apps te garanderen. Zie quickstart: Een Front Door-exemplaar maken voor een maximaal beschikbare globale webtoepassing of het beheren van Azure-app Service-verkeer met Azure Traffic Manager voor meer informatie.
Volgende stappen
Als u praktische aanbevolen procedures wilt krijgen die specifiek zijn voor uw resource, gebruikt u Diagnostische gegevens van App Service:
- Ga naar uw web-app in Azure Portal.
- Open App Service Diagnostische gegevens door Diagnose te selecteren en problemen op te lossen in het linkerdeelvenster.
- Selecteer de tegel Aanbevolen procedures .
- Selecteer Aanbevolen procedures voor beschikbaarheid en prestaties of aanbevolen procedures voor optimale configuratie om de huidige status van uw app te bekijken met betrekking tot deze aanbevolen procedures.
U kunt deze koppeling ook gebruiken om app Service-diagnostische gegevens rechtstreeks te openen voor uw resource: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.