クラウド的なアレ

試験対策の時にざーーーーっと読み通した中で見たODO。OpenShift Doの略とのこと。 Announcing odo: Developer-focused CLI for Red Hat OpenShift - Red Hat Developer OpenShift Do (odo, for short) is a fast and straightforward C developers.redhat.com 第2章 Developer CLI (odo) 4.5 | Red Hat Customer Portal The Red Hat Customer Portal delivers the knowledge, expertise access.redhat.com とりあえず何者かが、ocはより（OpenShiftに近いという意味で）低レベル、それに対してodoはOpenShiftについて抽象度高くしてくれていて意識しなければいけないレベルが浅くなっている、というレベルの理解。それ以上はまだよくわかっていないのでざっくりドキュメントを見てみる。 * OpenShiftに詳しくないと少し面倒に感じたボリュームマウントによる永続化は次のコマンドでできる（これPV, PVCはどんな感じになるんだろう......？） odo storage create <storage_name> --path=<path_to_the_directory> --size=<size> * サービス間の連携は次のコマンドでできて環境変数が差し込まれる odo link backend --port 8080 * アプリの公開も開発者の立場から見たコマンドに置き換えられてる odo url create frontend --port 8080 * DBのサービスを作成するのは次のコマンド（対話型でこの後postgresql-persistent と打てばPostgresのDBが作れる） odo service create * デプロイされたアプリのデバッグに使うport-forwardはdebugのサブコマンド内に収められている odo debug port-forward という感じで、OpenShiftそのままで使うにはハードルが

資格試験には出ない範囲なので先延ばしにしていたが、PVとPVCのバインドは動的にできる、という話を聞いていたものの自分でやったことがなかったのでやってみた。 要はラベルでできる。 まずPVはこんな感じ。 kind: PersistentVolume apiVersion: v1 metadata: name: pv1-testing-result labels: record: testing-result 上記のように最初からlabelsに組み込めばいいけど、自分の場合は、元々あったリソースを流用したのでコマンドでラベルを追加した。 oc label pv pv1-testing-result record=testing-result 続いてPVCは次のような感じにした。 アプリ側はapp=my-testingのようなラベルで紐付けさせたいと思い、PVにつけていたラベルとは別のラベルもつけた。 こうしないと、oc delete all -l my-testingのようにしてまとめて消した時にPVも削除対象になってしまうので、ちょっと違うかなあと思ってわけているけどそれは運用にもよるのだろうね。 kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc1-testing-result labels: record: testing-result app: my-testing あとは最近やっとfield-selectorも使えるようになった。 selectorはよく読むとラベルに対するクエリをかけるものだったので、それ以外に対してはこのセレクターを使う必要がある様子。 oc delete pod --field-selector status.phase=Succeeded 資格は取れてもやっぱりまだまだだなあという感じ。

最近publickeyでOpen Web Docsが取り上げられていた。 Google、マイクロソフトらが設立、「Open Web Docs」を発表。MDNなど支援、Web技術のドキュメント化を推進 オープンソースやテクノロジーを中心としたコミュニティの維持や発展を支援する組織「Open Collective」は、Web www.publickey1.jp ぱっと見で、あ、GoogleやMSが、Web技術のドキュメントの標準フォーマットみたいなのを規定することでドキュメント化するコストを下げる試みをしてくれるのか！なんて読んでしまっていた。 要はDITAのような素晴らしいフォーマットのWebに適合した何かのイメージ。 で、ちゃんとリンク先などを見るとどうもそうではなくて、長期的なWeb上のドキュメントの更新のためのサポートをする目的のコミュニティができたという話みたいで、そこにスポンサーとしてGoogleやMSが関わっていて、直近はMDNの支援する目的、と。 だから、まあ、一般ユーザーである自分にはあんまり関係のある話ではなかった。 ちなみにリンク先を見るとまたちょっと混同してしまうというか、貢献する方法でお金しか出ていなくて混乱したのだけど * Open Collectiveというなんらかのコミュニティだが会社ではないどこかが、スポンサーを受付けたりそのお金をどう使ったかをクリアに示したりすることができるプラットフォームがある * Open Web DocsはOpen Collectiveを使用して金銭授受については公表している * スポンサー等になる（＝Open Collectiveでお金を送る）ことでOpen Web Docsの活動を応援することができる とまあそういう仕組みみたい。 Open Web Docsだけだと使われ方がわかりにくいので比べてみると...... Open Web Docs 揃 Expenses - Open Collective opencollective.com SDKMAN! 揃 Expenses - Open Collective opencollective.com webpack 揃 Expenses - Open Collective opencollective.com * Open Web Docsだと作業用の20万超

