2023/12/14

Terraform コードのテスト方法

詳解 Terraform 第3版

2023年11月に「詳解 Terraform 第3版」の日本語版がオライリーから発売された。

https://www.oreilly.co.jp/books/9784814400522/

詳解 Terraform の目次

  • 1章 なぜ Terraform を使うのか
  • 2章 Terraform をはじめよう
  • 3章 Terraform ステートを管理する
  • 4章 モジュールで再利用可能なインフラを作る
  • 5章 Terraform を使うためのヒントとコツ:ループ、条件文機、デプロイ、その他つまずきポイント
  • 6章 シークレットを管理する
  • 7章 複数のプロバイダを使う
  • 8章 本番レベルの Terraform コード
  • 9章 Terraform のコードをテストする
  • 10章 チームで Terraform を使う

「9章 Terraform のコードをテストする」が気になったので購入し、気になるところをメモした。

Terraform コードのテスト手法

本書の中ではテスト手法を以下のように区分している。

  1. 静的解析
  2. プランテスト
  3. サーバテスト
  4. ユニットテスト
  5. 結合テスト
  6. E2Eテスト

リストの下に行くにつれて実装・実行コストが増えるが、Terraform コードの動作確認における確からしさが上がっていく。

実際には特定の区分のみ用いるのではなく、静的解析 + プランテスト + ユニットテスト + E2Eテストなどのように組み合わせて使う。

結論

やはり銀の弾丸はない。自分たちの身の丈、運用、サービスレベルにあったテスト手法を選択することになる。

テスト手法の組み合わせ、各テスト手法にかけるコスト比重、導入順序を検討し、サービスの成長に合わせて変えていくことになる。

静的解析はコストが非常に少ないのでとりあえず導入してみるでも良さそう

以下はそれぞれの手法の概要です。

静的解析

代表的なツール

  • terraform validate
  • tfsec
  • tflint
  • Terrascan

静的解析ツールの強み

  • 動作が高速
  • 使用が簡単
  • 安定している
  • 実際のプロバイダに認証の必要がない
  • 実際のリソースをデプロイ・削除しない

静的解析ツールの弱み

  • 非常に限られた種類のエラーのみ発見できる
  • 機能性をチェックしないので、すべてのチェックが成功してもインフラが動かない可能性がある

プランテスト

terraform plan を実行し、プランの出力を解析する

静的解析より踏み込んでいるが、コードを完全に実行するわけではない

プランテストツール

  • Terratest
  • Open Policy Agent
  • Hashi Corp Sentinel
  • Checkov
  • terraform-compliance
  • terraform test で plan を使用する
    • v1.6で追加されたコマンド。本書はv1.3時点に書かれているそうなので、記載されていない

Terratestを用いた例

planの出力結果

Terraform will perform the following actions:

  # module.alb.aws_lb.example will be created
  + resource "aws_lb" "example" {
      + arn = (known after apply)
      + load_balancer_type = "application"
      + name = "test-4Ti6CP"
      (...)
  }

  (...)

Plan: 5 to add, 0 to change, 0 to destroy.

Terratestでのplanを使ったテスト

func TestAlbExamplePlan(t *testing.T) {
    t.Parallel()

    albName := fmt.Sprintf("test-%s", random.UniqueId())

    opts := &terraform.Options{
        // この相対パスは、自分の alb モジュールの example ディレクトリを
        // 指すよう変更すること
        TerraformDir: "../examples/alb",
        Vars: map[string]interface{}{
            "alb_name": albName,
        },
    }

    planString := terraform.InitAndPlan(t, opts)

    // plan の出力の add/change/destroy の数をチェックする方法の例
    resourceCounts := terraform.GetResourceCount(t, planString)
    require.Equal(t, 5, resourceCounts.Add)
    require.Equal(t, 0, resourceCounts.Change)
    require.Equal(t, 0, resourceCounts.Destroy)
}

