Shrinking the container_zurich_july_2018

Shrinking the Container
@ewanslater

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
3

Take - aways
• Make smaller things
• Only pack what you need
• Use the smallest container
4

Software
12

Responsibility
13

When I wrote FORTRAN…
15
£140

16
£140 £40

17
£140 £40 £100

The less you care about,
The Happier you are
18

Enterprise Software
• Multiple responsibilities
• Difficult to deploy
• Difficult to scale
19

Lack of Agility
• “too big too fail”  “too difficult to change”
– Technical risk
– Political risk
• “it would take us two years to deploy hello world”
– Public sector customer Finland
20

All the Little Things
• Want better apps?
• Have them know as little as possible about each other
24
Talk by Sandi Metz https://youtu.be/8bZh5LMaSmE

Make smaller things*
* Things == Objects || Services || Applications
25

Small things* are easy to change
* Things == Objects || Services || Applications
26

Monoliths  Microservices

Microservices
• Do one thing well
• Loosely coupled
• Choreography > Orchestration
• Business capabilities not tech layers
28

Infrastructure
36

Diminished Responsibility
Server
• Hardware
• OS
• Multiple services and applications
VM
• OS
• Single service or application (typically)
Container
• Single service or application
43

A Case Study
44

SaaS Startup
• Monolithic Rails app
• Running on VMs
• Inflexible scaling (whole app only)
• Measure inflexibility in $
• Need to
– Improve Scalability
– Improve Utilisation
– Lower Costs
45

Splitting the Monolith
• Refactor app
• Set of Microservices
• Image per Microservice
• Choreography
46

Result
• Fine – grained scalability
• Event – driven
• Improved utilisation
• Lower costs
47

Houston, we have an opportunity…
48

…and a challenge…
49

“Docker makes building containers a breeze. Just put a standard Dockerfile
into your folder, run the docker ‘build’ command, and shazam! Your
container image is built!
The downside of this simplicity is that it’s easy to build huge containers full
of things you don’t need—including potential security holes.”
- Sandeep Dinesh, Google Developer Advocate
(see https://goo.gl/76GPcd)
51

Containers @ Oracle
52

Operational Differences
• Immutability
• Rebuild / Redeploy vs Patching
• Build toolchain vs Config Management tools
53

Worst Practices
• Developers without operational awareness
• Multiple applications per container
• Container Bloat
• Handling of security vulnerabilities
54

Security Matters
• Privilege escalation
– Whole Linux user space  bigger attack surface
– Compromise app  expose other vectors
• Vulnerability management
– Can’t patch a running container
– What does the app really need to run?
– What do I really need to patch?
55

Size Matters
• Large images
– Often > 1GB in size
– FROM Debian
– Alpine can help, but brings it’s own problems
• Bloat
– "You wanted a banana but what you got was a gorilla holding the banana and the
entire jungle" – Joe Armstrong
57

Enter Microcontainers
58

A Microcontainer
• Contains only
– Single executable
– Dependencies (of the executable)
• Runs with a read only root filesystem
• Files are all owned and read by a single user
59

Result
• Small image
• Fast, easy distribution
• Smaller attack surface
• Certainty over vulnerabilities
60

containers lean

Builder Pattern
• Development Dockerfile
– Creates “fat” development image
• Production Dockerfile
– Creates “lean” production image
• Build script to extract and copy
• Difficult to maintain
• Messy
64

Multi Stage Builds
• Single Dockerfile
• Create successive images
– (can use different bases)
• Copy from imagen to imagen+1
• Single, final image
65
Since Docker 17.05

If I had a hammer…
• Single layer
• Automatic Dependency Resolution
• Enables best practice:
– Single user
– Idempotent builds
– More secure images
• No overlayfs
69

Smith
• Open Source
– Apache License 2.0
– Universal Permissive License
• Command line tool for
– Building Microcontainer images
• yum repos
• rpm files
– Shrinking existing containers
• Standard image in  Microcontainer image out
71
http://github.com/oracle/smith

Process
• If shrinking
– Download image in OCI format
– Or point to URL
• Define a smith.yaml file
• Run smith
• Upload in OCI format to Docker repo
72

How it works:
Packages new OCI image
Creates single layer
Loads library search paths and recursively copies dependencies
Copies out files from paths in smith.yaml
Unpacks layers
75

For best results
• Build a Big Fat Image
• Hammer it with Smith
• Easier & quicker than Multi Stage Build
– YMMV
80
(unless you have a self contained binary)

What if…?
81

Don’t…
• Run sshd
• Login with ssh
• Embed debug tools
• Docker exec to get prompt
82

Challenges
• Can’t just mount a directory into the container on the fly
– Restart - may be difficult to recreate conditions
• Most tools expect to be in their own directory
• Paths
• Library conflicts
85

Requirements
• Debug tools happy with alternate location
• Static library dependencies  avoid conflict with container libraries
• Focus on solving problem, not hacking container.
86

Crashcart
• Open Source
– Apache License 2.0
– Universal Permissive License
• Simple command line tool
• “Sideloads” an image with Linux binaries (debug tools) into an existing
container
87
http://github.com/oracle/crashcart

Crashcart
• Attach to pid of container
• Mounts crashcart image
• Run binaries from crashcart image
• Detach & unmount
88

Get involved
• Fork Smith and Crashcart on GitHub
• Try the labs for Smith and Crashcart
• Get in touch via Slack
• Contribute
90

Take - aways
• Only pack what you need
• Use the smallest container
• Benefits
– Simplicity
– Agility
– Security
92

ewan.slater@oracle.com
@ewanslater
https://plus.google.com/+EwanSlater

Questions?
94

Shrinking the container_zurich_july_2018

Shrinking the container_zurich_july_2018

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Shrinking the container_zurich_july_2018

Similar a Shrinking the container_zurich_july_2018 (20)

Último

Último (20)

Shrinking the container_zurich_july_2018