タグ: Docker

Windows の設定 (Win+I) → System → About → Windows Specifications を開いて、”Version” の項を確認してください。（最初から version とかで検索しても出てくるはず。）　これが最新の 2004 （かそれ以上）である必要があります。

まだなら Windows を更新

OS の Windows Update の画面から更新を何度確認しても降ってこなかったので（そういうものなの？）、インストーラーを探してインストールしました。こちらから。

Download Windows 10

URL 的に将来再利用されそうだけれど、現時点では最新版 “Windows 10 May 2020 Update” がダウンロードできます。このファイル自体はダウンローダー？なので一瞬で終わるんだけど、それを起動して更新をダウンロード、インストールするのに 30 分くらいかかりました。ほげえ。

なお最新の状態でこのインストーラーを起動しても「今最新版だよ～」と教えてくれるだけなので無害です。

ただし人によってはこれでインストールできない場合もあるらしい。どういうんだろう。

Virtual Machine Platform を有効化

Install Windows Subsystem for Linux (WSL) on Windows 10 | Microsoft Docs

管理者権限で PowerShell を開き、以下を実行します。

> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

1 分くらい？

カーネルをインストール

Updating the WSL 2 Linux kernel | Microsoft Docs

この “Download the Linux kernel update package” の節から wsl_update_x64.msi をダウンロード、実行。

Windows Subsystem for Linux Update Setup のウィンドウ — 更新はウィザードでぽちぽちするだけ。

WSL 2 を使う

（任意）デフォルトで WSL 2 を利用するように

WSL 1 と 2 を併用できます。Microsoft Store とかでダウンロードした Linux ディストロをインストールするときの初期値をそのどちらにするか設定できるようです。

2 にするなら、こう。

> wsl --set-default-version 2
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

利用中の WSL 1 を 2 へ変換

一覧から名前を得て、その名前を対象に更新します。

まずは一覧を表示して、名前を得ます。この例では “Ubuntu” ですね。

> wsl --list --verbose
  NAME      STATE           VERSION
* Ubuntu    Stopped         1

この名前 “Ubuntu” を覚えておく。

続いて --set-version します。

> wsl --set-version Ubuntu 2
Conversion in progress, this may take a few minutes...
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
…

数分かかるとのことだが 60 分経っても終わりませんでした。ま、まただましたな！

完了したらバージョンが上がったのを確認。

> wsl --list --verbose
  NAME      STATE           VERSION
* Ubuntu    Running         2

使う

あとは普通に使うだけ。やったね。

やっぱり戻す

WSL 側から Windows 側ファイルの監視があやしい。

/mnt/c/User/ginpei 下にプロジェクト配置してるんだけど、どうも watch が怪しい感じがする。かつて普通の VM (VirtualBox) を使ってた頃も同じような問題に直面したような。

新機能は別途試すとして、やっぱり今の環境はそのまま残しておこう……ということにしました。残念。

バージョンをまた変える

さっき WSL 1 → 2 にしたのと同じ手順で 2 → 1 へ変換します。

> wsl --set-version Ubuntu 1

はいこれで元通り。こっちの変換の方が所要時間が少ない様子。

変換にかかる時間

対象は新規にダウンロード、インストールした空っぽの Ubuntu 20.04 LTS です。空っぽだと変換が速いみたい。

WSL のデフォルトを WSL 2 にしているので、2 → 1 → 2 の順番に変換してます。

2 → 1

1 分。

> Measure-Command { wsl --set-version Ubuntu-20.04 1 }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 49
Milliseconds      : 284
Ticks             : 492840008
TotalDays         : 0.000570416675925926
TotalHours        : 0.0136900002222222
TotalMinutes      : 0.821400013333333
TotalSeconds      : 49.2840008
TotalMilliseconds : 49284.0008

1 → 2

4 分。

> Measure-Command { wsl --set-version Ubuntu-20.04 2 }


Days              : 0
Hours             : 0
Minutes           : 3
Seconds           : 42
Milliseconds      : 670
Ticks             : 2226708369
TotalDays         : 0.00257720876041667
TotalHours        : 0.06185301025
TotalMinutes      : 3.711180615
TotalSeconds      : 222.6708369
TotalMilliseconds : 222670.8369

WSL 1 vs 2

