High availability microservices with Docker

Learn how to leverage Docker, CoreOS and VulcanD to keep your microservices running and manageable.

Transcript

1. Highly Available Microservices With Docker
2. So, what is
3. •  Applica'on  containers   – Your  app   – Its  libraries,  run'mes  and  other  dependencies   – All  running  in  userspace  isola'on  on  the  host   •  But  its  not  a  VM   – All  of  the  isola'on,  none  of  the  overhead   – Processes  s'll  run  on  the  host  OS/kernel  
4. Why use docker for my microservice?
5. •  Keep  your  dependencies  with  your  app   •  Run  the  exact  same  image  in  dev,  CI,  and   produc'on   •  It’s  deployable  
6. HOW  DO  I  PRODUCTION?   •  Build  an  image   •  Make  a  host   •  Run!   $  docker  build  –t  org/app  .   $  docker  push  org/app   $  sudo  apt-­‐get  install  docker-­‐io   $  docker  run  –d  –P  org/app  
7. Is it really this simple?
8. WHAT  HAPPENS  WHEN   •  The  app  dies   •  The  host  dies   •  You  need  to  upgrade/reboot  the  host   •  You  need  to  scale  the  app   •  You  need  to  route  traffic  to  the  app   •  You  need  balance  load  between  N  instances  of   the  app   •  The  app  needs  to  communicate  with  other   microservices  
10. No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT No. 00 SAMPLE TEXT CLUSTERS MAKE IT EASIER
11. •  install  nothing,  apps  run  in  containers   •  systemd  across  a  cluster  (fleet)     •  automa'c  updates   •  automa'c  failover   •  configura'on  management  (etcd)   •  'ny  
12. SERVICE  PUBLICATION   •  Reverse  Proxies  are  your  friend   •  DNS  is  also  a  great  way  to  keep  your  apps   decoupled  
13. BEST  PRACTICES   •  Unix  philosophy:  do  1  thing  and  do  it  well   •  12factor   – Log  collec'on   – Structured  logs  are  your  friend   – Inject  configura'on   – Don't  name  your  hosts  
14. BEST  PRACTICES   •  Configura'on  management  (etcd)   •  Let  go  of  the  ssh   •  The  filesystem  is  lava   •  Don't  manage  it  yourself  (if  you  dont  have  to)   •  If  you  absolutely  need  to  run  it  yourself,  make   sure  it's  clustered,  replicated  and  automated  
16. KUBERNETES   •  Google  might  have  some  experience  with   large-­‐scale  distributed  systems   •  Define  an  en're  service  as  a  pod  of   microservices   •  Keeps  logical  units  of  containers  together   •  Portable   •  Declara've  state  
17. ALSO  UPCOMING   •  docker-­‐swarm