HomeBlogTexas Ranger

Previous arcticle: TypeScript 4 Ever(ywhere)

Recap

In our previous article, we create a TS backend app along with an NPM module called mrutils. The article was based on the idea to keep our ALM as simple as possible: We develop our backend app and our NPM module(s) in parallel but don't want to hassle with constantly packaging and uploading our module to an NPM registry, neither private/local nor public. Therefore we used npm link to create a symbolic link from our app to the package (or the other way round, however you might look at it). In other words: Our backend app contains a linked folder called mrutils underneath node_modules. That's great for development. As soon as we change code in the module, it is reflected in our app. But: How do we deploy all assets to azure?

The whole idea in a nutshell

The simple plan is:

  • Create an azure web app
  • Create a "git deployment" in the azure app's deployment center
  • Clone the git repo to your local dev-environment
  • Compile the app and the module (in our case mrutils)
  • Package the module
  • Copy the compiled JS-files and the module to the git-repo we cloned in previous step
  • git add, commit and push
  • azure build tools (called Kudu) will recognize the node.js app, install all dependencies (npm install) and launch the app

Create an azure web app and choose git deployment

Straight forward: Create a web-app in the azure portal. "Create web-app"

"Create web-app"

Next we define our preferred deployment mechanism, which is, in our case, "local git". "Deploy through local git" What does "local" mean? It means that the git repo is local to the virtual machine on azure. As we will see later, azure "really" creates a VM for every web app. We can connect to this VM through Kudu, open a kind of CMD etc. And the "local" git repo will be located on this VM.

Then we choose Kudu as our build system. As you can see in the picture, the other option is "azure pipelines", but we just want to deploy the app without any pipelines at the moment. "Choose kudu"

On finshsing this wizard, we get to the git clone url. "git clone url"

Then clone the git repo to your local dev environment:

git clone https://testnodejsazure.scm.azurewebsites.net:443/testnodejsazure.git

The clone operation will create a directory testnodejsazure.

Compile and pack all dependend modules

Our previous blog covered TypeScript-nodejs-modules: How to define them and how to use them efficiently without any need for a n NPM registry (during dev-time). That's fine from a development perspective, but now we need to transfer our app to azure along with the modules it depends on.

That's what we are gonna do:

  • Pack (npm pack) all of our "homegrown" dependencies, eg. mrutils. In case we change any code of these modules, remember to increase the version number in the module's package.json. This ensures that azure's npm install recognizes a new version of the module. If you didn't increase the version number, npm install would - apart from the first installation - do nothing with the package.

  • Copy the packaged modules to the git-repo/directory we have cloned before: testnodejsazure

  • Copy the transpiled JS-files and (optionally) the map-files to the same directory.

  • Change into this directory and call the three commands git add *, git commit -m "my commit message", git push

  • The git push operation will trigger a deployment to our new web-app. The remote log output will be reflected in our local console, so we can follow what happens. "Deployment Flow"

  • The deploy.cmd will be run and installs our node app: "Deployment Command"

But I need to control my deployment a 100%!

So far everything was straight forward: We deployed our "homegrown" app and modules and let azure Kudu and npm install do the rest. We did not deploy any of the many other modules our app depends on (i.e. those under node_modules). Well, that makes sense: Our pacakge.json describes our app and packages and we don't want to transfer megabytes of node_modules from our local environment to azure.
But: What happens if azure's npm install installs a slightly different version or a very bad man in the middle interferes with the download somehow and injects trojan code into the downloaded modules?
That's what package-lock.jsonis for: It pins down the exact version along with a digital signature for the package. So we can be 100% sure to get exactly the same packages/code/versions as we had in our environment.

Outlook: Operations

In part three we will see how to operate/manage a nodejs app on azure and how to handle nodejs native modules through the infamous node-gyp.

Mext arcticle: TypeScript 4 Ever(ywhere) - Operate on azure