Pulumi を使用したコードとしてのインフラストラクチャのテスト。 パート2

こんにちは、みんな。 今日は記事の最後の部分を紹介します。 「Pulumi を使用したコードとしてのインフラストラクチャのテスト」、その翻訳はコースの学生のために特別に用意されました 「DevOps の実践とツール」.

導入テスト

このスタイルのテストは強力なアプローチであり、ホワイト ボックス テストを実行してインフラストラクチャ コードの内部動作をテストできます。 ただし、テストできる内容がある程度制限されます。 テストは、実際の展開前に Pulumi によって作成されたメモリ内展開計画に基づいて実行されるため、展開自体をテストすることはできません。 このような場合に備えて、Pulumi には統合テスト フレームワークがあります。 これら XNUMX つのアプローチはうまく連携します。

Pulumi 統合テスト フレームワークは Go で書かれており、これがほとんどの内部コードのテスト方法です。 前述の単体テストのアプローチはホワイト ボックス テストに似ていましたが、統合テストはブラック ボックスです。 (厳密な内部テスト用のオプションもあります。) このフレームワークは、完全な Pulumi プログラムを取得し、それに対してさまざまなライフサイクル操作 (新しいスタックを最初からデプロイする、バリエーションを加えて更新する、削除するなど) をおそらく複数回実行するために作成されました。 。 定期的 (夜間など) およびストレス テストとしてテストを実行します。

（私たちは 私たちはそれに取り組んでいます, これにより、同様の統合テスト機能が言語のネイティブ SDK で利用できるようになります。 Go 統合テスト フレームワークは、Pulumi プログラムが記述されている言語に関係なく使用できます)。

このフレームワークを使用してプログラムを実行すると、次のことを確認できます。

• プロジェクト コードは構文的に正しく、エラーなしで実行されます。
• スタックとシークレットの構成設定は機能し、正しく解釈されます。
• プロジェクトは、選択したクラウド プロバイダーに正常にデプロイできます。
• プロジェクトは初期状態から他の N 状態に正常にアップグレードできます。
• プロジェクトは正常に破棄され、クラウド プロバイダーから削除されます。

すぐに説明するように、このフレームワークは実行時検証の実行にも使用できます。

簡単な結合テスト

これが実際に動作していることを確認するには、リポジトリを見てみましょう pulumi/examples、私たちのチームと Pulumi コミュニティは、独自のプル リクエスト、コミット、夜間ビルドをテストするためにこれを使用しているためです。

以下は私たちの簡単なテストです S3 バケットとその他のオブジェクトを提供する例:

example_test.go:

package test
 
import (
    "os"
    "path"
    "testing"
 
    "github.com/pulumi/pulumi/pkg/testing/integration"
)
 
func TestExamples(t *testing.T) {
    awsRegion := os.Getenv("AWS_REGION")
    if awsRegion == "" {
        awsRegion = "us-west-1"
    }
    cwd, _ := os.Getwd()
    integration.ProgramTest(t, &integration.ProgramTestOptions{
        Quick:       true,
        SkipRefresh: true,
        Dir:         path.Join(cwd, "..", "..", "aws-js-s3-folder"),
        Config: map[string]string{
            "aws:region": awsRegion,
        },
    })
}

このテストでは、フォルダーのスタックの作成、変更、破棄という基本的なライフサイクルを実行します。 aws-js-s3-folder。 テストの合格を報告するには、約 XNUMX 分かかります。

$ go test .
PASS
ok      ... 43.993s

これらのテストの動作をカスタマイズするためのオプションが多数あります。 オプションの完全なリストを参照してください。 構造の中で ProgramTestOptions。 たとえば、Jaeger エンドポイントをトレースするように構成できます (Tracing)、テストが陰性の場合にテストが失敗すると予想されることを示します (ExpectFailure)、一連の「編集」をプログラムに適用して、状態を順次遷移させます(EditDirs）などなど。 これらを使用してアプリケーションのデプロイメントをテストする方法を見てみましょう。

リソースのプロパティの確認

上で説明した統合により、プログラムはクラッシュせずに「動作」することが保証されます。 しかし、結果として得られるスタックのプロパティを確認したい場合はどうすればよいでしょうか? たとえば、特定の種類のリソースがプロビジョニングされている (またはされていない) こと、およびそれらが特定の属性を持っていることなどです。

パラメーター ExtraRuntimeValidation のために ProgramTestOptions これにより、Pulumi によって記録された展開後の状態を確認できるため、追加のチェックを行うことができます。 これには、構成、エクスポートされた出力値、すべてのリソースとそのプロパティ値、リソース間のすべての依存関係を含む、結果として得られるスタックの状態の完全なスナップショットが含まれます。

この基本的な例を確認するために、プログラムが作成することを確認してみましょう。 S3バケット:

  integration.ProgramTest(t, &integration.ProgramTestOptions{
        // as before...
        ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
            var foundBuckets int
            for _, res := range stack.Deployment.Resources {
                if res.Type == "aws:s3/bucket:Bucket" {
                    foundBuckets++
                }
            }
            assert.Equal(t, 1, foundBuckets, "Expected to find a single AWS S3 Bucket")
        },
    })

