スキップしてメイン コンテンツに移動

OpenShift学習メモ

Topics:

コンテナイメージの作成

イメージが公開されているのにわざわざ自分で作るのはなぜか、そしてそれはいつか？という話。

既存コンテナイメージから子イメージをビルドするための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.
The difference between a replica set and a replication controller is that a replica set supports set-based selector requirements whereas a replication controller only supports equality-based selector requirements.

Understanding Deployments and DeploymentConfigs - Deployments | Applications | OpenShift Container Platform 4.4 https://docs.openshift.com/container-platform/4.4/applications/deployments/what-deployments-are.html

DeploymentConfig=ReplicationControllersを使う
ReplicationControllersは
* Replicaの数に合うようにPodを増減させる、足りなければ増やし、多すぎれば減らす
* Podの数はラベルで認識してる
* 負荷の増減によるスケーリングはしない
また、DeploymentConfig自体としては、可用性よりも一貫性が重視された設計になっていて、もしDeployのためのPodが乗ったNodeが落ちたとしたら、そのNodeが戻ってくるか手動で削除されるまで待機する。そしてもし手動でNodeを消したら、それに紐づくPodも削除される。

Deployment＝ReplicaSets（ReplicationControllersの後継）を使う
* 基本はReplicationControllersと一緒
* Podの数はラベルで認識しているが、名前が一致することのチェックだけでなく、Key：Valueでより柔軟に表現できる(*1)
DeploymentConfigとは対照的に、一貫性よりも可用性が重視された設計になっていて、落ちた場合は別のNodeを選ぶなどの対応がとられるので、Downしたときに早期の復旧が見込める。ただし、この方法の懸念点もあり、もし他のNodeでも同じように問題が起きるようなDeploymentの場合、同じ問題が別の場所でも起きるような事態に繋がる。


*1 具体的にはこんな感じ（ReplicationControllersの場合name: xxxの値がマッチするか否かだった）：

matchLabels: 
     tier: frontend
   matchExpressions: 
     - {key: tier, operator: In, values: [frontend]}

その他雑多なメモ

* デプロイなどの進捗逐次確認に oc get pods -w (-wは--watch)
* コンテナ周りでのトラブルシュート時、コンテナ内に必要な実行ファイルが足りない場合には、ホストのbinをコンテナにマウントする
* DeploymentConfigのイメージ変更トリガーは設定しておけばアプリの親イメージの変更を監視する必要がなくなる、が、それは内部レジストリーに関しての話。外部レジストリーのイメージの場合は、定期的にoc import-imageで変更の有無を確認する必要がある
* S2I(Source to Image)の言語検出ロジック：

出所：第5章 Source-to-Image ビルドのカスタマイズ https://rol.redhat.com/rol/app/courses/do288-4.5/pages/ch05