I've deployed React SPA to Azure and its running/started with pm2 serve /home/site/wwwroot --spa --no-daemon command. App build/deploy is done using Github action. We want to have two separate applications for production and test, on separate app services and with different env files. Problem is that by default, pm2 always loads .env.production - even if we set both DOTENV_CONFIG_PATH and NODE_ENV to .env.test and test respectively.
How to force app to load different .env file, depending on Application settings on Azure or by some other method? Apps are essentially the same but they are built using different action (different branch) and they should load different environment settings, depending on which App Service they are hosted. One should use .env.production and other should use .env.test. Local development works fine, it loads .env.development.
Related
For my React Native app, in my dev environment, I've a .env.development file that contains environment variables required by my app, like service endpoint urls, library secret keys, environment and log prefixes etc. In my app I'm consuming those using react-native-config.
How can I define these in App Center? I read here that environment variables defined in App Center config are only for build scripts.
Can I define variables required by my app here and use these or do I have to check in my .env.development into my repo (which I'd rather not if there is a way to avoid it!).
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
I have a monorepo which contains, an API, a React webapp and a worker.
I want to deploy this into Azure (first time doing so), however am unsure about the procedure I need to follow.
I've created an App Service - however do I need to create multiple app services for each of the 3 pieces (api, worker and front end)? I've seen deployment slots - is it in here I specify how to run each of them e.g. npm run api, npm run worker, cd front->npm run front
If I have to create 3 separate app services, as all my code is in a monorepo, when I update something will I have to deploy to each of the 3 app services?
Thanks.
Yes you can use multiple slots per same app plan, if you want to save costs and understands your apps computing needs here
To control the CI/CD pipelines, use repo path filters (include/exclude) in each build pipeline to work only if specific app changed like here
How are people transitioning between local development with .env files for Node.js to production deployment with Azure app service config settings?
Locally, I use a .env file for settings but on the cloud app service - I use service app settings. My deployemnt using the Azure app service extension deploys my .env file - which I don't want. The only way to stop it is to use a VSCode app setting which doesn't get saved to GitHub.
There has to be a better mechanism.
If you're using the zip deploy, VS Code should automatically add a settings.json file in your ".vscode" folder with a appService.zipIgnorePattern. That setting defines which items to ignore in the deploy. And it should be fine to check that into source control.
It is possible to update app.yaml or dispatch.yaml for services running in Google Cloud Platform by running the following in the terminal:
gcloud app deploy dispatch.yaml
However, when I replace dispatch.yaml with server.js, I get the following message:
ERROR: (gcloud.app.deploy) [path to the file] could not be identified as a valid source directory or file.
Is the only way to deploy the application completely again?
The gcloud app deploy takes YAML configuration files as input for determining what aspects of your application's configuration will be updated. If you specify gcloud app deploy app.yaml, the tool will deploy a new version of your app. If you want to override an existing version, then use gcloud app deploy app.yaml --version=NAMEOFCURRENTVERSION
If you need to upload changed files, you need to redeploy the app. Its tempting to think of App Engine like a standard web hosting environment, but the application code is containerized and possibly in multiple running instances. You don't have direct access to the files for things like direct editing or replacement.