Adrian Otto from Rackspace will present "Docker 102", This includes a summary of Docker 101 as a refresher from the August session, and builds upon that by discussing who should use a registry, and what options are available for keeping them private. We will discuss best practices for keeping your production environments evergreen with updated operating system environments, library dependencies, and maintaining an immutable infrastructure.

1. Docker 102
Immutable Infrastructure
Presented by: Adrian Otto
Prepared for: Docker Los Angeles
Date: September 10, 2014

2. Adrian Otto
• Principal Architect, Rackspace
• PTL, Solum
• Chair, OpenStack Containers Team
• Co-Chair, OASIS CAMP Technical Committee
2

3. 3
Quick Review of Docker 101

4. 4
Docker 101 Slides
http://www.slideshare.net/adrianjotto/docker-101-38986794
Please view slides above for my overview of Docker

5. 5
Immutable Infrastructure

6. Immutable
[ih-myoo-tuh-buh l]
adjective
1. Not mutable; unchangeable; changeless.
Origin:
1375-1425; late Middle English < Latin immūtābilis.
6

7. Immutable
I - Mute - The - Bull
7

8. What is Immutable Infrastructure?
• Utopia
– Applications are deployed, and code is never modified.
– Configuration is never modified (in place)
– Patches are never applied
– Only administrative actions are “deploy” and “destroy”.
8

9. Who Cares?
• Rationale
– Full Automation Means Consistency
– Re-Deploy More Often
– SHIP IT
– $$$
9

10. How?
• Any time you want to do a change to your app, redeploy.
• Any time you want to change your data schema, migration script.
10

11. 11
Techniques

12. Feature Flags
• Assumes you control the code in the application
• Wrap new features in conditions
• Activate conditions in accordance with appropriate risk
– By group
– By user settings
– By percentage of users
• De-Activate as needed (no re-deploy needed!)
12

13. Containerization with Docker
• Source repository contains a Dockerfile
• Build process produces a container
• Inject configuration using ENV key/pair values
• Use same container for test, stage, and prod
13

14. Limiting Downtime
• Green/Blue Deploy
1. Create live replica of database
2. Duplicate all application nodes with new code/config
3. Adjust routing (load balancer) to activate new code
14
App v1.0
App v1.0
App v1.1
App v1.1
Db v1.0
Db v1.1
LB

15. Limiting Risk
• Canary Deploy
1. Requires Feature Flags or Sticky LB Sessions
2. Back up your data
3. All nodes use the production database
4. Route new connections to new node(s)
15
App v1.0
LB App v1.0
Db v1.0
App v1.1

16. When to Use Canary
• No contract breaking changes to your data schema
– Or, you have an object versioned database
• You use feature flags
• Impractical to test the feature outside production
• Have a full backup of your data, and can restore
16

17. When to Use Blue/Green
• You are updating your data schema
• You don’t have an object versioned database
• You don’t have feature flags
• Can test the feature outside production
• Restoring from a backup is not practical (big data sets)
– Plan for the worst case scenario: Oops, my feature blew up!
17

18. 18
Orchestration

19. Imperative and Declarative
Imperative
– Define the process
– Sequenced steps
– Usually serialized
– Expressed as a script
Examples
– Shell scripts
– Puppet scripts
– Chef recipes
Declarative
– Define the outcome
– Ordering possible
– Good for parallel work
– Expressed as a DSL
Examples
– Fig
– Heat
– Solum
19

20. Tools to Help
• Solum and OpenStack
– Heat (HOT Files)
• Jenkins
• Ansible
• SaltStack
• Chef
20

21. Immutable Infrastructure with Docker
• Docker Public Registry
• Private Registry
– Run as a container (There be Dragons!)
– Run with Glance Backend (OpenStack)
– Run with Swift Backend (OpenStack)
– Run with S3 Backend (AWS)
• Docker Private Repos
– Example: adrianotto/private
– Not visible in the public registry
– Only you can push/pull to/from the repo
– 1 Private Repo is free
– 5 private repos free for 2 months with promo code: docker-los-angeles
– Allows for webhook integration
– Can be shared with other users
– Can be tagged
21

22. 22
https://hub.docker.com

23. Using a Private Repo
[root@example~]# docker login!
Username: h4x0r4u!
Password: !
Email: example@example.com!
[root@example~]# docker pull centos:centos6!
[root@example~]# docker run -i -t centos:centos6 /bin/bash!
bash-4.1# echo hello > hello.txt!
bash-4.1# exit!
[root@example~]# docker ps –a!
CONTAINER ID IMAGE COMMAND CREATED STATUS…!
f7485ea35f26 centos:centos6 /bin/bash 4 minutes ago Exited (0) 2…!
[root@example~]# docker commit f7485ea35f26 h4x0r4u/private!
1898aef1c36014b3702c3532263a9064ba928b78a9b2ccf44a101c61028179cd!
[root@example~]# docker images!
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE!
h4x0r4u/private latest 1898aef1c360 3 seconds ago 212.7 MB!
centos centos6 68eb857ffb51 1 day ago 212.7 MB!
23
Note: Private
repos can only
be seen by you

24. Updating Base Images
[root@example~]# docker images!
REPOSITORY TAG IMAGE ID CREATED VIRTUAL
SIZE!
centos centos6 b1bd49907d55 5 weeks ago 212.5 MB!
centos centos7 b157b77b1a65 5 weeks ago 243.7 MB!
centos latest b157b77b1a65 5 weeks ago 243.7 MB!
[root@example~]# docker pull centos:centos6!
68eb857ffb51: Download complete !
511136ea3c5a: Download complete !
34e94e67e63a: Download complete !
[root@example~]# docker images!
REPOSITORY TAG IMAGE ID CREATED VIRTUAL
SIZE!
centos centos6 68eb857ffb51 1 day ago 212.7 MB!
centos centos7 b157b77b1a65 5 weeks ago 243.7 MB!
centos latest b157b77b1a65 5 weeks ago 243.7 MB!
24
Hint: Automate
for evergreen
environment

25. 25