Spin's Deployment Architecture with Laravel.

[danmatthews]

Hey Jay et al!

I feel like these are things that haven't been covered by existing documentation, but please feel free to point me to the docs (RTFM, Dan!) if they have.

I also feel like a lot of these questions will be critical in guiding Laravel-ecosystem devs into using Spin + Docker Swarm if they're not already.

The reason i'm super interested in Spin is that i've been weighing new deployment options for an app at work recently, it needs to be resilient and potentially auto-scalable, but i'm aware spin doesn't automatically cover that.

How do deployments with spin handle load balancing?

(apologies if this is a docker swarm related question more, but i believe you'll be asked this by a bunch of folks moving from more traditional deployments).

In a traditional environment, i'd have a load balancer (nginx, apache or maybe HAProxy), this would sit on one server IP, and 'balance' / delegate web requests to different servers depending on the traffic.

Spin appears to provision your desired server as a 'manager' server in docker swarm, does this mean that the manager servers act like the load balancer, and can delegate work to 'worker' servers in the swarm?

If so, how does that translate to 'accessory' services like Redis, MySQL etc? Do they also run "primary" services on the main server, then use swarm to scale those out?

Lastly, can I deploy spin behind a load balancer and still take advantage of everything it offers?

Storage

If you're not using S3 or something, how does spin handle local filesystems?

How does deploying "queue worker" servers work?

In our infrastructure plans in the past, we've provisioned servers with just PHP that runs Laravel Horizon or queue:work to act as worker servers.

With docker, I had planned to build two images from our repository: one for 'web' and one as a 'worker' image that would simply run horizon.

With spin, would this be possible, or even necessary?

Scaling.

I know that "autoscaling" is a vast topic that we won't touch here, but it would be good to know if there are some hooks that spin, or swarm, has that we could potentially use to trigger autoscaling logic.

But planned scaling: I assume would involve adding extra hosts to the swarm, how would Spin handle this? adding the extra hosts into your config files and running a new deploy?

Zero downtime deployments

I also see in the feature list that zero downtime deployments - is this a feature of swarm and rolling restarts? Does it essentially work by restarting each host individually so that the new code comes online one container/host at a time?

Can we also add commands to run on each deploy like migrations, storage symlinking etc?

[tonychuuy]

I'm interested to know how queues are restarted, does the deployment process wait until any job is finished in order to reload the docker images? AFAIK if you reload the image and restart the docker containers any process in the old container is killed right? Am I understanding this correctly?