Nowadays a lot of OS webapps run through Docker compose. PaaS doesn’t support it. Azure is supporting through the webapp resource in a preview mode. I understand one can try to set all parts separately in different VMs and set it up in the toml file but it would be a lot easier just to deploy through the ready Docker deploy compose file. I’m wondering if one day Fly.io could support it.
Perhaps. But it is complicated. But we are constantly looking at it, and there are some changes underway that may make things easier. The TL;DR is that docker compose seems best suited to development and perhaps some narrowly targeted use cases, like preview mode.
For starters, here is a demo of what you can do today: Demo running docker compose up on fly machines . I’ll warn you that it is not pretty… there is some additional setup, but the main problem is that if you run docker compose up on a fly machine, that machine is not servicing requests until that request is complete.
I’m not too worried about the additional setup… we can address that once we tackle the harder problem. Possible solutions:
- Blue/green deployment - start a new machine but keep the old machine running until the new machine is ready. The problem here is data and volumes - I’ve yet to see a docker compose yaml file without a a database and having your new machine come up with an empty database is not the desired end result.
- Temporarily run both the old and new versions on a single machine and only route requests to the new version once it passes a health check, after which point the old version is torn down. Kamal does something like this.
- Treat the docker compose file as a template but don’t actually use docker compose for deploy. Build the necessary images first then deploy then replace those steps with ones that reference the resulting image. Find a way to deploy that quickly. At the moment, fly machines run a single image, it would be helpful if we could get to the point where fly machines could run multiple images in namespaces – essentially more like containers. This is a big undertaking, but similar things are needed for Fly Kubernetes so it may just happen.
If I had to guess, the first thing you are likely to see is some sort of docker compose import function that converts your existing docker compose yaml file into one or more fly toml files that can be deployed with a single command. Once that is working, perhaps we will be able to optimize away the intermediate step (and/or make it transparent to you).
I see but a lot of OS docs projects recommends full deploy using docker compose and if you want to scale then Kubernetes.
What you’ve said in the end about yaml import or convert function would be optimal for no advanced users like me.
Can you give an example? I’ll be honest with you… that’s the conversation I would rather have, particularly as the recommendation you mentioned above seems targeted at advanced users. And at the end of the day, the goal is to be able to quickly launch and deploy an OS docs project, not docker compose.
Perhaps start a new thread on the specific OS docs project you are interested in. If it is something I can download and install, I’ll likely give it a try and make recommendations. If it works out, those recommendations will quickly (as in days, not weeks or months) into documentation and code, ideally making it possible that all you will need to do to get started is:
fly launch
I see. What I mean is that lately I’ve came through a lot of open source webapp projects documentations, especially looking into the deployment section and I’ve realized most of them works through Docker compose as their stack pulls and works through multiple images. Sometimes they recommend a Kubernetes as an option too.
But yes, if I have some specific help request I’ll open another thread.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.