This document provides an overview of Docker including what it is, why it's useful, considerations around security, when and where it should be used, and examples of how three customers have implemented Docker. Docker allows for consistent packaging of applications and their environments, improved resource usage, and more rapid deployments. Key benefits include standardization, security, auditability, and bridging the gap between development and operations. Docker is well-suited for web applications, microservices, and environments requiring frequent deployments, while legacy applications may not be the best fit. The document outlines lessons learned around each customer case study.

1. Where and When to Docker
CAS20148
Dan Elder
Linux Services Manager
delder@novacoast.com
Ryan Trauntvein
Infrastructure & DevOps Lead
rtrauntvein@novacoast.com

2. 2
Agenda
• What is Docker
• Why Docker?
• What about security?
• Where to Docker
• Where not to Docker
• When to Docker
• When not to Docker
• Customer Use Cases
• Q&A

3. 3
CONTENT WARNING!!!!

4. 4
What is Docker?
• Containers for everyone.
• Consistent packaging environment for applications.
• A platform for developers and operations to build, ship,
and run application images.
• Containers run Linux apps on Linux hosts.
• Version control for not only app but entire environment.
• Included and fully supported in SLE 12 with extras like
Portus.

5. 5
Why Docker?
• Massive resource consolidation (~ 5X).
• Rapid and consistent deployments.
• Bridge gap between developers and operations.
• End-to-end audit trail and security controls.
• Standardization.
• Flexibility.

6. 6
What about security?
• No access to production (SSH, CLI, etc…)
• Stateless environment mitigates against APT
• Minimal images mean fewer attack vectors
• Deployment methodology allows for rapid response
• Full audit trail for entire lifecycle of deployment
• Breaks down communication barriers (Dev, Ops, Sec)
• Automation ensures consistency
• AppArmor and/or SELinux to confine everything

7. 7
Where to Docker
• Web applications
• Microservices
• Multiple instance deployments
• Complex dev to production deployments

8. 8
Where Not to Docker*
• Large, monolithic apps
• Complex legacy applications
• Complex GUI driven installations
• Single instance applications
*Unless you are brave

9. 9
When to Docker
• Testing/Deploying new applications
• Developing applications
• New projects/major upgrades
• All the time!

10. 10
When Not to Docker*
*Unless you are brave
• Non-Linux environments (for now)
• Already underway projects

11. 11
Customer A Environment
• ~ 130 existing web applications
• Elevated security requirements
• Limited IT support staff
• Large development staff
• Focus on automation and operational efficiency

12. 12
Customer A Use Case - Security
• Critical vulnerability discovered (shellshock)
• Vendor patch automatically mirrored to build server
• Automatic Docker image rebuilds based on severity
• Automated testing of images/applications
• Docker images pushed to production
• Load balancer directs traffic to new images
• Admin receives email notifying them of deployment
• < 30 Minutes from patch release to production

13. 13
Lessons Learned
• Docker is only part of the solution
• 12 Factor App* design is critical
• Tools are rapidly evolving
• Community is rapidly evolving
• Automating the whole workflow is key
* http://12factor.net/

14. 14
The Twelve Factors
I. Codebase
One codebase tracked in revision
control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing Services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
* http://12factor.net/

15. 15
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful
shutdown
The Twelve Factors

16. 16
The Twelve Factors
X. Dev/prod parity
Keep development, staging, and production as similar
as possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes

17. 17
Customer B Environment
• Multiple independent IT groups
• Little inter-group communication
• Lack of standardization and centralized management
• Change Control based
• Urgent need to re-build environment due to attacks

18. 18
Customer Use Case B
• Different IT groups control parts of the base images
• Base OS, Middleware, and Application images
• Testing and approval of merge requests
FROM SLES12
RUN zypper ref
RUN zypper in
FROM base
RUN zypper in ...
RUN setup.sh
FROM middleware
COPY /app /opt/
Base OS Image Middleware Image Application Image

19. 19
Lessons Learned
• DevOps doesn't solve internal politics
• Identify applications and stakeholders early
• Start with lower hanging fruit
• Establish quantifiable goals and metrics
• Build close relationships with vendors

20. 20
Customer Environment C
• Small Startup
• Few Developers
• Solo Sysadmin
• High Traffic web application
• Open Source technology stack
Sample Workflow

21. 21
Customer Use Case C
• Put everything into micro-service containers
• Backup scripts, maintenance task, utilities, the app
• SLE Docker host able to run any Linux Docker Image
• Easy to scale up or down

22. 22
Lessons Learned
• Passion matters
• Dockerizing the right environment is easy
• DevOps can be a force multiplier

23. 23

24. 24

25. 25
Docker Statistics
• 21,000+ GitHub Stars
• 400+ Million Docker Container Downloads
• 75,000+ Dockerized apps in Docker Hub
• 150+ Meetup groups in 50+ countries
• 900+ Community Contributors
• 50,000+ Third party projects using Docker
• Launched March 13th, 2013

26. Thank you.
26
Learn more about how Docker
and DevOps can work for you
www.novacoast.com/devops

27. Corporate Headquarters
Maxfeldstrasse 5
90409 Nuremberg
Germany
+49 911 740 53 0 (Worldwide)
www.suse.com
Join us on:
www.opensuse.org
27