Refine Fly.io deployment process

[ehmatthes]

trafficstars

Proof of concept Fly.io deployment is working, but there's lots left to do in order to ensure as few errors as possible.

• [x] Make initial Fly.io documentation.
• [ ] Prioritize refinements below.
• [ ] Implement most important set of refinements.

[ehmatthes]

Tasks

• [x] Add a .dockerignore file?! #117
  • I believe this was important in my original (non-simple_deploy) push, because it was pushing the venv. See recent blog post.
• [ ] Run with user logged out of flyctl.
• [x] Run with a user who has created multiple apps on Fly.io.
• [ ] Re-running command
  • [x] If user has attempted a push, current approach to finding app name fails.
  • [ ] Consider using flag for deployed_app_name, like in Platform.sh work.
  • [ ] Consider looking in current fly.toml file.
• [ ] Allow a flag for deployed app name. Should probably be same flag that platform_sh uses.
• [ ] Database management
  • [x] Handle the situation where a database is found better. Make a paid account, and use simple_deploy on a second app with a current one deployed.
  • [x] Reconsider when initial steps are taken, ie should we create the database after simple_deploy is added to req.txt? It may fail, so it should come before modifying the project (current reasoning).
    • [x] Would really be nice to log the creation of the database and the deployed project.
  • [ ] I may be making output_str variables that aren't ever used, ie in _create_db().
  • [x] Clarify how credentials such as db connection info is shown, and logged.
  • [x] Can easily recognize when a db with a matching name exists, ie app_name and app_name-db.
• [ ] Dockerfile
  • [ ] We can write any Python-optimized Dockerfile we want. What optimizations should this have over what Fly.io suggests? See Will's example, inspired by Jeff.
  • [ ] Parse a pre-existing docker file.
• [ ] Parse a pre-existing fly.toml file.
• [ ] Refactoring
  • [ ] Generalize the code for generating a new file from a template. Right now it's _add_dockerfile() and _add_flytoml_file(), but these methods are almost identical, and the same goes for Platform.sh files such as routes.yaml, and Heroku's Procfile.
  • [ ] Make template names consistent. Either call them ie fly_toml, fly_dockerfile, or (better) have a directory for each platform, so fly/fly.toml, fly/dockerfile, heroku/Procfile.
• [ ] Builder app
  • [ ] Builder app, created from a previous deploy, does not see secrets associated with current app. How address this? In test deploy, I'm going to destroy the builder app and hope a new one gets created.
• [ ] Seems to be working without running collectstatic; is that reliable? How are static files being managed?
  • [ ] Is gunicorn handling all of this, and it would be more efficient to set up whitenoise?
• [ ] Messages
  • [x] Review all messages for copyedit.
  • [x] Remove any Platform.sh cruft from deploy_messages_flyio.py.
  • [ ] Consider refactoring messages between the three platforms, ie success messages?
  • [ ] Use fly_io and flyio consistently.
  • [ ] Use flyctl consistently.
• [ ] Testing
  • [ ] Write integration tests.
  • [ ] Write unit tests.

[ehmatthes]

More tasks

• [ ] Make a more specific ALLOWED_HOSTS entry.
• [x] Output of fly deploy should stream, rather than being dumped after success. #121
  • [x] I believe this can be implemented using execute_command() in simple_deploy.py, instead of execute_subp_run().
• [ ] Fake, or don't call fly secrets when unit testing.
• [ ] Consider IDE-specific cruft such as .idea/ and .vscode to .dockerignore.
• [ ] Is there any indication including a .dockerignore file has any effect on the deployment process? Can I measure the impact, in image size or deployment/ subsequent push time?
• [ ] See recent blog post and recent updates to flyio docs for anything else that could be improved.

[ehmatthes]

Notes/ resources

• [ ] See Twitter discussion re psycpog2 vs psycopg2-binary, and appropriate docker images/ dockerfiles.
• [ ] Review against @wsvincent's latest tutorial.
  • [ ] Deploy the blog project using these steps, and compare the generated Dockerfile and fly.toml to what we're using here.
  • [ ] How are static files handled in this approach?
  • [ ] Does fly launch create a postgres db?

[wsvincent]

For now I'd just go with psycopg2-binary. More than enough for most projects. @webology would agree. Also, Psycopg 3 support is coming soon, maaaaybe for Django 4.2 if you just want to wait.

[ehmatthes]

Recent work addresses most of this issue.