An overview on the the Windows Subsystem for Linux | Microsoft Docs
- Comparing features

表を翻訳して転載。

機能 WSL 1 WSL 2

Windows と Linux の統合 ✅ ✅

高速起動 ✅ ✅

省サイズ ✅ ✅

Managed VM ❌ ✅

完全な Linux カーネル ❌ ✅

完全なシステムコール互換性 ❌ ✅

現行版の VM Ware や VirtualBox と併用 ✅ ❌

OS のファイルシステム越しのパフォーマンス ✅ ❌

機能	WSL 1	WSL 2
Windows と Linux の統合	✅	✅
高速起動	✅	✅
省サイズ	✅	✅
Managed VM	❌	✅
完全な Linux カーネル	❌	✅
完全なシステムコール互換性	❌	✅
現行版の VM Ware や VirtualBox と併用	✅	❌
OS のファイルシステム越しのパフォーマンス	✅	❌

（Managed VM って何？　本当の VM だよって意味？）

感覚的には、こんな感じ↓かなと思ってます。正しいですか？

WSL 1 は Windows のまま Linux のコマンドを動かす（Cygwin や MinGW みたいな）
WSL 2 は Windows とは別に Linux VM を動かす（VM Ware や VirtualBox みたいな）
- あと、 2 は Windows 10 Home でも使える

Docker

Docker が WSL2 サポート！というニュースだけ耳にしてろくに追ってなかったため勘違いしてたんですが、

WSL2 の中で Docker が完全に動くわけではない

っぽいです。

WSL2 で用意した Ubuntu に Docker を用意してもデーモン起動に失敗しました。

Docker がサポートしたのは WSL2 上の Linux ではなく「WSL2 バックエンド」だそうで、つまり Docker Desktop for Windows を経由してコンテナーを WSL2 の仕組みで実行させる、というものであるらしい。……これで合ってる？

Docker Desktop WSL 2 backend | Docker Documentation

Docker を使う流れ

なので、こんな流れ。

WSL2 準備（本稿）
Docker Desktop インストール
- Install Docker Desktop on Windows | Docker Documentation
Windows のコマンドプロンプト cmd.exe から docker run hello-world

さっくり動きました。

Docker側がWSL2を利用する設定をオンにするか聞いてくる様子 — Docker Desktop を更新すると WSL 2 を使うかどうか聞いてくる。

エラー

管理者権限が必要

Power Shell なり何なりを普通に起動すると、権限を elevate してねと言われます。管理者権限で起動してください。

>dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Error: 740

Elevated permissions are required to run DISM.
Use an elevated command prompt to complete these tasks.

不明なオプション

メモ取り忘れたんだけど、WSL 2 の準備が終わってないと --set-version とか諸々が使えません。（ wsl コマンド自体は存在する。）

順にやっていきましょう。

カーネルが古い

「不明なオプション」と同じ。まだ WSL 2 の準備が終わってません。『カーネルをインストール』の節を参照。

> wsl --set-default-version 2
WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

Docker が使えない

WSL2 で動かしてる Linux の中でも Docker 使えないっぽいです。そうじゃなくて Docker Desktop for Windows 経由で、コンテナーを WSL 2 で走らせます。『Docker』の節を参照。

以下 Ubuntu で試したもの。

$ docker run hello-world
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.

Docker デーモンが動いてない？　じゃあ動かそう。

$ sudo systemctl start docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

このエラー見たことある……。

$ sudo reboot
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Failed to talk to init daemon.

だめっぽいですね。VM の中に VM はだめ、みたいな。Docker Desktop 経由でやりましょう。

おしまい

仕事は引き続き WSL 1 でやることにします。

とはいえ Docker 使ってやっていきをしたいところ。ファイル監視はな～どうしたら良いかな、気のせいであってほしいけど。

参考

Ruby on RailsをDockerで始めるサンプルとチュートリアルを書いたよ。

投稿日時: 2018/08/07 20:48

カテゴリー: Ruby on Rails

タグ: Docker, Ruby on Rails, チュートリアル

書いたぞ。

ginpei/docker-rails-example

日本語版の方をセルフ転載します。最新版はGitHub↑のほうで。

Windowsの方

コマンドプロンプトやPowerShell入力時、 `pwd` を %CD% に置き換えてください。

