OpenShift学習モメ

OpenShift Web Console

目標

OpenShift Web コンソールを使用して効果的に管理および設定する方法について理解する。

OpenShift Web コンソールへのアクセス

• ログイン情報を取得

crc console --credentials

• Webコンソールを開く

crc console

• Webコンソールへkubeadminでログイン
  

概要

• 画面左上隅にあるスイッチャーで、管理者と開発者の視点を切り替えることができる。
• 画面左側のナビゲーションメニューで、様々なセクションや機能にアクセスできる。

管理者画面

• クラスタ、インベントリ、容量、CPU・メモリ使用率など様々な情報にアクセスできる。
• ユーザーアクセスの管理、クラスターの更新、カスタムリソース定義など。

開発者画面

• 開発者向けに調整されているワークフローを提供
• プロジェクト、ビルド管理など
• プロジェクトをGUIで作成し、該当プロジェクトに関する設定を確認することができた。
• 検索メニューからプロジェクトの特定リソースについて確認することができた。

OpenShift CLI

目標

コマンドラインインターフェース（CLI）、特にOCコマンドを効果的に使用する方法を理解する。

• ログインコマンド

oc login -u kubeadmin -p <password> <URL>

• プロジェクト作成

oc new-project <projectname>

• プロジェクトのステータスの概要取得

oc status

• プロジェクトのステータスの概要取得（プロジェクト指定）

oc status -n <projectname>

• プロジェクトのステータスの概要取得（全プロジェクト指定（namespace））

oc status -A

→CrashLoopBackOffエラーが出力。やっぱり、相当いいパソコンじゃないとCRC環境はうまく動作しないかも。。。

• アプリケーションデプロイ（ソースコードの場所を指定して新しいアプリケーションを作成可）

oc new-app --name=first-app --image=openshift/hello-openshift

• プロジェクトで実行されているポッドに関する情報を取得。

oc get pods -o wide

• 特定のポッドまたはデプロイメントのログを表示。

oc logs deployment/<app>

• クラスター内で利用可能なAPIリソースを表示。

oc api-resources

• OCコマンドについてカテゴリ別にグループ化された使用可能なコマンドの包括的なリストを表示。

oc help

• 特定のコマンドに関する詳細情報が必要な場合。（例：createコマンドの場合）

oc create --help

• 高度なクラスター管理タスクで使用可能なタスクのサブコマンドを確認する。

oc adm --help

→とりわけ重要なコマンドは覚えておき、必要に応じてhelpコマンドを利用して正しいコマンドを利用できるようになることが大切。

OpenShift リソースのクエリ、フォーマット、フィルター

目標

kubernetesの属性のクエリ、フォーマット、フィルタリングについて理解する。

• Podのステータスを確認（一覧形式で）

oc get pods

• 特定のPodの詳細情報を確認（YAMLorJSON）

oc get pod <podname> -o yaml

oc get pod <podname> -o json

• 特定のPodの詳細情報を確認（describe）

oc describe pod <podname>

• 特定のPodの詳細情報から任意のリソース属性を確認（describe）

oc describe pod <podname> | grep IP

• Podの情報をクエリを利用して出力

oc get pods -o custom-columns=NAME:.metadata.name,RSRC:metadata.labels

• 特定のラベルを持つPodのみをリストで出力

oc get pods -l deployment=<labelname>

• 特定のフィールドを指定して出力（実行中のPodを出力）

oc get pods --field-selector=status.phase=Running 

→リソースのクエリ、フォーマット、フィルターを指定することで、必要な情報を正確に指定し出力することができる。モニタリングやトラブルシューティングに役立つ。

OpenShift リソースのインポートとエクスポートと構成

目標

kubernetesリソースのインポート、エクスポート、構成について理解する。

インポート

• 指定されたディレクトリに定義されているリソース構成を適用（更新or適用）

oc apply -f ./<directoryname>

• 指定されたファイル（yaml）に定義されているリソース構成を適用（更新or適用）

oc apply -f ./<directoryname>/<filename>

エクスポート

• 指定されたデプロイメント定義をyaml形式で出力

oc get deployment <deployname> -o yaml > <filename>

• secretのリストを標準出力

oc get secrets

• 特定のsecretを情報を標準出力

oc extract secret/<secretname>

• 特定のsecretを情報をファイルへ出力

oc extract secret/<secretname> --to=./<filename>

• エクスポートしたyamlファイルの更新

nano <filename>

→viでもおけ

• 更新したyamlファイルを適用

oc apply -f <filename>

→競合エラーがでたので、oc apply -f <filename> --forceで実行したらうまくいった

宣言型と命令型

命令型

• oc create、oc delete、oc replace、oc editなど
• 命令型のコマンドは、特別の状況では必要であり便利だが、通常はより詳細なコマンド指定が要求される
• 監視と手動管理が必要となるため、エラーや不一致が発生する可能性が高くなる

宣言型

• oc apply
• 目標状態を宣言（構成ファイル定義）することで、OpenShiftがその状態を達成する方法を自動で判断し、リソースの作成や更新をしてくれる。

→基本的にoc apply（宣言型）の使用をしたほうがいい。命令型は、緊急時や簡単な動作確認の際に使用するにとどめたほうが安全。

コンテナイメージを見つけて調べる

目標

OpenShift管理者として、OpenShift上で実行されているコンテナイメージを検索して調べる方法を理解する。

• コンテナイメージストリームをリスト表示

oc get imagestream -n openshift

• 特定のコンテナイメージストリームの詳細情報を表示

oc describe is <imagestreamname> -n openshift

• 特定のコンテナイメージの詳細情報を表示

oc describe image <image>

• コンテナイメージのダウンロード

oc image extract

＜イメージストリームとは？＞

• OpenShift のリソースの 1 つ。
• コンテナイメージそのものは含まず、コンテナイメージを参照を行うためのリソース。
• コンテナイメージの参照を抽象化し、ImageStream とタグによって利用可能なイメージを管理。

👇を読み込んでもう少し、コンテナ、イメージ、イメージストリームの違いを理解する。
https://docs.redhat.com/ja/documentation/openshift_container_platform/4.2/html/images/understanding-images#understanding-images

プロジェクトの作成と削除

目標

OpenShift管理者として、プロジェクトの概念と作成、削除方法を理解する。

プロジェクトの概念

• プロジェクトは、リソースを整理および分離するためのOpenShiftの基本概念。
• 他のユーザと作業空間を分けたり、作成されるイメージ名の一部になったりと、名前空間としての役割を持つ。
• 他にもユーザが使用可能なメモリやCPUなどのリソースをProject単位で制限したり、他のユーザに自分のProjectを見せたり編集させたりする権利を明示的に与える等、様々な役割がある。
  👇以下参考サイト
  https://thinkit.co.jp/article/15696

プロジェクトの作成と削除（CLI）

• developerユーザーでocログイン

oc login -u developer https://api.crc.testing:6443

Logged into "https://api.crc.testing:6443" as "developer" using existing credentials.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

• プロジェクト作成（例：my-demon-projectを作成）

oc new-project my-demo-project --description='My demonstration project' --display-name='Demo Project'

Now using project "my-demo-project" on server "https://api.crc.testing:6443".

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app rails-postgresql-example

to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:

    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost serve-hostname

• 現在のプロジェクトを表示

oc project

Using project "my-demo-project" on server "https://api.crc.testing:6443".

• アプリケーションの作成

oc new-app --name=my-app --image=openshift/hello-openshift

--> Found container image 7af3297 (6 years old) from Docker Hub for "openshift/hello-openshift"

    * An image stream tag will be created as "my-app:latest" that will track this image

--> Creating resources ...
    imagestream.image.openshift.io "my-app" created
    deployment.apps "my-app" created
    service "my-app" created
--> Success
    Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
     'oc expose service/my-app' 
    Run 'oc status' to view your app.

• Podのステータスを確認

oc get pods

• プロジェクト内の全リソースを確認

oc get all

• プロジェクトの詳細情報を確認

oc describe project my-demo-project

• プロジェクトの削除

oc delete project my-demo-project

プロジェクトの作成と削除（Webコンソール）

作成

• 左上隅の「追加」をクリックして、「プロジェクトの作成」をクリックする。
  

• 名前など入力し「作成」をクリックする。
  

削除

• 左の「プロジェクト」の右上の「アクション」タブで、「プロジェクトの削除」をクリックする。
  

• 削除したいプロジェクト名を入力し、「削除」をクリックする。
  

リソースとクラスターのステータスを調査する

目標

OpenShift管理者として、リソースとクラスターのステータスを調査する方法を理解する。

• 現在のプロジェクトのデプロイメントを調べる

oc get deployments

• 指定したプロジェクトのデプロイメントを調べる

oc get deployments -n <namespace>

• クラスター内のすべてのプロジェクトのPodを調べる

oc get pods --all-namespaces

• クラスターの状態（概要）を調べる

oc status

• クラスターのノードに関する情報を調べる

oc get nodes

• クラスターの各コントロールプレーンの状態を調べる

oc get componentstatuses

• Podのリソース使用状況を調べる

oc adm top nodes

oc adm top nodes --sort-by=cpu

oc adm top pods

oc adm top pods --namespace=my-namespace

oc adm top pods -l app=app-name

Webコンソールを用いたリソース使用状況を調べる

管理者権限でログインし、「ホーム」→「概要」の画面を開くと、6つのセクションがある。それぞれ、以下用途で活用し、リソース使用状況を確認する。

詳細

• クラスターのステータスと履歴のクイックリファレンスガイド
• クラスターID、インフラストラクチャープロバイダーなどの情報が含まれている

クラスターイベントリー

• ノードの数、ポッドの総数、ストレージクラス、永続ストレージ、クラスター内のボリューム要求などが表示される
• クラスターが動作している規模を評価するのに役出つ

ステータス

• さまざまなコンポーネントの動作状態を表示する
• クラスターのコントロールプレーンとオペレーターに関するステータス情報など
• 問題が発生しているコンポーネントや注意が必要なコンポーネントを特定するのに役立つ

クラスターの使用率

• さまざまなリソースの使用状況を表示する
• 傾向の特定、容量の計画、トラブルシューティングに役立つ

アクティビティー

• クラスターの動作パネルに関する最新情報を入手できる
• 最新のアクティビティやイベントのフィードを提供し、内部で何が起こっているかダイナミックに把握できる

https://qiita.com/Y-Shikase/items/dc05259efda697b91f50

ログ

目標

OpenShift管理者として、ログを効果的に表示する方法を理解する。

• ビルド構成の最新ログを表示

oc logs -f bc/<build-config-name>

• デプロイメントの最新ログを表示

oc logs -f deployment/<deployment-name>

• 特定バージョンのデプロイメントの最新ログを表示

oc logs -f deployment/<deployment-name> -version=<version-number>

• 特定バージョンのビルド構成の最新ログを表示

oc logs -f bc/<build-config-name> -version=<version-number>

• 特定Podの最新ログを表示

oc logs -f pod/<pod-name>

• ログの最後の数行だけを表示したい場合は、末尾にtailをつける

oc logs -f pod/<pod-name> --tail=10

