I am new to Jive development using Node.js and I see that any addons that you create must be running and reachable via a specific address and port that you define in your jiveclientconfiguration.json file. I tried to deploy a tile addon to Azure websites hoping that would work but there is no way to define what port number Azure uses.
Where do you deploy your production Jive addons at and how do you set your configuration file?
Some of Jive documentation could be a bit confusing.
here the main steps I followed:
Sign up for a free account at Nitrous.IO.
Create a new Node.js workspace.
Install the Node SDK within the Nitrous workspace (npm install jive-sdk -g).
Create a new tile, app, or whatever you want to create (e.g. jive-sdk create tile-list).
Update dependencies (npm update).
Get the URI for your new workspace. (You can use the "Preview" menu to get this... e.g. http://fierce-meteor-71-123263.usw1-1.nitrousbox.com/) Update jiveclientconfiguration.json with this URL.
Start your service (node app.js).
Download extension.zip from Nitrous.
AND THEN... upload that extension.zip to the Sandbox and follow the other directions.
I tried this scenario earlier in the week and it worked for me. Let me know if this helps.
Related
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.
I have been trying to create a web service all day in azure using node js,
I cannot seem to figure out what to do, every time I get a different issue,
I created a simple express app and committed to git, afterwards connected it to azure web app just like in this tutorial:
https://www.youtube.com/watch?v=-zjnOTZxuEU
After that I am getting this page:
image
I tried to remove the hostingstart.html from the default document but then i am getting a page telling me I don't have permissions,
What to do in order to get it working?
You can see the express app here: https://github.com/orizvida/new
Your API method has no path defined:
app.get('/',(req,res) => res.send("hello"));
Should be like:
app.get('/hellomessage',(req,res) => res.send("hello"));
If you are new to this, you could follow this steps:
Create a simple express project by this command:
npx express-generator
npm install -g express-generator
express
express --view=pug {your-app-name}
cd {your-app-name}
npm install
Upload to GitHub. Here is the file structure:
Create a Web App on Azure.
Navigate to Deployment Center, set deployment from GitHub, choose your repository, and save settings.
Go to GitHub, and see the Action logs in your repository:
Go to your website to see the result: https://dorisnode.scm.azurewebsites.net/, and go to this site to see the file structure: https://{your-file-name}.scm.azurewebsites.net/wwwroot/
If your Web App based on Windows while creating, you might need a web.config file to make IIS recognize your project, see here.
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
I am currently working to move TFS from its' current server to a new environment. My team has already completed the steps as seen in this Microsoft Documentation on moving TFS to a new Server.
We have already installed and migrated/restored our SQL Database in the new server and ensured all the prerequisites for TFS were installed. The TFS Admin Console is currently installed and we are trying to configure it by using the existing Tfs_Configure database. That all works without a problem, however, when we go to look at our existing Project Collections, the build service is still "linked", having the TFS Address set to the old server and not the one we migrated to.
I have detached the collections in the old environment and reattached them in the new environment, however, they still seem to be trying to build in the old server. I am reading that we needed to detach them prior to migrating any data over. Did we do something incorrectly, or rather, did we try to detach the collections too late into the process?
You need to unregister the build service that uses the <<oldcomputername>>. Register a build service with the <<newcomputername>>. And do the same for the agent and the controller.
On each build server, open the administration console and stop the
build service.
In the properties for the build service, update the communications
properties.
According to the above screenshot, you could see the build service is configured under project collection level.
Moreover, for vNext build agent you need to remove and re-configure an agent.
To remove the agent:
.\config remove
After you've removed the agent, you can configure it again.
You have to update your build services to point to the new server. For XAML build, you'll have to reconfigure the build controller. For the modern build system, you'll need to reconfigure your build agent(s).
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