If you’d just like to dive into the code for adding a database management tool to the simple WordPress app from the previous post you can skip ahead to Putting It All Together.
This is Part 2 in a series describing a project to create a local WordPress development environment using Docker-Compose. The series is structured as follows:
- Part 1 – Series introduction and creating a simple WordPress app
- Part 2 – Adding a database management tool
- Part 3 – Adding a web server
- Part 4a – Exploring anonymous volumes
- Part 4b – Exploring bind mounts
- Part 4c – Exploring named volumes
- Part 4d – Working with data storage
- Part 5 – Securing passwords with Docker secrets
- Part 6 – Securing network communications with self-signed certificates
- Part 7a – Creating your own certificate authority
- Part 7b – Securing network communications with your own certificate authority
- Part 8 – Hosting multiple WordPress sites on a single database server
- Part 9a – Installing and configuring a Bitwarden password manager
- Part 9b – Hosting Bitwarden behind a reverse proxy server
In Part 2 we’ll add a database management tool to the simple WordPress app we created in Part 1 and use it to backup our WordPress database.
Limitations of the Simple WordPress App
The simple WordPress app we developed in Part 1 harnessed all the power of WordPress with just 16 lines of code and a single start up command. It’s a perfect app to tinker with WordPress, testing out new themes, plugins or whatever. However, the app has many limitations and doesn’t meet most of the goals I laid out in Part 1 for a WordPress development environment.
A big limitation we discovered at the end of Part 1 is that our simple WordPress app doesn’t retain its data from session to session, at least without some effort on our part. We’ll address this limitation in Part 4. Another data limitation for me is not being able to easily access the WordPress database from the app. We’ll see in Part 4 several ways to access the data that Docker is storing internally for us, but I’d rather access the database through my browser with a database management tool.
My hosting company provides the database management tool PhpMyAdmin to manage my online WordPress database. There is a Docker image for PhpMyAdmin which I use in my own development environment and that we can use here. But in keeping with using mostly Docker Official Images for this series I’m going to use a different tool, Adminer, for the next few parts of the series at least. Personally, I like PhpMyAdmin better and we might have a look at it further along in this series should Adminer not meet our needs.
Adding Adminer to Our Simple WordPress App
In keeping with the barebones spirit of our simple WordPress app, it will only take 4 lines of code to add the Adminer database management tool. We only need to specify an image and the ports to use.
A simple Adminer service
adminer: image: adminer ports: - "8080:8080"
That’s it. It wasn’t much effort to add an entire database management tool to our app.
The Compose code above does the following:
- image: specifies the “latest” Adminer image as our database management tool. This is fine for our simple app for now but note that using the latest image versus a fixed version could break your app if the latest version of an image becomes incompatible with your app.
- ports: we’ll use port 8080 to access Adminer from our browser. You’ll recall we used port 8000 to access WordPress in Part 1. So here we’ll access Adminer the same way we did for WordPress in Part 1 just substituting port 8080 for 8000. Here we specify port 8080 for both the host and container in the host:container pair above. Adminer exposes port 8080 by default so we’ll just use it here as well. If you find this way of accessing our apps services bothersome, you’ll be happy to know we’ll make it easier in Part 3 with the use of a web server.
Putting It All Together
Our Compose file isn’t much bigger, but we’ve added the capability to manage our WordPress database through a web portal. Below is our updated Compose file. I’ve created mine in a new directory named part-2, but you can just edit you docker-compose.yml file from Part 1 if you’d like.
docker-compose.yml file for a simple WordPress app with database management tool
version: '3.7' services: db: image: mariadb environment: MYSQL_ROOT_PASSWORD: simplewordpress MYSQL_DATABASE: wordpress wp: image: wordpress ports: - "8000:80" environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_NAME: wordpress WORDPRESS_DB_USER: root WORDPRESS_DB_PASSWORD: simplewordpress adminer: image: adminer ports: - "8080:8080"
If your app is still running from Part 1, you can simply add the 4 extra lines of code for Adminer to your Compose file and start the Adminer service with the following command.
docker-compose up -d
Compose will see that the database and WordPress services are already running and just start the Adminer service. If you’ve shutdown your app from Part 1, the above command will start up all three services. You can confirm all three services are running with the docker ps command which will show something like the list below.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 69b538e6d25f adminer "entrypoint.sh docke…" About a minute ago Up About a minute 0.0.0.0:8080->8080/tcp part-2_adminer_1 8b95f55657de wordpress "docker-entrypoint.s…" About a minute ago Up About a minute 0.0.0.0:8000->80/tcp part-2_wp_1 b9f148a6e665 mariadb "docker-entrypoint.s…" About a minute ago Up About a minute 3306/tcp part-2_db_1
This display shows the following information:
- Container ID: an ID assigned by Docker. It can be used in various Docker commands when working with your containers
- Image: the image used in creating the container
- Command: a command specified in the image or Compose file to run at container creation
- Created/Status: specifies the time since creation and the current status. The status column will indicate “Exited” if the container is shutdown.
- Ports: shows the ports specified in the image or Compose file for use by the container. We can see as expected, our WordPress service is accessible on port 8000 while our Adminer service is available on port 8080. Note the difference in how the port for the MariaDB service is specified. This means it is available on port 3306, but only for use by other containers in the Compose file, namely our WordPress and Adminer services. They both communicate with the database service over this port and you can’t access it directly from your browser. If you try, you’ll get a “can’t reach this page” error.
- Names: shows a container name assigned by Docker if you haven’t specified one yourself in the Compose file. The name assigned by Docker is simply the service name preceded by the directory of the Compose file, with a number appended to the end. We’ll see in another part of this series the usefulness of specifying our own container names.
As before you can access your WordPress site by entering one of the following in your browser:
- from the computer hosting the app
- from a computer on your local network
Similarly, you can access the Adminer service by using port 8080 in the commands above instead of port 8000. Doing that will take you to the Adminer login page.
You can log in to Adminer using the same information we specified in the Compose file for creating the WordPress service (Username = root; Password = simplewordpress; Database = wordpress). If you haven’t yet completed the WordPress installation, you’ll see an empty database screen, such as the one below.
Go ahead and complete the WordPress installation. After it’s completed, navigate back to Adminer and you’ll see WordPress tables in our wordpress database.
You can explore the database tables at your leisure. The options and users tables are most interesting at this point. There are times when you’ll need to change the URL of your site in the options table, for example when restoring the database from another WordPress site to your local site. The users table will come in handy should you forget your WordPress login information. Just add a new user here and your all set to go again.
The WordPress database stores a large portion of the content you create for your WordPress site. As such, you’ll likely want to back it up. You can do this simply with the Adminer Export function. To do so click on the Export link towards the upper left-hand side of the Adminer Database screen for the database you want to export, wordpress in our case.
Select the gzip Output option to export a compressed copy of the database. The save Output option will export an uncompressed copy of the database, while the open Output option will simply open a text file dump of the database.
That’s enough for now. You can play around with your WordPress site and use Adminer to see how WordPress reflects those changes in the database. Next up in Part 3 – Adding a Web Server, we’ll add a web server to our simple app to make access to our WordPress and database services a bit more intuitive. We’ll also briefly look into Docker volumes.