présentation de l'utilisation de Docker, du niveau 0 "je joue avec sur mon poste" au niveau Docker Hero "je tourne en prod". Ce talk fait suite à l'intro de @dgageot et ne comporte donc pas l'intro "c'est quoi Docker ?".

1. @ndeloof

4. Who
are
you
?
!
!
✓ Dev
✓ Integration/Test
✓ Acceptance / Qualif
✓ Sysdamin / Ops

5. level 0

6. DEV
✓Exact reproduction for
target environment
!
!
!
!

7. Not
on
Linux
?

8. DEV
✓Quickly get third party
tools up-and-running

9. level 1

10. Test
✓ Define build / test infra in your SCM

11. QA
✓ Quickly get low-cost iso-production environment

12. level 2

13. Dev/Ops
a WAR archive is NOT what a sysadmin expect as delivery
!
!
+

14. best
DevOps
tool
so
far
(imho)

15. Separation
of
concern
Inside container
/var/log/myapp
!
!
!
On host
/mnt/backup/myapp/log

16. Separation
of
concerns
Inside container
/var/log/myapp
VOLUME !
!
!
On host
/mnt/backup/myapp/log

17. Ops
✓ Manage hardware / infrastructure
✓ Monitoring / backups
- Not apps « implementation details »

18. ✓ Develop simplest possible solution
✓ Configuration is a runtime constraint
- Not extra-extra-flexibile application
!
!
new WebServer().start(8080);
Dev

19. level 3

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

21. Continuous
Delivery

22. Pour
quoi
?
!
✓ Cloud
!
✓ devices
more to come soon …
!
✓ on-premises

23. docker
@
Cloud
•« build and deploy » PaaS
!
!
!
!
•binaries-based PaaS

24. “
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
Google
and
Containers

25. your VM
your docker
image
Managed
VM
Compute Engine
your app
AppEngine
runtime
Google
Managed
VM
flexibility management

26. Bonus
Code
gde-in

27. level 4

28. New architectures

29. Diviser
pour
mieux
régner
Stop the monolithes !
!
!
!
!
!
!
!

30. Diviser
pour
mieux
régner
embrace Micro-services
‣ « the unix way »
‣ domain focussed
‣ quick release cycles
‣ segregate resources
!
!
http://yobriefca.se/blog/2013/04/29/micro-service-architecture/
!

31. Micro-­‐service
avec
Docker
LINK

32. sample
:
syslog
host
rsyslog
/dev/log
/tmp/syslogdev
logger "hello"
/dev/log
http://jpetazzo.github.io/2014/08/24/syslog-docker/

33. durée
de
vie
Un serveur ou une VM :
des mois, voir plus
!
Un (ou des) containeur(s) :
parfois juste quelques minutes
!

34. Immutable
infrastructures

35. Upgrades
!
Upgrade applicatif = build d’une nouvelle image

36. What
about
CM
?

37. pimp
my
Dockerfile
Dockerfile
BUILD chef-solo
Dockerfile
COPY /cookbooks

38. Orchestrate
Docker
load balancer
- hosts: web webapp
webapp
cache
monitoring
database replica
sudo: yes
tasks:
- name: run tomcat servers
docker: image=webapp ports=8080

39. level 5

40. En PROD si, si

41. Ops
is
cool
now
!
#o

42. #Sexists
you
said
?

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

44. Apache
Mesos

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

47. and
(lots)
more
«
orchestration
»
Kubelet
maestro-ng
Shipper
Fleet
Hellios
Centurion

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

49. Distribute
Docker
images
•DockerHub private registry
•Run your own internal registry (docker image)
•Docker load/save with CM
•Dogistry / s3

50. Monitoring
•collect cgroup metrics
•cAdvisor
•dedicated docker plugin
LogScape

51. What
about
Data
?

52. flocker

53. Container
live
migration

54. level 5

55. security

56. container
security
Containers are NOT secured
!
!
!
!
!
!
http://blog.docker.com/2014/07/new-dockercon-video-docker-
security-renamed-from-docker-and-selinux/

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

58. drop
capabilities
capabilities - 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, …

59. User
Name
Space
Map non root user to root within container

60. AppArmor
/
SELinux
http://stopdisablingselinux.com/

61. Multi
Category
Security
(MCS)
Protect containers from each other

62. level 42
DHocJkeerro

63. what’s next

64. disclaimer

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

66. Extensibility
Alt. backends (AUFS is not an approved linux patch)
‣ devicemapper
‣ BTRFS
‣ ZFS
‣ …
!
Alt. implementations
‣ Solaris Zones
‣ BSD Jails

67. Tooling

68. Orchestration

69. security
signature & authorization

71. Config
Management
Chef/Puppet/Salt/Ansible vs Docker

73. Q?