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.