序章


インフラストラクチャを構築すると、多くのサーバー、サービス、ユーザー、およびアプリケーションの管理がすぐに扱いにくくなる可能性があります。 構成管理システムは、この混乱を管理するのに役立ちます。

Chef は、システム全体のさまざまなコンポーネントを非常に簡単に構成できる優れた構成管理システムです。 以前のガイドでは、 Chefの用語、Chefサーバー、ワークステーション、およびノード( Chef12またはChef11 を使用)のインストール方法、および[X161X ]構成を管理するための簡単なクックブックを作成する方法。

このガイドでは、Chefを使用して環境を管理する方法について引き続き説明します。 今回は、役割と環境を使用して、サーバーとサービスがどのような機能を発揮するかに基づいてサーバーとサービスを区別する方法について説明します。

サーバー、ワークステーション、およびクライアントがインストールされており、前回のガイドで作成したクックブックが利用可能であると想定します。

役割と環境


役割とは何ですか?


組織内で、より高いトラフィックの需要を満たすためにインフラストラクチャが拡張された場合、すべてが同じ基本タスクを実行する複数の冗長サーバーが存在する可能性があります。 たとえば、これらはロードバランサーがリクエストを渡すWebサーバーである可能性があります。 それらはすべて同じ基本構成を持ち、それぞれが同じ「役割」を満たしていると言えます。

Chefのrolesの見方は、通常の定義とほぼ完全に同じです。 Chefでの役割は、特定のマシンが実行することになっていることを説明する分類です。 それにはどのような責任があり、どのソフトウェアと設定がそれに与えられるべきか。

さまざまな状況で、特定のマシンが複数の役割を処理している場合があります。 たとえば、ソフトウェアをテストしている場合、1つのサーバーにデータベースとWebサーバーのコンポーネントが含まれている可能性がありますが、本番環境では、これらを別々のサーバーに配置することを計画しています。

Chefを使用すると、これは、最初のサーバーを両方の役割に割り当ててから、各役割を実稼働マシン用の別々のコンピューターに割り当てるのと同じくらい簡単です。 各役割には、特定の役割を実行するためにマシンを完全に動作可能な状態にするために必要な構成の詳細が含まれます。 これは、パッケージのインストール、サービス構成、その役割の特別な属性などを処理するクックブックを収集できることを意味します。

環境とは何ですか?


役割の概念に関連するのは、Chef environmentの概念です。 環境とは、サーバーが本番プロセスのどの段階に含まれているかを管理者が知るのに役立つ単なる指定です。 各サーバーは、正確に1つの環境の一部にすることができます。

デフォルトでは、「_default」と呼ばれる環境が作成されます。 別の環境が指定されていない限り、各ノードはこの環境に配置されます。 プロセスグループの一部としてサーバーにタグを付けるための環境を作成できます。

たとえば、ある環境を「テスト」と呼び、別の環境を「本番」と呼ぶことができます。 実稼働マシンでまだテスト中のコードは必要ないため、各マシンは1つの環境にのみ存在できます。 次に、テスト環境のマシンに対して1つの構成を作成し、本番環境のコンピューターに対して完全に異なる構成を作成できます。

上記の役割の例では、テスト環境でWebサーバーとデータベースサーバーの役割が単一のマシン上にあることを指定できます。 実稼働環境では、これらの役割は個々のサーバーが取り組む必要があります。

環境は、テストプロセス自体にも役立ちます。 本番環境では、クックブックが安定したバージョンである必要があることを指定できます。 ただし、マシンがテスト環境の一部である場合は、より新しいバージョンのクックブックを受信できるように指定できます。

役割の使用方法


RubyDSLを使用して役割を作成する


を使用して役割を作成できます roles 私たちのディレクトリ chef-repo ワークステーションのディレクトリ。

ワークステーションにログインして、今すぐこのディレクトリに移動します。

cd ~/chef-repo/roles

このディレクトリ内に、組織で必要な役割を定義するさまざまなファイルを作成できます。 各ロールファイルは、ChefのRubyDSLまたはJSONのいずれかで書き込むことができます。

Webサーバーの役割を作成しましょう。

nano web_server.rb

このファイル内で、役割に関するいくつかの基本データを指定することから始めることができます。

name "web_server"
description "A role to configure our front-line web servers"

これらはかなり簡単なはずです。 指定する名前にスペースを含めることはできません。通常、この役割用に選択したファイル名から拡張子を除いたものと一致する必要があります。 説明は、役割が管理することになっているものについての人間が読めるメッセージにすぎません。

次に、この特定の役割に使用するrun_listを指定できます。 ロールのrun_listには、クックブック(デフォルトのレシピを実行する)、クックブックのレシピ(cookbook :: recipe構文を使用して指定)、およびその他のロールを含めることができます。 run_listは常に順番に実行されるため、依存関係の項目を他の項目の前に置くことを忘れないでください。

