アプリケーションのビルド

1. Developer パースペクティブで、Project ページに移動します。
2. Project メニューからプロジェクトを選択します。
3. Project Access タブを選択します。

4. Add access をクリックして、パーミッションの新規の行をデフォルトのパーミッションに追加します。

   図2.2 プロジェクトパーミッション

   
5. ユーザー名を入力し、Select a role ドロップダウンリストをクリックし、適切なロールを選択します。
6. Save をクリックして新規パーミッションを追加します。

手順

1. Administrator パースペクティブで、Administration → Cluster settings に移動します。
2. Configuration タブをクリックします。
3. Configuration resource リストから、Console operator.openshift.io を選択します。
4. YAML タブに移動し、YAML コードを表示し、編集します。

5. spec の YAML コードで、プロジェクトアクセスに使用可能なクラスターロールのリストをカスタマイズします。次の例では、デフォルトの admin、edit、および view ロールを指定します。

   apiVersion: operator.openshift.io/v1
   kind: Console
   metadata:
     name: cluster
   # ...
   spec:
     customization:
       projectAccess:
         availableClusterRoles:
         - admin
         - edit
         - view

6. Save をクリックして、Console 設定リソースへの変更を保存します。

検証

1. Developer パースペクティブで、Project ページに移動します。
2. Project メニューからプロジェクトを選択します。
3. Project access タブを選択します。
4. Role 列のメニューをクリックし、使用可能なロールが Console リソース設定に適用した設定と一致することを確認します。

手順

1. Developer パースペクティブで、+Add ページに移動します。
2. Project メニューからプロジェクトを選択します。
3. +Add ページで項目をクリックし、ワークフローに従います。

手順

1. cluster-admin 権限を持つユーザーとしてログインしている。

2. デフォルトのプロジェクトテンプレートを生成します。

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. オブジェクトを追加するか、既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。

4. プロジェクトテンプレートは、openshift-config namespace に作成される必要があります。変更したテンプレートを読み込みます。

   $ oc create -f template.yaml -n openshift-config

5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

   カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
   # ...
   spec:
     projectRequestTemplate:
       name: <template_name>
   # ...

7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

手順

1. cluster-admin 権限を持つユーザーとしてログインします。

2. 以下のコマンドを実行して、self-provisioners クラスターロールバインディングの使用を確認します。

   $ oc describe clusterrolebinding.rbac self-provisioners

   出力例

   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   self-provisioners セクションのサブジェクトを確認します。

3. self-provisioner クラスターロールをグループ system:authenticated:oauth から削除します。

   • self-provisioners クラスターロールバインディングが self-provisioner ロールのみを system:authenticated:oauth グループにバインドする場合、以下のコマンドを実行します。

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • self-provisioners クラスターロールバインディングが self-provisioner ロールを system:authenticated:oauth グループ以外のユーザー、グループまたはサービスアカウントにバインドする場合、以下のコマンドを実行します。

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. ロールへの自動更新を防ぐには、self-provisioners クラスターロールバインディングを編集します。自動更新により、クラスターロールがデフォルトの状態にリセットされます。

   • CLI を使用してロールバインディングを更新するには、以下を実行します。

     1. 以下のコマンドを実行します。

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. 表示されるロールバインディングで、以下の例のように rbac.authorization.kubernetes.io/autoupdate パラメーター値を false に設定します。

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
        # ...

   • 単一コマンドを使用してロールバインディングを更新するには、以下を実行します。

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. 認証されたユーザーとしてログインし、プロジェクトのセルフプロビジョニングを実行できないことを確認します。

   $ oc new-project test

   出力例

   Error from server (Forbidden): You may not request a new project via this API.

   組織に固有のより有用な説明を提供できるようこのプロジェクト要求メッセージをカスタマイズすることを検討します。

手順

1. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. cluster-admin 権限を持つユーザーとしてログインします。

     2. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

2. spec セクションを、projectRequestMessage パラメーターを含むように更新し、値をカスタムメッセージに設定します。

   カスタムプロジェクト要求メッセージを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
   # ...
   spec:
     projectRequestMessage: <message_string>
   # ...

   以下に例を示します。

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
   # ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.
   # ...

3. 変更を保存した後に、プロジェクトをセルフプロビジョニングできない開発者またはサービスアカウントとして新規プロジェクトの作成を試行し、変更が正常に適用されていることを確認します。

手順

1. Web コンソールのナビゲーションメニューの上部にあるコンテキストセレクターから Developer を選択します。
2. 目的のプロジェクト内で、+Add をクリックします。
3. Developer Catalog タイルの All services をクリックします。

