目的
今さらながら、Chef界隈をざっくり理解する必要に迫られたので、一旦Webで拾い読んだノート。
Chef
このポストを参考に下記をざっと読む。
Chefの概要
- 特色
- インフラをどのように構築し、維持するべきかという定義はRubyの文法で記述される
- あたかもRubyでプログラミングをするように、インフラの構成管理をコードによって行える
- べき等性=ある操作を一度行っても何度行っても結果が同じ
- chefは基本保証するが、cookbook、recipeを自分で書くときはべき等性を保つよう注意
- インフラの定義方法
- cookbook: rubyで記述されたインフラの定義
- recipe: cookbook構成要素のひとつ。ruby文法+resource
- resource: chef専用の命令
- 構成
- どちらでも運用可能、cookbookの書き方も同じ
- server/client: 大規模環境向き
- + serverに構成が一元蓄積され見通しが良い
- - server維持管理、client構築が手間
- solo: 小規模向き
- + 手軽に導入
- - 全体の確認、ノード連携は自己負担
- server/client: 大規模環境向き
- どちらでも運用可能、cookbookの書き方も同じ
- 構成要素
- chef server: Nodeの管理、Cookbook、Recipe情報などの構成管理。Web UI
- workstation: Knifeコマンドで、CookbookやRecipeを操作したり、Chef Serverに指示
- node: Chef Serverが管理するマシン。Chef Serverで管理しているCookbookやRecipe情報をNode上のChef Clientが取得、そのタスクを実行
なぜInfrastructure as Codeが必要か
- as-is
- 設定ミスにより膨大な作業が発生するリスクがある
- 全体の待ち時間が大きな時間のロスになる
- to-be
- コード化した状態を他のシステム構築・運用にも流用できる
- 繰り返し作業を集約できる
- システムの状態を容易に確認できる
- Chefについては「”サーバの構成を自動化するツール”ではなく、”サーバの状態をコードにする”が本質」
- 全てをStatelessにすることがImmutable Infrastructureの目的ではなく、Statelessであるべき箇所をImmutableに扱おうということが目的
- 例えばログなどの状態についてはfluentdで外部に配置するなどの仕組みを用いるべき
- 背景
- auto-scaling - 負荷に応じて自動的にサーバ台数を増減させる技術。自動立ち上げ/shutdown=使い捨て
- blue-green deployment - サーバ群をまるごと複製し、ロードバランサで切り替えることでデプロイとする
- Immutable Infrastructureとは:
- サーバを使い捨てにする
- 一度セットアップしたら二度と状態を変更しない
- 単なる運用テクニックではなく「サーバをソフトウェア部品として抽象化する」発想シフト
- to-be
- 全てのサーバが同じ状態であることが保証される
- 常にゼロからセットアップできることが保証される
- 自動化が必須になる
- プロビジョニングがシンプルにできる
- テストとの親和性
- サーバのポータビリティが高められる
- issue
- コスト - サーバ台数分
- ログ - サーバを使い捨てる分、ログ集約しておく必要
- DB/ストレージ - 永続的DB/ストレージは使い捨てにくい。ひとつの逃げ道がDBaaS
- Immutable 前提なプロビジョニングツール - Chef や Puppet の冪等性がオーバースペック
EOF