Deployment

That code can be managed from within a VCS such as git so that  changes are attempted, shared, rolled forward and rolled back in a much more frictionless way than the traditional written specification documents or word-of-mouth configuration sharing (e.g. do this .... now try that ... no, OK then try this) described beautifully in Gene Kim's book The Phoenix Project.

 

Why all the scripting ?

It can then be harnessed for simpler, easier ways to build an deploy software 

  • For Development
    • Repeatable Development Environments
  • For Test ,
    • CI, testing Config and code often
  • For Release Readiness,
    • Less time/ obstacles to production, accredication checks, security testing made simpler
  • For Demand
    • Demos and other purposes

The toolbox

Vagrant is a Virtual Machine which uses another service (such as VirtualBox or AWS) as its provider.  You can launch many different types of Virtual Environments with Vagrant, but the most common is a Linux server.

Docker is not a full-fledged Virtual Machine, but rather a container.  Docker enables you to run instances of services/servers in a specific virtual environment.  A good example of this would be running a Docker container with Ruby on Rails on Ubuntu Linux.

 

Both Puppet and Chef are both languages that allow you to write scripts to quickly provision servers (including instances of Vagrant and/or Docker).  You don't need to use Puppet or Chef to setup these services, but sometimes they can be a quick way to do so.

 

oh and there's others, Ansible, Salt

Tool after Tool but what are they ?

First consider your situation in terms of the paradigm of production deployment (Containers vs. VMs).

  1. Vagrant allows developer an environment  - (VirtualBox Linux VM that acts as a Docker engine)
  2. It then provides the Docker container
  3. using  Docker to perform the basic configuration of that container
  4. including the installation of Puppet
  5. The detailed configuration of the container is done using Puppet after the Docker build has completed. During the Puppet provisioning, the container can leverage folder mappings from the host (both Vagrant host and Docker host)
  6. therefore the limitation on build context / any temporary files no longer apply. Anything Puppet can do can now be done – in a neat, declarative way – on the Docker Container

 

Hypothetical Deployment Workflow