ほわいとぼーど

ぷろぐらまのメモ帳

開発環境をDockerにした話

Docker

若干釣りタイトルっぽい。
どの開発環境かという話だけど、自分の場合、

  • インフラ用途のちょっとしたPythonスクリプトの開発
  • Terraformをローカルから実行する
  • 開発したAnsibleのRoleをローカルで試す
  • golangの開発をローカルで行う

みたいなのをこれまではVagrant＋Virtualbox上で行ってきた。
主な理由として、

  • 家のPCはWindowsでLinux開発をローカルで実施しにくい
  • 会社のMacでもローカルを汚したくない
  • 家と会社の環境を共通化したい

みたいなのがある。
TerraformやgolangはMacローカルにも入れてたのだけど、
BrewCaskでの更新が危うく、やはりローカル直は管理ダルイよねと。
Vagrantでも回っていたんだけ思考。

でDockerでやることにしたんだけど、 やるだけならぶっちゃけ簡単で
Docker Toolboxさえ入れておけば、あとは
「python:2.7.11-slim」とか「golang:latest」
とか引っ張ってきてほぼ終了なのだが、
利便性のためにいくつかのツールを同梱するようにした。

  • direnv
  • peco
  • ghq

direnvはAWSの複数アカウント切替のため。
direnv allowの結果を保持するのでユーザホームもマウントしている。
peco+ghqはレポジトリ管理をgopath方式にしていて便利に使うため。
$GOPATHをマウントする。捗る。

あと一番やりたかったのはAnsibleで1.9系と2.x系の移行期をDockerで切り抜けたいのだが、
実はココはまだうまくいってない部分がある。

そんなわけで雑なDockerfileを量産体制に入りつつ、
余勢を駆ってあわよくばアプリもどうにかしていきたいと画策しているところ。
Mac for Dockerはまだ試してません。

Docker Toolboxで時刻を合わせる話

Docker Toolbox

Docker ToolboxでDocker使っていて時刻がずれて
直し方をなんだかんだで何度か調べているのでメモっておく。
(自分が欲しい方法が一発で検索されない)

ググると何種類か方法が出てくるのだが自分が直したい場面はそんな致命的じゃなくて
スリープ直後に時間がずれてAWS APIとか叩くと怒られた時くらいなので　　

docker-machine ssh default "sudo ntpd -q -p 1.jp.pool.ntp.org"

Docker Toolboxの裏側のboot2docker vmにssh経由でntpdコマンドを実行する。
これをMacはalias、Windowsはシェルで置いておいて、
怒られたら一旦containerから出て(もしくは別窓開いて)実行する。

元コマンドは次を参考にしました。
MacでDockerを動かす際に気をつけること

Windosw環境のDocker Toolboxでshared foldersのpermission設定する話

Docker Toolbox VirtualBox Windows

最近、VagrantをDockerに置き換え始めてるのだけど、 以前*1と同じ問題が発生したので対応した。

Docker Toolboxも裏側はVirtualbox + boot2dockerなので基本は一緒なのだが、
Docker Toolxoxだと今のところ設定でどうにかする方法は用意されてなさそうなので、
(前回のmount_optionはあくまでVagrantの機能実装)
作成されたVMを権限変えてマウントしなおす。

docker-machine ssh default "sudo umount c/Users"
docker-machine ssh default "sudo mount -t vboxsf -o uid=0,gid=0,fmode=0666,dmode=0777 c/Users /c/Users"

この作業はVMをcreateしたりstop-startする度にやる必要があって、
さすがに面倒だったのでクジラの絵を出してるシェルを適当にハックした。

C:\Program Files\Docker Toolbox\start.sh

この中でVMが存在するかチェックしてcreateする部分と、
VMのstatusをチェックしてstartする部分があるので

if [ $VM_EXISTS_CODE -eq 1 ]; then
  "${DOCKER_MACHINE}" rm -f "${VM}" &> /dev/null || :
  rm -rf ~/.docker/machine/machines/"${VM}"

(中略)

  "${DOCKER_MACHINE}" create -d virtualbox "${VM}"
fi

VM_STATUS="$(${DOCKER_MACHINE} status ${VM} 2>&1)"
if [ "${VM_STATUS}" != "Running" ]; then
  "${DOCKER_MACHINE}" start "${VM}"
  yes | "${DOCKER_MACHINE}" regenerate-certs "${VM}"