• 特定ノードのログを表示

oc adm node-logs <node-name>

oc adm node-logs --role master

oc adm node-logs --role master -u kubelet

• 特定のPodの詳細情報を確認（describe）

oc describe pod <podname>

Webコンソールからの確認方法

• プロジェクト→インベントリー→Podをクリック。
• 確認したいPod名をクリックし、ログタグを閲覧するとログを参照できる。
• ダウンロードも可能なため、エビデンスも残しやすい。かつ、複数Podがある場合、Pod間の行き来が楽！
  

クラスター全体の健全性

目標

OpenShift管理者として、クラスター全体の健全性を確認する方法を理解する。

etcdの監視

oc get pods -n openshift-etcd

oc -n openshift-etcd rsh etcd-crc

etcdctl endpoint health

oc logs -n openshift-etcd etcd-crc

Operatorの監視

oc get clusteroperators

バージョンの確認

oc version

一般的な問題のトラブルシューティング

目標

OpenShift管理者として、一般的なトラブルシューティングのシナリオと対応方法を理解する。

コンテナの起動失敗/クラッシュ

主な原因

• アプリケーションコードの設定ミス
• 依存関係の欠落
• リソースの制約

調査方法

• コンテナログの確認

oc logs

oc describe

• リソースの確認

oc adm top

Podのステータス異常（Pendingなど）

主な原因

• 設定ミス
• リソースの不足

調査方法

• Podのイベント確認

oc describe

oc get events --field-selector

• Podの強制削除（スタック時など）

oc delete

クラスター（etcdの問題）

主な原因

• 処理遅延
• ディスクI/O
• ネットワーク接続エラー

調査方法

• etcd CTL

クラスター（ネットワークの問題）

主な原因

• ネットワークポリシーの誤り
• ファイアウォールルールの誤り
• ネットワークプラグインの誤り

調査方法

• Podネットワークの詳細とイベントを確認

oc describe

• Podへのping、traceroute、telnetなど

oc exec my-pod -- ping annther-pod

→大事なのは、全体構成をしっかり把握し、問題を特定し、どこを見るべきかを知ること。
→練習も大事だが、実際のトラブルシューティングの経験がより重要。

製品ドキュメントについて

目標

OpenShift管理者として、製品ドキュメントの活用方法を理解する。

以下OpenShiftの製品ドキュメントを読めば、基本的な内容からベストプラクティス、トラブルシューティングなどまでカバーできる。あとは、oc helpで必要に応じてコマンドの利用法を調べられればおけ。

https://docs.openshift.com/
https://docs.redhat.com/ja/documentation/openshift_container_platform/4.16#Develop

HTPasswd ID プロバイダーの構成について

目標

OpenShift管理者として、クラスターへのユーザーアクセス管理について理解する。

• パスワードファイルの作成

htpasswd -c -B -b htpasswd alice redhat123

• パスワードファイルにユーザー追加

htpasswd -B -b htpasswd bob redhat123

htpasswd -B -b htpasswd charlie redhat123

htpasswd -B -b htpasswd ted redhat123

• クラスターの設定（Webコンソール）
  管理者権限でWebコンソールへログインし、「管理」→「クラスター管理」→「設定」タブへ進む
  「OAuth」をクリックし、「アイデンティティープロバイダー」で「追加」タブからhttpdpasswdを選択し、作成したファイルを選択し追加。
  

クラスターの設定（CLI）

• シークレットの作成

oc create secret generic my-htpass-secret --from-file=htpasswd=htpasswd -n openshift-config

• OAuthのエクスポート

oc get oauth cluster -o yaml > oauth.yaml

• OAuthの情報を確認

oc explain oauth.spec

oc explain oauth.spec.identityProviders

• OAuthの構成を修正(シークレット名を修正)

vi oauth.yaml

• yamlをreplace

oc replace -f oauth.yaml

• Pod（openshift-authentication）の起動を確認

oc get pods -n openshift-authentication

htpasswd-g2qb5

HTPasswd IDの削除方法について

目標

OpenShift管理者として、HTPasswd IDの削除方法について理解する。

概要

• パスワードファイルからユーザーを削除し、secretを作り直し、replaceしなおす
• その後、クラスターのユーザー一覧からdeleteコマンドを使って、ユーザーを削除する

グループの作成方法と管理方法について

目標

OpenShift管理者として、グループの作成方法と管理方法について理解する。

• グループの作成とユーザーの作成

oc adm groups new testers alice bob charlie

• グループへ表示ロールの割り当てをする

oc adm policy add-role-to-group view testers -n manage-groups

• グループから特定ユーザーの削除

oc adm groups remove-users view testers alice

ユーザーおよびグループの権限の変更

目標

OpenShift管理者として、ユーザーとグループのアクセス許可を変更する方法について理解する。

・クラスター全体に適用されるRBACクラスターとローカルの2つのレベルのRABCクラスターがある。
・ロールバイディングというものが必要。

• グループの作成とユーザーの作成

oc adm groups new testers alice bob charlie

プロジェクトのリソース制限設定（リソースクォータ）

目標

OpenShift管理者として、プロジェクトのリソース制限設定（リソースクォータ）方法について理解する。

＜概要＞
・コンピューターリソース：CPU、メモリー、一時ストレージの総数を制限する
・ストレージリソース：永続ボリュームクレームの総数を制限する
・オブジェクトカウント：Pod、レプリケーションコントローラー、サービス、シークレットなど様々なオブジェクトを制限する

＜デモ＞
・デモ用のプロジェクト作成

oc new-project quota-demo

・リソースクォータの作成

oc create quota custom-quota --hard=cpu=2,memory=10Gi,pods=5

・リソースクォータの確認

oc get quota

・リソースクォータの詳細確認

oc describe quota custom-quota

・Podの作成を試みてみる（リソースクォータの制限がかかっていることを確認）

oc run nginx --image=bitnami/nginx

・yamlからPodを作成してみる（レプリカ数4つ CPU制限100m メモリ制限128Mi）

vi deployment-quota.yaml

oc apply -f deployment-quota.yaml

oc get pods

・5つのレプリカ数にスケールしてみる（Podは作られる）

oc scale deployment/quota-test --replicas=5

oc get pods

・6つのレプリカ数にスケールしてみる（Podが作られない）

oc scale deployment/quota-test --replicas=6

oc get pods

クラスターのリソース制限設定（リソースクォータ）

目標

OpenShift管理者として、クラスターのリソース制限設定（リソースクォータ）方法について理解する。

・複数のプロジェクトにまたがるリソース使用量の管理ができる。
→特定のグループやユーザーにも。

・テスト用のプロジェクトを2つ作成

oc new-project project-1

oc label namespace project-1 enviroment=production

oc new-project project-2

oc label namespace project-2 enviroment=production

・リソースクォータの作成

oc create clusterresourcequota production-quota --project-label-selector=enviroment=production --hard=cpu=10 --hard=memory=20Gi

・リソースクォータの表示

oc describe appliedclusterresourcequota -n project-1

→注釈とラベルを活用することで、複数のプロジェクにまたがるリソースクォータを適用できる。

プロジェクト制限範囲の構成

目標

OpenShift管理者として、プロジェクトの制限範囲と、それがプロジェクト内のリソース消費の管理にどのように役立つか理解する。

→yamlで事前に定義したリソース制限範囲を作ることによって、リソースの独占を防止し、公平なリソース割り当てを促進することができる。

・テスト用のプロジェクトを作成

oc new-project limit-range-demo

・マニュフェストファイルの用意

more limitrange.yaml

・マニュフェストファイルの適用（制限範囲の作成）

oc create -f limitrange.yaml

・適用した制限範囲の確認

oc get limits

・制限範囲を超えたPodを作成し、作成が失敗することの確認

oc create -f limitrange-test.yaml

・制限範囲に収まるようにyamlを再定義して、今度はPodが作れることの確認。

oc create -f limitrange-test.yaml

プロジェクトテンプレートの構成

目標

OpenShift管理者として、プロジェクトテンプレート構成について理解する。

・テンプレートを作成すれば、1つ1つのプロジェクトに対するリソース制限の設定作業を削減し、一貫性を保つことができる。

・テンプレートの作成

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

vi template.yaml

・Namespaceにプロジェクトテンプレートを作成

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

・クラスターにもテンプレートを適用

oc edit projects.config.openshift.io/cluster

・OpenShfitAPIサーバPodの再起動を監視

oc get pod -n openshift-apiserver -w

・新規プロジェクトを作成してテスト

oc new-project test-project

oc get guota

oc describe limitrange

リソースマニフェストからアプリケーションをデプロイする

目標

OpenShift管理者として、リソースマニュフェストを使用してアプリケーションをデプロイする方法ついて理解する。

・リソースマニュフェストの構造

• apiVersion
• kind
• metadata
• spec

・リソースマニュフェスト作成手法

• webコンソールのyamlをコピーして作成
• --dry-runコマンドの利用

・開発者権限でログイン

oc login -u developer -p developer https://api.crc.testing:6443

・デプロイメントマニュフェストを作成

oc create deployment my-deployment -o yaml --image=bitnami/nginx --save-config --dry-run=client > my-deployment.yaml

・デプロイメントマニュフェストの中身を確認

cat my-deployment.yaml

・プロジェクトの作成

oc new-project manifests

・デプロイメントマニュフェストに基づいた、デプロイメントの作成

oc create -f my-deployment.yaml

・デプロイメントのステータス確認

oc get deployments

・デプロイメントマニュフェストの内容を変更してみる（レプリカ数を1から5に変更）。

vi my-deployment.yaml

oc apply -f my-deployment.yaml

※oc applyをするとキューブ（ctl.kubernetes.io）に保存されるらしいが、何者か？？

・デプロイメントマニュフェストの変更をテストする（実際には適用せず、クラスター内で実行）。

oc apply -f my-deployment.yaml --dry-run=server

・デプロイメントマニュフェストの変更をテストする（実際には適用せず、クライアント側として実行）。

oc apply -f my-deployment.yaml --dry-run=client

※ドライランオプションがクライアントに設定されている場合、サーバーに送信されるオブジェクトが出力される。
・デプロイメントリソースのyamlコードを取得

oc apply -f my-deployment.yaml --dry-run=client -o yaml

・デプロイメントリソースがスキーマに対して有効なのか確認

oc apply -f my-deployment.yaml --dry-run=server --validate=true

・デプロイメントリソースとデプロイメントマニュフェストの差分を表示

oc diff -f my-deployment.yaml

・Podの再起動

oc rollout restart deployment my-deployment

・デプロイメントリソースの削除

oc delete -f my-deployment.yaml

→リソースマニュフェストの構造から、リソースマニュフェストを効率的に作成するための実践的なやり方を学習できてよかった。

イメージ、OpenShift テンプレート、Helm チャートからアプリケーションをデプロイする

目標

OpenShift管理者として、イメージ、OpenShift テンプレート、Helm チャートからアプリケーションをデプロイする方法ついて理解する。

▪️コンテナイメージを使う方法
・新しいプロジェクトを作成

oc new-project deployapps

