search

intercity / intercity-next

Web control panel to deploy apps on your servers (with Dokku)
https://intercity.io/
MIT License
116 stars 23 forks source link

Initial Enable LetsEncrypt widget on domains page for app #260

Closed michiels closed 5 years ago

michiels commented 5 years ago

This PR adds the main core functionalities for enabling, disabling and refreshing LetsEncrypt on an app. It uses the official Dokku-LetsEncrypt plugin to do all the heavy lifting under the hood.

Here's a breakdown of the functional items, and then a caveat list of things to improve within this PR or outside.

Components in the PR

Enabling LetsEncrypt

To enable LetsEncrypt, a user can click the button on the "Domains" screen of their app. When enabling, we first check if LetsEncrypt is already enabled for the app. This is needed when someone already has LE enabled manually on existing services, and then uses this feature.

If LE is already enabled, we don't fire the job but we do set letsencrypt_enabled and letsencrypt_email are set on the App.

If LE is not yet enabled, we run the EnableLetsEncryptJob that:

  1. Installs the Dokku plugin
  2. Adds the Dokku LetsEncrypt cronjob so that auto-renews will happen.
  3. Runs dokku letsencrypt <appname>

Whenever something goes wrong we currently have no intelligent way of checking that. So currently the user will have to figure this out themselves.

Refresh LetsEncrypt

When LE is enabled on an app, we show a button so that the user can refresh LE for their app. This is useful to trigger after a domain was removed/added or DNS was changed for example. This simply runs dokku letsencrypt <appname> again.

Disable LetsEncrypt

There's a button that allows you to disable LetsEncrypt for the app. It fires off the DisableLetsEncryptJob that:

  1. Runs dokku letsencrypt:revoke <appname>
  2. Unsets the DOKKU_LETSENCRYPT_EMAIL on the server.
  3. Sets letsencrypt_enabled on the App to false

Caveats

No status reporting/failure fallbacks yet

We don't really have a system in Intercity yet that allows us to check if commands were run succesful or even if they were in progress and with which result they succeeded or failed. So a big issue we'll have to solve is provide better feedback to the user wether LE is enabled and figure out some way of updating the UI while the LE jobs run.

For this feature specific we could add a column letsencrypt_status or something like that so we can at least report back to the UI what the status of LE enabling is. This allows us to create a simple poller that updates our UI.

A more future-proof way would be to start logging command outputs and reporting back to a more sophisticated "command executor" so that we can use those entries to add a poller to the UI which will always show the latest status of commands that run.

When DNS is not set up correctly, enabling LE silently fails

When we enable LE, all we do is add the DOKKU_LETSENCRYPT_EMAIL to the app and attempt to run LE. If something fails during this run (for example DNS records not set up), we don't show that to the UI. So we do show that LE is enabled for the app (or at least configured).

Related to previous topic.

Todo

michiels commented 5 years ago

@jvanbaarsen I've seen your comments! Lots of them already on my list. I'll remove [WIP] when it's time to do a detailed code review too.

michiels commented 5 years ago

@jvanbaarsen I updated the PRs code and wrote an extensive overview of what's included. Added a "Todo" heading. Apart from the open points in our discussion and adding tests, I'm curious if thjs PR is already good to go as initial iteration for this feature. We can then iterate on follow-up PRs on this baseline.

michiels commented 5 years ago

Going to merge this in and will iterate on subsequent PRs!