We got ours fixed, ignore me 🙂
Nothing to do with AWS, someone had changed our nGinx config and not told me.
thanks @julian Beanstalk is just configuring an EC2 ( among other things) so I can't see why it wouldn't work. Does the actual files that end up on the EC2 include the entire structure that can be seen in say Visual Studio code or are they a small subset?
@tango The NodeBB git with the installed dependencies, plugins, completed config.json, and compiled sources would be the entirety of what is in your application instances. All other data would be stored in the database or external storage. Which for EBS would mean an Elasticache Redis and an S3 deployment.
(Although, I'm not entirely sure what the benefits to this setup would be over a standard vps.)
Thanks @yariplus for your valuable feedback. So would one have to perform a ./nodebb build? Your other comments has now got me thinking & makes sense. I guess I was thinking that the fully managed features of Beanstalk can pretty much be manually configured anyways....
I'm going to write a guide on setting up NodeBB on Elastic Beanstalk. I spent more or less a day installing and researching this setup. The process is fairly straightforward, although lengthy and not well-documented IMO.
My initial thoughts were that Elastic Beanstalk would be total overkill and not worth the price premium. The cost is about 2-4 times the cost of a VPS per thread. Also, the vCPUs of an EC2 instance are not the same kind of performance as a dedicated VPS instance. However, I was pleasantly surprised with the setup overall.
The forums that would benefit the most from this are forums that see modest traffic during a regular schedule, and large traffic spikes at known times. A single NodeBB instance (thread, t2.micro) can handle roughly 100 concurrent requests at peak performance (according to my tests), while a modest VPS with 4 processes might handle 400 concurrent requests. While the EB instances cost more, they can scale up to an almost unlimited number of instances, and scale down to the lowest cost when at low traffic. So, you could use 2 instances during slow times, and 8 instances during peak times, at a much lower cost then an 8 thread VPS.
This can be VERY beneficial if you have known traffic patterns or planned events. You can schedule minimum and maximum instances based on times, cpu load, users, traffic, and various other things. Scaling is very slow however, so scheduling by time is always the best option.
There are many options to the setup as well. Such as using larger instances with more process per instance. Giving a higher cost per instance, but more users per instance and smoother scaling.
@tango said in Installon AWS Beanstalk:
So would one have to perform a ./nodebb build?
This is how I did it. You could add the build setup to the startup command, but it makes more sense to prebuild, as the instance generation will be that much faster.