I would add an haproxy in tcp mode container to farm reqs to either online/offline container
have the nginx offline container mount the same SSL volume so you don’t need to fuss with running lets encrypt in cron and simply have existing template run it
have a data container so I can bootstrap while online
nginx proxying to nginx is tricky to get right, for example the setup here is restricting uploads to 2 megs, but plenty of other caveats
So it looks like @sam is pretty strongly opposed to the current approach, and looking at how difficult it is to get a newly compiled Nginx on Ubuntu 14.04 with OpenSSL 1.0.2 support (absolutely required for http/2 to work), I tend to agree. @mpalmer says Ubuntu 14 will never get a new version of OpenSSL in any form via apt-get, and 1.0.1 is end of life in December of this year.
(Is it possible to copy the nginx binary from Ubuntu 16 to Ubuntu 14? Does that work? That might be simplest, if it does…)
Anyway, it looks like we need another container here, a container that holds Nginx to do the routing and so on.
Doesn’t look like it; the package dependency for, ironically, libssl1.0.0 is the sticking point. It might work, if the ABI extensions in libssl1.0.0 aren’t relied upon, but it’d be a risky thing to try in general. I recommend a separate nginx-only container.
This change seems to cause problems with https redirects for logins, too – even with use https (force https) checked. After instituting the nginx outer layer with https, I had to:
enable http return URL for Google logins
enable http return URL for GitHub logins
Otherwise you get errors, e.g.
(github) Authentication failure! redirect_uri_mismatch: OmniAuth::Strategies::OAuth2::CallbackError, redirect_uri_mismatch | The redirect_uri MUST match the registered callback URL for this application. | https://developer.github.com/v3/oauth/#redirect-uri-mismatch
These are problems I didn’t have when the site was using Let’s Encrypt inside the container…
@fefrei I am not sure this is needed, because I just rebuilt talk.commonmark.org using the standard web updater. I had two browser windows open:
Home page of site in one window, in anon mode
/admin/upgrade rebuild process going in one window
I mashed f5 like an insane in window #1 and at no point during the rebuild was the site unavailable to me as an anonymous user hitting the homepage. Screenshot proof:
This is in place to serve a message during rebuilding and the following boot-up – web upgrades should always be fine
(It may not be worth it for a stable stock site. I think it’s definitely worth it if you either already have to use a nginx reverse proxy for another reason, or if you rebuild often, e.g. to install or uninstall plugins.)
I agree, as long as this is the only reason for a front-end nginx instance.
If you need to have that for some other reason, you can start with the Create an error page section – the rest is really straightforward. (And if you need to set up a front-end nginx, I think these steps are easier to follow than these instructions.)