Policy as Codeツール

  • Open Policy Agent(OPA)が人気
  • Rego という宣言型言語でポリシーをコートして記録できる
  • Terraformで管理しているリソースに ManagedBy というタグがあるかチェックする
// enforce_tagging.rego
package terraform

allow {
    resource_change := input.resource_changes[_]
    resource_change.change.after.tags["ManagedBy"]
}
  • 使い方
    • planの出力をプランファイルに保存する terraform plan -out tfplan.binary
    • OPAはJSONに対してのみ実行できる。JSONに変換 terraform show -json tfplan.binary > tfplan.json
    • JSONになったプランファイルをチェックする opa eval --data enforce_tagging.rego --input tfplan.json --format pretty data.terraform.allow

プランテストツールの強み

  • ユニットテスト・結合テストと静的解析の間の実行速度
  • 使いやすい
  • 安定している。不安定なテストはほとんどない
  • 実際のリソースを作成・削除しない

プランテストツールの弱み

  • 静的解析よりは多くのエラーを発見できる
  • プロバイダの認証が必要
  • 静的解析と同じく、テストが通ってもインフラが動かないことはあり得る

サーバテスト

サーバ(仮想サーバも含む)が正しく設定されているかテストすることに焦点を当てたテストツール

サーバテストツール

  • InSpec
  • Serverspec
  • Goss

InSpecの例

describe file('/etc/myapp.conf') do
  it { should exist }
  its('mode') { should cmp 0644 }
end

describe apache_conf do
  its('Listen') { should cmp 8080 }
end

describe port(8080) do
  it { should be_listening }
end

サーバテストツールの強み

  • ツールが提供するDSLで一般的な項目は簡単に確認できる
  • applyして、動作しているサーバを確認するので、より多くのエラーを発見できる。

サーバテストツールの弱み

  • 高速ではない。applyとdestroy(必要ないケースもあり)が必要になる
  • 実際にapplyするため、不安定なテストが存在する
  • プロバイダの認証が必要
  • リソースの作成・削除が必要。お金がかかる
  • サーバはチェックできるが、それ以外のインフラはチェックされない

ユニットテスト

Terraform におけるユニットは、再利用可能なモジュール

Terraform コードはAWSのAPIなどを呼びだすため、外部依存関係を全く無くす現実的な方法は存在しない

  • 純粋なユニットテストができない。実際のところ結合テストになる

実際のインフラを実際の環境にデプロイする自動テストを書くことで、Terraform コードが期待通りに動作するか確認できるため

基本戦略

  1. 小さく、独立したモジュールを作る
  2. terraform apply を実行し、実環境にデプロイする
  3. 期待通りに動作するか確認。ALBならHTTPリクエストを送る等
  4. terraform destroy で後片付け

terraform test で apply を使用する

  • v1.6で追加されたコマンド。本書はv1.3時点に書かれているそうなので、記載されていない

Terratest

  • terraform applyを実行し、動作確認をし、terraform destroy をする
  • HTTPリクエストの送信等のヘルパー関数が含まれる
  • terraform の出力変数の値を利用してテストコードを書ける
func TestAlbExample(t *testing.T) {
    opts := &terraform.Options{
        // この相対パスは、自分の alb モジュールの example ディレクトリを
        // 指すよう変更すること
        TerraformDir: "../examples/alb",
    }

    // テストの最後にすべてを後片付け
    defer terraform.Destroy(t, opts)

    // サンプルをデプロイ
    terraform.InitAndApply(t, opts)

    // ALB の URL を取得
    albDnsName := terraform.OutputRequired(t, opts, "alb_dns_name")
    url := fmt.Sprintf("http://%s", albDnsName)

    // ALB のデフォルトアクションが動作し、404 を返すことをテスト
    expectedStatus := 404
    expectedBody := "404: page not found"
    maxRetries := 10
    timeBetweenRetries := 10 * time.Second
    
    http_helper.HttpGetWithRetry(
        t,
        url,
        nil,
        expectedStatus,
        expectedBody,
        maxRetries,
        timeBetweenRetries,
    )
}

