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.
Related
I've been working on a small function to automate my certificate renewal in Azure Functions.
The function works in my local emulator (in vscode), running under node v10.15.3.
However, when running it online, an exeption is generated on the syntax of an async iterator when the file containing it is included
Stack: /home/site/wwwroot/node_modules/acme-dns-01-cloudflare/index.js:125
for await(const zone of consumePages(pagination =>
It's my understanding that this syntax has been adopted in node versions 10.x. I therefore added the console output line: console.log(process.versions); and get the response that the function is running node version 8.16.1. I therefore checked the WEBSITE_NODE_DEFAULT_VERSION application setting, and confirmed it is set to 10.14.1. I have also checked it with another recommended setting of ~10 and got the same result.
Unfortunately the documentation is difficult to search for such a specific issue, but I have not yet come across anything that states that Linux functions are limited to node v8.x
As extra information, the FUNCTIONS_WORKER_RUNTIME is set to "node", and the runtime version is 2.0.12733.0 (~2)
At time of writing, this issue on github highlights the problem https://github.com/Azure/azure-functions-host/issues/4948. Different node versions are simply not available on Linux consumption plans regardless of the setting in WEBSITE_NODE_DEFAULT_VERSION.
Hopefully their new arrangements will be in place soon for anyone else who has this issue.
For now you can switch to a windows consumption plan, or potentially switch to a service plan (I haven't checked this, as it sort of defeats the point of functions)
Refer to this issue1 and issue2, looks like WEBSITE_NODE_DEFAULT_VERSION won't work for linux function, have to set the LinuxFxVersion property to select the node version.
Follow is my flow to change it.
1.Go to your Function App in the portal and open the Resource Explorer. You will find LinuxFxVersion is node:2.0-node8-appservice.
2.Select the web under config node, then choose the Edit button. Find the linuxFxVersion and change the value to NODE|10.14, after this click the PUT button to update the setting. Then restart your Function, check the node version you will find it's 10.14.
I met an issue when using Azure function.
I create a Azure Functions v1(.Net Framework) Http Trigger template in VS. But when I try to run it directly, exceptions thrown.
I am using latest version of VS(15.6.7) and Azure Functions and Web Job tools(15.0.40502.0).
When I run it first time, no prompt for installation of anything, it runs on 1.0.10 Azure Function CLI. After I restart my VS and try to run it again, VS asks to download 1.0.12.1 Function CLI. The download seems failed as I still see 1.0.10 on the tile of window. The exception remains all the time.
Any idea? It doesn't make sense since I just try to run a template.
The root cause is shown in your screenshot.
Starting Host(...,Version=1.0.11232.0)
It means your function Cli is 1.0.4 other than 1.0.10 actually, here's release note of 1.0.4. After tests, find that old version does cause this exception. This version issue roots in failing to download latest Azure Function Core Tools trough VS.
Update for official solution
Handle downloading problem of Azure Function Core Tools. Try the first option to download using VS again, if it still fails, use the second option, PS scripts.
Below is the original solution, similar to the first and third official option, just ignore it
More Details
Azure Functions and Web Jobs Tools is updated to 15.0.40502.0 recently and mechanism of using local function Cli is also changed. Release Notes.
Tools now consume a feed which keeps templates, build tools, and the runtime up to date whenever there is a change made in the service.
The first time we create an Azure function after this update, we can see the tip on the dialog Making sure all templates are up to date.... It means VS is downloading necessary cli and templates to this folder C:\Users\UserName\AppData\Local\AzureFunctionsTools.
After a while, we can see the tip changes as
If we don't wait the downloading to complete and create project directly, it will prompt that VS is downloading 1.0.12.1 Cli. And everything should work fine after that.
As for your problem, I reproduce it once due to slow network. It fails to download those files and tries to use old version cli downloaded by VS before.
Solution
I recommend you to delete AzureFunctionsTools folder and restart your VS to download it again.
If it still fails to download, you can download it manually.
You can find download link of cli, itemTemplates and projectTemplates in C:\Users\UserName\AppData\Local\AzureFunctionsTools\feed.json.
And the folder structure in C:\Users\UserName\AppData\Local\AzureFunctionsTools\Releases\1.0.12.1 is like this
cli
--func.exe
....
templates
--ItemTemplates.nupkg
--ProjectTemplates.nupkg
manifest.json
Content of manifest.json
{
"ReleaseName": "1.0.12.1",
"CliEntrypointPath":"C:\\Users\\UserName\\AppData\\Local\\AzureFunctionsTools\\Releases\\1.0.12.1\\cli\\func.exe",
"TemplatesDirectory": "C:\\Users\\UserName\\AppData\\Local\\AzureFunctionsTools\\Releases\\1.0.12.1\\templates",
"FunctionsExtensionVersion": "~1",
"SdkPackageVersion": "1.0.13"
}
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.
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
I have an elasticbenastalk (eb) web node.js application in a working environment.
I'm using a well built zip file in order to deploy.
The thing is that after deploying, eb dashboard displays a green status and the correct version number for the application (the one I want to deploy). This should be the expected result (api-0.0.22 is the latest available version).
However, in a randomly manner, the deploy software doesn't change (I have a version file in order to confirm which is the effective deployed version). When I detect this, I also can see a timeout in the events' log that confirms the non-deployment.
I've gone through the available logs and I couldn't find any attempts to download the software from S3 nor installing it. I mean that is there not only a lack of errors but also a lack of proof of the deployment. It looks as if 'it never happened'.
I'm also using one ebextension for logging (logging.config):
files:
"/opt/elasticbeanstalk/tasks/bundlelogs.d/01-appname.conf":
content: |
/var/app/current/log/error.log
"/opt/elasticbeanstalk/tasks/taillogs.d/01-appname.conf":
content: |
/var/app/current/log/error.log
Note: /var/app/current/log exists in the application file tree
I've been making lots of tests and one of them gave me a little light over the dark: if I terminate the eb related instance that timeouts, eb launches another one with the correct (and expected) application version.
I don't know if this issue could be code related (that is why I'm using stack overflow) or eb setup or deployment method.
Any suggestions/ideas will be very appreciated.