This is a description of the process that I've been using to get applications running on Fly with a minimum of changes.
The first stage is actually in Heroku, do any version upgrades to dependencies or language runtime as you would normally do on Heroku. I think this makes everything easier rather than trying to upgrade anything while also trying to sort out the deployment.
This may not affect you but I had the dependency psycopg2 in all of my apps and only psycopg2-binary seemed to work during the image process because the postgres client cannot be compiled. I'm not sure why this worked on Heroku.
Once you have an app on Heroku you're happy with run flyctl launch and choose your preferred options. This will create the fly.toml file which will be used by the CLI for the next commands. If you don't have it you have to specify your application name with the -a parameter.
The setup process will ask to overwrite the Procfile and as far as I can tell you should just not let it and keep your current one.
Now divide your Heroku environment variables into things that are actually secrets (such as API keys) and variables that are just settings. The latter can be placed in the environment section of the fly.toml file.
For the secrets you can import things you don't want on the command line by creating a file with each line in the form NAME=value and then run cat secrets|flyctl secrets import. This will trigger a deployment which will be deferred until you've actually uploaded the app code.
Everything else can be set with flyctl secrets set NAME1=value1 NAME2=value2 .... Watch out for any UNIX substitution that may occur and use single or double quotes on the values as needed.
Now run flyctl deploy and the application should have an Docker image built and deployed. So far most of my launch failures have been related to not having the right Procfile or environment setup. Use flyctl logs to try and work out what is causing any errors.
As of CLI v0.0.429 I have actually had a pretty Heroku-like experience of importing a project and pushing changes and new versions without having to worry too much about the deployment environment. Unlike my earlier experiences.
I haven't tried setting up a database as part of this process as I choose to migrate all my databases before I started working on the webapps.
Top comments (0)