Distribuera en Node.js + MongoDB-webbapp till Azure

Azure App Service tillhandahåller en mycket skalbar, självkorrigeringsbaserad webbvärdtjänst med hjälp av Linux-operativsystemet. Den här självstudien visar hur du skapar en säker Node.js app i Azure App Service som är ansluten till en Azure Cosmos DB for MongoDB-databas. När du är klar har du en Express.js-app som körs på Azure App Service i Linux.

Den här artikeln förutsätter att du redan är bekant med Node.js utveckling och har Node och MongoDB installerade lokalt. Du behöver också ett Azure-konto med en aktiv prenumeration. Om du inte har något Azure-konto kan du skapa ett kostnadsfritt.

Exempelprogram

Om du vill följa med i den här självstudien klonar eller laddar du ned exempelprogrammet från lagringsplatsen https://github.com/Azure-Samples/msdocs-nodejs-mongodb-azure-sample-app.

git clone https://github.com/Azure-Samples/msdocs-nodejs-mongodb-azure-sample-app.git

Om du vill köra programmet lokalt gör du följande:

• Installera paketberoendena genom att köra npm install.
• .env.sample Kopiera filen till .env och fyll i värdet för DATABASE_URL med din MongoDB-URL (till exempel mongodb://localhost:27017/).
• Starta programmet med .npm start
• Om du vill visa appen bläddrar du till http://localhost:3000.

1. Skapa App Service och Azure Cosmos DB

I det här steget skapar du Azure-resurserna. Stegen som används i den här självstudien skapar en uppsättning säkra som standardresurser som omfattar App Service och Azure Cosmos DB för MongoDB. För skapandeprocessen anger du:

• Namnet på webbappen. Det är namnet som används som en del av DNS-namnet för din webbapp i form av https://<app-name>.azurewebsites.net.
• Regionen som ska köra appen fysiskt i världen.
• Körningsstacken för appen. Det är där du väljer vilken version av Node som ska användas för din app.
• Appens värdplan. Det är prisnivån som innehåller en uppsättning funktioner och skalningskapacitet för din app.
• Resursgruppen för appen. Med en resursgrupp kan du gruppera (i en logisk container) alla Azure-resurser som behövs för programmet.

Logga in på Azure Portal och följ dessa steg för att skapa dina Azure App Service resurser.

2. Konfigurera databasanslutning

Skapandeguiden genererade redan MongoDB-URI:n åt dig, men din app behöver en DATABASE_URL variabel och en DATABASE_NAME variabel. I det här steget skapar du appinställningar med det format som din app behöver.

3. Distribuera exempelkod

I det här steget konfigurerar du GitHub-distributionen med hjälp av GitHub Actions. Det är bara ett av många sätt att distribuera till App Service, men också ett bra sätt att ha kontinuerlig integrering i distributionsprocessen. Som standard startar varje git push till din GitHub-lagringsplats bygg- och distributionsåtgärden.

4. Bläddra till appen

5. Strömma diagnostikloggar

Azure App Service samlar in alla meddelanden som loggas i konsolen för att hjälpa dig att diagnostisera problem med ditt program. Exempelappen matar ut konsolloggmeddelanden i var och en av dess slutpunkter för att demonstrera den här funktionen. Slutpunkten matar till exempel get ut ett meddelande om antalet uppgifter som hämtats från databasen och ett felmeddelande visas om något går fel.

router.get('/', function(req, res, next) {
  Task.find()
    .then((tasks) => {      
      const currentTasks = tasks.filter(task => !task.completed);
      const completedTasks = tasks.filter(task => task.completed === true);

      console.log(`Total tasks: ${tasks.length}   Current tasks: ${currentTasks.length}    Completed tasks:  ${completedTasks.length}`)
      res.render('index', { currentTasks: currentTasks, completedTasks: completedTasks });
    })
    .catch((err) => {
      console.log(err);
      res.send('Sorry! Something went wrong.');
    });
});

6. Inspektera distribuerade filer med Kudu

Azure App Service tillhandahåller en webbaserad diagnostikkonsol med namnet Kudu som gör att du kan undersöka servervärdmiljön för din webbapp. Med Kudu kan du visa de filer som distribuerats till Azure, granska programmets distributionshistorik och till och med öppna en SSH-session i värdmiljön.

7. Rensa resurser

När du är klar kan du ta bort alla resurser från din Azure-prenumeration genom att ta bort resursgruppen.

Vanliga frågor och svar

• Hur mycket kostar den här installationen?
• Hur gör jag för att ansluta till Azure Cosmos DB-servern som skyddas bakom det virtuella nätverket med andra verktyg?
• Hur fungerar lokal apputveckling med GitHub Actions?
• Varför är GitHub Actions distributionen så långsam?

Hur mycket kostar den här installationen?

Prissättningen för att skapa resurser är följande:

• Den App Service planen skapas på Basic-nivån och kan skalas upp eller ned. Se App Service prissättning.
• Azure Cosmos DB-servern skapas i en enda region och kan distribueras till andra regioner. Se Priser för Azure Cosmos DB.
• Det virtuella nätverket debiteras inte om du inte konfigurerar extra funktioner, till exempel peering. Se Prissättning för Azure Virtual Network.
• Den privata DNS-zonen medför en liten avgift. Se Priser för Azure DNS.

Hur gör jag för att ansluta till Azure Cosmos DB-servern som skyddas bakom det virtuella nätverket med andra verktyg?

• För grundläggande åtkomst från ett kommandoradsverktyg kan du köra mongosh från appens SSH-terminal. Appens container medföljer mongoshinte , så du måste installera den manuellt. Kom ihåg att den installerade klienten inte bevaras mellan appomstarter.
• Om du vill ansluta från en MongoDB GUI-klient måste datorn finnas i det virtuella nätverket. Det kan till exempel vara en virtuell Azure-dator som är ansluten till ett av undernäten eller en dator i ett lokalt nätverk som har en VPN-anslutning från plats till plats med det virtuella Azure-nätverket .
• Om du vill ansluta från MongoDB-gränssnittet från Azure Cosmos DB-hanteringssidan i portalen måste datorn också finnas i det virtuella nätverket. Du kan i stället öppna Azure Cosmos DB-serverns brandvägg för den lokala datorns IP-adress, men det ökar attackytan för konfigurationen.

Hur fungerar lokal apputveckling med GitHub Actions?

Ta den automatiskt genererade arbetsflödesfilen från App Service som exempel, var git push och en startar en ny version och distributionskörning. Från en lokal klon av GitHub-lagringsplatsen skickar du önskade uppdateringar till GitHub. Exempel:

git add .
git commit -m "<some-message>"
git push origin main

Varför är GitHub Actions distributionen så långsam?

Den automatiskt genererade arbetsflödesfilen från App Service definierar build-then-deploy, two-job run. Eftersom varje jobb körs i en egen ren miljö ser arbetsflödesfilen till att deploy jobbet har åtkomst till filerna från build jobbet:

• I slutet av build jobbet laddar du upp filer som artefakter.
• I början av deploy jobbet laddar du ned artefakterna.

Merparten av tiden som tvåjobbsprocessen tar går åt till att ladda upp och ladda ned artefakter. Om du vill kan du förenkla arbetsflödesfilen genom att kombinera de två jobben till ett, vilket eliminerar behovet av uppladdnings- och nedladdningsstegen.

Nästa steg