Docker Revisited

Tech Talk from 11 March 2015

Transcript

1. All content contained herein is property of Deep Focus. ©2012 All Rights Reserved. MARCH 11, 2015 TECH BREAKFAST #33 DOCKER REVISITED Mark Edgington
2. Greg sez: ¤  “People  on  the  internets  are  deba1ng  whether   Docker  is  a  good  thing….”  
3. AGENDA 1.  Life before Docker 2.  Review of Docker 3.  How is Docker being used? 4.  My experience with Docker 5.  Hands-on with Docker 6.  Conclusion
4. Life before Docker ¤  Before  Docker,  there  was  Vagrant  (among  other   alterna1ves)   –  Could  only  run  one  project  at  a  1me  (without  bringing  my   laptop  to  it’s  knees).   –  Slow  to  boot  up  and  bring  down   –  Took  up  enormous  space  on  my  machine  (was  constantly   running  out  of  space   –  If  VM  crashed  and  died,  I  lost  a  great  deal  and  had  to   rebuild  from  scratch   –  Spent  lots  of  1me  wri1ng  puppet  scripts;  some1mes  felt   more  like  a  sysadmin  than  a  developer   –  S1ll,  I  thought  it  was  great,  compared  to  earlier  alterna1ves    
5. Docker arrives ¤  When  Docker  appeared  on  the  scene  two  years  ago,  it   almost  seemed  too  good  to  be  true.   ¤  Could  it  really  do  all  that  was  being  claimed  for  it?     Time  to  check  it  out.  
6. Docker Review ¤  Docker  is  an  open  plaNorm  of  lightweight   containers  for  code  to  run  in.   ¤  It  is  similar  to  running  a  virtual  machine  but   without  the  huge  resource  demands  that  a   virtual  machine  requires.   ¤  The  overhead  for  running  a  docker  container  is   very  low.  You  can  theore1cally  run  thousands  of   containers  on  a  single  host.   ¤  Building  containers  is  fast,  because  containers   are  built  in  layers,  and  layers  are  cached.  
7. Images and Containers ¤  When  I  was  first  learning  about  Docker,  I   remember  being  somewhat  confused  by  images   and  containers   –  Think  of  images  as  being  like  CD-­‐ROMs:  you  can  pass   them  around  and  build  off  of  them,  but  the  images   themselves  are  read-­‐only  and  used  as  a  base.   –  Containers  are  created  by  by  star1ng  up  an  image.     They  are  vola1le  /  constantly  changing,  although   they  can  be  saved  into  a  new  image.    You  can  start   and  stop  them  at  will,  they  don’t  disappear.   –  Under  the  hood,  containers  are  adding  layers  on  top   of  their  base  image.    These  layers  are  union-­‐mount   directories:  when  you  first  create  a  container,  it  is   iden1cal  to  it’s  image.    All  the  files  and  directories   from  the  base  image  are  visible;  but  when  a  file  is   changed,  the  base  layer  is  copied  to  a  new  layer,  and   the  base  file  is  replaced  by  the  modified  file.  
8. How is Docker being used? 1.  Development  tool   2.  Tes0ng  tool   3.  Deployment  tool  
9. Docker as development tool A.  Personal   1.  Gives  you  an  isolated  sandbox  to  build  your   applica1on.       2.  You’re  always  star1ng  from  a  known  environment   3.  Allows  you  to  quickly  switch  between  projects   B.  Team   1.  Team  can  work  from  a  standardized  image.   2.  Easy  to  bring  someone  up  to  speed.   3.  No  installa1on  headaches.   4.  No  more  (“it  doesn’t  work  on  my  machine”  “but  it   works  on  my  machine!”)  
10. Docker as testing tool ¤  Here’s  a  great  case  study  for  using  docker  as  a   tes1ng  tool  :   Tes1ng  code  against  many  Node  versions  with   Docker   ¤  It’s  a  project  that  helps  build  na1ve  Node.js  add-­‐ ons  while  maintaining  compa1bility  with  Node   and  V8  from  Node  versions  0.8  onwards.    It   shields  projects  from  Node  compa1bility  issues   ¤  This  means  all  code  changes  need  to  be  tested   against  all  versions  of  Node.   ¤  17  versions  of  Node;  test  suite  takes  about  20   seconds  to  run.    
11. Docker as deployment tool ¤  The  container  that  gets  deployed  is  always  the   same  as  the  ones  the  developers  were  working   on.       ¤  Doesn’t  maher  what  host  it’s  deployed  on;  the   container  isolates  and  contains  your  app.   ¤  Makes  the  app  more  portable.   ¤  Containers  work  together,  so  it’s  easy  to  mix  and   match  containers,  replace  one  container,  etc.   ¤  Of  the  three  ways  Docker  is  being  used,  I  think   this  is  where  there  can  be  debate  about  whether   it  is  really  ready  for  produc1on,  though  many   companies  are  already  using  it  in  produc1on.  
12. Docker pain point milestones ¤  No  more  limits  on  number  container  layers   ¤  Container  communica1on  fixed   ¤  Mac  OS  X  na1ve  client   ¤  Mapping  directories  into  virtual  Mac  client   ¤  Size  limit  on  container  removed   ¤  Ability  to  ssh  in  to  running  containers!!!   ¤  Official  repos  for  popular  techs  (e.g.,  no  longer  need   to  build  php  /  mysql  from  scratch)  
13. HANDS ON: HOW I USE DOCKER
14. Best practices ¤  Try  to  use  one  container  per  process.    So,  if  you  have   Apache,  Mysql,  and  SOLR  running,  you’ll  want  three   containers   –  In  earlier  versions  of  Docker,  pain  points  made  this  kind  of   purity  difficult,  but  with  recent  versions,  that  has  become   easier  and  a  standard  prac1ce.   ¤  If  you  need  more  than  one  process  in  a  container,  you   can  use  supervisor  to  manage  the  processes.   ¤  Using  separate  containers  for  each  process  makes  it   easier  to  troubleshoot  when  you  are  selng  up  a   container.   –  E.g.,  why  is  module  A  not  enabled?   –  It’s  also  quicker  to  rebuild  the  individual  images  
15. Docker on a Mac ¤  Docker  is  Linux  technology.    Needs  to  run  on  a  Linux   machine.   ¤  In  order  to  run  on  Mac,  we  boot  up  a  lean  virtual   machine  (~27MB)  using  the  helper  app  boot2docker   ¤  All  our  containers  will  actually  run  in  the  virtual   machine,  but  our  docker  client  is  na1ve,  so  it’s  fairly   seamless.  
16. LET’S BUILD SOMETHING
17. Building a LAMP stack ¤  For  any  new  project,  I’ll  create  a  new  image,  built  on   top  of  standard  images.    Even  the  simplest  use  case   almost  always  requires  some  sort  of  customiza1on.   ¤  For  a  LAMP  stack  we’ll  need   –  Apache   –  PHP   –  MySQL  
18. Building a MySQL container ¤  We  actually  need  to  build  two   containers  here,  one  for  our  data,  and   one  for  the  MySQL  server.    This  makes   our  data  (and  the  app)  more  portable.   ¤  Create  a  data  container:   –  docker  create  -­‐v  /var/lib/mysql  -­‐-­‐name   proj_dbdata  mysql  echo  Data-­‐only   container  for  proj   ¤  We  can  use  one  of  the  official  images   for  mysql  and  map  in  our  data   container:   –  docker  run  -­‐d  -­‐-­‐volumes-­‐from   proj_dbdata  -­‐-­‐name  proj_db  -­‐p   3311:3306  mysql  
19. Build a PHP container ¤  Apache  and  PHP  are  actually  the  same   container  (a  single  service)   ¤  Unlike  the  mysql  image,  we’ll  create  a   customized  php  image  so  that  we  can   add  whatever  modules  we  want   ¤  Build  a  new  image:   –  Docker  build  –t  proj  .   ¤  Create  a  new  container,  linked  with   mysql  container   –  docker  run  -­‐d  -­‐-­‐name  proj  -­‐-­‐link   proj_db:db  -­‐p  8094:80  -­‐v  /Users/mark/ sites/docker/apps/noise/proj/:/var/ www/html  proj        
20. Voila
21. Look inside the container
22. Usage notes ¤  For  each  project  I  build,  I  use  different  ports  for   apache  and  mysql  so  that  I’m  able  to   concurrently  run  mul1ple  projects.    Here,  I’m   mapping  apache  to  8094  and  mysql  to  3311.   ¤  With  the  recent  ability  to  ssh  in  to  a  running   container,  life  is  MUCH  easer  in  terms  of   troubleshoo1ng,  unit  tes1ng,  console   commands.   ¤  Don’t  use  grunt,  gulp  or  brunch  from  inside  a   container.    Though  they  work,  the  watch  task  is   not  responsive  enough  to  be  relied  on.    Use   grunt  or  gulp  outside  the  container,  on  files/ directories  that  are  mapped  into  the  container.     Everything  works  fine  when  used  this  way.  
23. Conclusion ¤  Is  it  a  good  thing?    Uhhh,  I  find  it  very  useful.   ¤  For  Linux  development,  it  seems  indispensable.   ¤  For  tes1ng,  it  can  be  a  great  tool.   ¤  For  deployment,  I  think  it  is  s1ll  in  the  early   stages.    Many  are  using  it  in  produc1on,  but  for   the  moment,  they  probably  have  to  deal  with   headaches  that  will  be  solved  as  the  technology   matures.  
24. THANKS!