run_listが前回のガイドで構成したものとまったく同じになるように指定したい場合は、次のようになります。

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"

また、環境固有のrun_listsを使用して、サーバーが属する環境に応じて可変構成の変更を指定することもできます。

たとえば、ノードが「本番」環境にある場合、「nginx」クックブックで特別なレシピを実行して、そのサーバーを本番ポリシーの要件に合わせることができます。 また、サーバーをテストするための特別な変更を構成することを目的としたレシピをnginxクックブックに含めることもできます。

これらの2つのレシピがそれぞれ「config_prod」および「config_test」と呼ばれると仮定すると、次のような環境固有の実行リストを作成できます。

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"
env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"]

上記の例では、ノードが本番環境の一部である場合、「nginx」クックブック内で「config_prod」レシピを実行する必要があることを指定しました。 ただし、ノードがテスト環境にある場合は、「config_test」レシピが実行されます。 ノードが別の環境にある場合は、デフォルトのrun_listが適用されます。

同様に、デフォルト属性とオーバーライド属性を指定できます。 この時点で、デフォルトの属性に精通している必要があります。 私たちの役割では、他の場所で設定されたデフォルト属性のいずれかをオーバーライドできるデフォルト属性を設定できます。

他の多くの属性宣言よりも優先度の高いオーバーライド属性を設定することもできます。 これを使用して、この役割が割り当てられているノードが特定の方法で動作するように強制することができます。

私たちのファイルでは、これらは次のように追加できます。

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"
env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"]
default_attributes "nginx" => { "log_location" => "/var/log/nginx.log" }
override_attributes "nginx" => { "gzip" => "on" }

ここでは、ノード内のサーバーのデフォルトのログの場所を設定しました。 また、他の場所で他の属性宣言が述べているにもかかわらず、このロールのノードではgzip属性を「on」に設定する必要があることも指定しました。 これは、さらにいくつかの場所でオーバーライドできますが、通常は優先度の高い宣言です。

JSONを使用してロールを作成する


ロールを構成するために使用できる他の形式はJSONです。 実際、knifeを使用してこの形式で役割を自動的に作成することにより、この形式を調べることができます。 テストロールを作成しましょう:

knife role create test

テンプレートロールファイルがプリロードされた状態でテキストエディタが開きます。 次のようになります。

{
  "name": "test",
  "description": "",
  "json_class": "Chef::Role",
  "default_attributes": {
  },
  "override_attributes": {
  },
  "chef_type": "role",
  "run_list": [

  ],
  "env_run_lists": {
  }
}

これは基本的に、RubyDSL形式のファイルに入力した情報と同じです。 唯一の違いは、フォーマットと2つの新しいキーの追加です。 json_classchef_type. これらは内部で使用されるため、変更しないでください。

それ以外は、次のようなJSONで他のファイルを簡単に再作成できます。

{
  "name": "web_server",
  "description": "A role to configure our front-line web servers",
  "json_class": "Chef::Role",
  "default_attributes": {
    "nginx": {
      "log_location": "/var/log/nginx.log"
    }
  },
  "override_attributes": {
    "nginx": {
      "gzip": "on"
    }
  },
  "chef_type": "role",
  "run_list": [
    "recipe[apt]",
    "recipe[nginx]"
  ],
  "env_run_lists": {
    "production": [
      "recipe[nginx::config_prod]"
    ],
    "testing": [
      "recipe[nginx::config_test]"
    ]
  }
}

これは、上記のRubyバージョンとほぼ同じ機能を持つはずです。

ワークステーションとサーバー間での役割の転送


ナイフコマンドを使用して作成されたJSONファイルを保存すると、Chefサーバーにロールが作成されます。 対照的に、ローカルで作成したRubyファイルはサーバーにアップロードされません。

次のようなコマンドを実行して、rubyファイルをサーバーにアップロードできます。

ファイルpath/to / role/fileからのナイフの役割

これにより、ファイルで指定された役割情報がサーバーにアップロードされます。 これは、RubyDSL形式のファイルまたはJSONファイルのいずれかで機能します。

同様に、サーバーからJSONファイルを取得する場合は、knifeコマンドにその役割ファイルをJSONで表示し、それを次のようなファイルにパイプするように指示できます。

ナイフの役割showweb_server-Fjson> path / to / save / to

ノードへの役割の割り当て


これで、使用した形式に関係なく、Chefサーバーでの役割があります。 ノードに特定の役割を割り当てるにはどうすればよいですか?

ノードのrun_listで、レシピと同じようにノードに役割を割り当てます。

したがって、ノードに役割を追加するには、次のコマンドを発行してノードを見つけます。

knife node list

そして、次のようなコマンドを実行します。

ナイフノード編集node_name

これにより、ノードの定義ファイルが表示され、run_listに役割を追加できるようになります。

{
  "name": "client1",
  "chef_environment": "_default",
  "normal": {
    "tags": [

    ]
  },
  "run_list": [
    "recipe[nginx]"
  ]
}

