Updating code of managed vm on google compute engine - node.js

I understand this might be an easy solution, but I am very new to this so any help would be appreciated.
I have been running through the hello world application for node.js with managed vms on google compute engine, and I have just done this stage
gcloud preview app deploy app.yaml --promote
Which has allowed me to put up the app, and it works.
BUT HOW do I now update that code? If I run that command again it starts up new instances and essentially treats it like a new upload.

You can deploy the updated version of your app by running the same command you used to deploy the app the first time, as indicate in this article:
If you update your app, you can deploy the updated version by entering the same command you used to deploy the app the first time. The new deployment creates a new version of your app and promotes it to the default version. The older versions of your app remain, as do their associated VM instances. Be aware that all of these app versions and VM instances are billable resources. For information about deleting or stopping your VM instances, see Cleaning up.

Just in case anyone found this question looking for the same information, I finally seemingly worked out how to do it.
You need to attach the --version flag when you are deploying, instead of using --promote.
You can find the default version in google cloud console, by going menu (burger icon) -> app engine -> versions and you will see in that list one item with (default) by it.
so then when deploying put that version string after --version and it will deploy without needlessly creating new things

Related

Why is my code not updating on App Engine?

I have an App Engine Service, running on Google Cloud Platform.
I run an old version of my NodeJS application on it.
After having updated my code, I have run the following command: gcloud app deploy, in my GCP console, directly. It shows no error.
It says 'X files updated' and after that, I go on my application and the code is actually not updated.
I expect my code to be deployed and therefore, updated, after I run this command.
Why is this expectation not met?
Are you sure you are deploying to the same version? If you're deploying a different version, did you migrate traffic to this new version? To check this, login to console.cloud.google.com > App Engine > Versions
This will show you all the versions you currently have deployed and you can confirm which one(s) are serving traffic
You should also confirm that you actually have the 'updated' source code deployed. Following the link in bullet 1 above, you should see a column that says 'Diagnose' with 'TOOLS' under it. Click on the drop down and select 'source'. This will show you your source code. Confirm you have your updated code
If your files are static, they could be cached. You can try using cache bursting techniques (search Stackoverflow for this), or wait for some time and try again.

Set up Azure Application Insights for local environment

We have set up Application Insights for our Dev & Prod environments, not with the SDK but through the Portal. We're now in the process of installing the SDK so we can have more control over customizing logging, what to measure in performance, etc.
I have found how to separate the environments in code (separate Instrumentation Key in different config files etc), but I have found nothing when it comes to my local environment. Which instrumentation key should I use there, the dev one? Wouldn't then this skew our dev metrics everytime one of the developers runs the app locally?
And also, doesn't it make sense to have a separate App Service slot just for the local environment, so I can test everything and see the logs I'm trying out locally, and not have to deploy to dev everytime I want to see what I'm doing?
I've tried creating a separate slot for local, but it generates a weird url based on the name I give, which I can't change later.
I've googled for a couple of days already and couldn't find any (or very little) helpful advice when it comes to this.
I realise there is a "Just add the SDK to try local only mode" option in Visual Studio, but then I would have to use it exclusively locally. What I want is to use all three - my local, dev & prod.
We're using .net core 2.2 for our backend and Angular 7 for front end.
I'm an idiot.
The url set up automatically basically means nothing. I solved the problem by just adding another App Service slot (created from our App Service production one, just like dev), and added this key to the local settings in our project.
Now we can use this key to get real time results as we debug, and use the other two for dev & production.

Deploying Strapi to Azure

I want to deploy Strapi to my Azure. Anyone here who has an experience doing such and making it up and running completely? Somehow I couldn't find any detailed instructions how to do that in Azure.. I'm looking for something that is as easy as deploying it to Heroku - but it's fine though if it'll require more steps as long as I can make it to work completely.
This is the complete instruction I have also created in the README of the repository.
Strapi-Azure 3.1.3
This is a working repository of Strapi 3.1.3 which you can already deploy as an Azure Web App. This requres a paid subscription, minimum of B1 plan (32 USD estimated), so we can enable the 64-bit platform configuration and the Always On feature.
To get started, let us first create and configure our Azure Web App:
Create an instance:
Name: The name of your choice that is still available
Publish: Code
Runtime staci: Node 12 LTS
Operating System: Windows
Region: select near you
Sku and Size: select B1 (minimum)
Configure the Environment variables:
Add the following key-value pairs:
For the HOST make a ping to your .azurewebsites.net instance and get the IP
Configure the Platform Settings
In the General Settings tab (beside the Application Settings), change the Platform from 32 Bit to 64 Bit
To confirm if you are indeed now on 64 Bit mode, go to Console and run node -p "process.arch"
Install yarn:
Go again to Console and run: npm install -g yarn
Deploy from your github account a copy of strapi-azure repo
In the Deployment Center tab, connect your GitHub account and browse your copy of strapi-azure
Select App Service build service as your build provider
Select repository and branch
Deploy!
Build your Admin UI using Kudu service
Go to Advance Tools -> Go -> expand Debug console from the toolbar -> CMD
Inside the wwwroot directory (site/wwwroot/), execute yarn build
See it in action 😊
It should not be any different than installing Strapi on any VM (Azure, AWS, GCP or even local VM).
Quick start guide should help you setup things and run Strapi server --> https://strapi.io/documentation/3.x.x/getting-started/quick-start.html
Primarily: Install nodejs, npm and strapi (via npm). Execute strapi new cms --quickstart and you should be good to go (with default configuration).
Assuming you have it within a GIT repository, I may have some useful insights.
When I set mine up, I created an app service hosted on windows - for some reason I found the Linux ones very unstable. I then used the Deployment Center to then setup the connection between my repository hosted on Azure Devops onto my App Service. When it deploys IISNode will automatically be setup with an appropriate web.config file for getting a NodeJS server up and running.
You may need to ensure you are running in production (assuming this is what you want), you can set this up by going to the App Service - Configuration - Application Settings (tab) - set up new variable called
"NODE_ENV" and set this "PRODUCTION".
I also found it useful to set
"WEBSITE_NODE_DEFAULT_VERSION" and specify the version - in my case it was "10.15.2".
For the database I used a ComosDB with the Mongo API, this was hosted on azure and it worked OK - the main problem I found was that I was getting charged a lot for the usage of it, not quite sure at this stage how to get around it.
One thing that did catch me out was setting the "port" variable within the config/environments/production/server.json - I was hard coding a port which doesn't work within IISNode - this needs to be set to something like
"host": "your.domain.com"
"port": "${process.env.PORT || 1280}"
You will also need to setup your database settings in config/environments/production/database.json file.
Happy to work through any further points, let me know