・アプリケーションのデプロイ（ApacheHTTPサーバアプリケーション）

oc new-app bitnami/apache

・アプリケーションのデプロイ（カスタム環境変数を使用してApacheHTTPサーバをデプロイ）

oc new-app --image=bitnami/apache --name=httpd2 --env=HTTPD_PORT=8080

→「bitnami/apache」のようなイメージ名は、oc get imagesで探せば出てくるもんなのか？

▪️テンプレートを使う方法
・テンプレートの検索

oc get templates -n openshift

・テンプレートの詳細情報を確認

oc describe template httpd-example -n openshift

・テンプレートのマニュフェストをファイル出力し確認

oc get template httpd-example -n openshift -o yaml > httpd-example-template.yaml

※テンプレートを使う場合は、こんな感じでローカルに出力し、カスタマイズして利用するのがベストプラクティス
・テンプレートのマニュフェストをカスタマイズして出力andデプロイ

oc process httpd-example -n openshift NAME=frontend -l app=web -o yaml > httpd-example-resources.yaml | oc apply -f -

・リソースが作成されたことの確認

oc get all

・特定のテンプレートのパラメータを表示

oc process --parameters -n openshift httpd-example

・テンプレートをプロジェクトのテンプレートライブラリにアップロードする

vi httpd-example-template.yaml

oc create -f httpd-example-template.yaml

・現状のプロジェクトに、テンプレートが登録されていることを確認

oc get templates

・登録したテンプレートでアプリケーションをデプロイできるか確認

oc new-app --template=httpd-example

▪️Helm チャートを使う方法
・新しいプロジェクトの作成

oc new-project helmdemo

・Helmチャートリポジトリの追加

helm repo add bitnami https://charts.bitnami.com/bitnami

・Wordpressのインストール

helm install wordpress-app bitnami/wordpress

・インストールされたかの確認

helm list

・helmリポジトリの更新

helm repo update

・Wordpressのインストール（ユーザー名とパスワードを指定してデプロイ）

helm install my-wordpress-app bitnami/wordpress --set wordpressUsername=admin --set wordpressPassword=secret

※Helmチャートの仕組みをもう少し理解する。特に利点。

1 回限りのタスクのジョブをデプロイする

目標

OpenShift管理者として、1 回限りのタスクのジョブをデプロイする方法ついて理解する。

▪️OpenShiftにおけるJOBの概念
→データ処理やバッチ計算、データベースの移行、バックアップ、１回限りのメンテナンスタスク。

▪️JOBの作成とデプロイ
・開発者権限でログイン

oc login -u developer -p developer https://api.crc.testing:6443

・JOBの作成

oc create job one-time-tasks --dry-run=client -o yaml --image=binami/apache -- ls

oc create job one-time-tasks --dry-run=client -o yaml --image=binami/apache -- ls > my-job.yaml

oc create -f my-job.yaml

▪️JOBのモニタリングと監視
・JOBの状態確認

oc get jobs

oc get pods

oc logs <podname>

▪️JOBの並行処理と完了
・JOBのマニュフェストファイルの修正（並行処理するPod数、Podが正常終了すると完了する、バックオフ定義を追加）

vi my-job.yaml

▪️JOBの失敗とクリーンアップの処理

oc delete job one-time-tasks

アプリケーションのデプロイメントを管理する

目標

OpenShift管理者として、アプリケーションのデプロイメントを管理する方法ついて理解する。

・OpenShiftのライフサイクルを効果的に管理する方法を理解することが重要だお
・アプリケーションのデプロイメント（更新のロールアウト、デプロイメントのスケーリング、ロールバックの処理など）。
・ロールアウト
→アプリケーションの更新をシームレスにロールアウトし、要件に合わせてデプロイメントを簡単に拡張する方法
→段階的に更新して、古いポッドを新しいポッドに徐々に置き換えることができる
→更新プロセス中にダウンタイムなしでアプリケーションを利用可能な状態が維持されます。
・再作成戦略
→既存のすべてのPodを終了し、再作成します。
→短時間のダウンタイムが発生します。

・新しいプロジェクトの作成

oc new-project deployment-demo

・httpdサーバのデプロイ

oc apply -f httpd-deployment.yaml

・httpdサーバのマニュフェストを書き換えて再度デプロイし、ローリングアップデートされていることを確認

vi httpd-deployment.yaml

oc apply -f httpd-deployment.yaml

oc rollout status deployment/httpd-deployment

・ロールバック

oc rollout undo deployment/httpd-deployment --to-revision=1

・ロールバックされていることをPodから確認

oc describe pod <podname>

・特定のリビジョン情報を表示

oc rollout history deployment/httpd-deployment --revision=2

※--revision=2を外して実行すると、リビジョンの履歴が表示されるので、それから指定すると良き

・レプリカ数を増やす

oc scale deployment/httpd-deployment --replicas=5

・ロールアウトのストップ

oc rollout pause deployment/httpd-deployment

・ロールアップの中止

oc rollout resumed deployment/httpd-deployment

ReplicaSets

目標

OpenShift管理者として、レプリカセットを管理する方法ついて理解する。

・レプリカセットはPodの数を一定に保つことで、アプリケーションにスケラービリティ、フォーr羽トレランス、高可用性を提供する。

・レプリカセットは、設定された数のPodを維持することでPodの可用性を確保するKubernetesリソースです。
・同一のPodを使用し、障害を許容し、更新をシームレスに処理します。
・Podのライフサイクルを管理し、宣言的な更新を提供するより高いレベルの抽象化です。
・Kubernetesのレプリカセットを理解すると、ワークロードの効果的なデプロイと管理についての洞察が得られます。
・ただし、デプロイメントはレプリカセットを管理し、宣言的な機能を提供する上位レベルの概念です。
　なので、普通はレプリカセットを直接操作するのではなく、デプロイメントを操作する。
・レプリカセットは、ラベルとセレクターを使用して、担当するPodを識別および管理します。

・練習用のyamlを用意

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: my-replicaset
spec:
 replicas: 3
 selector:
   matchLabels:
     app: my-app
 template:
   metadata:
     labels:
       app: my-app
   spec:
     containers:
     - name: my-app-container
       image: bitnami/apache

・作ったyamlファイルでデプロイする

oc apply -f replicaset.yaml

・レプリカセットのステータスを確認

oc describe rs/my-replicaset

oc get rs

oc get pods

・レプリカセットのスケーリング（レプリカ数を5に変更）

oc scale rs my-replicaset --replicas=5

・レプリカセットのスケーリング（レプリカ数を2に変更）

oc apply -f replicaset.yaml

・レプリカセットの削除

oc delete rs my-replicaset

・deployment.yamlの作成

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: bitnami/apach:2.4
        name: my-app-container 

・deployment.yamlのapply

oc apply -f deployment.yaml

・ステータスの確認

oc get all

・コンテナイメージを最新バージョンへ更新する

oc set image deployment/my-app-deployment my-app-container=bitnami/apache:latest

ReplicaSets

目標

OpenShift管理者として、ラベルとセレクターを操作する方法ついて理解する。

・ラベルとセレクターを利用することによって、バージョン管理やロールバックなど、より効率的にリソースを管理することができる。

・yamlファイルの作成

apiVersion: v1
kind: Pod
metadata:
  name: my-labeled-pod
  labels:
    app: my-app
    environment: production
    tier: frontend
spec:
  containers:
  - name: my-cotainer
    image: bitnami/nginx

・Pod作成

oc create -f labeled-pod.yaml

・Podに割り当てられたラベルの表示

oc get pod my-labeled-pod --show-labels

・セレクターを用いてリソースをフィルタリング

oc get pods -l app=my-app

・環境ラベルと運用値またはステージング値を持つPodを選択します。

oc get pods -l 'environment in (production, staging)'

・ラベルの更新

oc label pod my-labeled-pod environment=staging --overwrite=true

・ラベルの削除

oc label pod my-labeled-pod tier-

Configure Services

目標

OpenShift管理者として、サービスの概念ついて理解する。

＜サービスの主な利点＞
・アプリケーションのフロントエンドとバックエンドを分離できること。これにより、コンポーネントのスケーリング、更新、保守が用意になる。
・負荷分散を行い、トラフィックが均等に分散されるようになる。

＜サービスのタイプ＞
・クラスターIP：クラスター内でIPアドレスとDNS名を提供する。（クラスター内部向け）
・ノードポート：クラスター内の各ノードの静的ポートでサービス自体を公開する。（クラスター外部向け）
・ロードバランサー
・ExternalName：外部名パラメータで指定された値を持つCNAMEレコードを返す。

＜用語の整理＞
・Bridge：ノード内の内部通信を担当し、クラスターノードに接続する。

・内部通信：クラスターIP→SDN→Bridge→Pod
・外部通信：物理ポート→ノードポート→クラスターIP→SDN→Bridge→Pod
・セッションアフィニティ：クライアントが特定のPodに接続された状態を維持するための仕組みです。これは特に、リクエストが複数のPod間で均等に分散されるように設計された負荷分散環境で有効です。セッションアフィニティを有効にすると、同じクライアントからのリクエストが常に同じPodにルーティングされるため、クライアントが状態を維持するアプリケーション（例：ショッピングカートやユーザーセッション管理）が必要な場合に便利。
・ヘッドレスモードとは、リソースやアプリケーションを特定のホストに結びつけず、名前解決のみを行うための設定モードです。これは通常、Serviceの一種として、クラスタ内の複数のPodにアクセスするために利用されます。OpenShiftやKubernetesの「ヘッドレスService」を設定することで、サービスのロードバランシング機能を無効にし、直接個々のPodに対して名前解決を行います。

Expose HTTP and non-HTTP applications to external access（HTTP および非 HTTP アプリケーションを外部アクセスに公開する）

目標

OpenShift管理者として、外部にアプリケーションを公開する方法を理解する。

＜HTTPアプリケーションの公開＞
・Routesを利用する

＜非HTTPアプリケーションの公開＞
・NodePortを利用する
・ロードバランサーサービスを利用する

＜デモ＞
・デモ用のプロジェクト作成

oc new-project httpdemo

・アプリケーションの作成

oc new-app --name=my-http-app --image=bitnami/nginx

・Podの起動確認

oc get pods -w

・Routeの作成

oc expose service my-http-app --hostname=my-app.httpdemo.apps-crc.testing

・作成したRouteの情報確認

oc get route

・作成したRouteの詳細情報確認

oc describe route my-http-app

MetalLB and Multus

目標

OpenShift管理者として、MetalLBとMultusを用いた高度なネットワーク機能を理解する。

・MetalLB→ベアメタルクラスター用のロードバランサー実装を提供し、サービスを公開できるようにする。
・Multus→複数のネットワークインターフェースをPodに接続できるため、柔軟な管理が可能になる。

OpenShiftにおけるMetalLBとMultusは、ネットワークの柔軟性と機能拡張を提供する重要なコンポーネントです。それぞれの役割を以下に説明します。

1. MetalLB: ロードバランシングの実現

役割

