I am trying to deploy a React app in my Jelastic Node.js server but I am not being able to make it work.
I am using vite for building. To test the deployment, I am building my app on my local environment and deploying the build directory into the Node.js server which works fine sometimes but sometimes it too doesn't work and the site is unreachable. I don't know what causes this.
But I want to make this process automatic and set the root directory to dist directory which is default build directory for vite so that I could pull it from GitHub and run build command and deploy it automatically. I searched for changing the configurations in Jelastic Node.js but couldn't find any relating to this issue.
You can either a) add VCS project into any non ROOT context, and for ROOT create a symlink through WebSSH (but this can cause downtime during deployment) or b) add VCS project into any non ROOT context and add a deployment hook to which copy content from dist into ROOT (and in this case downtime is minimized).
Related
I'm trying to deploy a nodejs app on jelastic using pm2. Though I understand the classical use would be to have the app in ROOT folder, having ROOT folder containing package.json and ecosystem.config.js file.
Howerver the company I work with is used to have one GIT repo per project, with subdir /api for backend and /web for the frontend.
So my nodejs app is actually in ROOT/web/
Is there anyway to configure things so that it works? I tried changing node variables PROCESS_MANAGER_FILE and ROOT_DIR but it always somehow fail.
Thank you for your help
I am deploying a react web app on azure by creating a workflow on github.
Now after committing changes it shows an error on creating build as:
The same error occured when I was deploying it using surge.sh
Can anyone help me out?
It seems to be a problem related to the Node.js module in your repository. Therefore, I suggest you do the following
Part 1: Reinstall the Node module
yarn uninstall
yarn install
Part 2: Redeploy the project via GitHub Action
Part 3: Deploy the React app directly from Azure Portal
Adding to Mark's response. Try the following steps to further narrow-down the issue:
-Please check if there is a .deployment file in the root of the repository, and provide this file if present, along with the deploy._ file if present (deploy.cmd, deploy.sh, deploy.ps1).
-Just to isolate, test the deployment directly from your local Git repository to a new App Service.
--If a .deployment and deploy.sh file are included in the root directory of the app code, Kudu will use the legacy build to run the commands specified in the deploy.sh script.
--Just to highlight on this, Kudu is the engine behind Git deployments on both Windows and Linux. By default, App service uses Oryx to build/install and Kudu will determine type of stack is used and creates a generic deploy.sh script to install the packages.
-App Service sets the environment variable PORT in the Node.js container, and forwards the incoming requests to your container at that port number. your app should listen to that port using process.env.PORT
const port = process.env.PORT || 3000
1.Add a start-up script: Add the PM2 configuration file or your script file
2.Go to Azure Configuration>General Settings
If your build folder is at the root of the project:
Start up command: pm2 serve /home/site/wwwroot --no-daemon --spa
Certain web frameworks may use custom startup scripts when running in production mode.
Refer this doc Customize build automation for more details.
I am trying to deploy a Node app on an Azure App Service, using Github and Kudu, running on Windows. The deployment works and the app is started.
My codebase is organised as follows:
/config
/res
/src
package.json
and package.json contains node src/start.js.
The problem I am having is that it seems that on that deployment the root directory for the Node app is site/wwwroot/src and not (as on my local machine, or my previous deployment on AWS) site/wwwroot. This leads to my code not finding the files inside /config or /res since the paths used in the code presume that the root is top level, and not inside /src (e.g. ./res/myFile.jpg will try opening site/wwwroot/src/res/myFile.jpg and not site/wwwroot/res/myFile.jpg).
I have been looking around but can't find how to change this. Can anyone help me?
Thanks!
For those wondering: I didn't solve it but a workaround is to put your entrypoint js file in the root directory. So instead of having node src/index.js you use node index.js, while keeping all your other sources in /src.
I have an application using Node.js with Aurelia on the front-end, which I want to deploy on Heroku.
To run the app locally, I need to execute following commands:
1. npm start
2. cd public > gulp watch
After installing heroku-cli, tried publishing it using git push heroku master.
The problem is, Heroku only runs npm start when it's deploying the app on cloud. So it is able to start the server.
However, it doesn't know anything about cd public and gulp watch.
My question is, how can I tell Heroku to change directory to public and execute gulp watch command, once it has started the server?
Edit:
I forgot to address an important point. Since you only mentioned Aurelia in your question, I (wrongly) assumed that that's all you had.
Ultimately, for a production app you'll want to have a proper webserver hosting your Aurelia app.
Example:
For Aurelia apps I've built, I typically have 3 distinct processes running, each with their own port (or hostname):
IdentityServer
ASP.NET Web Api
OWIN FileServer
The third one is what hosts my Aurelia app as a static bundle.
There is no gulp or anything like that involved here. The server doesn't even have npm installed and sees it just like any other server-side application. And that's exactly how I deploy it; no node-related commands needed.
If you're using nodejs for your server-side stuff, use http-server to serve the static bundle.
When you host your aurelia app within your own serverside application you get the added benefit of being able to send some bootstrapping configuration directly along with the bundle, so you don't have to hard-code urls and such.
That's what I implied with "don't host a static site on heroku": bundle it up, and let your web application host it. My original answer would only apply if there is no server-side stuff involved.
Original answer:
It's generally not recommended to host static sites on heroku, see this blog post. The bottom line is that Aurelia sites are static, and a static site doesn't need an app server. It's unnecessarily expensive and doesn't have as good distribution as most CDNs do.
With that said, if you insist on hosting a static Aurelia site on Heroku then your best bet is to combine all your script calls into a single call which, as you say, already runs. So make your npm start script call gulp watch.
You'd probably want to npm install your dependencies and call ../node_modules/.bin/gulp watch instead of calling gulp globally.
When it comes to Heroku however, gulp watch in itself probably won't work because that will start a development server which will have no port binding in Heroku. It will run, but it won't be accessible from the outside.
gulp watch is not something you want to run on a server anyway because it will watch for file changes (which never happen there) and run things like browsersync which will be useless. Just bundle your app and start a normal http-server or better yet, upload the bundle ready-to-start into the correct folder and you're done.
You want to build your app and then deploy as if it were a fully-compiled, static application. With Aurelia CLI, that would be au build --env prod and then copy the scripts folder, index.html, and any dependencies like css, fonts, etc. to a separate folder. gulp build works the same way.
From there, you will publish the compiled app to Heroku as shown in this medium.com article:
https://medium.com/#winnieliang/how-to-run-a-simple-html-css-javascript-application-on-heroku-4e664c541b0b
The main part of the article is below, but here is the kicker - you are "tricking" heroku into thinking it is a PHP app. Serious!
Head to root directory of the repo that contains index.html which dictates the main HTML page.
Run touch composer.json to create a file called composer.json.
Add the following line: {} inside.
Run touch index.php to create a file called index.php.
Add the line: <?php include_once("index.html"); ?> inside.
Now update the repo on Github if it’s connected to your account or Heroku command git push heroku master . Wait for the automatic deploy to work its magic and tada!
There are some other steps to make your compiled app into a repo (ie, git init) but this should work for you. It did for me.
I am writing a number of VueJS apps that take part in a larger Microservices environment. My current workflow seems long winded but I can't find anything better and would like advice on how I could do it better. Here is my current work flow.
Write VueJS development version (testapp)
Push testapp to git server
npm rum build to get a dist folder
Create a nodejs/express app (testapp_server)
Copy testapp dist folder to the testapp_server html folder
Push testapp_server to git server
On production server clone testapp_server from git
pm2 start app.js --name testapp_server
If I make changes to my VueJS test app in dev, I have to go through this whole process again to get it into production.
I am on a closed secure network, so I don't have the luxury of using Heroku etc.
Is there a better way?
Update: I have just found out about git sparse-checkout which allows the checking out of specific folders from a repo. I am thinking I could include my dist folder in my development git repo and then just check out the dist folder using sparse-checkout directly into a node/express app on my production server.