じゃないと例えばこんな感じのエラーになります。

docker: Error response from daemon: create `pwd`/app: “pwd/app” includes invalid characters for a local volume name, only “[a-zA-Z0-9][a-zA-Z0-9_.-]” are allowed. If you intended to pass a host directory, use absolute path.

準備

事前に以下が必要です。

Dockerインストール

このサンプルを試す

あるいは既存プロジェクトに参加する例。

リポジトリをクローン
Dockerコンテナーを起動
DBを初期化
いえーい
止める

(さらに…)

Docker公式イメージでWordPress環境を用意する。

投稿日時: 2017/11/08 15:18

カテゴリー: サーバー

タグ: Docker, Docker Compose, WordPress

library/wordpress が公式に提供されているのを昨日知りました。WWW+PHP+WordPressなパッケージみたい。DBは library/mysql を使うとして、この二つでさっくり環境が用意できました。

$ docker run --rm -d --name my-mysql -e MYSQL_ROOT_PASSWORD=passwd -v `pwd`/db:/var/lib/mysql mysql
$ docker run --rm -d --name my-wordpress --link my-mysql:mysql -p 80:80 -v `pwd`/wp:/var/www/html wordpress

これで http://localhost を開くと、WordPressの初期設定が始まります。DBの初期処理にちょっと時間がかかるので、エラーが出てもちょっと待ってて開きなおしたりしてください。

終了は

こう。

$ docker stop my-mysql my-wordpress

Windowsは

pwd の代わりに %CD% を使います。

$ docker run --rm -d --name my-mysql -e MYSQL_ROOT_PASSWORD=passwd -v %CD%/db:/var/lib/mysql mysql
$ docker run --rm -d --name my-wordpress --link my-mysql:mysql -p 80:80 -v %CD%/wp:/var/www/html wordpress

後述のDocker Composeを使うと書き分ける必要がなくなります。

変数的なもの

以下の値は適宜変更してください。

my-mysql … MySQLコンテナの名前。
my-wordpress … WordPressコンテナの名前。
passwd … DBのパスワード。開発用となら適当でいいんじゃないの。
80 … ポート番号。 : で分けて左辺は任意。右辺は 80 で固定。
pwd/db, pwd/wp … 生成ファイルを配置するディレクトリ。絶対パス（フルパス）にする。

DBやアップロードしたファイルの行方

-v pwd/db:/foo 的な記述のおかげで、コマンド実行時の作業ディレクトリ直下に db, wp の二つのディレクトリが作成されるはずです。これらを保存しておいて、次回も -v で指定します。

新しい環境にする場合はここをさくっと変えればよろしい。

wordpressイメージ

安心安全のDocker公式イメージです。

PHPとApacheが含まれたイメージを元に作成されているみたい。（ものによるけど。）　DB以外が揃ってるので簡単に始められる。ありがとう、ありがとう。

WordPressのバージョン

tagsのページを見ると4.8.3, 4.8.2の二つが用意されているっぽい。

でも docker pull wordpress:3 とかで普通に落ちてくるし使えるので、試してないけど一通り用意されてるんじゃないでしょうか。知らんけど。

あるいは、Dockerfileは前述の通り公開されてます。やっぱり試してないんだけど、こいつの WORDPRESS_VERSION の数字をいじるだけで他のバージョンに対応したやつも作れるんじゃないすかね。知らんけど。

バリエーション

例えばこんなタグがあります。

4.8.3-php7.1-fpm-alpine
4.8.2-php5.6-apache
cli-1.4.0-php7.1

なんか色々あるみたいなので公式ドキュメントを読んで、良さそうなものを見つけてください。

単純にWordPressのバージョンを指定するだけだと、PHP5.6とApacheとの組み合わせになるみたいです。（古いバージョンについて調べてないです。）

“cli” については次項。

WP-CLI

こちらさまね。

Command line interface for WordPress | WP-CLI

wordpress:cli でCLIも使えます。

$ docker run --rm -ti --volumes-from my-wordpress --link my-mysql:mysql wordpress:cli plugin list
+---------+----------+-----------+---------+
| name    | status   | update    | version |
+---------+----------+-----------+---------+
| akismet | inactive | available | 4.0     |
| hello   | inactive | none      | 1.6     |
+---------+----------+-----------+---------+

