SREチーム西村(吉)です。9月21日に恵比寿のレッドハット株式会社さんで開催された Ansible Night in Tokyo 2018.09 でLT枠参加してきたのでスライドの補足をしたいと思います。
Ansible自体やその他のインフラ系ツールの説明等は別の記事に譲るとして、この記事ではLTしてきて話しきれなかったところ、反省、学びなど、思いつくまま記録しておこうと思います。
補足したいところ
ヒエラルキーについて
総AMI化、定期的な総入れ替え、安定稼動を念頭に、OSの統一、設定の標準化(インスタンスによって差異がある)によって、起動される各インスタンスが管理しやすいようにベースマシンからツリー状に組み立てられるようにしています。
ちょうどDockerでマルチステージビルドを多段にしている感じです。
ベースマシンについて
ベースマシンについてはどれでもいいというか、管理しやすいマシンであればOSはなんでもよかったのですが、別プロジェクトではCentOSを継続して使用してきており、差異の少ない別マシンとしてAmazonLinux2を選択しました。公式であり、長期サポートが受けられ、セキュリティアップデートやメンテナンスアップデートが継続されることが保障されているので、今回のようにイミュータブルな設計には向いているのかなと考えています。チューニングの勘所も似てますしね。
ちなみにEKSのワーカーノードのインスタンスもAmazonLinux2に基づいているようなので先々のことを考えてもいい選択なのかなと。
課題があるとすれば特になんのお知らせもなくextraのバージョンがあがったりしてあれ?ってなるところくらいでしょうか。
php マシンについて
弊社開発ではphpを使用しているので、ほとんど全てのマシンにphpが必要です。AmazonLinux2を使用するとamazon-linux-extrasで7系が使用できます(AWSが用意するリビジョン以外は別途操作が必要ですが)。残念ながら2018年10月現在、amazon-linux-extra の Ansible module はないようなので、command module を使っているのがイマイチなところです。。。
またextraではphpのバージョンをAWSに握られる(提供されないマイナーバージョンは自力でインストールする必要がある)のもどうかというところ。現時点ではさほど困っていませんが、特定のマイナーバージョンで固定したい時に提供されていないと困るかもしれない(提供されているバージョンで開発、テストしているのでレアケースとしていい気もする)。
jenkinsマシンについて
EFSを使用してオートヒーリングなjenkinsを実現していますが、東京リージョンで使えるようになったとはいえ、EFSでgitリポジトリを扱うととにかく遅いです。正直なところ次の機会ではこの組み合わせは採用しないつもりです。。。
Packer + Ansible について
ヒエラルキー状にAMIを作成すると決めてしまえば、プロビジョニング用のAnsibleはそれぞれごとのplaybookを持たせて切り替えてあげることで実行もすっきりしますし、どのAMIに何を設定したのかの見通しもよくなるのでおすすめです。
Terraformについて
実際資料からはほとんど落としていますが、弊社(今回のシステム)ではTerraformのほうがシステム構築の上で重要です。AnsibleはAMIを作成することと、Terraformのリモートステート用のs3 bucketを作成するだけになっており、残りはTerraformとAWSサービス自体がピタゴラスイッチすることで組みあがっています。Terraformの勉強会があったらこの辺りをちゃんと説明したい。。。
反省点
緊張して練習の成果が出せなかった
人前で話すのが久しぶりだったのでちょっと練習していたのですが、全然足りなかったようです。。。
早口になりすぎてた?
緊張と時間を気にしすぎて早口になっていた気がします。普段もだいぶ早口なほうなので今後の課題にしなくてはいけません。
口の中が乾燥してしゃべりにくかった
みなさんあんなに人前でしゃべっていてよく口渇かないですね。。。経験の差なんでしょうか。。。
学び
無線が使えないとGoogleスライドが使えない
今回の会場ではお借りできましたが、場合によって無線が使えない場合に、Googleスライドだと不安ですね。事前に共有できたりして便利なのですが。対策としてGoogle オフラインドキュメント機能拡張等を入れるようにしたいと思っています。
制限時間内に収まるように話すことをちゃんとしぼる
資料を作っている最中から5分は無理だなと思っていたので、最終的に図を書いてここだけ説明する、というのを決めていたのですが、うまく話せませんでした。
発表者ノートは埋めておくといざという時に安心
どこをどうしゃべるつもりなのかを発表者ノートに書いておくの大事ですね。今回の資料では元ネタのリンク等は書いてあるのですがしゃべりについては書いていませんでした。
今回はお題がCIということでプロジェクトのCI部分を抜き出したわけですが、いっそもっとplaybookやroleの話にしてもよかった
単純にそう思いました。1参加者として、Ansibleの話を聞きに行ったはずなのにAnsibleの設計や処理の話をしないのは物足りないというかなんか違うかなと思ったというか。whenやwithなどの使い方の工夫等、もっとナレッジについて話せるような、話すきっかけになるようなミートアップになったらいいですよね。
会場提言
- 無線LANは開放できないとつらい
- 弊社ビルの無線LANの接続制限も確認しておかないといけないですね
- ハッシュタグの案内は十分に(せっかくなのでたくさんつぶやいてもらいましょう
- フォトジェニックな部分にハッシュタグを印刷したシール等を貼っておくとよさそう
- 会場の入り口とか、ノベルティ配布スペースとか
- 設備説明(トイレ、喫煙所)の案内は十分に
- 弊社ビルの喫煙所は建物の外ですし休日はビルの入退館もセキュリティ的に面倒なので対策が必要かも
- そもそも会場に使える大きい会議室もセキュリティゲートの内側だった。。。
- 発表の間に休憩を差して、質疑応答と次の準備に充てるといいかも
- 長丁場座りっぱなしも辛いですし
- タイムテーブルにバッファがもてますし
まとめ
思いついたことをつらつらと挙げましたが、基本的に練習、実践、改善、しかないかなと。今後もっと回数こなして精進したいと思います。人見知りなので勉強会等ではたいてい隅っこでキョドっていますが人畜無害(なつもり)なので、どこかで見かけることがあったらぜひお声がけください。