Azure App Service suddenly stopped with PhantomJS error - node.js

We have a Restify API running in Azure App Service on Linux for a while now. Suddenly this app (both test and prod, they run as seperate apps) stopped working. Based on the logs the error is related to a package we are using node-highcharts-exporting which is dependent on PhantomJS. App Service is using Node 8.1.
We tried re-deploying the code, upgrading node version to 8.12 (do not want to use latest version with out testing) but still no luck.
Deployment Logs: (This part is successful. This is just for reference)
Container logs: (Startup fails here)
Tried to replicate the same environment on-prem and everything works fine. Created a new App Service which is also running into same issue. Any help is much appreciated.
Update 1:
I think I figured out what is happening. This is related to font libraries on linux https://github.com/ariya/phantomjs/issues/10904
I need to install libfontconfig but this is not supported on Azure App Service.

Yes, it is due to sandbox restriction on a App Service. Just to highlight, the standard/native Azure Web Apps run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available.
Not supported scenarios on standard App Service - PhantomJS (/Selenium): tries to connect to local address, and also uses GDI+.Known issue for all PDF generators based on wkhtmltopdf or phantomjs: custom fonts are not rendered (system-installed font is used instead) because of sandbox GDI API limitations.See App Service GitHub sandbox page.
Based on your requirement, however you could use a custom container in App Service (You can use a custom Docker image) that lets you make OS changes that your app needs.
Checkout these document for more details on this topic:
Run a custom Linux container in Azure App Service (You can use a custom Docker image): https://learn.microsoft.com/azure/app-service/containers/quickstart-docker
Run a custom Windows container in Azure (Preview):
https://learn.microsoft.com/azure/app-service/app-service-web-get-started-windows-container

Related

How to run AWS API gateway developer portal in local machine and change the UI

I need to make some UI changes in AWS developer portal. So I followed this steps to install developer portal in my windows machine. its installed without any errors.
the problem is when I run the application using node run start I'm getting this screen
The UI components is not loaded correctly and throwing some errors. same UI code working correctly in my AWS account.
How to run this in local machine?

How do you host Strapi within an Azure App Service?

After inheriting a Strapi application hosted on Azure Container Instances, which has proved temperamental.
Given it's on the surface just a Nodejs application we want to move it to an Azure App Service to take advantage of hosting savings and also deployments via slot swapping.
The current documentation for Strapi includes guides for both Azure VM and deploying as a Docker conatainer. However we want to host as code on a windows based app service.
The reason for windows over linux is the time that Zip Deploy or Web Deploy taken when running on the linux version. Also we can run the App in an existing App Service plan.
The question is how to host Strapi on an Azure App Service?
After much trial and error we finally have this up and running, here are the steps that made it successful.
Create the App Service
Create an App Service that publishes "code", has a runtime of Node 14 LTS & has OS of Windows.
Configure the App Service platform
Once created navigate to "Configuration" of the App Service and make sure that WEBSITE_NODE_DEFAULT_VERSION is set to "~14". And on the "General Settings" tab update the platform to "64 bit". This ensures that the "sharp" package that is used by Strapi can run, as it requires 64 bit platform.
After making these changes, navigate to the console and run the command node -p process.arch you should see the result is result is "x64".
Application Settings
Now to configure your application specific settings. For an out of the box Strapi app this is likely to include database configuration and any plugins like mail, identity and storage providers.
For us the crucial part though was the settings to be used by Strapi to startup and host the application.
This include the HOST & PUBLIC_URL settings.
HOST = 0.0.0.0 and PUBLIC_URL = https://{APP_NAME}.azurewebsites.net/ (replace APP_NAME with the name of your app).
Code changes
There are a few changes needed to the out of the box Strapi app that are needed to run on Azure.
Add a web.config to the route of the project. An example can be shown here: https://gist.github.com/bradleyisfluent/1033bb9dc908b2386c5ee09e0b36409f. This utilises IISNode to run server.js as the entry point to the app.
Create a server.js in the root of the project. Contents should look like:
const strapi = require("strapi");
strapi().start();
Modify the current server.js within Strapi config /config/server.js to access the environment variables on the server, like this:
host: process.env.HOST,
port: process.env.PORT || 3000,
n.b of course here, we are simply accessing environment variables and configuration it can be managed in different ways. The crucial thing though is to access the port via process.env.PORT which is implicitly set on the App Service.
Deploy code
This is where we are still a little bit of a work in progress. Utilising Azure Devops pipelines we are building and deploying the application.
It appears that using "Run From Package" feature of Azure App Service doesn't not work for Strapi. My hypothesis is something is trying to write to the wwwroot dir which is read-only in the this setup and this causes an error.
So we are using "webDeploy" which given the size of our built project (218mb, thanks node_modules) means the deployment times are slow. However this only applies to our preview builds as we can use slot swaps to release to Production.
Here is a link to a slightly reducted version of a working azure-pipelines.yml: https://gist.github.com/bradleyisfluent/ffff8c1b6bedd5052274dc0d9f19a91d

