Successfully reported this slideshow.
Your SlideShare is downloading. ×

Dockers zero to hero

Dockers zero to hero

Download to read offline

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

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

More Related Content

Dockers zero to hero

  1. 1. @ndeloof
  2. 2. Who are you ? ! ! ✓ Dev ✓ Integration/Test ✓ Acceptance / Qualif ✓ Sysdamin / Ops
  3. 3. level 0
  4. 4. DEV ✓Exact reproduction for target environment ! ! ! !
  5. 5. Not on Linux ?
  6. 6. DEV ✓Quickly get third party tools up-and-running
  7. 7. level 1
  8. 8. Test ✓ Define build / test infra in your SCM
  9. 9. QA ✓ Quickly get low-cost iso-production environment
  10. 10. level 2
  11. 11. Dev/Ops a WAR archive is NOT what a sysadmin expect as delivery ! ! +
  12. 12. best DevOps tool so far (imho)
  13. 13. Separation of concern Inside container /var/log/myapp ! ! ! On host /mnt/backup/myapp/log
  14. 14. Separation of concerns Inside container /var/log/myapp VOLUME ! ! ! On host /mnt/backup/myapp/log
  15. 15. Ops ✓ Manage hardware / infrastructure ✓ Monitoring / backups - Not apps « implementation details »
  16. 16. ✓ Develop simplest possible solution ✓ Configuration is a runtime constraint - Not extra-extra-flexibile application ! ! new WebServer().start(8080); Dev
  17. 17. level 3
  18. 18. 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
  19. 19. Continuous Delivery
  20. 20. Pour quoi ? ! ✓ Cloud ! ✓ devices more to come soon … ! ✓ on-premises
  21. 21. docker @ Cloud •« build and deploy » PaaS ! ! ! ! •binaries-based PaaS
  22. 22. “ 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
  23. 23. your VM your docker image Managed VM Compute Engine your app AppEngine runtime Google Managed VM flexibility management
  24. 24. Bonus Code gde-in
  25. 25. level 4
  26. 26. New architectures
  27. 27. Diviser pour mieux régner Stop the monolithes ! ! ! ! ! ! ! !
  28. 28. 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/ !
  29. 29. Micro-­‐service avec Docker LINK
  30. 30. sample : syslog host rsyslog /dev/log /tmp/syslogdev logger "hello" /dev/log http://jpetazzo.github.io/2014/08/24/syslog-docker/
  31. 31. durée de vie Un serveur ou une VM : des mois, voir plus ! Un (ou des) containeur(s) : parfois juste quelques minutes !
  32. 32. Immutable infrastructures
  33. 33. Upgrades ! Upgrade applicatif = build d’une nouvelle image
  34. 34. What about CM ?
  35. 35. pimp my Dockerfile Dockerfile BUILD chef-solo Dockerfile COPY /cookbooks
  36. 36. Orchestrate Docker load balancer - hosts: web webapp webapp cache monitoring database replica sudo: yes tasks: - name: run tomcat servers docker: image=webapp ports=8080
  37. 37. level 5
  38. 38. En PROD si, si
  39. 39. Ops is cool now ! #o
  40. 40. #Sexists you said ?
  41. 41. CoreOS Système hôte minimaliste (160Mb RAM) cluster-ready service discovery etcd cgroup + systemd boot in ~ seconds
  42. 42. Apache Mesos
  43. 43. schedule state N replicas for a service pod = containers tied together service discovery & routage ! Kubernetes
  44. 44. and (lots) more « orchestration » Kubelet maestro-ng Shipper Fleet Hellios Centurion
  45. 45. 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
  46. 46. Distribute Docker images •DockerHub private registry •Run your own internal registry (docker image) •Docker load/save with CM •Dogistry / s3
  47. 47. Monitoring •collect cgroup metrics •cAdvisor •dedicated docker plugin LogScape
  48. 48. What about Data ?
  49. 49. flocker
  50. 50. Container live migration
  51. 51. level 5
  52. 52. security
  53. 53. container security Containers are NOT secured ! ! ! ! ! ! http://blog.docker.com/2014/07/new-dockercon-video-docker- security-renamed-from-docker-and-selinux/
  54. 54. 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
  55. 55. 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, …
  56. 56. User Name Space Map non root user to root within container
  57. 57. AppArmor / SELinux http://stopdisablingselinux.com/
  58. 58. Multi Category Security (MCS) Protect containers from each other
  59. 59. level 42 DHocJkeerro
  60. 60. what’s next
  61. 61. disclaimer
  62. 62. de facto Standard Adoption both for Cloud and on-premises ! ! ! ! !
  63. 63. Extensibility Alt. backends (AUFS is not an approved linux patch) ‣ devicemapper ‣ BTRFS ‣ ZFS ‣ … ! Alt. implementations ‣ Solaris Zones ‣ BSD Jails
  64. 64. Tooling
  65. 65. Orchestration
  66. 66. security signature & authorization
  67. 67. Config Management Chef/Puppet/Salt/Ansible vs Docker
  68. 68. Q?

×