fi

この2箇所の後ろに2行ずつ追加すればよい。

  "${DOCKER_MACHINE}" ssh "${VM}" "sudo umount /c/Users"
  "${DOCKER_MACHINE}" ssh "${VM}" "sudo mount -t vboxsf -o uid=0,gid=0,fmode=0666,dmode=0777 c/Users /c/Users"

これで次に起動したりする際には権限を変えてマウントされる。
なお、これはdefault VMの設定なので、自分でcreateした場合には自分で対処する必要がある。
あとDocker Toolboxを更新するときにリセットされそうな気もする。

参考: Dockerにホストのフォルダをマウントしたい！

*1:Windows環境のVagrantでsynced_folder時にpermission設定する話

2段階認証+Windows10+SourceTree+Github

MFA github Windows SourceTree

先日、「AWSとGitHubに2段階認証の導入」という記事を見かけたのと
同僚が2段階認証を啓蒙していたので設定することにした。
MFA用のアプリはGoogleAuthenticatorをこれまで使っていたのだけれど、Authyに変更した。
多数並んだ時にアイコン付きで非常にわかりやすそうで、
更にバックアップ面でも効果がありそう。

入れ方はココを参照した。

  • 若干UIが変わってる部分があったが流れを読めばさほど問題ない
  • GoogleChromeExtensionと連携する際にアプリ側で受け入れる設定をする箇所があった
  • GoogleChromeExtensionがアプリ側で設定した更新の一部がうまく反映されないような・・・
    • 入れなおしたら反映されたのでバージョンとかあるかも、、Authyの公式から順に入れよう
  • 登録内容は暗号化されてサーバに保管されるので携帯交換が起きてしまってもAuthyから復旧できるらしい

Githubを2段階認証にするとhttps方式でアクセスしていた人はそのままではダメで、
アクセストークンを設定する必要があるそうなのだが、
ここはオーソドックスにSSH認証に変更する。
更に複数アカウントの人の場合はssh_config等で工夫する必要があり、
Linux的には普通だが自分の場合はWindowsだったので少し手間取った。

Windows10、SourceTreeを利用した設定をメモしておく。

基本的には次の通り
Windows+SourceTree+SSHに関してはこれ

  • msysgit導入
  • SourceTree設定で「システムGitを使用」
  • SourceTree設定で「PuTTY/Plink」ではなく「OpenSSH」を設定する
  • C:\Users\username.ssh\config にssh_config設定
    • C:\Program Files\Git\etc\ssh\ssh_config でもよいかもしれないが権限変更が必要だったので回避

何でOpenSSH設定でいけるのかちゃんと調査してないが、
msysgitを導入すると使えるようになった気がする。
というのはSourceTreeの「ターミナル」からsshコマンドを実行できているので。

2015年振り返り

適当メモ

雑感

SIerから事業会社に転職して1年以上が経ちました。
転職自体はおおむね満足しています。
やりたい事がやれる、というと若干語弊があるのですが、
不足しているものはいくらでもあって気づいた人が手を上げればやれる、という感じでしょうか。
インフラ的ポジションになってこちらも1年強ですがやりたいことは尽きないです。
前に戻りたい要素は無いですね。
自分の技量面の不足は圧倒的に感じます。

仕事の内容で見ると前半は仕組みを作ろうと少しずつやってたのですが
後半は運用雑務に追われてしまったように思います。
夏からチームメンバーが増えたので自分が運用保守している間に
なにかしら新しいものを作ってもらうことが出来るようにはなってきました。
2016年はもっと柔軟な構成をとれるように土台の仕組みづくりしていきたいです。

ざっくりやったこと

  • AnsibleでSetup
  • AWSもAnsibleで
  • mackerelで監視
  • fluetdでログバックアップ(S3)とログ可視化(Kibana)
  • AlertもERRORログSlackへ
  • hubot＋Slackでデプロイ、Setup、一部状態管理等

AWS＋Python、Ansible、Hubotばかりやっている印象でした。
同僚も「最近nodeJSばかり書いてる」と言ってた時期がありましたが自分はもっと・・・

AnsibleをSlackから実行するようになって未来感あるかと思ったけど
結果使う人が限定されかけていて負債化しかけているような。
作ったもの全般的にそうですね、普及施策が不足orやり方が悪いです。

スケールという意味で伸び悩み

