web dev

Deploying Web stacks DRY-ly with Ansible, Part 2: Users and Logins

 
In the last part we began by setting up the core infrastructure necessary to stand up a new server using automation and Continuous Integration. A Gitlab instance serves as the repository, with Gitlab CI connecting to the target server to deploy playbooks and execute Ansible. Our playbooks were surprisingly sparse due to the fact we relied on Ansible Roles to do most of the heavy lifting. Now, all we need to do is push code to our infrastructure repository, and CI will configure the server for us.

Deploying Web stacks DRY-ly with Ansible, Part 1: Infrastructure

 
I've been working on a new site for the last several months. It runs great locally, but when I started thinking of putting it on a live server, I ran into a series of problems. I was hoping that I could simply upgrade my web server from PHP 5.6 to PHP 7, then deploy my Drupal 8 site in place. Sounds simple, right? unfortunately, PHP 7 introduced compatibility-breaking changes which caused problems for my old, Drupal 7-powered site. If I wanted to install both PHP 5.6 and PHP 7 on the same server, I...

Docker From Scratch, Part 5: Custom Entrypoints and Configuration

 
In the last post, we introduced Docker Compose. Now, instead of looking up image IDs, managing our containers requires only a few easy to remember commands. We also used volumes to sync a directory on the host OS to the container for easier development. The wonderful thing about Docker Compose is that it can manage more than one container at a time. We can create multiple containers and manage them all as if they were part of the same, cohesive whole. In this post, we’re going to expand our...

Docker from Scratch, Part 4: Compose and Volumes

 
In the last post, we’ve created a repeatable web server container using a single file, the Dockerfile. While this is great, there’s one big limitation to a Dockerfile: It can only create one container. Docker containers are also only intended to run one process. What do we do if we want to run a web server, and a database, and a Solr instance, and a… We’d need to create a Dockerfile for each server process. Given that we’d need to call the Docker “run” command for each container, building...

Docker from Scratch, Part 3: Entrypoints and Ports

 
In the last post we used the RUN statement in our Dockerfile to setup and install software in our container. This saves us the trouble of creating build scripts that we need to run each time we start the container. We still have to specify the command to run when we start the container. What we want to do is eliminate that so we have less to remember each time we use the container. Background vs. Foreground Processes When a container is run, only a single process is run within it. Containers are less...