Posted at

ゼロからChefをざっくり理解するまでのノート

More than 1 year has passed since last update.


目的

今さらながら、Chef界隈をざっくり理解する必要に迫られたので、一旦Webで拾い読んだノート。


Chef


Chef初心者向け資料置き場 - Qiita


このポストを参考に下記をざっと読む。


Chefの概要




  • 特色


    • インフラをどのように構築し、維持するべきかという定義はRubyの文法で記述される

    • あたかもRubyでプログラミングをするように、インフラの構成管理をコードによって行える

    • べき等性=ある操作を一度行っても何度行っても結果が同じ


      • chefは基本保証するが、cookbook、recipeを自分で書くときはべき等性を保つよう注意





  • インフラの定義方法


    • cookbook: rubyで記述されたインフラの定義

    • recipe: cookbook構成要素のひとつ。ruby文法+resource

    • resource: chef専用の命令



  • 構成


    • どちらでも運用可能、cookbookの書き方も同じ


      • server/client: 大規模環境向き


        • + serverに構成が一元蓄積され見通しが良い

        • - server維持管理、client構築が手間



      • solo: 小規模向き


        • + 手軽に導入

        • - 全体の確認、ノード連携は自己負担







  • 構成要素


    • 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