またも二週間ごしになってしまった...
先週今週は新サーバに環境を構築する機会があり、試みにDockerを使っていこうという流れになったのでそれ関連が多め。
Dockerfile
↑のようにとりあえずコンテナを立ち上げて作業して環境を構築してイメージとしてコミットするVM的な運用もできなくはないが、メンテナンス性を考慮するならDockerfileを作成するスタイルのほうが良い。
とりあえず最低限以下のコマンドを把握しておけばひと通りの作業はできそう。
| コマンド | 動き | 書式 |
|---|---|---|
| FROM | ベースとなるイメージを文頭で記述する | FROM centos:centos6 |
| RUN | イメージ作成時に実行したいコマンド | RUN yum install -y git |
| WORKDIR | 作業ディレクトリを移動 | WORKDIR /tmp |
| ADD | ホスト側のファイルをコンテナに収める | ADD ./files /files |
| ENV | 環境変数を設定する | ENV PLACK_ENV production |
| CMD | コンテナ起動時に実行したいコマンド | CMD ["/usr/bin/supervisord", "-c", "/etc/supervisord.conf"] |
他にも開放するポートを予め示すEXPOSEやマウントするディレクトリを示すVOLUME、CMDと同じく起動時のコマンド実行だが引数で上書かれないENTRYPOINTなどがある。
CMDなら作ったイメージに対して通常は普通にrunするところを-it bashでチェックしやすいやん！と思ったけど、そういうのならコンテナ起動した上でexec -it bashで良かった。
となると固定動作はENTRYPOINTで記述して引数レベルだけCMDに記述するのが良いのかもしれん。
memorycraft: Dockerってなんじゃ？（Dockerfileでビルド）
注意点としてはCMDやENTRYPOINTなんかはそれぞれ最終の一行だけが適用される感じなんで、次に述べるように複数のプロセスを実行させるみたいなことはできない。
Supervisor
DockerコンテナはVMより手軽に作り壊しができるってことで重宝しているのだが、必ずしもVMと同等ではないことには留意しなければならない。
コンテナはあくまでファイルスペースやプロセスの分離こそが趣旨なのだ。
この思想の現れ方のひとつが、コンテナ内で単一のフォアグラウンドプロセスを動かし続けていなければ終了してしまう点。
とはいえ複数のプロセスを動かすことが前提のアプリケーションを単一のコンテナに載せたいという要求はある。
こんな場合、どうもググってみた感じだと一般的にはSupervisorを使えばよいらしい。
会社のサーバじゃ専らdaemontoolsを使われていてこれまで縁がなかったのだが、yumで導入できるし設定読みやすい・書きやすい感じが良いですな。
Docker以外でも使っていきたい。
実際にコンテナ上で動かそうと思った場合、Dockerfileに下記のような記述をすれば良さそう。
#Supervisorをインストール＆設定ファイル作成 RUN yum install -y epel-release RUN yum install --enablerepo=epel -y supervisor RUN touch /etc/supervisord.conf RUN echo '[supervisord]' >> /etc/supervisord.conf RUN echo 'nodaemon=true' >> /etc/supervisord.conf
# 例:Elasticsearchの起動コマンドを設定に追加 RUN echo '[program:elasticsearch]' >> /etc/supervisord.conf RUN echo 'command=/usr/share/elasticsearch/bin/elasticsearch -f' >> /etc/supervisord.conf
# 起動 CMD ["/usr/bin/supervisord", "-c", "/etc/supervisord.conf"]
有難いことに、いろんなミドルウェアについての設定のしかたがまとめられてる記事があった。
Dockerでcron
上で述べたのと同様の理由でコンテナ上でcronは動いていない。
色々調べてみたのだが、CentOS６をホストにしたCentOS６のコンテナではどうにも動かせない・・・
↑だと出来たみたいな報告もあるけど、どういう条件でそうなるんだろう？
Ubuntuコンテナなら/bin/bash cron -fで動かせそう。
とはいえ社内環境はCentOSなんで、なにかしらの方法もしくは代替手段は探して行きたい。
Let's Chat
社内のコミュニケーションツールをIRCから別のものに移行したいという話があり、色々と検討してみた。
要件としては
- 社内サーバで運用できること
- ログがとれること
- 部署ごとの複数のチャンネルを作れること
- (できれば)何かしらの手段で外部連携できること
といったところ。
候補としてはDevHubやKandanといったところが挙がったが、
- DevHubは情報のフロー〜ストックまでカバーする設計は興味深いものの「分かってる人」向けな印象であり、非エンジニアに使わせるには辛そう
- Kandanは最新版は後述するHubot動かないとか動くバージョンは色々UIが言うこときかなくて辛い
ということで、最終的に良さそうだったのがLet's Chatというツール。
Hubotのアダプタも用意されている。
sdelements/hubot-lets-chat · GitHub
Dockerfileが同梱されてて、気軽に立ち上げて試せるのも嬉しいですな。
Docker · sdelements/lets-chat Wiki · GitHub
シンプルで説明なしでも使えるUIに加え、デスクトップ通知もしてくれるのが良い。
現行のIRCと比べるとトーク的な方法が無いのと権限管理的なことが出来ないのが不満といえば不満だが、そのあたりは運用でなんとかしていきたい。
Hubot
そんなわけでLet's Chat導入に合わせて色々と試して遊んでいるのがHubot。
nagiosのアラートをつぶやかせたりデプロイを通知させたりしようと画策中。
余談だけどここでもYeoman使われてるんですな。
しかし見返すとQiita率の高さに驚く。
ここ最近のサービスなのに、一気に「無くてはならない」域に入ってきた感じある。
