SlideShare una empresa de Scribd logo
1 de 60
Descargar para leer sin conexión
Separation
of Concerns
with Docker
and Containers
1 / 60
Who am I?
Jérôme Petazzoni (@jpetazzo)
French software engineer living in California
Joined Docker (dotCloud) more than 4 years ago
(I was at Docker before it was cool!)
I have built and scaled the dotCloud PaaS
I learned a few things about running containers
(in production)
2 / 60
Outline
Intro / pop quizz about Docker and containers
VMs and containers: technical differences
VMs and containers: functional differences
Our goal: lean containers
Composing stacks of containers
3 / 60
Recap
about Docker
and containers
4 / 60
Build, ship, and run
any app, anywhere
5 / 60
Take any Linux program, and put it in a container
6 / 60
Take any Linux program, and put it in a container
Web apps and services, workers
(Go, Java, Node, PHP, Python, Ruby...)
7 / 60
Take any Linux program, and put it in a container
Web apps and services, workers
(Go, Java, Node, PHP, Python, Ruby...)
Data stores: SQL, NoSQL, big data
(Cassandra, ElasticSearch, Hadoop, Mongo, MySQL, PostgreSQL, Redis...)
8 / 60
Take any Linux program, and put it in a container
Web apps and services, workers
(Go, Java, Node, PHP, Python, Ruby...)
Data stores: SQL, NoSQL, big data
(Cassandra, ElasticSearch, Hadoop, Mongo, MySQL, PostgreSQL, Redis...)
Other server-y things
(Consul, Etcd, Mesos, RabbitMQ, Zookeeper...)
9 / 60
Take any Linux program, and put it in a container
Web apps and services, workers
(Go, Java, Node, PHP, Python, Ruby...)
Data stores: SQL, NoSQL, big data
(Cassandra, ElasticSearch, Hadoop, Mongo, MySQL, PostgreSQL, Redis...)
Other server-y things
(Consul, Etcd, Mesos, RabbitMQ, Zookeeper...)
Command-line tools
(AWS CLI, Ffmpeg...)
10 / 60
Take any Linux program, and put it in a container
Web apps and services, workers
(Go, Java, Node, PHP, Python, Ruby...)
Data stores: SQL, NoSQL, big data
(Cassandra, ElasticSearch, Hadoop, Mongo, MySQL, PostgreSQL, Redis...)
Other server-y things
(Consul, Etcd, Mesos, RabbitMQ, Zookeeper...)
Command-line tools
(AWS CLI, Ffmpeg...)
Desktop apps
(Chrome, LibreOffice, Skype, Steam...)
11 / 60
What about non-Linux programs?
12 / 60
What about non-Linux programs?
Desktop apps with WINE
(e.g.: Spotify client)
13 / 60
What about non-Linux programs?
Desktop apps with WINE
(e.g.: Spotify client)
Coming soon: Docker for Windows
(run Windows apps on Windows machines)
14 / 60
What about non-Linux programs?
Desktop apps with WINE
(e.g.: Spotify client)
Coming soon: Docker for Windows
(run Windows apps on Windows machines)
Coming soon: Docker for FreeBSD
(port in progress)
15 / 60
What about non-Linux programs?
Desktop apps with WINE
(e.g.: Spotify client)
Coming soon: Docker for Windows
(run Windows apps on Windows machines)
Coming soon: Docker for FreeBSD
(port in progress)
Coming eventually: Docker for OS X
(technically possible; but is this useful?)
16 / 60
Ship that container easily and efficiently
Docker comes with an image distribution protocol
Distribution server can be hosted by Docker Inc.
(free for public images)
Distribution protocol is public
Open source reference implementation
(used by Docker Inc. for the public registry)
Container images are broken down into layers
When updating and distributing an image,
only ship relevant layers
17 / 60
Run those containers anywhere
Containers can run in VMs or in physical machines
Docker is available on all modern Linux variants
Many IAAS providers have server images with Docker
On OS X and Windows dev machines: boot2docker
There are distros dedicated to run Docker containers
(Atomic, CoreOS, RancherOS, Snappy Core...)
Other Docker implementations exist (e.g. Joyent Triton)
Docker-as-a-Service providers are blooming
18 / 60
VMs and
containers:
technical
differences
19 / 60
Portability
Containers can run on top of public cloud
(run the same container image everywhere)
Nested hypervisors (VMs in VMs) exist, but still rare
Containers are easy to move
(thanks to layers, distribution protocol, registry...)
VM images have to be converted and transferred
(both are slow operations)
20 / 60
Format & environment
VM
executes machine code
environment = something that looks like a computer
JVM
executes JVM bytecode
environment = Java APIs
Container
executes machine code
environment = Linux kernel system calls interface
21 / 60
Containers have low overhead
Normal* process(es) running on top of normal kernel
No device emulation (no extra code path involved in I/O)
Context switch between containers
= context switch between processes
Benchmarks show no difference at all
between containers and bare metal
(after adequate tuning and options have been selected)
Containers have higher density
* There are extra "labels" denoting membership to given
namespaces and control groups. Similar to regular UID.
22 / 60
VMs have stronger isolation
Inter-VM communication must happen over the network
(Some hypervisors have custom paths, but non-standard)
VMs can run as non-privileged processes on the host
(Breaking out of a VM will have ~zero security impact)
Containers run on top of a single kernel
(Kernel vulnerability can lead to full scale compromise)
Containers can share files, sockets, FIFOs, memory areas...
(They can communicate with standard UNIX mechanisms)
23 / 60
Analogy: brick walls vs. room dividers
Brick walls
sturdy
slow to build
messy to move
Room dividers
fragile
deployed in seconds
moved easily
24 / 60
Blurring lines
Intel Clear Containers; Clever Cloud
(stripped down VMs, boot super fast, tiny footprint)
Joyent Triton
(Solaris "branded zones," running Linux binaries securely,
exposing the Docker API)
Ongoing efforts to harden containers
(GRSEC, SELinux, AppArmor)
25 / 60
VMs and
containers:
functional
differences
26 / 60
Inside
VMs need a full OS and associated tools
(Backups, logging, periodic job execution, remote access...)
Containers can go both ways:
machine container
(runs init, cron, ssh, syslog ... and the app)
application container
(runs the app and nothing else;
relies on external mechanisms)
27 / 60
VM lifecycle
Option 1: long lifecycle
(provisioning→update→update→…→update→disposal)
easily leads to configuration drift
(subtle differences that add up over time)
requires tight configuration management
Option 2: golden images
(phoenix servers, immutable infrastructure ...)
create new image for each modification
deploy by replacing old servers with new servers
nice and clean, but heavy and complex to setup
28 / 60
Container lifecycle
Containers are created from an image
Image creation is easy
Image upgrade is fast
Immutable infrastructure is easy to implement
Why? Because container snapshots are extremely fast and cheap.
29 / 60
Development process (VMs)
Best practice in production = 1 VM per component
Not realistic to have 1 VM per component in dev
Also: prod has additional/different components
(e.g.: logging, monitoring, service discovery...)
Result: very different environment for dev & prod
30 / 60
Development process (containers)
Run tons of containers on dev machines
Build the same container for dev & prod
How do we provide container variants?
31 / 60
Bloated containers
Containers have all the software required for production
In dev mode, only essential processes are started
In prod mode, additional processes run as well
Problems:
bigger containers
behavior can differ (because of extra processes)
extra processes duplicated between containers
hard to test those extra processes in isolation
32 / 60
Lean containers
33 / 60
Principle
"Do one thing, do it well"
One container for the component itself
One container for logging
One container for monitoring
One container for backups
One container for debugging (when needed)
etc.
34 / 60
Implementation (general principles)
Containers can share almost anything, selectively
files
(logs, data at rest, audit)
network stack
(traffic routing and analysis, monitoring)
process space, memory
(process tracing and debugging)
35 / 60
Let's dive
into the details
36 / 60
Logging (option 1: Docker logging drivers)
Containers write to standard output
Docker has different logging drivers:
writes to local JSON files by default
can send to syslog
Imperfect solution for now, but will be improved.
Preferred in the long run.
37 / 60
Logging (option 2: shared log directory)
Containers write regular files to a directory
That directory is shared with another container
dockerrun-d--namemyapp1-v/var/logmyapp:v1.0
In development setup:
dockerrun--volumes-frommyapp1ubuntu
sh-c'tail-F/var/log/*'
In production:
dockerrun-d--volumes-frommyapp1logcollector
38 / 60
Logging takeaways
Application can be "dumb" about logging
Log collection and shipping happens in Docker,
or in separate(s) container(s)
Run custom log analyzer without changing app container
(e.g. apachetop)
Migrate logging system without changing app container
39 / 60
"Yes, but..."
"What about performance overhead?"
no performance overhead
both containers access files directly
(just like processes running on the same machine)
"What about synchronization issues?"
same as previous answer!
40 / 60
Backups (file-based)
Store mutable data on Docker volumes
(same mechanism as for logs)
Share volumes with special-purpose backup containers
Put backup tools in the backup container
(boto, rsync, s3cmd, unison...)
dockerrun--volumes-frommydb1ubuntu
rsync-av/var/lib/backup@remotehost:mydb1/
The whole setup doesn't touch the app (or DB) container
41 / 60
Backups (network-based)
Run the backup job (pg_dump, mysqldump, etc.)
from a separate container
Advantages (vs. running in the same container):
nothing to install in the app (or DB) container
if the backup job runs amok, it remains contained (!)
another team can maintain backup jobs
(and be responsible for them)
42 / 60
Network analysis
Packet capture (tcpdump, ngrep, ntop, etc.)
Low-level metrics (netstat, ss, etc.)
Install required tools in a separate container image
Run a container in the same network namespace
dockerrun-d--nameweb1nginx
dockerrun-ti--netcontainer:web1tcpdump-pnieth0
dockerrun-ti--netcontainer:web1ubuntuss-n--tcp
43 / 60
Service discovery
Docker can do linking and generic DNS injection
Your code connects to e.g. redis
(pretending that redisresolves to something)
Docker adds a DNS alias* so that redisresolves
to the right container, or to some external service
In dev, Docker Compose manages service dependencies
In prod, you abstract service discovery from the container
* Really, an entry in the container's /etc/hosts.
44 / 60
Service discovery in practice
When service A needs to talk to service B...
1. Start container B on a Docker host
45 / 60
Service discovery in practice
When service A needs to talk to service B...
1. Start container B on a Docker host
2. Retrieve host+port allocated for B
46 / 60
Service discovery in practice
When service A needs to talk to service B...
1. Start container B on a Docker host
2. Retrieve host+port allocated for B
3. Start ambassador (relaying to this host+port)
47 / 60
Service discovery in practice
When service A needs to talk to service B...
1. Start container B on a Docker host
2. Retrieve host+port allocated for B
3. Start ambassador (relaying to this host+port)
4. Start container A linked to ambassador
48 / 60
Service discovery in practice
When service A needs to talk to service B...
1. Start container B on a Docker host
2. Retrieve host+port allocated for B
3. Start ambassador (relaying to this host+port)
4. Start container A linked to ambassador
5. Profit!
49 / 60
General pattern
Your code runs in the same container in dev and prod
Add "sidekick*" containers for additional tasks
Developers don't have to be bothered about ops
Ops can do their job without messing with devs' code
* Kubernetes sometimes calls them "sidecars."
50 / 60
Composing
stacks of
containers
51 / 60
Docker Compose
52 / 60
docker-compose.yml
rng:
build:rng
hasher:
build:hasher
webui:
build:webui
links:
-redis
ports:
-"80:80"
volumes:
-"webui/files/:/files/"
redis:
image:redis
worker:
build:worker
links:
-rng
-hasher
-redis
53 / 60
Docker Compose
Start whole stack with docker-composeup
Start individual containers (and their dependencies)
with docker-composeupxyz
Takes care of container lifecycle
(creation, update, data persistence, scaling up/down...)
Doesn't automatically solve networking and discovery (yet)
54 / 60
Docker Compose
Start whole stack with docker-composeup
Start individual containers (and their dependencies)
with docker-composeupxyz
Takes care of container lifecycle
(creation, update, data persistence, scaling up/down...)
Doesn't automatically solve networking and discovery (yet)
... However ...
55 / 60
docker-compose.yml, reloaded
hasher:
build:hasher
worker:
build:worker
links:
-rng
-hasherproxy:hasher
-redis
hasherproxy:
image:jpetazzo/hamba
links:
-hasher
command:80hasher80
(This was automatically generated by a tiny Python script.)
56 / 60
Heads up!
Docker networking is evolving quickly
Docker 1.7 (to be released Real Soon Now) will support:
"networks" as first class objects
multiple networks
overlay driver allowing to span networks across
multiple hosts
networking plugins from ecosystem partners
57 / 60
Conclusions
58 / 60
Conclusions
Containers can share more context than VMs
We can use this to decouple complexity
(think "microservices" but for ops/devs separation)
All tasks typically requiring VM access
can be done in separate containers
As a result, deployments are broken down
in smaller, simpler pieces
Complex stacks are expressed with simple YAML files
Docker isn't a "silver bullet" to solve all problems,
but it gives us tools that make our jobs easier
59 / 60
Thanks!
Questions?
@jpetazzo
@docker
60 / 60

