Appcontainers/WordPress

CentOS 6.8 based Customizable WordPress 4.9 Container – 485 MB – Updated 06/20/2016

This container is built from appcontainers/apache:centos
Any of the examples below can pull off of the Quay registry by putting quay.io/ in the front of the namespace/repository

Description:

WordPress.com powers beautiful websites for businesses, professionals, and bloggers.

Features
Start a blog or build a full-fledged website.
Included tools to create the site you want — without paying a dime.
Integrate Social Media into Your Site.
Track Your Site Statistics.
Customize Your Design with Ease.
Create and Read with Mobile Apps.
Easily Export Your Content.
Multilingual Platform.

Official WordPress Website

This container has 2 variants of which are built from appcontainers/centos:6, and appcontainers/debian_jessie respectively. Both base OS’s are slightly modified bare bones CentOS 6.8, and Debian 8 Jessie Minimal Installations. The images reside on both the docker hub as well as the quay registry. If you would prefer to use the images distributed from quay.io, just simply append quay.io to the front of the namespace/repository designation as such in the examples quay.io/appcontainers/centos, and quay.io/appcontainers/debian. Modifications to the minimal installations of the base images can be found by looking at the appcontainers/centos, and appcontainers/debian repositories located below:

Docker Hub: appcontainers/centos
Quay Registry: quay.io/appcontainers/centos
Docker Hub: appcontainers/debian
Quay Registry: quay.io/appcontainers/debian

Its purpose is to get a customizable wordpress instance up and running with a single or multiple docker run statements, depending on how resilient you want the environment. The container is built with environment variables that allow the user to plug in custom values which will allow the container to configure itself on first run. This will give you a fully customized experience just as if you set up wordpress on your own from scratch.

NOTE: The following documentation will reference the latest tag, referring to CentOS, if you would like to run Debian instead, just add the tag :debian to the image name instead of using either the default (latest) or :centos.

 

You Tube Demo:

Run as standalone:


 

Run as Production, Multiple deployement senario, fully explained:


 

Appcontainers/wordress container options explained. Run this container customized for your needs.


 

 

Container Variables:

This container is built to allow several configurable variables to be passed in at runtime. The values are as follows:

  • APP_NAME – This is the fully qualified domain name such as example.com. This should be passed without any prefix such as www.
  • APACHE_SVRALIAS – This is exactly what it sounds like, the apache file ServerAlias Directive data.
  • MYSQL_SERVER – This is the Host server that runs the MySQL instance where the Application DB will be stored.
  • MYSQL_CLIENT – This is the hostname or the IP address of the computer making the connection to the database
  • MYSQL_USER – This is the mysql user that will be used to connect to the mysql instance, and create the database. User must have grant option.
  • MYSQL_PASS – This will set the MySQL Root Password on standalone mode, or be used to connect to the database server in remote mode.
  • MYSQL_DB – The name of the MySQL DB that the Application will use.
  • APP_USER – The username that the Application will use in order to connect to the MySQL DB.
  • APP_PASS – The password of the user that the Application uses to connect to the MySQL DB.
  • WP_KEY – WordPress custom unique key value, configured in the wp-admin.php file
  • MODE – A toggle to tell the container to install mysql locally, connect to an external server and install a new DB on the remote server, connect to an existing database on an existing remote server, or just run as a persistent data volume with no services.
  • ENV – Variable to hold the environment, currently it serves no other purpose but is there in case its needed
  • TERMTAG – Environment variable to hold the highlighted bash shell tag. Currently set to the repo name, but can be change from within the container via TERMTAG=”Whatever You Want”

NOTE: If you have connected the server to a data volume that already contains a wordpress instance, and a pre-generated certificate, then when a new wordpress container is fired off using those volumes, it detects those existing files, and will NOT perform any reconfiguration on either the existing wordpress instance, nor create a new SSL cert. It will use the existing ones in place. This is assuming that the wordpress install folder, and certificate are named the same as the APP_NAME variable passed.