4. Type の下の Builder Images をクリックして、利用可能なビルダーイメージを表示します。

   注記

   以下に示すように、builder タグがアノテーションにリスト表示されているイメージストリームタグのみがリストに表示されます。

   kind: "ImageStream"
   apiVersion: "image.openshift.io/v1"
   metadata:
     name: "ruby"
     creationTimestamp: null
   spec:
   # ...
     tags:
       - name: "2.6"
         annotations:
           description: "Build and run Ruby 2.6 applications"
           iconClass: "icon-ruby"
           tags: "builder,ruby" 1
           supports: "ruby:2.6,ruby"
           version: "2.6"
   # ...

   1

   ここに builder を含めると、このイメージストリームがビルダーとして Web コンソールに表示されます。

5. 新規アプリケーション画面で設定を変更し、オブジェクトをアプリケーションをサポートするように設定します。

手順

1. +Add ビューで、Samples タイルをクリックして Samples ページを表示します。
2. Samples ページで、利用可能なサンプルアプリケーションの 1 つを選択し、Create Sample Application フォームを表示します。

3. Create Sample Application Form:

   • Name フィールドには、デフォルトでデプロイメント名が表示されます。この名前は必要に応じて変更することができます。
   • Builder Image Version では、ビルダーイメージがデフォルトで選択されます。Builder Image Version ドロップダウンリストを使用してイメージバージョンを変更できます。
   • Git リポジトリー URL のサンプルは、デフォルトで追加されます。
4. Create をクリックしてサンプルアプリケーションを作成します。サンプルアプリケーションのビルドステータスが Topology ビューに表示されます。サンプルアプリケーションの作成後、デプロイメントがアプリケーションに追加されていることを確認できます。

手順

1. +Add ビューで、Getting Started resources → Build with guided documentation → View all quick starts リンクをクリックして、Quick Starts ページを表示します。
2. Quick Starts ページで、使用するクイックスタートのタイルをクリックします。
3. Start をクリックして、クイックスタートを開始します。
4. 表示される手順を実行します。

手順

1. +Add ビューで、Git Repository タイルの From Git をクリックし、Import from git フォームを表示します。
2. Git セクションで、アプリケーションの作成に使用するコードベースの Git リポジトリー URL を入力します。たとえば、このサンプル nodejs アプリケーションの URL https://github.com/sclorg/nodejs-ex を入力します。その後、URL は検証されます。

3. オプション: Show Advanced Git Options をクリックし、以下のような詳細を追加できます。

   • Git Reference: アプリケーションのビルドに使用する特定のブランチ、タグ、またはコミットのコードを参照します。
   • Context Dir: アプリケーションのビルドに使用するアプリケーションのソースコードのサブディレクトリーを指定します。
   • Source Secret: プライベートリポジトリーからソースコードをプルするための認証情報で Secret Name を作成します。

4. オプション: 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 が検出された場合、特定のインスタンスをインポートするには、コンテキストディレクトリーからの相対パスをそれぞれ指定します。

5. Git URL の検証後に、推奨されるビルダーイメージが選択されて星マークが付けられます。ビルダーイメージが自動検出されていない場合は、ビルダーイメージを選択します。https://github.com/sclorg/nodejs-ex Git URL の場合、Node.js ビルダーイメージがデフォルトで選択されます。

   1. オプション:Builder Image Version ドロップダウンリストを使用してバージョンを指定します。
   2. オプション:Edit import strategy を使用して、別のストラテジーを選択します。
   3. オプション:Node.js ビルダーイメージの場合、Run command フィールドを使用して、アプリケーションを実行するためにコマンドを上書きします。

6. General セクションで、以下を実行します。

   1. Application フィールドに、アプリケーションを分類するために一意の名前 (myapp など) を入力します。アプリケーション名が namespace で一意であることを確認します。

   2. Name フィールドで、既存のアプリケーションが存在しない場合に、このアプリケーション用に作成されたリソースが Git リポジトリー URL をベースとして自動的に設定されることを確認します。既存のアプリケーションがある場合には、既存のアプリケーション内でそのコンポーネントをデプロイしたり、新しいアプリケーションを作成したり、またはコンポーネントをいずれにも割り当てない状態にしたりすることができます。

      注記

      リソース名は namespace で一意である必要があります。エラーが出る場合はリソース名を変更します。

7. Resources セクションで、以下を選択します。

   • Deployment: 単純な Kubernetes スタイルのアプリケーションを作成します。
   • デプロイメント Config: Red Hat OpenShift Service on AWS スタイルのアプリケーションを作成します。

8. Pipelines セクションで、Add Pipeline を選択してから Show Pipeline Visualization をクリックし、アプリケーションのパイプラインを表示します。デフォルトのパイプラインが選択されますが、アプリケーションで利用可能なパイプラインの一覧から必要なパイプラインを選択できます。

   注記

   次の基準が満たされている場合、Add pipeline チェックボックスがオンになり、Configure PAC がデフォルトで選択されます。

   • パイプラインオペレーターがインストールされています
   • pipelines-as-code が有効になっています
   • .tekton ディレクトリーが Git リポジトリーで検出される

