技術書読書会 #6 Infrastructure as Code
読書会とは
「すべては、待っている間に読書した人のもの。」と世紀の発明家が言っていました。
技術書を最後まで読み切る事は意外と大変です。一人なら無理だけどみんなの力があればできるかも・・・。
そんなことを誰が思たのか、ともあれそんな気持ちに賛同したメンバーが１冊の技術書を読み込むという結構ハードルの高いことにチャレンジをしていきます。
技術書読書会の進め方
eXtreme Readingの方式で進めていきます。
実施方法
以下の流れで読書をしていきます。
1. 0分～5分間で、今回読み進める章/節を発表する
2. 15分～30分間で、読書
3. 5分～10分間で、ディスカッション
4. 1～3を時間分繰り返す
5. まとめ
今回の読書会は、所要時間30分で以下の配分で行いました。
1. 5分間で、今回読み進める章/節を発表する
2. 15分間、読書
3. 5分間、ディスカッション
4. 10分間、まとめ
利点
eXtreme Readingの利点です。
- 事前の準備がいらない。
- ディカッションをすることにより理解を深める事ができる。参加者全体の理解度の底上げが期待できる。
- 時間を区切って進行するので、読書の進捗が一定となり本の読み終わり時期を予測することができる
- みんなでやればなんとかなる
今回読む書籍
Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス
参加人数
5人
所要時間
30分
進捗
3.2 - 3.3.4
ディスカッション
3.2 構成定義ファイル
桑 構成ツールの利便性が高いのはわかるが、これを利用して簡単にセットできるけどインフラの仕組みをちゃんと理解できるのか？
岡 今回は動きは別のお話かと、設定の部分ですね
桑 そうなんだけど
岡 仕組みを知っている人が定義ファイルを作成するのかなと、じゃないと作成できない
峯 後は定義ファイルを作成した人がどうするか、教育するかしないかだよね。
3.2.1 構成定義の再利用可能性
峯 これ昨日もそうだけど、押すよね。QA（Quality assurance）、ステージング、本番環境で別の定義ファイルを作らない
飯 こうやっとけば安定だよね。
3.3 インフラストラクチャ定義ツールの操作
岡 関係ないんですけど、ここでプロビジョニングの定義が来たんだなと
飯 僕もそう思いました。プロビジョニングの定義とは？って前々から質問したかったんですよ
峯 ツールによって、異なるものを意味すると書いてある
3.3.1 手続き型スクリプトによるインフラストラクチャのプロビジョニング
峯 servers.ymlとenvironment.ymlに変えたんだね。定義ファイルってどういう切り口で分けるのがいいのかな？
岡 フロントとＤＢで分けました。共通の設定とかは、別で切り出しても良かったかも
3.3.2 インフラストラクチャの宣言的な定義
岡 最初の冒頭の部分がなるほどと思いました。
気づき
- コードが出てきたが、ここら辺どのように進めるか
- 最後グダグダになってしまった。
- やはり読むスピードが速くなっている気がする
まとめ
集音マイクうまくいった。原因は、集音マイクがMacに対応していなかっただけだった。とりあえずリモート問題は解決！！