development icon

A Day in the Life of Outrigger

Adam Ross, Software Architect
#Devops | Posted

In Outrigger: A Development Toolset that Makes the Easy Stuff Easy we introduced what Outrigger is.  In Why You Should Add Outrigger to Your Development Toolkit we answered why you might choose to use it. Today let’s talk about how to use it.

As a developer, your daily routine with your tools needs to be smooth and painless. Using the Outrigger example for Drupal 8 as inspiration, here is a typical workday experience on OSX.

Good Morning

Let’s get started by ensuring that our development environment is up and running and we’re able to communicate with it from our terminal session.

 

$> rig start

$> eval “$(rig config)”

 

 

The rig start command will spin up a virtual machine to serve as your Docker host including running the Docker daemon and the other out-of-box services that Outrigger provides such as the Dashboard and DNS Services. You can see all the details of what rig is doing by running any command in verbose mode, such as rig --verbose start.

Selecting a project to work with is as simple as navigating to the project, and spinning up its containers. For local development we use docker-compose, as that allows us to keep commands relatively short and easily manage our Docker configuration via version control.The rig start command will spin up a virtual machine to serve as your Docker host including running the Docker daemon and the other out-of-box services that Outrigger provides such as the Dashboard and DNS Services. You can see all the details of what rig is doing by running any command in verbose mode, such as rig --verbose start.

Our project has Outrigger configuration that gives us shortcuts for most common tasks to save the need to remember the docker-compose incantations. This includes a shortcut to perform all the project startup tasks as a one-liner:

 

$> rig project up

 

That is a nice shorthand for two operations you could run instead:

 

$> rig project sync:start

$> docker-compose up -d

 

 

By convention, projects that use Outrigger have a docker-compose.yml file which defines all the “operational” services of an application, such as the web server, database, and object cache. This command uses docker-compose up -d to enable those services, and flips on the high-performance filesystem so our build tasks have near-native performance.

Containers load pretty fast, so you are ready to direct your browser to www.d8.vm in just a few seconds, given a previously assembled/compiled codebase. The URL is defined in your docker-compose configuration and by convention is related to your project name.

You spend an hour coding to that new ticket, and the time comes to see how well it works. Before you can see the results of your change you know you need to clear the cache, but since your environment is running in a container and you don't even have PHP or Drush installed locally what do you do? Enter the build container.

The Outrigger Build Container provides the workspace you need to run command-line tools, and your project has already configured a handy service for running drush.

 

$> docker-compose -f build.yml run --rm drush cache-rebuild

 

 

Yes, it’s a long command. The need to swap in the alternate build container configuration from the build.yml file instead of relying on the default configuration is most of it. Adding a shell alias and using the short form of the drush commands dramatically reduces typing.

 

$> alias r=”docker-compose -f build.yml run --rm”

$> r drush cr

 

 

If shell aliases aren’t for you, you could also use the easier to remember run helper built-in to your project configuration:

 

$> rig project run drush cr

 

Good Afternoon

After a productive morning, you get back to the laptop looking forward to making some more forward momentum.

The problem of the afternoon is a bit more involved, and you are going to need to bring a few more tools to bear. Rather than running a few common commands or using some common tools, you need to go deeper into the terminal to complete your work.

Any command can be run via the CLI service in our build container and with our alias we can quickly list files via...

 

$> r cli ls

 

 

But when you have a series of commands or ones that need to chain together  it’s time to open a BASH session, in the manner of remote server work via SSH.

 

$> r cli

$container> ls

 

Good Evening

A bug report came in for an old project. Let’s spin down the current project and move over. (You could keep both running at the same time, that’s fine at the cost of some extra, though lighter system resource consumption.)

 

$> rig project stop

 

Next, spinning up the other project. It should just take a few seconds.

 

$> cd ~/Projects/OldProject

$> git pull

$> rig project up

$> r composer install

$> r drush updatedb -y

 

While the overhead of any given container is very low, the resource usage of the container depends on the memory and CPU usage of the process it is running, from a lightweight process like Apache to a heavy process like Jenkins.

Time to Shut Down

You do not need to shut down at the end of the day, but you want to start tomorrow with a fresh start:

 

$> rig stop

 

 

Now your containers, volumes, and virtual machine have all been spun down.

Wrapping Up

Working with Outrigger adds some additional conceptual overhead to your command-line usage, but stepping around that is easy. In exchange, you get a really smooth way to juggle projects and environments. Hopefully this example has conveyed how working with Outrigger feels in practice. In a future post we will talk more about advanced tricks to streamline local management of your project and its docker setup.

Adam Ross

Software Architect