9. Webhook をリポジトリーに追加します。Configure PAC がオンになっており、GitHub アプリがセットアップされている場合は、Use GitHub App と Setup a webhook オプションが表示されます。GitHub アプリケーションがセットアップされていない場合は、Setup a webhook オプションのみが表示されます。

   1. Settings → Webhooks に移動し、Add webhook をクリックします。
   2. Payload URL を Pipelines as Code コントローラーのパブリック URL に設定します。
   3. コンテンツタイプを application/json として選択します。
   4. Webhook シークレットを追加し、別の場所に書き留めます。openssl がローカルマシンにインストールされた状態で、ランダムなシークレットを生成します。
   5. Let me select individual events をクリックし、Commit comments、Issue comments、Pull request、および Pushes のイベントを選択します。
   6. Add webhook をクリックします。

10. オプション: Advanced Options セクションでは、Target port および Create a route to the application がデフォルトで選択されるため、公開されている URL を使用してアプリケーションにアクセスできます。

    アプリケーションがデフォルトのパブリックポート 80 でデータを公開しない場合は、チェックボックスの選択を解除し、公開する必要のあるターゲットポート番号を設定します。

11. オプション: 以下の高度なオプションを使用してアプリケーションをさらにカスタマイズできます。

    Routing

    Routing のリンクをクリックして、以下のアクションを実行できます。

    • ルートのホスト名をカスタマイズします。
    • ルーターが監視するパスを指定します。
    • ドロップダウンリストから、トラフィックのターゲットポートを選択します。

    • Secure Route チェックボックスを選択してルートを保護します。必要な TLS 終端タイプを選択し、各ドロップダウンリストから非セキュアなトラフィックに関するポリシーを設定します。

      注記

      サーバーレスアプリケーションの場合、Knative サービスが上記のすべてのルーティングオプションを管理します。ただし、必要に応じて、トラフィックのターゲットポートをカスタマイズできます。ターゲットポートが指定されていない場合、デフォルトポートの 8080 が使用されます。

    ヘルスチェック

    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 としても知られています。

    リソースの制限

    Resource Limit リンクをクリックして、コンテナーが実行時に保証または使用が許可されている CPU および メモリー リソースの量を設定します。

    ラベル

    Labels リンクをクリックして、カスタムラベルをアプリケーションに追加します。

12. Create をクリックしてアプリケーションを作成し、成功の通知が表示されます。Topology ビューでアプリケーションのビルドステータスを確認できます。

手順

1. +Add ビューで、Container images をクリックして、Deploy Images ページを表示します。

2. Image セクションで以下を行います。

   1. Image name from external registry を選択してパブリックレジストリーまたはプライベートレジストリーからイメージをデプロイメントするか、Image stream tag from internal registry を選択して内部レジストリーからイメージをデプロイメントします。
   2. Runtime icon タブでイメージのアイコンを選択します。

3. General セクションで、以下を実行します。

   1. Application name フィールドに、アプリケーションを分類するための一意の名前を入力します。
   2. Name フィールドに、このコンポーネント用に作成されたリソースを識別するための一意の名前を入力します。

4. Resource type セクションで、生成するリソースタイプを選択します。

   1. Deployment を選択して、Pod および ReplicaSet オブジェクトの宣言的更新を有効にします。
   2. DeploymentConfig を選択して、Pod オブジェクトのテンプレートを定義し、新しいイメージと設定ソースのデプロイを管理します。
5. Create をクリックします。Topology ビューでアプリケーションのビルドステータスを確認できます。

手順

1. Topology ビューで、任意の場所を右クリックして Add to Project メニューを表示します。
2. Add to Project メニューにカーソルを置いてメニューオプションを表示し、Upload JAR file オプションを選択して Upload JAR file フォームを確認します。または、JAR ファイルを Topology ビューにドラッグできます。
3. JAR file フィールドで、ローカルマシンで必要な JAR ファイルを参照し、これをアップロードします。または、JAR ファイルをフィールドにドラッグできます。互換性のないタイプのファイルが Topology ビューにドラッグされると、トーストアラートが右側に表示されます。互換性のないファイルタイプがアップロードフォームのフィールドにドロップされると、フィールドエラーが表示されます。
4. デフォルトで、ランタイムアイコンとビルダーイメージが選択されています。ビルダーイメージが自動検出されていない場合は、ビルダーイメージを選択します。必要に応じて、Builder Image Version のドロップダウンリストを使用してバージョンを変更できます。
5. オプション: Application Name フィールドに、リソースのラベル付けに使用する一意のアプリケーション名を入力します。
6. Name フィールドに、関連付けられたリソースに名前を付けるために一意のコンポーネント名を入力します。
7. オプション: Resource type ドロップダウンリストを使用して、リソースタイプを変更します。
8. Advanced options メニューで Create a Route to the Application をクリックし、デプロイされたアプリケーションのパブリック URL を設定します。
9. Create をクリックしてアプリケーションをデプロイします。JAR ファイルがアップロードされたことを通知するトースト通知が表示されます。トースト通知には、ビルドログを表示するリンクも含まれます。