プルリクはmackerel-agent-pluginsにいくつか出来たけど思ったより出来なかったです。

勉強会参加

2/13 第8回elasticsearch勉強会
3/12 道玄坂LT祭り第2回(統計、機械学習、データ抽出)
4/15 SmartNews Tech Night Vol.2 ~クラウド事業者に就職する以外の インフラエンジニアの生きる道~
5/26 mackerel meetup #4
6/3 norikra meetup #4
6/26 IPROS Tech Meetup!インフラ系SaaSカジュアルトーク
7/2 サポートエンジニアNight
7/26 JTF
8/19 rebuild meetup
8/20-22 YAPC
9/17 mackerel meetup #5
10/9 次世代クラウド勉強会 Docker、DevOpsを取り巻くマイクロサービスのコンセプト
10/10 渋谷Java
10/18 次世代Webカンファレンス (ustream)
12/14 Workflow Hacks #1
12/15 Embulk meetup #2

今年は運よく1度発表させてもらえました。皆様には非常に感謝しています。
コミュ障なんで外部勉強会行っても知り合い増えない(懇親会参加しない)ですが、
発表する立場になると話しかけてもらえるという利点はありました。
開発力が無いので共有できるとしたら運用とかになるのでしょうが、
現状は同僚にもうまく共有できてないので悩ましいです。

勉強会はモチベーションアップか現場の温度感を感じに行くことが多いのですが
今年はそういった意味では面白いのが多かったですね。
rebuildからYAPCの盛り上がりが個人的にも大きかったです。
podcastもっと流行りそうですね。rebuild supportersお勧めです。
自分はrebuild.fm, mosaic.fm, admins.bar 聞いてます。

全般的に参加の方向性は完全にインフラ側に寄りました。

社内勉強会

http://takezoe.hatenablog.com/entry/2015/12/26/163807

毎週開催してもらえて頭の下がる思いです。
岡本さんの回がYAPCで見れなかったのが残念。

社内では1度発表させたもらったのと、
エンジニアチームで主催している社外勉強会の一環でAnsibleのハンズオンをしました。
教えるための資料作りは知識が体系化されるのでいいですね。
しかし代償に精神の疲弊が半端ないす。

買った本

  • WEB+DB PRESS 85
  • Webエンジニアが知っておきたいインフラの基本
  • 実践ドメイン駆動設計
  • WEBエンジニアの教科書
  • WEB+DB PRESS 88
  • たのしいインフラの歩き方
  • Nginxリファレンス

相変わらずの積読・・・
情報はネットで仕入れまくってるとはいえ、
どこかで体系的には抑えておきたいものです。

その他

婚活ェ・・・
プライベートは全然だけど仕事が好転したので今後に期待したいです。
Griffon隣にあるんで一人飲みも覚えるべきか。

映画

あんま見てない、、、
後はベイマックスを友人宅で見たか。
Amazon Fire TV Stickを買ったのでもっと家に篭りそうです。

ゲーム

最近は携帯携帯でしかやってなくて、
携帯のゲームは時間を気にしすぎるのでそれも止めました。
FF7remakeを果たしてどうするか

2016年はもっと時間が効率的に使えるようになれるといいなぁ。

Mackerelで予測する的な話を試したり発展させたりする

mackerel

『年末年始のディスク容量アラートを回帰分析で回避しよう』という最高の記事が公開されたので試してみました。また、追加で自分が試してみたいことを試してみた話。

経緯

MackerelでAlertが出たらSlackの特定チャンネルにメンションするという運用にしているのですが、
DiskやMemoryのAlertはショボい理由*1で発生することも多く
サーバ数が増えるに従って頻度も増えるし手が回らなくなってきたのでどうにかしたい、
予測みたいなことで対処できないかと思っていました。

そこでid:stanakaさんの記事を試してみたり、
応用例について考えてみたという内容になります。

用意

自分のような人間にはだいたい準備が大変です。
仕事の環境(AWS/Amazon Linux)を意識してCentOS6で環境を作ったので、
Ubuntuならあるいはもっと楽に出来るかも知れませんん。
欲張って慣れないpyenv-virtualenv環境でやったのもハマリポイントでした。

とりあえず雑にVagrantfile作りました。
Vagrantだとグラフは見れないけど予測プログラム試すだけならコレで出来るはず。*2

実行

id:stanakaさんのプログラムをコピーして実行してみます

