Azure App Service reuse Node.js modules on host for speed

Published on July 10, 2020
#devops#azure#nodejs
Follow me on twitter

If you are deploying a Node.js app to Azure App Services you can deploy the node_modules folder as part of the deploy, or you can reinstall the runtime Node.js modules on the host each time. There are some advantages and disadvantages to taking either option.

The scenario

If you have a Node.js app that builds in Azure DevOps Pipelines and you are deploying to Azure App Services you can ship the node_modules in the zip deploy, or install the node_modules on the host.

If you ship the Node.js modules then your build artefact is much larger and you have to make sure that the OS and the Node.js version is the same on both the build agent and the App Service host.

If you chose to install the packages on the host you have to ensure that the rebuild doesn’t take so long that the deploy fails from an npm install timeout.

Installing packages on the host

If you try to install the NPM packages on App Services each time it takes a long time. The data transfer speed seems to be quite slow. It even fails some of the time for large installs. You can see a way around the NPM timeout failures described here.

You can also setup azure app service to not delete the node_modules folder for each deploy. Now you need to be careful here because setting this option means all existing files will be kept. You might not want this depending on your app. And it is likely not suitable for you production environment.

The key is the RemoveAdditonalFiles: false option. This keeps the files that are already on the server. Including node_modules around! This will speed up your deploy by 5 to 10 minutes.

- task: AzureRmWebAppDeployment@4
    inputs:
      ConnectionType: 'AzureRM'
      azureSubscription: '$(azureSubscription)'
      appType: 'webAppLinux'
      WebAppName: '$(appName)'
      packageForLinux: '$(System.ArtifactsDirectory)/artefactDrop/$(Build.BuildId).zip'
      RuntimeStack: 'NODE|10.16'
      RemoveAdditionalFiles: false
      StartupCommand: 'cd server && node dist/index.js'
      ScriptType: 'Inline Script'
      InlineScript: |
        yarn install --production --network-timeout=30000
Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building and supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My Universal DevShell tooling will save you 30+ hours of configuring your Windows or Mac dev environment with all the best, modern shell and dev tools.

Get DevShell here: ✨ https://usemiller.dev/dev-shell ✨


Read more articles like this one...

List of article summaries

#devops

Extract user profile attributes from an Azure ADB2C tenant using the Microsoft Graph API

I had to retrieve a list of users from an Azure Active Directory B2C instance today. I thought I could just go through the Azure UI but that’s limited to short pages of data and limited attributes.

There is a CSV export provided on the UI but you won’t get the required identity objects in the csv output if you need a user’s signin email address.

I had to use the Microsoft Graph Api to get what I needed. This is a bit hacky but it does the trick!

Read More
#devops

Force restart your Azure App service site and host

Sometimes your Azure App service host will need to be restarted. You can do this but it’s hidden away in the Azure resource manager site. Here’s how to find it!

Read More
#devops

Scheduling a feature toggle using no-code with Azure Logic Apps

I use launch darkly to toggle features on an app. There is one third-party dependency that has regular scheduled maintenance and I need to toggle the feature on and off on schedule.

Launch Darkly has built in scheduling to handle this scenario but you have to be on the enterprise plan to use it. The enterprise plan is too expensive to upgrade to for scheduling alone so I needed to find a different way to automate this.

Read More
#frontend-development

Avoid rebuild of React App in every CI stage

If you have a react app you can use env vars like REACT_APP_MY_ENV_VAR in your application and React will automatically pull them in to your app when you build the production application.

This is very useful but if you have variables that change for each environment and your application build takes a long time, you might want to avoid building unnecessarily in CI. For example you might have a QA environment and a Staging environment that have different configuration.

We type-check our code on each build and that was taking 5 minutes+ to build each environment so we had to make it faster. We changed our app from using REACT_APP env vars to using a configuration file that we could quickly write to using CI.

Our CI system is Azure DevOops so the CI scripts here are specifically for Azure DevOps but they apply to most CI systems with small changes.

The real work happens in a Node.js script that would work anywhere.

Read More

Comments