WordPress Docker Build & Deploy Wizard 🧙

A makefile-managed all-in-one development system for scaffolding, pushing, pulling, and syncing databases and files to and from local and staging and remote servers. Phew.

Currently in use on a Dokku-powered Docker-ized WordPress installation.

Minor modifications would be required to generalize it for use in any environment.

Requirements

• A fresh installation of Ubuntu 18.04 x64
• The FQDN set
  • Run sudo hostname -f to check if the system has an FQDN set
• At least 1GB of system memory
• A domain name pointed at the host's IP (optional)

Use

Make Commands (local)

Commands sourced from Makefile.

make build clones repo from https://github.com/WordPress/WordPress using variables within .env and configuration files within config and deploys it to a (Docker container running heroku-buildpack-php using the a gliderlabs/herokuish build orchestration on git push dokku master.

Command	Action
make help	Outputs all commands & instructions.
make build	Scaffold or Update WP Container. After running this cd [<appname>] && git push dokku master
make instructions	Show initial application set-up instructions (db setup, filesystem setup, etc)
make diff_prod	Compare local changes with what's on the dev/prod server (depending on what's set in /etc/hosts)
make push [<local path>] [<remote hostname or USER@HOST>]:[<remote path>]*	Send files to specified ENV server (optionally takes a path relative to src/, prompts otherwise)
make pull [<remote hostname or USER@HOST>]:[<remote path>] [<local path>]*	Get files from specified ENV server (optionally takes a path relative to src/, prompts otherwise)
make sync [<from hostname or USER@HOST>] [<to hostname or USER@HOST>]	Pull database, wp-content from origin and push to destination (prompts for each procedure)
make plugit [<user/repo>] ENV=[<host or USER@]HOST>]	Download a git repo to the specified ENV server's wp-content/plugins folder, set proper ownership & permissions
make destroy	🧨 Permanently destroys the database, app, & all stored files (fresh start) 🧨
Development
make dev	"vagrant up" Power up (or create, if it doesn't already exist) the VM
make dev_down	"vagrant halt" Shut down the VM
make dev_reload	"vagrant reload" Restart the VM (loads any Vagrantfile changes) Pass --provision to re-provision
make dev_ssh	"vagrant ssh" SSH into the VM
make dev_ssh_info	"vagrant ssh-config dokku" Output the SSH info (for use in ~/.ssh/config)
make dev_destroy	"vagrant destroy" 🧨 Permanently destroys all remnants of the VM: the database, app, & all stored files (fresh start) 🧨
make theme_build [<local path>] [<hostname or USER@HOST>]:[remote path]	Run the theme build (CSS/JS compile) scripts & push to [<hostname or USER@HOST>]:[remote path]

*Before make push ..., make pull ..., make theme_build ..., or vscode-ext.sync-rsync will work you must first modify the host visudo settings to allow unattended operations:

# remote
which rsync # take note of the result!
sudo visudo

# ...and add the following to the bottom of the file (lower instructions take precedence):
[<username>] ALL=NOPASSWD:[<path returned from which rsync>]

⚠️ IMPORTANT PUSH/PULL/SYNC TARGET PATH INFORMATION:

• Source
  • When using "/" at the end of source path, rsync will copy the content of the source folder to the destination, but not the folder itself.
  • When omitting "/" from the end of source path, rsync will copy the folder and its content to the destination.
• Destination
  • When using "/" at the end of the destination path, rsync will place the data inside the last destination folder.
  • When omitting "/" from the end of the destination path, rsync will create a folder with the name of the last destination and paste the data inside that folder.

Shell Scripts (server)

Commands sourced from .profile.

Copy .profile up to the server:

# local ./
scp .profile [<remote hostname or USER@HOST>]:~

# remote ~/
source .profile

Command	Action	Notes
la [<(opt: dir)>]	Supercharged ls (list files)	Uses current dir if unspecified
lap [<(opt: dir)>]	la with "octal permissions" (e.g. 755)	☝️
bin [<appname>] [<(opt: sudo)>]	Enter container as root	Executes docker exec -it [<appname>].web.1 /bin/bash; (assumes docker ps 'name')<br> Shorthand: sudo : -s`
Copy files into (-i) or out of (-o) a docker container	dcp -[<i/o>] [<source>] [<app name>] [<destination>]	Executes docker cp [<source>] [<appname>]:[<destination>] (swapping order for in/out)
wgit [<user/repo>]	Download a git repo (e.g. plugin), extract, set ownership & permissions	Sets ownership to 32767 (container user)
uzp [<file.zip>]	Extract a .zip file, set ownership & permissions	☝️, (also: be sure to verify unzipped directory name!)
pfix	Fix ownership & permissions of current directory & subdirectories	Sets ownership to 32767 (container user)
av [<on/off>]	Turn on/off Sophos AV	Shorthand: on : -i, off : -o
clr	Clear up RAM (PageCache, Swapfile)	Not recommended to run often, or in live environments!
db [<export/import>] [<(import.sql)>]	Import or export a database dump	Export: Database dumps to ~/.sql with timestamped filename. Import: requires passing a dump.sql file Shorthand: export: -e, import: -i
sync [<up/down>]	Sync wp-content files up or down from VAGRANT (dev) server	Note: this only works between local & vagrant, this will not work on remote (prod) Shorthand: up: -u, down: -d

Upgrading WordPress

To upgrade to a later version of WordPress just change the version number in the .env file and run make build again!

⚠️ Warning: A 'traditional' upgrade performed using the WordPress UI-based upgrade process will not survive a server app restart (due to the ephemeral nature of the underlying docker-based filesystem) and thus should not be attempted if you want to persist the upgrade.