弊社新人謹製のGeekDojoで、興味を引くイベントが企画されていたので参加した。

ほっかい道場の第一回勉強会。
名前だけだとどんな内容かさっぱりだが、説明にある「DevOps」が琴線に触れた。

会場も銀座のコワーキングスペースでイケメンな感じだった。道に迷ったけど。

ChefやAnsibleとServerspecについて

最初に自己紹介した後、主催のhokkai7goさんのスライドを数枚見て、テーマであるDevOpsについてのイントロを行った。
僕は社内では、先輩が導入したAnsibleを使っていたことがありChefはHello World的knife solo程度だったが、hokkai7goさんはChefを使っていて今はAnsibleも使うとの事だった。
「Chefの本書いててなんでAnsibleなんだろう」と思ったが、Chef(特にChef Server)は大規模システムには向くが、rubyのDSLということもあり、保守性に難があったりするらしく、スタートアップで使うならAnsibleの方が良いらしい。

構成管理ツールがある中でのserverspecの意義について質問したところ、

• 既にきっちりと構成管理されているなら不要かもしれない
• 今構成管理されていないシステムが過渡期としてserverspecを使うのは有意義かも

という結論に至った。

僕がいるチームは後者なので、serverspecから初めてansibleをより充実させるのが良いのかなと思う。

社内にInfrastructure as a Codeを広めることについて

構成管理されていない既存システムに構成管理を導入することは難しいと考えていた(いる)。 そこでhokkai7goさんが教えてくれたのが、

• 最初に開発環境のchef/ansible化を行う(vagrantと一緒に)
• 次にきっちりとした手順書を揃える
• 最後に手順書をchef/ansibleのコードで置き換えていく

という方法。
これはhokkai7goさんの実体験に基づくものらしく、

• 複数の手順書で共通する汎用的なところからchef/ansible化
• 構成管理導入後も、コード実行のエントリポイントになるコマンドくらいはドキュメントに書くことを維持する
• chefを実行したタイミングなどは知っておきたいので、実行時にチャットを残しておく
• 大きなオペレーション毎にパーマリンクを作っておく

というノウハウと併せて、非常に参考になった。

SIとwebについて

僕と、一緒に参加した後輩以外は全員SIに居たことがあるらしく、雑談でSI業界の話も出てきた。
なれる!SEを読んで「SI大変っぽい」という印象は持っていたが、「エクセルにスクショ貼るとか」「あるあるー」という会話を聞いて、マジでそういう世界があるのかと思った。

ちなみになれる!SEは今6巻の途中まで読んだけど、3, 4巻が心にぐさっと刺さってやばかった。
(主に「客や仲間のこと置き去りにして技術だけ語ってんじゃねーぞ！」的な文脈)

SI世界のアレな話を多く聞いたが、そこから他にやりたいことを見つけてweb業界に来た人は、SI時代の経験から「仕事を楽にしよう！」「より良い人生にしよう」というモチベーションが非常に高いと思う。
SIからwebに来た人は強い。

感想

今回の勉強会は、技術的なディスカッションだけではなく、会社でどう技術を広めるかや技術コミュニティの運営方法など、社会人として必要な事を沢山学ぶことができた。
とりあえず、今会社でやっている運用を良くするチャレンジを続けて、この勉強会の第二回で話せるようになれれば良いなと思う。

id:hokkai7go++

おまけ: Elastic Beanstalk with Dockerの認証部分

この話をした時も今回も、一番最初のDockerHub-EB認証のあたりを載せることを忘れていたので。

1: docker login

予めDockerHubでユーザ登録し、パソコンにdockerをインストールした後で

docker login

コマンドを打ちID/パスワードを入力すると、ホームディレクトリに

~/.dockercfg

が生成される。

2: そのファイルを、任意のS3のバケットにアップロードする。

3: Elastic Beanstalkが読む設定ファイルをプロジェクトのルートに置く

このサンプルアプリをにあるようなDockerrun.aws.jsonを用意する。

Elastic Beanstalk with Dockerに必要なファイル

4: DockerHubのAUTOMATED BUILD REPOSITORYを作成する

普通に"Add Repository"から"Repository"を作成するのではなく、その下の"Automated Build"を選択する。
後はGitHub/Bitbucket連携を設定しリポジトリを選択し、対象のDockerfileが存在するディレクトリを入力すればOK。
僕は

• yum installやperl/rubyのインストールなどを行うbaseイメージ
• baseイメージをもとに最新のソースコードを加えて依存モジュールをインストールし、nginxやsupervisordの設定ファイルを設置するappイメージ
• 開発時にS3やSQSやRDSを模倣するresourceイメージ

の3つを使えないか試している。
baseとappを使い分けることで、appイメージのAutomated Buildの時間を短縮することができる。 resourceイメージは本当に実用的か実験中。
サンプルは https://registry.hub.docker.com/repos/saisa6153/ に置いてある。

5: EBに対してIAMロールを設定し、EBがVPC内のS3にあるdockerhub認証ファイルを読めるようにする

EBのサンプルを1度動かすとaws-elasticbeanstalk-ec2-roleというIAM Roleが作成されるので、それにS3のRead Permissionを設定する。 僕はそこんとこ面倒だったので、Policy TemplateからPower User Accessを与える方法でデモしたりしていたので良くない。

あとはAWS Management ConsoleからEBをポチポチして適当に。