技術書読書会 #10 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 ―クラウドにおけるサーバ管理の原則とプラクティス
参加人数
6人
所要時間
30分
進捗
4.4.1- 4.5
ディスカッション
4.4.1 Rubyアプリケーション管理がコンテナによってどのように変わるか？
浜 環境ごとパッケージングできるので依存関係を解消できるのでいいよね。ってことですよね。
4.4.2.1 仮想マシンとコンテナの違い
岡 ディストリビューション違いならいいよ。
浜 カーネルとディストリビューションの間あたりにレイヤーがあるというか
4.4.3 仮想マシンよりもコンテナ
岡 これ結構好きなんですけど
浜 コンテナは起動がはやいですよね
岡 一つ一つのプロセスでコンテナを分けましょう
浜 プロセス単位というのはちょっと微妙なのかな
岡 ようは、できるだけ小さくするというイメージなのかな
浜 適切な粒度があるのかなと
浜 スケーリングしたい単位で分ける。というのはありかと
浜 コンテナは管理がめんどくさい。
4.4.4 コンテナの実行
岡 これ使ったことない。コンテナオーケストレーションシステム
浜 比較的最近にkubanates使いました。
浜 ロギングとかを独自で実装していると、結構複数のサーバーが絡んでくるとごちゃごちゃする。という傾向がある。Dockerは、ロギングサービスがあるので比較的楽。GKEはロギングがすごく楽。サービス化されているので、AWSでkubanatesを利用するとそこまで楽じゃなかったような記憶があります。
4.4.5.1 コンテナの分離とセキュリティー
浜 コンテナ使っているから安心というわけではない
飯 のらコンテナを使うとそれに脆弱性が入っている可能性がある
4.5 まとめ
飯 結果、みんなで頑張りながらVCSを利用してバージョン管理しましょう。ということですね。
岡 バージョン管理、いっぱい出るからね。
気づき
まとめ
本日、4章が終わりました。1部は残すところ5章のみ。まだまだ継続できそうです。