Terraform：コードとしてのインフラストラクチャへの新しいアプローチ

こんにちは同僚！ 華麗なアイロンマスクは、 火星をテラフォーミングするための野心的な計画を育みますが、「 コードとしてのインフラストラクチャ 」パラダイムに関連する新しい機会に興味があり、「壮大な7」の代表の1つであるTerraformに関する記事の翻訳を提供したいと考えています。 このトピックに関するエフゲニー・ブリクマンの本は悪くないが、彼女は1歳になるので、声を出してください-ロシア語で見たいですか



ヒープからKamal Marhubiへの言葉。



インフラストラクチャはAWSに基づいており、Terraformで管理しています。 この出版物では、作業中に役立つ実用的なヒントとコツを取り上げました。

Terraformおよびコードレベルのインフラストラクチャ

Terraformは、インフラストラクチャの宣言的な管理を支援するHashicorpのツールです。 この場合、インスタンス、ネットワークなどを手動で作成する必要はありません。 クラウドプロバイダーのコンソールで; 将来のインフラストラクチャをどのように見るかを概説する構成を記述するだけです。 この構成は、人間が読み取れるテキスト形式で作成されます。 インフラストラクチャを変更する場合は、構成を編集してterraform apply



を実行しterraform apply



。 Terraformは、クラウドプロバイダーにAPI呼び出しをルーティングし、インフラストラクチャをこのファイルで指定された構成に合わせます。



インフラストラクチャ管理をテキストファイルに移行すると、ソースコードとプロセスを管理するためのすべてのお気に入りのツールを使用して、インフラストラクチャで動作するように方向を変えることができます。 現在、インフラストラクチャは、ソースコードと同様にバージョン管理システムの対象となります。何か問題が発生した場合、同じ方法でレビューしたり、以前の状態にロールバックしたりできます。



