Today I’m releasing ElephpantDB, a small SQL database written entirely in PHP and shipped as a single file.
Why? Because sometimes you look at a normal application stack and think: “This has far too few opportunities for surprise.”
Every PHP app has a handful of directories the web server has to write to. Cache, sessions, log files, image uploads,
compiled views. Deployer logs in as one user (deploy) and unpacks code into a release directory owned by that user.
PHP-FPM runs as a different user (www-data, nginx, apache, depending on the distro) and needs write access to a
subset of that release. How you bridge those two users is writable_mode. Deployer ships six options. This post walks
through what each one does, the syscalls behind it, and where it fits.
If you have ever wondered why a Deployer release is "atomic", the answer is one syscall: rename(2). The whole
zero-downtime story is built on the fact that, on a single filesystem, swapping a symlink with mv -T is indivisible
from the kernel's point of view. Either every request sees the old release, or every request sees the new one. Never
half of each. This post explains exactly how that works, and what Deployer does on the systems where it does not.
A typical Deployer run fires somewhere between twenty and a hundred SSH commands per host. Pull from git, install
vendors, run migrations, swap a symlink, restart container, clean up old releases. If each of those opened a fresh SSH
connection, deploys would feel painful. They do not, because of a small OpenSSH feature called ControlMaster. This
post is about how it works, and how Deployer wires it up.
When Deployer deploys to ten hosts at once, it does not run ten SSH sessions inside a single PHP process. It spawns ten subprocesses, one per host, and lets them run in parallel. Each subprocess (a "worker") needs to ask the parent (the " master") for things: the current config for its host, permission to ask the user a question, a place to push updated values back to. v8 ships a rewritten version of that master and worker plumbing. This post walks through what is in there, and why.
If you ever passed a user-supplied string into a shell command from PHP, you have probably written something like this:
$cmd = 'grep ' . escapeshellarg($pattern) . ' file.log';
shell_exec($cmd);
It looks right, and most of the time it works. But escapeshellarg() has a few quirks that matter a lot when you are
running commands across many hosts, with arbitrary user input, in arbitrary locales. Deployer v8 replaces every internal
call to escapeshellarg() with a new quote() function. This post explains why.
After a long road through alpha, beta, and release candidates, Deployer v8 is finally out. This release modernizes the foundations of Deployer, introduces a new recipe format, and tightens up many of the rough edges that accumulated over the v7 cycle.
Deployer v8 introduces MAML-based recipes as a replacement for YAML, while PHP recipes remain unchanged. This shift raises an important question: why move from YAML to MAML? In this blog post, I will explain the rationale behind this decision.
{
import: ["recipe/common.php"]
hosts: {
"deployer.org": {
remote_user: "deployer"
deploy_path: "~/deployer.org"
}
}
tasks: {
deploy: [
"deploy:prepare"
"deploy:publish"
]
build: [
{ runLocally: "npm run clear" }
{ runLocally: "npm run build" }
]
"deploy:update_code": [
{
upload: {
src: "build/"
dest: "{{release_path}}"
}
}
]
}
}
We're excited to announce the release of the Official Deployer Docker Image! This image simplifies the deployment process for anyone using Deployer, providing a pre-configured environment ready to handle your deployment tasks right out of the box.
It's hard to believe that Deployer has been around for a decade. What started as a small tool, born out of frustration with setting up Ruby for deployment, has now grown into one of the de facto standards for deploying PHP applications. Today, millions of websites rely on Deployer, and over the past ten years, we've powered more than a 1 000 000 000 deployments.
As we look to the future, we're excited about what's coming. We've got a host of new features in the pipeline, all designed to make your deployment process even smoother and more efficient. And after ten years, it's also the perfect time to refresh our look. Here it is, fresh for the next chapter of Deployer.