MetalLBは、Kubernetes環境（OpenShiftも含む）で、ロードバランサーの機能を提供するためのオープンソースのロードバランシングソリューションです。
クラウド環境で一般的なロードバランサー（AWSのElastic Load Balancerなど）と異なり、オンプレミス環境ではそのようなサービスが標準で提供されない場合があります。MetalLBはそのギャップを埋めるために利用されます。

主な機能

• LoadBalancer型サービスの実現:
  KubernetesのServiceリソースにおいて、type: LoadBalancerをサポート。
• IPアドレスの割り当て:
  指定されたIPレンジからサービスに外部IPを動的に割り当てる。
• 動作モード:
  • Layer 2モード: ローカルネットワーク内でARPを使ってIPアドレスを解決。
  • BGPモード: BGP（Border Gateway Protocol）を利用してルーターにIPアドレスをアドバタイズ。

OpenShiftでの活用例

MetalLBを利用することで、オンプレミス環境においても外部からサービスにアクセス可能なロードバランサーを提供でき、OpenShiftクラスターのネットワークをクラウドのように扱えるようになります。

2. Multus: マルチネットワークの実現

役割

Multusは、KubernetesやOpenShiftで複数のネットワークインターフェースをPodに割り当てるためのCNI（Container Network Interface）プラグインです。デフォルトのネットワークに加え、追加のネットワークを柔軟に設定できます。

主な機能

• マルチネットワークの提供:
  1つのPodが複数のネットワーク（例: デフォルトネットワーク + ストレージ用ネットワークなど）を利用可能。
• カスタムネットワークの追加:
  例えば、SR-IOV（Single Root I/O Virtualization）やその他の特殊なネットワークを構成。
• ネットワーク分離の実現:
  セキュリティやパフォーマンス要件に応じたネットワークの分離。

主な構成要素

• NetworkAttachmentDefinition:
  カスタムリソースとして定義され、Podにアタッチされる追加ネットワークの仕様を記述。

OpenShiftでの活用例

• ネットワーク分離:
  フロントエンドとバックエンド用のネットワークを分離してトラフィックを最適化。
• 特殊用途のネットワーク:
  高性能なネットワークや外部ストレージとの通信専用ネットワークを構築。

まとめ

これらを組み合わせることで、オンプレミスのOpenShiftクラスターにおけるネットワークの柔軟性と拡張性を大幅に向上させることが可能です。

Create and useConfiguration Maps

目標

OpenShift管理者として、ConfigMapとそれがアプリケーション構成の管理にどのように役立つのか理解する。

＜概要＞
・Secretとの主な違いは、ConfigMapはデータをプレーンな状態で保存すること。
・機密ではない構成データをキーと値のペアとして保存するOpenShfitオブジェクト。
・構成情報を外部化して、Pod（アプリケーション）からアクセスできるようにする。
・ConfigMapを利用すると、構成情報をアプリケーションコードから分離できるため、独立して更新および管理することが用意になる。よって、OpenShiftデプロイメントのスケーラビリティ、保守性、柔軟性が向上する。

＜デモ＞
・新しいプロジェクトの作成

oc new-project configmap-demo

・nginxコンテナーのデフォルトWebページを保持するConfigMapを作成

vi index.html

oc create configmap nginx-config --from-file=index.html

・作成したConfigMapの確認

oc describe cm nginx-config

・nginxのPodをデプロイして、作成したConfigMapにマウントする

vi cm-nginx-pod.yaml

oc create -f cm-nginx-pod.yaml

oc get pods

・作成したnginxのPodへWebアクセス

oc port-forward nginx-pod 8080:8080

localhost:8080

Persistent Storage

目標

OpenShift管理者として、永続ストレージとはなにか、それによってどのようなプロビジョニングが可能になるのかを理解する。

＜概要＞
・OpenShiftでアプリケーションを実行する場合、ストレージは重要
・アプリケーションでは、Podの再起動とデプロイメント後も保持されるデータを保存し、アクセスする必要がある。→だから永続ストレージが必要なわけ。
・デフォルトでは、Podファイルシステムに保存されるデータは一時的。つまり、Podが再起動されるとデータは失われる（揮発性）。
・永続ストレージは、独立してデータを保存する方法を提供することで、この問題を解決する。
・ブロックストーレジは、従来のハードドライブと同様にPodに接続できる生のブロックを提供する（例：AWS、EBSなど）。データベースアクセスなど低遅延のアプリケーションに適している。
・ファイルストレージは、ファイルシステムによってサポートされており、Podにマウント可能（例：HostPath、ローカルファイル、NFSなど）。ファイルストレージは、コンテンツ管理などのファイルへの共有アクセスが必要なアプリケーションに適している。
・永続ボリューム（PV）と永続ボリュームクレーム（PVC）が重要なコンポーネント。
・永続ボリューム（PV）：管理者が用意する実際に利用できるストレージ定義
・永続ボリュームクレーム（PVC）：開発者が要求するストレージ定義。必要なアプリケーションのストレージ要件などを指定する。
→PVCを通じてストレージを要求し、OpenShiftが割り当てとバインドプロセスを処理してくれる。

＜デモ：永続ボリュームを作成および構成し手動でPodに接続するお＞
・デモ用のプロジェクトを作成

oc new-project persistent-storage-demo

・永続ボリュームのプロビジョニング（コアOSホストのディレクトリでお試し）

oc get nodes

oc debug node/crc

sh-5.1# chroot /host

sudo mkdir /mnt/data1

echo "<h1>persistent storage demo!</h1>" > /mnt/data1/index.html

ls -laZ /mnt/data1

chcon -Rt svirt-sandbox_file_t /mnt/data1

ls -laZ /mnt/data1

exit

・PVの作成 ※管理者権限で

vi pv.yaml

oc create -f pv.yaml

oc get pv

・PVCの作成

vi pvc.yaml

oc create -f pvc.yaml

oc get pvc

・Podの作成（作ったpvcを利用したやつ）

oc apply -f persistent-pod.yaml 

oc describe pod my-pod

・作成したnginxのPodへWebアクセス

oc port-forward nginx-pod 8080:8080

localhost:8080

Storage Classes

目標

OpenShift管理者として、ストレージクラスの概念を理解する。

＜概要＞
・ストレージクラスを定義することで、それぞれに独自の特性を持つ様々なストレージオプションを開発者に提供することできる。

＜デモ＞
ストレージクラスと永続ボリューム要求を作成する方法を学ぶ。
→Webコンソール上から、新しいプロジェクトの作成→ストレージクラスの確認（１つしかない）→PVCの作成→yamlをインポートしてPodを作成して、PVCで定義したとおりストレージを参照していることを確認

→ストレイジクラスは、基盤となるストレージインフラストラクチャーを抽象化するのが一番の役目。ストレージの割り当てに便利。

StatefulSets

目標

OpenShift管理者として、ステーテトフルセットの概念と、それを使用して管理する方法について理解する。

＜概要＞
・ステートフルセットは、安定したIDと永続的なPodのセットをデプロイおよび管理する方法を提供する。
・Podが再スケジュールされても同じままになる永続的なホスト名が必要な際に有効？
・また、ステートフルセット上各Podは専用のストレージを取得し、データがそのまま残り、共有されないようにする。
→展開とスケーリングに関して永続データに依存するアプリケーションにとって非常に重要です。

Configuring Network Components

目標

OpenShift管理者として、ネットワークオペレーターとプラグインについて理解を深める。

OpenShfitSDN

＜概要＞
・OpenShfitSDN
→コントロールプレーンとデータプレーンの2つの主要部分で構成されている。

＜デモ＞
・ネットワークプラグインを含むクラスターのネットワーク構成を表示

oc get network.conf/cluster -o yaml

・DNSオペレーターの情報を表示

oc describe dns.operator/default

・お試し用の新規プロジェクト作成

oc new-project network-demo

・クラスターIPサービスの作成

oc create service clusterip myservice --tcp=80:80

・Serviceが作成されたことの確認

oc get service myservice

・DNS名を確認する

oc run busybox --image=busybox --restart=Never --command -- sleep 3600  

oc exec busybox -- nslookup myservice.network-demo.svc.cluster.local 

OVN-Kubernetes

＜概要＞
・OpenShiftのデフォルトのネットワークプロバイダーであり、オーバーレイベースのネットワークキングを活用する。
・各ノードでオープンVswithcを構成して、宣言されたネットワーク構成を実装する。
・OpenShift SDNプラグインとOVN-KubernetesはどちらもOVSと集中IPアドレス管理を利用します。
→違いと用語がいまいち理解できない・・・。

Create and edit external routes

目標

OpenShift管理者として、外部ルートの作成と編集方法ついて理解を深める。
※この動画、字幕がねぇ・・・。くしょがぁ・・・。

＜デモ＞
・新しいプロジェクトの作成

oc new-project route-demo

・apacheのPod作成

oc new-app bitnami/apache

・動作しているServiceを確認

oc get services

・既存のリソース（通常はServiceやPod）に対して外部アクセスを可能にするルート（Route）を作成

oc expose service apache --hostname=myapp.apps-crc.testing

・Routeが作成されているか確認

oc get routes

・ちゃんとカスタムホスト名でアクセスできるか確認

curl myapp.apps-crc.testing

・Route リソースの編集(myapp.apps-crc.testing→my-app.apps-crc.testing)

oc edit route apache

・Route リソースが編集されていることを確認

oc get routes

Secure traffic using TLS certificates

目標

OpenShift管理者として、TLS証明書を使用して外部トラフィックと内部トラフィックを保護する方法について理解する。

＜概要＞
・TLS証明書を使用して外部トラフィックと内部トラフィックを保護することは必要不可欠
・さまざまな種類のルートとそのTLS構成を理解することが重要

＜デモ：エッジルートシナリオでトラフィックを保護するための自己証明書を生成する＞
・デモ用の新しいプロジェクトの作成

oc new-project tls-demo

・RSAキーペアを生成

