Auto scaling L5 project

I think you meant Forge instances instead of Homestead instances, right?

Using AWS auto scaling, or really anything in AWS to help automate new servers, won't be compatible with Forge in its current form as there's no API, giving you no way to not add a server info Forge without some manual work.

The easiest work around to this might be to use a load balancer in Forge and spin up 2+ servers in whichever cloud you use. Keep a server shutdown until you need it - if you can anticipate spikes, you can turn on a server when you need it, and add it to a load balancer when it has the latest version of your case base.

Keeping a load balancer around even when you only have one application server makes this fairly easy to do.

Hey @fideloper,

thanks a lot for your answer! Yes, I meant Forge. As you wrote it is possible to create multiple EC2 instances, deploy my code and shut all than one down. But what if I want to deploy a new version to each instance. I have to start all instances, deploy my code, and shut them down again.

So I think Forge isn't a good solution for this. Maybe Docker would be a better approach. I could install Homestead and pull my repo from Github. But what about the .env file? What about different environments (staging, testing etc.) and what about deploying different branches than master?

Do you have some articles about this topic on serversforhackers.com?

Thanks a lot! Maybe we can start a new project here which simplifies all of this stuff?

@bart I guess you could take a snapshot of a ec2 server setup made by Forge and then use the autoscaling rules within AWS while having them coupled to an AWS load balancer?

@bart We do this for several of our clients & projects, but it is not a simple solution. We use Jenkins to build new AMI's each time that code is pushed into the repo. We then use cloud formation to stand up new servers behind the ELB with the new AMI.

We actually use this process to do our server/os updates as we build new machines at minimum every 3 days.

I'd be happy to talk with you about this, but it is a very involved process that we have been tweaking for about 3 years.

Hey @jimmy.puckett and thanks for sharing the main idea behind ya stack. I did some resourcing during the last couple of days and in my opinion I found a good and simple way to deploy Laravel apps on AWS EB. Due to the .ebextensions folder it's pretty simple to customize the deployment process, running commands like artisan migrate, setting environment variables, loading files from S3, installing additional packages and so far. You could create different environments which run an own stack of instances each. In that way you can achieve different deployment states like testing, staging and production. What do you think? Does it sound like a good idea?

@bart Ya, we have looked into that, but we do a good bit with credit card processing (PCI), and we have to have some specific controls in place, so we actually build our boxes with very specific configurations like no ssh. We just find that jenkins gives us more control.

Sounds like you have a great solution for your needs!

https://pionect.nl/autoscaling-aws-laravel-codedeploy-opsworks-chef-automation/