[Terraform + SaltStack]プレッシャークッカーでのPrestoDBクラスターの準備（パート＃1）

ここで面白いのは何ですか？

AWSパブリッククラウドでTerraformおよびSaltStackベースのプレッシャークッカーを使用した、おいしい健康的なPrestoDBクラスターのレシピ。 圧力鍋自体の作業の準備のニュアンス、皿自体の適切な準備に必要な手順を詳細に検討し、もちろん、完成した皿の消費について少しお話します。 この部分は、Terraformのトレーニング資料として使用できます。

それでは始めましょう：

レシピの材料

• Terraform -1個
• SaltStack -1マスターと1+ミニエン
• PrestoDB -1人のコーディネーターと1人以上のワーカー
• AWSアカウント -1個
• 精通してファイルを味わう

材料をより詳細に検討してください：（準備のルールなし）
1. Terraform -Hashicorpの人々（Vagrant、 Consul 、Packer、Vaultなどの非常に有用なものも作成しました）のすばらしいツールです。環境だけでなく 、さまざまなクラウドでインフラストラクチャを作成および変更します。
2. SaltStack-サーバーの自動構成および構成のためのツール。 あなたの謙虚な使用人はすでにこことここでそれについて書きました 。
3. PrestoDB-ネイティブで理解可能なSQLでクエリを実行できるビッグデータプロバイダー向けのアドオン。 Facebookの開発者が開発し、 OSSステータスに移行しました。
4. PrestoDBクラスターがその後動作する、サポートされているTerraformのリストからのAWS （またはその他のパブリック/プライベートクラウド、たとえばGCEまたはOpenStack ）。 AWSを次のように使用します これは（パブリッククラウドプラットフォームの中で）最も一般的であり、多くの追加説明なしで多くの人に理解できます。
5.この記事では、これらの製品群の基本原理とプロセスを容易にするためのいくつかのトリックについてのみ説明しますが、コンポーネントの作業の微妙な違いについては触れません。それぞれについて、原則として本を書くことができます。 したがって、頭を使用してこれらの技術を適応させることは大歓迎です。 そしてまだ-何かが最適に構成されていないことをコメントに書かないでください（特にPrestoDB）-これは私が追求している目標ではありません。

圧力鍋を調理する！

どんな料理のレシピでも、フライパンやフライパンはすでに調理の準備ができているという沈黙がありますが、私たちの場合、プレッシャークッカー（Terraform + SaltStack）の正しい準備が調理の成功のほぼ80％です。
それでは、Terraformから始めましょう。 さて、 SaltStackの作成者によるAWSまたはSaltCloudの CloudFormationがあります。なぜTerraformが選ばれたのですか？ Terraformの主な機能は、シンプルで理解しやすいDSLで、必要なインスタンス（または10）を作成し、この説明を十分に作成することです（Terraformがダウンロードされ 、$ PATH内にあることを意味します ）。

