はてなを退職しました

昨日付ではてなを退職しました。

この記事を書いてから、2年少しですが、こんな日が来るとは2年前は微塵にも思っていませんでした。 というのが正直な気持ちです。 sharatani.hatenablog.com

2015年6月、まだ上場前のはてなに入社し、職種としてははてなで初めてのセールスエンジニアとして採用され、途中で職種・役割が変わりましたが、2年2ヶ月のはてな生活でした。

改めましてお世話になった皆さん、ありがとうございました。

私が会社としての「はてな」を知ったのはITmediaのこの記事でした。 www.itmedia.co.jp

当時は小さなシステム開発会社で3次請けの立場でSEとして働いており、なんだか凄そうな人が小さな会社に行って大丈夫なんだろうか、そういう時代になるんだろうかと思っていた次第です。

それから10年が経ち、はてなに入社し、2年という短い期間ではありましたが、色々な仕事ができて楽しい2年でした。

次は感情データを分析してマーケティングの支援を行う、Emotion Techという会社で働きます。 肩書きとしてはチーフセールスエンジニアなのですが、実際にはセールス・コンサルティング・導入支援といったビジネス寄りの仕事をします。

はてなと比べてもまだまだ小さな会社ではありますが、その分出来ることも・やることも・チャンスも多い環境です。 Emotion Techを選んだ理由はいくつかあるのですが、その中の一つに「社長の人柄の良さ」というものがありました。 ちょっと心配になるぐらい人が良いのですが、小さい組織だからこそ、社長の人柄って会社を選ぶ中でも大切な要素だなと個人的には考えています。

※前職はてなでも栗栖社長の人柄が物凄く良かったこともあり、はてなへの入社を決めました

もしEmotion Techの仕組み・サービス・採用にご興味がありましたら、ぜひお声がけ下さい。

2016年

色々とあったし忙しかったけど、良い一年だった。（と思う）

神奈川県某所にいってきた

Dockerメモ5

データ専用コンテナ

• 名前の通りデータ専用のコンテナでアプリ関係は動かさない

systemd対応のDockerコンテナ

• CentOS7.xではdocker run実行時に--privilegedオプションを付与する必要がある
• --privilegedオプションを付与すると、コンテナは管理者権限モードで実行される

Dockerfile

• イメージファイル
• FROM行で使用するDockerイメージを指定する
• MAINTAINER行でメンテナー名などを記述する
• ENV行で環境変数を指定する
• RUN行で実行するコマンドを記述する
• ADDまたはCOPY行でホストOS側のファイルをコンテナ内にコピーする -- ADDは圧縮tarファイルを解凍・展開して元のファイルはコピーされない、COPYは単純に圧縮tarファイルをコピーして解凍・展開は行わない
• ENTRYPOINT行でコンテナの実行時にコマンドを実行する（実行後はすぐに終了する） -- 終了させたくない場合などはtail -f /dev/nullなどの終了しないコマンドを記述しておく -- CMD行でもコンテナの実行時にコマンドを実行することが可能、ただしENTRYPOINTとは違いが有る

• EXPOSE行で外部に開放するポート番号を指定する

• docker buildコマンドを実行する時はDockerfileのあるディレクトリを指定する必要がある -- docker buildのhelpを見るとUsage： docker build [OPTIONS] PATH | URL | -と記述がある -- 直下にDockerfileの名称で置いている場合はdocker build -t test:testdocker --no-cache .こんな感じで末尾のドットが必要 -- こうしてDockerイメージが作られる、イメージの確認はdocker imagesコマンド

• ホスト側から直接コンテナ内のコマンドを実行するには、docker execコマンドを使用する

Dockerメモ4

ホストOSからコンテナへディレクトリを共有する

• DockerはホストOSのディレクトリをコンテナ側へ見せることが可能になっている
• -vオプションを利用して-v <ホスト側ディレクトリ>:<コンテナ側ディレクトリ>とする
• docker run -v /root/docker-testdir:/root/docdoc -it --name test0x1 centos:centos6.6 /bin/bashこんな感じ、ホスト側の/root/docker-testdirをコンテナ側の/root/docdocディレクトリに割り当てる
• コンテナ側で/root/docdocの中にファイルを作成すると、ホスト側では/root/docker-testdirの中にコンテナ側で作成したファイルが存在する
• つまりホスト/コンテナ側から読み書きできる状態になっている