結合テスト

複数のUnitを組み合わせてテストをする

  • mysql serverの作成、mysql server を使用するweb app

E2E テスト

インフラが複雑になると実行に時間がかかりすぎる

現実的な対応として、本番に近いテスト環境を1回だけ構築し、動かしたままにする。

インフラコードに変更を加えたらテスト環境に変更を適用し、SeleniumなどでE2Eテストを実行する

その他:不安定なテストに対してリトライする

インフラのコードの定期的に自動テストをすると、不安定なテスト(flaky tests)に直面する

  • 時々EC2が立ち上がらないとか

Terratestを使っているなら、terraform.Options の MaxRetries、TimeBetweenRetries、RetryableTerraformErrors の各引数を使ってリトライを有効にする

2019/12/13

macOS Mojave + VirtualBox + Vagrantで作った環境で composer install が失敗する

環境
  • macOS Mojave: 10.14.6
  • VirtualBox: 6.0.12
  • php: 7.0.33
  • composer: 1.9.1
Vagrantでdebian環境を構築し、PHPのプロジェクトを共有フォルダでマウントする方式だった。
セットアップで vagrant ssh して、その中で composer install を実行したところ、1つ目のpackageのインストールが失敗して、以下のようなエラーが表示された。
- Installing ****/xxxxxxx (x.y.z): Reading /home/vagrant/.cache/composer/files/****/xxxxxxx/4beacec67ac5fe138813cdfd0ab1d031111111.zip from cache
Loading from cache
Extracting archiveExecuting command (CWD): unzip -qq  '/vagrant/hoge/vendor/****/xxxxxxx/98c734dfe8c02cf90edc8787111111111' -d '/vagrant/hoge/vendor/composer/zxcvbnm'
Plugin installation failed, rolling back
- Removing ****/xxxxxxx (x.y.z)

[RuntimeException]
Could not delete /vagrant/yoyaku/vendor/****/xxxxxxx/tests/HogeFuga:
結論としては、Vagrantfileの共有フォルダのtypeオプションに virtualboxが指定されていたので、削除すると動作した。
ファイルのパーミッションやcomposer周りを色々調べたが、時間の無駄だった。

2015/09/15

Dropboxで同期させてるDay Oneのエントリが増殖した

Day One/Journal.dayone/entries の下にエントリが1ファイルずつ存在しているが、
以下のように同じファイルが増殖してた。

4619D4A8395F4163B3CDA61BD40FB1F8 (1).doentry
4619D4A8395F4163B3CDA61BD40FB1F8 (2).doentry
4619D4A8395F4163B3CDA61BD40FB1F8 (3).doentry
4619D4A8395F4163B3CDA61BD40FB1F8.doentry

以下のコマンドで適当に削除して、再同期することで治った

cd ~/Dropbox/アプリ/Day\ One/Journal.dayone/entries
find . -type f -name '*(*' -print0 | xargs -0 rm -f

2015/08/03

php-fpmをServer::Starterを使ってHot deploy

したかったけど、ダメだった。

Server::Starterはサーバプログラムをよしなにホットデプロイしてくれるスーパーデーモンです。

FPM_SOCKETSを使ってsocketは引き継げるが、php-fpmがそもそもgraceful shutdownに対応してないため、Server::StarterがSIGHUPを受けてphp-fpmを切り替える際に処理途中のリクエストが切断される。

なんとかしたい……。

FPM_SOCKETSについて

php-fpmは環境変数のFPM_SOCKETSからsocket情報を引き継ぐ機能がある。

start_serverはsocket情報をSERVER_STARTER_PORTに入れてサーバプログラムに渡すので、FPM_SOCKETSにセットしてphp-fpmを起動するとよい。