provider "aws" { access_key = "XXXXXXXXXXXXXXXXXXXXX" # AWS IAM key secret_key = "******************************************" # AWS IAM secret region = "us-east-1" # region used to create resources } resource "aws_instance" "example_inst" { ami = "ami-6d1c2007" # CentOS 7 AMI located in US-East-1 instance_type = "t2.medium" count = "1" # or "10" can be used for parallel creation vpc_security_group_ids = [ "default-sg" ] # some security group with at least 22 port opened key_name = "secure_key" # pre created AWS E2 key pair subnet_id = "sub-abcdef123" # AWS VPC subnet } 

コマンドの簡単なシーケンス：

terraform plan
terraform apply

物語は理解可能であり、私にとっては、AWSに精通している人には説明を必要としないようです。 利用可能なAWSリソースの詳細については、 こちらをご覧ください 。 もちろん、Terraform構成でキーが指定されているAWSアカウントには、必要なリソースを作成する権限があります。
実際、最も興味深いのはTerraform自体の呼び出し-terraformプラン-が最後の状態（この例では、新しいインスタンスを作成する必要がある）から実行する必要があるものの「見積もり」を作成し、どのリソースが作成、削除、変更、適用されるかを示します-それは実際にプロセスを開始します計画されたリソースの作成。 Terraformが既に開始されており、計画段階で構成（たとえば、追加されたインスタンス）を変更した場合、どの不足リソースが作成され、適用されて不足リソースを作成できるかが表示されます。

terraform destroy

Terraformを使用して作成されたすべてのリソースを完全に削除するのに役立ちます（作成されたインフラストラクチャの状態の説明を格納する現在の.tfstateディレクトリ内のファイルが考慮されます）。
忘れてはならない重要な点-terraformはほとんどの場合、既存のリソースを変更しません-単純に古いリソースを削除して、再作成します。 これは、たとえば、t2.mediumタイプのインスタンスを作成し、インスタンスの新しいタイプ（m4.xlargeなど）を指定して構成を変更した場合、適用するときにTerraformは以前に作成したインスタンスを破棄してから新しいインスタンスを作成することを意味します。 これはAWSユーザーにとって奇妙に思えるかもしれません（インスタンスを停止し、タイプを変更し、ディスク上のデータを失うことなく再起動できます）が、これはすべてのプラットフォームで同じ予測される動作を提供するために行われました。 そしてもう1つ：Terraformはライフサイクル中にリソースを制御できません（その性質上できないはずです）-これは、Terraformがそれを使用して作成されたインスタンスに対して停止または再起動などのコマンドを提供しないことを意味します-他の手段を使用して確立されたインフラストラクチャを管理します。
Terraformは、DSLで使用できる優れた機能セットを提供します。これらは変数 （https://www.terraform.io/docs/configuration/variables.html）、 補間 （反復、変数の変更に必要）、 モジュールなどです。 これをすべて使用する1つの例を次に示します。

 # Cluster shortname variable cluster_name { default = "example-presto" } # Count of nodes in cluster variable cluster_size { default = 3 } # Default owner for all nodes variable cluster_owner { default = "user@example.com" } # Default AWS AMI to use for cluster provisioning variable cluster_node_ami { default = "ami-6d1c2007" } # Default AWS type to use for cluster provisioning variable cluster_node_type { default = "t2.large" } # Defualt VPC subnet variable cluster_vpc_subnet { default = "subnet-da628fad" } # Default Security group to apply to instances variable cluster_sg { default = "sg-xxxxxxx" } # Default KeyPair to use for provisioning variable cluster_keyname { default = "secure_key" } # Cluster worker nodes resource "aws_instance" "worker_nodes" { ami = "${var.cluster_node_ami}" instance_type = "${var.cluster_node_type}" count = "${var.cluster_size - 1}" # one node will be used for coordinator vpc_security_group_ids = [ "${var.cluster_sg}" ] key_name = "${var.cluster_keyname}" subnet_id = "${var.cluster_vpc_subnet}" disable_api_termination = true tags { Name = "${var.cluster_name}-cluster-worker-${format("%02d", count.index+1)}" Owner = "${var.cluster_owner}" Purpose = "PrestoDB cluster '${var.cluster_name}' node ${format("%02d", count.index+1)}" } } 

ここでは、変数の使用、変数の算術演算、フォーマットを使用した補間、現在の要素のインデックスの使用（同じタイプの複数のインスタンスが作成された場合）、およびリソースのタグ付けの例を示します。
ただし、インスタンスを作成/破棄するだけでは十分ではありません-このTerraformには、 Provisionersの概念を導入するために、何らかの方法でそれらを初期化する必要があります（ファイルのコピー、特定のソフトウェアのインストールと構成、システムの更新、クラスターの構成など）。 主なものはfile 、 remote-exec 、 chef、およびnull-resourceです。 典型的な操作は、リモートインスタンスでのファイルのコピーとスクリプトの実行です。
プロビジョニング操作を有効にした前の例を次に示します。

 # Localy stored SSH private key filename variable cluster_keyfile { default = "~/.ssh/secure_key.pem" } # Cluster worker nodes resource "aws_instance" "worker_nodes" { ami = "${var.cluster_node_ami}" instance_type = "${var.cluster_node_type}" count = "${var.cluster_size - 1}" # one node will be used for coordinator vpc_security_group_ids = [ "${var.cluster_sg}" ] key_name = "${var.cluster_keyname}" subnet_id = "${var.cluster_vpc_subnet}" disable_api_termination = true tags { Name = "${var.cluster_name}-cluster-worker-${format("%02d", count.index+1)}" Owner = "${var.cluster_owner}" Purpose = "PrestoDB cluster '${var.cluster_name}' node ${format("%02d", count.index+1)}" } # Copy bootstrap script provisioner "file" { source = "bootstrap-script.sh" destination = "/tmp/bootstrap-script.sh" connection { type = "ssh" user = "centos" private_key = "${file("${var.cluster_keyfile}")}" } } # Running provisioning commands provisioner "remote-exec" { inline = [ "yum -y update", "sudo sh /tmp/bootstrap-script.sh" ] connection { type = "ssh" user = "centos" private_key = "${file("${var.cluster_keyfile}")}" } } } 

主なポイントは、リモートホストへの接続に関する情報を提供することです。AWSの場合、これはほとんどの場合キーアクセスです。したがって、正確にこのキーの場所を指定する必要があります（変数は便宜上導入されました）。 接続セクションのprivate_key属性はファイルへのパスを受け入れることができないことに注意してください（キーのみがテキストです）-代わりに、ディスク上のファイルを開き、その内容を返す$ file {}補間が使用されます。
複数のインスタンスで構成される単純なクラスターを作成しました（bootstrap-script.shファイルの内容の詳細には触れません-必要なソフトウェアのインストールがそこに登録されていると仮定します）。 圧力鍋で専用マスターを使用してクラスターを作成する方法を見てみましょう。 一般に、クラスターのワーカーノードは、マスターノードの場所を認識して、将来的にタスクを受信する必要があると想定します（他の記事のためにクラスター内でマスターを確立し、情報を広めるためにRaftやGossipプロトコルなどのあらゆる種類のグッズを残しましょう）-簡単にするために-ワーカーがマスターのIPアドレスを知っている必要があるとします。 これをTerraformに実装する方法は？ 最初に、マスター用に個別のインスタンスを作成する必要があります。

 resource "aws_instance" "master_node" { ami = "${var.cluster_node_ami}" instance_type = "${var.cluster_node_type}" count = "1" <...skipped...> provisioners { <...skipped...> } } 

次に、ワーカーノードに依存関係を追加します。

 # Clurter worker nodes resource "aws_instance" "worker_nodes" { depends_on = ["aws_instance.master_node"] # dependency from master node introduced ami = "${var.cluster_node_ami}" instance_type = "${var.cluster_node_type}" count = "${var.cluster_size - 1}" # one node will be used for coordinator <...skipped...> } 

depend_onリソース修飾子を使用して、インフラストラクチャを作成するタスクを実行する順序を指定できます。Terraformは、マスターノードが完全に作成されるまでワーカーノードを作成しません。 この例からわかるように、依存関係（tei）として、リソースのタイプから構成されたリストを指定し、その名前をドットで示します。 AWSでは、インスタンスだけでなく、VPC、ネットワークなども作成できます。 -VPCを使用してリソースの依存関係として指定する必要があります-これにより、正しい作成順序が保証されます。
しかし、マスターノードのアドレスをすべてのワーカーノードに渡し続けましょう。 このため、Terraformは、以前に作成されたリソースを参照するメカニズムを提供します。 ワーカーの説明でマスターノードのIPアドレスに関する情報を簡単に抽出できます。

 # Clurter worker nodes resource "aws_instance" "worker_nodes" { depends_on = ["aws_instance.master_node"] # dependency from master node introduced ami = "${var.cluster_node_ami}" instance_type = "${var.cluster_node_type}" count = "${var.cluster_size - 1}" # one node will be used for coordinator <...skipped...> # Running provisioning commands provisioner "remote-exec" { inline = [ "yum -y update", "sudo sh /tmp/bootstrap-script.sh ${aws_instance.master_node.private_ip}" # master-ip passed to script ] connection { type = "ssh" user = "centos" private_key = "${file("${var.cluster_keyfile}")}" } } } 

つまり $ {aws_instance.master_node.private_ip}という形式の変数を使用すると、ほとんどすべてのリソース情報にアクセスできます。 この例では、bootstrap-script.shがマスターノードのアドレスをパラメーターとして取得し、後で内部構成に使用できると想定しています。
そのような接続では不十分な場合があります。たとえば、Terraformではnullと呼ばれるメカニズムがあるため、ワーカーノードを接続した後、マスターノード側でいくつかのスクリプトを呼び出す必要があります（キーを受け入れ、ワーカーノードでinitタスクを実行するなど） -resourceは、依存関係メカニズム（上記を参照）を使用して、すべてのマスターノードとワーカーノードが作成された後に作成できる偽のリソースです。 そのようなリソースの例を次に示します。

 resource "null_resource" "cluster_provision" { depends_on = [ "aws_instance.master_node", "aws_instance.worker_nodes" ] # Changes to any instance of the workers' cluster nodes or master node requires re-provisioning triggers { cluster_instance_ids = "${aws_instance.master_node.id},${join(",", aws_instance.worker_nodes.*.id)}" } # Bootstrap script can run only on the master node connection { host = "${aws_instance.master_node.private_ip}" type = "ssh" user = "centos" private_key = "${file("${var.cluster_keyfile}")}" } provisioner "remote-exec" { inline = [ <... some after-provision scripts calls on master node...> ] } } 

少し説明：
1. depend_on-事前に準備が必要なリソースのリストを示します。
2.トリガー-ドレイン（この場合はコンマで区切られたすべてのインスタンスのID）を形成します。この変更により、このリソースで指定されたすべてのプロビジョニングエージェントが実行されます。
3.接続セクションのこのリソースで指定されたプロビジョニングスクリプトを実行する必要があるインスタンスを示します。

異なるサーバーでいくつかの手順を実行する必要がある場合-必要な依存関係を持つ複数のnullリソースを作成します。

一般に、Terraformを使用して非常に複雑なインフラストラクチャを作成するには、説明されているだけで十分です。
他の人の間違いから学びたい人のためのいくつかのより重要なヒントを以下に示します。
1. Terraformが作成されたインフラストラクチャの最後の状態を保存する.tfstateファイルを慎重に保存することを忘れないでください（さらに、作成されたリソースに関する情報の網羅的なソースとして使用できるjsonファイルです）
2. Terraformを使用して作成されたリソースを手動で変更しないでください（サービス自体の管理コンソールおよび他の外部フレームワークを使用）-次回プランおよび適用を開始すると、現在の説明に対応しないリソースの再作成を受け取ります。
3.最初に小さなインスタンス/少数のインスタンスで構成をテストしてみます-構成を作成するときに多くのエラーをキャッチすることは非常に難しく、Terraformに組み込まれたバリデーターは構文エラーのみを表示します（それだけではありません）。

第2部では、作業用の圧力鍋の準備の継続を検討します-PrestoDBを配置するインフラストラクチャの上にSaltStackマスター+ミニオンを配置する方法を説明します。