手順

1. Developer Perspective → +Add → Developer Catalog → All Services に移動します。Developer Catalog で利用可能なすべてのサービスの一覧が表示されます。
2. Type で、Devfiles をクリックして、特定の言語またはフレームワークをサポートする devfiles を参照します。あるいは、キーワードフィルターを使用して、名前、タグ、または説明を使用して特定の devfile を検索できます。
3. アプリケーションの作成に使用する devfile をクリックします。devfile タイルに、devfile の名前、説明、プロバイダー、ドキュメントなど、devfile の詳細が表示されます。
4. Create をクリックしてアプリケーションを作成し、Topology ビューでアプリケーションを表示します。

手順

1. Developer パースペクティブで、+Add に移動して、Developer Catalog タイルから All Services をクリックし、Developer Catalog で利用可能なすべてのサービスを表示します。
2. All Services で、サービスの種類またはプロジェクトに追加する必要のあるコンポーネントを選択します。この例では、Databases を選択してすべてのデータベースサービスを一覧表示し、MariaDB をクリックしてサービスの詳細を表示します。

3. Instantiate Template をクリックして、MariaDB サービスの詳細情報を含む自動的に設定されたテンプレートを表示し、Create をクリックして Topology ビューで MariaDB サービスを作成し、これを表示します。

   図3.1 トポロジーの MariaDB

   

手順

1. この手順を実行するために Red Hat OpenShift Service on AWS Web コンソールで新規プロジェクトを作成します。この例では、my-etcd というプロジェクトを使用します。

2. Operators → Installed Operators ページに移動します。このページには、dedicated-admin によってクラスターにインストールされた使用可能な Operator が、クラスターサービスバージョン (CSV) のリストの形で表示されます。CSV は Operator によって提供されるソフトウェアを起動し、管理するために使用されます。

   ヒント

   以下を使用して、CLI でこのリストを取得できます。

   $ oc get csv

3. Installed Operators ページで、etcd Operator をクリックして詳細情報および選択可能なアクションを表示します。

   Provided APIs に表示されているように、この Operator は 3 つの新規リソースタイプを利用可能にします。これには、etcd クラスター (EtcdCluster リソース) のタイプが含まれます。これらのオブジェクトは、Deployment または ReplicaSet などの組み込み済みのネイティブ Kubernetes オブジェクトと同様に機能しますが、これらには etcd を管理するための固有のロジックが含まれます。

4. 新規 etcd クラスターを作成します。

   1. etcd Cluster API ボックスで、Create instance をクリックします。
   2. 次のページでは、EtcdCluster オブジェクト (クラスターのサイズなど) のテンプレートを起動する最小条件を変更できます。ここでは Create をクリックして確定します。これにより、Operator がトリガーされ、Pod、サービス、および新規 etcd クラスターの他のコンポーネントが起動します。

5. example etcd クラスター、Resources タブの順にクリックし、Operator が自動的に作成および設定した多数のリソースが含まれていることを確認します。

   Kubernetes サービスが作成され、プロジェクトの他の Pod からデータベースにアクセスできることを確認します。

6. 所定プロジェクトで edit ロールを持つすべてのユーザーは、クラウドサービスのようにセルフサービス方式でプロジェクトにすでに作成されている Operator によって管理されるアプリケーションのインスタンス (この例では etcd クラスター) を作成し、管理し、削除することができます。この機能を持つ追加のユーザーを有効にする必要がある場合、プロジェクト管理者は以下のコマンドを使用してこのロールを追加できます。

   $ oc policy add-role-to-user edit <user> -n <target_project>

手順

1. データベースをインストールします。

   $ sudo yum install -y postgresql postgresql-server postgresql-devel

2. データベースを初期化します。

   $ sudo postgresql-setup initdb

   このコマンドで /var/lib/pgsql/data ディレクトリーが作成され、このディレクトリーにデータが保存されます。

3. データベースを起動します。

   $ sudo systemctl start postgresql.service

4. データベースが実行されたら、rails ユーザーを作成します。

   $ sudo -u postgres createuser -s rails

   作成をしたユーザーのパスワードは作成されていない点に留意してください。

手順

1. Rails gem をインストールします。

   $ gem install rails

   出力例

   Successfully installed rails-4.3.0
   1 gem installed