$ export MACKEREL_APIKEY="(your own mackerel key)"
$ python mackerel_estimate_filesystem_lifetime.py
INFO:__main__:fetching ip-xxx-xxx-xxx-xxx (1/xxx)
INFO:__main__:fetching ip-xxx-xxx-xxx-xxx (2/xxx)
...
...
ip-xxx-xxx-xxx-xxx:xvda1, size: 277.73 GB/422.62 GB, full in 12d21h21m35.429102s
ip-xxx-xxx-xxx-xxx:xvda1, size: 4.46 GB/8.32 GB, full in 17d22h39m20.554903s
...
...

こんな感じでDiskFullまでの時間が短いものから表示されます。
あくまで予測ですが候補が提示されるのは非常に助かります。
何日か連続でチェックすれば変動に幅があるものもケアできるでしょう。
毎日1回とか仕込もうかなとか画策中です。

metricsを収集する範囲は1週間で利用してます。

(APIの叩く頻度は数秒に1回程度にご配慮ください)

とのことなので、API実行後に time.sleep(2.0) とかして実行してます。

Memoryでも試してみました。
他のmetricもいい感じに確認できるようになるといいですね。

とりあえずこれで長期的な予測はしやすくなりました。
デプロイ前後の挙動変更とか元々使用量が高い場合とかいくつか難しい課題はあるのですが、
こういった手段の枠組みが提供されたことは喜ばしいことです。
更に
『もう少しすると、今までの傾向を分析して予測に基づいた監視が出来るようになりそうなので、ぜひご期待ください！』
(Mackerelが大切にしているエンジニアを”ワクワク”させることについて)
とあるので期待せざるをえません！

応用例

もう1つ出来たらいいなと思っていたことがあって、
それは閾値を超えたら緊急度を判定して通知してくれないか、というもの。
WARNING Alertをトリガーに分析した結果を通知する方向で考えてみました。

方法

流れとしては、

  • Alert APIでAlertを定期的に取得する
  • 未処理のDisk WARNING Alertを判定
  • 短時間のmetrics値を元に前出の分析を実行
  • 結果(DiskFullに到達するまでの時間)が一定の値よりも短い場合はSlackメンションする

分析には前出のプログラムを流用します。
プログラムは適当にcronで監視させます。

f:id:a3no:20151227213921p:plain

こんな感じでDisk使用量が増加すると、

f:id:a3no:20151227213931p:plain

Alert出現時に分析も行って結果を表示して、寿命が短い場合はメンションも実施します。

逆に寿命に猶予がある場合にはメンションしないようにします。
MAXまで1日以上かかるような場合は平日であればメンションせずとも対応可能なのではないでしょうか。

試したコードはサンプルとして貼っておきます。
https://gist.github.com/ki38sato/7f2b1a81423a55a0bbef
分析期間やAlert判定閾値は適当です。

チューニングはまだまだこれから*3、場合によって分析方法も、、ですが、
こういった仕組みを用意することで分析の得意な人に改善してもらえる土壌ができます。(他人任せ)

以上、Mackerelで予測したりする話でした。

補足

filesystemを分析するスクリプトをVagrant VMに対して試す場合は注意が必要です。 /dev/mapper/VolGroup-lv_root がMackerelサーバでは mapper_VolGroup-lv_root に変換されています。

*1:ちょっとしたエラーを放置してログが溢れるとかリークを放置するとか

*2:ただし初回起動に1時間くらいかかる気がする　Docker欲しい案件

*3:ddでファイル作って試しましたが傾きを調整できずなかなか、、、

Mackerel Meetup #5に参加した話

mackerel

9/17に マークシティで開催されたMackerel Meetup #5 参加してきました。
進化の早いMackerelですが一周年記念だそうです。おめでとうございます！
当日の雑なメモと簡単な感想です。

1. はてな　stanakaさん　「Mackerelの最初の1年と今後」

  • 1周年 一升餅作った
  • 毎週リリース継続　(開発スピードはやい)
  • 10,000+ agent
  • おすすめ5選
    • オートスケールグラフ
    • アラーと通知グラフ
    • 外形監視
    • 監視ルールコード化
      • mkr monitors diff/pull/push CircleCI
    • docker plugin
      • docker-hub mackerel-agent
  • 価格　移動平均で後払い決済=>セールスに連絡
  • ビジョン