たとえば、レシピを次のファイルの役割に置き換えることができます。

{“ name”:“ client1”、“ chef_environment”:“ _default”、“ normal”:{“ tags”:[
]

}、“ run_list”:[“ role [web_server] ”]}

これは以前のレシピと同じ手順を実行しますが、代わりにサーバーが持つべき役割を単に伝えます。

これにより、検索によって特定の役割のすべてのサーバーにアクセスできます。 たとえば、役割と環境を検索することで、実稼働環境のすべてのデータベースサーバーを検索できます。

knife search "role:database_server AND chef_environment:prod" -a name

これにより、データベースサーバーとして構成されているノードのリストが表示されます。 これをクックブックの内部で使用して、すべての本番データベースサーバーをプールに自動的に追加して読み取り要求を行うようにWebサーバーを構成できます。

環境の使い方


環境の作成


いくつかの点で、環境は役割にかなり似ています。 これらは、異なるサーバーを区別するためにも使用されますが、サーバーの機能によって区別するのではなく、マシンが属する開発フェーズによって環境を区別します。

役割について話すときに、これについては前に説明しました。 実際の製品ライフサイクルと一致する環境が最も理にかなっています。 テスト、ステージング、本番環境でコードを実行する場合は、一致する環境が必要です。

ロールと同様に、RubyDSLまたはJSONのいずれかで定義ファイルを設定できます。

ワークステーションの「chef-repo」ディレクトリに、environmentsディレクトリが必要です。 これは、環境ファイルを配置する場所です。

cd ~/chef-repo/environments

このディレクトリ内で、開発用の環境を定義する場合は、次のようなファイルを作成できます。

nano development.rb

name "development"
description "The master development branch"
cookbook_versions({
    "nginx" => "<= 1.1.0",
    "apt" => "= 0.0.1"
})
override_attributes ({
    "nginx" => {
        "listen" => [ "80", "443" ]
    },
    "mysql" => {
        "root_pass" => "root"
    }
})

ご覧のとおり、システムに環境を組み込むことの主な利点の1つは、クックブックのバージョン制約と、デプロイされるレシピを指定できることです。

JSON形式を使用することもできます。 ナイフツールは、次のように入力して環境ファイルのテンプレートを生成できます。

knife environment create development

これにより、エディターが開きます(ここでも、エディターを次のように設定できます export EDITOR=nano)名前が入力されたプリロードされた環境ファイルを使用します。

次のように入力して、同じファイルを作成できます。

{
  "name": "development",
  "description": "The master development branch",
  "cookbook_versions": {
    "nginx": "<= 1.1.0",
    "apt": "= 0.0.1"
  },
  "json_class": "Cheff:Environment",
  "chef_type": "environment",
  "default_attributes": {
  },
  "override_attributes": {
    "nginx": {
      "listen": [
        "80",
        "443"
      ]
    },
    "mysql": {
      "root_pass": "root"
    }
  }
}

このファイルは、上記で示したRubyファイルと機能的に同じである必要があります。 JSONロールファイルと同様に、環境JSONファイルには2つの追加情報があります(json_classchef_type)これはそのままにしておく必要があります。

サーバーとの間での環境ファイルの移動


この時点で、Ruby DSLを使用した場合、ファイルはワークステーション上にあり、JSONを使用した場合、ファイルはサーバー上にのみ存在します。 ナイフを使ってファイルを簡単に前後に移動できます。

次のように入力して、RubyファイルをChefサーバーにアップロードできます。

knife environment from file ~/chef-repo/environments/development.rb

JSONファイルの場合、次のように入力することで、サーバーから環境ファイルを取得できます。

knife environment show development -Fjson > ~/chef-repo/environments/development.json

これにより、サーバーからのJSONファイルが表示され、結果がenvironmentsサブディレクトリ内のローカルファイルにパイプされます。

ノードでの環境の設定


各ノードは、正確に1つの環境に存在できます。 ノード情報を編集することで、ノードが属する環境を指定できます。

たとえば、というノードを編集するには client1、これを入力できます:

knife node edit client1

これにより、現在のノードパラメータを使用してJSON形式のファイルが開きます。

{
  "name": "client1",
  "chef_environment": "_default",
  "normal": {
    "tags": [

    ]
  },
  "run_list": [
    "role[web_server]"
  ]
}

ご覧のとおり、 chef_environment に設定されています _default 元は。 その値を変更するだけで、ノードを新しい環境に配置できます。

完了したら、ファイルを保存して閉じます。 ノードでの次のchef-client実行時に、新しい属性とバージョン制約を取得し、新しいポリシーに合わせて自身を変更します。

結論


これで、マシンの状態を固めるために役割と環境を操作するさまざまな方法を十分に理解できたはずです。 これらの分類戦略を使用して、Chefがさまざまなコンテキストでサーバーを処理する方法の管理を開始できます。

ジャスティン・エリングウッド