How to run nginx and Node.js with EC2 (linux) server startup

Question

How to run nginx and Node.js at server startup?

In order to start Amazon EC2 with AWS Auto Scaling, I must directly connect to EC2 to run nginx and Node.js.

Can this be done for Auto Scaling?

---

In Amazon EC2, I want to run nginx with Node.js during EC2 startup by Auto Scaling.

EC2 is set up as an Auto Scaling group using images. I want to run EC2 Node.js applications and nginx, which are started by Auto Scaling, together with the EC2 server startup.

For nginx, I can run the executable with chkconfig , but the Node.js application will run as pm2, using the code written in package.json.

How can I run nginx and Node.js with EC2 startup and let the new EC2 -- started with Auto Scaling -- respond properly?

---

comment reply :

I don't want to run node.js using "node app.js" command.

I want to run node.js by package.json ( script )

ex.

  "start": "NODE_ENV=production PORT=3000 pm2 start server.js -i -1"

How can I do this?

Your suggestions are using linux server init script file.

But, I want to set NODE_ENV, PORT and use pm2 command.

---

solution

I solved the problem.

When Linux booted, I tried to use the script file to automatically run node.js.

I created the script file and made the shell script run automatically after linux booted, but it did not seem to be a good idea.

Alternatively, pm2 startup and ecosystem.config.js can be used to solve problems flexibly.

Thank you for your reply.

Answer 1

This has nothing to do with autoscaling. It most often has to do with the EC2 AMI (Amazon Machine Image) that the autoscaler is launching your EC2 instances with, and possibly also with the "user metadata" that you are passing to the instance when it launches. These are the only two things that impact what an EC2 instance does when and after it starts up, up until it starts communicating with the outside world.

So what you need to do is create an AMI that is set up so that the right things launch when an EC2 instance is launched from that AMI. What you'd do is take the AMI you want to use as a starting point, launch that AMI into an instance, make the necessary changes and installations you want, and then save off a new AMI. Then change your autoscaling group to launch new instances with that new AMI.

You could alternately send a script in your "user metadata" that launches things, but this is rarely what you want to do". Most of the time, you want to have your AMI do the right thing.

It's also possible that you are using some sort of post-boot provisioner, like Chef, Ansible or Chef Habitat. If you are, that's where you'd set all of this stuff up. You'd want that system to do the work you're describing. But if you're doing that, what I have said earlier still applies. For this to work, you'd often have also built a custom AMI that has parts of the provisioning system already built into it, so that that system can connect into it and provision it. It's possible for these systems to start from a generic AMI as well. It depends on the system.