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.
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
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
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