ITコミュニティの皆さん、こんにちは。 私の名前はオレグです。ソフトウェアを開発する会社で働いています。 LinuxおよびUnix製品の手動および自動テストに携わっています。OpenshiftOriginでの自動テストの良い経験を共有したいと思います。
私が追求する目標 ：
- ロシア語圏のコミュニティに、テストのコンテキストでOpenshift Originを使用する機能を伝えます。
- コンテナでのテストの長所と短所について話します。
- Kubernetes / Openshiftの知識を集約して更新します。
すべての資料は3つの記事に記載されています 。
注：提示された資料は、Openshift v2ではなくOpenshift v3に関するものであることにすぐに気付きます（Red HatがKubernetesを製品およびサービスのカーネルとしてまだ使用していない場合）。
Openshift Originが選ばれた理由 ：
そのため、現在の職場での雇用後、原則として自動テストが行われていないことが判明しました。 手動モードで数か月働いた後、テスト環境を展開およびサポートするためのツール、テストを記述するためのフレームワークの2つの必要性について理解しました。
最初の段階では、自動更新されたVagrantリポジトリ（ VirtualBox ）が編成され、環境を展開およびサポートし、さまざまなOSを自動モードで更新およびパックしました。 これは、テストだけでなく開発の助けにもなりました。なぜなら、開発された要件に従って仮想マシンが構成されたためです。 仮想マシンが更新され、必要なツールがプレインストールされました。 複雑な環境を展開するためのVagrantスクリプトがありました。 すべてのVagrant環境は、ワークステーションのパフォーマンスの問題を引き起こすと予想されていた専用のIaaSではなく、開発参加者のローカルマシンにデプロイされることに注意してください。
時間が経ち、作業がより便利になり、特定の標準と予測可能性が現れましたが、主な問題は残っていました-テスト環境（完全仮想化、さまざまなLinuxディストリビューション、追加サービス（テストに関与））の長期展開です。 テスト環境の展開には数十分かかり、テスト自体は数秒で完了しました。 同時に、自動化されたテストの数が増加し、結果の待機時間が長くなりました。
論理的な問題は、すべてのテストタスクが行われる別個のIaaSの組織でしたが、このアプローチは理想的ではありませんでした：完全な仮想化を引き続き使用し、IaaSはハードウェアを購入するために金銭的投資を必要とします（弱いワークステーションの小さなフリートが存在しました） 。
次のステップは、新しい要件、つまり（優先度に応じた基本的な）を考慮に入れた高速な（環境のパフォーマンスの観点から） CI / CDの開発でした。
- ソフトウェアを購入する費用なしのオープンソースソリューション。
- テスト環境の高速展開。 環境間のサービスの存在の接続性と認識。 環境内でのテスト実行の組み込みサポートと制御。 パラグラフ4を満たす高密度
- アクティブなコミュニティ、予測可能な未来、所有者の評判、ドキュメントを備えた人気のあるプロジェクト。
- ハードウェアへの追加投資の欠如。
適切な製品を見つけるための厄介な道を詳細に改めて説明することで読者を悩ませることはありませんが、レビューされたソフトウェアのリストに精通したいと思います（2016年2月）：
- 完全な仮想化の置き換え： Docker 、 LXC 、 OpenVZ 、 kvmtool 。
- オーケストレーションとクラスター管理： Kubernetes 、 Nomad 、 Openshift 、 Openstack 、 Swarm 。
- Jenkinsサポート： Dockerプラグイン 、 Kubernetesプラグイン 、 Openshiftプラグイン
一部のツールは管理が不十分であるか、サポートとメンテナンスが多すぎます。他のツールはジェンキンスとの統合が不十分で、必要な機能を提供していませんでしたが、他のツールはまだ始まったばかりです。 明確なリーダーはKubernetesとその派生物（多くあります）を迫りましたが、Googleのプラットフォームは純粋な形で学習と展開が困難でした（開発者はこのプラットフォームの使用を簡素化するために多大な努力を払っています）。
Openshift Originについてのあなた自身の言葉で：
Openshift Originは、主にKubernetesコンテナオーケストレーションプラットフォームに基づくオープンソースソフトウェア開発および公開プラットフォームです。 プラットフォームは、特別なオブジェクトとメカニズムの助けを借りてKubernetesを拡張します。
クラスター：
Ansibleスクリプトを使用して、クラスターをデプロイまたは更新できます。 クラスター内では、組み込みDockerレジスタと外部Dockerレジスタの両方を使用できます。 クラスターノードは、特別なラベルに基づいて個々のプロジェクトに割り当てることができます。 ガベージコレクタとカスタムスケジューラがあります。 クラスターはOpenstack内にデプロイし、クラスターと統合して、データストレージを自動的に拡張および提供できます。 環境は、環境変数とDNS名を使用して、公開されたサービスと他のノードを認識できます。 HTTP / TCPリクエストおよび/またはコンテナ内のコマンドの実行により、サービスの可用性を確認することができます。 クラスターリソースは、プロジェクトレベル（プロセッサ、メモリ、オブジェクト数など）でクォータベースにすることができます。 コンテナおよび作業ノードのレベルでクラスターを監視する機能があります。
データ：
コンテナに直接マウントされる一時ボリュームまたは永続ボリュームは、データストレージの方法として使用できます。 これらのボリュームのバックエンドには、 NFS、GlusterFS、OpenStack Cinder、Ceph RBD、AWS Elastic Block Store（EBS）、GCE Persistent Diskなどがあります。 コンテナが実行されている作業ノードのローカルディレクトリをマウントする可能性（hostPath）があります。
ネットワーク：
デフォルトでは、すべての通信はOpen vSwitchを使用して行われますが、Kubernetesプラグインシステムを介した他のネットワークソリューションのサポートがあります。 デフォルトでは、すべての環境が相互に通信できますが、プロジェクトレベルでの分離は可能です。 統合されたSkyDNSサービスを使用したサービス名のDNS解決をサポートしました。 クラスタ内で公開されたサービスは、外部からアクセスできる場合があります。 Iptablesは、 すべての分離機能とNAT機能を処理します。
安全性：
役割に基づいたユーザー権利の差別化。 SELinux （およびその他）を使用したコンテナの分離。 さまざまなリソースへのアクセスに使用されるシークレットのサポート。 クラスターの作業ノードとマスター間のすべての通信は、暗号化された接続を介して行われます（CAが作成され、クライアント証明書が発行されます）。
管理：
APIはOpenshiftとKubernetesの両方で使用できます。 クロスプラットフォームコンソールクライアントが利用可能です 。 Webインターフェースを使用して、ユーザーは以下を実行できます。隔離されたプロジェクトでの作業、権限の考慮、クラスターで実行されているコンテナーとの対話、作成されたオブジェクトの表示、イベントの追跡など。
結論：
市場で入手可能な技術と製品が豊富にあるにもかかわらず、適切なツールを見つけることは非常に困難です。 CI / CDプロセスの統合と統合のバランスをとり、メンテナンスの複雑さ、関連するテクノロジーチェーンの追跡、Kubernetes、そしてOpenshift Originが見つかりました。 Kubernetesコンテナを使用したオーケストレーションの基本プラットフォームとは異なり、Openshiftは便利で効率的な作業に必要な要素を提供します。