初めに
本記事はDocker advent Calendarの3日目の記事になります。
Docker は今年の3月からようやく触り始めたのですが、
もっと早く知っておけば良かったなぁと一年間ずっと後悔する程に感動的でした。
(多分 Vagrant とか Chef とかを当時勉強しておけば、その時にも同じ感動を味わえたんだろうなぁ。。)
まだ触っていない方がいらっしゃいましたら是非ともトライしてみて欲しいです。
大げさに言うと価値観が変わります。
本記事でまとめること
→ 私的 Docker の使い方
→ Docker の良いところ、ツラいところ
→ 気に入っている周辺ツール
→ 来年頑張りたいこと
私的 Docker の使い方
開発
基本的にはこのリポジトリでやっているように、大文字キャメルケースのディレクトリに各コンテナのDockerfile
を持たせておいて、最上位階層にdocker-compose.yml
を置いておきます。
$ tree
.
├── docker-compose.yml
├── Nginx
│ ├── custom_conf
│ │ ├── nginx_general.conf
│ │ ├── nginx_oauth.conf
│ │ └── nginx_team.conf
│ ├── Dockerfile
│ ├── general
│ │ └── index.html
│ └── only_team
│ └── index.html
├── OAuth2Proxy
│ ├── Dockerfile
│ ├── extra_whitelist.txt
│ └── oauth2_proxy
└── README.md
開発の際は最上位階層でdocker-compose up --build -d
することで各コンテナを立ち上げ、ホストとディレクトリを共有させておいて、ホスト側で開発を行うようにしています。
本番環境
今年は3月から新しい仕事を任され、そのプロジェクトの本番環境には AWS Beanstalk の multi-container docker というプラットフォームを採用する事にしました。
※ 以下 AWS Beanstalk multi-container docker プラットフォームの事を指して Beanstalk と書きます。
AWS におわす神々曰く、 ECS の開発には並々ならぬ力を割いておられるらしく、 ECS を直で使うほうが良いよとの事。
。。だったのですが、実はワタクシ AWS 自体も今年の3月から初めてちゃんと触るという体たらくだったため、コンソール画面でポチポチやれば、 ELB やら AutoScale Group やら、勝手によしなに用意してくださるところが大変魅力的で、結局神々の忠告を無視する形で Beanstalk を使っていました。
Beanstalk ではDockerrun.aws.json
というファイルでデプロイするのですが、これがdocker-compose.yml
とほぼ同じように書けたので、そこもとても良いなぁって思っています。
あと、Docker のログドライバに awslogs を指定しておくと、全標準出力と標準エラー出力を AWS CloudWatch Logs に垂れ流してくれるので、こちら大変オススメです。
アラームを設定しておくと(もう少し頑張って欲しい機能ではあるのですが)例えば「Error」という文字列が検出されたときに Slack に通知を送るような事も簡単に出来ます。
Docker の良いところ・ツラいところ
良いところ
-
技術の試し食いが簡単に出来るところ。
- 色んなツールに対する参入障壁が下がったなぁという印象
- Virtualbox で試し食いしてたあの頃にはもう戻れない。。
- 暇な時は dockerhub の公式リポジトリ内を徘徊して、面白そうなミドルウェアを発見したら手元で動かしてみて遊んでいます。
-
「動く」状態をファイルで共有できる事
- これは私が Vagrant だの Chef だのが流行っていた当時にそこらの勉強をサボっていたせいで今更喜んでいるだけに過ぎないのですが、人にファイルを共有して、あとは
docker-compose up
で同じものが動作するなんて、なんて素敵なんだろうと心底思います。 - 「動く」ってのが良いですよね!「動く」ってのが大事!
- バージョン管理も出来ますしね。
- これは私が Vagrant だの Chef だのが流行っていた当時にそこらの勉強をサボっていたせいで今更喜んでいるだけに過ぎないのですが、人にファイルを共有して、あとは
-
便利そうなツールや仕組みが沢山出てくるところ
- 大変他人任せな話ですが、 k8s にしても AWS Fargate にしても、とりあえずコンテナイメージ化しておけば後はどうとでもなるという状況が整ってきているなぁって思います。開発環境で動かしているものがそのまま本番でも動かせる(しかもスケールも簡単!)なんて、これ以上素敵なことってないですね。
ツラいところ
- 会社で貸与される PC が Windows なんですよね。。。
- 大抵の場合 Mac か Windows で選べたりすんですが、私が結構な Apple 製品嫌いでして、となると Windows しか選択肢がないわけです。
- ゆるされるなら即座に OS 抜いて Kubuntu にしたい。。けど貸与 PC にはセキュリティソフトなんかも入っているので、中々許しが得られない。
- Docker for Windows は開発しづらかった。。Virtualbox 使えなくなるし。。
- 結局のところ Windows の場合は Virtualbox の中に lubuntu でも立ち上げて、そこで Docker 環境立ち上げたほうがまだ開発しやすいという結論になった。
- WSL で dockerd が動く未来早よ!
気に入っている周辺ツール
docker-compose
多分、僕は Docker そのものというよりも docker-compose が好きなんだと思う。docker-compose が無かったとして、ここまで自分の開発スタイルが Docker に依ることは無かったなぁとさえ思うくらいに。
SchemaSpy
こちらの記事でとても分かり易く取り上げられている SchemaSpy。ER図を吐き出してくれるとても気の利く子。そしてこの記事を読んで、--net "host"
としておくとホストマシンと同じネットワークが使えることを知った。勉強になるなぁ。
Goose
この方のリポジトリを参考に、Goのバージョンだけ、1.5では動かなかったので調整した。 docker run
でマイグレーションを実行できるのがお手軽で良い。
Portainer
Docker for Windows を一度試した際に付いて来た Kitematic みたいなツール。現在立ち上がっているコンテナとか、持っているイメージの一覧とかが GUI で確認できるもの。
Portainer はそれ自身もコンテナとして立ち上がるところがすごく素敵。Docker をまだ使ったことがない人に Docker の事を勧める時に重宝する。けど、自分で使うときは CLI で操作するのであまり立ち上げることは無い。
来年頑張りたいこと
今年は docker-swarm や k8s には手が出なかったです。
何か難しそうな印象が強いのと、それらは本番環境を見越した技術であり、開発のための技術ではないような気がしていて旨味を想像できませんでした。
ただ、AWS も EKS や Fargate なるものを発表したし、開発は本番環境を見越して行う必要があるので来年はそれらの技術にも親交を深めつつ、もっと Docker に対する理解を深めたいと思います。