なぜ展開したと確信しているのですか

何かが機能しない場合によく起こります。 そして、誰も彼のせいで何かが機能しないことを望みません。 大規模なインフラストラクチャおよび分散アプリケーションのコンテキストでは、構成エラーは致命的です。



この記事では、アプリケーションの環境を適切にテストする方法、使用するツールを示し、成功した適切なテストの例を示します。



この記事は、 DevOpsまたはSRE 、 Devを担当するチーム、およびその他の優秀な人々にとって興味深いものになります。



Infrastructure as Codeの概念はテストなしで実装できると言わなければなりません。 そして、それも機能します。 しかし、完璧には限界がありますか？



テストは開発の世界から私たちにやって来ました。テストはそのような実装オプションを含む非常に壮大なものです。

• 単体テスト （コードのテスト）-1つのパラメーターを入力として受け取り、計算を実行して結果を返す関数があります。 単位-結果が予想どおりであることを確認します。大まかに言えば、 1 == 1です。
• 統合テスト （コンポーネントの相互接続のテスト）-正しい操作のためのベースを必要とするアプリケーションがあり、その中に「 ユーザー」プレートがあります。 このテストでは、ベースがあり、プレートがあり、 すべてが動作する準備ができていることを確認します。
• システムテスト （アプリケーション全体のテスト）-アプリケーションがあり、ファイルを変換する必要があります。 テストでは、 アプリケーションが変換されていることを確認し、 結果 が私たちに合っていることを確認します 。
• 煙テスト （ユーザーの行動をシミュレート）- ユーザーがブラウザーでWebサイトを開き 、 ログインし 、画像をアップロードし、 変換 できることをテストします 。

そして、ここで、私たちの世界でAnsible / Chef / Puppet / Saltのすべてが非常に原始的であり、すべてが非常に単純であり、私たちのツールのエコシステムではそのような何かの実装がないという誤った認識が来るかもしれません。



しかし、どういうわけかそうではありません。



これはすべて、これはすべて長い間使用されており、成功しています。

テストするよりも

構成管理のための高度なプログラミングは考慮しないことをすぐに明確にします。 たとえば、 AnsibleモジュールまたはChef LWRPを作成した場合、作成内容を適切にテストする方法を理解するには知識が十分です。



実際、テストのために考慮されるすべてのフレームワークは非常に類似しており、既製のテストケースと構文のセットが異なります。



例の1つの問題をどこでも解決します。パッケージ ' apache2 'がインストールされ、サービス ' apache2 'が稼働中であることを確認する必要があります。 最後に、誰かがポート80でリッスンしていることを確認します。

ServerSpec

検討する最初のテストフレームワークはServerspecです。



使用例：

require 'spec_helper' describe package('apache2') do it { should be_installed } end describe service('apache2') do it { should be_enabled } it { should be_running } end describe port(80) do it { should be_listening } end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インスペック

2番目のフレームワークはInSpecです。

構文はServerspecと同じです。

Testinfra

3番目のフレームワークはTestinfraです。

 def test_apache_is_installed(Package): apache = Package("apache2") assert apache.is_installed def test_apache_running_and_enabled(Service): apache = Service("apache2") assert apache.is_running assert apache.is_enabled def test_apache_port(Socket): sock = Socket("tcp://80") assert sock.is_listening
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ゴス

4番目のフレームワークはGossです。

 package: apache2: installed: true service: apache2: enabled: true running: true port: tcp:80: listening: true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Serverspec / InSpec / Testinfra / Goss？

構文からわかるように、選択できるものはたくさんあります。 一番好きな人は誰でも使うのがベストです。 たとえば、 Chefがある場合、 InSpecまたはServerspecは完全に 落ちます。 AnsibleまたはSalt - TestinfraまたはGossがクールな場合。



すべての違いは既製のモジュールの有無です。最初のことは、フレームワークに必要な要件のリストを準備し、必要なもの（またはほとんどすべて）を備えたものを探すことです。



さて、選ばれました。 正確にテストするものは何ですか？

テストするもの

数週間前、 DevOpsコミュニティで 、何をテストする必要があるのか​​、何をテストする必要があるのか​​、Trappist-1に何年かかるのかなどについて話しました。



たとえば、 ctrlokは、宣言的なものをテストすることは正しくないと考えています。 そして私は彼に同意します。



私は間違いなくテストする必要がないことを予約します：

• さまざまな宣言的事項（パッケージの可用性、パッケージのバージョン、ファイルの存在）- 構成管理がこれらすべてを処理します。

テストする必要があるもの：