2. Rails gem のインストール後に、PostgreSQL をデータベースとして指定して新規アプリケーションを作成します。

   $ rails new rails-app --database=postgresql

3. 新規アプリケーションディレクトリーに切り替えます。

   $ cd rails-app

4. アプリケーションがすでにある場合には pg (postgresql) gem が Gemfile に配置されていることを確認します。配置されていない場合には、gem を追加して Gemfile を編集します。

   gem 'pg'

5. すべての依存関係を含む Gemfile.lock を新たに生成します。

   $ bundle install

6. pg gem で postgresql データベースを使用するほか、config/database.yml が postgresql アダプターを使用していることを確認する必要があります。

   config/database.yml ファイルの default セクションを以下のように更新するようにしてください。

   default: &default
     adapter: postgresql
     encoding: unicode
     pool: 5
     host: localhost
     username: rails
     password: <password>

7. アプリケーションの開発およびテスト用のデータベースを作成します。

   $ rake db:create

   これで PostgreSQL サーバーに development および test データベースが作成されます。

1. Linux x86_64 または Linux amd64 Helm バイナリーをダウンロードし、これをパスに追加します。

   # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm

2. バイナリーファイルを実行可能にします。

   # chmod +x /usr/local/bin/helm

3. インストールされたバージョンを確認します。

   $ helm version

   出力例

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

1. 最新の .exe ファイル をダウンロードし、希望のディレクトリーに配置します。
2. Start を右クリックし、Control Panel をクリックします。
3. System and Security を選択してから System をクリックします。
4. 左側のメニューから、Advanced systems settings を選択し、下部にある Environment Variables をクリックします。
5. Variable セクションから Path を選択し、Edit をクリックします。
6. New をクリックして、.exe ファイルのあるフォルダーへのパスをフィールドに入力するか、Browse をクリックし、ディレクトリーを選択して OK をクリックします。

1. 最新の .exe ファイル をダウンロードし、希望のディレクトリーに配置します。
2. Search クリックして、env または environment を入力します。
3. Edit environment variables for your account を選択します。
4. Variable セクションから Path を選択し、Edit をクリックします。
5. New をクリックし、exe ファイルのあるディレクトリーへのパスをフィールドに入力するか、Browse をクリックし、ディレクトリーを選択して OK をクリックします。

1. Helm バイナリーをダウンロードし、これをパスに追加します。

   # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm

2. バイナリーファイルを実行可能にします。

   # chmod +x /usr/local/bin/helm

3. インストールされたバージョンを確認します。

   $ helm version

   出力例

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

1. Developer パースペクティブで、+Add ビューに移動し、プロジェクトを選択します。次に、Helm Chart オプションをクリックし、Developer Catalog にすべての Helm チャートを表示します。
2. チャートを選択し、チャートの説明、README、チャートに関するその他の詳細を確認します。

3. Create をクリックします。

   図5.1 Developer カタログの Helm チャート

   

4. Create Helm Release ページで:

   1. リリースの固有の名前を Release Name フィールドに入力します。
   2. Chart Version ドロップダウンリストから必要なチャートのバージョンを選択します。

   3. Form View または YAML View を使用して Helm チャートを設定します。

      注記

      利用可能な場合は、YAML View と Form View 間で切り替えることができます。ビューの切り替え時に、データは永続化されます。

   4. Create をクリックして Helm リリースを作成します。Web コンソールは、Topology ビューに新しいリリースを表示します。

      Helm チャートにリリースノートがある場合は、Web コンソールに表示されます。

      Helm チャートがワークロードを作成する場合、Web コンソールはそれらを Topology または Helm リリース詳細 ページに表示します。ワークロードは、DaemonSet、CronJob、Pod、Deployment、および DeploymentConfig です。

   5. Helm Releases ページで、新しく作成された Helm リリースを表示します。

手順

1. 新しいプロジェクトを作成します。

   $ oc new-project nodejs-ex-k

2. Red Hat OpenShift Service on AWS オブジェクトを含むサンプル Node.js チャートをダウンロードします。

   $ git clone https://github.com/redhat-developer/redhat-helm-charts

3. サンプルチャートを含むディレクトリーに移動します。

   $ cd redhat-helm-charts/alpha/nodejs-ex-k/

4. Chart.yaml ファイルを編集し、チャートの説明を追加します。

   apiVersion: v2 1
   name: nodejs-ex-k 2
   description: A Helm chart for OpenShift 3
   icon: https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.svg 4
   version: 0.2.1 5

   1

   チャート API バージョン。これは、Helm 3 以上を必要とする Helm チャートの場合は v2 である必要があります。

   2

   チャートの名前。

   3

   チャートの説明。

   4

   アイコンとして使用するイメージへの URL。

   5

   Semantic Versioning (SemVer) 2.0.0 仕様に準拠したチャートのバージョン。