開発が早いのは肌で感じてます。
はてなの皆さん、お会いする度に「何でも言ってください！」みたいにおっしゃられるのですが、 本当にリクエストしたものがすぐ入るので頭が下がります。
自社の導入状況は後の方で振り返ってみたいと思います。
後払い決済最高ですね。今月都合3回くらいポチった気がするので導入したい。
休み明けたらメールしようと思います！

2. GMOペパボ　山下さん　「僕が今日呼ばれた意味」

  • private cloud : OpenStack利用　<- サービス全て移行予定
  • 壊れたら作り直す
  • Nagiosを使っていた　動的追加厳しい
    • Mackerel採用　サービスメトリックで自由に追加
  • macklog plugin作った
  • OpenStackの監視　ポート使用数監視　利用率監視
    • scriptにfog使用、重い => YAO 軽量 開発Udzuraさん
  • hubotでMackerel＋OpenStackの情報をJOINして返す
  • hubotでMackerelのURLを返す　一発で開ける　便利
  • unreachableの切り分けは皆はどうしているのか？
  • mkr最高！

Mackerel APIとOpenStakの連携が始まってて羨ましいです。
サーバ管理という意味での連携はうまく出来てないので見習いたい。
Mackerel用のURLをhubotで返すの便利そう。
unreachableは今はcloudwatchと合わせ技で判断してます。
Mackerelをメインに他もチェックして自動で判断、とかできると良さそう？
mkr最高、間違いない。

3. サイバーエージェント　松浦さん　「アメーバオウンドとMackerel」

  • アメーバオウンドはAll AWS、Golang
  • Sensu + influxdb + grafana
    • influxdb 0.8 クエリがフルスキャンで参照が重い
    • Mackerel採用
  • ホスト名つけよう
  • サービス/ロールの設計方法について
  • sensu-plugin.io
    • pending queue監視とか

サラッと言われてたけどGolangも実践投入しているとはさすがサイバーさん。
松浦さんとは少し前に直接話す機会がありましたが、 influxdb 0.8使っててMackerelに乗り換える経緯が全く同じで共感したことが。 influxdbも0.9で改善されたとのことなので、grafanaも2.0出たし気にはなりますね。
ホスト名に関してはうちはむしろPrivateIP運用になっているので現状困ってないのですが、 display_name使いつつ、徐々にIP依存無くしたいとは思ったり。
sensu-plugin流用するのいいですね。
自分もMackerel-plugin書く時に出力参考にした気がしますが、 そのまま使うのも検証済みの場合は特に良さそう。

LTは飲んでたのでメモなし！
あと折角京都から来られていた人達に挨拶できなかったので課題です。

というわけで前回発表してから何が変わって何が変わってないのか少し振り返り。

追加されて導入済み

  • スクリプトによるチェック監視が出来るようになった
    • バッチやバックエンドサーバのプロセス監視とか便利
  • 通知先や通知条件が分けれるようになった
    • 更にチェック条件も調整できるようになった
    • stagingとproductionをSlackの別のchannelに出してproductionはメンション有りとか
  • URL外形監視
    • たまに504みたいなので警報出てつらかったけど回数や時間も見れるようになった
    • response timeグラフ便利
  • auto_retirement
    • BlueGreenDeploymentでグラフが無限増殖しない
  • on_start/on_stop
    • マシン毎停止する場合には警報止めたりする必要がなくなった
  • statusをRoleの一覧画面から変更できる
    • 某アーキテクト大喜び
  • display_name付けれるようになった
  • グラフ上で範囲選択できるようになった
    • kibanaっぽい感じで範囲ドラッグできる

未導入

  • カスタムダッシュボード
    • slackへのグラフ通知が便利すぎて皆そこから飛んでるっぽい
  • 監視設定API　mkr monitors
    • これからやる！絶対！

これ以外にもいくつか想定した挙動と異なる部分を質問して改良してもらったりしてます。
4ヶ月でえらい便利に。特にAPI化は大きいです。
同僚にmonitoringの設定100＋手で設定した話して苦笑されるしかなかったので、 パパッとコード管理化してドヤ顔するしかない。
またpluginも書きたい。

AWSなんかもそうですが毎週何かしらリリースされるの進化が目に見えてありがたいですね。
年末までに何がリリースされるか楽しみです。
はてなさん、サイバーエージェントさん、発表者の皆さん、ありがとうございました。