KEMBAR78
Docker Ecosystem on Azure | PPTX
Patrick Chanezon & Tim Park
Microsoft
@chanezon @timpark
French
Polyglot
Server Side
San Francisco
Developer Relations
@chanezon
3
Devops TED Working Group
5
Cloud Market
PublicHybridPrivate
IT Pros Devops DevelopersArchitects
History of containerization
1960’s mainframe
1990’s hardware virtualization
1990’s OS virt precursors: BSD Jails, Solaris zones
2006 Cloud IaaS
2009 platform virtualization (PaaS)
2013 Docker
See @bcantrill’s deck http://www.slideshare.net/bcantrill/docker-and-the-future-of-containers-in-production
7
Linux Container Ecosystem
Containers
Engaging with the ecosystem
It looks like a VM
Private process space
Can run stuff as root
Private network interface and IP address
Custom routes, iptables rules, etc.
Can mount filesystems and more
Faster to boot, less overhead than a VM
$ time docker run ubuntu echo hello world
hello world
real 0m0.258s
Disk usage: less than 100 kB
Memory usage: less than 1.5 MB
Isolation using Linux kernel features
namespaces
 pid
 mnt
 net
 uts
 ipc
 user
cgroups
 memory
 cpu
 blkio
 devices
How does it work?
Copy-on-write storage
 Create a new machine instantly
(Instead of copying its whole filesystem)
 Storage keeps track of what has changed
 Multiple storage plugins available
(AUFS, device mapper, BTRFS, overlayfs, VFS)
Union Filesystems
(AUFS, overlayfs)
Copy-on-write
block devices
Snapshotting
filesystems
Provisioning Superfast
Supercheap
Average
Cheap
Fast
Cheap
Changing
small files
Superfast
Supercheap
Fast
Costly
Fast
Cheap
Changing
large files
Slow (first time)
Inefficient (copy-up!)
Fast
Cheap
Fast
Cheap
Diffing Superfast Slow Superfast
Memory usage Efficient Inefficient
(at high densities)
Inefficient
(but may improve)
Drawbacks Random quirks
AUFS not mainline
Overlayfs bleeding edge
Higher disk usage
Great performance (except
diffing)
ZFS not mainline
BTRFS not as nice
Bottom line Ideal for PAAS, CI/CD, high
density things
Works everywhere,
but slow and inefficient
Will be great once memory
usage is fixed
Storage options
Initial goals
 LXC container engine to build a PaaS
 Containers as lightweight VMs
(complete with syslog, cron, ssh...)
 Part of a bigger puzzle
(other parts: builders, load balancers...)
Docker now
 Build, ship, and run any app, anywhere
Say again?
 Build: package your application in a container
 Ship: move that container from a machine to another
 Run: execute that container (i.e. your application)
 Any application: anything that runs on Linux
 Anywhere: local VM, cloud instance, bare metal...
build
Dockerfiles
 Recipe to build a container
 Start FROM a base image
 RUN commands on top of it
 Easy to learn, easy to use
Authoring images
with a Dockerfile
 Minimal learning curve
 Rebuilds are easy
 Caching system makes rebuilds faster
 Single file to define the whole environment
 Single file to define the whole component
FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y nginx
RUN echo 'Hi, I am in your container!' 
>/usr/share/nginx/html/index.html
CMD nginx -g "daemon off;"
EXPOSE 80
docker build -t jpetazzo/web .
docker run -d -P jpetazzo/web
Docker language stacks
« docker build » goodness
 Takes a snapshot after each step
 Re-uses those snapshots in future builds
 Doesn't re-run slow steps (package install...)
when it is not necessary
ship
Docker Hub
 docker push an image to the Hub
 docker pull this image from any machine
Why does this
matter?
Deploy reliably & consistently
 Images are self-contained, independent from
host
 If it works locally, it will work on the server
 With exactly the same behavior
 Regardless of versions
 Regardless of distros
 Regardless of dependencies
