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 --command
ee shell
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.
Thanks so much guys, now I can stop checking your site every five minutes for the update 😉
Looking forward to trying this out!!
Tamhas
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?
@alphapress as per your comment here: https://easyengine.io/blog/v4-beta-6-admin-tools-mailhog-auth/#comment-224040
if you want to clear the Global Redis cache on V4 ee just use the redis-cli executed inside the docker container.
docker exec -it ee-global-redis redis-cli FLUSHALL