MODE VALUES:

  • Standalone – Start a local mysql instance, and install a new database on the localhost mysql instance.
  • Remote – Connect to an existing remote database server and install a new database on the remote mysql instance. MySQL-Server package is removed in this mode. User with grant-option must be pre-configured on the existing database server and supplied at runtime.
  • Existing – Connect to an existing remote database on an existing remote mysql instance. MySQL-Server package is removed in this mode.
  • DataVol – This mode will uninstall the mysql, mysql-server, mod_rewrite, mod_ssl, mod_env, php php-common, php-cli, php-mysql and httpd packages. This mode is intended to be used solely as a data volume, allowing another instance to connect to the installed directory structure of the application for persistent storage.

Note: If “Remote” or “Existing” is selected, then before running the container the user must know a mysql superuser username/password, or connect to the database and ensure that the APP_USER and APP_PASS that will be used in the run statement, already have permission to either create a new database and publish a new grant (remote), or read the MYSQL_DB (existing).

Note: Keeping the default mode of “standalone” will start the local MySQL instance, and set it to run on start, setting the mode to either “remote” or “existing” will not configure the local instance of mysql, and will not set it to start at run time, it will also automatically remove the installed mysql packages from the container.

Running the Container:

docker run -d -it --name wordpress -h wordpress -p 80:80 -p 443:443 appcontainers/wordpress

This will assume the following

  • ENV = dev
  • TERMTAG = wordpress
  • MODE = standalone
  • APP_NAME = wordpress.local
  • APACHE_SVRALIAS = www.wordpress.local localhost
  • MYSQL_SERVER = localhost
  • MYSQL_CLIENT = localhost
  • MYSQL_USER = root
  • MYSQL_PASS = PAssw0rd
  • MYSQL_DB = wordpress
  • APP_USER = admin
  • APP_PASS = PAssw0rd
  • WP_KEY = Check us out at www.appcontainers.com

Setting any of the above values will tell the container to replace the default values already set within the container with the values that are supplied at runtime. For example, if you pass in -e APP_NAME=mysite.com then wordpress will be reconfigured for mysite.com. The project folder located in /var/www/html will be named mysite.com, and Apache will be set to listen for requests to mysite.com etc.. Additionally SSL Self Signed certs are generated in the /etc/pki/tls directory (centos) or the /etc/ssl directory (debian), and mysite.com is auto configured to listen for both HTTP/HTTPS requests.. To test the container, you simply can run it, hit the IP via a standard http or https request, and you will be presented with a php info page showing you the status of PHP and all of the PHP modules that are pre installed.

Running the container in standalone mode, with customized variable values:

docker run -d -it \
--name wordpress \
--restart always \
-h wordpress \
-p 80:80 \
-p 443:443 \
-e APP_NAME='testapp.com' \
-e APACHE_SVRALIAS='www.testapp.com localhost' \
-e MYSQL_SERVER='localhost' \
-e MYSQL_PASS='PAssw0rd' \
-e MYSQL_DB='testapp' \
-e APP_USER='admin' \
-e APP_PASS='PAssw0rd' \
-e WP_KEY='I Love Flappyjacks' \
-e ENV=production \
-e TERMTAG=WORDPRESS \
appcontainers/wordpress

