Openshiftでアプリケーションがどのように起動されたかについて話をしたいと思います。 また、プレイの過程で、Openshift内のアプリケーションを管理するためのユーティリティを検討します。 これは、 kubernetes SPBミートアップ＃3でのパフォーマンスの転写です。
目的
通常、クライアントは別々のサーバーにデプロイされますが、ここでは、openshiftで実行してレーキを収集する可能性をテストするタスクが来ました。
最初に、アプリケーションについて説明する必要があります。 豊かな歴史を持つプロジェクト。 大規模な組織で使用されており、おそらく各自が間接的に交差しています。 アプリケーションは、多くのデータベース、統合などをサポートします。
前提条件
アプリケーションは、まったく異なる環境で動作するはずです。 その結果、インストールドキュメントは非常に広範囲に渡ります。 しかし、あなたを見下していれば、複雑なことは何もありません：
- データベーススキーマを適用します。
- アプリケーションサーバーを構成します。
- ライセンスをインストールします。
- アプリケーションと外部システムとの統合をカスタマイズします。
しかし、世界は残酷であり、多くの制限がありました。
- アプリケーションは、署名に従事しているJenkinsでのみ構築できます。 そしてそこだけ。
- Openshiftクライアントから開発環境へのアクセスはありません。
- 多くのイデオロギー上の理由により、既存のDockerイメージを開発用に再利用することはできませんでした。
- サーバーにアプリケーションをインストールおよび構成するためのansibleプレイブックがあります。
Ansible-containerデモ
Ansible Containerは、コンテナーの組み立て、展開、およびプロセス制御の自動化を目的としたオープンソースソフトウェアです。 名前から推測できるように。 Ansibleはコンテナの構築に使用されます。 サーバー上にアプリケーションをインストールおよびデプロイするためのAnsibleロールをすでに作成したため、ホイールを再発明して再利用しないことにしました。 完璧なツールであるだけでなく、既存の役割をすばやく再利用できることがデモの決定的な要因でした。
概して、デモを行うために、すべてを構成する既存の役割を引き受け、「モノリシックコンテナー」を作成しました。 コンテナの収集に特別な問題はありませんでした。 Openshiftには優れた推奨事項がいくつかありますが 、個別に言及します。
- 役割を完成させる必要がありました。 systemdを使用します。
- デフォルトでは、セキュリティ上の理由から、openshiftでsyscallを使用することは禁止されています。 その結果、chroot、sudoには微妙な違いがあります。 こんにちはCVE-2019-5736
- 同様に、セキュリティ上の理由から、コンテナはランダムIDを持つユーザーの下から起動されますが、これもカスタム動作です。
この時点での主なアイデアは、デモをすっきりさせたということです。
複数コンテナのデモ
デモコンテナーはその役割を果たし、別のコンポーネントに分割しました。
- 私たちのアプリケーション。
- データベース。
- 外部サービスなど...
最初に遭遇したのは、データベースを初期化する方法ですか？ 移行を使用することは明らかですが、いつ、どのように適用するのですか？ ここでは、デバイスPODを説明するすばらしい記事へのリンクを与える価値があります： PODの寿命 。 概して、いくつかのアプローチがあります。
- init-containerを使用する
- サービスの展開の順序を決定し、必要に応じて移行を移行するオーケストレーションシステムを使用します。
Init-containerパスに従うことにしました。 つまり アプリケーションのPODでは、アプリケーションの開始前に、移行をロールするコンテナーが開始されます。 しかし、アプリケーション自体と外部統合を構成する方法は？
アプリケーションを初期化する
すでに述べたように、私たちのアプリケーションは、異なるデータベースと統合を備えた完全に異なる環境で動作することができ、動作するはずです。 繰り返しますが、問題はそれをすべて設定する方法ですか？
- サービスが展開される順序を決定し、アプリケーションの起動後に構成を適用するオーケストレーションシステムを使用します。
- 環境変数を構成方法をコンテナに渡します。
- 開始フックを使用します。
- 構成を含む別のコンテナーを作成し、それをアプリケーションに適用します。 データベースの大まかなアナログ移行。
最後のアプローチを選んだのは、 これにより、構成を再現可能かつ自立させることができます。 しかし、何らかの理由で、最初にこのコンテナを1の係数を持つ別のレプリケーションコントローラで作成しました。
OK、もう一度ドキュメントを読んでください。
ポッド（クジラのポッドやエンドウ豆のポッドなど）は、共有ストレージ/ネットワークを備えた1つ以上のコンテナ（Dockerコンテナなど）のグループであり、コンテナの実行方法の仕様です。
PODはコンテナのグループです 。 その結果、潜水艦は3つのコンテナで構成されていました
- PostgreSQLを初期化するコンテナを初期化します。
- アプリ付きコンテナ。
- アプリケーション構成のあるコンテナー。
ツールキット
デプロイされたアプリケーションの外観図を取得しました。 自然の中でツールについて議論する時が来ました。すでに準備が整っているものがたくさんあります。以下のリストのいくつかを検討し、主観的な結論を導きます。
- Openshiftテンプレート
- bash / python / ruby + ymlテンプレート
- Terraform k8sプロバイダー
- アンシブルコンテナ
- Ansible + k8sモジュール
- Ansible Playbookバンドル
- アンシブルベンダー
- オペレーター
- source2image
- カスタマイズする
- 舵取り
- オートメーションブローカー
Openshiftテンプレート
長所：
- ネイティブで、優れたドキュメントがあります。
短所：
- 別のテンプレートエンジン。
- 長くてひどいYAMLファイル。
- サービスとその開始順序の間に依存関係がある場合、それは困難になります。
スクリプトとテンプレート
長所：
- 優れたツールとOOPのすべてのパワーを使用できます。
短所：
- サポートする松葉杖。 そしてあなただけではありません。
Terraform k8sプロバイダー
長所：
- インフラストラクチャ要素を作成する優先順位について心配する必要はありません。
- インフラストラクチャコードをモジュールとして再利用できます。
- アプリケーションの初期化ロジックを追加できます。
短所：
- OpenShiftのサポートなし、k8のみ。
- 時々古いドックとモジュール。
- あなたのチームの別のトゥーラ。
アンシブルコンテナ
長所：
- CMを作成、bashなし
- コードをロールとして再利用できます。
- 私たちの場合、すべてのための1つのツールです。
短所：
- 巨大な画像、なぜなら 1つのレイヤーに移動します。
- 放棄され、サポートされていないように見えます。 Ansible benderに置き換えられました。
Ansible k8sモジュール
長所：
- Openshift内のすべてのプロジェクトインフラストラクチャを説明する1つのプレイブック。
- ロールの形でコードを再利用します。
- アプリケーションの初期化ロジックを追加できます。
短所：
- プロキシはサポートされていません。
- 削除の世話をします。 オブジェクトが不要になった場合は、その削除について説明してください。
- あなた自身がインフラストラクチャ要素を作成するシーケンスを説明します。
Ansible Playbookバンドル
Ansible Playbook Bundle （APB）ユーティリティはアプローチを提供します：k8s / openshift内のアプリケーションをコンテナーにデプロイし、k8s / openshift内で実行するためのansibleロールをパックしましょう。
長所：
- 私はすべてを持ち歩いています。
- テスト可能で再現可能。
- サービスカタログとの統合（アプリケーションを起動するための使いやすいWebインターフェイス）。
短所：
- 管理者レベルの権限が必要です。
- ドキュメンテーションには、多くのことが望まれることがあります。
結果
私は最後の手段になりたくありませんが、結論を共有します。
- アプリケーションをサービスとして提供する予定がない場合は、 Ansible k8sモジュールが選択されます。
- ただし、必要な場合は、 オートメーションブローカーとAnsible Playbook Bundleについて掘り下げる必要があります。