I have to restart a deployed app when one node in the cluster(2 nodes Active/Passive) goes down, how do I handle a node failure and then restart the app?
I'm using mod_cluster for hot_standby and load balancing.
You cannot restart the application server from the balancer if that is what you are trying to do?
If your App has crashed or become undeployed you could have a crontask that runs on the server and checks the status of the App
If you are hosting in a cloud environment (eg. AWS) you could use the EC2 API's to reboot any instances that have become unresponsive from the balancer
Related
I created a Node server that receives events through webhooks, handles them, and posts their data to one API endpoint. Currently I'm deploying it using AWS Elastic Beanstalk, but I don't know if it's the best option.
I don't need load balancers.
I don't need web servers like Apache/Nginx.
My Node server does not have any ports to receive requests, since it's a simple server that only handles webhooks events. So the EBS service will always be without metrics for requests (severe health status - because doesn't handle any of the health requests).
Should I use another type of AWS service? Docker?
Finally, I went for it with the App Runner AWS service for running containers. No load balancers, just elastic sizing. No web servers.
I cannot get my React app running on an EC2 Instance after deploying with CodeDeploy.
I have 3 Amazon Linux EC2 Instances running: Production, Staging 1, and Staging 2.
The Staging servers are imaged from Prod and all are running the same code. Our stack is a Node backend with React on the front.
Staging 1's deploys are managed by CodePipeline/CodeDeploy. The Node server runs and I can query the back-end API, but it isn't serving our React app. Trying to access the front-end URL via browser/CURL will time out. Staging 2 and Production work without issue.
Traffic is forwarded to the port the React app is running on via "proxy": "http://localhost:5000/" in the client's package.json.
I'm wondering what configuration the CodeDeploy agent could have changed to disable access to ports and proxying between React and Node.
Any demystifiation of what the CodeDeploy agent actually changes on an EC2 instance, or other potential cause would be a huge help. Thanks!
I am using pm2 to deploy nodejs apps to production. Currently all apps are running in the same host. But I am going to put a few apps to a different hosts. I know pm2 support deploying to multiple servers by defining host in an array such as: "host" : ["212.83.163.1", "212.83.163.2", "212.83.163.3"], But this approach will deploy all apps to all hosts listed in this array. How can I deploy some apps to one host and other apps to another hosts?
In addition, it would be good if pm2 support master-slave mode. I have checked pm2 cluster but it doesn't seem to work in a cluster of hosts mode. It is more like a cluster of nodejs processes in one host.
I want to deploy a WCF service that utilizes net.tcp port sharing. When running on a normal Windows Server, I make sure that the NET.TCP port sharing service is enabled and running and my application launches without any issues.
When switching to Azure Service Fabric, this service is not running on the node and my application cannot start. How do I make sure that when I deploy my application to a node that the node has WCF.s NET.TCP port sharing service installed and enabled?
We deployed a Node.js Azure Web App and defined a minimum of 2 instances (for scalability and high-availability).
It seems like the LB is balancing the load between the instances, but it doesn't react on instance error (crash) and seems to insist balancing the load between all the instances including the one which crashed.
Is there a way to set a fail-over mechanism for high-availability?
The load balancer used by Azure App Service will continue to send requests to individual web servers as long as the underlying virtual machines are up and running.
To workaround the issue you are running into, you can try configuring the "auto-heal" feature. If the scenario is that the app gets "stuck" in a permanently broken state, auto-heal rules can be configured to automatically restart the app.
More details on auto-heal here:
Auto-heal for Azure Web Sites