rija / docker-nginx-fpm-caches-wordpress Goto Github PK

the created backup file only contains:

Usage: mysqldump [OPTIONS] database [tables]
OR     mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR     mysqldump [OPTIONS] --all-databases [OPTIONS]
For more options, use mysqldump --help

Given, all env variables are set up correctly, it most likely indicates that the cron line:

@daily      ( date ; mv /root/sql/wordpress.sql /root/sql/wordpress.sql.old ; mysqldump -h $DB_HOSTNAME -u $DB_USER -p$DB_PASSWORD

doesn't recognize the env variables.

Corresponding stack overflow discussion:
https://stackoverflow.com/questions/2229825/where-can-i-set-environment-variables-that-crontab-will-use#10657111

For example to push the web site from Test to Production, or to build a Live-like version of the web site on your development machine.

Starting point: Working Wordpress install with real content deployed as shown in "Deploying Wordpress in a Docker container" and "Deploying Mysql in a Docker container".

On Test:

1. export Database using a Wordpress Plugin like WP Migrate DB
2. export data files from the data volume container used by Wordpress container as described above
3. export themes options if it applies
4. export widgets using a Wordpress plugin like Widgets Settings Importer/Exporter

On Production:

1. Instantiate a database server container as described above
2. Import the mysql dump as shown in "Import a sql database dump in Mysql running in a Docker container"
3. Create a data volume container for Wordpress as shown in first part of "Deploy Wordpress in a Docker container"
4. Import data files as shown in "Import into a data volume container"
5. verify that all files have been copied over. Remove the 'wp-config.php' file.
6. Instantiate a wordpress server container as described in second part of "Deploy Wordpress in a Docker container"

Notes:

• When exporting data files, you can either backup the whole /usr/share/nginx/www or just /usr/share/nginx/www/wp-content
• When exporting data files, you may want to exclude large files from the uploads directory. E.g: You can pass '--exclude "*.mp3" to the tar command to exclude all mp3
• if you have exported /usr/share/nginx/www, Wordpress software is included which is most of the time what you want to do when migrating from Test to Production, but is rarely what you want if you were using these steps to get production data from Live installation into a newer version of the web site being developed. In that case export only wp-content
• the last note results from the fact that a mount point from a data volume container supersedes the identically named mount point from the instantiated container. More info at Docker Docs.

I've been playing around with this repo lately and like it a lot. I made a few tweaks (like don't use https b/c my reverse proxy does the ssl handling, serve static files created by a caching plugin if they exist, ...), but changing those things was super easy. Kudos!

The one thing I struggle though is the question on how to deal with the uploads. I can use the admin backend to alter pages and posts. Those changes get stored into the DB and a backup is created automatically. But what about media uploads? One solution is to simply not do media uploads but instead deploy a new stateless image. That works great, but is a bit tedious/complicated for somebody not familiar with docker. Another option seems to be a plugin like wp-stateless.

How do you recommend dealing with uploads?

Not sure if I missed a step here, but on a fresh installation of Ubuntu 16.04 + docker, running the docker run command gives me "No such container: wordpressfiles".

Further, if I exclude the line "--volumes-from wordpressfiles," the container starts normally but accessing my domain redirects to "https://server_fqdn/." docker logs doesn't show anything suspicious either.

Did I miss something?

For security reasons, php-fpm and nginx run under different users so Nginx-Cache and Nginx-Helper plugins cannot delete the cache on the filesystem.
This is not desirable anyway because it creates an attack opportunity on the filesystems form Wordpress.

A better approach is to use a location-based approach, something like:

 location ~ /purge(/.*) {
            allow              127.0.0.1;
            deny               all;
            fastcgi_cache_purge  tmpcache $1$is_args$args;
        }

nginx is already compile with ngx_cache_purge.

Only Nginx-Helper supports this in theory but last time I tried it wasn't reliable.

cron cannot be stopped or started again after initial launch by supervisord.

$ supervisorctl
supervisor> status
cron                             FATAL     Exited too quickly (process log may have details)
nginx                            RUNNING   pid 27, uptime 0:00:21
php5-fpm                         RUNNING   pid 29, uptime 0:00:21
php5-fpm-log                     RUNNING   pid 28, uptime 0:00:21
stdout                           RUNNING   pid 25, uptime 0:00:21

