3.2.4. Git のコードベースのインポートおよびアプリケーションの作成
Developer パースペクティブを使用し、GitHub で既存のコードベースを使用して OpenShift Container Platform でアプリケーションを作成し、ビルドし、デプロイすることができます。
以下の手順では、Developer パースペクティブの From Git オプションを使用してアプリケーションを作成します。
手順
- +Add ビューで、Git Repository タイルの From Git をクリックし、Import from git フォームを表示します。
-
Git セクションで、アプリケーションの作成に使用するコードベースの Git リポジトリー URL を入力します。たとえば、このサンプル nodejs アプリケーションの URL
https://github.com/sclorg/nodejs-exを入力します。その後、URL は検証されます。 オプション: Show Advanced Git Options をクリックし、以下のような詳細を追加できます。
- Git Reference: アプリケーションのビルドに使用する特定のブランチ、タグ、またはコミットのコードを参照します。
- Context Dir: アプリケーションのビルドに使用するアプリケーションのソースコードのサブディレクトリーを指定します。
- Source Secret: プライベートリポジトリーからソースコードをプルするための認証情報で Secret Name を作成します。
オプション:
Devfile、Dockerfile、Builder Image、またはServerless Functionが Git リポジトリーからインポートして、デプロイをさらにカスタマイズできます。-
Git リポジトリーに
Devfile、Dockerfile、Builder Image、またはfunc.yamlが含まれている場合は自動的に検出され、それぞれのパスフィールドに入力されます。 -
Devfile、Dockerfile、またはBuilder Imageが同じリポジトリーで検出された場合は、デフォルトでDevfileが選択されます。 -
Git リポジトリーで
func.yamlが検出されると、Import Strategy がServerless Functionに変更になります。 - または、Git リポジトリー URL を使用して +Add ビューでサーバー Create Serverless function をクリックして、サーバーレス関数を作成することもできます。
- ファイルのインポートタイプを編集して、別のストラテジーを選択し、Edit import strategy オプションをクリックします。
-
複数の
Devfiles、Dockerfiles、またはBuilder Imagesが検出された場合、特定のインスタンスをインポートするには、コンテキストディレクトリーからの相対パスをそれぞれ指定します。
-
Git リポジトリーに
Git URL の検証後に、推奨されるビルダーイメージが選択されて星マークが付けられます。ビルダーイメージが自動検出されていない場合は、ビルダーイメージを選択します。
https://github.com/sclorg/nodejs-exGit URL の場合、Node.js ビルダーイメージがデフォルトで選択されます。- オプション:Builder Image Version ドロップダウンリストを使用してバージョンを指定します。
- オプション:Edit import strategy を使用して、別のストラテジーを選択します。
- オプション:Node.js ビルダーイメージの場合、Run command フィールドを使用して、アプリケーションを実行するためにコマンドを上書きします。
General セクションで、以下を実行します。
-
Application フィールドに、アプリケーションを分類するために一意の名前 (
myappなど) を入力します。アプリケーション名が namespace で一意であることを確認します。 Name フィールドで、既存のアプリケーションが存在しない場合に、このアプリケーション用に作成されたリソースが Git リポジトリー URL をベースとして自動的に設定されることを確認します。既存のアプリケーションがある場合には、既存のアプリケーション内でそのコンポーネントをデプロイしたり、新しいアプリケーションを作成したり、またはコンポーネントをいずれにも割り当てない状態にしたりすることができます。
注記リソース名は namespace で一意である必要があります。エラーが出る場合はリソース名を変更します。
-
Application フィールドに、アプリケーションを分類するために一意の名前 (
Resources セクションで、以下を選択します。
- Deployment: 単純な Kubernetes スタイルのアプリケーションを作成します。
- Deployment Config: OpenShift Container Platform スタイルのアプリケーションを作成します。
Serverless Deployment: Knative サービスを作成します。
注記アプリケーションをインポートするためのデフォルトのリソース設定を設定するには、User Preferences
Applications Resource type フィールドに移動します。Serverless Deployment オプションは、OpenShift Serverless Operator がクラスターにインストールされている場合にのみ、Import from Git フォームに表示されます。Resources セクションは、サーバーレス関数の作成時には利用できません。詳細は、OpenShift Serverless のドキュメントを参照してください。
Pipelines セクションで、Add Pipeline を選択してから Show Pipeline Visualization をクリックし、アプリケーションのパイプラインを表示します。デフォルトのパイプラインが選択されますが、アプリケーションで利用可能なパイプラインの一覧から必要なパイプラインを選択できます。
注記次の基準が満たされている場合、Add pipeline チェックボックスがオンになり、Configure PAC がデフォルトで選択されます。
- パイプラインオペレーターがインストールされています
-
pipelines-as-codeが有効になっています -
.tektonディレクトリーが Git リポジトリーで検出される
Webhook をリポジトリーに追加します。Configure PAC がオンになっており、GitHub アプリがセットアップされている場合は、Use GitHub App と Setup a webhook オプションが表示されます。GitHub アプリケーションがセットアップされていない場合は、Setup a webhook オプションのみが表示されます。
-
Settings
Webhooks に移動し、Add webhook をクリックします。 - Payload URL を Pipelines as Code コントローラーのパブリック URL に設定します。
- コンテンツタイプを application/json として選択します。
-
Webhook シークレットを追加し、別の場所に書き留めます。
opensslがローカルマシンにインストールされた状態で、ランダムなシークレットを生成します。 - Let me select individual events をクリックし、Commit comments、Issue comments、Pull request、および Pushes のイベントを選択します。
- Add webhook をクリックします。
-
Settings
オプション: Advanced Options セクションでは、Target port および Create a route to the application がデフォルトで選択されるため、公開されている URL を使用してアプリケーションにアクセスできます。
アプリケーションがデフォルトのパブリックポート 80 でデータを公開しない場合は、チェックボックスの選択を解除し、公開する必要のあるターゲットポート番号を設定します。
オプション: 以下の高度なオプションを使用してアプリケーションをさらにカスタマイズできます。
- Routing
Routing のリンクをクリックして、以下のアクションを実行できます。
- ルートのホスト名をカスタマイズします。
- ルーターが監視するパスを指定します。
- ドロップダウンリストから、トラフィックのターゲットポートを選択します。
Secure Route チェックボックスを選択してルートを保護します。必要な TLS 終端タイプを選択し、各ドロップダウンリストから非セキュアなトラフィックに関するポリシーを設定します。
注記サーバーレスアプリケーションの場合、Knative サービスが上記のすべてのルーティングオプションを管理します。ただし、必要に応じて、トラフィックのターゲットポートをカスタマイズできます。ターゲットポートが指定されていない場合、デフォルトポートの
8080が使用されます。
- ドメインマッピング
Serverless Deployment を作成する場合、作成時に Knative サービスにカスタムドメインマッピングを追加できます。
Advanced options セクションで、Show advanced Routing options をクリックします。
- サービスにマッピングするドメインマッピング CR がすでに存在する場合は、Domain mapping のドロップダウンメニューから選択できます。
-
新規ドメインマッピング CR を作成する場合は、ドメイン名をボックスに入力し、Create オプションを選択します。たとえば、
example.comと入力すると、Create オプションは Create "example.com" になります。
- ヘルスチェック
Health Checks リンクをクリックして、Readiness、Liveness、および Startup プローブをアプリケーションに追加します。すべてのプローブに事前に設定されたデフォルトデータが実装され、必要に応じてデフォルトデータでプローブを追加したり、必要に応じてこれをカスタマイズしたりできます。
ヘルスプローブをカスタマイズするには、以下を実行します。
- Add Readiness Probe をクリックし、必要に応じてコンテナーが要求を処理する準備ができているかどうかを確認するためにパラメーターを変更し、チェックマークを選択してプローブを追加します。
- Add Liveness Probe をクリックし、必要に応じてコンテナーが実行中かどうかを確認するためにパラメーターを変更し、チェックマークを選択してプローブを追加します。
Add Startup Probe をクリックし、必要に応じてコンテナー内のアプリケーションが起動しているかどうかを確認するためにパラメーターを変更し、チェックマークを選択してプローブを追加します。
それぞれのプローブについて、ドロップダウンリストから要求タイプ (HTTP GET、Container Command、TCP Socket) を指定できます。選択した要求タイプに応じてフォームが変更されます。次に、プローブの成功および失敗のしきい値、コンテナーの起動後の最初のプローブ実行までの秒数、プローブの頻度、タイムアウト値など、他のパラメーターのデフォルト値を変更できます。
- ビルド設定およびデプロイメント
Build Configuration および Deployment リンクをクリックして、それぞれの設定オプションを表示します。オプションの一部はデフォルトで選択されています。必要なトリガーおよび環境変数を追加して、オプションをさらにカスタマイズできます。
サーバーレスアプリケーションの場合、Deployment オプションは表示されません。これは、Knative 設定リソースが
DeploymentConfigリソースの代わりにデプロイメントの必要な状態を維持するためです。
- スケーリング
Scaling リンクをクリックして、最初にデプロイするアプリケーションの Pod 数またはインスタンス数を定義します。
サーバーレスデプロイメントを作成する場合、以下の設定を行うこともできます。
-
Min Pods は、Knative サービスである時点で実行する必要がある Pod 数の下限を決定します。これは、
minScale設定としても知られています。 -
Max Pods は、Knative サービスである時点で実行できる Pod 数の上限を決定します。これは、
maxScale設定としても知られています。 - Concurrency target は、ある時点でアプリケーションの各インスタンスに対して必要な同時リクエストの数を決定します。
- Concurrency limit は、ある時点でアプリケーションの各インスタンスに対して許容される同時リクエストの数の制限を決定します。
- Concurrency utilization は、Knative が追加のトラフィックを処理するために追加の Pod をスケールアップする際に満たす必要のある同時リクエストの制限のパーセンテージを決定します。
-
Autoscale window は、Autoscaler がパニックモードではない場合に、スケーリングの決定を行う際のインプットを提供するためにメトリクスの平均値を計算する期間を定義します。この期間中にリクエストが受信されなかった場合、サービスはゼロにスケーリングされます。Autoscale window のデフォルト期間は
60sです。これは stable window としても知られています。
-
Min Pods は、Knative サービスである時点で実行する必要がある Pod 数の下限を決定します。これは、
- リソースの制限
- Resource Limit リンクをクリックして、コンテナーが実行時に保証または使用が許可されている CPU および メモリー リソースの量を設定します。
- ラベル
- Labels リンクをクリックして、カスタムラベルをアプリケーションに追加します。
- Create をクリックしてアプリケーションを作成し、成功の通知が表示されます。Topology ビューでアプリケーションのビルドステータスを確認できます。