This example will start a new container named wordpress, It will set wordpress and apache to testapp.com, It will configure apache for the testapp.com site, additionally a self signed SSL cert will be generated generated, and the site will be configured to be accessible via HTTP/HTTPS listening on port 80 and 443 respectively within the container. Host port 80 will be mapped to the Apache container port 80, and host port 443 will be mapped to the Apache container port 443. The restart policy will be set to always, meaning that if the container crashes unexpectedly, it will automatically kick itself back off. Mode is set to standalone, meaning that Apache will run fully within the single container. It will leave the default database instance on the localhost and configure mysql to have a root password of “PAssw0rd”, with the wordpress database being named testapp. It will create a user named “admin” with a password of “PAssword” and set a grant statement on the testapp database to allow all privileges to be granted to the admin@localhost user. It will automatically set those connection credentials in the wp-config file to the values specified as well. At this point wordpress is fully configured and you need just to go the default URL via HTTP/HTTPS. The default URL will either be the IP address or the FQDN of the host running the container. You can either hit the IP address of the host on port 80/443, put a host file entry in mapping the host IP with testapp.com, allowing you to hit testapp.com directly from a browser, or if the container is running locally, then you can hit it via localhost, 127.0.0.1, or by the container IP which can be obtained with a docker inspect wordpress | grep IP.

MODE “Remote” or “remote”:

In this example lets assume the following scenario:
The database will live on “mydbserver.mydomain.mytld”.
The database will be named “wordpressapp”.
A connection to the existing database server will be made using the existing mysql user “superuser”.
The “superuser” user also has an existing password set to “superpassword”.
The wordpress user that will be used to connect to the new database will be named “appadmin”.
The wordpress user “appadmin”, password will be set to “flappyjacks”.
Connections to the wordpressapp database will be allowed from any host (%).

The superuser/superuserpassword users must already exist on the mysql server, and will be used to allow the container, to create a connection, and create the database for wordpress. This means that the superuser, user must have the appropriate permissions with the grant option in order to effectively make the connection, create the database, the application user, the application password and he necessary grants to allow the application to interact accordingly with the database.

The above scenario correlates to the following configuration given at container runtime.

  • MODE=”remote”
  • MYSQL_USER=”superuser”
  • MYSQL_PASS=”superpassword”
  • MYSQL_SERVER=”mydbserver.mydomain.mytld”
  • MYSQL_CLIENT=”%”
  • MYSQL_DB=”wordpressapp”
  • APP_USER=”appadmin”
  • APP_PASS=”flappyjacks”

Note: The following assumes that on the mysql server, a user named superuser has been created with the grant option, and has permissions on all databases, or you are firing this connection off as the mysql root user, which has been configured already to allow connections from %. If you are using a user other than root, ensure that the MySQL connecting user (MYSQL_USER) has all privileges including grant, so that the mysql script can create the application user and publish the grant to the newly created database for the application. An appropriate grant statement is as follows

GRANT ALL PRIVILEGES ON *.* TO 'superuser'@'%' IDENTIFIED BY 'superpassword' WITH GRANT OPTION;

Running the container in “Remote” Mode:

docker run -d -it \
--name mysql \
-h mysql \
-p 3306:3306 \
-e CREATEDB=false \
-e MYSQL_USER='admin' \
-e MYSQL_PASS='adminpassword123' \
-e MYSQL_CLIENT='172.17.0.%' \
-e TERMTAG=mysql \
appcontainers/mysql
 
docker run -it \
--name wordpress \
-h wordpress \
-p 80:80 \
-p 443:443 \
--link mysql:mysql \
-e MODE=remote \
-e APP_NAME='testapp.com' \
-e APACHE_SVRALIAS='www.testapp.com localhost' \
-e MYSQL_SERVER='mysql' \
-e MYSQL_USER='superuser' \
-e MYSQL_PASS='superpassword' \
-e MYSQL_DB='wordpressapp' \
-e MYSQL_CLIENT='%' \
-e APP_USER='appadmin' \
-e APP_PASS='flappyjacks' \
-e WP_KEY='I Love Flappyjacks' \
-e ENV=production \
-e TERMTAG=prod \
appcontainers/wordpress