run
Execution is fast and lightweight
 Containers have no* overhead
 Lies, damn lies, and other benchmarks:
http://qiita.com/syoyo/items/bea48de8d7c6d8c73435
http://www.slideshare.net/BodenRussell/kvm-and-docker-lxc-benchmarking-with-openstack
*For some definitions of « no »
Is there really no overhead at all?
 Processes are isolated,
but run straight on the host
 Code path in containers
= code path on native
 CPU performance
= native performance
 Memory performance
= a few % shaved off for (optional) accounting
 Network and disk I/O performance
= small overhead; can be reduced to zero
Deploy almost anywhere
Devops
Separation of concerns:
Dave the Developer
 Inside my container:
 my code
 my libraries
 my package manager
 my app
 my data
Separation of concerns:
Oscar the Ops guy
 Outside the container:
 logging
 remote access
 network configuration
 monitoring
Docker
Components
Docker: the cast
 Docker Engine
 Docker Hub
 Docker, the community
 Docker Inc, the company
Docker Engine
 Open Source engine to commoditize LXC
 Uses copy-on-write for quick provisioning
 Written in Go, runs as a daemon, comes with a CLI
 Everything exposed through a REST API
 Allows to build images in standard, reproducible way
 Allows to share images through registries
 Defines standard format for containers
(stack of layers; 1 layer = tarball+metadata)
… Open Source?
 Nothing up the sleeve, everything on the table
 Public GitHub repository: https://github.com/docker/docker
 Bug reports: GitHub issue tracker
 Mailing lists: docker-user, docker-dev (Google groups)
 IRC channels: #docker, #docker-dev (Freenode)
 New features: GitHub pull requests (see CONTRIBUTING.md)
 Docker Governance Advisory Board (elected by contributors)
Docker Hub
•Collection of services to make Docker more useful.
 Library of official base images
 Public registry
(push/pull your images for free)
 Private registry
(push/pull secret images for $)
 Automated builds
(link github/bitbucket repo; trigger build on commit)
 More to come!
Docker, the community
 >700 contributors
 ~20 core maintainers
 >40,000 Dockerized projects on GitHub
 >60,000 repositories on Docker Hub
 >25000 meetup members,
>140 cities, >50 countries
 >2,000,000 downloads of boot2docker
Docker Inc, the company
 Headcount: ~70
 Revenue:
 t-shirts and stickers featuring the cool blue whale
 SAAS delivered through Docker Hub
 Support & Training
Developing
with Docker
One-time setup
 On your dev env (Linux, OS X, Windows)
 boot2docker (25 MB VM image)
 Natively (if you run Linux)
 On your servers (Linux)
 Packages (Ubuntu, Debian, Fedora, Gentoo, Arch...)
 Single binary install (Golang FTW!)
 Easy provisioning on Azure, Rackspace, Digital Ocean...
 Special distros: CoreOS, Project Atomic, Ubuntu Core
Azure deployment
VMNAME=jpetazzo
IMAGE=b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-14_04-LTS-amd64-server-20140724-en-us-30GB
USER=jpetazzo
PASSWORD=1234abcdABCD@
LOCATION="West US"
azure vm docker create $VMNAME 
$IMAGE $USER $PASSWORD -l "$LOCATION"
export DOCKER_HOST=tcp://$VMNAME.cloudapp.net:4243
docker --tls version
azure vm endpoint create $VMNAME 80
Running
multiple
containers
Fig
 Run your stack with one command: fig up
 Describe your stack with one file: fig.yml
 Example: Python+Redis webapp
web:
build: .
command: python app.py
ports:
- "5000:5000"
volumes:
- .:/code
links:
- redis:redis
redis:
image: redis
Per-project setup
 Write Dockerfiles
 Write fig.yml file(s)
 Test the result