Can't shutdown app engine version. Keeps billing

I am not able to stop and consequently delete a app engine version. I have 3 different versions at the moment, under the same default service:
gappa-v1, which is currently serving 100% of the traffic
mg-v1, which is currently stopped
20170223t163224
I am able to stop, restart and delete all the versions but the 20170223t163224 version.
I have tried everything, both from the Google Cloud Console, and the gcloud command-line tool.
Interacting from the Google Cloud Console is kinda useless because it gives me no feedback on the error, but just a generic Failed to stop version on a stop attemp or The version could not be deleted on a delete attempt.
When interacting with the gcloud command line tool, I have tried:
$> gcloud app versions stop `20170223t163224`
$> ERROR: (gcloud.app.versions.stop) INTERNAL: This flexible version cannot be modified, it can only be deleted.
Then if I try to delete it:
$> gcloud app versions delete `20170223t163224`
$> [default/20170223t163224]: Error Response: [13] Deployment Manager operation failed, name: operation-1488895382516-54a247861f121-d456a139-0b1e3fc6, error: [{"code":"RESOURCE_ERROR","locati
on":"/deployments/aef-default-20170223t163224/resources/aef-default-20170223t163224-00","message":"{\"ResourceType\":\"compute.beta.regionInstanceGroupManager\",\"ResourceErrorCode\":\"400
\",\"ResourceErrorMessage\":{\"code\":400,\"errors\":[{\"domain\":\"global\",\"message\":\"The instance_group_manager resource 'aef-default-20170223t163224-00' is already being used by 'ae
f-default-20170223t163224'\",\"reason\":\"resourceInUseByAnotherResource\"}],\"message\":\"The instance_group_manager resource 'aef-default-20170223t163224-00' is already being used by 'ae
f-default-20170223t163224'\",\"statusMessage\":\"Bad Request\",\"requestPath\":\"https://www.googleapis.com/compute/beta/projects/MYAPPID/regions/us-central1/instanceGroupMana
gers/aef-default-20170223t163224-00\"}}"}]
Somewhere (I can't find where in this moment), the docs says I can't delete a version until traffic is allocated to it. So, I made sure that the version has no traffic allocated. Infact the app engine console shows the following:
I have also tried to delete the single version instances using `gcloud app instances delete INSTANCE_ID --service=default --version=20170223t163224. This command didn't return any error, but had no effect, there are still 2 instances.
I also tried to override the version deploying a new, basically empty app (hello world, from the google tutorial), but it didn't allow me to deploy it.
The biggest problem is that i am still getting charged for this version, as it is still there, serving and with 2 instances.
I am currently working with Google App Engine Flexible Environment and NodeJS.
You should contact billing through this form. In future, for production issues like this, you should also see about posting to the issue tracker.

Upgrade/downgrade service fabric application with already deployed version

In Service Fabric cluster, If application has multiple versions(say 1.0.0,1.0.1,1.0.2), then how can we shift the application to one version to another version(say active is 1.0.0, then I wanted to shift to 1.0.1) with out redeploying the application. Is there a PowerShell command to do this?
You should be able to use the PowerShell command
Start-ServiceFabricApplicationUpgrade
This being said I did hit an issue with my local cluster, telling me I couldn't upgrade / roll back the application if the service description had changed, which it hadn't. Using an Azure hosted cluster this worked as expected, perhaps an inconsistency with how the package is copied into the image store.
Depending on what you are attempting to achieve you could also look at named instance where you are able to deploy multiple versions of an application at once, for A - B testing.
Here are some similar posts:
Post 1
Post 2
EDIT:
Thanks to Aleksey L for the comment below. With a bit of messing around due to types not being the same and as long as you haven't changed any parameters between versions this will work,if you have you will need to manually build up the hash table.

Resources