I have a node app that serves HTTP requests and caches stuff in Redis. While I was able to get a basic setup working by following the guides, I’d like to automate some of this stuff as “infrastructure as code” when deploying services into test, staging or production “organisations”.
I have some questions along these lines:
There’s a dependency between the node app and Redis and as I understand, I have to maintain two different fly.toml files for them. Is there something akin to docker-compose in fly.io that allows you to declare a dependency between them and bring them up at once?
I prefer to use shared-cpu-1x VM but with 512MB memory instead of the 256MB default. Is there a way to do that automatically as part of the app configuration without running fly scale memory?
I’d like to do this because someone could forget about running that command when setting up services in a new organization. (I’m guessing the answer here is no because App Configuration (fly.toml) makes no mention of such a setting).
Along similar lines, is there a way to pick up secrets for a fly app from a dotenv file or another source, instead of having to manually enter secrets through the flyctl secrets command?
As hinted at above, I’d like to maintain seperate test, staging and production environments for my fly apps, and as I understand I’d have to maintain three different sets of fly.toml files. Coming from AWS Cloudformation where you could could dynamically change the AWS account ID without maintaining different file sets, I find this approach a bit messy to say the least. Is there a better approach that I’m unaware of?
I solve parts of the abstraction layer you’re asking about through CI (github actions); for instance, iterate through secrets and pass them to flyctl - or knowing which file to use for what environment, or releasing ip’s as part of an initial setup.
Making this more robust is probably best achieved by using their graphql endpoint to interface with; but I haven’t gotten to that point yet. It would be interesting to collaborate on a github actions project that would hande a lot of the plumbing at some point.
We have a preview feature for running multiple processes as a logical grouping in an app, but it’s not really designed for this use case. That’s more for something like a web+worker scenario.
There’s no way to do this with fly.toml, but also something we’re thinking about.
fly secrets import will import key=value pairs from stdin, i.e. cat .env | fly secrets import
Many options in fly.toml can be overridden on the command line, such as env vars. That said, if you already env vars in fly.toml and try to use fly deploy -e, a bug will get in your way.
Generally speaking, we plan to pull a good amount of config into fly.toml but only after we migrate to some newer deployment plumbing we’re working on. Happy to expand on that if you’re interested. Stay tuned!
Sorry for dropping this. The TLDR is that our new Machines feature will underpin our new runtime. A new config will grow out of our work on this as we introduce orchestration around machines.
Currently the Machines feature is in a pretty raw state. But you can already do something like “Infrastructure as Code” using them and our Terraform provider. Check out our example project to see how you could use it.
As another infrastructure as code guy, I’m afraid I need to give you bad news w/ regard to the terraform provider. Volumes are already broken, and the tf provider isn’t a priority according to the fly folks. I think it may have been taken down at this point.
The path forward might be their new kubernetes feature, if that’s going to be more than just an experiment. I’m kinda waiting to see if they’re serious about it, or if it’s just another demo. (It’s not mentions in the docs section of the site yet, and things from the blog articles tend to break)
Unfortunately, the fly/fly.toml files look like a dead-end, because they’re “1 app, 1 target configuration” at a time. And that seems to imply that flyctl is too, because it’s also fly.toml specific.
All that might eventually get sorted out if cool things are built onto the machines api (like the k8s thing, or a new terraform provider), but I read somewhere in the forum that flyctl is where the “fancy” logic is going for deployments and whatnot. And once you go to the machine level, you can never use flyctl to do updates.
There’s a lot of truly amazing stuff here. The dashboards with grafana integration is awesome. The focus on elixir (what brought me here) is cool. But there’s really no story at all for what you want.