20200424 Infra Study Meetup #1「Infrastructure as Code」メモ

Qrunchからの移行（ログ）

基本情報

セッション

mizzy さん

  • 資料
  • コード化すべきもの
    • 課題を解決するものかどうかを判断しよう
    • ツールが重要ではない（ツールは手段）
    • ツールを使っていると気が付くことがある（面白そうだからやってみる、もあり）
  • アンチパターン
    • Ansible で書いた物をServerspec で書くとか
  • IaC 疲れ
    • 手段と目的をよく考える
    • 使ってみないとわからない面もある（取り組んでみる価値はある）
    • 結局ソフトウェア開発の後追いにもなっていると思う
  • 取っ掛かり
    • AWSとTerraform
  • 過剰な再利用性を求めてしまう

LT2 「Patterns in Infrastructure as Code」chaspy氏

  • 資料
  • SaaS のコンフィグもコード化
  • DRYは目指さない
    • 共通化し過ぎない（影響範囲が大きくなる）
    • 共通化は絞り込むこと
  • セルフサービスに必須ツール
    • コード生成ツールを自作している
  • 手変更をコードに戻す考え方

LT3「Infrastracture as Code変遷 ~ やるようになったこと・やらなくなったこと」

  • 資料
  • 人間には信頼性がない
  • Define everything as code -> Infrastructure as code 2nd Edition
  • クラウド、コンテナが抽象度をあげている(2nd Edition でレイヤ説明が無くなっている)
  • Provising をしなくなった
  • 監視のコード化

LT5「Infrastructure as Code におけるTest-Driven Development とその差分」Shuya

LT6「サービスメッシュを完全に理解する」inductor氏

  • 資料
  • マイクロサービスとサービスメッシュの基本説明
  • その上でIaC化の必要性を説明されている（共通項をまとめる）

LT8「フルリモートにおける Infrastructure as Code の効果」そのっつ氏

  • 資料
  • 全面IaCおよびCI/CD
  • 監視のコード化もやっている（DataDog）
  • 手作業での想定が書かれている

振り返り

  • オンライン開催のインフラテストが重要
  • IaC が当たり前になって来た
  • サービスメッシュも実はIaC
  • 監視のIaC 化
    • Terraform でできるが？（DataDog普通にやっている）
    • レビューとかできるのだが。Codeに書くのは意味がある
    • 閾値とかもやっている（履歴を残す意味で）
    • べきろんでは、やるべき
      • スケールするような大変なものにやっていくとか、取捨選択必要
    • 監視項目をIaC化するのか、サーバの設定と同じようなイメージ
      • 現実として見えるように。やれるのであればやった方がいい
    • ダッシュボードも作った人しか使えないようになる

以上