$ tail -f /tmp/supervisord.log 
2016-01-30 14:41:24,161 INFO gave up: cron entered FATAL state, too many start retries too quickly
2016-01-30 14:41:29,167 INFO spawned: 'cron' with pid 57
2016-01-30 14:41:29,172 INFO exited: cron (exit status 1; not expected)
2016-01-30 14:41:30,178 INFO spawned: 'cron' with pid 58
2016-01-30 14:41:30,184 INFO exited: cron (exit status 1; not expected)
2016-01-30 14:41:32,193 INFO spawned: 'cron' with pid 59
2016-01-30 14:41:32,199 INFO exited: cron (exit status 1; not expected)
2016-01-30 14:41:35,206 INFO spawned: 'cron' with pid 60
2016-01-30 14:41:35,211 INFO exited: cron (exit status 1; not expected)
2016-01-30 14:41:35,212 INFO gave up: cron entered FATAL state, too many start retries too quickly

The supervisord configuration for cron:

[program:cron]
command=/usr/sbin/cron
stdout_events_enabled=true
stderr_events_enabled=true

I'm currently preparing release 2 for this project.

Release content (headlines):

• Upgraded PHP to PHP 7.0 for much improved performance
• Upgraded base OS to Ubuntu 16.04 LTS
• Deployed Nginx from the stable line, compiled with ngx_cache_purge, currently 1.10.1
• HTTP/2 and SSL enabled by default
• Use of Ubuntu packages for Supervisord and LetsEncrypt
• Enabled automated security updates using the Ubuntu unattended-upgrades package
• Minimised the number of processes running as root inside the container
• LetsEncrypt certificate for nginx is automatically renewed
• The Wordpress container communicates with its host's Docker API to find the database container's address
• Made better usage of Supervisord, for consolidating process logs, and as the ID 1 process
• docker compose YAML file to easilily deploy the full stack

Status:

I need to finish the last point regarding Supervisord as ID 1 process, use the Docker image on a staging site for testing and then tag a new release.

Why are theme and plugin/file modifications disabled by default? Is the expected way to install themes/plugins through the wp cli or something?

How can I change DISALLOW_FILE_MODS to false in a way that will persist between docker container restarts?

Thanks - great work on this btw!

The calls to nginx and service in the wordpress.cron cronjob fail because the default bash shell's environment variables are not accessible to cronjob.
This is because cron doesn't use /bin/bash but /bin/sh which links to /bin/dash on Ubuntu.

The call to letsencrypt/certbot script in the same cronjob file succeeds because it is on the path known by /bin/sh.

The fix is to use absolute path for nginx and service, i.e: /usr/sbin/nginx and /usr/sbin/service.

Errors preventing SSL handshake caused web site to become suddenly unavailable:

2017/07/15 00:16:20 [error] 44#44: OCSP_check_validity() failed (SSL: error:2707307D:OCSP routines:OCSP_check_validity:status expired) while requesting certificate status, respond
er: ocsp.int-x3.letsencrypt.org

The certificate is not expired and Let's Encrypt OSCP server responds to ping and resolve with dig

openssl s_client -connect <website>:443 -tls1  -tlsextdebug -status

return handshake errors.

Temporary workaround is to force renew the certificate again.

when opening a terminal in the wordpress container, using 'service nginx start' or 'service nginx restart' hangs. The only way to get nginx restarted is by restarting the container.

When deploying a Wordpress install with a database dump supplied, the data is not loaded in the database server.
The docker logs show the following error:

install_wordpress stdout | this is an existing Wordpress web site, loading the database dump if not loaded already ...
install_wordpress stderr | ERROR install_wordpress stderr |  2003 (HY000) install_wordpress stderr | : Can't connect to MySQL server on 'dbs' (111)
2018-04-27 16:18:14,558 INFO exited: install_wordpress (exit status 1; not expected)

Whenever I load a page in my browser that is not the home page, the page is served from the server instead of from the cache, always. The response header contains:

X-Cache-Status:BYPASS

After enabling debug level:

error_log    /var/log/nginx/error.log debug;

I can see this:

2015/08/05 07:05:11 [debug] 115#0: *371 http script var: "q=/en/my-page/&"
2015/08/05 07:05:11 [debug] 115#0: *371 http script value: ""
2015/08/05 07:05:11 [debug] 115#0: *371 http script not equal
2015/08/05 07:05:11 [debug] 115#0: *371 http script if
2015/08/05 07:05:11 [debug] 115#0: *371 http script value: "1"
2015/08/05 07:05:11 [debug] 115#0: *371 http script set $skip_cache