development icon

Why You Should Add Outrigger to Your Development Toolkit

Chris Johnson, VP of Engineering
#Devops | Posted

A few months ago we announced the release of some Docker-based tooling we’ve developed at Phase2 over the past couple of years. Chances are pretty good that you’ve heard about Docker before, but in case you haven’t, let me set the stage for why we’re using it for development.

 outrigger logo

Why Use Docker for Development

 Prior to Docker, a typical developer’s workstation would use one of:

  • Virtual machine(s) crafted to mimic the production environment managed via Vagrant and Puppet

  • A generic virtual machine configured via PuPHPet to support development needs or pre configured options like DrupalVM when appropriate for the project.

  • A bevy of locally installed tools and services managed via whatever a developer was most comfortable with (something like brew or MAMP on OSX).

This hampered developers and team productivity in many ways:

  • Developers spent a lot of time juggling system administration type tasks or needed help in ensuring their environment was running properly.

  • Context switching between projects was tedious and time consuming due to the need to juggle configuration changes and/or switch virtual machines out due to resource consumption.

  • In cases where a custom VM had not been configured, software versions were constantly out of sync across the team.

  • A developer’s setup might be missing services present in the production infrastructure, typically things like caching servers.

  • Slightly (or vastly) different configuration options for things like web servers, database server, etc.

All of these hindrances fed into problems such as surprises on deploying changes to production, or an inability to troubleshoot observed issues on any other environment.

We’ve found using Docker for development leads to an enormous boost in productivity regardless of whether our clients are using it in deployed environments.

 

What Outrigger brings for Development

 At it’s core, Outrigger provides the following things: 

  • Transparent and performant use of local IDEs with code executed by a container

  • DNS services and network routing allowing access to project services through easy to remember and configure domain names

  • Exposure to underlying Docker ecosystem tools allowing a continuum from local development environments to CI to production hosting
     

Exposure to Underlying Docker Ecosystem Tools

Outrigger’s guiding goal is to ensure that the underlying Docker ecosystem and containers aren’t just part of the plumbing but are directly in your hands. This ensures that the components you learn about are useful even if you don’t use Outrigger in the future. Outrigger helps configure your Docker host with a few key elements to support the features listed above by providing some core services and configuration setup.

After that, your project uses tools like Docker Compose and any Docker images you want. If you have another tool for orchestrating your Docker containers, you are free to use that as well as long as you provide the necessary metadata upon which Outrigger relies. This gives you full control of the layers between you and your project environment.

developers using outrigger

Transparent Use of Local IDEs 

One of the core configurations that Outrigger provides allows you to work on code executed in a container with your IDE. This prevents the need to build your code into a volume container or set up deployment on save or other synchronization options.

This works due to the NFS setup that Outrigger configures automatically. Simply drop in a volume declaration in your Docker Compose file saying where to mount your code within the container and you are ready to go. We’re also working on some options, using unison, that dramatically improve the performance when dealing with projects with very large numbers of files which we plan to release soon.

 

Easy to Remember Access to Project Services

Outrigger allows for ease of integrating other tools with a project environment by allowing access to services using DNS. With Outrigger, you no longer have to look up and use IP addresses or manage a host file. You don’t need to figure out what random port a service is listening on due to pushing all services to a single address space. You don’t need to manage configuration across multiple projects so that they don’t conflict. You simply access a service on it’s standard port using an easy to remember DNS name like database.project.vm.

Outrigger provides this ease of connecting to services based on two key aspects of setting up your Docker host: network routing and DNS services. Outrigger configures routing to allow access to any service on any container from your host machine on the standard ports those services use. Combined with the use of DNSDock that means you can easily access your database at db.project-a.vm on port 3306 and your object caching service at redis.project-b.vm on port 6379.

To ensure these two pieces work you should make sure your containers run on the bridge network (172.17.0.0/16, use network_mode: “bridge” in your Docker compose configuration) and that you have the necessary DNSDock labels specified for containers you want to access using easy to remember DNS names.

 

Label Configuration

URL

com.dnsdock.image=project-b

http://project-b.vm

com.dnsdock.name=redis

http://redis.project-b.vm

  

Additional Approaches to Common Use Cases

Outrigger also demonstrates some different approaches for data persistence between container invocations, as well as ways that we offer container flexibility so that we spend more of our time using containers rather than building them. 

There are several Docker and non Docker based development tooling environments and each has made different tradeoffs and taken different approaches to common use cases. As someone who frequently sets up the project environment for a team, the control Outrigger offers, combined with the developer experience it offers, has been a great combo. I also like that I can use it with any container, not just those that are Drupal ecosystem related. 

Switching to containerization for our development tooling has been a very positive experience. It’s boosted efficiency and productivity in many ways, provided a simpler and better developer experience, and provided avenues for experimentation with this industry practice. Additionally, working with these technologies in our development tooling has allowed us to deal with many of the implications for continuous integration, packaging and deploying our work for clients. Using Outrigger can be valuable whether you’re new to containerization or if the Docker ecosystem is second nature to you.

Chris Johnson

VP of Engineering