"spin deploy": Allow deployments without CI/CD

[jaydrogers]

Discussed in https://github.com/serversideup/spin/discussions/61

^{Originally posted by **jaydrogers** January 24, 2024} # 👉 Describe the problem [comment]: <> (What are you trying to solve?) - The current version of Spin requires using GitHub Actions or GitLab CI for deployment, adding more knowledge requirements to get started - Many users getting started are very confused on how to run deployments # 👥 Problem evidence & reach [comment]: <> (How many people have this problem?) Some users have expressed interest in removing this requirement: https://discord.com/channels/910287105714954251/1195096786776359064 # 🥰 Describe the "impact" on users? [comment]: <> (How will this make people's lives better once it is solved?) - New users can deploy a server on their own very easily # 🏆 How to solve this problem [comment]: <> (Describe the feature that you are proposing and how it will solve the problem) ### Solution Overview We can reduce the knowledge requirements by allowing users to run `spin provision` (to configure and prepare their server for Docker), then `spin deploy` to locally deploy their image to their servers.  This proposed method eliminates a few headaches: - Users don't need to learn GitHub Actions or the deep inner workings on how a Docker Registry works - This configuration is a lot easier to debug since its working with systems directly in the user's control > [!NOTE] > This method is intended to be used for **very simple** set ups. For most environments, it will be recommended to use GitHub Actions or GitLab CI (or comparable) to deploy applications ### Deployment Process 1. Initialize Project (create files) 2. Configure (ensure Spin configs are set) 3. Build (ensure tag is set correctly, ensure env exists within application) 4. Transfer (use `docker image save`: https://nickjanetakis.com/blog/docker-tip-97-save-and-load-docker-images-from-a-zip-file) 5. Run `docker stack deploy` to initialize the transfer # 💯 How do we validate the problem is solved? [comment]: <> (Explain use cases on how we can measure the success of this implementation) - [x] Users can run `spin provision` (to configure their server) then `spin deploy` to deploy their stack

[nckrtl]

Hey Jay as I played this feature a bit already I was wondering what it would look like when running multiple applications on the same server. As you won't deploy generic services like traefik and redis with each application/project, would you have like a generic stack/project with stuff like traefik, redis etc, and then specific app stacks with php service(s) + appropriate traefik labels? Or would this be meant to deploy 1 app per server?

[nckrtl]

Been doing some testing, and got it working with multiple swarm stacks. 1 stack for traefik, 1 for redis, and 1 with a laravel project. What's cool about the setup is that it's really easy to run multiple web projects on the same server. Perhaps I'm misunderstanding the current situation and this is already possible, but I couldn't see how.

A couple things I ran into:

• A Dockerfile is needed when running spin deploy, while it won't be needed if your stack only consists of a treafik or redis service. So I created an empty Dockerfile that just uses a random image.
• As I intended to only run traefik and redis on production and not locally I removed docker-compose.dev.yml. But the deploy command is throwing a warning that docker-compose.dev.yml is missing.
• Also a docker-compose-prod.yml is needed, would be nice to just default to docker-compose.yml if there is not production yml.
• You need to update the production server name in spin-inventory.ini to be unique across all stacks, because that name is being used to generate the stack name. Maybe it could be supported to be able to somewhere set the stack name, so you can always use spin deploy production instead if spin deploy production_<unique_tag>

Its also important to define the network as follows:

networks:
  web-public:
    external: true

Else the stacks won't be able to communicate with each other.

All things above are probably out of scope currently for this issue/feature, but it would be really cool to have proper support for multiple docker stacks.

[nckrtl]

You can ignore my remarks, they don't really apply to the issue/feature in question. I'll create a separate feature request.

[jaydrogers]

This has been completed and released with 2.0 🥳

Thanks for your help, @nckrtl!

[nckrtl]

Nice!