たとえば、TerraformがEBSボリュームでEC2インスタンスを定義する方法は次のとおりです。

 resource "aws_instance" "example" { ami = "ami-2757f631" instance_type = "t2.micro" ebs_block_device { device_name = "/dev/xvdb" volume_type = "gp2" volume_size = 100 } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Terraformをまだ試していない場合は、この初心者向けガイドが適切であり、このツールのタスクの流れにすぐに慣れるのに役立ちます。

地形データモデル

一般的な観点では、Terraformデータモデルは単純です。Terraformはリソースを管理し、リソースには属性があります。 AWSの世界からの例：

• インスタンスEC2は、マシンタイプ、ブートイメージ、アベイラビリティーゾーン、セキュリティグループなどの属性を持つリソースです
• EBSボリュームは、ボリュームサイズ、ボリュームタイプ、IOPSなどの属性を持つリソースです
• エラスティックロードバランサーは、バックアップインスタンスの属性、そのパフォーマンス特性、およびその他の現象を備えたリソースです。

Terraformは、構成ファイルに記述されているリソースと、クラウドプロバイダーの対応するリソースのマッピングを提供します。 このマッピングは状態と呼ばれ、巨大なJSONファイルです。 terraform apply



Terraformは対応するリクエストをクラウドプロバイダーに送信して状態を更新します。 次に、返されたリソースをTerraform構成に記録されている情報と比較します。 違いが見つかった場合、実際の構成が構成で指定された構成と一致するように、本質的にクラウドプロバイダーのリソースに対して行う必要がある変更のリストを作成します。 最後に、Terraformはこれらの変更を適用し、クラウドプロバイダーへの適切な呼び出しを指示します。

すべてのTerraformリソースがAWSリソースではない

リソースと属性を備えたこのようなデータモデルを理解することはそれほど難しくありませんが、クラウドプロバイダーAPIと完全には一致しない場合があります。 実際、単一のTerraformリソースは、クラウドプロバイダーの1つまたは複数の基本オブジェクトに対応できます。 AWSからの例をいくつか示します。

• aws_ebs_volume
  
  
  
  は、1つのAWS EBSボリュームと一致します
• 前の例のようにebs_block_device
  
  
  
  ブロックを持つTerraformのaws_instance
  
  
  
  は、2つのEC2リソースに対応しています：インスタンスと
• aws_volume_attachment
  
  
  
  は、EC2のどのオブジェクトとも一致しません！

後者は驚くべきことに思えるかもしれません。 aws_volume_attachment



作成すると、TerraformはAttachVolume



リクエストを作成します。 このボリュームが破壊されると、 DetachVolume



リクエストが送信されDetachVolume



。 単一のEC2オブジェクトは関係していませんaws_volume_attachment



は完全に合成されています！ Terraformのすべてのリソースと同様に、IDがあります。 ただし、ほとんどの場合、IDはクラウドプロバイダーから購入されますが、 aws_volume_attachment



IDは、ボリュームID、インスタンスID、およびデバイス名からの単なるハッシュです。 Terraformに合成リソースが表示される他のケースがありますaws_route53_zone_association



、 aws_elb_attachment



、 aws_security_group_rule



。 それらを見つけるには、 association



またはattachment



リソースの名前で検索できますが、常に役立つとは限りません。

すべてのタスクはいくつかの方法で解決されるため、選択する際は注意してください！

Terraformを使用する場合、まったく同じインフラストラクチャをいくつかの異なる方法で表すことができます。 TerraformのEBSボリュームを使用したインスタンス例の説明の別のバージョンは、まったく同じEC2リソースを提供します。

 resource "aws_instance" "example" { ami = "ami-2757f631" instance_type = "t2.micro" } resource "aws_ebs_volume" "example-volume" { availability_zone = "${aws_instance.example.availability_zone}" type = "gp2" size = 100 } resource "aws_volume_attachment" "example-volume-attachment" { device_name = "/dev/xvdb" instance_id = "${aws_instance.example.id}" volume_id = "${aws_ebs_volume.example-volume.id}" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

EBSボリュームはTerraformの本格的なリソースになりました。EC2インスタンスから区切りました。 最初の2つをリンクする3番目の合成リソースがあります。 インスタンスとボリュームを想像すると、 aws_ebs_volume



およびaws_volume_attachment



を追加および削除するだけで、ボリュームを追加および削除できます。



多くの場合、選択するEBSの表現は関係ありません。 しかし、選択が間違っていた場合、その後のインフラストラクチャの変更は非常に困難になることがあります！

私たちは選択を間違えました

これは私たちがやけどした場所です。 大規模なAWS PostgreSQLクラスターを使用しており、18個のEBSボリュームがストレージとして各インスタンスに接続されています。 これらのインスタンスはすべて、 ebs_block_device



ブロックで定義されたEBSボリュームを持つ唯一のaws_instanceリソースとしてTerraformで表されます。



データベースのインスタンスでは、情報はZFSファイルシステムに保存されます。 ZFSを使用すると、ブロックデバイスを動的に追加して、遅延なくファイルシステムを拡張できます。 したがって、顧客からのデータ送信量が増えるにつれて、ストレージを徐々に増やしていきます。 私たちは分析会社であり、あらゆる種類の情報を収集するため、このような機会は私たちにとって大きな助けになります。 クエリを常に最適化し、クラスタに操作を挿入します 。 したがって、クラスターを準備するときに選択した厳格なCPUストレージ比率にとらわれずに、最新のイノベーションを効果的に使用するために、その場でバランスを調整することができます。



ebs_block_device



ブロックを使用しない場合、このプロセスはさらにスムーズにebs_block_device



ます。 はい、Terraformがebs_block_device



の19番目のブロックをaws_instance aws_instance



追加することを期待できaws_instance



。すべてが正常に機能しaws_instance



。 ただし、Terraformはここで圧倒的な変更を確認します。彼は18ボリュームのインスタンスを19に変更する方法を「知りません」。いや、Terraformはインスタンス全体を破棄し、代わりに新しいインスタンスを作成します。 少なくとも、テラバイトの情報が保存されているデータベースに似たものが欲しかったのです！



最近まで、回避策を使用し、いくつかの段階でTerraformを同期させました。

1. AWS CLIを使用してボリュームを作成および追加するスクリプトを実行しました
2. terraform refresh
   
   
   
   実行して、Terraformが状態を更新し、
3. 最終的に新しい現実に合わせて再構成されました

ステップ2と3の間で、 terraform plan



チームは、Terraformがデータベースのすべてのインスタンスを破壊して再作成しようとしていたことを示します。 したがって、誰かが構成を更新するまで、Terraformでこれらのインスタンスを操作することはできませんでした。 言うまでもなく、この状態を永続的に維持することはどれほど恐ろしいことでしょう。

Terraform State：手術への移行

aws_volume_attachment



を使用したアプローチを発見したため、ビューを再構築することにしました。 各ボリュームは、 aws_ebs_volume



とaws_volume_attachmentの2つの新しいTerraformリソースに変わりました。 クラスター内のインスタンスごとに18のボリュームがあり、1000を超える新しいリソースが目の前に並んでいます。 ビューの再構築は、Terraform構成の変更だけではありません。 Terraformの最下部に到達し、リソースのビジョンを変更する必要がありました。



1,000を超えるリソースを追加したため、手動で追加することは絶対にありませんでした。 TerraformステータスはJSON形式で保存されます。 この形式は安定していますが、ドキュメントには「 ステータスのあるファイルを直接編集することはお勧めできません 」と記載されています 。 私たちはまだそれをしなければなりませんが、私たちはそれを正しくしていることを確認したかったのです。 JSON形式のリバース開発に従事しないことにしましたが、読み取り、変更、書き込み用のライブラリとしてTerraform内部要素を使用するプログラムを作成しました。 簡単なことではありませんでした。なぜなら、私たち全員にとって、Goで作業する最初のプログラムだったからです！ ただし、確認する必要があると考えました。はい、データベースのすべてのインスタンスのすべてのTerraform状態を1つのヒープに混同しないでください。



このツールをGitHubに投稿しました。このツールで遊んでみて、自分の靴で自分を感じたい場合に備えて。

正確な地形

terraform apply



の開始は、企業インフラ全体に深刻な損害を与える可能性のある数少ない行為の1つです。 いくつかのヒントがありますが、その後、リスクを減らすことができます-一般的にはそれほど怖くないでしょう。

常に–out



計画を準備し、この計画に従ってください

terraform plan -out planfile



を実行すると、Terraformはterraform plan -out planfile



に計画をplanfile



ます。 その後、 terraform apply planfile



実行terraform apply planfile



により、この計画を正確に取得できterraform apply planfile



。 したがって、この時点で適用される変更は、計画時にTerraformが表示する内容に正確に対応しています。 例外は、同僚の1人が「計画」操作と「適用」操作の間でインフラストラクチャを調整したために、インフラストラクチャが突然変更される可能性がある状況です。



ただし、このファイルを操作するときは注意してください。Terraform変数はそこに含まれているため、そこに何か秘密を書くと、 この情報は暗号化されていない形式でファイルシステムに記録されます 。 たとえば、資格情報を変数としてクラウドプロバイダーに転送する場合、資格情報はプレーンテキストとしてディスクに保存されます。

読み取り専用のIAMロールを作成して変更を列挙する

Terraform terraform plan



開始するとterraform plan



Terraformはアーキテクチャの基本ビューを更新します。 これを行うには、読み取り専用権限を持つクラウドプロバイダーへのアクセスのみが必要です。 彼にそのような役割を与えたので、構成に加えられた変更をterraform plan



を使用して確認し、不注意なapply



チームが1日または1週間であなたのために行ったすべての作業を取り消す危険を冒すことさえできません！



AWSを使用すると、TerraformでIAMロールと関連する権限を管理できます。 Terraformの役割は次のようになります。

 resource "aws_iam_role" "terraform-readonly" { name = "terraform-readonly" path = "/", assume_role_policy = "${data.aws_iam_policy_document.assume-terraform-readonly-role-policy.json}" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

assume_role_policy



は、このロールの受け入れをassume_role_policy



されたユーザーを単にリストします。



最後に、すべてのAWSリソースへの読み取り専用アクセスを提供するポリシーが必要です。 Amazonは、ポリシーの説明が記載されたドキュメントを親切に提供します。これは、コピーして貼り付けることができます。これは、使用したドキュメントです。 このドキュメントを参照するaws_iam_policy



ポリシーを定義します。

 resource "aws_iam_policy" "terraform-readonly" { name = "terraform-readonly" path = "/" description = "Readonly policy for terraform planning" policy = "${file("policies/terraform-readonly.json")}" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、 aws_iam_policy_attachment



を追加しながら、ポリシーをaws_iam_policy_attachment



terraform-readonly



ロールに適用します。

 resource "aws_iam_policy_attachment" "terraform-readonly-attachment" { name = "Terraform read-only attachment" roles = ["${aws_iam_role.terraform-readonly.name}"] policy_arn = "${aws_iam_policy.terraform-readonly.arn}" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、Secure Token Service APIの一部であるAssumeRole



メソッドを使用して、AWSのみをリクエストできる一時的な認証情報を取得できますが、変更はできません。 terraform plan



起動することにより、Terraformの状態を更新し、インフラストラクチャの現在の状態を反映するようにします。 ローカル状態で作業している場合、この情報はterraform.tfstate



ファイルに書き込まれます。 たとえば、S3でリモート状態を使用する場合、読み取り専用ロールには書き込み権限も必要になります。そうしないと、S3に到達できません。



データベースaws_volume_attachment



でaws_volume_attachment



を使用するようにTerraformの状態全体を書き直すよりも、このロールを整理する方がはるかに簡単でした。 AWSインフラストラクチャで変更が計画されていないことはわかっていました。Terraformでのプレゼンテーションのみが変更されます。 最終的に、インフラストラクチャを完全に変更するつもりはありませんでした。なぜこのような機会が必要なのでしょうか。

未来へのアイデア

私たちのチームは成長しており、新しい従業員はTerraformでインフラストラクチャに変更を加えることを学んでいます。 このプロセスはシンプルで安全なものにしたいです。 ほとんどの障害は人為的エラーと構成の変更に関連しており 、Terraformを使用した変更は両方に伴う可能性があります。恐ろしいことです。



たとえば、小さなチームでは、常に1人だけがTerraformで作業することを保証するのは簡単です。 大規模なチームでは、これを保証することはできません-期待するだけです。 terraform apply



が2つのノードから同時に実行された場合、結果はひどい非決定的ハッシュになる可能性があります。 Terraform 0.9では、 状態をロックする機能が導入されました。これにより、 terraform apply



1つのterraform apply



コマンドのみをterraform apply



できます。



簡単さとセキュリティを実現したい別の作業領域は、インフラストラクチャに加えられた変更のレビューです。 この段階では、レビューする際に、 terraform plan



出力をコピーしてレビューへのコメントとして貼り付けます。オプションが承認されたら、すべての変更を手動で行います。



Terraformの構成を検証するときに、継続的統合ツールを使用するように既に適合しています。 terraform validate



、 terraform validate



コマンドを実行するだけで、ツールはコードの構文エラーをチェックします。 次のタスクは、 terraform plan



を起動し、インフラストラクチャに加えられた変更をコードレビューのコメントとして表示するように、継続的統合ツールを適合させることです。 継続的インテグレーションシステムは、変更が承認されるとすぐに、 terraform apply



を自動的に起動しterraform apply



。 そのため、手動で実行する必要がある手順の1つを除外し、コメントで追跡可能な、より一貫した制御トラック（変更履歴）を提供します。 Terraform Enterpriseバージョンにはこの機能があります。そのため、詳細を確認することをお勧めします。