1. 一度/最近壊れたもの
2. 潜在的に壊れる可能性のあるもの
3. 誰か（ 同僚 ）が無知のために破ることができるもの
4. 何も確実に機能しないもの

1つの製品のコンテキストで多くのアプリケーションがあり、それらのすべてが通常の動作のために環境の微調整を必要とします。 最も厄介でボトルネックの1つは、さまざまなドキュメント形式の変換を行うアプリケーションでした。 数十のパッケージと数百のライブラリを使用していることを推測するのは難しくありません。依存するパッケージが更新されると、これらすべてが突然動作しなくなる可能性があります。



アプリケーションを適切に評価してテスト用に準備するには、テスターのように考える必要があります。 または、たとえば、 QAチームに相談します。



通信中に、メインのテストケースを熟考し、それらすべてをカバーするようにする必要があります。



実用例（アプリケーション上）：

• PDFからHTMLに変換
• htmlからpdfに変換
• doc / docxからpdfに変換

私たちの場合、個々のポイントは別々のアプリケーションモジュールであり、それがテスト方法です。

テストしてみましょう！

最初のアプリケーションモジュールのシステム統合テストの小さな例を示します。 pdf2htmlexコンソールユーティリティを正しくインストールする役割があることを明確にします。このユーティリティには、すべての依存関係と必要なものが明確に記述されています。 環境の展開プロセスが成功し、インフラストラクチャのテストの段階が始まったことを意味します。



まず、バイナリが利用可能であることを確認することをお勧めします。それを起動して、結果に何かを取得できます。

 # Validate binary exists and working describe bash('pdf2htmlEX --version') do its('stderr') { should match /pdf2htmlEX version 0.14.6/ } its('exit_status') { should eq 0 } end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、このバイナリが実際にテストドキュメントを変換できることをテストしてみましょう。結果は私たちに合っています。

 # Try to convert and validate result html describe bash('pdf2htmlEX /opt/test/pdf-sample.pdf /tmp/pdf-sample.html') do its('stderr') { should match /Working/ } its('exit_status') { should eq 0 } end describe file('/tmp/pdf-sample.html') do it { should exist } its('content') { should match /<!DOCTYPE html>/} its('size') { should eq 267189 } end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、テストが成功すると、PDFからHTMLへの変換を担当するアプリケーションモジュールが機能することを明確に宣言できます。 さらに、それは正しく動作し、その結果に満足しています。



そのようなテストを行うのは難しくて長いですか？ そうは思いません



これにより、ビジネスにどの程度の費用が節約できますか？ それぞれに独自のエラーがあります。

メリット

すぐに環境のテストを開始しなかったと言う価値があります。 なぜこのようなことに時間を浪費するのか-私たちはすべてスーパーマンであり、 構成管理のコードをエラーなしですぐに書くことは明らかですか？



そして、このアプローチは、DevOpsチームが1-2人で構成されている場合に機能します。 この場合、各エンジニアはアプリケーションの動作方法、環境の準備方法、および「突く」方法を知っています。準備したサイトでどのように動作するかを確認します。



すべてが本番環境で機能する必要があるときにすべてが終了しますが、機能しません。 デバッグプロセスは、実際の製品のロールバックまたはロールバックのロールバックから始まり、1分ごとにビジネスに非常に費用がかかります。



それがインフラテストが将来への投資である理由です。

さて、何かが壊れたとき、私たちの仕事の一部が100％完了したことを絶対に確信し、私たちの側からはすべての質問が閉じられます。

したがって、展開したばかりであると確信しています。

結論

正しく構成されたプロセス（CIおよびCD）により、非常に動的な世界で頻繁に変更されるアプリケーションを使用しています。 私たちはすべて、アプリケーション自体の作業について非常に真剣であり、すべての側面から同じことをテストします。 同時に、このアプリケーションが動作するインフラストラクチャを無視することはあまり合理的ではありません。 さらに、これには大きな影響が伴います。



私たち自身のために、そのような場合にテストすることにしました：

• システムモジュールに複雑なロジックがある場合 （複雑さ）
• モジュールが今すぐ壊れる場合（可用性）
• 特定の知識を伝達する必要がある場合（コミュニケーション）
• エラーがXのお金（ビジネス価値）以上の費用を要する場合

主なメッセージは、インフラストラクチャをテストすることの重要性を伝え、現時点ではなく、近い将来、これらのツールの使用を奨励することでした。



また、インフラストラクチャの何パーセントがテストでカバーされていますか？

PS情報があなたにとって有用であり、あなたがこの方向で発展したいなら-私の個人的な電報チャンネルを購読してください ： https : //goo.gl/1MnG9v

いつでも登録解除できます。 気に入ったらどうしますか？