I think if you’re a DevOps person in any capacity, the utility of Docker is very clear. Your things run in containers that are identical everywhere. Assuming Docker is working/running, the code will execute in a reliably consistent way whether that is Docker running on some developer’s computer, or a sky computer. The (massive) appeal there is that bugs will happen consistently. “Production-only” bugs become a thing of the past. There are other benefits, too, like shipping a dev environment to a team of developers that is entirely consistent, even across platforms, rather than battling with individual developers computers.
So… great? Use it all the time for everything? The stopper there is that it’s complicated, and web dev is already friggin complicated and it often just feels like too much. Andrew Welch, however, makes the case that you don’t have to learn Docker super deeply in order to use it:
Docker is a devops tool that some people find intimidating because there is much to learn in order to build things with it. And while that’s true, it’s actually quite simple to start using Docker for some very practical and useful things, by leveraging what other people have created.
Fair point. I don’t deeply understand most of the technology I use, but I can still use it.
While I run Docker all day for CodePen’s fancy dev environment, that’s what my use is limited to. I don’t reach for it like Andrew does for everything. But I can see how it might feel liberating having all that isolation between projects. One of my favorite of points that Andrew makes is:
Switching to a new computer is easy. You don’t have to spend hours meticulously reconfiguring your shiny new MacBook Pro with all the interconnected tools & packages you need.
I find myself bopping around between computers fairly often for various odd reasons, and being able to make the switch with minimal fussing around is appealing.
When you develop an application, you begin by coding and testing in your local environment. Many applications interface with a database, so in this early stage, you might use SQLite rather than the database brand used in production. This is an issue, however, because ideally, you want to develop the application with the production database in mind.
When using a distributed system setting up and starting/stopping the components needed for this can become error-prone and time-consuming.
Is Minikube melting your laptop? Are your local integration tests suffering because you can’t run dependencies on your development machine?
As organizations adopt Kubernetes and cloud-native architectures, development teams will often run into resource constraints as their architectures get more complex. Additionally, Kubernetes presents new challenges for configuring local development environments in comparison with legacy monolithic applications.
It is a fact that the development process in a Kubernetes environment is not easy. There are a lot of tools that help us in this process. For this use case, we are going to use DevSpace; a tool for developers that makes the Kubernetes lifecycle easier.
Pre-Requisites
Here you have the technologies used in this project:
Flywheel put its new Local Lightning app into public beta this week. The app is an improved version of the company’s local WordPress development tool, formerly known as Pressmatic before Flywheel acquired it from Clay Griffiths and renamed it to “Local by Flywheel.”
Since its acquisition in 2016, Local has gained many fans, particularly developers who had grown tired of debugging local development environments. Local has proven to be a reliable app that saves many wasted hours. It also allows developers to quickly switch between PHP and MySQL versions as well as Apache and nginx.
Overall, Local users enjoy the app’s features but have found performance to be a continual issue. Users reported having one-minute page loads in the backend, on small, uncomplicated sites. These speed issues began to drive users away from Local to other products, as many found that working locally was slower than creating a test site with their hosting companies.
Even booting up the app can be abysmally slow, as demonstrated in a video Griffiths shared announcing the Local Lightning beta:
“To chart a more reliable and powerful path forward, we’re rebuilding Local’s core architecture and moving away from virtualization in favor of native, system-level software to run WordPress locally,” Griffiths said.
The new Local Lightning app reduces system requirements and the minimum disk space requirement has decreased by more than 18GB. Griffiths also reports that the download size for Local is 50% less than before.
Local is also now available on Linux, thanks to the new architecture in the updated app. Linux availability has been a frequent request since Local was originally launched.
Hey, guess what? LOCAL IS NOW AVAILABLE FOR LINUX!
We’ve built it into the public beta of Local Lightning.
Local Lightning and Local by Flywheel have been developed as two separate applications in order to allow users to migrate their sites at their own pace. They can also run alongside each other and are named differently. “Local by Flywheel” is now the old version and the new Local Lightning app is simply known as “Local.” Users can migrate their sites by exporting from the old version and dragging them into the new app for automatic import. The beta is lacking some features that were previously available, including hot-swapping development environments and support for Varnish HTTP Cache. Griffiths’ team is working on restoring feature parity with the original app.
When asked in the product’s forums about the general release date, a Flywheel representative said that it “will definitely be by the end of the year.” Users who want to join the public beta can download the latest version for Mac, Windows, or Linux from the Local Lightning announcement post.
I first heard of Flywheel through their product Local, which is a native app for working on WordPress sites. If you ask around for what people use for that kind of work, you'll get all sorts of answers, but an awful lot of very strong recommendations for Local. I've become one of them! We ultimately did a sponsored post for Local, but that's based on the fact that now 100% of my local WordPress development work is done using it and I'm very happy with it.
Now I've taken the next step and moved all my production sites to Flywheel hosting!
Full disclosure here, Flywheel is now a sponsor of CSS-Tricks. I've been wanting to work with them for a while. I've been out to visit them in Omaha! (👋 at Jamie, Christi, Karissa, and everybody I've worked with over there.) Part of our deal includes the hosting. But I was a paying customer and user of Flywheel before this on some sites, and my good experiences there are what made me want to get this sponsorship partnership cooking! There has been big recent news that Flywheel was acquired by WP Engine. I'm also a fan of WP Engine, being also a premium WordPress host that has done innovative things with hosting, so I'm optimistic that a real WordPress hosting powerhouse is being formed and I've got my sites in the right place.
Developing on Local is a breeze
It feels like a breath of fresh air to me, as running all the dev dependencies for WordPress has forever been a bit of a pain in the butt. Sometimes you have it going fine, but then something breaks in the most inscrutable possible way and it takes forever to get going again. Whatever, you know what I mean. At this point, I've been running Local for over a year and have had almost no issues with it.
There are all kinds of features worth checking out here. Here's one that is very likely useful to bigger teams. Say you have a Flywheel account with a bunch of production sites on it. Then a new person starts working with you and they have their own computer. You connect Local to Flywheel, and you can pull down the site and have it ready to work on. That's pretty sweet.
Local doesn't lock you into anything either. You can use Local for local development and literally use nothing else. Local can push a site up to Flywheel hosting too, which I've found to be mighty useful particularly for that first deployment of a new site, but you don't have to use that if you don't want. I'll cover more about workflow below.
Other features that I find worthy of note:
Spinning up a new site takes just a second. A quick walkthrough through a wizard where they ask you some login details but otherwise offer smart-but-customizable defaults.
Dealing with HTTPS locally is easy. It will create a certificate for you and trust it locally with one click.
You can flip on "Live Link", which uses ngrok to create a live, sharable URL to your localhost site. Great for temporarily showing a client or co-worker something without having to move anything.
One click to pop open the database in Sequel Pro, my favorite free database tool. Much easier than trying to spin up phpMyAdmin or whatever on the web to manage from there.
Flywheel's Dashboard is so clear
I love the simple UI of Local, and I really like how that same design and spirit carries over into the Flywheel hosting dashboard.
There are so many things the dashboard makes easy:
You need an SSL cert? Click some buttons.
Wanna force HTTPS? Flip a switch.
Wanna convert the site to Multisite? Hit a button.
Need to edit the database? There is a UI around it built in.
Want a CDN? Toggle a thing.
Need to invite a collaborator on a site? Go for it.
Need a backup? There are in there, download it or restore to that point.
It's a big deal when everything is simple and works. It means you aren't burning hours fighting with tools and you can use them doing work that pushes you forward.
Workflow
When I set up my new CSS-Tricks workflow, I had Flywheel move the site for me (thanks gang!) (no special treatment either, they'll do that for anybody).
I've got Local already, so my local development process is the same. But I needed to update my deployment workflow for the new hosting. Local can push a site up to Flywheel hosting, but it just zips everything up and sends it all up. Great for first deployment but not perfect for tiny little changes like 95% of the work I do. There is a new Local for Teams feature, which uses what they call MagicSync for deployment, which only deploys changed files. That's very cool, but I like working with a Git-based system, where ultimately merges to master are what trigger deployment of the changed files.
For years I've used Beanstalk for Git-based deployment over SFTP. I still am using Beanstalk for many sites and think it's a great choice, but Beanstalk has the limitation that the Git-repo is basically a private Git repo hosted by Beanstalk itself.
During this change, I needed to switch up what the root of the repo is (more on that in a second) so I wanted to create a new repo. I figured rather than doing that on Beanstalk, I'd make a private GitHub repo and set up deployment from there. There are services like DeployHQ and DeployBot that will work well for that, but I went with Buddy, which has a really really nice UI for managing all this stuff, and is capable of much more than just deployment should I ultimately need that.
Regarding the repo itself, one thing that I've always done with my WordPress sites is just make the repo the whole damn thing starting at the root. I think it's just a legacy/comfort thing. I had some files at the root I wanted to deploy along with everything else and that seemed like the easiest way. In WordPress-land, this isn't usually how it's done. It's more common to have the /wp-content/ folder be the root of the repo, as those are essentially the only files unique to your installation. I can imagine setups where even down to individual themes are repos and deployed alone.
I figured I'd get on board with a more scoped deployment, but also, I didn't have much of a choice. Flywheel literally locks down all WordPress core files, so if your deployment system tries to override them, it will just fail. That actually sounds great to me. There is no reason anyone from the outside should alter those files, might as well totally remove it as an attack vector. Flywheel itself keeps the WordPress version up to date. So I made a new repo with /wp-content/ at the root, and I figured I'd make it on GitHub instead just because that's such an obvious hub of developer activity and keeps my options wide open for deployment choices.
Maybe I'll open source it all one day when I've had a chance to comb through it.
For the same kind of spiritual reasons, during the the move, I moved the DNS over to Cloudflare. This gives me control over DNS from a third-party so it's easy for me to point things where I need them. Kind of a decentralization of concerns. That's not for everyone, but it's great for me on this project. While now I might suffer from Cloudflare outages (rare, but it literally just happened), I benefit from all sorts of additional security and performance that Cloudflare can provide.
So the workflow is Local > GitHub > Buddy > Flywheel.
And the hosting is Cloudflare > Flywheel with image assets on Cloudinary.
And I've got backups from both Flywheel and Jetpack/VaultPress.
Those who host or manage sites on WP Engine now have a new tool at their disposal. It’s called DevKit, developed by Chris Wiegman and Jason Stallings.
DevKit is a WordPress local development environment that includes SSH Gateway access, push and pull deployments to WP Engine, Command Line Interface commands for the Genesis theme framework and other tools.
Although DevKit has tight integration with WP Engine the software can be used independently of the host. With Local by Flywheel, Vagrant, XAMPP, and other tools available, Wiegman explains what motivated him to create a new solution.
“I’ve been working on the perfect WordPress developer environment since I learned about Vagrant in 2013,” he said. “As it was never my full-time job, I could never take it to the next level. DevKit gives me the power to do that.”
Stallings added, “We wanted to build a kick ass set of tools for developers building on WP Engine. That’s been our mission from the start, build something that all developers want to use (including us)!”
As what for what sets DevKit apart from the others, “I think our architecture is very different from both tools,” Stallings said.
“Similar to Docker Engine, DevKit CLI is the interface to DevKit. So when we build the GUI it will 100% complement the CLI, and the two can be used interchangeably. This will enable us to build other interfaces in the future too.”
DevKit provides the following features:
Container-based local development environment
SSH Gateway access
Push and pull deployments to WP Engine
Preview your local site with others via ngrok
PHP version selector
Email testing client
MySQL
Local SSH & WP-CLI
Genesis Framework WP-CLI commands
phpmyadmin
webgrind
Varnish
HTTPS Proxy
xdebug
Currently, DevKit’s user interface is command line only with plans to add a GUI later this year. It’s available for free and is in open beta for Mac and Linux. Those interested in participating in the open beta can sign up on the DevKit landing page.
As a developer, I like to do as much development as possible locally, because it's generally easier and faster to develop and debug code. In order to build cloud-native applications and microservices, it's very convenient to have a local Kubernetes cluster and Istio running locally. This article describes how to install these components and some additional tools like Kiali.
Minikube
In order to run Kubernetes clusters locally, there are different alternatives. One is to use the Kubernetes functionality integrated in Docker Desktop. The alternative that I've chosen is Minikube, which runs a single-node Kubernetes cluster inside a VM on your development machine.
Hey, guess what? LOCAL IS NOW AVAILABLE FOR LINUX!
We’ve built it into the public beta of Local Lightning. 
Get it here: 