ここで、go test を実行すると、一連のライフサイクル テストが実行されるだけでなく、スタックが正常にデプロイされた後、結果の状態について追加のチェックが実行されます。

ランタイムテスト

これまでのところ、すべてのテストは純粋にデプロイ動作と Pulumi リソース モデルに関するものでした。 プロビジョニングされたインフラストラクチャが実際に機能することを確認したい場合はどうすればよいでしょうか? たとえば、仮想マシンが実行中であること、S3 バケットに予期したものが含まれていることなどです。

これを行う方法はすでに推測しているかもしれません: オプション ExtraRuntimeValidation のために ProgramTestOptions -これは素晴らしい機会です。 この時点で、プログラムのリソースの完全な状態にアクセスしてカスタム Go テストを実行します。 この状態には、仮想マシンの IP アドレス、URL、および結果として得られるクラウド アプリケーションやインフラストラクチャと実際に対話するために必要なすべての情報が含まれます。

たとえば、テスト プログラムはプロパティをエクスポートします。 webEndpoint 呼ばれるバケット websiteUrl、これは構成されたものを取得できる完全な URL です。 index document。 状態ファイルを調べて見つけることはできますが、 bucket そのプロパティを直接読み取りますが、多くの場合、スタックはチェックに使用すると便利な次のような便利なプロパティをエクスポートします。

integration.ProgramTest(t, &integration.ProgramTestOptions{
            // as before ...
        ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
            url := "http://" + stack.Outputs["websiteUrl"].(string)
            resp, err := http.Get(url)
            if !assert.NoError(t, err) {
                return
            }
            if !assert.Equal(t, 200, resp.StatusCode) {
                return
            }
            defer resp.Body.Close()
            body, err := ioutil.ReadAll(resp.Body)
            if !assert.NoError(t, err) {
                return
            }
            assert.Contains(t, string(body), "Hello, Pulumi!")
        },
    })

以前の実行時チェックと同様に、このチェックはスタックを引き上げた直後に実行され、すべて単純な呼び出しに応答して実行されます。 go test。 そして、これは氷山の一角にすぎません。コードで記述できるすべての Go テスト機能が利用可能です。

継続的なインフラストラクチャ統合

コードレビューに提出する前にテストのためにインフラストラクチャに多くの変更が加えられる場合に、ラップトップでテストを実行できるのは便利です。 しかし、私たちと多くのクライアントは、開発ライフサイクルのさまざまな段階でインフラストラクチャをテストします。

• マージ前のテストのため、開いているすべてのプル リクエストで。
• 各コミットに応じて、マージが正しく行われたことを再確認します。
• 追加の検査のために夜間または毎週など定期的に。
• パフォーマンス テストまたはストレス テストの一環として、通常は長期間にわたってテストを並行して実行したり、同じプログラムを複数回展開したりします。

これらのそれぞれについて、Pulumi はお気に入りの継続的統合システムとの統合をサポートしています。 継続的統合により、インフラストラクチャに対してもアプリケーション ソフトウェアに対してと同じテスト範囲が提供されます。

Pulumi は一般的な CI システムをサポートしています。 その一部を次に示します。

• AWS コードサービス
• Azure DevOps
• サークルCI
• GitHubアクション
• GitLab CI
• Google クラウド ビルド
• トラビス

詳細については、次のドキュメントを参照してください。 連続放出.

一時的な環境

非常に強力な機会が開かれるのは、受け入れテストの目的のみに一時的な環境を展開できることです。 コンセプト プロジェクトとスタック Pulumi は、いくつかの単純な CLI コマンドまたは統合テスト フレームワークを使用することで、完全に分離された独立した環境を簡単に展開および破棄できるように設計されています。

GitHub を使用している場合、Pulumi は以下を提供します GitHub アプリこれは、CI パイプライン内のプル リクエストに受け入れテストを接続するのに役立ちます。 アプリケーションを GitHub リポジトリにインストールするだけで、Pulumi がインフラストラクチャのプレビュー、更新、テスト結果に関する情報を CI およびプールのリクエストに追加します。

コア受け入れテストに Pulumi を使用すると、チームの生産性が向上し、変更の品質に自信が持てる新しい自動化機能が得られます。

合計

この記事では、汎用プログラミング言語を使用することで、アプリケーションの開発に役立つ多くのソフトウェア開発テクニックが利用可能になることを見てきました。 これには、単体テスト、統合テスト、およびそれらが連携して広範な実行時テストを実行する方法が含まれます。 テストはオンデマンドまたは CI システムで簡単に実行できます。

プルミ - オープンソース ソフトウェア、無料で使用でき、お気に入りのプログラミング言語やクラウドで動作します - 今日試してみてください!

→ 最初の部分

出所： habr.com