As stated above, In this scenario, the container will connect to the MYSQL_SERVER (mysql), as superuser (MYSQL_USER)suppling the MYSQL_PASS of superpassword, which will grant access to the mysql server instance. A query will be made against the database instance to check to see if the database already exists.. If it exits then it will do nothing further, however if it does not exist then, the superuser mysql user, will create the wordpressapp database, and place a “GRANT ALL PRIVILEGES” on that database to the APP_USER ‘appadmin’@’%’ (% signifies wild as in accept from any connecting IP, this can be substituted with an IP of the connecting host or from the connecting subnet like 172.17.0.%) and with the APP_PASS of “flappyjacks”. It will then flush mysql privileges, and finally remove the “test” database if it exits. Finally the local mysql-server package will be removed from the wordpress instance.

MODE “Existing” or “existing”:

In the following example, the assumption is made that there is a remote database server, that already contains a pre-existing wordpress database, and there is already a grant statement allowing the APP_USER/APP_PASS all privileges on the existing wordpress database.

Note: If you are unsure if the APP_USER/APP_PASS credentials have the appropriate permissions on the existing wordpress database, then you can connect to the existing database server and issue the following grant substituting the variables with actual values that will be used in the run statement.

GRANT ALL PRIVILEGES ON $MYSQL_DB.* TO '$APP_USER'@'%' IDENTIFIED BY '$APP_PASS';
FLUSH PRIVILEGES;

Running the container in “Existing” Mode:

docker run -d -it \
--name wordpress \
-h wordpress \
-p 80:80 \
-p 443:443 \
-e MODE='existing' \
-e APP_NAME='testapp.com' \
-e APACHE_SVRALIAS='www.testapp.com localhost' \
-e MYSQL_SERVER='mydbserver.mydomain.mytld' \
-e MYSQL_DB='wordpressapp' \
-e APP_USER='appadmin' \
-e APP_PASS='flappyjacks' \
-e WP_KEY='I Love Flappyjacks' \
-e ENV=production \
-e TERMTAG=prod \
appcontainers/wordpress

Note: Using the existing mode also tells the wordpress instance to remove the local mysql-server package from the wordpress instance.

MODE “Datavol” or “datavol”:

As stated above the intention of the datavol mode is to set up a shell of the wordpress directory structure that will be set as persistent storage. The idea is that the /var/www/html, and /etc/pki/tls directories will be flagged as persistent. A second actual instance container will then run connected to the persistent volume and will perform the configuration of the wordpress application. This configuration will allow you to remove the wordpress container to upgrade to a new one or reset it, without loosing any of your wordpress data.

Note: When the wordpress container initially runs, it checks for the existence of both the wordpress directory and an existing certificate, and if detected, it skips both the wordpress configuration steps, or certificate creation steps respectively. Each of these checks are independent of each other, meaning that if a wordpress directory is detected, but no certificate is detected, then it will skip only the wordpress configuration pieces, but will generate a new certificate. These checks are dependent upon the wordpress folder, and certificate being named the same as APP_NAME. Example, if APP_NAME=example.com, then the check will search for /var/www/html/example.com for wordpress, and then will check for /etc/pki/tls/certs/example.com.crt for the certificate. The checks are based on the initial configuration of the application via the very first original container run, which does perform both of those configurations.

Running the container in “Datavol” Mode:

docker run -d -it \
--name mysql \
-h mysql \
-p 3306:3306 \
-e CREATEDB=false \
-e MYSQL_USER='admin' \
-e MYSQL_PASS='adminpassword123' \
-e MYSQL_CLIENT='172.17.0.%' \
-e TERMTAG=mysql \
appcontainers/mysql
 
docker run -d -it \
--name wordpressdata \
-h wordpressdata \
-v /var/www/html \
-v /etc/pki/tls \
-e MODE="datavol" \
-e ENV=production \
-e TERMTAG=wp_data \
appcontainers/wordpress
 
