doing the old thing the new way 
by @rafecolton
brief prologue 
“rafe” (rafecolton on the internets) 
software engineer, platform @ modcloth 
using docker in prod since v0.7.0 
*todo: explain “doing the old thing the new way”
obligatory slide with a bunch of logos
the stack that was
the stack that was
the stack that was
the stack that would be
motivations 
• simplify application architecture 
• support a variety of application languages 
• make provisioning and deployment more accessible
motivations 
• simplify application architecture 
• support a variety of application languages 
• make provisioning and deployment more accessible 
goals 
• push-button provisioning and deployment 
• consolidated, pluggable platform 
• move to linux
motivations 
• simplify application architecture 
• support a variety of application languages 
• make provisioning and deployment more accessible 
goals 
• push-button provisioning and deployment 
• consolidated, pluggable platform 
• move to linux 
bonus points 
• chatops 
• actual button for provisioning and deployment
motivations 
goals 
bonus points 
• chatops 
• actual button for provisioning and deployment 
does docker 
facilitate such a 
solution? 
• simplify application architecture 
• support a variety of application languages 
• make provisioning and deployment more accessible 
• push-button provisioning and deployment 
• consolidated, pluggable platform 
• move to linux
the stack that would be
case study: modcloth.com/style-gallery 
Clear and Simple Statement.
case study: modcloth.com/style-gallery
case study: modcloth.com/style-gallery
case study: modcloth.com/style-gallery 
webserver 
nginx ruby 
smartos 
rails
case study: modcloth.com/style-gallery 
webserver workers 
nginx ruby 
smartos 
rails 
sidekiq 
cron ruby 
smartos 
rails
case study: modcloth.com/style-gallery 
webserver 
nginx ruby 
smartos 
rails 
sidekiq 
workers 
cron ruby 
smartos 
rails 
how complex could it be?
case study: modcloth.com/style-gallery 
webserver 
rails 
ruby nginx 
docker 
ubuntu
case study: modcloth.com/style-gallery 
webserver 
rails 
ruby nginx 
docker 
ubuntu 
cron
case study: modcloth.com/style-gallery 
webserver 
rails 
ruby nginx 
docker 
ubuntu 
cron 
supervisord
case study: modcloth.com/style-gallery 
webserver 
rails 
ruby nginx 
docker 
ubuntu 
cron 
supervisord 
sidekiq 
workers 
rails
case study: modcloth.com/style-gallery 
webserver 
rails 
ruby nginx 
cron 
supervisord 
docker 
ubuntu 
sidekiq 
workers 
rails 
nad 
nodejs rsyslogd 
sshd
challenges 
• overall complexity 
• maintainability 
• image consistency 
• container reliability 
• log aggregation 
• monitoring
challenges 
• overall complexity 
• maintainability 
• image consistency 
• container reliability 
• log aggregation 
• monitoring 
lessons 
• don’t do the new thing the old way 
• consider division of responsibility
case study: modcloth.com/style-gallery 
webserver 
rails 
ruby 
rails 
docker cron 
ubuntu 
nginx 
sidekiq 
workers 
ruby 
nad 
nodejs rsyslogd
the stack
observations 
docker is an excellent packaging and distribution system
observations 
docker is an excellent packaging and distribution system 
containers are the canonical building block for a continuous delivery pipeline
begin github search… 
projects for orchestrating containers: 
• docker/fig 
• deis/deis 
• flynn/flynn 
• coreos/fleet 
• ansible/ansible 
• opscode/chef 
• progrium/dokku 
• newrelic/centurion
begin github search… 
• docker/fig 
• deis/deis 
• flynn/flynn 
• coreos/fleet 
• ansible/ansible 
• opscode/chef 
• progrium/dokku 
• newrelic/centurion 
• mesosphere/marathon 
• airbnb/chronos 
• GoogleCloudPlatform/kubernetes 
• openshift/geard 
• VoltFramework/volt 
projects for orchestrating containers:
• docker/fig 
• deis/deis 
• flynn/flynn 
• coreos/fleet 
• ansible/ansible 
• opscode/chef 
• progrium/dokku 
• newrelic/centurion 
• mesosphere/marathon 
• airbnb/chronos 
• GoogleCloudPlatform/kubernetes 
• openshift/geard 
• VoltFramework/volt 
• octohost/octohost 
• makeusabrew/decking 
• signalfuse/maestro-ng 
• shipyard/shipyard 
• DevTable/gantryd 
• mcuadros/dockership 
• longshoreman/longshoreman 
• marmelab/gaudi 
• etc. 
begin github search… 
projects for orchestrating containers:
begin github search… 
projects for building containers: 
• rafecolton/docker-builder 
• mitchellh/packer 
• swipely/dockly 
• ???
observation 
everybody is building containers differently.
observation 
everybody is building containers differently. 
how do we build production-ready containers?
writing a good Dockerfile 
lesson 0: getting started
writing a good Dockerfile 
lesson 0: getting started use a docker hub base
writing a good Dockerfile 
lesson 0: getting started 
set your env
writing a good Dockerfile 
lesson 1: order matters 
deps before bundling
writing a good Dockerfile 
lesson 1: order matters 
ADD only Gemfile* first
writing a good Dockerfile 
lesson 1: order matters 
`ADD .` as late as possible
writing a good Dockerfile 
lesson 2: optimize for size, repeatability 
combine RUN commands 
whenever possible
writing a good Dockerfile 
lesson 2: optimize for size, repeatability 
RUN dependent 
steps together
writing a good Dockerfile 
lesson 3: use a standard entrypoint 
use a *simple* 
entrypoint script
writing a good Dockerfile 
lesson 3: use a standard entrypoint 
operate on docker-specific 
environment variables
writing a good Dockerfile 
lesson 3: use a standard entrypoint 
wrap verbose 
CMD options
writing a good Dockerfile 
lesson 3: use a standard entrypoint 
exec "$@" # give yourself a shell
the image development lifecycle 
build 
*type things* push 
tag
the image development lifecycle 
> docker build -t myapp:latest . 
> export latest="$(docker images | grep myapp:latest | head -n 1 | awk '{print $3}’)" 
> docker tag $latest "$(git rev-parse -q HEAD)" # sha 
> docker tag $latest "$(git describe --always --dirty --tags)" # tag 
> docker tag $latest "$(git rev-parse -q --abbrev-ref HEAD)" # branch 
> for image in $(docker images | grep myapp | awk '{print $1 ":" $2}' | head -n 4) ;  
push 
do docker push $image ; done 
build 
tag 
*type things*
the image development lifecycle: docker-builder 
push 
build 
tag 
> docker-builder build . 
*type things*
teh pipeline 
docker build 
server* 
app 
app 
app 
app 
*https://github.com/rafecolton/docker-builder
conclusion 
building containers is like writing ruby code:
conclusion 
building containers is like writing ruby code: 
it’s easy to do 
it’s hard to do correctly
so what did we learn? (or, through what did you sleep?) 
stuff: 
• the complexity will come naturally (so don’t force it) 
• be intentional about your Dockerfile
so what did we learn? (or, through what did you sleep?) 
stuff: 
• the complexity will come naturally (so don’t force it) 
• be intentional about your Dockerfile 
• docker is an excellent packaging and distribution system 
• containers are the canonical building blocks
so what did we learn? (or, through what did you sleep?) 
stuff: 
• the complexity will come naturally (so don’t force it) 
• be intentional about your Dockerfile 
• docker is an excellent packaging and distribution system 
• containers are the canonical building blocks 
• consider division of responsibility between the host and the container 
• don’t do the new thing the old way (do the old thing the new way!)
brief epilogue 
goal: move to linux 
=> all apps (less one) now employing docker/ansible/linux
brief epilogue 
goal: move to linux 
=> all apps (less one) now employing docker/ansible/linux 
goal: consolidated, pluggable platform 
=> shared monitoring, log aggregation, & load balancing services
brief epilogue 
goal: move to linux 
=> all apps (less one) now employing docker/ansible/linux 
goal: consolidated, pluggable platform 
=> shared monitoring, log aggregation, & load balancing services 
goal: push-button provisioning and deployment 
=> it works, minimal magic… and it’s well documented
brief epilogue 
goal: move to linux 
=> all apps (less one) now employing docker/ansible/linux 
goal: consolidated, pluggable platform 
=> shared monitoring, log aggregation, & load balancing services 
goal: push-button provisioning and deployment 
=> it works, minimal magic… and it’s well documented 
could easily be maintained by only two people… dun dun dun
brief epilogue 
I’m job hunting…
brief epilogue 
I’m job hunting… 
…and I haven’t shot anything yet. 
so if you’re hiring, come talk to me after the show. 
twitter: @rafecolton 
github: rafecolton 
rafecolton.com
thank you