Azure app service docker container 'Service Unavailable'

I have followed the tutorials for building a .net core web application into a docker image, publishing to an azure container registry, and then I have setup my VSTS Release template to deploy the container to the app service.
This all appears to work, I can view my image in the container registry, and the deployment appears to succeed - but when navigating to the app service site, all I get is an HTTP 503 - Service unavailable.
The app service is started, I can see deployments in my file system via bash - so I wondered if I am missing something?
I do not have a 'startup' command in any of my templates, I wondered if it could be this?
The site works perfectly from VS2017, including debugging via docker, so it really is just a case of... how do I get the App Service to actually load and execute the image?
Thank you!
EDIT
Further to this, I have got access to the docker diagnostics logs which claim "image operating system "windows" cannot be used on this platform".
My base image is the microsoft/aspnetcore:2.0 image, which runs perfectly fine on my linux container in my development environment... but appears to not work in the Linux App Service?
Is the aspnetcore:2.0 base image not suitable for a linux app service?
I ended up resolving this week, hopefully the answer will help others.
When using VSTS Hosted build agents to produce images running off the docker base microsoft/aspnetcore:latest - unless you use the (Linux Preview) hosted build agent, you will get produced a windows container, which will not run on the linux app services.
Once I switched to using the hosted linux build agent, the container successfully loads, and my issue is resolved.
Another solution for the same error message:
Try microsoft/aspnetcore (without the tag/version :2.0) as image. If that doesn't work, check the docker logs as mentioned above and look for a solution based on the exact error (usually a missing dependency).

Hosting existing node.js apps on Windows Azure

Is it possible to port existing node.js applications to Windows Azure platform? I currently develop on my Mac but will need to deploy the application to Windows Azure in a near future.
You may also want to check a video on Channle 9.
node.js on Azure : http://channel9.msdn.com/Events/Patterns-Practices-Symposium-Online/Patterns-Practices-Symposium-Online-2012/node-js-on-Azure
Yes it is very much possible. You may also need to consider to make changes to use Azure Blob storage where your node.js code is using local file system (if required). The deployment is very similar to any other Windows Azure App and one you have Azure SDK for node.js you can use powershell cmdlets to make your job easy.
Download Node.js SDK for Azure
https://www.windowsazure.com/en-us/develop/nodejs/
Here you can learn the basics to deploy node.js app to Azure:
https://www.windowsazure.com/en-us/develop/nodejs/tutorials/getting-started/
Porting node.js apps to Azure is possible but not yet a yes/no answer.
You can run your Node apps in Azure but you need to look at the modules you're using to make sure you aren't depending on a tool or command or other facility that isn't yet available on Azure. For example, are you using a database like redis or couchDB or mysql? These don't exist natively in Azure so you may or may not be able to port that layer -- you'll have to check.
Since you're on a Mac, there isn't yet a native OS X deployment tool. Microsoft and the Cloud9 folks have been showing a way for Macs to deploy from the Cloud9 IDE which works but the Mac story will most assuredly improve over time. I work on a Mac but I keep a Windows VM open (Parallels) and if I deploy from the desktop I've been using the Powershell cmdlets in the Windows Azure SDK for Node.js which makes things fairly turnkey from Windows.
You will want to follow a couple of repos and their contributors: Azure SDK for Node, which allows native access to Azure Storage via npm install azure and iisnode (on Github) which is a component that assists your node app running under IIS (the Windows Web Server) on Azure.
It's been great to see the Node story on Azure evolve; it's still just a little early but they seem to be making great progress quickly.

Test Azure application in Dev Fabric

I have a created a sample web role application using cloud service. Before hosting my application in cloud, i want to test the application in Dev Fabric. I am sure that when we run the application from VS, it creates an environment that simulates the cloud.
But, if I want to give my application for testing to QA, do I still need to give my source to them and run the application from VS under Dev Fabric or is there any other ways in running my deployed package under Dev Fabric.
In a line, my question is: How do i run my packaged Azure application under Dev Fabric before hosting in Cloud?
Can anyone having an idea, please share me some information?
Thanks for your quick response. CSRun command helped in accoomplishing my requirement. But i can see that it is taking an IP Address, http://127.0.0.1:80/ by default.
Also i am trying to find it out that, is there a way we can change this to a proper name instead of using like an IP?
for ex: http://localhost/ or
with deployed machine name like http://applicationserver/webrole1/ - so that we can access this from any machine in the netwrok.
I went through the Dev Fabric UI, where we can see the curent instances running, but i didnt find any options for these.
Please share me some information on this.
When you run your application locally, a different kind of package gets created (actually a directory) with a .csx extension.
As long as you have that .csx directory and your configuration file (.cscfg), you can run the package by using the "csrun" command. (So no, you don't need Visual Studio.)
You can use this blog post to access azure services running in DevFabric (DF) from other boxes -
http://blog.ehuna.org/2009/10/an_easier_way_to_access_the_wi.html

Resources