社内Wikiに書いていたけど、個人開発でも参考にしたかったので転記しておく。

コンテナ立ち上げたけど Mavenインストールするの忘れた。後からインストールできる？

docker exec -it --user root [CONTAINER] apt install maven ってコマンド実行すればできるよ。

普通に/bin/bash しても sudo が無いので apt でインストールができない
--user root で root実行ができる。
コマンドは /bin/bash にしなくても直接 apt を実行すればいいよね。

Volumeについての雑なまとめ

Volume は、コンテナ内のディレクトリを永続化するためのもの
Volumeを作成するとまずホストPCにVolume用のディレクトリが作られ、コンテナにマウントする
作成されたVolumeは、コンテナを破棄しても削除されない

Volumeの指定方法（作成方法）

docker run の -v オプション

代表的なのは3パターン

使っていきたいのは、 No.3の Volume名を指定する方法。

-v [ホストのディレクトリパス]:[コンテナのディレクトリパス]
-v [コンテナのディレクトリパス]
-v [Volume名]:[コンテナのディレクトリパス]

No.1 は厳密には、Bind mount と呼ばれる設定を行っている。Bind mountは、ホスト側の既存ディレクトリをそのままコンテナ側にマウントする使い方である。なのでVolumeという概念とはちょっと異なる。（更に最近だと非推奨という話も挙がっていた）
このため、Volumeを作成しているのは No.2 と No.3 のみ。この2つの違いは主にVolumeの命名。前者はハッシュ値を名称に割り当てるのに対して、後者は任意の名称を指定できるのでどのコンテナで利用しているVolumeかが分かりやすい。
指定したVolumeがホスト側のどこに存在するかを知りたい場合は、 docker volume inspection [Volume名] を実行する。
以上より、個人的には No.3 の -v [Volume名]:[コンテナのディレクトリパス] を使っていきたい。
更に -v / --volume というオプションではあるが、上記3つの手順で共通していることは、ホスト側のディレクトリをコンテナ側への”マウント”処理である。
No.2 と No.3 の場合は「Volumeを作成してマウントする」,No.1の場合は「ホスト側のディレクトリをマウントする」ということ。
こういう背景があるからか最近では、 -v では無く --mount オプションで指定する方法が推奨されている模様。
--mount だと source=[volume名], target=[コンテナのディレクトリパス] のように属性値を明記したりできる。

Volume は、個別に作成しておくこともできる

docker volume create [volue名] で先に作成しておいて、docker run 時にマウントすることができる。

その他、docker volume では Volumeの一覧や詳細が確認できる。

Docerfile のVOLUME

dockerfile で定義できるVOLUME は、前述のNo.2 のコンテナのマウント先ディレクトリパスを指定するだけのもので、Volume名は定義することができなさそう。
つまり Volume名は定義できず、ハッシュ値となるので正直使い勝手は悪いと思う。

このため、docker run コマンド時に -vコマンドをつけ忘れて実行することを防止する以外の理由では使わない方針にしたい。個人的には必ず -v や --mount オプションを付けることを忘れないようにしたい。

リンク

コンテナにアクセスするときは exec と attach どちらの方がよい？

execの方が良いとのこと。（attachだと入った後に exit するとコンテナも終了するから。）

attach は、コンテナの起動コマンド(エンドポイント) から入るイメージなので、exitしてもコンテナまで終了しない

コンテナにファイルをコピーするコマンド

起動中のコンテナに、ホストOSのファイルをコピーする方法（SCP コマンドみたいなもの）

docker cp CONTAINER:SRC_PATH DEST_PATH

docker cp SRC_PATH CONTAINER:DEST_PATH

前者がコンテナのファイルをホストにコピーする場合。後者が、ホストのファイルをコンテナにコピーする場合。

コンテナ側は <コンテナID:コンテナ内のPath> とどのコンテナかも指定する事

このコマンドは出来る限り使うべきではないと思う。コンテナの用途次第ではあるけども。

理由はコンテナは出来る限り ”ステートレス” で使うべきだから。なので外部からコンテナ内の状態を変えるようなファイルのコピーは行うべきではない。やるなら Dockerfileで恒久的に定義するべき。

なのでこのコマンドは

検証など一時的に利用するコンテナに対して使う。
本番環境など冗長的に使うコンテナでは利用しないようにする。
コンテナからのコピーもで本番環境であれば、元から必要なファイルをVolumeや外部ストレージファイルへ出力するように設計する。(ログファイルとか動的に生成・更新されるファイル)

Dockerfile の WORKDIR の使い方

作業ディレクトリを指定するのが目的
指定したディレクトリが無ければ、作成しつつ移動することができる。

ADD と COPY と RUN の雑なまとめ

どちらもホスト側のファイルをコンテナ側に持って行くために利用する
ADD の場合は、更にそのファイルが圧縮ファイルだと展開まで行う。
ただしそのために、ADDを使った場合の方が、イメージファイルが多く作られ、結果としてサイズの大きいイメージが出来上がる。
なので展開する必要が無ければCOPYを使った方がよい。
とはいえどちらも実行するごとにイメージファイルが作られるし、外部ファイルをコンテナに持ってくること自体に色々と懸念がある。
（dockerfileを配布するときにホスト側で、リソースファイルを用意しないといけない。外部ファイルを使うことでセキュリティリスクが高まるなど）
よって、できるだけADDもCOPYも使わずに、RUNを使って、コンテナ内でCurlやWgetなどでファイルをダウンロードして解凍するなどを行う方がよい。
更に言えば、RUNも実行するごとにイメージファイルが増えていくので、1つのRUN内で & を使って複数のコマンドを実行させたり、キャッシュを利用させることが最も望ましい。

マルチステージビルドで、アプリのビルド環境と実行環境を分ける

マルチステージビルドは例えば、ビルド実行様に作ったイメージから、アプリの実行部分だけを取り出したイメージを作ることが出来る機能
Javaアプリなどで例えば、Mavenやgit、ひょっとしたらCurlなんかですら実際のアプリ環境で不要だとビルド環境をそのまま実行環境として使うと、余計なイメージサイズが増えるのでこれを削減する方法。
仮にMavenでもGradleでもラッパーで実行すればビルドツールのインストールは不要だけど、テスト用など実行環境では不要な依存関係は残ってしまうよね。
マルチステージビルドを使わなくても色々やりようはあるけど、要するに利用するイメージには不要なリソースは載せずに、サイズを軽くさせることを意識することが大事ということ。