5. チャートが適切にフォーマットされていることを確認します。

   $ helm lint

   出力例

   [INFO] Chart.yaml: icon is recommended
   
   1 chart(s) linted, 0 chart(s) failed

6. 直前のディレクトリーレベルに移動します。

   $ cd ..

7. チャートをインストールします。

   $ helm install nodejs-chart nodejs-ex-k

8. チャートが正常にインストールされたことを確認します。

   $ helm list

   出力例

   NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
   nodejs-chart nodejs-ex-k 1 2019-12-05 15:06:51.379134163 -0500 EST deployed nodejs-0.1.0  1.16.0

手順

1. Developer パースペクティブで、+Add ビューに移動し、プロジェクトを選択します。
2. Developer Catalog タイルから、Helm Chart オプションを選択して Developer Catalog ですべての Helm チャートを表示します。

3. Helm チャートのリストの左側にあるフィルターを使用して、必要なチャートをフィルターします。

   • Chart Repositories フィルターを使用して、Red Hat Certification Charts または OpenShift Helm Charts が提供したチャートをフィルターします。
   • Source フィルターを使用して、Partners、Community または Red Hat から提供されるチャートをフィルターします。認定チャートはアイコン ( ) で表示されます。

手順

1. Topology ビューで Helm リリースを選択し、サイドパネルを表示します。
2. Actions → Upgrade Helm Release をクリックします。
3. Upgrade Helm Release ページで、アップグレード先とする Chart Version を選択してから Upgrade をクリックし、別の Helm リリースを作成します。Helm Releases ページには 2 つのリビジョンが表示されます。

1. Developer パースペクティブで Helm ビューに移動し、namespace の Helm Releases を表示します。
2. リスト表示されているリソースに隣接する Options メニュー をクリックし、Rollback を選択します。
3. Rollback Helm Release ページで、ロールバックする Revision を選択し、Rollback をクリックします。
4. Helm Releases ページで、チャートをクリックし、リリースの詳細およびリソースを表示します。

5. Revision History タブに移動し、チャートのすべてのリビジョンを表示します。

   図5.2 Helm リビジョン履歴

   
6. 必要な場合は、さらに特定のリビジョンに隣接する Options メニュー を使用して、ロールバックするリビジョンを選択します。

手順

1. Topology ビューで Helm リリースを右クリックし、Delete Helm Release を選択します。
2. 確認プロンプトで、グラフの名前を入力し、Delete をクリックします。

手順

1. 秘密鍵および公開証明書から新しい TLS シークレットを作成します。ここで、fullchain.pem および privkey.pem は、公開または秘密のワイルドカード証明書です。

   例

   $ oc create secret tls <name>-tls --cert=fullchain.pem --key=privkey.pem -n <my_project>

2. 新規の CustomDomain カスタムリソース (CR) を作成します。

   例: <company_name>-custom-domain.yaml

   apiVersion: managed.openshift.io/v1alpha1
   kind: CustomDomain
   metadata:
     name: <company_name>
   spec:
     domain: apps.<company_name>.io 1
     scope: External
     loadBalancerType: Classic 2
     certificate:
       name: <name>-tls 3
       namespace: <my_project>
     routeSelector: 4
       matchLabels:
        route: acme
     namespaceSelector: 5
       matchLabels:
        type: sharded

   1

   カスタムドメイン。

   2

   カスタムドメインのロードバランサーのタイプ。このタイプは、ネットワークロードバランサーを使用する場合は、デフォルトの classic または NLB にすることができます。

   3

   前の手順で作成されたシークレット

   4

   オプション: CustomDomain イングレスによって提供されるルートのセットをフィルタリングします。値が指定されていない場合、デフォルトはフィルタリングなしです。

   5

   オプション: CustomDomain イングレスによって提供される namespace のセットをフィルタリングします。値が指定されていない場合、デフォルトはフィルタリングなしです。

3. CR を適用します。

   例

   $ oc apply -f <company_name>-custom-domain.yaml

4. 新規に作成された CR のステータスを取得します。

   $ oc get customdomains

   出力例

   NAME               ENDPOINT                                                    DOMAIN                       STATUS
   <company_name>     xxrywp.<company_name>.cluster-01.opln.s1.openshiftapps.com  *.apps.<company_name>.io     Ready

5. エンドポイント値を使用して、Route53 などのマネージド DNS プロバイダーに新しいワイルドカード CNAME レコードセットを追加します。

   例

   *.apps.<company_name>.io -> xxrywp.<company_name>.cluster-01.opln.s1.openshiftapps.com

6. 新規アプリケーションを作成し、これを公開します。

   例

   $ oc new-app --docker-image=docker.io/openshift/hello-openshift -n my-project

   $ oc create route <route_name> --service=hello-openshift hello-openshift-tls --hostname hello-openshift-tls-my-project.apps.<company_name>.io -n my-project

   $ oc get route -n my-project

   $ curl https://hello-openshift-tls-my-project.apps.<company_name>.io
   Hello OpenShift!