あら便利。

話には聞くけど使ったことはないです。ちゃんと動くよね？　大丈夫？

ところでこれって、

ものが全然違うから将来分割されるんじゃないかなあ。 wp-cli みたいなのに。あ、まんまだ。それとも、サーバの方もなんかいろいろあるし、これでいいんだろか。

自分が作ったテーマを別途追加する

実践編。

たぶん個別にGitで管理したりしてると思うので、そういうのは別々に追加していきましょう。

-v ないし --volume で指定します。 : の左側にテーマのディレクトリ（絶対パス）、右側に配置先、つまり /var/www/html/wp-content/themes/xxx 的なやつを書きます。

$ docker run --rm -d --name my-wordpress --link my-mysql:mysql -p 80:80 \
-v `pwd`/wp:/var/www/html \
-v `pwd`/my-great-theme:/var/www/html/wp-content/themes/my-great-theme \
-v /path/to/my-wonderful-theme:/var/www/html/wp-content/themes/my-wonderful-theme \
wordpress

（さすがに長いので改行しました。）

-v でもっと追加してもいいですよ。

とはいえこんな長えのを毎回ぽちぽちしてらんねえーので、Docker Composeを使います。（シェルスクリプトが好きならそっちでも良いと思う。）

Docker Composeにする

相対パス使えて便利ね。

 # docker-compose.yml
version: "3"

services:

  wp:
    image: wordpress
    ports:
      - "80:80"
    volumes:
      - ./wp:/var/www/html
      - ./my-great-theme:/var/www/html/wp-content/themes/my-great-theme
    depends_on:
      - db

  db:
    image: mysql
    volumes:
      - ./db:/var/lib/mysql
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "yes"
      MYSQL_DATABASE: wordpress
      MYSQL_USER: username
      MYSQL_PASSWORD: password

これで起動すれば “Database Host”を “db” にする以外はそのままぽちぽちいけるはずです。

$ docker-compose up

終了は Ctrl+C で。

envが増えてしまうのが謎。いやDocker直でやったらいらない方が謎か。

きっとありがちなエラーとトラブルシュート

名前が被った

docker: Error response from daemon: Conflict. The container name “/my-wordpress” is already in use by container “0c38694fb63ec30c7e5c1a2140489055dec35a3e6b6031af81be4b591e089ec1”. You have to remove (or rename) that container to be able to reuse that name.

その名前（ --name で指定したもの）は既に稼働中です。他の名前を付けるか、現在稼働中のものを停止してください。

たぶん停止し忘れ。

ポートが使用中

docker: Error response from daemon: driver failed programming external connectivity on endpoint my-wordpress2 (87a56c6aaaf8adc1a12dcfa26a0f18917bf9fc4809a65726a5eb47d39ad0b3b9): Bind for 0.0.0.0:80 failed: port is already allocated.

そのポート（ -p で指定したもの）は既に稼働中です。他の番号を使うか、現在稼働中のものを停止してください。

先の例では80番で起動したけど、例えば8080番で起動する場合はこう。

$ docker run --rm -d --name my-wordpress --link my-mysql:mysql -p 8080:80 -v `pwd`/wp:/var/www/html wordpress

そしてポート番号を指定して http://localhost:8080 みたいにして開いてください。

MySQLを起動していない

docker: Error response from daemon: could not get container for my-mysql: No such container: my-mysql.

先に docker run ... mysql 的なアレを実行して、MySQLのコンテナを用意してください。その後WordPressを起動。

`db`, `wp` ディレクトリが作られない

例えば相対パスは使えません。

こちら駄目な例。

$ docker run --rm -d --name my-mysql -e MYSQL_ROOT_PASSWORD=passwd -v ./db:/var/lib/mysql mysql
$ docker run --rm -d --name my-wordpress --link my-mysql:mysql -p 80:80 -v ./wp:/var/www/html wordpress

絶対パスで書くか、冒頭のように pwd や %CD% を利用します。

`pwd` 周りに使えない記号が含まれている。

docker: Error response from daemon: create `pwd`/wp: “`pwd`/wp” includes invalid characters for a local volume name, only “[a-zA-Z0-9][a-zA-Z0-9_.-]” are allowed. If you intended to pass a host directory, use absolute path.

