最近の更新 | |
---|---|
ドライランのありがたみを改めて知る
| 2024/04/04 |
伊豆半島
| 2024/03/31 |
お出かけチェックリスト
| 2024/03/29 |
Ruby
| 2024/03/27 |
Kubernetes
| 2024/03/22 |
音楽データをDisplayAudioで聞く
| 2024/03/09 |
Redmine
| 2024/02/05 |
git
| 2024/02/02 |
経済
| 2024/01/08 |
どうする家康
| 2023/12/17 |
MX-Linux
| 2023/11/06 |
國體関連学-休学のご連絡
| 2023/08/13 |
Debian
| 2023/08/02 |
CentOS
| 2023/06/13 |
Dell-XPS13
| 2023/05/23 |
ベルト
| 2023/05/18 |
SourceForge
| 2023/04/17 |
確定申告
| 2023/02/19 |
さらば「まぐまぐ」
| 2023/01/09 |
風猷縄学
| 2022/11/23 |
Docker なるものを使ってみる。
Linux デスクトップを使用している僕としては原理的に vmware や virtualbox より良さげ。
https://fa-works.com/blog/visualizing-docker-containers-and-images の図が 分かりやすいのだけど、僕なりにまとめたのがこちら:
$ docker run centos:7 cat /etc/centos-release CentOS Linux release 7.4.1708 (Core)
$ docker run ubuntu:16.04 cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 ...
上の図では run = create + start と書いたけど、厳密には違うようだ。
例えば、 docker run -d オプションは create にも start にもない。 ここら辺の細かい動作は僕はまだよく分かってない。
firewalld を docker container に入れるとしばらくして外につながらなくなる:
$ wget http://www.yahoo.co.jp ... wget: unable to resolve host address ‘www.yahoo.co.jp’
不明(2019/07 時点)
これはもう非推奨の模様
これが僕の場合はいいかも
127.0.0.1:13306 を 172.29.0.2:3306 につなげたいのだけど、その方法として
$ sudo systemctl start sshd $ ssh -N -L 13306:172.29.0.2:3306 localhost
$ sudo firewall-cmd --zone=external --add-forward-port=port=13306:proto=tcp:toaddr=172.29.0.2:3306
$ docker network create --subnet 172.29.0.0/16 my-fixed-ip
$ docker network connect bridge A
サーバ用途に固定IPを付与したかったので別ネットワーク 'my-fixed-ip' 172.29.0.0/16 を作ったけど、その中のコンテナ A は元のネットワーク 'bridge' と デフォルトでは通信できなかったので、 上記コマンドが必要だった次第。
新しい docker (少なくとも v1.13.1 以上では対応されている) では、 docker run に --add-host オプションを使って /etc/hosts にエントリーを追加できる。
$ sudo apt purge docker.io $ sudo rm -rf /var/lib/docker
一旦 commit して image から作りなおさないといけないようだ:
$ docker stop [CONTAINER] $ docker rename [CONTAINER] [CONTAINER-bkp] $ docker commit [CONTAINER-bkp] [REPO]:TAG] $ docker run ... -p NEW_PORT:NEW_PORT ...
…と言う2つのニーズを満たすために、sshd を Docker で走らせる必要があった。
「Docker にて sshd を走らせるのは良くない」と言う記事があるけれど ( http://postd.cc/docker-ssh-considered-evil/ ) 今回は「sshd 必要環境」を用意する必要があるので、この論点の対象には 入らないかな。
凡例:
[APP-USER]: | コンテナユーザ。例: my_app |
[CONTAINER-DIR]: | コンテナディレクトリ。 -v でホスト側に接続。例: /home/MY/docker/。⇔ [HOST-DIR] |
[DPORT]: | docker port で得るポート番号。例: 32768 |
h$: | ホストプロンプト。⇔ c$ |
[HOST-DIR]: | ホスト側ディレクトリ。例: /home/MY/docker/。⇔ [CONTAINER-DIR] |
c#: | コンテナプロンプト(root) |
c$: | コンテナプロンプト。⇔ h$ |
[MY-APP-HOST]: | コンテナホスト |
[MY-APP-WITH-SSHD-CONTAINER]: | コンテナ名 |
[MY-APP-WITH-SSHD-IMAGE]: | イメージ名 |
[UID]: | [APP-USER] uid。例: 1000 |
FROM centos:7 RUN yum install -y openssh-server tar which wget RUN yum install -y iproute openssh-clients # CentOS7 only RUN mkdir -p /etc/chef/ohai/plugins # itamae の bug 回避。itamae 用途以外では不要
h$ docker build -t [MY-APP-WITH-SSHD-IMAGE] - <Dockerfile
h$ docker run -P -d \ -v [HOST-DIR]:[CONTAINER-DIR] \ --hostname [MY-APP-HOST] \ --name [MY-APP-WITH-SSHD-CONTAINER] \ --privileged \ [MY-APP-WITH-SSHD-IMAGE] \ /sbin/init
h$ docker exec -d [MY-APP-WITH-SSHD-CONTAINER] /usr/sbin/sshd -D
h$ docker port [MY-APP-WITH-SSHD-CONTAINER] 22/tcp -> 0.0.0.0:[DPORT] # コンテナ側ポート 22 に対応するホスト側ポート [DPORT] を知る h$ ssh -p [DPORT] root@localhost
以降は、セキュリティ強化のために行っておくこと:
下記を改変:c$ sudo vi /etc/ssh/sshd_config ... PermitRootLogin no ... PasswordAuthentication no ...
一度構築したコンテナで、以降 sshd が不要であればもう起動する必要はない
※ この節で書いた方法は、 https://docs.docker.com/engine/examples/running_ssh_service/ を参考に しているけど、僕の用途では過剰な設定なので、もはや不要。
参考: https://docs.docker.com/engine/examples/running_ssh_service/FROM centos:6 RUN yum install -y openssh-server tar which wget cronie RUN yum install -y openssh-clients # scp サーバ側動作に必要 RUN /etc/init.d/sshd start # key の生成に必要 RUN sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd ENV NOTVISIBLE "in users profile" RUN echo "export VISIBLE=now" >> /etc/profile EXPOSE 22 CMD ["/usr/sbin/sshd", "-D"]
※ "Downloading Packages" で5分ほど反応がないが、待つ。h$ docker build -t [MY-APP-WITH-SSHD-IMAGE] - <Dockerfile
h$ docker run -P -d \ -v [HOST-DIR]:[CONTAINER-DIR] \ --hostname [MY-APP-HOST] \ --name [MY-APP-WITH-SSHD-CONTAINER] \ [MY-APP-WITH-SSHD-IMAGE]
してみる。# /usr/sbin/sshd -D -d
h$ docker exec -it [MY-APP-WITH-SSHD-CONTAINER] bash c# adduser -u [UID] [APP-USER] c# yum install passwd c# passwd [APP-USER]
h$ docker exec -d [MY-APP-WITH-SSHD-CONTAINER] /usr/sbin/sshd -D
以下、docker 内で:h$ docker port [MY-APP-WITH-SSHD-CONTAINER] 22/tcp -> 0.0.0.0:[DPORT] h$ ssh -p [DPORT] [APP-USER]@localhost
c$ mkdir .ssh/ c$ chmod go-rwx .ssh
以降、key-pair でログイン可能h$ scp -P [DPORT] ~/.ssh/id_rsa.pub [APP-USER]@localhost:~/.ssh/authorized_keys [APP-USER]@localhost's password: *********
下記を改変:c$ sudo vi /etc/ssh/sshd_config ... PermitRootLogin no ... PasswordAuthentication no ...
注: docker exec の -u(--user) オプションは、[APP-USER] に docker コンテナに root 権限を与えるようで、/etc/sudoers なども見放題となってしまう。通常のユーザ権限の範囲で実行するには 上にように su する必要があるようだ。h$ docker exec -it [MY-APP-WITH-SSHD-CONTAINER] bash -c 'su - [APP-USER']
分かっていなかったのでメモ。build するとき、何も考えずに
$ docker build -t [tag] . # 僕の場合では間違っていた方法
としていたのだけど、この '.' はイメージをを作る際の起点となるようで。 . 以下全データが docker daemon に送られるとのこと。
僕は . 以下に開発リポジトリなど持っていたところ、数G のイメージが 作られてしまった…。はい、アホです。
僕の用途では必要ないので、そういう時は
$ docker build -t [tag] - <Dockerfile
とするのが正解のようだ。
コミット: | docker commit |
イメージ一覧: | docker images |
$ docker stop myproject-dev $ docker rename myproject-dev myproject-dev-before-ubuntu-16.04 $ docker commit myproject-dev-before-ubuntu-16.04 リポジトリ名:タグ名
$ docker create ..
$ docker start myproject-dev
-rw------- 1 root root 146 3月 9 09:59 2016 /etc/resolv.conf
ホスト: | MX Linux 21 (Debian 11(bullseye)) |
コンテナ: | CentOS 6.7 |
$ sudo apt install docker.io
$ sudo adduser [USER] docker
これがないと docker build 時に下記エラーに:$ sudo apt install apparmor
AppArmor enabled on system but the docker-default profile could not be loaded: running `apparmor_parser apparmor_parser --version` failed with output: error: exec: "apparmor_parser": executable file not found in $PATH
$ sudo docker pull centos:6
$ sudo docker run -it centos:6
# adduser -u [NNNN] [MyName] # su - [MyName]
$ mkdir -p SOME/DIRECTORY
例:$ sudo docker commit [commit-id] [name]
$ sudo docker commit 2fb761c8c516 add-MyName
$ sudo docker run -it -v [HOST-DIR]:[GUEST-DIR] [name]
ここで 192.168.2.1 はホストOSの参照する DNS$ sudo $EDITOR /etc/default/docker DOCKER_OPTS="--dns 192.168.2.1" $ sudo service docker restart
VirtualBox + 同ゲスト(CentOS 6.7) + ホストとは NFS 共有、 という環境と比較する。
どちらも Rails アプリ(DB = MySQL)を走らせ、 rake test:performance で計る。
結論から言うと、Dockerの方が倍近く速かった ( ・∀・)イイ!!
速すぎなので、逆に VirtualBox の NFS が今まで悪い環境だったのかと 思ったりも…。
項目 | Docker | VM |
---|---|---|
rubyソース | ホストvolume上 | ホストfs NFS経由 |
MySQLデータ | ホストvolume上 | ゲストfs |
「速度云々」は僕の開発マシンでの話し。
他方、Dockerにまつわる誤解とベストプラクティスについて にて「『速度のためにDockerを使うべき』は誤解」とあるけれど、 この著者も冒頭で念押しされているけれど、こちらはミッションクリティカルでの話し。
両者は Docker の使用目的が全然違うので、矛盾しているわけではないと思っている。
$ docker pull ubuntu:12.04 $ docker run ubuntu:12.04 cat /etc/lsb-release ... DISTRIB_RELEASE=12.04 ... $ docker run ubuntu:12.04 apt-get update
$ docker run -it ubuntu:12.04 bash