ざっくり書くとこういう形

start.sh

#!/bin/bash
start_server --path=`pwd`/php-fpm.sock \
    --interval=15 \
    --signal-on-hup=QUIT -- \
    sh -c 'FPM_SOCKETS=$SERVER_STARTER_PORT php-fpm -y php-fpm.conf'

その他テスト用ファイル

php-fpm.conf

[global]
pid = /Users/yosasaki/devel/php/php-fpm-graceful/php-fpm.pid
error_log = /Users/yosasaki/devel/php/php-fpm-graceful/php-fpm-error_log
daemonize = no

[www]
listen = /Users/yosasaki/devel/php/php-fpm-graceful/php-fpm.sock
listen.backlog = 256
listen.allowed_clients = 127.0.0.1
listen.mode = 0660
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
slowlog = /Users/yosasaki/devel/php/php-fpm-graceful/www-slow_log
php_admin_value[error_log] = /Users/yosasaki/devel/php/php-fpm-graceful/www-error_log
php_admin_flag[log_errors] = on

index.php

<?php
sleep(10);
echo "OK";

nginx.conf

worker_processes  1;
daemon off;

events {
  worker_connections  1024;
}

http {
  include       mime.types;
  default_type  application/octet-stream;

  server {
    listen       8080;
    server_name  localhost;
    root /Users/yosasaki/devel/php/php-fpm-graceful;

    location / {
      fastcgi_pass   unix:/Users/yosasaki/devel/php/php-fpm-graceful/php-fpm.sock;
      fastcgi_index  index.php;
      include fastcgi.conf;
    }
  }
}

2015/07/22

CentOS 6.4でyum updateが"Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again"で失敗する

epelの mirrors.fedoraproject.org とSSLコネクションをひらくところでコケている模様

解決方法

  1. /etc/yum.repos.d/epel.repoのmirrorlistがhttpsになっているので、一旦baseurlに変更する

    baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
    #mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
    
  2. ca-certificatesを更新

    % sudo yum update -y ca-certificates

2015/06/26

DockerでClojureを動かす

Docker containerでClojureのWAFであるLuminusを動かしてみる

事前準備

プロジェクト生成と実行

$ lein new luminus hello-world
$ cd hello-world/
$ lein run
Retrieving org/clojure/clojure/1.7.0-RC2/clojure-1.7.0-RC2.pom from central
Retrieving org/clojure/clojure/1.7.0-RC2/clojure-1.7.0-RC2.jar from central
2015-6-26 13:02:18 +0900 SPC-072.local INFO [hello-world.handler] -
-=[ hello-world started successfullyusing the development profile]=-
2015-06-26 13:02:18.357:INFO:oejs.Server:jetty-7.6.13.v20130916
2015-06-26 13:02:18.439:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:3000

ブラウザで開く

$ open http://localhost:3000

Dockerfile

方針

  • imageはdocker hubのjava8を使う
  • containerにuberjarを含める
    • leiningen runだとcontainer起動後から接続可能になるまで時間がかかる
    • Elastic Beanstalkだと結構致命的
  • CMDexec formじゃなくshell formで書く
    • sh経由で立ち上がるので、ENVでセットした環境変数が受け取れる
    • CMDならdocker run時に簡単に書き換えられる

Dockerfile

    FROM java:8

    ENV TZ JST-9
    ENV JVM_OPTS -server -Xms512m -Xmx512m -Xmn256m

    RUN mkdir -p /home/app
    COPY ./target/hello-worldjar /home/app/

    EXPOSE 3000

    WORKDIR /home/app
    CMD /usr/bin/java $JVM_OPTS -jar hello-world.jar 3000

詳しくはDockerfile referenceを参照。

containerの作成と立ち上げ

uberjar作成

$ lein uberjar
Compiling hello-world.core
Compiling hello-world.handler
Compiling hello-world.layout
Compiling hello-world.middleware
Compiling hello-world.routes.home
Compiling hello-world.session
Created /path/to/project/hello-world/target/hello-world-0.1.0-SNAPSHOT.jar
Created /path/to/project/hello-world/target/hello-world.jar

container作成

$ docker build -t luminus/hello-world .
Sending build context to Docker daemon 56.42 MB
Sending build context to Docker daemon
Step 0 : FROM java:8
 ---> 433801eb0894
Step 1 : ENV TZ JST-9
 ---> Running in ac5801626c85
 ---> 77b3c91b3d78
Removing intermediate container ac5801626c85
Step 2 : ENV JVM_OPTS -server -Xms512m -Xmx512m -Xmn256m
 ---> Running in 5c6a50907c9d
 ---> 9db9e3ecf034
Removing intermediate container 5c6a50907c9d
Step 3 : RUN mkdir -p /home/app
 ---> Running in 4e0e9d8c0b15
 ---> 9af2a4c10750
Removing intermediate container 4e0e9d8c0b15
Step 4 : COPY ./target/hello-world.jar /home/app/
 ---> 4e89615ff644
Removing intermediate container 88d653f5d04f
Step 5 : EXPOSE 3000
 ---> Running in 383fc9ad8ee1
 ---> 0ecb672ec459
Removing intermediate container 383fc9ad8ee1
Step 6 : WORKDIR /home/app
 ---> Running in eb575c33ce63
 ---> 158e8dbc87eb
Removing intermediate container eb575c33ce63
Step 7 : CMD /usr/bin/java $JVM_OPTS -jar hello-world.jar 3000
 ---> Running in 344eac7db8b2
 ---> 132b7b08093a
Removing intermediate container 344eac7db8b2
Successfully built 132b7b08093a

docker run

$ docker run --rm -it -p 3000:3000 luminus/hello-world
2015-Jun-26 13:47:52 +0900 9ae20b5deccf INFO [hello-world.handler] -
-=[ hello-world started successfully]=-
2015-06-26 13:47:52.424:INFO:oejs.Server:jetty-7.x.y-SNAPSHOT
2015-06-26 13:47:52.513:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:3000

-pオプションでcontainer側のTCP/3000をhost側(localhostじゃない)のTCP/3000にマッピングしているので、
boot2dockerコマンドでhost側のIPを調べて接続する

$ open http://$(boot2docker ip):3000

TODO

そのうち以下について書く

  • Docker Compose
  • Docker + ElasticBeanstalk

2015/03/04

Railsアプリをruby-profとqcachegrindでプロファイリング

遅いサイトをなんとかする必要があったので、まずは計測する。

最初に使ったrack-mini-profilerは大して役に立たないので無駄だった。

qcachegrindのインストール

% brew install qcachegrind graphviz

graphvizはqcachegrindでコールグラフの生成に使う

手順

  1. Gemfileにruby-profを追加

    group :profile do
      gem 'ruby-prof'
    end
    
  2. config.ruにprofの設定追加

    if Rails.env.profile?
      use Rack::RubyProf, :path => 'tmp/profile',
        :printers => {
          ::RubyProf::FlatPrinter => 'flat.txt',
          ::RubyProf::GraphPrinter => 'graph.txt',
          ::RubyProf::GraphHtmlPrinter => 'graph.html',
          ::RubyProf::CallStackPrinter => 'call_stack.html',
          ::RubyProf::CallTreePrinter => 'call_grind.txt',
        }
    end
    
  3. RAILS_ENV=profileの設定は適宜developmentあたりをコピーして作成。

  4. サーバを起動して、問題のページにアクセスする。

    ./bundle/bin/spring rails s -p 3001 -e profile
    
  5. tmp/profile/-call_grind.txtが生成されているのでqcachegrindに読み込ませる。

  6. Incl.やSelfの値の大きいところを目安にして、実際に遅い処理の部分を探す