Final update here: I’m walking away. The server wont load the containers, error messages below. The ee4 docker implementation is too brittle to use. For fresh installations it may work ok. For real world, it seems like it needs some development and bug fixes to be usable. Documentation is super shallow. This product is not ready for production use, imo. I admit I only have superficial knowledge of docker, but EE does not trap error conditions or recover gracefully when there are problems. See you all in a year or so.
Best advice for anyone: take frequent snapshots! Working installations broke on me when I rebooted. Good luck.
I may be able to help a bit, since I just did this 3 times. I basically compared how the ee4 migration script works and a couple of websites with instructions. Bottom line: if you can move the source server WP site database and the source /htdocs/wp-content to the target server, in theory, you’re done.
But there are few wrinkles. I found the easiest way to move the database was to open PhpMyAdmin or Adminer (my choice) on both servers, then on the source site dump the database SQL to the screen, then just cut and paste it into the target site and run it in a SQL query window TO A TEMPORARY DB NAME. That way you dont have to re-run it if there are any problems. Then on the target database DROP all the tables except wp_users and possibly wp-options.
Then copy all the other tables from the temp database to the target database.
These are the wrinkles:
If you overwrite the users table, with the old users and passwords, you may not be able to log in. As long as you don’t stomp on the new user ee created for you, you should be fine.
Regarding the wp_options table, I found that the target WP site did not always write/read properly. So in my case, I kept both the wp_users and the wp_options tables of the target site database, then I hand configured the rest of the way. You may want to compare contents of the source and target wp_options files, and just copy over a few of the theme configuration records… that partially worked for me, but in the end it was less work to just hand configure the new site.
the underlying assumption that you can just move database tables between source and target databases is that they are the same DataBase version. I got caught on this 2x. At some point after the tables are moved, and a reboot, WordPress will compare the database version number in the database vs what is in
/wp-include/version.php and then it will force you to a dialog box saying that there is a DB version mismatch, and you should click OK to “upgrade”. screenshot below. If you click OK, WP will hang at that point and EasyEngine wont load properly on reboot. Big problem.
Solution: upgrade wp version on source site, or do this https://stackoverflow.com/questions/17308436/wordpress-error-database-update-required/23506630
Regarding the website directory /htdocs/wp-content: if the versions of WP are close enough, or the same, then it should work fine. If the source and target versions are not too close, then you may have to merge the subdirectories to be sure you dont remove things the newer version needs that the older version doesn’t have.
Good luck, YMMV.
root@eta:~# docker info
Server Version: 18.09.1
root@eta:/opt/easyengine/services# docker-compose up -d
Creating services_global-redis_1 …
Creating services_global-nginx-proxy_1 … error
Creating services_global-db_1 …
Creating services_global-redis_1 … done
ty on endpoint services_global-nginx-proxy_1 (34810441eca136fd3bfdd3e14474bf824d05e7d37076d41814fc3158083c2ab1): Bind for 0.0.0.Creating services_global-db_1 … done
ERROR: for global-nginx-proxy Cannot start service global-nginx-proxy: driver failed programming external connectivity on endpoint services_global-nginx-proxy_1 (34810441eca136fd3bfdd3e14474bf824d05e7d37076d41814fc3158083c2ab1): Bind for 0.0.0.0:443 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.