Windowsだと pwd が使えないです。本記事冒頭参照。

localhostに繋がらない

初回ならたぶんMySQL待ちです。

念のためdockerの状況見ときましょうか。

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
730219bd4919        wordpress           "/entrypoint.sh ap..."   6 seconds ago       Up 29 seconds       0.0.0.0:80->80/tcp   my-wordpress
29d4002b011b        mysql               "docker-entrypoint..."   15 seconds ago      Up 38 seconds       3306/tcp             my-mysql

一覧右端 “NAMES” に my-wordpress が出てくれば大丈夫。のはず。

DBエラー

Error establishing a database connection

たぶん前項と同じ。

あるいはイメージのバージョンを変えちゃったとか。それならバージョンを戻すか作り直し。

イメージを変えたのにWordPressのバージョンが変わらない

ちゃんと db, wp のディレクトリを新しいのにしました？

書いてる人について

WordPressは仕事で使ったことないですのでそこらへんの温度感についてはお察しください。

Docker入門みたいなやつやってみたよ。（下書き供養 Advent Calendar 2018 – 05日目）

投稿日時: 2017/06/04 00:00

カテゴリー: サーバー

タグ: Docker, Docker Compose

この記事は下書き供養 Advent Calendar 2018の05日目の記事です。

というわけで公開は2018年12月05日ですが、書いたのは2017年06月です。記事の日付は後者の方を設定しました。ちなみに開催はもうちょっと前で2017年04月でした。あらやだ怠惰。

当日利用したリソース群はこちらにまとまってます。

ginpei/20170429-docker

ちなみにWordPressやるならその名の通り library/wordpress というDocker公式イメージが公開されてるので、そっち使う方が楽だと思います。

Docker公式イメージでWordPress環境を用意する。

（以下、下書きの状態であったもの。書きあがってるっぽいのでそのまま。）

当方初心者なんだけど、まわりにやってる人が少なくて、利用者が増えたらいいなーそんでもって誰か詳しくなっておれに教えてくれたらいいなーくらいの感じでやりました。

本当は詳しい人にも来てもらって駄目出しされつつ進行したかったんだけど、日程が合いませんでした。先にそっち合わせとけっていう。

というわけで、やった内容を書いておきます。「利点について」→「単語と知識」→「手を動かす」という流れです。

Dockerとは何か

端的に言うと、

仮想マシンです。
仮想マシンじゃないです。

「使う」側からすると自分のマシン（物理）の中に別のマシンが仮想的に用意されて、その中で色々走ったりするよーっていう感じ。実際は「仮想マシン」と呼ばれる技術とは別物で、仮想ハードウェアをすっ飛ばして直接物理リソースを使うとかなんかそういう？違い？があるらしい。

あとコンテナを小分けにしてっていうのもVM方面にだけ慣れてるとすぐには出てこない発想かなーと思う。

何が嬉しいのか

VMでも何でもいいんだけど、基本的にはホストマシンと分けて環境を作れる嬉しさというものがあると思ってます。ほら汚染とかバージョン管理とかさ。

開発者向けには

開発環境を簡単に用意できる
実際こんな手順
1. git clone
2. docker-compose up
3. やったね
いらない
- Node.js, Ruby, Python, etcのインストール
- Sass, Babel, Rails, image magic, etcのインストール
- ウェブサーバの設定
- ネットワークの設定（たぶん）

誰かがDocker環境を用意してくれていて、それを使うという状況です。

データベースの用意とか、 gem install sass とか、そもそも言語環境の用意とかそういうのをすっ飛ばして、一発でwatchとかローカルサーバとかを起動できます。

Docker自体もWin/MacともにGUIでインストールできるので、準備の難易度は低いかと思ってます。（でもWindowsだとHyper-Vが必須だったりするのかな？　自分は元々使ってたし、周りが皆Macなんで調べてない。）

上位開発者には

今度はDocker環境を用意する側のひと。Makefileとかnpm scriptを用意するあたりの人達。

環境の詳細が文書化される
環境を他の人と共有できる
過去に作った環境を再利用したり拡張したりできる

