How fly.io versioning works

1

Hello,

I’m running an application that uses semver versioning for tagging the docker image every time a new version of the software is released

Screen Shot 2021-04-22 at 10.39.45
Screen Shot 2021-04-22 at 10.39.45812×868 25.1 KB

This is actually done at a Docker Hub private registry and I want to move to fly.io keeping the behavior.

On the fly.io universe, a new docker image generation will trigger running flyctl deploy but I didn’t find a way to tag the version according to my semver version.

The semver version approach is mainly motivated with the ability to rollback to a determined version.

I can see how fly.io is using an internal version (currently my version is v27) for anything performed over the app:

❯ f releases
VERSION STABLE TYPE    STATUS    DESCRIPTION                        USER                          DATE
v27     true   scale   succeeded Autoscale                                                        8m15s ago
v26     true   scale   succeeded Autoscale                                                        9m0s ago
v25     true   scale   succeeded Scale VM count: ["app, 2"]         me                            19m41s ago
v24     true   scale   succeeded Scale VM count: ["app, 3"]         me                            20m10s ago
v23     true   release succeeded Deploy image                       me                            38m10s ago
v22     true   scale   succeeded updating region configuration                                    40m59s ago
v21     false  scale   cancelled updating region configuration                                    41m6s ago
v20     true   scale   succeeded Scale VM count: ["app, 2"]         me                            43m13s ago
v19     false  scale   cancelled updating region configuration                                    43m54s ago
v18     true   release succeeded Deploy image                       me                            53m6s ago
v17     true   release succeeded Deploy image                       me                            1h3m ago
v16     true   scale   succeeded Change vm size to dedicated-cpu-2x me                            10h32m ago
v15     true   scale   succeeded Change vm size to dedicated-cpu-4x me                            10h34m ago
v14     true   scale   succeeded Change vm size to dedicated-cpu-1x me                            10h36m ago
v13     true   scale   succeeded Change vm size to dedicated-cpu-2x me                            10h40m ago
v12     true   scale   succeeded Change vm size to dedicated-cpu-1x me                            10h43m ago
v11     true   scale   succeeded Change vm size to shared-cpu-1x    me                            10h57m ago
v10     false  scale   cancelled Change vm size to shared-cpu-1x    me                            10h57m ago
v9      true   scale   succeeded Change vm size to dedicated-cpu-8x me                            11h5m ago
v8      false  scale   cancelled updating region configuration                                    11h6m ago
v7      true   scale   succeeded updating region configuration                                    11h10m ago
v6      false  scale   cancelled updating region configuration                                    11h10m ago
v5      false  scale   cancelled updating region configuration                                    11h11m ago
v4      true   scale   succeeded updating region configuration                                    11h12m ago
v3      true   scale   succeeded Change vm size to dedicated-cpu-2x me                            11h21m ago

That is not necessary bad, but my question there is:

  • Can I associate some metadata with the fly.io releases? (like my internal version number)
  • In case of distaste, how I can roll back to a previous version?
2

App versions are a combination of two things:

  1. The Docker image reference, which we resolve from the label at deploy time
  2. Our internal version number

You can override the image label, which is what I would do for semver: flyctl deploy --image-label 3.1.12.

The version number is not very useful right now. These change when you change secrets, autoscaling happens, deploys fail, etc. This is something we need to improve because it makes fly release rollback more difficult than necessary.

Rollbacks are best accomplished with your CI system for now. Most people rollback by re-running a previous CI step. It’s sub optimal but it works pretty well!