Michael Irwin graduated from VT in 2011 and started using Docker for QA work in 2015. He attended his first DockerCon in 2016 and deployed Summit, his first production project using Docker, on AWS later that year. He started the Blacksburg Docker Meetup in 2016. In 2017, he was recognized as a Docker Captain. Docker provides containerization which isolates processes using kernel namespaces. Images are built from layers containing filesystem changes and metadata. Docker can be used to standardize environments for development, testing, and production.
2. ● 2011 - Graduated (CS@VT); started full-time at VT
● Sept 2015 - Started using Docker for QA
● June 2016 - Attended first DockerCon
● August 2016 - Deployed Summit (research admin app)
○ First production IT project using Docker
○ First IT project deployed on AWS
● Sept 2016 - Started Blacksburg Docker Meetup
○ Have met monthly since then
● March 2017 - Recognized as Docker Captain
4. “In order to truly utilize any technology,
you must first understand how it works
and its motivations.”
- Someone, somewhere (me, now)
6. ● NOT a VM, but simply an isolated process
● Isolation is provided by kernel namespaces
○ Process - PID 1 in container may be PID 3753 on host
○ Network - container can have its own network interfaces/IP address/sockets
○ Mount - container can have its own root filesystem/mountpoints
○ User - root/user ID 1 in container may actually be user ID 10976 on host
○ UTS - container gets its own hostname
9. ● A root filesystem
● Networking setup...
○ To let the container talk to the world
○ To let one container talk to others
○ To expose ports from container to host
● Various namespaces
● Launch the initial command
● Clean things up afterwards
10. Docker provides an integrated technology suite that enables development and IT
operations teams to build, ship, and run applications anywhere.
● Build - package an application with its dependencies and environment
● Ship - share the package with all deployment environments
● Run - run, scale, and monitor your application
12. ● Every image contains a manifest and a collection of layers
● Each layer consists of...
○ Metadata (json) - container config, reference to parent layer, etc
○ A tarball of filesystem diffs
13. Alpine Base Image
OpenJDK 9
Tomcat Wildfly
App 1 App 2 App 3
Apache httpd 2.4
PHP 7.1 PHP 5.6
App 4 App 5
● Layers can be reused by multiple children
○ Provides ability to have common base layers
● Since each layer is immutable, only one copy is needed
○ Reduces both registry and local storage requirements
14. ● Preferred method is to create a Dockerfile
● Text-based script with commands to configure/create filesystem layers
○ Allows it to be version controlled with a project
● Each command ends up being another layer in the Dockerfile
● Multi-stage builds allow final images to contain only runtime dependencies
FROM mvn:3.5-jdk8 AS build
WORKDIR /app
COPY . .
RUN mvn package
FROM tomcat:7-jre8-alpine
COPY --from=build /app/target/*.war /usr/local/tomcat/webapps
20. ● Development
○ Developer pulls environment images and code
○ Performs development in environment
○ Pushes code
● Staging/Production
○ Images pulled on to various infrastructure
(on-prem/cloud/hybrid)
● CI/CD Server
○ Builds code and runs automated test suites
○ Produces image using same environment base,
but with build artifact added
○ Push to image registry
21. ● Forces earlier collaboration with sysadmins
○ Do you actually trust your devs to come up with safe base images?
● Gives confidence that the app will work the same everywhere
○ Has allowed Summit to be deployed 49 times in the last year
● Images in registries can then be scanned for vulnerabilities!
23. OpenJDK 9 (VULNERABLE!!)
Tomcat Wildfly
App 1 App 2 App 3
● No longer need to go to each individual machine and patch
● Simply update images to point to patched parent
OpenJDK 9 (PATCHED)
Tomcat Wildfly
App 1 App 2 App 3
OpenJDK 9 (VULNERABLE!!)
Tomcat Wildfly
App 1 App 2 App 3
Alpine Base Image
27. ● Hosts only need to run containers
○ Reduces potential attack vectors
○ Reduces number of things that need to be patched
● Makes host machines easily replaceable
○ No need to have direct access to the machine to "make tweaks"
○ Lock yourself out of production
"Use container-specific host OSs instead of general-purpose ones to reduce attack surfaces. When using a
container-specific host OS, attack surfaces are typically much smaller than they would be with a general-purpose host
OS, so there are fewer opportunities to attack and compromise a container-specific host OS. Accordingly, whenever
possible, organizations should use container-specific host OSs to reduce their risk. However, it is important to note
that container-specific host OSs will still have vulnerabilities over time that require remediation."
-NIST draft Application Container Security Guide
28. ● Deployment (and patching) becomes…
○ Spin up new hosts
○ Start containers on new hosts
○ Transfer traffic to new containers
○ Burn down old machines
30. ● Base from official images as much as possible
● Keep images as minimal as possible
○ Install only what you need
○ Use multi-stage builds to keep final images focused
● Use --privileged very, very sparingly
○ Treat such a container as any other process running as root
● Run containers in read-only mode (if possible)
● Limit user capabilities by using AppArmor, seccomp, SELinux
● Sign images when pushing to repos using
● Use Docker Bench benchmark to evaluate container host security
31. ● Start experimenting… you’re already doing most of the work
● You don’t need to do everything Day One
○ Still deploy on the hosts you’re using, but move artifacts using Docker
32. ● Twitter - @mikesir87
● Email - mikesir@vt.edu
● Docker Blacksburg Meetup (or another one near your location)
● Docker Community Slack