Dockercon EU 2014

  • 1.
    doing the oldthing the new way by @rafecolton
  • 2.
    brief prologue “rafe”(rafecolton on the internets) software engineer, platform @ modcloth using docker in prod since v0.7.0 *todo: explain “doing the old thing the new way”
  • 3.
    obligatory slide witha bunch of logos
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
    motivations • simplifyapplication architecture • support a variety of application languages • make provisioning and deployment more accessible
  • 9.
    motivations • simplifyapplication architecture • support a variety of application languages • make provisioning and deployment more accessible goals • push-button provisioning and deployment • consolidated, pluggable platform • move to linux
  • 10.
    motivations • simplifyapplication architecture • support a variety of application languages • make provisioning and deployment more accessible goals • push-button provisioning and deployment • consolidated, pluggable platform • move to linux bonus points • chatops • actual button for provisioning and deployment
  • 11.
    motivations goals bonuspoints • chatops • actual button for provisioning and deployment does docker facilitate such a solution? • simplify application architecture • support a variety of application languages • make provisioning and deployment more accessible • push-button provisioning and deployment • consolidated, pluggable platform • move to linux
  • 12.
  • 13.
    case study: modcloth.com/style-gallery Clear and Simple Statement.
  • 14.
  • 15.
  • 16.
    case study: modcloth.com/style-gallery webserver nginx ruby smartos rails
  • 17.
    case study: modcloth.com/style-gallery webserver workers nginx ruby smartos rails sidekiq cron ruby smartos rails
  • 18.
    case study: modcloth.com/style-gallery webserver nginx ruby smartos rails sidekiq workers cron ruby smartos rails how complex could it be?
  • 19.
    case study: modcloth.com/style-gallery webserver rails ruby nginx docker ubuntu
  • 20.
    case study: modcloth.com/style-gallery webserver rails ruby nginx docker ubuntu cron
  • 21.
    case study: modcloth.com/style-gallery webserver rails ruby nginx docker ubuntu cron supervisord
  • 22.
    case study: modcloth.com/style-gallery webserver rails ruby nginx docker ubuntu cron supervisord sidekiq workers rails
  • 23.
    case study: modcloth.com/style-gallery webserver rails ruby nginx cron supervisord docker ubuntu sidekiq workers rails nad nodejs rsyslogd sshd
  • 24.
    challenges • overallcomplexity • maintainability • image consistency • container reliability • log aggregation • monitoring
  • 25.
    challenges • overallcomplexity • maintainability • image consistency • container reliability • log aggregation • monitoring lessons • don’t do the new thing the old way • consider division of responsibility
  • 26.
    case study: modcloth.com/style-gallery webserver rails ruby rails docker cron ubuntu nginx sidekiq workers ruby nad nodejs rsyslogd
  • 27.
  • 28.
    observations docker isan excellent packaging and distribution system
  • 29.
    observations docker isan excellent packaging and distribution system containers are the canonical building block for a continuous delivery pipeline
  • 30.
    begin github search… projects for orchestrating containers: • docker/fig • deis/deis • flynn/flynn • coreos/fleet • ansible/ansible • opscode/chef • progrium/dokku • newrelic/centurion
  • 31.
    begin github search… • docker/fig • deis/deis • flynn/flynn • coreos/fleet • ansible/ansible • opscode/chef • progrium/dokku • newrelic/centurion • mesosphere/marathon • airbnb/chronos • GoogleCloudPlatform/kubernetes • openshift/geard • VoltFramework/volt projects for orchestrating containers:
  • 32.
    • docker/fig •deis/deis • flynn/flynn • coreos/fleet • ansible/ansible • opscode/chef • progrium/dokku • newrelic/centurion • mesosphere/marathon • airbnb/chronos • GoogleCloudPlatform/kubernetes • openshift/geard • VoltFramework/volt • octohost/octohost • makeusabrew/decking • signalfuse/maestro-ng • shipyard/shipyard • DevTable/gantryd • mcuadros/dockership • longshoreman/longshoreman • marmelab/gaudi • etc. begin github search… projects for orchestrating containers:
  • 33.
    begin github search… projects for building containers: • rafecolton/docker-builder • mitchellh/packer • swipely/dockly • ???
  • 34.
    observation everybody isbuilding containers differently.
  • 35.
    observation everybody isbuilding containers differently. how do we build production-ready containers?
  • 36.
    writing a goodDockerfile lesson 0: getting started
  • 37.
    writing a goodDockerfile lesson 0: getting started use a docker hub base
  • 38.
    writing a goodDockerfile lesson 0: getting started set your env
  • 39.
    writing a goodDockerfile lesson 1: order matters deps before bundling
  • 40.
    writing a goodDockerfile lesson 1: order matters ADD only Gemfile* first
  • 41.
    writing a goodDockerfile lesson 1: order matters `ADD .` as late as possible
  • 42.
    writing a goodDockerfile lesson 2: optimize for size, repeatability combine RUN commands whenever possible
  • 43.
    writing a goodDockerfile lesson 2: optimize for size, repeatability RUN dependent steps together
  • 44.
    writing a goodDockerfile lesson 3: use a standard entrypoint use a *simple* entrypoint script
  • 45.
    writing a goodDockerfile lesson 3: use a standard entrypoint operate on docker-specific environment variables
  • 46.
    writing a goodDockerfile lesson 3: use a standard entrypoint wrap verbose CMD options
  • 47.
    writing a goodDockerfile lesson 3: use a standard entrypoint exec "$@" # give yourself a shell
  • 48.
    the image developmentlifecycle build *type things* push tag
  • 49.
    the image developmentlifecycle > docker build -t myapp:latest . > export latest="$(docker images | grep myapp:latest | head -n 1 | awk '{print $3}’)" > docker tag $latest "$(git rev-parse -q HEAD)" # sha > docker tag $latest "$(git describe --always --dirty --tags)" # tag > docker tag $latest "$(git rev-parse -q --abbrev-ref HEAD)" # branch > for image in $(docker images | grep myapp | awk '{print $1 ":" $2}' | head -n 4) ; push do docker push $image ; done build tag *type things*
  • 50.
    the image developmentlifecycle: docker-builder push build tag > docker-builder build . *type things*
  • 51.
    teh pipeline dockerbuild server* app app app app *https://github.com/rafecolton/docker-builder
  • 52.
    conclusion building containersis like writing ruby code:
  • 53.
    conclusion building containersis like writing ruby code: it’s easy to do it’s hard to do correctly
  • 54.
    so what didwe learn? (or, through what did you sleep?) stuff: • the complexity will come naturally (so don’t force it) • be intentional about your Dockerfile
  • 55.
    so what didwe learn? (or, through what did you sleep?) stuff: • the complexity will come naturally (so don’t force it) • be intentional about your Dockerfile • docker is an excellent packaging and distribution system • containers are the canonical building blocks
  • 56.
    so what didwe learn? (or, through what did you sleep?) stuff: • the complexity will come naturally (so don’t force it) • be intentional about your Dockerfile • docker is an excellent packaging and distribution system • containers are the canonical building blocks • consider division of responsibility between the host and the container • don’t do the new thing the old way (do the old thing the new way!)
  • 57.
    brief epilogue goal:move to linux => all apps (less one) now employing docker/ansible/linux
  • 58.
    brief epilogue goal:move to linux => all apps (less one) now employing docker/ansible/linux goal: consolidated, pluggable platform => shared monitoring, log aggregation, & load balancing services
  • 59.
    brief epilogue goal:move to linux => all apps (less one) now employing docker/ansible/linux goal: consolidated, pluggable platform => shared monitoring, log aggregation, & load balancing services goal: push-button provisioning and deployment => it works, minimal magic… and it’s well documented
  • 60.
    brief epilogue goal:move to linux => all apps (less one) now employing docker/ansible/linux goal: consolidated, pluggable platform => shared monitoring, log aggregation, & load balancing services goal: push-button provisioning and deployment => it works, minimal magic… and it’s well documented could easily be maintained by only two people… dun dun dun
  • 61.
    brief epilogue I’mjob hunting…
  • 62.
    brief epilogue I’mjob hunting… …and I haven’t shot anything yet. so if you’re hiring, come talk to me after the show. twitter: @rafecolton github: rafecolton rafecolton.com
  • 63.