これは、Openshift Originでのソフトウェア製品の自動テストに特化した一連の3つの記事（ 最初の記事 、 2番目の記事 ）の最後の部分です。 この記事では、コンテナでのテストの側面と、次のような製品の参加によるCI / CDの構築機能について説明します。
- Openshit Origin-テスト環境を展開するシステムとして。
- Jenkins-継続的インテグレーションのツールとして。
- テストリンク-テスト管理システムとして。
Robot Framework-テストを記述するためのフレームワークとして。
代表性を高めるために、上記の製品から事前に構成された環境を含むVagrantイメージを準備しました（この記事にリストされているすべてのオブジェクトとメカニズムは簡単に検査できます）。 素材の理解度を高めるために、アセンブリタスクとテストタスクの2つのタスクを作成しました。 両方のタスクはステージに分割され、詳細に説明されています。
クイックスタート：
- Vagrant ImageおよびVagrantfileの ダウンロード
vagrant box add --name viewshift viewshift-1.0.box && vagrant up
本格的な環境を作成することは私の計画の一部ではありませんでしたが、ミニシフトをdockerコンテナーにリンクするいくつかのシナリオを失った後、私はそれがカテゴリー的に不便でエラーがたくさんあることに気付きました。 読者の想像力を単一のテキストで訓練するために、私はそれを無駄な練習だと考えています。
デフォルトでは、環境はグラフィカルモードで起動します。 これは、外部からの製品へのアクセスに関する問題を回避するために行われます。 自動ユーザーログインを構成しました。 カスタムFirefoxには、製品にアクセスするためのブックマークと資格情報が保存されています。
システムユーザーuserおよびvagrantには、無制限のsudoアクセスがあります。
関連するソフトウェア：
| 役職 | バージョン | クレデンシャル |
|---|---|---|
| オープンシフト | 1.5.1 | 管理者：管理者 |
| ジェンキンス | 2.60.1 | 管理者：管理者 |
| テストリンク | 1.9.16 | 管理者：管理者 |
| ゴグ | 11/0 / 19.0609 | git：git |
| マリアド | 5.5.52 | ルート：ルート |
| OpenShift Pipeline Jenkinsプラグイン | 1.0.47 | - |
| Testlinkプラグイン | 3.12 | - |
| Robot Frameworkプラグイン | 1.6.4 | - |
| ビルド後スクリプトプラグイン | 0.17 | - |
| システム | - | ルート：ルート |
| システム | - | ユーザー：ユーザー |
| システム | - | vagrant：vagrant |
SHA1：
0992d621809446e570be318067b70fe2b8e786b2 viewshift-1.0.box
組立作業：
ビルドタスクには、curlアプリケーションを使用したDockerイメージのビルドが含まれます。これは、後でテストタスクに参加します。
注： スーパーバイザーは 、コンテナーのルートプロセス（PID 1）として使用されます。 スーパーバイザーおよび他の同様のツールは、アプリケーションを完全にシャットダウンするか、プロセスをリモートで管理する必要がある場合に非常に役立ちます。
回路図：
ステージ ：
タスクに関与する変数を定義します。
PROJECTは、Openshiftプロジェクトの名前です。 このプロジェクトでは、ServiceAccount "jenkins"が作成されました。これはプロジェクトの管理者権限を持っています。 このServiceAccountは、Jenkinsからプロジェクトにアクセスするために使用されます（このアカウントはテストタスクでも使用されます）。
APP_NAMEとAPP_VERSIONはアプリケーションの条件付きの名前とバージョンですが、いくつかの場所に表示されます：結果のDockerイメージの名前とタグ、起動されたビルドの名前など。
必要な変数が定義された後（プロジェクト内のタスクの粒度/明確性が考慮された後）、それらをすべてのYAML Openshift構成および他のJenkinsステップに分散する必要があります。
この段階で、BuildConfigオブジェクトが作成され、それに基づいてBuildオブジェクトが作成および実行されます。
ビルドプロセスは、作成されたBuildConfigに基づいて開始されます。 成功した場合、結果のイメージは内部Dockerレジスターに配置されます。
アセンブリの成功に関係なく、作成されたオブジェクトはすべて削除されます。
テストの目的：
テストの目的は、HTTPプロトコルを介してnginxサービスと対話するcurlアプリケーションのテストプロセスです。 アプリケーションが正しく動作し、指定されたテストに合格することを確認する必要があります。
回路図：
ステージ ：
タスクに関与するパラメーターを決定します。
PROJECTは、Openshiftプロジェクトの名前です。
TESTPLAN - Testlinkのテスト計画の名前。 指定したテスト計画がTestlinkにない場合、タスクは失敗します。
APP_NAMEとAPP_VERSIONは、アプリケーションの条件付きの名前とバージョンであり、ビルドタスクでも同様に使用されます。
TEST_CMD-コンテナ内で実行される実行可能ファイルの名前を含む変数。 コマンドライン引数は、適切なJenkinsステップで指定されます。
TEST_TIMEOUT-コマンドがコンテナ内で完了するまで待機する時間を設定する数値式。 この時間が経過すると、Jenkinsタスクは実行をエラーで終了します。
ビルドタスクを参照してください。
この段階で、テストリンク構成が指定されます：どのサーバーに接続するか、どのテスト計画を使用するか（このテスト計画に割り当てられているすべてのテストは、テスト計画からダウンロードされ、その後の比較のために）、どのプラットフォームでテストが実行されたかなどd。 これはすべて、その後のTestlinkに渡されたテストの公開およびJenkinsでのテストレポートの直接表示に必要です。
このステップは、サービスを作成することを目的としています。 作成されたサービスは、後で起動されるアプリケーションを指します。 これらのサービスを通じて、アプリケーションの可用性が確認されます。
この時点で、「nginx」アプリケーション用のポッドが作成されます。
この時点で、curlアプリケーション用のポッドが作成されます。 このコンテナのイメージは、ビルドタスク中に作成されるイメージです。 「nginx」とは異なり、データボリューム「share」がこのイメージに追加され、コンテナーが作業ノードのファイルシステムと通信できるようになります。
すべてのポッドが作成された後、公開された初期サービスを介したアプリケーションの可用性チェックが必要です。
この段階で、テストコマンドがポッドで起動され、このコマンドの完了を待機します。
すべてのテストに合格すると、テストレポートがタスクスペースにコピーされ、その後Testlinkにインポートされます。
この段階では、合格したテストを、示された以前のテスト計画から得られたものと比較するための戦略が示されます（複数ある場合があります）。 この場合、テストケースの名前の単純な比較があります。 すべての操作後、テストレポートがTestlinkに公開されます。
Junit形式のTeslinkレポートに加えて、Robot Framework形式のテストレポートがあり、合格したテストのしきい値に基づいて完了したタスクのステータスを確立します。
この段階で、タスクの実行中に作成されたすべてのOpenshiftオブジェクトが削除されます。
すべて一緒に：
コンテナでのテストの長所と短所：
短所：
- Linuxのみ。 いわゆる「簡単な」仮想化が開発されており、おそらく状況の変化を期待する必要がありますが、これまでのところLinuxのみです。
- すべてのコンテナ用の単一のカーネルバージョン。 おそらくパラグラフ1
- X86_64のみ。 いいえ、もちろん、イメージはx86かもしれませんが、カーネルはx86_64になります。 一部の人にとって、これは障害になる可能性があります。
- ネストされたSELinuxの欠如（ ネストされたCGroupが存在します ）。
- 本格的なビデオデバイスの欠如と画面へのアクセス。 おそらく段落1
長所：
- 起動環境の速度と柔軟性、高密度。
- 統合されたアプリケーション配信、移植性、再現性。
結論：
Openshift Originを他のツールと組み合わせて使用すると、柔軟性と効率が大幅に向上します。 プロジェクト/オブジェクトのよく考えられた命名スキームにより、テストタスクの大量起動時のエラーを回避できます。
謝辞：
このような優れたプラットフォームを作成してくれたGoogleに感謝します。
素晴らしいプラットフォームで完成品を作ったRed Hatの従業員に感謝します。