手順

1. 新しいシークレットを作成します。

   $ oc create secret tls <secret-new> --cert=fullchain.pem --key=privkey.pem -n <my_project>

2. CustomDomain CR にパッチを適用します。

   $ oc patch customdomain <company_name> --type='merge' -p '{"spec":{"certificate":{"name":"<secret-new>"}}}'

3. 古いシークレットを削除します。

   $ oc delete secret <secret-old> -n <my_project>

1. ReplicationController 定義の要素。
2. 新規デプロイメントの自動作成のトリガー。
3. デプロイメント間の移行ストラテジー。
4. ライフサイクルフック。

1. pre ライフサイクルフックを実行します。
2. サージ数に基づいて新しいレプリケーションコントローラーをスケールアップします。
3. 最大利用不可数に基づいて以前のレプリケーションコントローラーをスケールダウンします。
4. 新しいレプリケーションコントローラーが希望のレプリカ数に到達して、以前のレプリケーションコントローラーの数がゼロになるまで、このスケーリングを繰り返します。
5. post ライフサイクルフックを実行します。

1. pre ライフサイクルフックを実行します。
2. 以前のデプロイメントをゼロにスケールダウンします。
3. 任意の mid ライフサイクルフックを実行します。
4. 新規デプロイメントをスケールアップします。
5. post ライフサイクルフックを実行します。

手順

1. ファイルにクォータを定義します。

2. クォータを作成し、これをプロジェクトに適用するためにファイルを使用します。

   $ oc create -f <file> [-n <project_name>]

   以下に例を示します。

   $ oc create -f core-object-counts.yaml -n demoproject

手順

1. プロジェクトで定義されるクォータのリストを取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。

   $ oc get quota -n demoproject

   出力例

   NAME                           AGE    REQUEST                                                                                                      LIMIT
   besteffort                     4s     pods: 1/2
   compute-resources-time-bound   10m    pods: 0/2                                                                                                    limits.cpu: 0/1, limits.memory: 0/1Gi
   core-object-counts             109s   configmaps: 2/10, persistentvolumeclaims: 1/4, replicationcontrollers: 1/20, secrets: 9/10, services: 2/10

2. 関連するクォータについて記述します。たとえば、core-object-counts クォータの場合、以下を実行します。

   $ oc describe quota core-object-counts -n demoproject

   出力例

   Name:			core-object-counts
   Namespace:		demoproject
   Resource		Used	Hard
   --------		----	----
   configmaps		3	10
   persistentvolumeclaims	0	4
   replicationcontrollers	3	20
   secrets			9	10
   services		2	10

手順

1. プロジェクト要求テンプレートにリソースクォータ定義を追加します。

   • プロジェクト要求テンプレートがクラスターに存在しない場合:

     1. ブートストラッププロジェクトテンプレートを作成し、これを template.yaml というファイルに出力します。

        $ oc adm create-bootstrap-project-template -o yaml > template.yaml

     2. リソースクォータの定義を template.yaml に追加します。以下の例では、'storage-consumption' という名前のリソースクォータを定義します。テンプレートの parameters: セクションの前に定義を追加する必要があります。

        - apiVersion: v1
          kind: ResourceQuota
          metadata:
            name: storage-consumption
            namespace: ${PROJECT_NAME}
          spec:
            hard:
              persistentvolumeclaims: "10" 1
              requests.storage: "50Gi" 2
              gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
              silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
              silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
              bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
              bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7

        1

        プロジェクト内の永続ボリューム要求の合計数です。

        2

        プロジェクトのすべての永続ボリューム要求において、要求されるストレージの合計はこの値を超えることができません。

        3

        プロジェクトのすべての永続ボリューム要求において、gold ストレージクラスで要求されるストレージの合計はこの値を超えることができません。

        4

        プロジェクトのすべての永続ボリューム要求において、silver ストレージクラスで要求されるストレージの合計はこの値を超えることができません。

        5

        プロジェクトのすべての永続ボリューム要求において、silver ストレージクラスの要求の合計数はこの値を超えることができません。

        6

        プロジェクトのすべての永続ボリューム要求において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。この値が 0 に設定される場合、bronze ストレージクラスはストレージを要求できません。

        7

        プロジェクトのすべての永続ボリューム要求において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。この値が 0 に設定される場合、bronze ストレージクラスは要求を作成できません。

     3. openshift-config namespace の変更された template.yaml ファイルでプロジェクト要求テンプレートを作成します。

        $ oc create -f template.yaml -n openshift-config

        注記

        設定を kubectl.kubernetes.io/last-applied-configuration アノテーションとして追加するには、--save-config オプションを oc create コマンドに追加します。

        デフォルトでは、テンプレートは project-request という名前になります。

   • プロジェクト要求テンプレートがクラスター内にすでに存在する場合は、以下を実行します。

     注記

     設定ファイルを使用してクラスター内のオブジェクトを宣言的または命令的に管理する場合は、これらのファイルを使用して既存のプロジェクト要求テンプレートを編集します。

     1. openshift-config namespace のテンプレートをリスト表示します。

        $ oc get templates -n openshift-config

     2. 既存のプロジェクト要求テンプレートを編集します。

        $ oc edit template <project_request_template> -n openshift-config

     3. 前述の storage-consumption の例などのリソースクォータ定義を既存のテンプレートに追加します。テンプレートの parameters: セクションの前に定義を追加する必要があります。