書き込み不可でコンテナへディレクトリを共有する

• -v <ホスト側ディレクトリ>:<コンテナ側ディレクトリ>:roとする

共有可能なディレクトリの確認

• docker inspect <container id> | <container image>で表示される
• こんな感じで出てくる、docker inspectコマンドで色々と情報が取れる

    "Mounts": [
      {
        "Source": "/root/docker-testdir",   #コンテナ側ディレクトリ
        "Destination": "/root/docdoc",      #ホスト側ディレクトリ
        "Mode": "",                         #読み込み専用ならroと表示
        "RW": true,                         #読み書き出来るのでtrueになっている
        "Propagation": "rprivate"
      }

コンテナ間でのディレクトリの共有

• docker run -v /root/dockertest -itd --name test0x4 centos:centos6.6 /bin/bashこれでコンテナtest0x4の/root/dockertestディレクトリができる
• docker run --volumes-from test0x4 -it --name test0x5 centos:centos6.6 /bin/bashこれでコンテナtest0x5のroot/dockertestはtest0x4のディレクトリと共有されている -- --volumes-from <container id>オプションが必要 -- --volumes-from:ro <container id>にすると書き込み不可で共有されるが、提供側のコンテナでは読み書きが出来る

Dockerメモ3

Dockerコンポーネント

• Docker エンジン：Docker本体のこと
• Docker コンテナ：Dockerエンジンが実行するコンテナのこと
• Docker クライアント：Dockerデーモンが提供する各種コマンドなどのIFのこと
• DockerコンテナはホストOS上で複数同時に起動することができる、ホストOSから見ると分離された名前空間として見える

コンテナの起動

• 例えば"/bin/bash"でコンテナを起動した後のプロンプトで"root@11450a5780f2"等と表示されるが、@の後ろはコンテナID
• hostnameはコンテナIDが自動的に設定されるが、-hオプションで設定することも可能
• コンテナをバックグラウンドで稼働させる場合は-dオプションを強する
• 起動のコマンドはdocker start <container id>でOK、起動後はdocker psで確認ができるが、バックグラウンドで動いている

コンテナのイメージ化

• 作成したコンテナをイメージ化することができる
• docker commit <container id> <repository name>:<tag name> -- docker commit c7c2983acd46 local:test-run こんな感じ
• アプリケーションごとにコンテナを作成してイメージ化しておけば、必要な時に必要なものをすぐ実行可能な状態でコンテナの再利用をすることができる
• docker images --no-truncで本来のイメージID64文字で表示が可能、通常は12文字。イメージIDのみ出力したい場合はdocker images -qでOK

シェル変数にコンテナIDを入れると便利

• abc=$(docker run -d --name centos-test -i -t centos:centos6.6 /bin/bash)を実行すると、コンテナIDがabcに代入される
• コンテナIDは長いので便利そう？

コンテナの停止

• docker stop <container id>でOK

コンテナのアタッチ

• 一度停止したコンテナはdocker start -i -a <コンテナID>で再接続ができる -- iは標準入力を受け付けるオプション、-aはアタッチ
• バックグラウンドで動作しているコンテナはそのままdocker attach <container id>でOK

コンテナとコンテナイメージの削除

• docker rm <container id>でコンテナは削除可能 -- docker ps -a | awk '{print $1}' | xargs docker rmでまとめて一括で消せる -- 起動中のコンテナは削除できないが、-fオプションを付与することで強制的に削除可能
• docker rmi <Image id>でコンテナは削除可能 -- docker images | awk '{print $3}' | xargs docker rmiでまとめて一括で消せる

コンテナの自動廃棄

• docker runコマンドに--rmオプションを付与して起動すると、コンテナ停止時に自動的に廃棄される
• -dオプションとはセットで利用できないので注意

Dockerメモ2

導入について

• CPU：ハイパーバイザー型の仮想化ソフトウェアはCPUコアあたりのゲストOS数の目安があるが、Dockerの場合はそれがない
• メモリ：ホストOS分＋全コンテナで使用するメモリ容量を考慮して計算する
• ディスク：Docker領域はユーザーの数やコンテナ数によって使用量が変わるので、OS領域とは別でディスクを確保した方が良い
• devicemapper関連のパラメーターはDocker運用後には簡単に変更がきかないため、事前に注意が必要

コマンド

• docker info：Dockerの設定値他の状態を取得できる
• docker version：ClientとServerのバージョン情報を取得できる

Dockerメモ

改めてDockerの本を読んでいるのでメモ

Dockerコンテナのアーキテクチャ

コンテナ毎に空間を分離してくれる

• ただしLinuxの基盤上でWindowsのコンテナを動かすことは出来ない
• コンテナにはLinuxコンテナ（LXC）というものがあり、古いバージョンのDockerはLXCの機能を利用していた
• LXDというものが最近出てきた
• 現在のDockerはlibcontainerというドライバを利用しており、LXCには依存していない（Docker0.9以上）
• Dockerはプロセスレベル、ファイルシステムレベルでの分離を行う

ハイパーバイザー型とコンテナ型の違い

• ハイパーバイザー型は自身のゲストOS上のMBR領域に対してブートローダーをインストールする等の必要がある（物理OSを起動する時と同じような感じ）、コンテナ型はそういったものがないため、起動・停止が非常に高速。
• ハイパーバイザー型はハードウェアをエミュレーションしているが、コンテナ型は名前空間とcgroupを利用してコンテナがプロセスとして稼働するだけなので、リソースが少なくて済む
• コンテナ型はアプリケーションが分離されるが、ホストOS環境から直接実行されるため、ホストOSと同等の性能を発揮出来る

名前空間

• プロセスでの分離が出来る、分離した空間同士を見えないように制御を行う
• 名前空間にはいくつか種類があり、名前空間ごとにハードウェアリソースを割り当てているのがcgroup
• Dockerコンテナを立ち上げると、ipc/mnt/net/pid/user/utsの名前空間が作られる

Docker導入準備

コンテナ専用OS

• コンテナを稼働させること以外のパッケージやアプリケーションは極力排除されている、サーバーOSと比較してセキュリティ・性能面などで優位性がある
• CoreOSとかPorject Atomicとか

Dockerにおけるドライバ

• Dockerのバックエンドの仕組みとして、コンテナの生業を行う実行ドライバ、ファイルシステム関連の制御を行うストレージドライバの2種類がある
• 実行ドライバは名前空間やcgroupを利用するのに必要
• Dockerシステムの裏側で動作するバックエンドの実行ドライバーとしてlibcontainerがある
• Docker0.9から組み込まれているので、DockerとLinuxカーネルの間にLXCなどのドライバを挟まなくても良くなった

もうすぐ一年が経ちます

転職してからもうすぐ一年が経ちます。気がついたら早いもので、この一年で公私ともに色々とありました。

転職して一年が経つということは、セールスエンジニアのキャリアも一年が経つということになります。 半年ぐらい前にはてなアドベントカレンダーにて、仕事のこととか書いてました。

sharatani.hatenablog.com

セールスエンジニアという肩書きで一年間ほど仕事をしてきたのですが、面白い仕事だな〜って一言に尽きます。 一生懸命やっているので、しんどいこともあれば、楽しいこともあるのが仕事なのですが、これまでの社会人としての人生を振り返っても面白い仕事です。

一年前を振り返ると、だいぶ成長した感はあるのですが、まだまだいけるしまだまだやれるし、まだまだやりたいことはたくさんあるので頑張ります。 弊社のCTOが「自分に限界を定めると、それが仕事の限界になる」というようなことを言っていて、厳しくなるとその言葉をよく思い出したりしています。

やりたいこと、知りたいこと、気になる技術はまだまだたくさんあるので頑張る！

MackerelでWindowsイベントログ監視とプロセス監視をする

ちょっと触ってちょっと検証したため、メモしておきます。

MackerelはWindowsでも利用可能ですが、公式のcheckプラグインがWindowsに対応していないため、個別に用意する必要があります。

※プロセス監視のcheck-procsは公式に用意してあるのですが、自分でビルドする必要があります。

環境

Mac OSXを利用しています、gitやhomebrewなどは予め環境が出来ているという状況です。

Go環境の整備

Goの環境整備にあたっては、弊社のSongmuさんの記事を利用させてもらいました。

www.songmu.jp

check-procsのビルド

予め"$HOME/repos"というディレクトリを作っておきました。

git clone https://github.com/mackerelio/go-check-plugins.git

git cloneしてローカル環境にデータを持ってきます。

GOOS=windows GOARCH=386 go build -o check_procs_windows.exe

でビルドすると、こんなエラーが出ました。

check_procs.go:9:2: cannot find package "github.com/jessevdk/go-flags" in any of:
    /usr/local/Cellar/go/1.6/libexec/src/github.com/jessevdk/go-flags (from $GOROOT)
    /Users/sharatani/dev/src/github.com/jessevdk/go-flags (from $GOPATH)
check_procs.go:10:2: cannot find package "github.com/mackerelio/checkers" in any of:
    /usr/local/Cellar/go/1.6/libexec/src/github.com/mackerelio/checkers (from $GOROOT)
    /Users/sharatani/dev/src/github.com/mackerelio/checkers (from $GOPATH)

パッケージが見つからないと出ているので、以下のコマンドを実行します。

go get github.com/jessevdk/go-flags
go get github.com/mackerelio/checkers

その後で改めて以下のコマンドでビルドをします。

GOOS=windows GOARCH=386 go build -o check_procs_windows.exe

すると、check_procs_windows.exeが出来ています。

検証

AWSのWindowsServer2012R2で試してみました。

• タスクマネージャー起動させる
• コマンドプロンプトで"check_procs_windows.exe --pattern Task"実行
  • "Procs OK: Found 1 matching processes; cmd /Task/"が表示されたのでOK
• タスクマネージャーを終了させて、再度コマンド実行して確認
  • "Procs CRITICAL: Found 0 matching processes; cmd /Task/"が表示されたのでOK

mackerel-agent.confへ記述するには、こんな感じです。

[plugin.checks.taskmanager-procs]
command = "C:\\Users\\Administrator\\Downloads\\check_procs_windows.exe --pattern Task"

confを変更して有効化するには、サービスからmackerel-agentを再起動させる必要があります。

Windowsのイベントログ監視

イベントログを監視するにはいくつか方法があるのですが、試した結果、パワーシェルを使うよりもexeを使った方が楽でした。

一旦こちらからexeプログラムをダウンロードします。

check_winevent - NRPE check plugin for Windows eventlogs | itefix.net

単体でコマンドプロンプトから実行したら、こんな感じでした。

C:\> check_winevent.exe --log application --type error

EVENT OK - 2 events|events=2;;;

これはアプリケーションログに対して、タイプがエラーになっているものが2件見つかったため、2と表示されています。 2と言ってもログの確認範囲（いつからいつまでなのか）が分からなかったので、いくつか試したところ・・・・

試しにコマンドをちょっと変えて実行してみました。

C:\> check_winevent\\check_winevent.exe --log application --type error --critical 0

EVENT CRITICAL - 2 events|events=2;;0;

0以上の場合はCRITICALにするオプションを付与したところ、CRITICALが返ってきています。

--verboseオプションを付与して、出力を詳細に出してみました。

C:> check_winevent.exe --log application --type error --verbose

Event log(s): application
Event code(s): all
Event type(s): error
Event sources: all
Time window: 3600 seconds, timestamp: 20160517043648.000000+000
Eventlog application - 2 selected events
Total number of events selected: 2

EVENT OK - 2 events|events=2;;;

これを見ると、Time windowという項目が有り、3600秒=60分が検出の対象になっているようです。 --windowオプションで秒数を変更出来るようなので、60秒にして実行した見たところ、今度はCRITICALではなくOK表示でした。

C:> check_winevent.exe --log application --type error --critical 0 --window 60

EVENT OK - 0 events|events=0;;0;

他にもいくつかオプションはあるようなのですが、ちゃんと動いていそうなので、細かい所はまた後で。

mackerel-agent.confにはこのように記述します、記述後はサービスからmackerel-agentを再起動させて反映します。

[plugin.checks.windowsApp-exe]

command = "C:\\Users\\Administrator\\Downloads\\check_winevent\\check_winevent.exe --log application --type error --critical 0"