Month: April 2022

ホストマシンとコンテナのボリュームをマウント

e.g.
ホストマシンの ~/work と コンテナ内の /myapp を同期させる

~/work/file1.txt
/myapp/file2.txt

ファイル名が同じだった場合、ホストマシンがコンテナを上書きする

### Dockerにおけるマウント指定
Dockerによる環境構築をする際、ボリュームをマウントする方法はDockerfile, Composeファイル、コマンドラインの3つがある

### 1. Dockerfileによるマウント
Dockerfile内でVOLUME命令を書く。この命令では、引数としてコンテナ側のディレクトリしか指定することはできない

VOLUME /myapp

Dockerfile

FROM debian
RUN mkdir /myapp && \
	echo "Hello, World" > /myapp/file.txt
VOLUME /myapp

$ sudo docker build -t hello .
$ sudo docker run -it hello bash
# cat /myapp/file.txt
Hello, World

Dockerfileにボリュームのマウント設定をする際は、ホストマシンのディレクトリを指定することができない

### 2. docker-composeによるマウント
composeファイルでは、ホストマシンのディレクトリも指定することができる

volumes:
  - ./work:/myapp

– ホストマシンのディレクトリ： Composeファイルから見た相対パスもしくは絶対パス
– コンテナのディレクトリ: 絶対パス

$ tree
.
├── docker-compose.yml
└── test
└── file.txt
$ cat test/file.txt
hello shinbashi!

docker-compose.yml

version: '3'
services:
  web:
    image: debian
    volumes:
      - ./test:/myapp

$ sudo docker-compose run web bash
Creating network “entrypoint_default” with the default driver
root@e8b020e943ae:/# cat /myapp/file.txt
hello shinbashi!
root@e8b020e943ae:/#

### DockerfileとComposeファイルを同じディレクトリに作成
$ tree
.
├── Dockerfile
├── docker-compose.yml
└── test
└── file.txt

dockerfile

FROM debian
RUN mkdir /myapp && \
	echo "It's a beautiful day." > /myapp/another_file.txt

docker-compose.yml

version: '3'
services:
  web:
    build: . 
    volumes:
      - ./test:/myapp

なるほどー、少し見えなかったものが見えてきた

### ADD
– リモートからもファイル追加できる
– 圧縮ファイルが自動解凍

### COPY
– リモートからのファイル追加はできない
– 圧縮ファイルは自動解凍されない

FROM alpine

# auto unarchive
ADD add.txt.gz /tmp

# Can add from remote
ADD https://github.com/github/fetch/blob/master/README.md /tmp

# Not auto unarchive
COPY copy.txt.gz /tmp

なるほど、mountするときは、Add . /tmp を使って、buildする際は COPY を使うのか
少しずつ繋がっていく感じか…

$ docker run -it centos
bashが起動する理由は、公式イメージで、/bin/bashを実行する命令があるため

CMD [“/bin/bash”]

引数の指定があれば、その引数の実行が優先される

$ docker run -it centos /bin/sh

### ENTRYPOINTが入った場合

FROM centos:latest
ENTRYPOINT ["ping", "-c", "3", "1.1.1.1"]

なるほど、ENTRYPOINTとCMDの違いがなんとなくわかったわ
ENTRYPOINTって言うと、なんか最初の引数みたいだけど、PID1の実行コマンドなのね。
奥が深いにゃー

CMD命令とENTRYPOINT命令はコンテナ内で実行するPID1のプロセスを指定するもの
このイメージは一体何をするのか、何のためのイメージなのかを決定づける命令

FROM debian:9
CMD ping

$ sudo docker build -t myimage .
$ sudo docker run –rm –name myimage myimage
$ sudo docker run myimage date

CMD命令とは
PID1として実行するプロセスのコマンドを指定できる
※PID1とはinitプロセスであり、起動した時に最初に実行するコマンド
そのコマンドは docker run ${image} ${引数}　の引数で上書きできる

### ENTRYPOINT命令のきそ

FROM debian:9
ENTRYPOINT ["ping"]

$ sudo docker build -t myimage .
$ sudo docker run –rm –name myimage myimage 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=398 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=61 time=67.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=61 time=50.9 ms
EXEC形式で書くと、引数を渡すことができる

$ docker container run –entrypoint date myimage
エントリーポイントを上書きできる

### CMD命令とENTRYPOINT命令の組み合わせ

FROM debian:9
CMD ["8.8.8.8"]
ENTRYPOINT ["ping"]

$ sudo docker build -t myimage .
$ sudo docker run –rm –name myimage myimage
これで動く

ENTRYPOINT命令はPID1プロセスのコマンド
CMD命令はコマンドのデフォルト引数を指定できる
–entrypointで上書きできる

これは凄い、1ヶ月くらいやってもまだ理解したとは言い難い
PID1プロセスが大事なのはわかった

Shell形式
– 利点: 記述が簡単、シェル変数展開が利用できる
– 欠点: /bin/sh -c を渡して実行するため、イメージに /bin/sh が含まれてなければならない

Exce形式
– 利点: イメージに /bin/sh が必要ないため、イメージサイズと攻撃面を削減できる
– 欠点: 記述が面倒で、シェル変数展開できない

### Shell形式
Dockefile

FROM busybox
ENV COUNT 3
CMD /bin/ping -c $COUNT 8.8.8.8

$ sudo docker build -t test .
$ sudo docker run –rm –name test test

FROM busybox AS source
FROM scratch
COPY --from=source /bin/busybox /bin/pin
ENV COUNT 3
CMD /bin/ping -c $COUNT 8.8.8.8

### Exec形式
Exec形式は、指定のコマンドを直接実行するもの
Shell形式である必要はないが、JSOフォーマットで記述しないといけない

FROM busybox
CMD ["/bin/ping", "-c", "3", "8.8.8.8"]

FROM busybox AS source
FROM scratch
COPY --from=source /bin/busybox /bin/pin
CMD ["/bin/ping", "-c", "3", "8.8.8.8"]

EXECだとシェル変数展開ができないが、/bin/shは必要ないのね
ShellとExec形式の2種類があるってことはわかった。