docker run -d -it \
--name wordpress \
-h wordpress \
-p 80:80 \
-p 443:443 \
--volumes-from wordpressdata \
--link mysql:mysql \
-e MODE=remote \
-e APP_NAME='testapp.com' \
-e APACHE_SVRALIAS='www.testapp.com localhost' \
-e MYSQL_SERVER='mysql' \
-e MYSQL_PASS='PAssw0rd' \
-e MYSQL_DB='testapp' \
-e APP_USER='admin' \
-e APP_PASS='PAssw0rd' \
-e WP_KEY='I Love Flappyjacks' \
-e ENV=production \
-e TERMTAG=prod \
appcontainers/wordpress

Note: This mode removes all httpd/php/mysql packages from the datavol container. It is intended to be used a persistent storage only, and not actually run any application services.

Access the new Install:

Simply Navigate to the IP address of the host/container via a standard http or https request, and you will be presented with the MediaWiki Installation GUI. (80/443 default). You also could put a host file entry in mapping the host IP with the configured $APP_NAME, allowing you to hit that URL directly from a browser, or if the container is running locally, then you can hit it via localhost, 127.0.0.1, or by the container IP which can be obtained with a docker inspect apache | grep IP.

Once the container is up and running you can attach to the container via docker exec -it wordpress bash or you can copy existing project data from your local machine via docker cp /path/to/your/data wordpress:/var/www/html/$APP_NAME. Lastly if an apache restart (restarting the entire container) is not convenient, then you can launch the container appending the command /bin/bash to the end of any of the docker run statements above, and then simply attach to the container via docker attach wordpress (hit enter twice), which will make the container act like a standard VM, allowing you to stop and start services normally. When you are finished in either the attached or exceed container, do not type exit (which would shut down the container), but instead use the detach key combination of CTL P + CTL Q.

 

Launching the Container via docker-compose:

Copy the text below and paste it into a file named docker-compose.yml. Then you can navigate to the directory and if you have docker-compose installed, just issue the following command:

docker-compose up -d

NOTE: If you need assistance setting up docker-compose please visit [http://www.appcontainers.com] (http://www.appcontainers.com/installing-and-deploying-containers-using-docker-compose/) to watch the tutorial or read about the installation process.

Centos:

dbdata:
  image: appcontainers/centos
  hostname: dbdata
  stdin_open: true
  tty: true
  volumes:
  - /var/lib
  environment:
  - TERMTAG=DBDATA
  command: sleep 1
 
db:
  image: appcontainers/mysql
  hostname: db
  stdin_open: true
  tty: true
  restart: always
  volumes_from:
  - dbdata
  environment:
  - MYSQL_USER=appadmin
  - MYSQL_PASS=adminpassword123
  - TERMTAG=DB
  command: /bin/bash
 
 webdata:
   image: appcontainers/wordpress
   hostname: wpdata
   stdin_open: true
   tty: true
   volumes:
   - /var/www/html
   - /etc/pki/tls
   environment:
   - MODE=datavol
   - ENV=production
   - TERMTAG=WEBDATA
   command: /bin/bash
 
web:
  image: appcontainers/wordpress
  hostname: wordpress
  stdin_open: true
  tty: true
  restart: always
  ports:
  - "80:80"
  - "443:443"
  links:
  - db
  volumes_from:
  - webdata
  environment:
  - MODE=remote
  - APP_NAME=testwordpress.com
  - APACHE_SVRALIAS=www.testwordpress.com localhost
  - MYSQL_SERVER=db
  - MYSQL_CLIENT=172.17.%.%
  - MYSQL_USER=appadmin
  - MYSQL_PASS=adminpassword123
  - MYSQL_DB=wordpress
  - APP_USER=appuser
  - APP_PASS=apppass
  - WP_KEY=ILoveFlappyjacks
  - ENV=production
  - TERMTAG=WORDPRESS

Debian:

dbdata:
  image: appcontainers/debian
  hostname: dbdata
  stdin_open: true
  tty: true
  volumes:
  - /var/lib
  environment:
  - TERMTAG=DBDATA
  command: sleep 1
 
db:
  image: appcontainers/mysql:debian
  hostname: db
  stdin_open: true
  tty: true
  restart: always
  volumes_from:
  - dbdata
  environment:
  - MYSQL_USER=appadmin
  - MYSQL_PASS=adminpassword123
  - TERMTAG=DB
  command: /bin/bash
 
webdata:
  image: appcontainers/wordpress:debian
  hostname: wpdata
  stdin_open: true
  tty: true
  volumes:
  - /var/www/html
  - /etc/ssl
  environment:
  - MODE=datavol
  - ENV=production
  - TERMTAG=WEBDATA
   command: /bin/bash
 
web:
  image: appcontainers/wordpress:debian
  hostname: wordpress
  stdin_open: true
  tty: true
  restart: always
  ports:
  - "80:80"
  - "443:443"
  links:
  - db
  volumes_from:
  - webdata
  environment:
  - MODE=remote
  - APP_NAME=testwordpress.com
  - APACHE_SVRALIAS=www.testwordpress.com localhost
  - MYSQL_SERVER=db
  - MYSQL_CLIENT=172.17.%.%
  - MYSQL_USER=appadmin
  - MYSQL_PASS=adminpassword123
  - MYSQL_DB=wordpress
  - APP_USER=appuser
  - APP_PASS=apppass
  - WP_KEY=ILoveFlappyjacks
  - ENV=production
  - TERMTAG=WORDPRESS

NOTE: This image is now set to generate a SSL key/cert Pair on first run. This cert is not shared with anyone else, and is also only self signed, which will allow for HTTPS connections, but will not be a valid cert. If you wish to use a valid cert, then place your own key/cert in /etc/pki/tls/private, /etc/pki/tls/certs respectively, and change the apache configuration accordingly if the certificate name is changed from its default value.

 

Dockerfile Change-log:

06/20/2016 - Update OS Versions, Remove Ubuntu
12/28/2015 - Auto Run CMD, Fix Debian/Ubuntu AllowOverride
08/31/2015 - Moved into new format using new runconfig script.
05/10/2015 - Enable checks for existing data in /var/www/html, and mysql remote mode.
05/09/2015 - Enable Data Volume Mode for persistent storage of /var/www/html.
05/08/2015 - SSL Support included with newly generated Self Signed Cert/Key Pair.
05/01/2015 - Remove all Non EN Locales to save around 100MB of space.
04/08/2015 - Changed the Mode 'New' to 'Remote' to be less confusing. Wrote and included a docker-compose.yml file in the project.
04/06/2015 - Added MYSQL_CLIENT, MYSQL_USER, and MODE features. Server can now be set to either run mysql local or connect to remote server.

 

Verification

------------------------
Test Standalone Version
------------------------
docker run -it \
--name wordpress \
-h wordpress \
-p 80:80 \
-p 443:443 \
-e APP_NAME='testapp.com' \
-e APACHE_SVRALIAS='www.testapp.com localhost' \
-e MYSQL_SERVER='localhost' \
-e MYSQL_PASS='PAssw0rd' \
-e MYSQL_DB='testapp' \
-e APP_USER='admin' \
-e APP_PASS='PAssw0rd' \
-e WP_KEY='I Love Flappyjacks' \
-e ENV=production \
-e TERMTAG=prod \
appcontainers/wordpress
 
 
------------------------
Test Standalone Version
(attached to data vol)
------------------------
docker run -it \
--name wordpressdata \
-h wordpressdata \
-v /var/www/html \
-v /etc/pki/tls \
-e MODE="datavol" \
-e ENV=production \
-e TERMTAG=wp_data \
appcontainers/wordpress
 
# Run once, remove, run again
docker run -it \
--name wordpress \
-h wordpress \
-p 80:80 \
-p 443:443 \
--volumes-from wordpressdata \
-e APP_NAME='testapp.com' \
-e APACHE_SVRALIAS='www.testapp.com localhost' \
-e MYSQL_SERVER='localhost' \
-e MYSQL_PASS='PAssw0rd' \
-e MYSQL_DB='testapp' \
-e APP_USER='admin' \
-e APP_PASS='PAssw0rd' \
-e WP_KEY='I Love Flappyjacks' \
-e ENV=production \
-e TERMTAG=prod \
appcontainers/wordpress
 
 
------------------------
Test Datavol/Remote
------------------------
# Launch the following, then remove the wordpress container, and run another wordpress web container only, leaving the datavolume in tact.
 
docker run -d -it \
--name mysql \
-h mysql \
-p 3306:3306 \
-e CREATEDB=false \
-e MYSQL_USER='admin' \
-e MYSQL_PASS='adminpassword123' \
-e MYSQL_CLIENT='172.17.0.%' \
-e TERMTAG=mysql \
appcontainers/mysql
 
docker run -it -d \
--name wordpressdata \
-h wordpressdata \
-v /var/www/html \
-v /etc/pki/tls \
-e MODE="datavol" \
-e ENV=production \
-e TERMTAG=wp_data \
appcontainers/wordpress
 
docker run -it \
--name wordpress \
-h wordpress \
-p 80:80 \
-p 443:443 \
--link mysql:mysql \
--volumes-from wordpressdata \
-e MODE=remote \
-e APP_NAME='testpress.com' \
-e APACHE_SVRALIAS='www.testpress.com localhost' \
-e MYSQL_SERVER='mysql' \
-e MYSQL_USER='admin' \
-e MYSQL_PASS='adminpassword123' \
-e MYSQL_DB='wordpress' \
-e MYSQL_CLIENT='172.17.0.%' \
-e APP_USER='wpadmin' \
-e APP_PASS='PAssw0rd' \
-e WP_KEY='I Love Flappyjacks' \
-e ENV=production \
-e TERMTAG=prod \
appcontainers/wordpress
 
 
----------------------------------
Test Existing off of previous test
Make sure to first remove containers:
wordpress, wordpressdata
----------------------------------
docker run -it \
--name wordpress \
-h wordpress \
-p 80:80 \
-p 443:443 \
--link mysql:mysql \
-e MODE=existing \
-e APP_NAME='testpress.com' \
-e APACHE_SVRALIAS='www.testpress.com localhost' \
-e MYSQL_SERVER='mysql' \
-e MYSQL_DB='wordpress' \
-e MYSQL_CLIENT='172.17.0.%' \
-e APP_USER='wpadmin' \
-e APP_PASS='PAssw0rd' \
-e ENV=production \
-e TERMTAG=prod \
appcontainers/wordpress
 
-------------------------------------
Test docker-compose front end upgrade
-------------------------------------
docker-compose up -d
 
docker kill wordpress_web_1
docker rm wordpress_web_1
 
docker run -it \
--name wordpress_web_1 \
-h wordpress_web_1 \
-p 80:80 \
-p 443:443 \
--link wordpress_db_1:wordpress_db_1 \
--volumes-from wordpress_webdata_1 \
-e MODE=existing \
-e APP_NAME='testwordpress.com' \
-e APACHE_SVRALIAS='www.testwordpress.com localhost' \
-e MYSQL_SERVER='wordpress_db_1' \
-e MYSQL_DB='wordpress' \
-e MYSQL_CLIENT='172.17.0.%' \
-e APP_USER='appuser' \
-e APP_PASS='apppass' \
-e ENV=production \
-e TERMTAG=prod \
appcontainers/wordpress

1 comments
jmdocherty
jmdocherty

Thanks for the great info. How do I modify this setup to include wordpress plugins? I'm going round in circles between the dockerfile and docker-compose.yml

Trackbacks

  1. […] This is just perfect since it already has WordPress set up nicely and even has a nice tutorial. Read the tutorial on appcontainers.com to find out what all the different environment variables […]

  2. […] This is just perfect since it already has WordPress set up nicely and even has a nice tutorial. Read the tutorial on appcontainers.com to find out what all the different environment variables […]