docker compose by aanand prasad
DESCRIPTION
Docker Compose is the last piece of the orchestration puzzle. After provisioning Docker daemons on any host in any location with Docker Machine and clustering them with Docker Swarm, users can employ Docker Compose to assemble multi-container distributed apps that run on top of these clusters. The first step to employing Docker Compose is to use a simple YAML file to declaratively define the desired state of the multi-container app: containers: web: build: . command: python app.py ports: - "5000:5000" volumes: - .:/code links: - redis environment: - PYTHONUNBUFFERED=1 redis: image: redis:latest command: redis-server --appendonly yes This example shows how Docker Compose takes advantage of existing containers. Specifically, in this simple two-container app declaration, the first container is a Python app built each time from the Dockerfile in the current directory. The second container is built from the redis Official Repo on the Docker Hub Registry. The links directive declares that the Python app container is dependent on the redis container. Not that it’s defined, starting your app is as easy as … % docker up With this single command, the Python container is automatically built from its Dockerfile and the redis container is pulled from the Docker Hub Registry. Then, thanks to the links directive expressing the dependency between the Python and redis containers, the redis container is started *first*, followed by the Python container. Docker Compose is still a work-in-progress and we want your help to design it. In particular, we want to know whether or not you think this should be a part of the Docker binary or a separate tool. Head over to the proposal on GitHub to try out an alpha build and have your say. Coda All this is just the briefest introduction to Docker Machine, Docker Swarm, and Docker Compose. We hope you’ll take a moment to try them out and give us feedback – these projects are moving quickly and we welcome your input! We also wish to thank the many community members who have contributed their experience, feedback, and pull requests during the pre-Alpha iterations of these projects. It’s thanks to you that we were able to make so much progress so quickly, and in the right direction. Distributed apps offer many benefits to users – portability, scalability, dynamic development-to-deployment acceleration – and we’re excited by the role the Docker platform, community, and ecosystem are playing in making these apps easier to build, ship, and run. We’ve got a ways to go, but we’re psyched by this start – join us and help us get there faster!TRANSCRIPT
Docker Compose
Multi-container apps are a hassle.
• Build images from Dockerfiles
• Pull images from the Hub or a private registry
• Configure and create containers
• Start and stop containers
• Stream their logs
Multi-container apps are a hassle.
$ docker pull redis:latest
$ docker build -t web .
$ docker run -d --name=db redis:latest redis-server --appendonly yes
$ docker run -d --name=web --link db:db -p 5000:5000 -v `pwd`:/code web python app.py
Multi-container apps are a hassle.
$ docker pull ...$ docker pull ...$ docker build ...$ docker build ...
$ docker run ...$ docker run ...$ docker run ...$ docker run ...
Docker Compose:Get an app running in one command.
$ docker up
Text file
Native Docker API
The same API used by other Docker commands.
The same API used by other Docker tools.
The same API exposed by Docker Swarm.
Multi-container apps on multi-host clusters.
Built into the Docker client
• New command: docker up• Enhanced commands: docker build, pull, run, start, stop, kill, rm...
app.py
from flask import Flaskfrom redis import Redis
app = Flask(__name__)redis = Redis(host="redis", port=6379)
@@app.route('/')def hello(): redis.incr('hits') return 'Hello World! I have been seen %s times.\n' % redis.get('hits')
if __name__ == "__main__": app.run(host="0.0.0.0", debug=True)
requirements.txt
flaskredis
Dockerfile
FROM python:2.7ADD . /codeWORKDIR /codeRUN pip install -r requirements.txt
group.ymlname: counter
containers: web: build: . command: python app.py ports: - "5000:5000" volumes: - .:/code links: - redis redis: image: redis:latest
Demo
Enhanced syntax which refers to group.yml
Same as before: docker rm mycontainer
New form:docker rm :web
Equivalent to: docker rm [name of the web container] (if the web container exists)
Enhanced syntax which refers to group.yml
New form:docker rm :
Equivalent to: docker rm [all containers defined in group.yml]
Enhanced syntax which refers to group.yml
List all running containers defined in group.yml:
docker ps :
Manually rebuild the web image:
docker build :web
Manually re-pull the redis image:
docker pull :redis
Demo
Open design questions
Should the app name be included in group.yml?
name: counter
containers: ...
Should the app name be included in group.yml?
• Fig users have asked for it(we currently let you override it with --project-name or $FIG_PROJECT_NAME)
• Less portable
• Alternative: generate name and store it in an unversioned file
Should we auto-build?
• Keeps the "one command" promise
• Risk of running an old version of the image
Should we keep Compose separate?
• Avoid inflating the core
• Separate release schedules
• More freedom to experiment
But...
• Initial experience would be better
• Difference between Fig and Docker is unclear to newcomers
• Fig bug reports are often actually Docker bugs
Thank You.