openssl genrsa -des3 -out myca.key 2048                                                                     ```

・CAの公開キー証明書を作成

openssl req -x509 -new -key myca.key -sha256 -days 3650 -out myca.pem
※Common nameはcrc.exaple.com

・Routeのカスタムキーを作成

openssl genrsa -out tls.key 2048

openssl req -new -key tls.key -out tls.csr
※Common nameはsecureapp.apps-crc.testing

・CA証明書とキーを使用してCSRを割り当て、最終的な署名付き証明書を生成する

openssl x509 -req -in tls.csr -CA myca.pem -CAkey myca.key -CAcreateserial -out tls.crt -days 1650

・証明書が作成されたことの確認

ls *.crt

・TLS証明書を使用してセキュリティを保護するサンプルアプリケーションのデプロイ

oc new-app --name=secureapp --image=bitnami/apache

・デプロイされたことの確認

oc get all

・エッジルートを作成し、作成したアプリケーションに関連づける

oc create route edge --service=secureapp --hostname=secureapp.apps-crc.testing --cert=tls.crt --key=tls.key

・HTTPSリクエストの送信

curl -v https://secureapp.apps-crc.testing -k

・TSL構成情報を確認

oc describe route secureapp

oc get route secureapp -o yaml

Controlling Ingress

目標

OpenShift管理者として、クラスターネットワークのIngress制御について理解する。

＜概要＞
・外部からクラスターへ要求されたサービスに基づいて外部トラフィックを特定のサービスにルーティングするためのルールを定義する方法を提供する。
→OpenShiftにおいて、RouteとIngressの使い分けがよくわからない。。。

＜デモ＞
・デモ用のプロジェクトを作成

oc new-project ingress-demo

・お試し用のアプリケーションをデプロイ

oc new-app githubで公開されているパス・・・

・Ingress オブジェクトの作成

oc create ingress web-ingress --rule="mywebsite.apps-crc.testing/*=mywebsite:8080"

・作成したIngress オブジェクトの確認

oc get ingress

ヘルスプルーブ

目標

OpenShift管理者として、ヘルスプルーブについて理解する。

＜概要＞
・Probeはコンテナが適切に機能し、受信トラフィックを処理できることを保証し、それによってOpenShiftを有効にします。
・Health Probeには２タイプある
・LivenessProbe：コンテナが期待通り実行され、機能しているかを判断。失敗した場合、コンテナを自動再起動する。
・ReadinessProbe：コンテナが受信トラフィックを処理できるかどうかを判断。失敗した場合、準備が整うまでコンテナへのトラフィックのルーティングを停止します。この動作はアプリケーションの起動中、またはコンテナがリクエストを処理できない場合に特に役立つ。
・Probeタイプもいくつかある
→HTTP GET
→TCP Socket
→Exec　などなど

＜デモ：LivnessProbe＞
・お試し用のプロジェクトを作成

oc new-project probe-demo

・以下を実行するコンテナを作成する

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600

・Podをapply

oc apply -f liveness.yaml

・livenessの状態を出力（applyしてから30秒以内）

oc describe pod liveness-exec

・livenessの状態を出力（30秒以上たってからもう一度実行。killされていることがわかる。）

oc describe pod liveness-exec

・Podが再起動していることを確認

oc get pod liveness-exec

Reserve and limit application compute capacity

目標

OpenShift管理者として、コンテナ、CPU、メモリリソースを割り当てて制限する方法を理解する。

＜概要＞
・リソースリクエスト：コンテナが適切に実行されるための最小のCPUおよびメモリリソースを定義。
OpenShiftは、要求されたリソースがコンテナに割り当てられることを保証する。イメージは、コンテナに必要なリソースを予約する方法ととらえる。
・リソースリミット：コンテナのCPUリソースとメモリリソースの最大量を定義する。コンテナがその最大量を超えてリソースを利用しようとした場合、OpenShiftはコンテナのリソース使用量を制限する場合がある。コンテナが過剰なリソースを消費してパフォーマンスに影響を与えるのを防ぎます。
→リクエストにより、コンテナが機能するために必要な最小限のリソースが確実に確保され、リソース制限により、コンテナがリソースを過剰に消費するのを防ぐ。
→効率的に実行するために必要なリソースを確保し、リソースの競合や過剰使用を防ぎます。

＜デモ＞
・デモ用プロジェクトの作成

oc new-project demo-capacity

・deployment.yamlの作成

vi deployment-capacity.yaml

・deployment.yamlの適用

oc apply -f deployment-capacity.yaml

・Podの確認

oc get pods

oc describe pod <deployment-name>

・Podのリソースをコマンドで変更

oc set resources deployment dep-capacity --limits=memory=5Mi --requests=memory=1Mi

・Podの確認

oc get pods

oc get rs

oc describe pod <deployment-name>
※古い方と新しくできた（起動できていないPod）を見比べる

・yaml定義も確認

oc get deployment dep-capacity -o yaml

・Podのリソースをコマンドで変更

oc set resources deployment dep-capacity --limits=memory=50Mi --requests=memory=1Mi

・Podの確認

oc get pods

Scaling applications

目標

OpenShift管理者として、アプリケーションをスケーリングしてトラフィックの増加に対処する方法を理解する。

＜概要＞
・アプリケーションを効果的にスケーリングすることで、負荷の増加に対処できるようになる。
・手動スケーリング：観察や予測に基づいて、アプリケーションのレプリカ数を調整するなど。人間の介入が必要で、ワークロードが予測可能なシナリオに適している。または、スケーリングプロセスを完全に制御したい場合。
・水平ポッド自動スケーリング：観察されたCPU使用率に基づいてレプリカ数を自動的に調整する。ワークロードが変動するアプリケーションに適しており、自動スケーリングベースのメリットを得ることができる。

＜デモ＞
・デモ用の新しいプロジェクトを作成する

oc new-project scaling-demo

・アプリケーションの作成

oc new-app name=nginx --image=bitnami/nginx

・アプリケーションの状態確認

oc get all

・Podの数を1から3にする

oc scale deployment/nginx --replicas=3

・Pod数を確認

oc get pods

・Podの数を3から2にする

oc scale deployment/nginx --replicas=2

・Pod数を確認

oc get deployments

→Webコンソール上からも簡単にPod数を変更することができる。
・デプロイメントコントローラーまたはレプリケーションコントローラーの自動スケーリングを有効化

oc autoscale deployment/nginx --min=1 --max=10 --cpu-percent=50

Managing Image Streams

目標

OpenShift管理者として、イメージストリームとその使用法、および作成および管理するための関連CLIコマンドについて理解する。

＜概要＞
・OpenShiftでは、イメージレジストリを直接操作せず、代わりにイメージストリームリソースを抽象化レイヤーとして使用することができる。
・デプロイメントを基盤となるコンテナレジストリから分離し、追跡、管理、イメージの更新をシームレスにトリガーします。
・イメージストリームは、イメージリポジトリの仮想表現として考えられ、イメージリポジトリへのポインタとして機能します。
・アプリケーションイメージのさまざまなバージョンまたはリリースにタグを付けて、参照しやすくすることができます。
・イメージストリームタグは、時間の経過とともにポイントしたイメージ履歴も保持します。この履歴レコードによりロールバックが容易になり、タグを以前のバージョンに戻すことができる。

＜デモ＞
・デモ用のプロジェクトを作成

oc new-project imagestreams

・DockerHubのコンテナイメージを使用して新しいアプリケーションを作成する（テスト）

oc new-app --image=bitnami/nginx --name=test -o yaml

・DockerHubのコンテナイメージを使用して新しいアプリケーションを作成する

oc new-app --image=bitnami/nginx --name=test

・全リソース確認

oc get all

・イメージストリームの詳細を確認（testというストリーム名）

oc get is test

・イメージストリームの完全なyamlマニフェストを表示するため、yamlフラグを追加

oc get is test -o yaml

・イメージストリームを作成

oc create imagestream myapache

・Dockerレジストリのイメージに2.4.59タグを付けてイメージストリームに追加する。

oc tag docker.io/bitnami/apache:2.4.59 myapache:2.4.59

・イメージストリームタグの詳細を確認

oc describe istag/myapache:2.4.59

・イメージストリームのイメージルックアップを有効にする

oc set image-lookup myapache

・イメージストリームをクエリして、オプションが設定されているかどうかを確認する。

oc set image-lookup imagestream --list

Using Tags and Digests to Identify Images

目標

OpenShift管理者として、イメージタグとダイジェストを使用してコンテナイメージを識別する方法を理解する。

＜概要＞

• イメージタグ
  ・イメージの特定のバージョンまたはバリエーションに割り当てることができる人間が判読できるラベル
  ・アプリケーションのさまざまなバージョンを参照および管理するための便利な方法を提供します
  ・タグは一般的に、最新、安定版、バージョンなど、開発のさまざまな段階を表すために使用されます
  ・イメージタグは変更可能。イメージが特定のタグに関連づけられており、更新または上書きが可能。
• ダイジェスト
  ・イメージの一意で不変の識別子を提供する
  ・ダイジェストはイメージのコンテンツの暗号化ハッシュであり、特定のイメージを一意に識別することを保証する
  ・信頼性を提供し、期待通りのイメージバージョンを確実に使用できるようにする
  ・ダイジェストを使用すると、展開のセキュリティと信頼性が強化される
  ・ダイジェストによってイメージを参照すると、異なる環境間で同じイメージが確実に使用される。
  ・タグのみに依存する場合に、意図しない変更や不一致が発生するリスクが排除される。
  ・新しいバージョンを使用するたびに展開構成を更新する必要がある。このプロセスを簡素化するために、イメージストリームを使用すると、イメージバージョンの管理と追跡が可能になる。

＜デモ：タグとダイジェストを使用してイメージを識別する方法を確認する＞
・デモ用のプロジェクトを作成

oc new-project image-demo

・httpdという名前のイメージストリームを作成

oc create imagestream httpd

・外部レジストリからイメージストリームにイメージを追加し、タグ付けする

oc import-image httpd:2.4.58 --from=docker.io/bitnami/apache:2.4.58 --confirm

・最新のタグをイメージストリームの2.4.58バージョンに追加する

oc tag httpd:2.4.58 httpd:latest

・イメージストリームの詳細を確認

oc describe is httpd

・ダイジェストの更新

oc tag docker.io/bitnami/apache:2.4.59 httpd:2.4.59

oc tag httpd:2.4.59 httpd:latest

・アプリケーションの作成（httpdイメージストリームの最新タグを使用して作成）
　※この方法だと予期せぬタイミングでダイジェストが変わってしまうので一貫性が失われる。

oc new-app --image=httpd:latest --name=webapp

・ダイジェストの取得

oc get istag httpd:2.4.58

・取得したダイジェストでアプリケーションを作成

oc new-app --image=＜ダイジェスト＞ --name=webapp2

・デプロイメントの詳細を確認

oc describe deployment webapp2

Using Triggers to Manage Images

目標

OpenShift管理者として、トリガーを使用してOpenShiftでイメージを管理する方法を理解する。

＜概要＞
・トリガーは、展開プロセスを自動化し、アプリケーションを確実に最新の状態に保つために重要。
・最新のイメージ変更により、イメージ変更トリガーがコンテナをどのように合理化できるかに焦点を当てます。
・特定のイベントまたは条件に基づいてアクションを自動的に実行できるようになります。
・これにより、アプリケーションのライフサイクルのさまざまな側面（構築、デプロイ）、または、特定のトリガーに応じてアプリケーションをスケーリングします。
・最も一般的に使用されるトリガーの1つは、イメージ変更トリガーです。
・画像変更トリガーは、画像ストリーム内の変更を自動的に検出し、トリガーするように設計されています。更新されたイメージを使用したアプリケーションの新しいデプロイメント。これにより、アプリケーションは常に最新バージョンのイメージを使用して実行されます。
・トリガーを使用してイメージを管理する場合は、イメージストリームタグを更新する必要がある。新しいアプリケーションイメージバージョンがある場合は、それをイメージストリームにプッシュし、関連するイメージバージョンを更新できます。

＜デモ：トリガーを使用してイメージとOpenShiftを管理する方法を確認する＞
・デモ用のプロジェクト作成

oc new-project trigger-demo

・イメージストリームの作成

oc create imagestream apache

・外部レジストリからイメージストリームにイメージを追加し、最新としてタグ付けする

oc import-image apache:latest --from=docker.io/bitnami/apache:2.4.57 --confirm

・作成したイメージストリームを用いて、新しいデプロイメントを作成する

oc new-app apache:latest --name=myapache

・yaml定義を調べて、デプロイメントにイメージ変更トリガーが含まれていることを確認

oc get deployment myapache -o yaml

・apacheイメージの新しいバージョンが利用可能なシナリオをシミュレートしてみる。新しいイメージをイメージストリームにプッシュし、新しいバージョンを参照するように最新タグを更新する。

oc tag docker.io/bitnami/apache:2.4.58 apache:latest

・デプロイメントの変化を確認

oc get pods

・yamlからデプロイメントを作成し、イメージ変更トリガーを構成する方法を検討する。
　まず、yamlファイルの作成。

vi image-trigger.yaml

・yamlからデプロイメント

oc create -f image-trigger.yaml

・デプロイメントの確認

oc get deployments

oc get deployments myapp -o yaml

・イメージ変更トリガーを構成する

oc set triggers deployment/myapp --from-image=apache:latest -c myapp 

・デプロイメントの確認

oc get deployments myapp -o yaml

・apacheイメージの新しいバージョンが利用可能なシナリオをシミュレートしてみる。新しいイメージをイメージストリームにプッシュし、新しいイメージを参照するように最新のタグを更新できる。

oc tag docker.io/bitnami/apache:2.4.59 apache:latest

・デプロイメントの変化を確認

oc get pods

手動介入なしでアプリケーションが最新のイメージバージョンと同期した状態を維持できる様子を理解。

Rolling back failed deployments

目標

OpenShift管理者として、失敗したデプロイメントをロールバックしてアプリケーションを復元する方法を理解する。

＜概要＞
・OpenShift上でアプリケーションをデプロイすると、各デプロイメント履歴が追跡される。
・デプロイするたびに、一意のリビジョン番号を付与することで実現しているもの。
・ロールバック中に、失敗したデプロイメントに関連づけられたPodを終了し、それらを、指定されたリビジョンを実行する新しいPodに置き換えます。

＜デモ＞
・デモ用のプロジェクを作成

oc new-project rollback

・デプロイメント用のyamlを用意

vi rollback-deployment.yaml

・デプロイメントの適用

oc apply -f rollback-deployment.yaml

・ステータスの確認

oc get all

oc get pods

・デプロイメント用のyamlを変更（イメージバージョンを更新）

vi rollback-deployment.yaml

・デプロイメントの適用

oc apply -f rollback-deployment.yaml

・デプロイメント履歴と利用可能なリビジョンを表示

oc rollout history deployment/myapp

・デプロイメントをロールバックする

oc rollout undo deployment/myapp --to-revision=1

・ステータスの確認

oc get pods

oc describe pod <deployment-name>

Creating and Configuring Service Accounts

目標

OpenShift管理者として、サービスアカウントの作成の目標と、構成と設定方法について理解する。

＜概要＞
・サービスアカウントは、Podやアプリケーションなどのコンポーネントがアクセスできるようにするアカウントを指す（APIを利用する）。
・サービスアカウントは、各プロジェクト内のAPIオブジェクトであり、APIアクセスを制御する柔軟な方法提供する。

＜デモ（サービスアカウントの作成および構成する）＞
・デモ用の新しいプロジェクトの作成

oc new-project service-account-demo

・サービスアカウントの作成

oc create sa my-demo-sa

・作成したサービスアカウントを表示ロールにバインドして、サービスアカウントに表示権限を付与する。
※my-demo-saサービスアカウントを使用するPodには、プロジェクト内の表示権限が与えられる。

oc policy/add-role-user view -z my-demo-sa

・現在のプロジェクト内のすべてのサービスアカウントを一覧表示することで、サービスカウントが作成されたことを確認できる。

oc get sa

oc describe sa my-demo-sa

・新しく作成したサービスアカンウトを使用するPodを作成

vi my-demo-pod.yaml

oc apply -f my-demo-pod.yaml

・Podがサービスアカウントを使用していることを確認

oc get pod my-demo-pod.yaml -o yaml | grep service

・サービスアカウントの削除

oc delete sa my-demo-sa

Managing and applying permissions using security context constraints

目標

OpenShift管理者として、セキュリティコンテキストの制約を使用してアクセス許可を管理するおよび適用する方法を理解する。

＜概要＞
・SCCは、Podのアクションとアクセスできるリソースを決定します。
・デフォルトのSCCの変更は、問題が発生する可能性があるため推奨されない
・特定の要件に合わせてSCCを作成および変更することがベストプラクティス
・SCCを使用すると、特権コンテナーの実行など、Podセキュリティのさまざまな側面を制御できる。

＜デモ（サービスアカウントを作成して構成し、SCCを適用する方法を試す）＞
・デモ用の新しいプロジェクトを作成

oc new-project scc-demo

・apacheアプリケーションの作成

oc new-app dockr.io/httpd

・アプリケーションのステータスを確認

oc status

oc status --suggest

※アプリケーションをrootユーザーとして実行できなかったため、デプロイメントは失敗しているはず
・サービスアカウントを作成し、それに任意のUID SCCを付与する（管理ユーザーで実行する必要あり）

oc whoami

oc create sa my-sa

・ユーザーコマンドにCCを追加し、サービスアカウントに任意のUID SCCを付与

oc adm policy add-scc-to-user anyuid -z my-sa

・作成したサービスアカウントを使用するようにデプロイメント構成を変更する

oc patch ※長いので実際やる時にビデオ見直し

・アプリケーションが正常に実行されていることを確認

oc get pods

oc status

・パッチではなくsetコマンドを使ったサービスアカンウト適用方法

oc set sa deployment/httpd my-sa

・アプリケーションが正常に実行されていることを確認

oc get pods

oc status

Running Privileged Applications

目標

OpenShift管理者として、コンテナの実行権限について理解する。

＜概要＞
・OpenShiftではデフォルトでrootとしてコンテナを実行することを拒否する。
・野良コンテナイメージはrootとしてコンテナを実行できてしまう。柔軟な操作が可能である一方でセキュリティに懸念が残る。
・一方、bitnamiなど一部のプロバイダーが提供するコンテナイメージは非rootでないと実行できないように設計されている。（RedHatなども同様）
→最小特権の原則により、あらゆるセキュリティの潜在的な影響が制限され、セキュリティが強化されます。
・非rootコンテナはデフォルトで、1024より高いポートのみにバインドできる。1024未満のポートは特権ポートとみなされ、それらにバインドするには特権が必要。

＜デモ（bitnami/apacheのhttpサーバーイメージを使用して非rootコンテナを実行し、その様子を観察する）＞
・デモ用のプロジェクトを作成する

oc new-project privileged

・新しいアプリケーションの作成

oc new-app bitnami/apache

・ステータスチェック

oc get all

・サービスの公開

oc expose svc/apache

・作成したapacheアプリケーション用に作成されたサービスを確認する（Route）

oc get route

Configuring Application Access to Kubernetes APis

目標

OpenShift管理者として、KubernetesAPIへのアプリケーションアクセス構成について理解する。

＜概要＞
・サービスアカウント、セキュリティ、コンテキスト制約、ロールベースのアクセス制御が重要。
・Kubernetesのサービスアカウントは、プロジェクト内で実行されるアプリケーションIDを指す。アプリケーションがKubernetesシステムのどの部分と対話できるかを制御するPodは非常に重要。
・APIサーバーと通信するときは、サービスアカウントを使用して認証します。
・RABCを使用すると、クラスター内で実行できるプロセスまたはアプリケーションへのアクセスを認証および制限できる。ロールとロールバインディングを利用することによって。
・サービスアカウントに付与されるこれらの特定のアクセス許可を定義して、アプリケショーンが確実に必要なリソースとアクションのみにアクセスできます。
・デフォルトのサービスアカウントに追加のアクセス許可を割り当てることは推奨されない。追加した権限がプロジェクト内のすべてのPodに拡張される、セキュリティリスクがあるため。
・通常作成するPodはデフォルトの設定でも問題なし。ただし、オペレーターやアプリケーション監視アプリなどの一部のインフラストラクチャ関連のワークロードは、KubernetesAPIアクセスを構成する必要があるケースも。

＜デモ（サービスアカウントを使用してアプリケーションにKubernetesAPIアクセスを許可する方法を観察）＞
・デモ用の新しいプロジェクトを作成

oc new-project demo-app

・アプリケーション用の新しいサービスアカウントを作成

oc create sa my-app-sa

・作成したサービスアカウントを利用する新しいアプリケーションを作成

oc new-app --name=my-app --image=bitnami/nginx

・作成したサービスアカウントと作成したアプリケーションを紐づける

oc set sa deployment my-app my-app-sa

・別のプロジェクトを作成

oc new-project demo-api

・作成したプロジェクトのビュークラスターロールをサービスアカウントに割り当てる。ビューロールは読み取り専用とする。

oc adm policy add-role-to-user view system:serviceaccount:demo-app:my-app-sa -n demo-api

Module Introduction

目標

OpenShift管理者として、オペレーターを効果的に管理する方法を理解する。

＜概要＞
・crdは、オペレーターが新しい定義を行うことでKubernetes機能を拡張できるため、基本的なものです。これがないと、オペレーターは複雑なアプリケーション構成を表現および管理する方法がない。
・crdが青写真でcrsが特定オブジェクトの状態
・OAMが他のオペレーターを管理するスーパーオペレーター
・OAMはOpenShiftHub上から他の追加できるオペレーター情報を提供する。Webコンソールから簡単にオペレーターを追加できるようになっている。

試験の準備

時間管理が重要

・試験は3時間続くため、効果的に準備するには時間管理が必要不可欠
・通常15問で構成されており、すぐに答えられる質問もある。1問あたり、10分〜15分で回答する必要がある。
・試験を始める前に、回答順など計画するほうがいい。たとえば、自信を高めて節約するために、より単純な問題から回答し始めるなど。
・1つの問題にあまり時間を費やさないこと。行き詰まった場合は、次に進み、時間があれば後で戻ってくればいい。

目標セクションで言及されているトピックに焦点を当てる

・目標セクションで言及されているトピックが出題内容の中核となる。
・製品ドキュメントのすべてを押さえておく必要はない。
・DO180トレーニングが前提条件になっている点も注意。

実務経験の重要性

・試験に調整する前に、少なくとも1〜２ヶ月のOpenShiftの実務経験があった方がいい。

ハンズオンの重要性

・なによりもハンズオンによる練習が不可欠。
・OpenShiftを操作すればするほど、その機能とコマンドがより使いやすくなる。
・CLIとWebコンソール、両方操作できるようにしておく。

OpenShift特有の概念に慣れておく

・Route、イメージストリーム、OAuthサーバなどOpenShfit特有の概念について理解しておくこと

製品ドキュメントから必要な情報を抜き出せるように

・試験中、ローカルで製品ドキュメントを閲覧できるが、必要な情報をゆっくり探す時間はない。必要な情報にすぐアクセスできるように練習しておくこと。特に複雑なyaml構成へアクセスなど。
・HTMLバージョンとHTMLバージョンの両方をよく理解していおくこと。どっちが試験中に簡単かつ効率的に利用できるのかよく確認しておく。
・試験中に利用できるHTMLバージョンは側面に索引がないことに注意。
・検索機能が制限されているので厳しいかも。
・HTMLとPDFが見れますが、HTMLだと重くて全然開きません。PDFで見た方がよい。
・helpコマンドのほうが早いかも？

その他

・問題で求められている要件をよく読み取ること。結構、微妙な要件を求めていることがある。たとえば、既存のコンポーネントを追加または変更するのではなく変更するなど、特定の指示に注意すること。
・ユーザーの権限とアクセスを扱う場合は、常にソリューションを検証すること。
・とにかく落ち着いて取り組むこと。難しいタスクに遭遇した場合は、深呼吸して質問を読み直し、論理的に対処する。
・身分証と、飲み物をわすれずに。ペットボトルのラベルを外して持っていく。あと、RedHatアカウントIDとパスワードも控えておくこと。
・試験開始時刻の15分ほど前からアクセスが可能になりますので、試験会場へは早めに到着するように
・ブラウザではctrl+cでコピー、ターミナルにはctrl+shift+vでペーストできます。

ネット上の声

https://zenn.dev/gashirar/articles/d44d77ea058418
https://qiita.com/Osbrewery/items/5be049cf755e37a3d151
https://qiita.com/dingtianhongjie/items/84979249f8ddc9f063e9
https://k8sinfo.com/2021/03/08/ex280-difficulty/

試験中に使えるマニュアル

https://docs.openshift.com

試験の練習：OpenShift Container Platform の管理⭐️

出題範囲

• Web コンソールを使用して、OpenShift クラスタを管理および構成する
• コマンドライン・インタフェースを使用して、OpenShift クラスタを管理および構成する
• Kubernetes リソースの属性のクエリ、フォーマット、フィルタリングを行う
• Kubernetes リソースをインポート、エクスポート、設定する
• コンテナイメージを見つけて調べる
• プロジェクトを作成して削除する
• リソースとクラスタのステータスを確認する
• ログを確認する
• クラスタイベントとアラートを監視する
• OpenShift クラスタの健全性を評価する
• 一般的なコンテナ、ポッド、クラスタイベントとアラートのトラブルシューティングを行う
• 製品マニュアルを使用する

メモ

• 主にocコマンドの利用方法などを学ぶ
• 製品ドキュメントの検索方法になれておく
• helpコマンドで必要な情報を検索できるようになっておくこと

https://docs.openshift.com/container-platform/4.14/cli_reference/openshift_cli/getting-started-cli.html

試験の練習：アプリケーションのデプロイ

出題範囲

• リソースマニフェストからアプリケーションをデプロイする→oc create deployment --name=my-app --image=bitnami/nginx --save-config -o yaml > my-deployment.yaml
• Kustomize オーバーレイを使用してアプリケーション設定を変更する
• イメージ、OpenShift テンプレート、Helm チャートからアプリケーションをデプロイする
• ジョブをデプロイして 1 回限りのタスクを実行する→oc create job onetimetask --image=bitnami/nginx --list
• アプリケーション・デプロイメントを管理する→oc rollout など
• レプリカセットを操作する→oc scall --replicas=3など
• ラベルとセレクターを操作する
• サービスを設定する
• HTTP アプリケーションと非 HTTP アプリケーションを外部アクセスに公開する→oc expose,oc get routeなど。外部へ公開するにはServiceが必要なので、アプリケーションはoc new-appコマンドで作った方がよい（一緒にServiceを作ってくれるので）。
• MetalLB や Multus などの Operator を操作する

メモ

https://docs.openshift.com/container-platform/4.14/applications/creating_applications/creating-applications-using-cli.html#applications-create-using-cli-image_creating-applications-using-cli
https://docs.openshift.com/container-platform/4.14/applications/working_with_helm_charts/configuring-custom-helm-chart-repositories.html
https://docs.openshift.com/container-platform/4.14/nodes/pods/run_once_duration_override/run-once-duration-override-release-notes.html

試験の練習：アプリケーション設定およびデータのストレージの管理⭐️

出題範囲

• シークレットを作成して使用する→oc create secret　Podへの適用やyamlじゃなくて、oc runで--dry-runしてからが楽かも。oc set env --from=secret/mysecret deploymnet/myappでいける？
• 構成マップを作成して使用する→oc create configmapで作って、oc create -f yamlで適用する。yamlはドキュメントみて作る。
• ブロックベースおよびファイルベースのデータ用に永続ストレージボリュームをプロビジョニングする→hostPathを作成→oc create -f pv.yaml（内容はドキュメント参照）→oc create -f pvc.yaml（内容はドキュメント参照）でおけ。コンテナへログインが必要な場合は、oc exec -it -- /bin/bash
• ストレージクラスを使用する
• StatefulSet を使用した非共有ストレージを管理する

メモ

https://docs.openshift.com/container-platform/4.14/nodes/pods/nodes-pods-secrets.html#nodes-application-secrets-creating-using-sa_nodes-pods-secrets

https://docs.openshift.com/container-platform/4.14/nodes/pods/nodes-pods-configmaps.html

⭐️↓これは場所覚えておく。必ず使う。
https://docs.openshift.com/container-platform/4.14/storage/persistent_storage/persistent_storage_local/persistent-storage-hostpath.html

https://docs.openshift.com/container-platform/4.14/storage/dynamic-provisioning.html

試験の練習：信頼性をもたらすアプリケーション設定

出題範囲

• 正常性プローブを設定して使用する→ドキュメントを見ながらyamlを作って、oc apply -fなどで適用し、oc descirbeのイベントから成功を確認すればおけ
• アプリケーションのコンピューティング容量を予約および制限する→これはデプロイメント自体にlimitsとrequestsを設定してデプロイすることだけ。適当なyamlを作っておけ。oc set resourcesでセットしたほうがいいかも。
• 増加する要求に合わせてアプリケーションを拡張する→oc scale コマンドでレプリカセットを変更できればおけ。oc scale --replicas=3 deployment(or rs)/name あと、oc autoscaleコマンドを使って、自動でスケーリングする設定もできる。これはoc autoscale -hで例文でてくるから大丈夫。例文ではrs指定だけど、deployment指定にする（わざわざrs作らんから）。

メモ

https://docs.openshift.com/container-platform/4.14/applications/application-health.html

試験の練習：アプリケーション更新の管理

出題範囲

• タグとダイジェストを使用してイメージを識別する→oc get is isname,oc get isname -o yamlなどで確認できる。あとは、oc create imagestream myaphacheで新規作成も可能（-hで確認できるから暗記は不要）。イメージストリームにタグづけするこも必要：oc tag -hで調べられる（oc tag docker.io/bitnami/apache:2.4.59 myaphache:2.4.59） 。最後に、イメージストーリムを検索できるようにする：oc set image-lookup myapache
• 失敗したデプロイをロールバックする→oc rollout history deployment/myappなどでバージョンを確認→oc rollout undo dc/myapp --to-revision=3 的な感じで指定バージョンにロールバックできるお。
• イメージストリームを管理する→oc image-importでイメージストリームにイメージを追加できる。ダイジェストを使ってデプロイしないといけないことくらい？
• トリガーを使用してイメージを管理する→oc create imagestream myapacheでイメージストリームを作成→oc import-image apache:latest --from=docker.io/bitnami/apache:2.4.57 --confirm感じでイメージストリームにイメージをインポートしてタグ付け→oc tag docker.io/bitnami/apache:2.4.57 apache:latestでトリガーを起動してPodが再作成されることが確認できる。また、既存デプロイメントにはoc set triggersコマンドでトリガーをセットすることができる。(oc set triggers bc/webapp --from-image=namespace1/image:latest -webapp)

メモ

試験の練習：認証と認可の管理⭐️

出題範囲

• 認証用に HTPasswd ID プロバイダーを構成する→htpasswd -c -B -b <file.htpass> <username> <passwd>,oc create secret generic <secretname> --from-file=<htpasswd.filename> -n openshift-config,oc get oauth cluster -o yaml > oauth.yaml,oc replace -f oauth.yaml
• ユーザーを作成して削除する
• ユーザーのパスワードを変更する
• グループを作成して管理する→oc adm groups
• ユーザーおよびグループの権限を変更する→oc adm policy

メモ

• 認証用に HTPasswd ID プロバイダーを構成する⭐️→これは場所覚えておく。必ず使う。
  https://docs.openshift.com/container-platform/4.14/authentication/identity_providers/configuring-htpasswd-identity-provider.html
  →httpwdコマンドが利用できな場合、sudo yum install httpd-toolsを実行する。
  →プロバイダーを作成する際は、既存の定義をoc get oauth cluster -o yaml > oauth.yamlで引っこ抜くといい
  →CRを適用したら、oc get pods -n openshift-authenticationでpodが作成されていることを確認するとよい
• クラスター権限を構成し、デフォルトの権限を削除する⭐️→これは場所覚えておく。必ず使う。
  https://docs.openshift.com/container-platform/4.14/authentication/using-rbac.html#adding-roles_using-rbac

試験の練習：ネットワークセキュリティの設定⭐️

出題範囲

• ネットワークコンポーネントを設定する
• ソフトウェア・デファインド・ネットワークをトラブルシューティングする
• 外部ルートを作成して編集する→oc expose service apache --hostname=URL→oc get route→curl URL（ここまでは一緒）→oc edit route apache(これでホスト名を変更するとURLを変更できる：spec/host：〜を修正)
• クラスタネットワークの進入を制御する
• TLS 証明書を使用して外部および内部トラフィックを保護する→oc new-app --name=tls-app --image=bitnami/nginx→oc create route edge --service=tls-app --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com →curl -vk https://www.example.com
• アプリケーション・ネットワーク・ポリシーを設定する→oc create ingress simple --rule="foo.com/bar*=svc1:8080"→oc get ingress

メモ

https://docs.openshift.com/container-platform/4.14/networking/cluster-network-operator.html
https://docs.openshift.com/container-platform/4.14/networking/dns-operator.html
https://docs.openshift.com/container-platform/4.14/networking/routes/secured-routes.html

試験の練習：開発者のセルフサービスの有効化⭐️

出題範囲

• クラスタリソースクォータを設定する→oc create quotaでいけるお
• プロジェクトクォータを設定する
• プロジェクトのリソース要件を設定する
• プロジェクトの制限範囲を設定する
• プロジェクトテンプレートを設定する

メモ

• クラスタリソースクォータを設定する⭐️→これは場所覚えておく。必ず使う。
  https://docs.openshift.com/container-platform/4.14/scalability_and_performance/compute-resource-quotas.html

試験の練習：OpenShift Operator の管理

出題範囲

• Operator をインストールする
• Operator を削除する

製品ドキュメント

• Operator をインストールする
  https://docs.openshift.com/container-platform/4.17/operators/admin/olm-adding-operators-to-cluster.html
• Operator を削除する
  https://docs.openshift.com/container-platform/4.17/operators/admin/olm-deleting-operators-from-cluster.html

メモ

試験の練習：アプリケーションのセキュリティの設定

出題範囲

• サービスアカウントを設定して管理する→以下と同じ
• 特権アプリケーションを実行する→具体的なことはなく、非rootで実行することが大切だということ
• サービスアカウントを作成する→oc create sa my-demo-saで作成→oc policy add-role-to-user view -z my-demo-saでサービスアカウントにロールを付与する。→oc get sa で作成されていること、oc describe sa my-demo-saで内容を確認→サービスアカウントを利用するPodをデプロイする（yamlはドキュメントからもってくる。もしくはデプロイ後にoc set sa deployment/httpd my-saで適用する）
• セキュリティコンテキストの制約を使用してアクセス許可を管理し、適用する→oc create sa my-sa的な感じで、んービスアカウントを作成→oc adm policy add-scc-to-user anyuid -z my-sa的な感じでサービスアカウントにセキュリティコンテキストを適用する（anyuidなどはドキュメントを見て選択かな。もしくはoc get scc）→サービスアカウントを適用する：oc set sa deployment/httpd my-sa
• 機密情報を管理するためのシークレットを作成して適用する
• Kubernetes API へのアプリケーションアクセスを設定する→サービスアカウントの作成（oc create sa my-demo-sa）→アプリケーションの作成（oc new-app --name=my-app --image=bitnami/nginx）→アプリケーションにサービスアカウントを紐づける（oc set serviceaccount deployment my-app my-demo-sa ）→新しいプロジェクト作成（oc new-project demo-api）→作成したプロジェクトに参照権限を付与（oc adm policy add-role-to-user view system:serviceaccount:demo-app:my-app-sa -n demo-api）
• Kubernetes CronJob を設定する

メモ

https://docs.openshift.com/container-platform/4.14/authentication/bound-service-account-tokens.html
https://docs.openshift.com/container-platform/4.14/authentication/managing-security-context-constraints.html

Introduction to OpenShift Operators

目標

OpenShift管理者として、オペレーターとはなにか概要を理解する。

・オペレーターは、Kubernetes上で実行されているアプリケーションのスマートで自動化されたアシスタント。
・CRD（カスタムリソース定義）：オペレーターが新しい定義を行うことでKubernetes機能を拡張できるようにするための基本的なコンポーネント。
・CR（カスタムリソース）：CRDにもとづいて作成され動作する実際のインスタンス。オペレーターはCRD（定義）とCRの差異をチェックし、自動的に埋めようとしてくれる。
・OLM：オペレーターのインストール、最新の状態の維持、権限の管理などのタスクを処理してくれる。たとえば、クラスターサービスバージョン（CSV）を使用して、オペレーターの特定のバージョンを表してくれる。
・CSV（クラスターサービスバージョン）：オペレーターの使用や前提となるCRDや依存関係などが載っている。
・OperatorHub：Webコンソールから直接アクセスして、オペレーターの参照とインストールができる。
・CVO：クラスターオペレーターを管理するもの。OLMでは管理しない。

Operator Ecosystem

目標

OpenShift管理者として、オペレーターエコシステムのコンポーネントを理解する。

概要

・OLM：オペレーターエコシステムのさまざまな部分をすべて調整する指揮者のようなもの。
・サブスクリプション：クラスターにオペレーターをインストールするためのエントリポイント。
・CSV：オペレーターの名前、バージョンの説明、内容など、オペレーターに関する重要なメタデータが含まれている。特に重要な側面の1つは、オペレーターのインストール方法を指定していること。
・インストールプラン：もう1つの重要な要素はインストール計画です。サブスクリプションを作成すると、OLMによってインストールプランが生成される。オペレーターをインストールまたはアップグレードするために作成または更新する必要があるすべてのリソースの概要を説明する。CSVは設計図、インストールプランは構築計画と考えるとわかりやすい。
・オペレーターグループ：オペレーターのインストール範囲を決定するもの。オペレーターの監視範囲が、複数のプロジェクトにまたがるのか単体なのかもしくはクラスター全体かなど。
・カタログソース：インストールできるさまざなオペレーターのカタログを含む、リポジトリ。
・オペレーターハブ：Webコンソールのユーザーインターフェースコンポーネント。ユーザーがインストールするオペレーターを参照して選択できる。（カタログソースを参照している）
・パッケージサーバ：カタログソースとオペレーターハブの間の仲介として機能する。

サブスクリプション（デモ）

・サブスクリプションをチェックアウトする

oc get subscriptions -n openshift-logging

・Webコンソール上から確認
⇨「オペレーター」→「インストールされたオペレーター」ページへ移動
⇨ 該当のオペレーターを見つけて、クリック
⇨ サブスクリプションタブをクリックして情報を確認

CSV（デモ）

・CSV情報を表示

oc get csvs -n openshift-logging

・Webコンソール上でCSVを確認
⇨「オペレーター」→「インストールされたオペレーター」ページへ移動
⇨ 該当のオペレーターを見つけて、クリック
⇨ メインページに情報が掲載されている

インストールプラン（デモ）

・インストールプランの確認

oc get installplans -n openshift-logging

・Webコンソール上でインストールプランを確認
⇨「オペレーター」→「インストールされたオペレーター」ページへ移動
⇨ 該当のオペレーターを見つけて、クリック
⇨ サブスクリプションタブをクリックして情報を確認

オペレーターグループ（デモ）

・オペレーターグループの確認

oc get operatorgroups -n openshift-logging

・Webコンソール上でオペレーターグループを確認
⇨「オペレーター」→「インストールされたオペレーター」ページへ移動
⇨ すべてのオペレーターを表示させると掲載されている

カタログソース（デモ）

・カタログソースを確認する

oc get catalogsources -n openshift-marketplace

パッケージサーバ（デモ）

・利用可能なオペレーターを確認する

oc get packagemanifests -n openshift-marketplace

・Webコンソール上から確認
⇨ オペレーターハブセクションに表示される

試験の振り返り（20241220）

結果

項目

https://www.redhat.com/ja/services/training/red-hat-certified-openshift-administrator-exam?section=試験の内容

OpenShift Container Platform の管理

• Web コンソールを使用して、OpenShift クラスタを管理および構成する
• コマンドライン・インタフェースを使用して、OpenShift クラスタを管理および構成する
• Kubernetes リソースの属性のクエリ、フォーマット、フィルタリングを行う
• Kubernetes リソースをインポート、エクスポート、設定する
• コンテナイメージを見つけて調べる
• プロジェクトを作成して削除する
• リソースとクラスタのステータスを確認する
• ログを確認する
• クラスタイベントとアラートを監視する
• OpenShift クラスタの健全性を評価する
• 一般的なコンテナ、ポッド、クラスタイベントとアラートのトラブルシューティングを行う
• 製品マニュアルを使用する
  →情報を収集してログとして固めることができなかった・・・。うーん。。。

アプリケーションのデプロイ

• リソースマニフェストからアプリケーションをデプロイする：イマイチ
• Kustomize オーバーレイを使用してアプリケーション設定を変更する
• イメージ、OpenShift テンプレート、Helm チャートからアプリケーションをデプロイする：Helmができなかった・・・。
• ジョブをデプロイして 1 回限りのタスクを実行する
• アプリケーション・デプロイメントを管理する：いまいち
• レプリカセットを操作する：できた
• ラベルとセレクターを操作する
• サービスを設定する
• HTTP アプリケーションと非 HTTP アプリケーションを外部アクセスに公開する
• MetalLB や Multus などの Operator を操作する

アプリケーション設定およびデータのストレージの管理

• シークレットを作成して使用する：できた
• 構成マップを作成して使用する：できた？
• ブロックベースおよびファイルベースのデータ用に永続ストレージボリュームをプロビジョニングする：イマイチ・・・？
• ストレージクラスを使用する：できなかった・・・
• StatefulSet を使用した非共有ストレージを管理する

信頼性をもたらすアプリケーション設定

• 正常性プローブを設定して使用する：できた
• アプリケーションのコンピューティング容量を予約および制限する：できた
• 増加する要求に合わせてアプリケーションを拡張する：できた

アプリケーション更新の管理

• タグとダイジェストを使用してイメージを識別する
• 失敗したデプロイをロールバックする
• イメージストリームを管理する：できなかった？
• トリガーを使用してイメージを管理

認証と認可の管理

• 認証用に HTPasswd ID プロバイダーを構成する
• ユーザーを作成して削除する
• ユーザーのパスワードを変更する
• グループを作成して管理する
• ユーザーおよびグループの権限を変更する
  →もうちょい練習が必要

ネットワークセキュリティの設定

- ネットワークコンポーネントを設定する：できなかった・・・。
- ソフトウェア・デファインド・ネットワークをトラブルシューティングする
- 外部ルートを作成して編集する：できなかった・・・。
- クラスタネットワークの進入を制御する：できなかった・・・。
- TLS 証明書を使用して外部および内部トラフィックを保護する：できなかった・・・。
- アプリケーション・ネットワーク・ポリシーを設定する：できなかった・・・。

開発者のセルフサービスの有効化

- クラスタリソースクォータを設定する：できた

• プロジェクトクォータを設定する
• プロジェクトのリソース要件を設定する
  - プロジェクトの制限範囲を設定する：できた？
  - プロジェクトテンプレートを設定する：できなかった・・・。

OpenShift Operator の管理

• Operator をインストールする：できた？
• Operator を削除する

アプリケーションのセキュリティの設定

• サービスアカウントを設定して管理する：いまいち
• 特権アプリケーションを実行する
• サービスアカウントを作成する：いまいち
• セキュリティコンテキストの制約を使用してアクセス許可を管理し、適用する：いまいち
• 機密情報を管理するためのシークレットを作成して適用する：いまいち
• Kubernetes API へのアプリケーションアクセスを設定する
• Kubernetes CronJob を設定する：できなかった

よかったこと

• 予備試験を受験していたおかげで、試験形式に慣れた状態で挑むことができた
• 練習していた箇所については、確実にできるようになっていた（手応えあり）
• 体調管理をしっかりできたこと
• 会場に余裕をもって到着できたこと
• helpコマンドをちゃんと使えるようになったこと

いまいちだったこと

• 勉強ができていない範囲が多かった
• 勉強していた範囲でも練習不足が否めない箇所があった
• PROJECTという変数にコマンド実行結果をいれたり、情報収集するなど、実運用に通ずる問題ができなかった
• 時間管理が甘かった。かなり時間がない。ゆっくりガイドを見る時間はない。

その他

• トイレ休憩は結構簡単に取れるので、トイレの心配はそこまで必要なかった。

はじめること

• Udemyでの学習だけでなく、公式HP記載の項目1つ1つについてきちんと理解とハンズオンできるように練習する
• 研究というかもっと自分の疑問をつぶしていく感じで遊びまわる
• 学習と研究を継続するための仕組みづくり

やめること

• Udemyの内容をなぞるだけの学習

増やすこと

• ハンズオンと遊びまわる時間

減らすことこと

• 時間の浪費

次のアクション

• 次回試験の予約
• 学習と研究を継続するための仕組みづくり
• 次回試験までの計画を立てる