2. プロジェクト要求テンプレートを作成した場合は、クラスターのプロジェクト設定リソースでこれを参照します。

   1. 編集するプロジェクト設定リソースにアクセスします。

      • Web コンソールの使用

        1. Administration → Cluster Settings ページに移動します。
        2. Configuration をクリックし、すべての設定リソースを表示します。
        3. Project のエントリーを見つけ、Edit YAML をクリックします。

      • CLI の使用

        1. project.config.openshift.io/cluster リソースを編集します。

           $ oc edit project.config.openshift.io/cluster

   2. プロジェクト設定リソースの spec セクションを更新し、projectRequestTemplate および name パラメーターを追加します。以下の例は、project-request というデフォルトのプロジェクト要求テンプレートを参照します。

      apiVersion: config.openshift.io/v1
      kind: Project
      metadata:
      #  ...
      spec:
        projectRequestTemplate:
          name: project-request

3. プロジェクトの作成時にリソースクォータが適用されていることを確認します。

   1. プロジェクトを作成します。

      $ oc new-project <project_name>

   2. プロジェクトのリソースクォータをリスト表示します。

      $ oc get resourcequotas

   3. リソースクォータを詳細に記述します。

      $ oc describe resourcequotas <resource_quota_name>

手順

1. アノテーションに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

   $ oc create clusterquota for-user \
        --project-annotation-selector openshift.io/requester=<user_name> \
        --hard pods=10 \
        --hard secrets=20

   これにより、以下の ClusterResourceQuota オブジェクトが作成されます。

   apiVersion: quota.openshift.io/v1
   kind: ClusterResourceQuota
   metadata:
     name: for-user
   spec:
     quota: 1
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: 2
         openshift.io/requester: <user_name>
       labels: null 3
   status:
     namespaces: 4
     - namespace: ns-one
       status:
         hard:
           pods: "10"
           secrets: "20"
         used:
           pods: "1"
           secrets: "9"
     total: 5
       hard:
         pods: "10"
         secrets: "20"
       used:
         pods: "1"
         secrets: "9"

   1

   選択されたプロジェクトに対して実施される ResourceQuotaSpec オブジェクトです。

   2

   アノテーションの単純なキー/値のセレクターです。

   3

   プロジェクトを選択するために使用できるラベルセレクターです。

   4

   選択された各プロジェクトの現在のクォータの使用状況を記述する namespace ごとのマップです。

   5

   選択されたすべてのプロジェクトにおける使用量の総計です。

   この複数プロジェクトのクォータの記述は、デフォルトのプロジェクト要求エンドポイントを使用して <user_name> によって要求されるすべてのプロジェクトを制御します。ここでは、10 Pod および 20 シークレットに制限されます。

2. 同様にラベルに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

   $  oc create clusterresourcequota for-name \1
       --project-label-selector=name=frontend \2
       --hard=pods=10 --hard=secrets=20

   1

   clusterresourcequota および clusterquota はいずれも同じコマンドのエイリアスです。for-name は ClusterResourceQuota オブジェクトの名前です。

   2

   ラベル別にプロジェクトを選択するには、--project-label-selector=key=value 形式を使用してキーと値のペアを指定します。

   これにより、以下の ClusterResourceQuota オブジェクト定義が作成されます。

   apiVersion: quota.openshift.io/v1
   kind: ClusterResourceQuota
   metadata:
     creationTimestamp: null
     name: for-name
   spec:
     quota:
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: null
       labels:
         matchLabels:
           name: frontend

手順

1. プロジェクトに適用されているクォータを表示するには、以下を実行します。

   $ oc describe AppliedClusterResourceQuota

   出力例

   Name:   for-user
   Namespace:  <none>
   Created:  19 hours ago
   Labels:   <none>
   Annotations:  <none>
   Label Selector: <null>
   AnnotationSelector: map[openshift.io/requester:<user-name>]
   Resource  Used  Hard
   --------  ----  ----
   pods        1     10
   secrets     9     20