Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker-compose #308

Open
uniquejava opened this issue May 3, 2020 · 2 comments
Open

docker-compose #308

uniquejava opened this issue May 3, 2020 · 2 comments

Comments

@uniquejava
Copy link
Owner

uniquejava commented May 3, 2020

~ docker-compose --version
docker-compose version 1.25.4, build 8d51620a
➜  ~ docker --version
Docker version 19.03.8, build afacb8b
➜  ~ docker-compose -f docker-compose-postgres.yml up

First glance

  1. 包含service (一个service可以跑相同image的多个replica)
  2. 可以定义多个containers, networks和volumes
  3. 使用template, variables

v2 vs v3

  1. v2 focus: single-node dev/test
  2. v3 focus: multi-node orchestration
  3. If not using Swarm/K8s, stick to v2

docker-compose.yml (默认文件名)

node.js

version: '2.0'

services:
  web:
    image: sample-01
    build .
    ports:
      - "3000:3000"

mysql

version: '3'
services:
  mysqldb:
    image: mysql:5.7
    container_name: mysqldb
    ports:
      - "3306:3306"
    environment:
     MYSQL_ROOT_PASSWORD: admin
     MYSQL_DATABASE: catalog

docker-compose up

  1. build/pull images(s) if missing
  2. create volume/network/container(s)
  3. starts container(s) in foreground (-d to detach)
  4. --build to always build

docker-compose down

  1. stop and delete network/container(s)
  2. use -v to delete volumes

docker-compose build/stop

  1. many commands take "service" option
  2. build: just build/rebuild image(s) docker-componse build --no-cache 重新执行Dockerfile中的每一行命令
  3. stop: just stop containers don't delete
  4. ps: list "services"
  5. push: images to registry
  6. logs: same as docker CLI
  7. exec: same as docker CLI
@uniquejava
Copy link
Owner Author

uniquejava commented May 3, 2020

github: https://github.com/BretFisher/docker-mastery-for-nodejs

Assignment: Compose CLI Basics

# Run through simple compose commands
$ cd sample-02
$ docker-compose up
$ ctrl-c (same as docker-compose stop)
$ docker-compose down
$ docker-compose up -d
$ docker-compose ps
$ docker-compose logs
# While app is running detached...
$ docker-compose exec web sh
$ curl localhost
$ exit
# edit Dockerfile, add curl with apk
$ RUN apk add --update curl
$ docker-compose up -d
# curl还是不会安装, 因为已经build过一次, 重新build需指定--build
$ docker-compose up -d --build
# Now try curl again
$ docker-compose exec web sh
$ curl localhost
$ exit
# Cleanup(Inside sample-02 directory)
$ docker-compose down

@uniquejava
Copy link
Owner Author

docker 3 types of volumes or mounts for persistent data

see: https://stackoverflow.com/a/47152658/2497876

We basically have 3 types of volumes or mounts for persistent data:

  1. Bind mounts

  2. Named volumes

  3. Volumes in dockerfiles

Bind mounts are basically just binding a certain directory or file from the host inside the container (docker run -v /hostdir:/containerdir IMAGE_NAME)

Named volumes are volumes which you create manually with docker volume create VOLUME_NAME. They are created in /var/lib/docker/volumes and can be referenced to by only their name. Let's say you create a volume called "mysql_data", you can just reference to it like this docker run -v mysql_data:/containerdir IMAGE_NAME.

And then there's volumes in dockerfiles, which are created by the VOLUME instruction. These volumes are also created under /var/lib/docker/volumes but don't have a certain name. Their "name" is just some kind of hash. The volume gets created when running the container and are handy to save persistent data, whether you start the container with -v or not. The developer gets to say where the important data is and what should be persistent.

What should I use?

What you want to use comes mostly down to either preference or your management. If you want to keep everything in the "docker area" (/var/lib/docker) you can use volumes. If you want to keep your own directory-structure, you can use binds.

Docker recommends the use of volumes over the use of binds, as volumes are created and managed by docker and binds have a lot more potential of failure (also due to layer 8 problems).

If you use binds and want to transfer your containers/applications on another host, you have to rebuild your directory-structure, where as volumes are more uniform on every host.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant