specコマンドを実行すると、オールグリーンでテストが終了します。※webserverのapacheを止めたり、アンインストールしたりすると、それぞれテストが失敗するので、やってみてください。前置きが長くなってしまったので、serverspecが実行している処理の中身や、制御方法については次回解説します。前回に引き続き、AWS環境周りのテスト。awspecgithub.comという、AWSリソースのテスト(assertion機能付き)フレームワークがあると教えてくれたので、早速使ってみた。2.4.2ゴールこんな感じのセキュリティグループを以下の観点でテストしてみたい。awspecをインストールするだけなので省略。したいところだが、ただ実行するだけだと、公式ドキュメントの丸パクリ(というか劣化版)になってしまう。インフラエンジニアの端くれとして多少の差別化をはかり、(申し訳程度に)Vagrantfileを添付することにする。実行して、credentialを登録。下記のように記述すれば準備完了。下記のように記述する。実行すればテスト完了。下記のようにオールグリーンのコンソールが出ればO.K.やってること記述や実行方式は、serverspecやrspecと同じ。用いて、タグのチェックを行っている。用いて、22番ポートは、10.10.10.10/32から「のみ」アクセスを許可していることをチェックしている。対してアクセスを許可していることをチェックしている。感想serverspecに慣れ親しんでいる身としては、この方式(環境も)でテストが書けるのはうれしい。「余計なものが許可されていない」ことを確認するのは難しかった。セキュリティグループに限らず、テストの範囲をEC2インスタンスの内部だけでなく、リソース全体に広げることができるので、テストの質が上がりそう。リソース作成の動作確認2.motoでboto3スクリプトの自動テスト(テストフェーズ)3.awspecでリソース作成確認4.serverspecでサービスの動作確認どのツールがどの程度まで品質を担保できるものなのかは、もうちょっと使ってみてからまたブログに書きます。許可しているかどうかテストすると、感覚的にはテスト成功しそうだが、実際はテスト失敗になる。be_opened(3389).protocol('tcp').for('0.0.0.0/0')}end。こんな「ポリシーがあるのかないのかよくわからないセキュリティポリシー(笑)」をテストするようなこともないだろうし、あったとしても、本来NGになるべきものがOKになっているわけではないので、無視していいでしょう。前回、LocalStackを使ってboto3のテストを実行してみて、リソース操作系スクリプトの動作確認を気軽に行えるようになった。あったりと、現場で使うにはまだ改善点が多いことが分かったので、別の方法も考えてみることに。github.com、、、というboto3のエミュレートを行えるライブラリを発見したので、使ってみた。スクリプトのテストを考えてみる。バケットを作成します。テストするには、下記のようなテストを書く。デコレータを付与すること。関連の操作がすべてモック化される。正常系のテストtest_mainでは、S3バケットが一つも存在しない空間にS3のバケットを作成しにいくので、正常終了する。実行しているので、ClientErrorが発生して異常終了する。異常系のパターンをすべて網羅しているわけではない。エラーが発生するパターンがエミュレートできない。motoを使わずスクリプトを2回実行する(すでに存在するバケットを再度作成する)と、BucketAlreadyExists(他の人が使っている)ではなく、BucketAlreadyOwnedByYou(自分がすでに所有している)エラーが発生するべきである。BucketAlreadyOwendByYouのエラーを発生させることはできなさそう。)そのため、create_bucketを行う前に、同名のバケットが存在しないか事前チェックを行うなど、実装側の方でカバーしたり、テストの書き方を工夫する必要がある。LocalStackとの住み分けこのぐらい単純なスクリプトのテストだと、motoの方が簡単にテストできるので優れていそうだが、大量のリソースを操作するスクリプトや、CloudFormationの動作確認などでは、ダッシュボード機能でリソースの状態を確認できるLocalStackの方が活躍する場面が増えてくる(と思う)どちらもまだ使いこなせていないので、引き続き学習していきます。CLIを使っているのだが、動作確認するだけで自分の環境が汚れてしまうのがどうも気にくわない。単体テストを回して品質を担保したいが、一番重要なAWSコマンド実行の部分を動作させられないといまいち。環境を汚さず品質担保するうまい方法はないかプロに聞いてみたら、LocalStackというのがあるからやってみれ、とのことだった。ゴールWindowsのVirtualBox上に、LocalStackのサーバーを立てて、LocalStackに向けてS3のバケット作成コマンド実行する。アクセスして、下記のような画面(ダッシュボード)が表示されれば、LocalStackの構築は完了。bucketを実行する以下のようなPythonコードを実行する。boto3のインストール方法については割愛。LocalStackのダッシュボードを確認すると、S3のバケット作成が行われたことが確認できる。インストールとコンテナの構築を実施。仮想マシンのポートとつなげておけば、仮想マシンのポートをエンドポイントに指定するだけで応答を返してくれる。(ダッシュボードは8080)vagrantが使える環境であれば割と簡単に実行できる。LocalStackを向いて、本番実行するときは所望の環境に向いてくれるように設定するのが好ましい。やり方についてはこれから検討予定。bash動機サーバープロビジョニングにansibleやchefを使う前準備として、hostサーバーの公開鍵を複数台のスレーブノードに配布する必要がある。サーバーの数が増えてくると、手順書を作ったり、実行したりするだけでもかなりの時間を食ってしまう。目的ansibleやchefのスレーブノードに、hostサーバーの公開鍵をコマンド1発で配布できるようにする。(あと、手順書を簡略化する。CentOS7.2前提クライアントから各スレーブノードにsshのパスワード認証ログインができる。クライアントPCでbash,ssh,sshpassが使える。Bashのapt-getでインストールできる。)結論sshリモートコマンドでばらまく。Windows10からはコマンドプロンプトからbashが使えるので、下記のようなBashスクリプトを書いて実行する。(ネットワーク設定が適切にされていれば、VirtualBox上のLinux仮想マシンでも同様のことができるはず。プロビジョニングツールホストで作成した公開鍵。ログインするユーザーと、スレーブノードのユーザーが異なる場合は、こんな感じ。変数に公開鍵情報を格納し、sshリモートコマンドで、authorized_keysに追記リダイレクトしている。環境変数が初期化された後に調整する必要があるため、ヒアストリングでコマンドを渡すようにしている。踏み台サーバーを経由するような構成の場合は、少し変更が必要。踏み台サーバーからスレーブノードへssh公開鍵認証が設定済みの場合sshの公開鍵認証が通っているような構成であれば、sshpassを使わず、同様のコマンドで鍵をばらまくことができる。userSERVER踏み台サーバーからスレーブノードへパスワード認証でログインする構成で、かつ、rbashでコマンド制限されている場合。この場合は、ターミナルのマクロを使って実行する必要がある。踏み台サーバーからログインできなくなって大変なことになるので、扱いは慎重に。プログラムを拡張してください。確認手順を差し込みたい場合がある。できると便利だったりする。中で、次のecho文を実行するか、中断するか、確認を求めてくれる。文でヒアドキュメントを読み込んで順次処理を実行している中で、select文を読み込んであげているだけなのだが、一つだけ注意しなければいけない点がある。read文の中でselect文を実行しても、キーボードからの入力を求めてくれないばかりか、ループ処理もparam1を処理しただけで終わってしまう。<<PARAMによって、ヒアドキュメントに切り替えられているために起きる現象である。select文を実行するときに、あらかじめ複製しておいたファイルディスクリプタを指定してあげれば、select文の実行時にキーボードから入力を求めてくれるようになる。コミットするかロールバックするか確認を取ってくれるようになる。標準出力にSQLを出力するoutput_sql上で作ったsample.shを、下記のように、psqlコマンドに渡してあげれば、psqlで順次SQLを実行してくれる。DBNAME下記のような選択肢が出てくるので、コミットして続行する場合は1を、ロールバックして終了する場合は2を選択する。tbl1;みたいなコマンドを入力すると、その通り実行してくれる。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。