Docker for WordPress: Commit Log - Supercharged

Key Takeaways

[Music] so when I thought about developing for WordPress I thought about having to configure Apache and my sequel and all these things it actually kind of scared me and then I thought this would be a really good opportunity to finally look into docker and learn how docker works in both local development and for deployment and all these things and in the end I have to say I have no regrets it turned out to be a really great setup and I want to show you how it works you can even run this entire setup on your machine locally before we dive in just keep in mind that I didn't just pull this out of a hat at the very start this is a result of many iterations on my end and lots of failure and lots of frustration but in the end I had a setup that I really liked and before we start I think I should make sure that we all know what darker actually is docker is a way to run virtual machines and not just virtual emulated machines but actually containers like isolated from the host system and we're gonna have two of these containers running one for Apache PHP and the WordPress code and one for the database which is my sequel we can put these containers in their own little virtual networks so they only can talk to each other in two nothing else and also no other docker container that might be running can talk to them and we're only going to expose port 8080 from the Apache machine because that's where the web server is running and that's the thing that we want to talk to so you configure these virtual machines by writing so called docker files so in this case we need to write two darker felts one for Apache on PHP in WordPress and one for my sequel so let's start with the my sequel container we can use the official my sequel image and if we read through the readme we will actually find the command that we can just copy paste and just adjust to our needs so the only thing that we need to change is set the password for the root account and we need to add it to a network so that we have it in isolation where we can later add on the Apache so we can just change the command accordingly one of the things we need to keep in mind is that these containers volatile so there should be throw away and recreate able at any point in time without creating a disturbance in the system so any kind of data that we want to persist between these tear downs recreation phases we need to persist to the host system and that's where volumes come into play which basically is mounting a directory from the whole system into the container and in this case we're going to store all of my sequel data in one of these mounted folders the other container for Apache PHP on WordPress we can actually use the official WordPress image which already takes care of configuring Apache and PHP to work together as WordPress expects and just surfs up WordPress for you again the only thing we need to worry about is to add the network flag so that the Mike's secret container and the WordPress container can talk to each other and if we run this command you can already see that WordPress is being served up and is completely working which I thought was pretty amazing with just two containers but for my development flow I wanted to have something more I wanted to have it hb2 because it makes websites so much faster so to achieve that I wanted to add a third container that runs caddy caddy is an HTTP to server that runs as a reverse proxy and has a very tight integration with let's encrypt so in this case I would run it as a reverse proxy in front of Apache and expose a new port to it in this case it would be 8 4 4 3 and that means that on the port a 4 4 3 I would get the entire app served over hb2 with a locally signed TLS certificate while on 8080 the old hb1 version would be served up ok once again we start with reading the readme of the image that we are going to use we can copy paste the command just into little adjustments once again we have the port in this case we have the configuration file for caddy and we have as always the network flag so the caddy ends up in the same network as all our other two containers for the configuration file for caddy we need to define where the requests are supposed to go so we need to use Caddy's proxy command to tell that all incoming requests are supposed to be forwarded to a machine called pwp which is the machine that runs Pachi PHP and WordPress additionally though we need to add some headers to the forward request because the back end needs to know that even though it's receiving HTTP requests that they were originally actually HTTP and that enables a slightly different machinery inside WordPress this is the only bit where we need to monkey patch a little bit inside WordPress but that's because that's how their official wiki is documenting this process and they don't have this HTTP handling built in then we need to tell Kelly that we want to use a self-signed certificate so we don't actually want to go let's encrypt but just create a certificate yourself for local development that's fine if we were to go to production we could just remove that line and Kathy would actually request a real sign certificate from let's encrypt and the entire machinery would just work even on a real server which kind of blew my mind that we can just use the exact same setup for local development and for production so if we run this additional third machine you can see that we now have the exact same effect as before that everything is working but this time it's now over HTTP too which is amazing however we now have three individual machines that we need to configure and that can get quite cumbersome and this is where so-called orchestration comes into play for orchestration docker has the command docker compose we write a compose file to describe how all your individual machines are supposed to work together so this is what really makes this thing really frictionless to write or compose file we just create a new Yano file docker compose clusters are always in their own little network so we don't need to worry about the network flag anymore and now it's basically just a list of the machines that we need so the first service in our docker compose file is the my sequel service and we're going to define the my cycle password the image to use and the volume you want to mount that holds all the my sequel data the second service is the WordPress image with Apache and PHP which also needs the my sequel password and the port to listen on and the third service now is caddy which needs the image the configuration file for caddy and the second port that we want to expose to the host machine so this configuration file we can now save and run with a command docker compose up and as you can see if you run this command we immediately have our entire system set up and we can just start using WordPress out-of-the-box so we use docker to define our developer environment and you just spin it up and tear down with just one command but also we can use it in production which i think is pretty great next time we're going to write our very first lines of PHP and I'm really excited about that so if you want to see that subscribe to this channel and I will see you next time [Music]