自分のマシンにぽちぽちインストールして環境作って、いざそれを他の開発者にも使ってもらおうとすると、割と面倒くさかったりするじゃないすか。試行錯誤してると文書化するの億劫だし。

そういうのが全部 Dockerfile と docker-compose.yml に残るので、「えーとあれこれってどうやって入れたんだっけ？」「そもそも入れたっけ？」みたいなのがなくなります。文書に残っているので、環境の共有はそのファイルを共有するだけで事足ります。（パスワードとかの秘匿情報については別途にしても良さそう。）

あとは後から変更したり拡張したりも、残ってるのでいけるはず。

アドミンには

サーバの管理者さんとか。

開発環境を簡単に用意できる
本番環境を簡単に用意できる
環境を簡単に複製できる

ここら辺は完全に想像です。

既存プロジェクト

をDocker化することもできるのでは。

依存パッケージのインストールが不要に
- grunt, gulp, rails, etc
プロジェクトのディレクトリの外からあれこれできる

プロジェクトが /home/ginpei/myproject にあったとして、 /home/ginpei/myproject-docker みたいなのを用意してそっちにDocker系ファイルを置いたりとかして、既存のものは既存のままにしておけば、簡単にできるのではないか？と思いました。

でも実際やってみたら別の問題があって、ちゃんとできるのかわかりません……、という話をしました。なんかwatchがうまく動かなかったんだけど、まあこの話はいずれ。

使ってみよう

ワークショップ前に知識の整理をしました。

使う場合

Docker本体のインストールは別にして、

ファイル群をダウンロード
- git clone
コンテナ作成
- docker-compose up

でおわり。

※ただし理想的な環境に限る

作る場合

Dockerfile でコンテナを用意
docker-compose.yml でコンテナ群を連携
docker-compose up で起動

これだけ言ってもわからんと思うけど、こういう流れです。

単語

コンテナ … 仮想マシン実体的な。実際に動くもの。作って捨てる
イメージ … ISOイメージ的な。コンテナの素。ダウンロードしてくる。作れる
docker … イメージからコンテナを作成するコマンド
docker-compose … 複数のdockerコマンドをまとめてやってくれるコマンド
ボリューム … 記憶領域。コンテナを作りなおしても消えない

コンテナ vs イメージは、OOPのクラス vs インスタンスに近いかなと思ってます。

ファイル

Dockerfile
- マシンひとつ分（イメージ）の設定
- Linuxのディストリビューションとか
- インストールするパッケージとか
docker-compose.yml
- マシン間の繋がりの指定とか
  - データ専用マシンとか
- 簡単なマシンの設定とか
- 実マシンへの露出の設定とか
その他
- Nginxの設定ファイルとか

ワークショップ

ここ↓に当日使用したやつが残ってます。

ginpei/20170429-docker

用意した環境はこんなの:

all/ … ダウンロードする用に色々書いただけ
php/ … PHP + Nginx + MySQL
rails/ … Ruby on Rails
web-front/ … gulp + sass + browser-sync
wordpress/ … 当日皆で一緒に作ったやつ

最初に all/ で docker-compose up してもらうと、一通りのイメージが降ってきます。皆で一斉にやるとネットワークがつらそうなので、各自自宅でやってきてもらいました。

php, rails, web-front はこちらが用意した環境を使ってみようというやつです。だいたい何もしなくても、すぐに何かが起動します……というわけにはいかなくて、 rake db:migrate とか npm install とかが必要です。今回はそれはそういうもんだということにしてやってもらいました。

最後、 wordpress は自分で docker-compose.yml をはじめ各種設定を書いて「環境を作る」を体験するやつです。構成はだいたい php と一緒。

その他話したこと

コンテナを小分けにする

Vagrantだと全部入りのマシンを用意して普通に（実マシンと同様に）あれこれする感じなんだけど、Dockerないしコンテナ云々の技術大系ではばらばらに用意してからネットワークで繋げていく、みたいな感じらしい。疎結合って言えるのかな。

全部入りにしない利点はよくわかってないです。一番大事なところなんだろうけど。たぶん、イメージ再構築のコストを減らすとかそういうところなのかなって想像してます。そのうち調べる。公式ドキュメントに書いてあったのは覚えてる。

バージョンを固定する

ビルドするたびに「同じ」環境になってほしいよね、なのでイメージのバージョン指定に latest はやめましょう、と。

