We have just released EasyEngine v4 Beta-3. We’re thankful to the people helping us in whatever capacity they can by suggesting ideas, testing our beta releases and reporting bugs. This beta release fixes issues found in beta-1 and beta-2 releases and also introduces a few features. Please leave us helpful comment or report issues on our GitHub repo.
You can get started on our currently supported OSs (Ubuntu 14.04, 16.04, 18.04 and Debian 8) using –
wget -qO ee rt.cx/ee4beta && sudo bash ee
We repeat, v4 is not ready for production. For instruction on how to install on currently unsupported distributions, please see installation instructions.
Notable New Additions
Port from Traefik to jwilder/nginx-proxy
- This is one of the major changes that took us some time to figure out as we tried a few existing solutions like jwilder/nginx-proxy, Traefik and Fabio. After taking a look at all their pros and cons, we decided to stick with jwilder/nginx-proxy due to few of reasons. First, Nginx is something we love and understand. Secondly, we found a number of issues with all three of the tested tools.
- The problem with jwilder/nginx-proxy was that it didn’t have support for letsencrypt. More on this later.
- Traefik has both static and dynamic config and a few of the most important settings for running EasyEngine was to be added to the static configuration and for Traefik to reload the static configuration meant restarting Traefik. For exampe, if we had to enable HTTPS for one WordPress MU subdomain site, for which we’ll require wildcard SSL, we’d have to restart the Traefik reverse proxy and all other sites on the server would go down.
- Fabio is a powerful service which lends itself to the containerized services wonderfully. But Fabio in turn has a dependency on Consul and that would require us to modify the application WordPress itself. Moreover, Fabio along with Consul might be useful for high availability but for our requirements, it did not fit well.
- So we thought, if we had to make modifications, we should make those modifications to a tool that has support for most of the capabilities we require as well as is easy for us to work with. So we added support for LetsEncrypt in jwilder/nginx-proxy but we are maintaining our own fork of it – easyengine/nginx-proxy
Add Letsencrypt support
We have added letsencrypt ssl support for single as well as multi-site types.
- We’ve used acmephp to implement letsencrypt integration. We chose it over certbot as acmephp is a php library which allows us more control and hence it integrates better with EasyEngine. In the process of integrating it, we also contributed to upstream by fixing some critical issues.
- For the single wordpress site as well as Subdirectory wordpress sites, EasyEngine issues certificates using the http challenge method. Hence, only input need from user in this method is an email to register on letsencrypt which can be passed using `–le-mail=<mail-id>`, or by saving the value of `le-mail` in `/opt/easyengine/config.yml`. If neither is done then EasyEngine will prompt for email only first time during site creation. After that it will read from config at `/opt/easyengine/config.yml`
- For Subdomain multisite creation, EasyEngine uses dns method to generate wildcard certificates. For now, users will have to manually add TXT records as displayed during site creation and then run `ee site <site-name> le` to complete the certificate checks and generation. This will be automated in later versions as we add support for multiple DNS providers, through the use of API. This is something where the community can help. We might add Cloudflare support before the stable release as it is a popular provider.
- You can use `–letsencrypt` to create SSL sites.
# Install wordpress with letsencrypt ee site create example.com [--letsencrypt|--le] # Install wordpress subdomain with letsencrypt (wildcard certs) ee site create example1.com --wpsubdom --le # After adding the TXT record you need to run ee site le example1.com
- Find more examples in the README https://github.com/EasyEngine/site-command/
Tag all EasyEngine Docker images
- Add image tagging to ensure that proper images of EasyEngine are pulled and used according to the version of EasyEngine being used by the user.
Other issues that have been fixed are
- Add confirmation to the delete commands.
- Improve v4 installation script
- Pick an ORM library for EE’s SQLite DB and Migrations
- –letsencrypt to work without adding www domain to DNS
Release Link: v4.0.0-beta.3 release
Is there a way to purge the Redis cache in this beta?
We’ll currently configure the https://wordpress.org/plugins/nginx-helper/ plugin with the cached site, you can expect this the next beta release. Also we’re planning a different way to handle things in v4 than the nginx-helper plugin so some improvements are underway.
When trying to install the theme in WordPress I get a “413 Request Entity Too Large” from nginx/1.13.12.
Normally would just create a local php.ini, add some directives into the wp-config.php file, but I haven’t got my head around the way Docker handles things yet.
We’re already aware of this and have fixed this. Also as for editing configuration files, we’ll have the files available in the
I updated EE to the nightly release and restarted the container, but the problem remains. Is there a simple edit somewhere that will fix it?
Apparently it requires this patch — http://nginx.2469901.n2.nabble.com/attachment/7582554/0/patch.expect.txt — and that’s definitely above my pay grade, so I will wait [impatiently] until you’ve fixed it..
1) ee presented two different _acme.challenge txt records for the same domain
2) both “_acme.challenge” and “acme.challenge” can be entered but don’t work in a DigitalOcean zone file. The txt value is invisible to the challenge and to external dns probes. Only the domain name is accepted by the DNS but then the challenge fails
3) as a result “ee site le domain.tld” fails
Maybe the underscore in the hostname is the problem…
A “name” (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of “domain style names”. (See
RFC-921, “Domain Name System Implementation Schedule”, for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period.
The Github Issue tracker is a good place to track such an issue. 🙂