That Conference 2016 – Daring to Develop with Docker

That Conference 2016, Kalahari Resort, Lake Delton, WI
Daring to Develop with Docker – Philip Nelson, Omni Resources

Day 2, 9 Aug 2016

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2016 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Progression from bare metal to containers
  • Demoing Docker

Contact Info

github.com/panmanphil
twitter.com/panmanphil
panmanphil.wordpress.com

Docker and Containerized Apps

History: Bare Metal, VM, Docker

Racks of boxes

  • Manually installed hardware, software
  • Must configure everything
  • Deplyment lightly automated

Virtual machines

  • Software installed servers (guests)
  • Still manually configure
  • Lightly automated deployments
  • This is an improvement
    • Easier to provision hardware, servers, networks
    • Mainly helps IT admins

Devops

  • Intersection of Development, QA, Operations

Devops 1.0

  • Improvement: automated setup for your dev environments
  • E.g. Vagrant, Chef, Puppet, Ansible
    • These tools set up OS
  • Provisioning: setting up everything that you need for running your application
  • Drawbacks, trouble spots
    • Don’t always handle dependencies
    • Not quite complete
    • Took maybe 15-20 mins to set up box
    • Eventually, the host OS gets messy
  • Provisioners only useful at start for clean boxes
    • They don’t delete stuff

Containers

  • Slice VM up into smaller units
  • Automated OS setup, automated application setup, automated deployment
  • Each unit from application perspective, appears to own the OS
    • In reality, units share same kernel

Containers vs. VMs

  • VM
    • Each VM has guest OS, with shared libs and app
  • Container
    • Docker Engine on Host OS
    • Libraries on top, shared libraries across all applications
    • Then multiple instances of App on top of each set of shared libs

Docker Interactions

  • Containers
    • Commit (to image)
    • Run (from image)
  • Images
    • All files, code + binaries
    • Pull to Images from Registry
    • Only pull what’s different
    • Push to Registery after building

Containers – Building

  • Build machine
    • Pulls from git
    • Build app.jar
    • Upload to Docker Hub
  • Docker Hub
    • Run on production machine–docker run <app image>

Containers – Hosting Prior to 8/2016

  • Locally, create VM for running containers in
  • docker-machine create –driver virtualbox thatconference

Containers – Hosting Now

  • Containers run in native hypervisor on OS X or Win 10
  • Can still use docker-machine and separate collections of images, but most won’t do this

Containers – Running

  • You run with an image
  • docker run -d yourregistryname/yourimage
  • Map ports to host ports
  • Use volumes to persist data between different versions of image
    • Docker containers are immutable
    • Can save data that your application is running by using volumes

Containers – Demo

  • docker run -d mongo:latest
  • docker ps
    • What’s running on this box
    • Assigns random name to box
    • More detail with container id
  • docker logs namehere
  • docker inspect namehere
    • .json document that talks about how it was set up
  • Container is just a definition of what should run
  • Stopping
    • docker stop namehere
    • Containers not yet dead
  • docker ps -a
    • Containers stick around
  • Remove permanently
    • docker rm namehere

Run on Windows

  • Docker runs on both Win 10 and OS X
  • bash shell stuff a bit problematic on Windows
  • docker run -it hello
    • .NET Core on Debian
  • File changes not quite working–compiled even after no changes

Link Node.js container to Mongodb from command line

  • Networking established by container, no need to map external ports
    • Injects name of other containers
  • Run Mongo, run node-starter
    • -e MONGODB=mongodb://mongo:27017
    • –link mongo
  • Link will link to the other container

Containers – Volumes

  • Data will stay with running container only when it is defined, running or stopped
    • So if you start/stop the same container, the data will be there
  • But container definition is immutable
    • So data will go away if you remove container and start again
  • Volumes tell docker to manage longer term persistence of data independent of the container
    • As long as one guy is pointing to volume, it will remain
  • Use -v on command line

Demo – Volumes

  • docker run -it -docker-data –volumes-from mongo

Containers – Volumes

  • For working locally on rapidly changing code, can map any folder in container to host volume
  • Use -v command to map volume

Containers – Registry

  • Build image using docker build
    • docker build
  • After image is built, can be launched locally

Containers – Swarm

  • Make cluster out of docker machines and/or host machines
  • Docker swarm is part of base docker release
  • Some competitors, e.g. Amazon ECS
    • ECS “not that wonderful”

Containers – Troubleshooting

  • inspect
  • logs
  • docker ps
  • docker images
  • Log into running container
    • docker exec -t <name> /bin/bash
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s