Book Image

Docker Orchestration

By : Randall Smith
Book Image

Docker Orchestration

By: Randall Smith

Overview of this book

Docker orchestration is what you need when transitioning from deploying containers individually on a single host to deploying complex multi-container apps on many machines. This book covers the new orchestration features of Docker 1.12 and helps you efficiently build, test, and deploy your application using Docker. You will be shown how to build multi-container applications using Docker Compose. You will also be introduced to the building blocks for multi-host Docker clusters such as registry, overlay networks, and shared storage using practical examples. This book gives an overview of core tools such as Docker Machine, Swarm, and Compose which will enhance your orchestration skills. You’ll learn how to set up a swarm using the decentralized building block. Next, you’ll be shown how to make the most out of the in-built orchestration feature of Docker engine and you’ll use third-party tools such as Kubernetes, Mesosphere, and CoreOS to orchestrate your existing process. Finally, you will learn to deploy cluster hosts on cloud services and automate your infrastructure.
Table of Contents (17 chapters)
Docker Orchestration
Credits
About the Author
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface

Using volumes


Like plain Docker, Kubernetes supports volumes. The main difference is that Kubernetes supports them at the pod level. This means that a volume configured in a pod is available and may be used by every container in the pod for reading and writing. Second, Kubernetes volumes may use multiple different types of network storage at the same time.

Volumes come in two forms, the first is an ephemeral volume that lives only as long as the pod using it. When the pod is deleted, so is the volume. The second is a persistent volume that persists data even when a pod is deleted.

Using plain volumes

Volumes in Kubernetes behave a lot like volumes do in plain Docker. They are only expected to live as long as the pods using them. Every container in the pod may mount the volume and they may mount in the same or different locations. The only restriction is that volumes cannot be mounted on filesystems that are mounted from other volumes. In other words, volumes may not nest:

apiVersion: v1 
...