Document fly.io deployment

[psonnera]

A stub is present at https://github.com/nightscout/nightscout.github.io/blob/source/docs/vendors/fly.io/new_user.md Feel free to use it Create an img subfolder to place the screenshots

[ninelore]

Consider me assigned to this.

As of now i do not recommend the use of fly.io's heroku migrator tool, as it places all enviromental variables as secrets, which is bad practise and will probably lead to confusion later on.

Optimal fly.io use requires to create a fly.toml in the fork's root for both regular environmental variables and some configuration required to make the instance accessible from the web.

I propose to to add a template fly.toml to the nightscout repo and maybe some kind of script (py, bash, batch, ps, etc) that can automate the configuration of the fly.toml.
Details on latter are tbd.

[psonnera]

Agree. We shouldn't recommend Fly.io. Not because it's bad (it's not) but too complicated to maintain for basic users. But having it documented is good to have. Thanks!

[psonnera]

@ninelore should we suggest those who used the utility to delete all secrets and re-create manually corresponding environment variables?

[ninelore]

Probably yea because it probably will cause problems when updating nightscout.

Besides the sensible login stuff i would also place DISPLAY_UNITS as a secret due to being a mandatory variable and the fact that i had some weird issues when deploying when it wasnt a secret

[ninelore]

fly.toml template so far

[waltersf]

Hi,

I was able to create a new deployment using flyctl + cloned Nightscout source code (including Dockerfile) + existing MongoDB Atlas account. Steps:

• Install flyctl, following the instructions from https://fly.io/docs/hands-on/install-flyctl/.
• Clone the Nightscout repository (https://github.com/nightscout/cgm-remote-monitor) using git to a folder (let's call it INSTALL_DIR). It does not have to be the official repo, it can be your own repo.
• Adapt the following fly.toml template and change the the property internal_value to 1337 (default NS port) and other properties according to your setup (for example, change MONGODB_URI and API_SECRET env variables).

  
  app = "CHANGE ME"
  kill_signal = "SIGINT"
  kill_timeout = 5
  processes = []

[env] API_SECRET = "CHANGE ME!" BG_TARGET_BOTTOM = 80 BG_TARGET_TOP = 180 DISPLAY_UNITS = "mg/dl" ENABLE = "careportal boluscalc food bwp cage sage iage iob cob basal ar2 rawbg pushover bgi pump openaps dbsize cors" MONGODB_URI = "CHANGE ME!" SHOW_PLUGINS = "careportal" THEME = "colors" TIME_FORMAT = 24

[experimental] allowed_public_ports = [] auto_rollback = true

[[services]] http_checks = [] internal_port = 1337 processes = ["app"] protocol = "tcp" script_checks = [] [services.concurrency] hard_limit = 25 soft_limit = 20 type = "connections"

[[services.ports]] force_https = true handlers = ["http"] port = 80

[[services.ports]] handlers = ["tls", "http"] port = 443

[[services.tcp_checks]] grace_period = "1s" interval = "15s" restart_limit = 0 timeout = "2s"

- Open a shell prompt and change current folder to INSTALL_DIR.
- In order to create an account in Fly, I issued the following command:
`$ flyctl auth signup`
- A browser window will show up. Follow the instructions to create a new account. I informed my credit card number, but I don't know if it is really needed. 
- Then, execute:
`$ flyctl launch`
- flyctl will detect a Dockerfile inside INSTALL_DIR and starts deploying it. 
- Confirm "Would you like to copy its configuration to the new app? Yes", inform the app name  and select the deployment region. Other options: "Would you like to set up a Postgresql database now? No", "Would you like to deploy now? Yes".
- After the success message, I opened my app by executing:
`$ flyctl open `

I also used the command `flyctl dashboard` to open the Dashboard and be sure that everything was working and not being charged. 

Some comments:
- I used environment variables, but, as discussed before, secrets can also be used, especially for the sensitive data, like MONGODB_URI. 
- I could use a Dockerfile with a prebuild image, but the building process does not take long. 
- I repeated the process once and it worked, but is important to test it in other environments (I tested using Windows and Power Shell). 
- When you run the command `flyctl deploy`, a new container version is created and the previous one destroyed. I can use this command to update my container when the source code changes, after executing `git pull`, for example.

Hope it helps you.

Best

[psonnera]

Just to make sure... I haven't understood if migrating from Heroku with their method uses a container and will allow Docker like maintenance of the migrated site or the option should be completely ignored... If it isn't supported I need to remove it from the documentation.

[ninelore]

Just to make sure... I haven't understood if migrating from Heroku with their method uses a container and will allow Docker like maintenance of the migrated site or the option should be completely ignored... If it isn't supported I need to remove it from the documentation.

It deploys as nodejs directly without using container, and the toml that you can copy from the migrated site with flyctl doest even work on manual deploy. Thats why i'd say ignore and remove it

[psonnera]

@ninelore got it. I will remove it from the documentation and add a warning: don't use.

[TheSamSmith]

I got fly.io working tonight pretty easily, I think for the mildly technical users it's a good solution. I did flyctl secrets set xxxx for all the secrets rather than using the toml template though which I wouldn't do if I was doing it again.

[psonnera]

@TheSamSmith deploying from scratch? How?

[TheSamSmith]

Pretty much just follow the Heroku docs, once you do flyctl launch it'll build a docker container and push it to fly.io then just set the secrets.

I'm happy to put a PR together to show this in docs if that's helpful.

[psonnera]

@TheSamSmith yes please! Thanks a lot in advance.

[psonnera]

@TheSamSmith I couldn't get that running without changing the internal port as mentioned by @waltersf at this point I'll put a fly.toml in this documentation and would recommend requesting pull in cgm-remote-monitor to have it already present in Nightscout repo. Still I want to thank you both for the indications as I know believe fly.io is a valid alternative for those who do not mind typing a few commands, really worth it.

[ninelore]

@TheSamSmith I couldn't get that running without changing the internal port as mentioned by @waltersf at this point I'll put a fly.toml in this documentation and would recommend requesting pull in cgm-remote-monitor to have it already present in Nightscout repo. Still I want to thank you both for the indications as I know believe fly.io is a valid alternative for those who do not mind typing a few commands, really worth it.

Already PR'ed https://github.com/nightscout/cgm-remote-monitor/pull/7560 Im also working on the docs but im delayed Seems you were faster

[ninelore]

@psonnera I had a look at the toml youve put into the docs. There are some thing that should be changed:

• Ive mentioned the secret feature and how it should be used. Why do you have the sensitive stuff in the toml?? That's a big security no-no
• You can move some lines that mustnt be edited below the enviromentals. Check my file on how ive placed them

[psonnera]

@ninelore whilst agreeing with you for the use of secrets, as a support resource I know people forget to write down this information and in the case of the API_SECRET recovery of all connected devices will take much more effort than reading it. Checking Dexcom credentials or MONGODB_URI will be impossible with secrets. That would make Fly.io the only deployment using this method in all available. Where can I see your fly.toml example? Not this one, right? https://github.com/nightscout/cgm-remote-monitor/pull/7560/commits/c5db358a011c704c3736c66b2f508fc2b1fafaf1

[ninelore]

While i agree to your point, they by far do not outweigh the security risks. The people you mentioning shouldn't use fly in the first place anyway.

Yes, its the right file. Note how i have kill_signal and kill_timeout below the [env] block and a comment? That ensure we have the dont-edits away from the do-edits.

[psonnera]

@ninelore noted, thanks! I believe those who are not practical with computing should use a hosted service but history says differently. Most DIYers just follow instructions and don't have a clue of what they're doing. Myself included to some extend. When it comes to support that's another story. Will you help support those stuck with secrets in Facebook/Discord ? Then I'll be glad to implement Fly.io security in the documentation.

[ninelore]

Easier support or convenience is no excuse for lacking security. Doing so anyway is gross neglience on our side.

Where do you see need for extra support? Once documented properly i dont see any problem other that what can happen with every other service.

[psonnera]

@ninelore basically you mean we should document and implement security for all PaaS providers? That does make sense indeed but this is a large modification to Nightscout DIY strategies. I would prefer it to be documented as a recommendation. I would rather change PaaS if my account gets hacked... BTW I spend most of my free time supporting users with xDrip+, Nightscout, ... and I know what happens. If you tell them to secure their site they can't manage to setup the followers. When I tried to implement Heroku safety recommendation many just deleted the authenticator app and lost access to the site as they didn't print recovery codes. At that point, the mass will take risks and nothing will happen. Just hoping those using remote bolus or overrides are smarter...

[ninelore]

Please stop making silly conclusions. The problem is with fly's design. If you put secrets in the toml you can also just post them publicly on Facebook.

[psonnera]

@ninelore please modify the documentation an PR. Thanks.

[psonnera]

No PR received. Considering this closed.

[psonnera]

@ninelore after implementing the web terminal solution as indicated by @Jackenmen I'm glad to inform you that the recommendation is now to use secrets. This wasn't a consideration linked to security but having an updated fly.toml on your PC (and not in your repo) proved too complex to handle without the flyctl utility. https://github.com/nightscout/nightscout.github.io/commit/63342321409984bdcae065d63c90089abced3bd5