イメージとコンテナ、そしてボリューム

イメージはダウンロードしてきて長いことファイルに保存されます。コンテナは使うたびに新規作成して、使い終わったら削除されます。

OOPでいうところのクラスとインスタンスみたいな関係。

削除されるということはコンテナ内でファイル編集しても元に戻っちゃうので、編集するファイルはボリュームとして残します。ボリュームにも二種類あって、ホストマシンのファイルをマウント？して使う場合と、Docker内で「これとっといてねー」みたいに指定するのとがある。

イメージとレイヤー

イメージはダウンロードしてくるだけじゃなくて、自分で Dockerfile を書いて作成できる。

イメージはでかい塊だけど、実は玉ねぎみたいに複数の層から成っている。（だから、実は docker image ls で出てくるサイズはディスクに保存されるファイルサイズと直結しない。）

基本的にひとつのレイヤーは Dockerfile の指示一行ごとに作成される。なので、一時ファイルを作成するような指示は一行の中でその削除までするのが好ましい。（下記の例。）　さもなくば一時ファイルがある状態の上に削除した状態のレイヤーがかぶさるだけなので、レイヤーのファイルサイズがでかくなる。

RUN apt-get update && apt-get install -y \
    ruby1.9.1 \
 && rm -rf /var/lib/apt/lists/*

あと、レイヤーもイメージ。名前が付いてるかどうかが違う、と言いきっちゃって良い？

Dockerそんなによくないよね

って話もいくつか共有しました。

Dockerの本番運用 | インフラ・ミドルウェア | POSTD … 様々な環境 (OS) で試したけどひとつ残らず何かしらの問題があってつらい、という話。
Docker盲信してる皆様へ … もっと良いやり方あんだろーという話。「続き」の方が本論っぽい。はてブで反論も読める。
実際に運用してみてわかった、大規模Mastodonインスタンスを運用するコツ – pixiv inside … Dockerでも動かせるOSSをDockerなしで動かしたって話。つまりDocker直接関係ないです。（Docker以外にも選択肢はあるよ、ということを言いたかった。）
Docker？なにそれおいしいの？ for フロントエンド（だけやる）エンジニア – console.lealog(); … 今回 web-front ということでホストマシンにnodeをインストールすることなく gulp とかアレしたんだけど、結局そういうのもつらいよねって話。

話さなかったこと

初手の選択肢は少ない方が良い、という方基本針です。あと知らないものは知らないので。

コンテナ化技術

知らなくても使えるので第一歩で触れる必要なさそう。おれ自身詳しくないし。

`docker` vs `docker-compose`

composeの説明でちょっと触れたくらい。

compose以外のオーケストレーションツール

Kubernetes てのが熱いらしいぞ！　でもおれ使ったことないぞ！

Docker Hub

イメージのダウンロードに絡めてちょっとだけ。

Moby

忘れてた。まあいいか。

パッケージのバージョン管理

イメージのバージョンを固定した方が良いぞという話はしたんだけど、パッケージ類のバージョンについては触れてなかったはず。

で、そのパッケージ類も固定化した方が環境が安定しそう。

Dockerfile で単純に apt-get とかすると「そのとき」のパッケージをダウンロードしてくるので、一年ぶりにビルドしたらツールのバージョンが変わってた……とかになっちゃうかもしれない。もしくは古すぎて消えてるとか。

そもそも Dockerfile を共有すること自体が既に悪手で、誰かがイメージまで用意してからそれを docker-compose.yml で指定する、の方が良いのではないでしょうか。

どうなんすか、先生。

イメージの配布

前項と絡めて話せるかなと思うけど、しなかった。Docker Hub以外の場所を使うやり方も知らないしなー。

`docker-compose run xxx` 系

「このコマンドを入力してください」という形でさんざん使ってはもらったんだけど、説明はあんまりしなかった。「もうbashでいいじゃん！」みたいになってもアレだなーと思って。

とはいえ、コマンド実行する必要がある場合はどうするのが良いのかなあ。ほら、初期設定は別にしてもRoRで rake db:migrate とかばんばんするでしょ。別途シェルスクリプト的なものを用意しておくの？

やってみた感想

いろいろたいへんだったけど、たのしかったです。