At the moment i wait for API to complete before starting DB then after DB i start Admin. If any one of these fail then the deployment stops at that point. This raises a number of issues such as if API deploys successful and DB fails then i need a way to roll back the API deployment. Secondly while Admin is deploying the old/existing version will be using the new API and DB version which i don’t really want.
Is there a way to pre-check or group deploy to ensure these three build one after each other but actually all deploy/switch over at the same time?
I know someone is building a CI/CD for fly specifically. I can’t find the URL now to share, but don’t know if it support group deploy / monorepos at all.
I use a monorepo and have a similar setup, except my frontend and backend admin are all Sqlite, so no separate DB. But all migrations and changes to data happen with Admin first.
Right now, Admin is deployed first via CLI. I have not built GitHub Actions or any pipelines yet to handle the monorepo deploy.
But my thought would be that I would have different states. I would deploy Admin, run tests that would validate what is expected, and then automatically move to the next stage.
This would all be outside of Fly.io. The fly command line only knows how to deploy a single app. With the exception of using Process Groups.
The downside of process groups is that they share the same Docker Image. Maybe you can use Dockerfile Stages to “fix” this shortcoming.
But I am not sure the [build] supports process groups yet.
I did play with process groups a bit in the past. They are really neat.
I DO THINK they deploy in a static order.
[processes]
web = "bin/rails fly:server"
cron = "supercronic /app/crontab"
So web would deploy first, and then Cron. They are deployed as seperate VMs, so almost like seperate apps. But they have the downside of being a little quirky with what is supported in fly.toml.
I am using a mono-repo along with github actions but each project mentioned above has its own fly.toml file along with its own instance, which i think is good practice so i can scale etc. I dont think trying to put all my services into a single Docker container is a good idea and feel overall i have a good setup, its just the deployment of it if not ideal at the moment.
To be clear, the process groups are deployed as separate VMs, and can scale independently, you specify the process with scale commands. The only downside is that the Dockerfile has to have everything installed to run all three apps, even if the entrypoint only runs one.
I looked over process groups, I think this is basically what I am after. Question tho, i have my API service and Admin page at the moment within the admin project it makes network requests to the sub domain of the API (which has its own decimated v4 and v6 addresses) if they are part of the same app but different machines is this optional or should inner app communicate look different?
@Zane_Milakovic once again thanks for your help. I re-read over my message and think it maybe a little unclear. The admin page communictaes with the API service via public network requests (window.fetch from a browser) hitting a public facing API. Im assuming that the <process_group>.process approach won’t work in this scenario?
But every process group is kinda treated like a separate application, where you need to define the port it’s listening on.
So three options that I can think of -
Choose a port, and define the service for that backend to use, like https://myapp.fly.dev:3000. I could not get this working with HTTPS when i did it, but I believe you can.
If you have a main app, that has a server, you can have that app proxy requests, so https://myapp.fly.dev/api/ proxy requests to the backend application.
Setup Nginx or similar as a reverse proxy as the entry point application, and have that handle proxy requests to downstream.
For all three of these, there are examples in the community forum here.