(i.e.: Make sure that « git clone ; fig up »
works on new Docker machine works fine
Per-developer setup
 Make sure that they have Docker
(boot2docker or other method)
 git clone ; fig up
 Done
Development workflow
 Edit code
 Iterate locally or in a container
(use volumes to share code between local
machine and container)
 When ready to test « the real thing », fig up
Going to production
 There are many options
 full 45-minutes talk about
« Docker to production »
Implementing CI/CD
 Each time I commit some code, I want to:
 build a container with that code
 test that container
 if the test is successful, promote that container
Docker Hub to the rescue
 Automated builds let you link github/bitbucket
repositories to Docker Hub repositories
 Each time you push to github/bitbucket:
 Docker Hub fetches your changes,
 builds new containers images,
 pushes those images to the registry.
Coming next on Docker Hub...
 Security notifications
 Automated deployment to Docker hosts
 Docker Hub Enterprise
(all those features, on your infrastructure)
Summary
•With Docker, I can:
 put my software in containers
 run those containers anywhere
 write recipes to automatically build containers
 use Fig to effortlessly start stacks of containers
 automate testing, building, hosting of images,
using the Docker Hub
Advanced concepts
 naming
 give a unique name to your containers
 links
 connect containers together
 volumes
 separate code and data
 share data between containers
Docker future
• Docker machine: provisioning hosts
• Docker swarm: clustering
• Docker compose: composing apps
• Docker plugin model: for weave, flocker
Linux Container Ecosystem
Weave
Flocker
CoreOS
Fleet
Docker & etcd
Cluster Architecture
Deis (http://deis.io)
• Open source PaaS platform that builds on CoreOS.
• Replicates the popular Heroku devops workflow.
• Primary mechanism for pushing applications is through git.
• Developer experience is not unlike Azure Websites…
• …but is built on Linux so full support for open source stacks.
• Enables us to win migrations from Salesforce to Azure.
• Hackfest in November to enable Deis for Tagboard.
• Enables us to win startups that expect this workflow.
tpark:www$ git push deis master
• Git pushes master to deis git remote on endpoint
• Deis senses static web application
• Selects Heroku Buildpack
• Uses buildpack to build application Docker container.
• Pushes this container to a private Docker registry.
• Orchestrates the creation or update of this container on
the cluster.
• Updates routing mesh to route to these containers.
Router Mesh
deis-1 deis-2 deis-3 deis-4
www
CoreOS CoreOS CoreOS CoreOS
tpark:www$ deis scale www=3
• Deis pushes the container to two more cluster nodes.
• Updates routing mesh to pass traffic to these nodes.
Router Mesh
deis-1 deis-2 deis-3 deis-4
www www www
tpark:api$ git push deis master
• Git pushes master to deis git remote on endpoint
• Deis senses node.js application
• Selects Heroku node.js Buildpack
• Uses buildpack to build application Docker container.
• Pushes this container to a private Docker registry.
• Orchestrates the creation or update of this container on
the cluster.
• Updates routing mesh to route to these containers.
Router Mesh
deis-1 deis-2 deis-3 deis-4
www
api
www
api
www api
Router Mesh
deis-1 deis-2 deis-3 deis-4
www
api
www
api
www api
Router Mesh
deis-1 deis-2 deis-3 deis-4
www
api
www
api
www
api
tpark:api$ deis config:set
DATABASE_URL=postgres://user:pass@example.com:54
32/db
• Applications in Deis are configured through environmental variables.
• MUST READ: http://12factor.net/
• Key point: Code is separated from config.
• Enables generic containers that are configured at runtime.
• Every app container spun up by Deis will have a copy of these config
environmental variables.
tpark:api$ deis logs
• Deis automatically rolls and consolidates logs from all
containers.
Router Mesh
deis-1 deis-2 deis-3 deis-4
www
api
www
api
www
api
Router Mesh
deis-1 deis-2 deis-3 deis-4
www
api
www
api
www
api
Kubernetes (http://kubernetes.io)
Kubernetes
Master / Scheduler
host-1 host-2 host-3 host-n
…..
Container
Agent
Container
Agent
Container
Agent
Container
Agent
Linux Linux Linux Linux
Kubernetes
Scheduler
host-1 host-2 host-3 host-n
…..
Container
Agent
Container
Agent
Container
Agent
Container
Agent
Linux Linux Linux Linux
Container
Container
Kubernetes
host-1
Container
host-2 host-3 host-4 host-n
…
Container
Container
Container
Container
ContainerContainer
Container
Container
Kubernetes
host-1 host-2 host-3 host-4 host-n
…
Frontend
Worker
my_app pod
MyAppMyApp MyApp
Replication
Controller
3
Kubernetes
host-1 host-2 host-3 host-4 host-n
…
Frontend
Worker
my_app pod
MyAppMyApp MyApp
Replication
Controller
3
Kubernetes
host-1 host-2 host-3 host-4 host-n
…
MyAppMyApp MyApp
Replication
Controller
Pod Pod
Pod
Pod
PodPod
Pod
Pod
Replication Controller
Kubernetes
host-1 host-2 host-3 host-4 host-n
…
MyApp
staging
MyApp
staging
MyApp
staging
MyApp
prod
MyApp
prod
MyApp
prod
MyApp
prod
MyApp
prod
MyApp Production Service
{ environment: prod }
MyApp Staging Service
{ environment: staging }
Labels and Services
• https://github.com/chanezon/azure-linux
• Docker container to get started
docker run –ti chanezon/linux
• CoreOS cluster, fleet
• Deis
• Weave
• Docker machine
• Deploy Java app
• Strategic Engagement team
• We build Epic stuff with customers
• What can we do together?
• When do you want to start?
• patric@microsoft.com
10
3
http://www.slideshare.net/chanezon/tackling-complexity-in-giant-systems-approaches-from-several-cloud-
providers
https://msopentech.com/
https://github.com/timfpark/coreos-azure
http://www.slideshare.net/jpetazzo/
http://www.slideshare.net/bcantrill/docker-and-the-future-of-containers-in-production
Docker Ecosystem on Azure

Docker Ecosystem on Azure

  • 1.
    Patrick Chanezon &Tim Park Microsoft @chanezon @timpark
  • 2.
  • 3.
  • 5.
    5 Cloud Market PublicHybridPrivate IT ProsDevops DevelopersArchitects
  • 6.
    History of containerization 1960’smainframe 1990’s hardware virtualization 1990’s OS virt precursors: BSD Jails, Solaris zones 2006 Cloud IaaS 2009 platform virtualization (PaaS) 2013 Docker See @bcantrill’s deck http://www.slideshare.net/bcantrill/docker-and-the-future-of-containers-in-production
  • 7.
  • 9.
  • 10.
  • 11.
  • 14.
    It looks likea VM Private process space Can run stuff as root Private network interface and IP address Custom routes, iptables rules, etc. Can mount filesystems and more
  • 15.
    Faster to boot,less overhead than a VM $ time docker run ubuntu echo hello world hello world real 0m0.258s Disk usage: less than 100 kB Memory usage: less than 1.5 MB
  • 16.
    Isolation using Linuxkernel features namespaces  pid  mnt  net  uts  ipc  user cgroups  memory  cpu  blkio  devices
  • 17.
    How does itwork? Copy-on-write storage  Create a new machine instantly (Instead of copying its whole filesystem)  Storage keeps track of what has changed  Multiple storage plugins available (AUFS, device mapper, BTRFS, overlayfs, VFS)
  • 18.
    Union Filesystems (AUFS, overlayfs) Copy-on-write blockdevices Snapshotting filesystems Provisioning Superfast Supercheap Average Cheap Fast Cheap Changing small files Superfast Supercheap Fast Costly Fast Cheap Changing large files Slow (first time) Inefficient (copy-up!) Fast Cheap Fast Cheap Diffing Superfast Slow Superfast Memory usage Efficient Inefficient (at high densities) Inefficient (but may improve) Drawbacks Random quirks AUFS not mainline Overlayfs bleeding edge Higher disk usage Great performance (except diffing) ZFS not mainline BTRFS not as nice Bottom line Ideal for PAAS, CI/CD, high density things Works everywhere, but slow and inefficient Will be great once memory usage is fixed Storage options
  • 19.
    Initial goals  LXCcontainer engine to build a PaaS  Containers as lightweight VMs (complete with syslog, cron, ssh...)  Part of a bigger puzzle (other parts: builders, load balancers...)
  • 20.
    Docker now  Build,ship, and run any app, anywhere
  • 21.
    Say again?  Build:package your application in a container  Ship: move that container from a machine to another  Run: execute that container (i.e. your application)  Any application: anything that runs on Linux  Anywhere: local VM, cloud instance, bare metal...
  • 22.
  • 23.
    Dockerfiles  Recipe tobuild a container  Start FROM a base image  RUN commands on top of it  Easy to learn, easy to use
  • 24.
    Authoring images with aDockerfile  Minimal learning curve  Rebuilds are easy  Caching system makes rebuilds faster  Single file to define the whole environment  Single file to define the whole component
  • 25.
    FROM ubuntu:14.04 RUN apt-getupdate RUN apt-get install -y nginx RUN echo 'Hi, I am in your container!' >/usr/share/nginx/html/index.html CMD nginx -g "daemon off;" EXPOSE 80 docker build -t jpetazzo/web . docker run -d -P jpetazzo/web
  • 26.
  • 27.
    « docker build» goodness  Takes a snapshot after each step  Re-uses those snapshots in future builds  Doesn't re-run slow steps (package install...) when it is not necessary
  • 29.
  • 30.
    Docker Hub  dockerpush an image to the Hub  docker pull this image from any machine
  • 31.
  • 32.
    Deploy reliably &consistently  Images are self-contained, independent from host  If it works locally, it will work on the server  With exactly the same behavior  Regardless of versions  Regardless of distros  Regardless of dependencies
  • 33.
  • 34.
    Execution is fastand lightweight  Containers have no* overhead  Lies, damn lies, and other benchmarks: http://qiita.com/syoyo/items/bea48de8d7c6d8c73435 http://www.slideshare.net/BodenRussell/kvm-and-docker-lxc-benchmarking-with-openstack *For some definitions of « no »
  • 35.
    Is there reallyno overhead at all?  Processes are isolated, but run straight on the host  Code path in containers = code path on native  CPU performance = native performance  Memory performance = a few % shaved off for (optional) accounting  Network and disk I/O performance = small overhead; can be reduced to zero
  • 36.
  • 37.
  • 38.
    Separation of concerns: Davethe Developer  Inside my container:  my code  my libraries  my package manager  my app  my data
  • 39.
    Separation of concerns: Oscarthe Ops guy  Outside the container:  logging  remote access  network configuration  monitoring
  • 40.
  • 41.
    Docker: the cast Docker Engine  Docker Hub  Docker, the community  Docker Inc, the company
  • 42.
    Docker Engine  OpenSource engine to commoditize LXC  Uses copy-on-write for quick provisioning  Written in Go, runs as a daemon, comes with a CLI  Everything exposed through a REST API  Allows to build images in standard, reproducible way  Allows to share images through registries  Defines standard format for containers (stack of layers; 1 layer = tarball+metadata)
  • 43.
    … Open Source? Nothing up the sleeve, everything on the table  Public GitHub repository: https://github.com/docker/docker  Bug reports: GitHub issue tracker  Mailing lists: docker-user, docker-dev (Google groups)  IRC channels: #docker, #docker-dev (Freenode)  New features: GitHub pull requests (see CONTRIBUTING.md)  Docker Governance Advisory Board (elected by contributors)
  • 44.
    Docker Hub •Collection ofservices to make Docker more useful.  Library of official base images  Public registry (push/pull your images for free)  Private registry (push/pull secret images for $)  Automated builds (link github/bitbucket repo; trigger build on commit)  More to come!
  • 45.
    Docker, the community >700 contributors  ~20 core maintainers  >40,000 Dockerized projects on GitHub  >60,000 repositories on Docker Hub  >25000 meetup members, >140 cities, >50 countries  >2,000,000 downloads of boot2docker
  • 46.
    Docker Inc, thecompany  Headcount: ~70  Revenue:  t-shirts and stickers featuring the cool blue whale  SAAS delivered through Docker Hub  Support & Training
  • 47.
  • 48.
    One-time setup  Onyour dev env (Linux, OS X, Windows)  boot2docker (25 MB VM image)  Natively (if you run Linux)  On your servers (Linux)  Packages (Ubuntu, Debian, Fedora, Gentoo, Arch...)  Single binary install (Golang FTW!)  Easy provisioning on Azure, Rackspace, Digital Ocean...  Special distros: CoreOS, Project Atomic, Ubuntu Core
  • 49.
    Azure deployment VMNAME=jpetazzo IMAGE=b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-14_04-LTS-amd64-server-20140724-en-us-30GB USER=jpetazzo PASSWORD=1234abcdABCD@ LOCATION="West US" azurevm docker create $VMNAME $IMAGE $USER $PASSWORD -l "$LOCATION" export DOCKER_HOST=tcp://$VMNAME.cloudapp.net:4243 docker --tls version azure vm endpoint create $VMNAME 80
  • 50.
  • 52.
    Fig  Run yourstack with one command: fig up  Describe your stack with one file: fig.yml  Example: Python+Redis webapp
  • 53.
    web: build: . command: pythonapp.py ports: - "5000:5000" volumes: - .:/code links: - redis:redis redis: image: redis
  • 54.
    Per-project setup  WriteDockerfiles  Write fig.yml file(s)  Test the result (i.e.: Make sure that « git clone ; fig up » works on new Docker machine works fine
  • 55.
    Per-developer setup  Makesure that they have Docker (boot2docker or other method)  git clone ; fig up  Done
  • 56.
    Development workflow  Editcode  Iterate locally or in a container (use volumes to share code between local machine and container)  When ready to test « the real thing », fig up
  • 57.
    Going to production There are many options  full 45-minutes talk about « Docker to production »
  • 58.
    Implementing CI/CD  Eachtime I commit some code, I want to:  build a container with that code  test that container  if the test is successful, promote that container
  • 59.
    Docker Hub tothe rescue  Automated builds let you link github/bitbucket repositories to Docker Hub repositories  Each time you push to github/bitbucket:  Docker Hub fetches your changes,  builds new containers images,  pushes those images to the registry.
  • 60.
    Coming next onDocker Hub...  Security notifications  Automated deployment to Docker hosts  Docker Hub Enterprise (all those features, on your infrastructure)
  • 61.
    Summary •With Docker, Ican:  put my software in containers  run those containers anywhere  write recipes to automatically build containers  use Fig to effortlessly start stacks of containers  automate testing, building, hosting of images, using the Docker Hub
  • 62.
    Advanced concepts  naming give a unique name to your containers  links  connect containers together  volumes  separate code and data  share data between containers
  • 63.
    Docker future • Dockermachine: provisioning hosts • Docker swarm: clustering • Docker compose: composing apps • Docker plugin model: for weave, flocker
  • 64.
  • 65.
  • 66.
  • 68.
  • 69.
  • 70.
  • 71.
  • 75.
    Deis (http://deis.io) • Opensource PaaS platform that builds on CoreOS. • Replicates the popular Heroku devops workflow. • Primary mechanism for pushing applications is through git. • Developer experience is not unlike Azure Websites… • …but is built on Linux so full support for open source stacks. • Enables us to win migrations from Salesforce to Azure. • Hackfest in November to enable Deis for Tagboard. • Enables us to win startups that expect this workflow.
  • 78.
    tpark:www$ git pushdeis master • Git pushes master to deis git remote on endpoint • Deis senses static web application • Selects Heroku Buildpack • Uses buildpack to build application Docker container. • Pushes this container to a private Docker registry. • Orchestrates the creation or update of this container on the cluster. • Updates routing mesh to route to these containers.
  • 79.
    Router Mesh deis-1 deis-2deis-3 deis-4 www CoreOS CoreOS CoreOS CoreOS
  • 80.
    tpark:www$ deis scalewww=3 • Deis pushes the container to two more cluster nodes. • Updates routing mesh to pass traffic to these nodes.
  • 81.
    Router Mesh deis-1 deis-2deis-3 deis-4 www www www
  • 82.
    tpark:api$ git pushdeis master • Git pushes master to deis git remote on endpoint • Deis senses node.js application • Selects Heroku node.js Buildpack • Uses buildpack to build application Docker container. • Pushes this container to a private Docker registry. • Orchestrates the creation or update of this container on the cluster. • Updates routing mesh to route to these containers.
  • 83.
    Router Mesh deis-1 deis-2deis-3 deis-4 www api www api www api
  • 84.
    Router Mesh deis-1 deis-2deis-3 deis-4 www api www api www api
  • 85.
    Router Mesh deis-1 deis-2deis-3 deis-4 www api www api www api
  • 86.
    tpark:api$ deis config:set DATABASE_URL=postgres://user:pass@example.com:54 32/db •Applications in Deis are configured through environmental variables. • MUST READ: http://12factor.net/ • Key point: Code is separated from config. • Enables generic containers that are configured at runtime. • Every app container spun up by Deis will have a copy of these config environmental variables.
  • 87.
    tpark:api$ deis logs •Deis automatically rolls and consolidates logs from all containers.
  • 88.
    Router Mesh deis-1 deis-2deis-3 deis-4 www api www api www api
  • 89.
    Router Mesh deis-1 deis-2deis-3 deis-4 www api www api www api
  • 91.
  • 92.
    Kubernetes Master / Scheduler host-1host-2 host-3 host-n ….. Container Agent Container Agent Container Agent Container Agent Linux Linux Linux Linux
  • 93.
    Kubernetes Scheduler host-1 host-2 host-3host-n ….. Container Agent Container Agent Container Agent Container Agent Linux Linux Linux Linux Container Container
  • 95.
    Kubernetes host-1 Container host-2 host-3 host-4host-n … Container Container Container Container ContainerContainer Container Container
  • 96.
    Kubernetes host-1 host-2 host-3host-4 host-n … Frontend Worker my_app pod MyAppMyApp MyApp Replication Controller 3
  • 97.
    Kubernetes host-1 host-2 host-3host-4 host-n … Frontend Worker my_app pod MyAppMyApp MyApp Replication Controller 3
  • 98.
    Kubernetes host-1 host-2 host-3host-4 host-n … MyAppMyApp MyApp Replication Controller Pod Pod Pod Pod PodPod Pod Pod Replication Controller
  • 99.
    Kubernetes host-1 host-2 host-3host-4 host-n … MyApp staging MyApp staging MyApp staging MyApp prod MyApp prod MyApp prod MyApp prod MyApp prod MyApp Production Service { environment: prod } MyApp Staging Service { environment: staging } Labels and Services
  • 101.
    • https://github.com/chanezon/azure-linux • Dockercontainer to get started docker run –ti chanezon/linux • CoreOS cluster, fleet • Deis • Weave • Docker machine • Deploy Java app
  • 102.
    • Strategic Engagementteam • We build Epic stuff with customers • What can we do together? • When do you want to start? • patric@microsoft.com
  • 103.