If you're starting on the journey from local development to production with Docker and don't know all the steps involved, this guide is for you. We'll go over creating production Dockerfiles, tweaking configurations, setting up deployment workflows, and adding seamless CI/CD integration.
Recently I decided to take on the task of automating my site's build and deployment process through GitHub Actions. I'm using my static site generator Cleaver to handle that, which requires Node + PHP to be installed in order to run the build process. Actions supports both of those runtimes out of the box, but I had just created a perfectly good Docker Image for using Cleaver, and wanted to use that.
I've been maintaining and iterating on a basic Docker Compose setup for Laravel over the last year or so. It's worked well enough for local development, which was what I originally intended it for. Ever since I released it though, I've had multiple people sending me concerns and GitHub issues surrounding permissions problems.
Before we get started, I'd like to let you know that this article isn’t a deep-dive tutorial into Docker or an explanation on the intricacies of the toolset. It’s more of a casual walk-through that explores the basics in getting a local development environment set up fast using Docker and Docker Compose.
I'm really interested in electronic engineering, specifically using it to record data and analytics around my house. I've been monitoring the temperature and humidity on my back porch for over a year using a Raspberry Pi Zero and a DHT22 sensor, pushing the data every minute to a more powerful Raspberry Pi 3 Model B in my living room.
This tutorial is built on a previous one that I wrote a few months back called The beauty of Docker for local Laravel development. While this article is beginner-friendly, it leaves out a lot of the original setup for the nginx, php, and mysql containers. I'd recommend that you start off with the previous tutorial first, and then move on to this one.
You can think of Docker as a watered-down VM. Why is this helpful or useful? Well if you have multiple production servers running different versions of Linux, PHP, or any other web software, those variables can be replicated in your container and you can be guaranteed that the application will run precisely how it’s intended to on the production machine.