内容や対策については触れない。エッセイ。 受けた試験はEX288という試験IDのRed Hat Certified Specialist in OpenShift Application Development examというやつ。 振り返るとゆるーく勉強を始めたのが去年の11月頃。 そんで仕事であまり時間を工面できず、12月末頃にかけてようやく本気出した。 1週間ほどでLearning Subscriptionのコンテンツをひとまず消化......していざ試験を申し込んだらリモート受験の枠が全然なくてなんだかんだ1月下旬の受験となってしまった。 とはいえ、その期間があったおかげで追加で1周＋公式ガイドを読み通す時間が取れたのはよかった。（というか多分その時間がなかったら落ちてた） 延べ、多分80時間くらいは勉強してる。（ダッシュボード上） 100時間は必要、と言われている試験らしい（誰から聞いたんだっけ）けど、自分の場合は仕事で少しOpenShiftを触っていたから、その時間も含めると100時間という数字は結構妥当なのかもしれないな。 試験を受けるのに何が辛かったかなと振り返ると、次のあたりかなー。 * サンプル問題がないから実際にはどんな問題が出るかがわからない中での試験対策だった * 出題言語は英語だけなのか日本語もOKなのかがわからなかった * 子持ちで勉強時間を確保するのが大変だった AWSの試験を受けたのが一昨年とか？だった気がするのだけど、 彼らの試験はサンプル試験問題が豊富に存在していて、そのものずばりではなくても、どういう聞き方で何を聞いてくるのかがわかる。 対してOpenShiftのこの試験は、そもそもRed Hatがサンプル問題を出してくれていないので、何が出るのか予測がつかなかった。 もちろんLearning SubscriptionにはLabがあるから、そういうのが出るのかなーとは思っていたし、 内容を語ってはいけないという決まり事を守る範囲で教えてもらったのは「実践的」なテストで4択から選ぶような机上のテストではないということだった。 けど、それにしても......あ、一番難しい側で捉えるべきだったか、とちょっと面食らった。 今回のも当たった問題が良かったけれど、ひどいのに当たったら落としていたかもしれないな。（最後にテスト結果のレポート

一通り学習を終えたので復習と落穂拾いを兼ねて公式ドキュメントを読み返した。 時短のために今回は日本語翻訳版を読んでる。 Product Documentation for OpenShift Container Platform 4.5 - Red Hat Customer Portal The Red Hat Customer Portal delivers the knowledge, expertise access.redhat.com サービスアカウント： * プロジェクトではデフォルトで3つのサービスアカウントが自動的に作られる * builder：ビルドのPodで使用される。system:image-builderロールが付与される。このロールによってビルド結果を内部のレジストリーからプロジェクトのイメージストリームにプッシュ可能にしている * deployer：デプロイメントのPodで使用される。system:deployerロールが付与される。このロールによってレプリケーションコントローラーやPodを表示したり変更したりできる。 * default：指定されない限りその他全てのPodで使用される。 * この他、すべてのサービスアカウントには system:image-pullerロールが付与される。このロールは内部のレジストリーを使用してイメージストリームからイメージをPullすることを可能にしている。 この最後のimage-pullerロールは学習コンテンツ内でも使われていた。具体的には、共通で使用する用のイメージストリームを持つプロジェクトを作成、他のプロジェクトのimage-pullerロールに、当該共通用のイメージストリームからpullできるように権限をセットするというもの。 oc policy add-role-to-user system:image-puller system:serviceaccount:project-a (--namespace=project-b)のようにすればproject-bのイメージを参照可能なロールがproject-aに所属するすべてのユーザーにつく。 ストレージ管理： * PV：クラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにする。 * PVC：開発者がP

コンテナイメージの作成 イメージが公開されているのにわざわざ自分で作るのはなぜか、そしてそれはいつか？という話。 既存コンテナイメージから子イメージをビルドするためのDockerfileを作成する典型的なシナリオ： * 新しいランタイムライブラリ (データベースコネクタなど) を追加する。 * 組織全体でのカスタマイズ (SSL 証明書や認証プロバイダーなど) を含める。 * 内部ライブラリーを追加し、さまざまなアプリケーションの複数のコンテナーイメージで単一のイメージレイヤーとして共有する。 既存のDockerfileを変更するよりも新しいイメージを作成することの方が賢明なシナリオ： * 使用されていないマテリアル (man ページや /usr/share/doc にあるドキュメントなど) を削除することにより、コンテナーイメージをトリミングする。 * 親イメージか、または特定のリリースに含まれている何らかのソフトウェアパッケージのいずれかをロックして、今後のソフトウェアの更新に関連するリスクを低減する。 また、ファイルのコンテナ内部へのコピー後には、RUN命令により所有者を変更し、"Permission Denied"エラーを回避することがRed Hatにより推奨されている。（推奨一覧みたいなドキュメントはどこかにあるんだろうか......） DeploymentConfigとDeployment DeploymentConfigとDeployment、似てるこれらの違いについて。 ちなみに、OpenShift 4.5からは oc new-appすると、デフォルトでDeploymentが作られるようになっている。（それまではDeploymentConfig） DeploymentConfigs involve one or more ReplicationControllers, which contain a point-in-time record of the state of a DeploymentConfig as a Pod template. Similarly, Deployments involve one or more ReplicaSets, a successor of ReplicationControllers