読者です 読者をやめる 読者になる 読者になる

そんな今日この頃でして、、、

コード書いたり映画みたり。努力は苦手だから「楽しいこと」を探していきたい。

今週気になった技術ネタ

技術ネタブクマ Docker Hubot

またも二週間ごしになってしまった...

先週今週は新サーバに環境を構築する機会があり、試みにDockerを使っていこうという流れになったのでそれ関連が多め。


Dockerfile

blue1st.hateblo.jp

↑のようにとりあえずコンテナを立ち上げて作業して環境を構築してイメージとしてコミットするVM的な運用もできなくはないが、メンテナンス性を考慮するならDockerfileを作成するスタイルのほうが良い。

kimh.github.io

inokara.hateblo.jp

とりあえず最低限以下のコマンドを把握しておけばひと通りの作業はできそう。

コマンド 動き 書式
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を使えばよいらしい。

qiita.com

会社のサーバじゃ専ら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"]

有難いことに、いろんなミドルウェアについての設定のしかたがまとめられてる記事があった。

qiita.com


Dockerでcron

上で述べたのと同様の理由でコンテナ上でcronは動いていない。

色々調べてみたのだが、CentOS6をホストにしたCentOS6のコンテナではどうにも動かせない・・・

qiita.com

↑だと出来たみたいな報告もあるけど、どういう条件でそうなるんだろう?

Ubuntuコンテナなら/bin/bash cron -fで動かせそう。

qiita.com

とはいえ社内環境はCentOSなんで、なにかしらの方法もしくは代替手段は探して行きたい。


Let's Chat

社内のコミュニケーションツールIRCから別のものに移行したいという話があり、色々と検討してみた。

要件としては

  1. 社内サーバで運用できること
  2. ログがとれること
  3. 部署ごとの複数のチャンネルを作れること
  4. (できれば)何かしらの手段で外部連携できること

といったところ。

候補としてはDevHubやKandanといったところが挙がったが、

  • DevHubは情報のフロー〜ストックまでカバーする設計は興味深いものの「分かってる人」向けな印象であり、非エンジニアに使わせるには辛そう
  • Kandanは最新版は後述するHubot動かないとか動くバージョンは色々UIが言うこときかなくて辛い

ということで、最終的に良さそうだったのがLet's Chatというツール

sdelements.github.io

sdelements/lets-chat · GitHub

Hubotのアダプタも用意されている。

sdelements/hubot-lets-chat · GitHub

Dockerfileが同梱されてて、気軽に立ち上げて試せるのも嬉しいですな。

Docker · sdelements/lets-chat Wiki · GitHub

シンプルで説明なしでも使えるUIに加え、デスクトップ通知もしてくれるのが良い。

現行のIRCと比べるとトーク的な方法が無いのと権限管理的なことが出来ないのが不満といえば不満だが、そのあたりは運用でなんとかしていきたい。


Hubot

そんなわけでLet's Chat導入に合わせて色々と試して遊んでいるのがHubot。

qiita.com

nagiosのアラートをつぶやかせたりデプロイを通知させたりしようと画策中。

余談だけどここでもYeoman使われてるんですな。

blue1st.hateblo.jp


しかし見返すとQiita率の高さに驚く。

ここ最近のサービスなのに、一気に「無くてはならない」域に入ってきた感じある。