先週に引き続きBitcoin関連で週末コーディング。
取引アルゴリズムを考える前に、とりあえずは可視化（と仮説の検証）が必要だろうということで。
ポート管理やら各種パスやら環境変数やらに煩わされたくない怠惰系のアプリケーションエンジニアとしては、 この手のツールがDockerで用意されてると簡単に試せて本当に助かる。
以下Docker Compose導入後という前提で。
続きを読む最近気になった技術ネタ
ここのとこ忙しくて、興味あることもやりたいこともいっぱいあるんだが全然消化できてない・・・
OSの通知センターにRubyからメッセージを投げる
前回紹介したterminal-notifierには、Rubyから使えるterminal-notifier-guardというのがある。
そんなわけでRubyの勉強も兼ねて
- nokogiri+poltergeistを用いたスクレイピング(Nokogiri + capybara + PhantomJS(poltergist)を使ってスクレイピング - Qiita)
- terminal-notifier-guardによる通知(terminal-notifier-guardを使う - 城陽人の本棚)
- bundler gem xxx -bによるひな形作成 (RubyでオレオレCLIツールを作って大人しめに公開する - Qiita)
あたりを使ってはてなブログの当日のアクセス数を取得して通知するツールを書いてみた。
で、ツール自体は一応予定通り動きはしたんだが一つ誤算。
OSXてデフォではcron動いてないんですな。
定期的にコマンド叩かせようと思ってたんだけど、正攻法でlaunchdを記述するにしろ無理やりcron動かすにしろ面倒くさそう。
そのうち定時実行の仕組みを内部に含む形に書き直そうと思う。
Disque
会社のツールではRedisをジョブキュー的に使ってたりもするんだけど、どうやらそのRedisの作者がまさにジョブキュー用のプロダクトを作成してるっぽい。
そのうち試してみたい。
Electron
Visual Studio Codeで使われていることでもお馴染みElectron。
今のところ紹介記事をなぞって動かしてみた程度だけど、本業のウェブ系のスタイルでデスクトップアプリが開発できるのはそこはかとなくワクワク感ありますな。
プラットフォーム・ブラウザ間での差異を気にしないでも済むので、例えば管理画面なんかでも使い勝手良いんじゃないかって気がする。
サブドメインのワイルドカード指定
新しいのを立ち上げるたびに/etc/hostsを追記するのは面倒くさいし、かといってプライベートでDNS立ち上げるのもなーと思っていたけど、そういえばこの手がありましたな。
クライアントの数が少ない分にはこれが一番楽かもしれん。
bacon.js
同僚におふざけでIQ145本を貰ったんだけど、関数型プログラミング以前に論理展開が飛躍しすぎてついていけないし文章的にも厳しいものを感じて放置気味・・・
関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間
- 作者: 岡部健
- 出版社/メーカー: 秀和システム
- 発売日: 2015/04/24
- メディア: 単行本
- この商品を含むブログ (4件) を見る
本自体はアレなんだけど「じゃあ実際のところ関数型プログラムてどういうの？」という興味だけは沸いたりはする。
さて、そんな中でキーワードとして目についたのがbacon.js。
iQ145本ではなんでわざわざ配列でインプットする必要があるのかビタイチ分からなかった(「クール」とか言われましても・・・)のだけど、↑のスライドでスッと理解できたｗ
機会見つけて使ってみたい。
Heroku Docker
Heroku | Introducing 'heroku docker:release': Build & Deploy Heroku Apps with Docker
Herokuの'docker:release'の動き | SOTA
HerokuでDockerが動かせようになるの！？と思ったらそういうことではなくて、どっちかというとHerokuの環境を手元で再現できてそのままデプロイできる(=デプロイしてみたら何故か動かないという事態を避けられる)という感じらしい。
YAPC::Asia 2015
出不精マンなんでこれまで勉強会とかイベント事には関わってこなかったけど、今年で最後ということで思い切って個人スポンサーチケット買ってみた。
８月が楽しみ。
Docker Composeでコンテナ運用を簡単化してみる
Dockerそれなりにいじれるようになり入門レベルは脱したかなと思ってはいるが、色々なものを読むとまだまだ学びがありますな。
先日配信されたWEB+DB PRESS vol.86には正にDocker運用が特集されており、「１コンテナ１プロセスの徹底=パーツの代替可能性確保」あたりなんかはかなり自分の中では意識変革があった。
- 作者: 結城洋志,沖元謙治,足永拓郎,林健太郎,大竹智也,内田誠悟,伊藤直也,中山裕司,hiroki.o,泉水翔吾,佐藤太一,高橋俊幸,西尾泰和,舘野祐一,中島聡,橋本翔,はまちや2,竹原,麻植泰輔,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2015/04/23
- メディア: 大型本
- この商品を含むブログを見る
（今月号の他の記事も含め個人的にヒット率高い。定期購読してない人も手にとってみる価値はあると思う。）
これまではコンテナをアプリケーションの可搬性を良くするもの程度にとらえていたので、supervisordなんかを使って無理やり複数プロセスを１コンテナに押し込み、さながらミニマルなVMとして１アプリ１コンテナで運用することを考えていた。
だが、Dockerの理念に従うならばそれは邪道であり、プロセスごとにコンテナ化してlinkを用いて連携させるのが王道なようだ。
Dockerコンテナ間のlink，database.ymlの書き方 | SOTA
さて、そうなってくるといささか面倒くさくなってくるのがコンテナの管理運用。
１つのアプリケーションを動かすために本体だのストレージだのと複数のイメージを適切な引数を付けて起動しなければならず、ちょっとしんどくなってくる。
起動用にシェルスクリプトを書くとかでも良いっちゃ良いのだが、流石にチームで運用管理するとなるとしんどいし、中の１コンテナだけイメージを更新するとか一括で止めるとか、そういう管理もしづらい。
そこで活躍するのがfig改めDocker Composeだ。
ざっくり言ってしまえばアプリケーションに必要な複数のコンテナだとか起動時の引数だとかをymlファイルに記述することで、一括で操作できるようにしてくれるツールである。
前にfigという名称だったころ試そうとして導入に失敗し、その時はそこまで必要性も感じなくてそのままにしていたんだけど、今回の１コンテナ１プロセスを徹底することを考えると凄く便利ですな。
導入
とりあえず入ってるDockerが1.3以降なことを確認。
$ docker --version Docker version 1.4.1, build 5bc2ff8/1.4.1
ドキュメントに倣い導入する。
# curl -L https://github.com/docker/compose/releases/download/1.2.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose # chmod +x /usr/local/bin/docker-compose
色々やってて気づいたけど(少なくともCentOS６だと)sudo時に/usr/local/bin以下を参照してくれないんですな。
これまでdockerはsudoつけていじってたけど、それだとdocker-composeを素で叩くと動かせず、かといってsudoつけただけだとdocker-composeコマンドが見つからず・・・
vimsudoでいじるなりパス引き継ぐなりエイリアスきるなり方法はあるけれど、それをするぐらいならいっそアカウントをdockerグループに追加してしまった方が楽。（dockerコマンドもsudoなしでいじれるようになるし。）
そんなわけでついでにdockerグループに自分のアカウントを追加しておく。
$ sudo groupadd docker $ sudo usermod -aG docker アカウント名 $ docker ps -a #sudoなしで使えてるのを確認
Let's Chatで実例
ちょうど先日社内で導入したLet's ChatなんかがアプリのコンテナとMongoDBのコンテナを連携させるような構造なので、これをComposeで動かしてみる。
実は元々fig.ymlが同梱されてて、単に持ってきてdocker-compose upでもいけるけど・・・
$ docker-compose up fig.yml is deprecated and will not be supported in future. Please rename your config file to docker-compose.yml
fig.ymlはもう古いぜってな警告でるし、イメージは既に作ってあったりするのでそっちを使うように新たに書きなおしてみた。
docker-compose.yml記述
作業ディレクトリを作り、docker-compose.ymlというファイルを作り下記の記述をする。
web: image: lets-chat:latest links: - db:db ports: - 5000:5000 db: image: mongo:latest
内容は
- イメージ「mongo」をdbという名称のコンテナとして起動
docker run -d --name db mongo - イメージ「lets-chat」を5000番ポートをホストと繋ぎ、先に起動したdbコンテナとリンクさせて起動
docker run -p 5000:5000 --link db:db lets-chat
という２つの操作。
ベタに起動スクリプトを書くのに比べても格段に読みやすく管理しやすいと思う。
docker-composeからの起動
docker-compose.ymlのあるディレクトリで下記コマンドで起動できる。
$ docker-compose up -d #デタッチモードでの起動 Recreating letschat_db_1... Recreating letschat_web_1...
これで記述した両方のコンテナが立ち上がる。
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 08752afba892 lets-chat:latest "npm start" About a minute ago Up About a minute 0.0.0.0:5000->5000/tcp letschat_web_1 d03eec08ad95 mongo:latest "/entrypoint.sh mong About a minute ago Up About a minute 27017/tcp letschat_db_1
あるいは
$ docker-compose ps
Name Command State Ports
-----------------------------------------------------------------------
letschat_db_1 /entrypoint.sh mongod Up 27017/tcp
letschat_web_1 npm start Up 0.0.0.0:5000->5000/tcp
同様にしてdocker-compose killとかdocker-compose rmとかで一括でのコントロールができるので、個別で管理するよりも格段に楽になる。
件の特集記事には他にもログまわりとか監視まわりの話題も載っているので、本格的に使う際には非常に参考になりそう。
- 作者: 結城洋志,沖元謙治,足永拓郎,林健太郎,大竹智也,内田誠悟,伊藤直也,中山裕司,hiroki.o,泉水翔吾,佐藤太一,高橋俊幸,西尾泰和,舘野祐一,中島聡,橋本翔,はまちや2,竹原,麻植泰輔,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2015/04/23
- メディア: 大型本
- この商品を含むブログを見る
Hubot（とLet's Chat）であそんでみる
MSNメッセンジャー全盛の世代としては人工無能を思い出して懐かしくなりますな。
とりあえずザーッと。
モジュールインストール
$ sudo npm install yo generator-hubot -g
作業ディレクトリ作成
$ mkdir myhubot&&cd $_
テンプレート作成
諸々入力してテンプレートを作成する。
ここでアダプタとしてlets-chatを指定しておく。
$ yo hubot
? ==========================================================================
We're constantly looking for ways to make yo better!
May we anonymously report usage statistics to improve the tool over time?
More info: https://github.com/yeoman/insight & http://yeoman.io
========================================================================== No
_____________________________
/ \
//\ | Extracting input for |
////\ _____ | self-replication process |
//////\ /_____\ \ /
======= |[^_/\_]| /----------------------------
| | _|___@@__|__
+===+/ /// \_\
| |_\ /// HUBOT/\\
|___/\// / \\
\ / +---+
\____/ | |
| //| +===+
\// |xx|
? Owner:blue1st
? Bot name: myhubot
? Description: A simple helpful robot for your Company
? Bot adapter: (campfire) lets-chat
? Bot adapter: lets-chat
Shell上で動作テスト
hubotを実行して対話画面に入る。
$ bin/hubot
細かいエラーが出るがひとまず気にしない。
PINGと話しかけると返答してくれる。
myhubot> @myhubot PING PONG
応答スクリプトを作ってみる
下記のような応答スクリプトを/script/talk.coffeeとして作成してみる
module.exports = (robot) ->
robot.hear /ぬるぽ/, (res) ->
res.send "ｶﾞｯ"
robot.respond /今何時/i, (res) ->
d = new Date
hour = d.getHours()
min = d.getMinutes()
res.send "#{hour}時#{min}分"
hearならマッチする文言が登場したときに、respondならbot宛に発言された時に記述された反応を返す。
myhubot> myhubot 今何時? 19時9分 myhubot> ぬるぽ ｶﾞｯ
正規表現で記述しているところから分かるように、res.match[1]とかで発言内容を取得できる。
実用的には例えば指定されたサーバのmuninグラフのURL生成して返すようにすることで、Let's Chatの画像表示機能と合わせてサーバの異常値をすぐに確認できるようにするなんてこともできそう。
cronで定期的につぶやかせる
package.jsonにパッケージを追加
〜
"dependencies": {
〜
"cron": "~1.0.5"
},
〜
処理を記述
/script/cron.coffeeで定時処理を記述する。
cronJob = require('cron').CronJob
module.exports = (robot) ->
new cronJob '0 * * * * *', () =>
robot.send {room: "552fa8c833783d15002fc699"}, "cronだお"
, null, true ,"Asia/Tokyo"
cron処理なのでrobot.sendを使うこと、そして本分の前に引数(roomとか指定する)が一つ必要なことに注意。
shell起動だと関係ないけど、後でアダプターで実際に繋いだ際にroomの指定ないとどこにもメッセージが行かない。
systemのcronと異なり秒から指定できる。
httpdで待ち受けて動作させる
robot.routerを使うことでhttpdでの何かしらのリクエストをトリガーとして動作させることができる。
デフォルトで8080ポート、環境変数PORTで別のポートを指定することができる。
script/httpd.coffeeとして下記のような記述をすると・・・
module.exports = (robot) ->
robot.router.get "/test", (req, res) ->
res.end "ok"
robot.send {room: "552fa8c833783d15002fc699"}, "httpd"
robot.router.post "/echo", (req, res) ->
if not req.body
res.end "ng"
return
res.end "ok"
message = req.body.message
robot.send {room: "552fa8c833783d15002fc699"}, message
$ curl localhost:8080/test ok (chat側でhttpdと発言)
$ curl -XPOST localhost:8080/echo -d message=aaa ok (chat側でaaaと発言)
Let's Chatにつなげてみる
Let's Chat自体はDockerが使えるなら下記の手順で簡単に立ち上げられるので省略。
環境変数を設定する
ボットを駐在させたいROOMのURLの末尾と、ボットアカウントの認証トークンをそれぞれHUBOT_LCB_TOKEN HUBOT_LCB_ROOMSとして登録する。
また、ローカルで動かしていない場合はプロトコル(デフォではhttp)、ドメイン(デフォでlocalhost)、ポート(デフォでは5000)をそれぞれHUBOT_LCB_PROTOCOL HUBOT_LCB_HOSTNAME HUBOT_LCB_PORTとして登録する。
起動する
-aオプションでアダプタとして予めインストールしていたlets-chatを指定、ついでに-nオプションでLet's Chat側でのボットアカウント名に合わせて名称を指定しておく。
$ bin/hubot -a lets-chat -n bot
これで少し待てば、Let's Chatにはbotが入ってくるはず。
Dockerfile化する
色々環境変数もあるしなので、作ったhubotをDockerコンテナ化してみる。
以下のようなDockerfileを作成する。
FROM node:latest RUN npm install hubot coffee -g ADD 今回作ったのを収めたディレクトリ /hubot WORKDIR /hubot ENV HUBOT_LCB_TOKEN ボットアカウントのトークン ENV HUBOT_LCB_ROOMS 駐在させたい各ROOMのURLの/room/以降をカンマ区切りで ENV HUBOT_LCB_PROTOCOL http ENV HUBOT_LCB_HOSTNAME Let'sChatを設置したドメイン ENV HUBOT_LCB_PORT Let'sChatを設置したポート EXPOSE 8080 ENTRYPOINT ["bin/hubot"] CMD ["-a", "lets-chat", "-n", "ボットのアカウント名"]
引数部分だけCMDにすることで、run -it "-a shell"とかすることで任意に挙動を確認できる。
うっかり忘れてしまうところだが、別のコンテナなので同ホスト上であれどlocalhostでは接続できないことに注意。（それ用にコンテナのlinkオプション設定するとかでも良いけどね）
しかし起動時にスクリプトのワーニングが消えない・・・
coffeeスクリプトの書き方もっちょい勉強せんといかんかもしれん。
今週気になった技術ネタ
またも二週間ごしになってしまった...
先週今週は新サーバに環境を構築する機会があり、試みに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率の高さに驚く。
ここ最近のサービスなのに、一気に「無くてはならない」域に入ってきた感じある。
今週気になった技術ネタ
ブクマ中心のエントリならと高をくくっていたら、先週は仕事のサーバトラブルが連続したのとBloodborneに時間を取られて書けなった。
（血に乾いた獣倒してさまよってる。聖剣は確かに強いというか使い勝手が良いというか。）
我ながら呆れるほどの意思の弱さである。
そんなこんなで先週今週のブクマ中心に。
Redis3.0
「仕事のサーバトラブル」の直接的な原因が実はRedisだったりする。
なまじ雑に使ってもそれなりに動くのを良いこと適当に導入してしまったツケが来て、設置サーバのメモリ食いつぶすだとかコネクション張りすぎてレスポンスが遅くなるとか、まあそんな感じ。
そろそろちゃんとした設定とまともな使い方にしていかねば。
さて、そんなRedisが３系に突入。今回の目玉は公式でのクラスタ構成への対応。
これで大規模なサービスでも使いやすくなりますな。
Docker
昨年夏ごろにどんなもんかな程度には使っていたDocker。
仕事で使ってる環境を色々とリプレイスするにあたって導入してみようということのなったのでセルフブクマ。
しかし素のCentOSイメージからPerlがまともに動く(cpanmとか諸々)段階まで持ってくのは意外と骨が折れますな。→yumでgcc、make、gzip, perl, perl-coreあたり入れればいけそう。
その辺だけでいえばubuntuイメージを使うと楽なんだけど、他の環境と合わせることを考えるとなぁ。
Bootstrap
管理画面作成なんかで重宝してるTwitter Bootstrap。
外向けじゃないんでそこまで使い込んだりカスタマイズしたりはしてないけれど、それでも用法に沿って組めばそれなりの見た目になってくれるという恩恵は大きくて、もはやこれなしでは仕事が成り立たないんじゃないかって位に思っていたりする。
さて、そんな「Bootstrapを用いたサイト設計」という部分に着目した本が出てたらしく、個人的にすごく気になっている。
これからのWebサイト設計の新しい教科書 CSSフレームワークでつくるマルチデバイス対応サイトの考え方と実装〈Bootstrap・コンテンツファースト・コンポーネント設計〉
- 作者: 松田直樹,後藤賢司,こもりまさあき
- 出版社/メーカー: エムディエヌコーポレーション
- 発売日: 2015/03/23
- メディア: 単行本
- この商品を含むブログ (2件) を見る
これまでも使い方ガイド的なのはあったけれど、そうじゃなくて設計レベルの話が書いてあるらしい。
デザイナーさんレベルとまではとはいわないが、ある程度「機能としてのデザイン」位はできるようになりたいし、何より「パーツの再利用」あたりは開発の効率化のためにも是非取り入れたいところ。
今度買ってみようかなと思っている。
VRヘッドセット
にわかに盛り上がりをみせているこの界隈、僕も手を出してみたいなーと思いつつも古参のOculusRiftなんかは母艦にそこそこ性能がいるらしいので手を出せずにいたり。
あくまでユーザの立場でいうとPS4という強力な母艦もありコンテンツも豊富なProject Morpheusあたりが本命になってくるけれど、ここに新たにSteamVRなるものが登場するらしい。
「母艦どうするの」「コンテンツどうするの」問題を考えるとOculusより現実的な気がするし、おそらく母艦になるであろうSteamMachineも基本的にはゲーミングPCだからPS4よりは開発者フレンドリーになりそな予感。
それぞれ発売時期が今年末〜来年ということで、今からワクワクといった感じ。お金貯めなきゃな。
Surface3
割と評判の良いSurfacePro系に対し、いまいちどこまで使えるんだか分からないRT搭載のせいですっかり陰の薄いSurface系。
どうやら方針転換があって3では普通のWindowsが乗るらしい。
プライベートで使ってるデスクトップがすっかり古くなり、Windows使うのはNasneから円盤に焼く時ぐらいだしそこまで性能はいらんから↓みたいな安価なタブレットでも買ってみようかな思っていたんだけど、価格帯と時期によってはこっちも良いなーと思ったり。
- 出版社/メーカー: Asustek
- 発売日: 2014/10/18
- メディア: Personal Computers
- この商品を含むブログを見る
今更ながらCentOS6.4にDocker導入してみる
アプリ側の人間なんでインフラいじりは本業ではないのだけど、だからこそその辺の煩わしさを減らして気軽に色々試したいなーということでDocker勉強始めてみた。
Docker導入
インストール
EPELより
# yum install -y docker-io
起動
# service docker start
バージョン確認
# docker version Client version: 1.0.0 Client API version: 1.12 Go version (client): go1.2.2 Git commit (client): 63fe64c/1.0.0 Server version: 1.0.0 Server API version: 1.12 Go version (server): go1.2.2 Git commit (server): 63fe64c/1.0.0
自動起動設定
# chkconfig docker on
使ってみる
Hello world
とりあえず仮想CentOS上でechoしてみる。
# docker run centos echo "Hello world" Unable to find image 'centos' locally Pulling repository centos b157b77b1a65: Download complete 511136ea3c5a: Download complete 34e94e67e63a: Download complete Hello world
最初はイメージをダウンロードしてきた後にコマンドが実行される。
結構サクッと。
当たり前だけど二度目はダウンロードなし。
# docker run centos echo "Hello world" Hello world
コンテナを起動してみる
# docker run -i -t centos /bin/bash bash-4.2#
オプションはインタラクティブ・ターミナルの意。
こんな感じでコンテナ内に入れる。
ここで諸々の操作をして環境を作る。
ちなみにexitコマンドで抜けられる。
コンテナ確認
docker ps -aで起動していたコンテナの確認ができる。
# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a67741966c87 centos:latest /bin/bash 2 minutes ago Exited (0) About a minute ago tender_sammet
ちなみに消すには
# docker rm [コンテナID]
イメージの保存
環境作ったらイメージを保存。
# docker commit 3fd1c5b1e0a4 blue1st/test 933754bdc3d046930813b8f42ec36b8de3a6079fcedb5e1129cf47361652f354
IDとイメージ名を指定する。
イメージ名は「ユーザ名/〜」の形が一般的らしい。
imagesで確認できる。
# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE blue1st/test latest 933754bdc3d0 28 seconds ago 243.7 MB centos latest b157b77b1a65 4 days ago 243.7 MB
ほいでもって、runでもって起動できる
# docker run -i -t blue1st/test bash-4.2#
ちなみにイメージ削除は
# docker rmi [イメージID]
バックグランド実行とか
現実には何がしかのコンテナで何かしらのミドルウェアなりアプリなりを動かし、ポートフォワーディングでホストから接続する形になると思う。
この場合は
# docker run -p [ホストのポート]:[コンテナのポート] -d [リポジトリ]
みたいな形で起動する。
ちなみに止める時は
# docker kill [コンテナID]
その他
実用上は、必要な操作等を記述したDockerfileを使って自動でコンテナの環境を作成してそれを使っていくらしい。
こっちの方はおいおい勉強していきたい。
ちょっと前まではVagrant＋Chefで環境つくって云々と考えていたけど、何気に勉強が必要な要素多いしサーバリソース食うしで実のところやる気がダダ下がってったんだけど、こっちは割とシンプルでサクッとできそうなのが好感触。
Docker入門 Immutable Infrastructureを実現する
- 作者: 松原豊,米林正明
- 出版社/メーカー: 技術評論社
- 発売日: 2014/04/25
- メディア: Kindle版
- この商品を含むブログ (5件) を見る
