dockers zero to hero

@ndeloof

Who  are  you  ?!

!

✓ Dev

✓ Integration/Test

✓ Acceptance / Qualif

✓ Sysdamin / Ops

level 0

DEV

✓Exact reproduction for target environment

!

!

!

!

Not  on  Linux  ?

DEV

✓Quickly get third party tools up-and-running

level 1

Test

✓ Define build / test infra in your SCM

✓ Quickly get low-cost iso-production environment

QA

level 2

Dev/Opsa WAR archive is NOT what a sysadmin expect as delivery !

!

+

best  DevOps  tool  so  far  (imho)

Separation  of  concernInside container /var/log/myapp

!

!

!

On host /mnt/backup/myapp/log

Separation  of  concerns

VOLUMEInside container /var/log/myapp

!

!

!

On host /mnt/backup/myapp/log

✓ Manage hardware / infrastructure

✓ Monitoring / backups

- Not apps « implementation details »

Ops

✓ Develop simplest possible solution

✓ Configuration is a runtime constraint

- Not extra-extra-flexibile application !

!

new WebServer().start(8080);

Dev

level 3

Continuous  Delivery

•100% Reproducible environments

« docker build . » to replace « mvn install »

Dockerfile build WAR from

sources

Dockerfile run acceptance

test suite

Dockerfile build deployable

container

docker run COPY

Continuous  Delivery

Pour  quoi  ?

!

✓ Cloud !

✓ devices !

✓ on-premises

more to come soon …

docker  @  Cloud

•« build and deploy » PaaS !

!

!

!

•binaries-based PaaS

 Google  and  Containers

“   Everything   at   Google,   from   Search   to   Gmail,   is  packaged  and  run  in  a  Linux  container.  !Each   week   we   launch   more   than   2   billion   container  instances  across  our  global  data  centers,  and  the  power  of   containers   has   enabled   both   more   reliable   services  and  higher,  more-­‐efficient  scalability.  “

http://googlecloudplatform.blogspot.fr/2014/06/an-update-on-container-support-on-google-cloud-platform.html

Compute Engine

your VM

Managed VM

your docker image

AppEngine runtime

your app

Google  Managed  VMflexibility management

 Bonus

Code gde-in

level 4

New architectures

Diviser  pour  mieux  régnerStop the monolithes ! !

!

!

!

!

!

!

Diviser  pour  mieux  régnerembrace Micro-services ‣ « the unix way »  ‣ domain focussed ‣ quick release cycles ‣ segregate resources !

!

http://yobriefca.se/blog/2013/04/29/micro-service-architecture/

!

Micro-­‐service  avec  Docker

LINK

host

sample  :  syslog

http://jpetazzo.github.io/2014/08/24/syslog-docker/

rsyslog

/dev/log

/tmp/syslogdev

logger "hello"

/dev/log

durée  de  vieUn serveur ou une VM : des mois, voir plus !

Un (ou des) containeur(s) : parfois juste quelques minutes !

Immutable  infrastructures

Upgrades

!

Upgrade applicatif = build d’une nouvelle image

What  about  CM  ?

pimp  my  Dockerfile

Dockerfile BUILD chef-solo

Dockerfile COPY /cookbooks

Orchestrate  Docker

load balancer

webapp

database replica

webapp

monitoring

cache- hosts: web sudo: yes tasks: - name: run tomcat servers docker: image=webapp ports=8080

level 5

En PROD si, si

Ops  is  cool  now  !

#o

#Sexists  you  said  ?

Système hôte minimaliste (160Mb RAM) cluster-ready service discovery etcd cgroup + systemd boot in ~ seconds

CoreOS

Apache  Mesos

schedule state N replicas for a service pod = containers tied together service discovery & routage !

Kubernetes

and  (lots)  more  «  orchestration  »

Kubeletmaestro-ng

Shipper

FleetHellios

Centurion

images: - name: jenkins_master source: ryfow/jenkins:0.2 type: Default ports: - host_port: '9080' container_port: '8080' proto: TCP volumes: - host_path: "/var/jenkins" container_path: "/var/jenkins_home" - name: jenkins_slave_1 source: ryfow/docker-jenkins-slave:0.2 type: Default links: - service: jenkins_master alias: jenkins environment: - variable: SLAVE_NAME value: slave1

{ "containers":[ { "name":"rockmongo", "count":1, "image":"openshift/centos-rockmongo", "publicports":[{"internal":80,"external":6060}], "links":[{"to":"mongodb"}] }, { "name":"mongodb", "count":1, "image":"openshift/centos-mongodb", "publicports":[{"internal":27017}] } ] }

name: demo registries: my-private-registry: registry: https://my-private-registry/v1/ ships: vm1.ore1: {ip: c414.ore1.domain.com} vm2.ore2: {ip: c415.ore2.domain.com, docker_port: 4243} services: zookeeper: image: zookeeper:3.4.5 instances: zk-1: ship: vm1.ore1 ports: {client: 2181, peer: 2888, leader_election: 3888} volumes: /var/lib/zookeeper: /data/zookeeper limits: memory: 1g cpu: 2

Distribute  Docker  images

•DockerHub private registry

•Run your own internal registry (docker image)

•Docker load/save with CM

•Dogistry / s3

Monitoring

•collect cgroup metrics

•cAdvisor

•dedicated docker plugin

LogScape

What  about  Data  ?

flocker

Container  live  migration

level 5

security

container  securityContainers are NOT secured !

!

!

!

!

!

http://blog.docker.com/2014/07/new-dockercon-video-docker-security-renamed-from-docker-and-selinux/

do  you  care  ?Treat containers like regular services !

✓ drop privileges as soon as possible

✓ run as non-root as much as possible

✓ treat root within container as root on host

✓ don’t run untrusted container

drop  capabilitiescapabilities - overview of Linux capabilities

!Description

!For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list).

!Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.

!CAP_NET_ADMIN, CAP_SYS_ADMIN, …

User  Name  SpaceMap non root user to root within container

AppArmor  /  SELinux

http://stopdisablingselinux.com/

Multi  Category  Security  (MCS)Protect containers from each other

level 42

DockerHJero

what’s next

disclaimer

de  facto  Standard  Adoption both for Cloud and on-premises !

!

!

!

!

ExtensibilityAlt. backends (AUFS is not an approved linux patch) ‣ devicemapper ‣ BTRFS ‣ ZFS ‣ …

!

Alt. implementations ‣ Solaris Zones ‣ BSD Jails

Tooling

Orchestration

securitysignature & authorization

Config  ManagementChef/Puppet/Salt/Ansible vs Docker

Q?