EasyEngine v4 – First Release Candidate

We finally have a first release candidate for EasyEngine v4 tagged RC1.

This release adds support for migrations between EasyEngine versions seamlessly.

You can start testing on a fresh VPS. Currently, we support a limited operating system that includes Ubuntu 14.04, 16.04, 18.04 and Debian 8. Please run the following command:

wget -qO ee rt.cx/ee4 && sudo bash ee

You can find the detailed instructions, here.

What has changed?

  • Seamless self-update for the next EasyEngine version
  • Support added for global mysql and redis
  • Logs and Confs now made available under site root
  • EE shell is now supercharged
  • Auth command now has the whitelisting option
  • Some commands have been renamed to ensure their consistency
  • Minor bugs have been fixed

Seamless self-update for the next EasyEngine version

You will be able to update to next EasyEngine versions just by running ee cli update. This includes the stable as well as intermediate updates, such as, RC1 to RC2 upgrade. 👋

The ee cli update command automatically updates sites for changes, related to that command. For e.g. PHP container has an update, say a security patch, ee cli update will ensure that all sites using PHP get updated to the latest container image.

Changing the container image on a running site may lead to a downtime of a few seconds, in some cases. Therefore, please plan your update carefully. Ideally, do it when the server CPU load is low.

If you have a large MySQL database, then restarting MySQL will have its own latency. The MySQL restart time is in no way related to EasyEngine or Docker it uses.

Ofcourse, MySQL will not restart all the time, but, only when there is an update available.

Support added for global mysql and redis

Before this release, all sites created with EEv4 had their own mysql and redis container. Redis is used for WordPress sites when full-page caching is enabled.

This was becoming a resource hog. Hence from this release, by default, all sites will use a single global database container and single global redis container.

However, if you wish to have separate mysql or redis containers for a site, you can do that by passing a flag during site create

ee site create example.com --type=wp --local-db --with-local-redis

Logs and Confs now made available under site root

Now, each site’s PHP and Nginx configuration as well as log files are available under each sites’ root folder.

Earlier, many of them were only present in containers, hence, you cannot see them directly on your filesystem. However, now you can easily view and even edit them per site.

For a site such example.com, logs & confs will be accessible from following paths:

  • PHP conf => /opt/easyengine/sites/example.com/config/php-fpm
  • PHP logs => /opt/easyengine/sites/example.com/logs/php-fpm
  • Nginx conf => /opt/easyengine/sites/example.com/config/nginx
  • Nginx logs => /opt/easyengine/sites/example.com/logs/nginx

Also, configuration and logs of global services like nginx-proxy, mysql and redis are now mounted at /opt/easyengine/services.

EE shell is now supercharged

We have updated ee shell command to add three things.

Non-interactive command execution

You can use --command parameter to specify a command to be executed inside the container. Following is an example where we check the integrity of the core WordPress files without starting an interactive shell, using normal ee shell command.

ee shell example.com --command="wp core verify-checksums"

Specify containers

Each EE site, except HTML site, has at least PHP, Nginx and Postfix containers. Depending on the way you create a site, the site might have MySQL, Redis and/or Mailhog containers associated with them.

Until now, every time you ran ee shell, you used to exec shell inside PHP container, except for HTML site type.

Now, you can specify a container using --service parameter such as:

ee shell example.com --service=nginx

Specify user

Each docker container has a default Linux user. For PHP & Nginx containers, it’s www-data.

For MySQL, Redis, Mailhog, and Postfix, the default user is root.

You can specify user via --user parameter such as:

ee shell example.com --user=root

Combing these new parameters

You can combine these newly introduced parameters in any way you like. Such as:

ee shell example.com --service=nginx --command="nginx -t" --user="root"

Auth command now has the whitelisting option

Auth command in EEv4 now has the option to whitelist an IP, as it was in EEv3.

You can use the following command, which will whitelist the given 2 IPs from auth. You can pass any number of IP addresses, separated by a comma.

ee auth create --ip="172.0.1.1,172.0.1.2"

Some commands have been renamed to ensure consistency

We ran into one of the two toughest problems of computer science, during this project, many times! We have fixed the naming issue upto some extent, hopefully. 🤞

The following commands were renamed:

  • ee admin-tools up => ee admin-tools enable
  • ee admin-tools down => ee admin-tools disable
  • ee mailhog up => ee mailhog enable
  • ee mailhog down => ee mailhog disable
  • ee cron add => ee cron create

Minor bugs have been fixed

  • Site delete now deletes site auth, cron jobs, redirection configs and purges object as well as page cache, if any.
  • Site command –cache flag during site creation now enables object cache and also adds the nginx-helper plugin, which helps purge page cache.
  • Update default database charset to utf8mb4
  • The real IP of users is now correctly forwarded to site’s nginx
  • Rename cache keys (full-page cache and object cache now have a separate key prefix)
  • You can now run cron as a specific user
  • Change wp cron event run to 1hr instead of 5 mins
  • All global services have been added into docker-compose.yml
  • The installation of admin-tools have been made faster by switching to a zip based installation, instead of the installation method with the previous composer.

Status

We understand that the final beta to the first RC, we took more than a month. But since v3 to v4 is a big change, we want to test v4 on our own sites first. We believe in dogfooding! 🐶

We tagged RC1 and have already moved many of our sites, including this one on EasyEngine v4.. 🎉

We might need one last RC before we can have 4.0. While we will not announce the release dates, we are optimistic about a mid-November 4.0 release.

Start Testing

The only way we can improve quality of final EasyEngine project is by testing early and testing as much as possible. So please test EasyEngine and send us all the feedback you can send via Github issue tracker.

Link: EasyEngine 4.0.0-rc.1 release

3 responses to “EasyEngine v4 – First Release Candidate”

  1. Thanks so much guys, now I can stop checking your site every five minutes for the update 😉
    Looking forward to trying this out!!
    Tamhas

  2. So I just spun up a quick website with this using the. . .

    ee site create example.com –type=wp –cache –admin-user=blah –admin-pass=blah –ssl=le

    NGINX Helper is installed, WP Redis is installed. but I’m only getting cache hits on the frontpage.

    I went in and created a number of garbled test posts, opened up the site in Chrome’s incognito mode, went into the Network tab of Chrome’s console and started browsing the site.

    The Homepage shows. . .
    x-srcache-fetch-status: HIT
    x-srcache-store-status: BYPASS

    as it should. . .

    but any posts that I have created shows. . .
    x-srcache-fetch-status: BYPASS
    x-srcache-store-status: BYPASS

    Is this a known bug and to be expected since it’s RC1? Or do I not have something setup properly?