◦ For simple applications it can ▫ provision VM ▫ on multiple cloud providers ▫ monitor resources ◦ For complex applications ▫ expose REST API ◦ For everyone ▫ manage subscriptions, billing, pay- per-use, invoicing, payments
repository ◦ Container: an instance launched from an image ◦ Volume: persistent writable area of a container ◦ Registry: repository of images (versioned via tags) ◦ Dockerfile: the descriptor from which an image is built
https://get.docker.com/ | sh ◦ Windows https://github.com/boot2docker/windows-installer/releases/latest ◦ OSX https://kitematic.com/download/ ◦ Hello world $ docker run -ti ubuntu:14.04 /bin/bash
image from registry ◦ Creates a new container ▫ Allocates a rw filesystem ▫ Allocates a network interface (on a bridge) ▫ Sets up network (IP address, dns..) ◦ Launch a process in the container ◦ Captures and provides application output Container terminates when the process exit
gionn/nodejs-app:1.0.0 . ▫ a tagged image is generated ◦ docker push gionn/nodejs-app:1.0.0 ▫ publish to repository Pull & run: ◦ docker pull gionn/nodejs-app:1.0.0 ▫ fetch from repository ◦ docker run gionn/nodejs-app:1.0.0 ▫ run container from this image Example gist: link
talk to service in container B Docker solution: ◦ Use Container Links Reality: ◦ Works only on the same host ◦ Ordered sequence to boot-up ◦ Can’t solve cyclic dependencies
of cake for wrapping together the technologies of Linux containers, multi-layered filesystems and an image build system, in an unique tool easy and fast to use.
of issues far time ago, even before Docker existed? Those kind of problems are all about configuration management and automation. So use the tools already available.
SCM, build an artifact ◦ Apply testing, CI, CD to infrastructure ◦ Keep it aligned with your software ◦ Automation via repeatable actions (e.g. click to deploy)
a service (e.g. mysql). Contains: ◦ Attributes: they are like global variables (e.g. version to install) ◦ Recipes: an atomic unit of configuration ◦ Templates: patterns to generate real files, filled with data ◦ Files: static configuration
for a group of nodes ◦ Roles: contains attributes for nodes sharing a particular behaviour ◦ Data bags: general-purpose JSON data, optionally encrypted, usually to store credentials
GitHub ◦ Maintained by Opscode https://github.com/opscode-cookbooks ◦ by vendors https://github.com/elastic/cookbook-elasticsearch ◦ by the community https://supermarket.chef.io Community Stats (07/04/2015) 2,120 Cookbooks ~ 62,086 Chefs
an .ERB template ◦ a template resource declared in a recipe The template is evaluated using the variables passed directly or via the global node object.
to be used for persistent data (e.g. database files), but may be used to inject configurations into the container at runtime. Definitevely avoid the needs of image rebuilding to adjust a setting.
its own run_list, defining which recipes should be executed (in JSON): { “run_list”: [ "cd-infrastructure::docker-cmw", "cd-infrastructure::docker-deployer", "cd-infrastructure::docker-monitor", "cd-infrastructure::docker-logger" ], “cloudesire”: { “key”: “value” } }
It’s easy to getting started with Chef by using kitchen-ci or plain Vagrant: ◦ Initialize a chef repo ◦ Create a new cookbook ◦ Start hacking ◦ Play on kitchen-ci or vagrant ◦ Repeat last 2
◦ No embedded configuration ◦ No, you don’t need SSH ◦ No, you don’t need syslog ◦ No, you won’t touch a running container to adjust a thing ◦ No, you will not use a community-contributed image without looking at what it do
gionn
r4ynode
subroh0508
coco_se
makikub
ks91
cyberagentdevelopers
taketo957
tomokusaba
line_developers_tw
exactpro
_kensh
tomoki10
addyosmani
cromwellryan
thekraken
mayatellez
eileencodes
kimpetersen
akademiya2063
aleyda
sferik
lindahogenes
sergeychernyshev