Más contenido relacionado

Más de Jérôme Petazzoni

From development environments to production deployments with Docker, Compose,...
From development environments to production deployments with Docker, Compose,...From development environments to production deployments with Docker, Compose,...
From development environments to production deployments with Docker, Compose,...Jérôme Petazzoni
 
How to contribute to large open source projects like Docker (LinuxCon 2015)
How to contribute to large open source projects like Docker (LinuxCon 2015)How to contribute to large open source projects like Docker (LinuxCon 2015)
How to contribute to large open source projects like Docker (LinuxCon 2015)Jérôme Petazzoni
 
Containers, Docker, and Security: State Of The Union (LinuxCon and ContainerC...
Containers, Docker, and Security: State Of The Union (LinuxCon and ContainerC...Containers, Docker, and Security: State Of The Union (LinuxCon and ContainerC...
Containers, Docker, and Security: State Of The Union (LinuxCon and ContainerC...Jérôme Petazzoni
 
Anatomy of a Container: Namespaces, cgroups & Some Filesystem Magic - LinuxCon
Anatomy of a Container: Namespaces, cgroups & Some Filesystem Magic - LinuxConAnatomy of a Container: Namespaces, cgroups & Some Filesystem Magic - LinuxCon
Anatomy of a Container: Namespaces, cgroups & Some Filesystem Magic - LinuxConJérôme Petazzoni
 
Microservices. Microservices everywhere! (At OSCON 2015)
Microservices. Microservices everywhere! (At OSCON 2015)Microservices. Microservices everywhere! (At OSCON 2015)
Microservices. Microservices everywhere! (At OSCON 2015)Jérôme Petazzoni
 
Deploy microservices in containers with Docker and friends - KCDC2015
Deploy microservices in containers with Docker and friends - KCDC2015Deploy microservices in containers with Docker and friends - KCDC2015
Deploy microservices in containers with Docker and friends - KCDC2015Jérôme Petazzoni
 
Containers: from development to production at DevNation 2015
Containers: from development to production at DevNation 2015Containers: from development to production at DevNation 2015
Containers: from development to production at DevNation 2015Jérôme Petazzoni
 
Immutable infrastructure with Docker and containers (GlueCon 2015)
Immutable infrastructure with Docker and containers (GlueCon 2015)Immutable infrastructure with Docker and containers (GlueCon 2015)
Immutable infrastructure with Docker and containers (GlueCon 2015)Jérôme Petazzoni
 
The Docker ecosystem and the future of application deployment
The Docker ecosystem and the future of application deploymentThe Docker ecosystem and the future of application deployment
The Docker ecosystem and the future of application deploymentJérôme Petazzoni
 
Docker: automation for the rest of us
Docker: automation for the rest of usDocker: automation for the rest of us
Docker: automation for the rest of usJérôme Petazzoni
 
Docker Non Technical Presentation
Docker Non Technical PresentationDocker Non Technical Presentation
Docker Non Technical PresentationJérôme Petazzoni
 
Introduction to Docker, December 2014 "Tour de France" Bordeaux Special Edition
Introduction to Docker, December 2014 "Tour de France" Bordeaux Special EditionIntroduction to Docker, December 2014 "Tour de France" Bordeaux Special Edition
Introduction to Docker, December 2014 "Tour de France" Bordeaux Special EditionJérôme Petazzoni
 
Introduction to Docker, December 2014 "Tour de France" Edition
Introduction to Docker, December 2014 "Tour de France" EditionIntroduction to Docker, December 2014 "Tour de France" Edition
Introduction to Docker, December 2014 "Tour de France" EditionJérôme Petazzoni
 
Containers, Docker, and Microservices: the Terrific Trio
Containers, Docker, and Microservices: the Terrific TrioContainers, Docker, and Microservices: the Terrific Trio
Containers, Docker, and Microservices: the Terrific TrioJérôme Petazzoni
 
Containerization is more than the new Virtualization: enabling separation of ...
Containerization is more than the new Virtualization: enabling separation of ...Containerization is more than the new Virtualization: enabling separation of ...
Containerization is more than the new Virtualization: enabling separation of ...Jérôme Petazzoni
 
Pipework: Software-Defined Network for Containers and Docker
Pipework: Software-Defined Network for Containers and DockerPipework: Software-Defined Network for Containers and Docker
Pipework: Software-Defined Network for Containers and DockerJérôme Petazzoni
 
Docker Tips And Tricks at the Docker Beijing Meetup
Docker Tips And Tricks at the Docker Beijing MeetupDocker Tips And Tricks at the Docker Beijing Meetup
Docker Tips And Tricks at the Docker Beijing MeetupJérôme Petazzoni
 
Introduction to Docker at Glidewell Laboratories in Orange County
Introduction to Docker at Glidewell Laboratories in Orange CountyIntroduction to Docker at Glidewell Laboratories in Orange County
Introduction to Docker at Glidewell Laboratories in Orange CountyJérôme Petazzoni
 
Docker en Production (Docker Paris)
Docker en Production (Docker Paris)Docker en Production (Docker Paris)
Docker en Production (Docker Paris)Jérôme Petazzoni
 
Introduction to Docker at the Azure Meet-up in New York
Introduction to Docker at the Azure Meet-up in New YorkIntroduction to Docker at the Azure Meet-up in New York
Introduction to Docker at the Azure Meet-up in New YorkJérôme Petazzoni
 

Más de Jérôme Petazzoni (20)

From development environments to production deployments with Docker, Compose,...
From development environments to production deployments with Docker, Compose,...From development environments to production deployments with Docker, Compose,...
From development environments to production deployments with Docker, Compose,...
 
How to contribute to large open source projects like Docker (LinuxCon 2015)
How to contribute to large open source projects like Docker (LinuxCon 2015)How to contribute to large open source projects like Docker (LinuxCon 2015)
How to contribute to large open source projects like Docker (LinuxCon 2015)
 
Containers, Docker, and Security: State Of The Union (LinuxCon and ContainerC...
Containers, Docker, and Security: State Of The Union (LinuxCon and ContainerC...Containers, Docker, and Security: State Of The Union (LinuxCon and ContainerC...
Containers, Docker, and Security: State Of The Union (LinuxCon and ContainerC...
 
Anatomy of a Container: Namespaces, cgroups & Some Filesystem Magic - LinuxCon
Anatomy of a Container: Namespaces, cgroups & Some Filesystem Magic - LinuxConAnatomy of a Container: Namespaces, cgroups & Some Filesystem Magic - LinuxCon
Anatomy of a Container: Namespaces, cgroups & Some Filesystem Magic - LinuxCon
 
Microservices. Microservices everywhere! (At OSCON 2015)
Microservices. Microservices everywhere! (At OSCON 2015)Microservices. Microservices everywhere! (At OSCON 2015)
Microservices. Microservices everywhere! (At OSCON 2015)
 
Deploy microservices in containers with Docker and friends - KCDC2015
Deploy microservices in containers with Docker and friends - KCDC2015Deploy microservices in containers with Docker and friends - KCDC2015
Deploy microservices in containers with Docker and friends - KCDC2015
 
Containers: from development to production at DevNation 2015
Containers: from development to production at DevNation 2015Containers: from development to production at DevNation 2015
Containers: from development to production at DevNation 2015
 
Immutable infrastructure with Docker and containers (GlueCon 2015)
Immutable infrastructure with Docker and containers (GlueCon 2015)Immutable infrastructure with Docker and containers (GlueCon 2015)
Immutable infrastructure with Docker and containers (GlueCon 2015)
 
The Docker ecosystem and the future of application deployment
The Docker ecosystem and the future of application deploymentThe Docker ecosystem and the future of application deployment
The Docker ecosystem and the future of application deployment
 
Docker: automation for the rest of us
Docker: automation for the rest of usDocker: automation for the rest of us
Docker: automation for the rest of us
 
Docker Non Technical Presentation
Docker Non Technical PresentationDocker Non Technical Presentation
Docker Non Technical Presentation
 
Introduction to Docker, December 2014 "Tour de France" Bordeaux Special Edition
Introduction to Docker, December 2014 "Tour de France" Bordeaux Special EditionIntroduction to Docker, December 2014 "Tour de France" Bordeaux Special Edition
Introduction to Docker, December 2014 "Tour de France" Bordeaux Special Edition
 
Introduction to Docker, December 2014 "Tour de France" Edition
Introduction to Docker, December 2014 "Tour de France" EditionIntroduction to Docker, December 2014 "Tour de France" Edition
Introduction to Docker, December 2014 "Tour de France" Edition
 
Containers, Docker, and Microservices: the Terrific Trio
Containers, Docker, and Microservices: the Terrific TrioContainers, Docker, and Microservices: the Terrific Trio
Containers, Docker, and Microservices: the Terrific Trio
 
Containerization is more than the new Virtualization: enabling separation of ...
Containerization is more than the new Virtualization: enabling separation of ...Containerization is more than the new Virtualization: enabling separation of ...
Containerization is more than the new Virtualization: enabling separation of ...
 
Pipework: Software-Defined Network for Containers and Docker
Pipework: Software-Defined Network for Containers and DockerPipework: Software-Defined Network for Containers and Docker
Pipework: Software-Defined Network for Containers and Docker
 
Docker Tips And Tricks at the Docker Beijing Meetup
Docker Tips And Tricks at the Docker Beijing MeetupDocker Tips And Tricks at the Docker Beijing Meetup
Docker Tips And Tricks at the Docker Beijing Meetup
 
Introduction to Docker at Glidewell Laboratories in Orange County
Introduction to Docker at Glidewell Laboratories in Orange CountyIntroduction to Docker at Glidewell Laboratories in Orange County
Introduction to Docker at Glidewell Laboratories in Orange County
 
Docker en Production (Docker Paris)
Docker en Production (Docker Paris)Docker en Production (Docker Paris)
Docker en Production (Docker Paris)
 
Introduction to Docker at the Azure Meet-up in New York
Introduction to Docker at the Azure Meet-up in New YorkIntroduction to Docker at the Azure Meet-up in New York
Introduction to Docker at the Azure Meet-up in New York
 

Último

COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 

Último (20)

COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 

Implementing Separation of Concerns with Docker and Containers

  • 2. Who am I? Jérôme Petazzoni (@jpetazzo) French software engineer living in California Joined Docker (dotCloud) more than 4 years ago (I was at Docker before it was cool!) I have built and scaled the dotCloud PaaS I learned a few things about running containers (in production) 2 / 60
  • 3. Outline Intro / pop quizz about Docker and containers VMs and containers: technical differences VMs and containers: functional differences Our goal: lean containers Composing stacks of containers 3 / 60
  • 5. Build, ship, and run any app, anywhere 5 / 60
  • 6. Take any Linux program, and put it in a container 6 / 60
  • 7. Take any Linux program, and put it in a container Web apps and services, workers (Go, Java, Node, PHP, Python, Ruby...) 7 / 60
  • 8. Take any Linux program, and put it in a container Web apps and services, workers (Go, Java, Node, PHP, Python, Ruby...) Data stores: SQL, NoSQL, big data (Cassandra, ElasticSearch, Hadoop, Mongo, MySQL, PostgreSQL, Redis...) 8 / 60
  • 9. Take any Linux program, and put it in a container Web apps and services, workers (Go, Java, Node, PHP, Python, Ruby...) Data stores: SQL, NoSQL, big data (Cassandra, ElasticSearch, Hadoop, Mongo, MySQL, PostgreSQL, Redis...) Other server-y things (Consul, Etcd, Mesos, RabbitMQ, Zookeeper...) 9 / 60
  • 10. Take any Linux program, and put it in a container Web apps and services, workers (Go, Java, Node, PHP, Python, Ruby...) Data stores: SQL, NoSQL, big data (Cassandra, ElasticSearch, Hadoop, Mongo, MySQL, PostgreSQL, Redis...) Other server-y things (Consul, Etcd, Mesos, RabbitMQ, Zookeeper...) Command-line tools (AWS CLI, Ffmpeg...) 10 / 60
  • 11. Take any Linux program, and put it in a container Web apps and services, workers (Go, Java, Node, PHP, Python, Ruby...) Data stores: SQL, NoSQL, big data (Cassandra, ElasticSearch, Hadoop, Mongo, MySQL, PostgreSQL, Redis...) Other server-y things (Consul, Etcd, Mesos, RabbitMQ, Zookeeper...) Command-line tools (AWS CLI, Ffmpeg...) Desktop apps (Chrome, LibreOffice, Skype, Steam...) 11 / 60
  • 12. What about non-Linux programs? 12 / 60
  • 13. What about non-Linux programs? Desktop apps with WINE (e.g.: Spotify client) 13 / 60
  • 14. What about non-Linux programs? Desktop apps with WINE (e.g.: Spotify client) Coming soon: Docker for Windows (run Windows apps on Windows machines) 14 / 60
  • 15. What about non-Linux programs? Desktop apps with WINE (e.g.: Spotify client) Coming soon: Docker for Windows (run Windows apps on Windows machines) Coming soon: Docker for FreeBSD (port in progress) 15 / 60
  • 16. What about non-Linux programs? Desktop apps with WINE (e.g.: Spotify client) Coming soon: Docker for Windows (run Windows apps on Windows machines) Coming soon: Docker for FreeBSD (port in progress) Coming eventually: Docker for OS X (technically possible; but is this useful?) 16 / 60
  • 17. Ship that container easily and efficiently Docker comes with an image distribution protocol Distribution server can be hosted by Docker Inc. (free for public images) Distribution protocol is public Open source reference implementation (used by Docker Inc. for the public registry) Container images are broken down into layers When updating and distributing an image, only ship relevant layers 17 / 60
  • 18. Run those containers anywhere Containers can run in VMs or in physical machines Docker is available on all modern Linux variants Many IAAS providers have server images with Docker On OS X and Windows dev machines: boot2docker There are distros dedicated to run Docker containers (Atomic, CoreOS, RancherOS, Snappy Core...) Other Docker implementations exist (e.g. Joyent Triton) Docker-as-a-Service providers are blooming 18 / 60
  • 20. Portability Containers can run on top of public cloud (run the same container image everywhere) Nested hypervisors (VMs in VMs) exist, but still rare Containers are easy to move (thanks to layers, distribution protocol, registry...) VM images have to be converted and transferred (both are slow operations) 20 / 60
  • 21. Format & environment VM executes machine code environment = something that looks like a computer JVM executes JVM bytecode environment = Java APIs Container executes machine code environment = Linux kernel system calls interface 21 / 60
  • 22. Containers have low overhead Normal* process(es) running on top of normal kernel No device emulation (no extra code path involved in I/O) Context switch between containers = context switch between processes Benchmarks show no difference at all between containers and bare metal (after adequate tuning and options have been selected) Containers have higher density * There are extra "labels" denoting membership to given namespaces and control groups. Similar to regular UID. 22 / 60
  • 23. VMs have stronger isolation Inter-VM communication must happen over the network (Some hypervisors have custom paths, but non-standard) VMs can run as non-privileged processes on the host (Breaking out of a VM will have ~zero security impact) Containers run on top of a single kernel (Kernel vulnerability can lead to full scale compromise) Containers can share files, sockets, FIFOs, memory areas... (They can communicate with standard UNIX mechanisms) 23 / 60
  • 24. Analogy: brick walls vs. room dividers Brick walls sturdy slow to build messy to move Room dividers fragile deployed in seconds moved easily 24 / 60
  • 25. Blurring lines Intel Clear Containers; Clever Cloud (stripped down VMs, boot super fast, tiny footprint) Joyent Triton (Solaris "branded zones," running Linux binaries securely, exposing the Docker API) Ongoing efforts to harden containers (GRSEC, SELinux, AppArmor) 25 / 60
  • 27. Inside VMs need a full OS and associated tools (Backups, logging, periodic job execution, remote access...) Containers can go both ways: machine container (runs init, cron, ssh, syslog ... and the app) application container (runs the app and nothing else; relies on external mechanisms) 27 / 60
  • 28. VM lifecycle Option 1: long lifecycle (provisioning→update→update→…→update→disposal) easily leads to configuration drift (subtle differences that add up over time) requires tight configuration management Option 2: golden images (phoenix servers, immutable infrastructure ...) create new image for each modification deploy by replacing old servers with new servers nice and clean, but heavy and complex to setup 28 / 60
  • 29. Container lifecycle Containers are created from an image Image creation is easy Image upgrade is fast Immutable infrastructure is easy to implement Why? Because container snapshots are extremely fast and cheap. 29 / 60
  • 30. Development process (VMs) Best practice in production = 1 VM per component Not realistic to have 1 VM per component in dev Also: prod has additional/different components (e.g.: logging, monitoring, service discovery...) Result: very different environment for dev & prod 30 / 60
  • 31. Development process (containers) Run tons of containers on dev machines Build the same container for dev & prod How do we provide container variants? 31 / 60
  • 32. Bloated containers Containers have all the software required for production In dev mode, only essential processes are started In prod mode, additional processes run as well Problems: bigger containers behavior can differ (because of extra processes) extra processes duplicated between containers hard to test those extra processes in isolation 32 / 60
  • 34. Principle "Do one thing, do it well" One container for the component itself One container for logging One container for monitoring One container for backups One container for debugging (when needed) etc. 34 / 60
  • 35. Implementation (general principles) Containers can share almost anything, selectively files (logs, data at rest, audit) network stack (traffic routing and analysis, monitoring) process space, memory (process tracing and debugging) 35 / 60
  • 36. Let's dive into the details 36 / 60
  • 37. Logging (option 1: Docker logging drivers) Containers write to standard output Docker has different logging drivers: writes to local JSON files by default can send to syslog Imperfect solution for now, but will be improved. Preferred in the long run. 37 / 60
  • 38. Logging (option 2: shared log directory) Containers write regular files to a directory That directory is shared with another container dockerrun-d--namemyapp1-v/var/logmyapp:v1.0 In development setup: dockerrun--volumes-frommyapp1ubuntu sh-c'tail-F/var/log/*' In production: dockerrun-d--volumes-frommyapp1logcollector 38 / 60
  • 39. Logging takeaways Application can be "dumb" about logging Log collection and shipping happens in Docker, or in separate(s) container(s) Run custom log analyzer without changing app container (e.g. apachetop) Migrate logging system without changing app container 39 / 60
  • 40. "Yes, but..." "What about performance overhead?" no performance overhead both containers access files directly (just like processes running on the same machine) "What about synchronization issues?" same as previous answer! 40 / 60
  • 41. Backups (file-based) Store mutable data on Docker volumes (same mechanism as for logs) Share volumes with special-purpose backup containers Put backup tools in the backup container (boto, rsync, s3cmd, unison...) dockerrun--volumes-frommydb1ubuntu rsync-av/var/lib/backup@remotehost:mydb1/ The whole setup doesn't touch the app (or DB) container 41 / 60
  • 42. Backups (network-based) Run the backup job (pg_dump, mysqldump, etc.) from a separate container Advantages (vs. running in the same container): nothing to install in the app (or DB) container if the backup job runs amok, it remains contained (!) another team can maintain backup jobs (and be responsible for them) 42 / 60
  • 43. Network analysis Packet capture (tcpdump, ngrep, ntop, etc.) Low-level metrics (netstat, ss, etc.) Install required tools in a separate container image Run a container in the same network namespace dockerrun-d--nameweb1nginx dockerrun-ti--netcontainer:web1tcpdump-pnieth0 dockerrun-ti--netcontainer:web1ubuntuss-n--tcp 43 / 60
  • 44. Service discovery Docker can do linking and generic DNS injection Your code connects to e.g. redis (pretending that redisresolves to something) Docker adds a DNS alias* so that redisresolves to the right container, or to some external service In dev, Docker Compose manages service dependencies In prod, you abstract service discovery from the container * Really, an entry in the container's /etc/hosts. 44 / 60
  • 45. Service discovery in practice When service A needs to talk to service B... 1. Start container B on a Docker host 45 / 60
  • 46. Service discovery in practice When service A needs to talk to service B... 1. Start container B on a Docker host 2. Retrieve host+port allocated for B 46 / 60
  • 47. Service discovery in practice When service A needs to talk to service B... 1. Start container B on a Docker host 2. Retrieve host+port allocated for B 3. Start ambassador (relaying to this host+port) 47 / 60
  • 48. Service discovery in practice When service A needs to talk to service B... 1. Start container B on a Docker host 2. Retrieve host+port allocated for B 3. Start ambassador (relaying to this host+port) 4. Start container A linked to ambassador 48 / 60
  • 49. Service discovery in practice When service A needs to talk to service B... 1. Start container B on a Docker host 2. Retrieve host+port allocated for B 3. Start ambassador (relaying to this host+port) 4. Start container A linked to ambassador 5. Profit! 49 / 60
  • 50. General pattern Your code runs in the same container in dev and prod Add "sidekick*" containers for additional tasks Developers don't have to be bothered about ops Ops can do their job without messing with devs' code * Kubernetes sometimes calls them "sidecars." 50 / 60
  • 54. Docker Compose Start whole stack with docker-composeup Start individual containers (and their dependencies) with docker-composeupxyz Takes care of container lifecycle (creation, update, data persistence, scaling up/down...) Doesn't automatically solve networking and discovery (yet) 54 / 60
  • 55. Docker Compose Start whole stack with docker-composeup Start individual containers (and their dependencies) with docker-composeupxyz Takes care of container lifecycle (creation, update, data persistence, scaling up/down...) Doesn't automatically solve networking and discovery (yet) ... However ... 55 / 60
  • 57. Heads up! Docker networking is evolving quickly Docker 1.7 (to be released Real Soon Now) will support: "networks" as first class objects multiple networks overlay driver allowing to span networks across multiple hosts networking plugins from ecosystem partners 57 / 60
  • 59. Conclusions Containers can share more context than VMs We can use this to decouple complexity (think "microservices" but for ops/devs separation) All tasks typically requiring VM access can be done in separate containers As a result, deployments are broken down in smaller, simpler pieces Complex stacks are expressed with simple YAML files Docker isn't a "silver bullet" to solve all problems, but it gives us tools that make our jobs easier 59 / 60