Red Hat OpenShiftをざっくり理解する。
まえがき
現在私が開発を行っているWEBシステムはROSA(Red Hat OpenShift on AWS/Kubernetesコンテナプラットフォーム)を利用しています。
↓の図にあるように、開発者が該当ブランチにマージしたら自動でイメージ作成＆デプロイまでやってくれるCICD環境(Jenkins)と連携している形です。
これをまとめるまでは、
・OpenShift内の中身がブラックボックス状態。どうなってるん？
・どういう流れでイメージが作られてデプロイされてるん？
という状態だったので、忘れないよう記事に残しておきます。
※本記事は勉強用OUTPUTとして残しておくので、Red Hat Openshiftの全てを網羅しているわけではないです。もっと勉強しないとな...(´_ゝ｀)
単語
大前提である単語の定義を改めて確認。
コンテナ
- OS上のアプリケーションの動作環境を仮想的に区切る技術。
- 1台の物理サーバー上で動作する複数のコンテナを、それぞれ独立したサーバー環境のように利用できる。
- 機能単位の小さなアプリケーション（サービス）を組み合わせてシステムを実現する設計手法であるマイクロサービスとの相性も良い。
イメージ
- コンテナを構築するための設計書(テンプレート)
- イメージ = リポジトリ＋タグ で決まる。
例: xxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/repo1:latest
レジストリ と リポジトリ と イメージ(Tag付)
- リポジトリ と イメージ は、GitHubのリポジトリとTagの関係性と同じ。
１つのリポジトリに対してバージョン(イメージ/Tag)が存在しているイメージ。 - レジストリはGitHubに該当する。
- レジストリ(Amazon ECR)で、アプリA(リポジトリ)のイメージ(V_1.X.X) を管理。
アプリAがリリースされるたびに、アプリA(リポジトリ)にはイメージがどんどん増えていく。
コンテナオーケストレーション/Container orchestration
Container orchestration automates the deployment, management, scaling, and networking of containers.
Reference: Red Hat｜What is container orchestration?
✅コンテナのデプロイ/管理/スケーリング/ネットワーキングを自動化すること。
- １つ１つのPod(サーバ)を人間が監視して、アクセス数が増えたらスケーリングしたりPodが死んだらデプロイし直すとか手間だよね...
- このコンテナの管理を自動でやってくれるツール(コンテナオーケストレーションツール)ないかな -> これがKubernetesである。
Kubernetes
- Container orchestration toolの１つ。
- 米グーグル（Google）が社内で利用していたコンテナ管理ツールを汎用化してOSSにしたもの。
Kubernetesマネージドサービス
自動でコンテナ管理してくれるコンテナオーケストレーションツール(Kubernetes)をそのまま使うだけでいいの？...そういうわけではないようだ。Kubernetesを利用する主な選択肢としては
- サーバにKuberneteをインストール＆1から構築
- クラウドベンダーが提供するKubernetesマネージドサービスを利用
1と2の主な違いは
- Control planeがmanagedかどうか。
・2の場合、DeveloperはControl planeのことは気にする必要なし。
・マネージドサービスが常にControl planeが正常稼働するよう管理してくれる。 - Data planeに対するOS update等の管理
・2の場合、Data plane内の各NodeのOS updateやセキュリティパッチ対応などはマネージドサービスがやってくれる。Developerは気にしなくていい。
裏を返せば、そのままKubernetesを使う場合、自分でControl planeを管理しないといけないし、Data plane内の各NodeのOS updateなどをする必要があるということだ。
参考：Compare EKS vs. self-managed Kubernetes on AWS
ROSA全体像
私が開発しているWEBシステムはWEBサーバ(NodeJS/React)と複数のAPIサーバ(Java/SpringBoot)で構成されており、いずれもOpenShift内で各サーバ(Pod)を立ち上げてCloudFrontからアクセスできる形になっています。
ROSAの"Red Hat OpenShift"ってそもそも何？
✅Red Hat社が提供するKubernetesマネージドサービス。
✅Red Hat社が直接提供しているものを利用する手段があるが、他サービスで既にAWSを利用している＆それらとOpenShiftを連動させたい(例えばCloudFrontと紐づけたい)場合は、AWS上で利用できるRed Hat OpenShiftを採用することになる（私の開発現場ではそう）。
Kubernetesになくて、OpenShiftにあるもの
「素のKubernetesに便利機能を付け加えたのがOpenShift」みたいなイメージなので、以下の要素はOpenShift固有の特徴になる。
✅Imageレジストリ作成/運用可能(ImageStream) ※別でレジストリ作成不要だから嬉しい
✅CI/CDパイプラインの作成/運用可能 ※JenkinsでCICD構成してる場合は使わないかな
✅OpenShift特有のリソース
→ Project/DeploymentConfig/BuildConfig/Route/ImageStream
クラウドベンダーが提供するKubernetesマネージドサービス
素のKubernetesを運用するには複雑すぎるという問題を解決してくれるのが、各クラウドベンダーが提供するKubernetesマネージドサービス。Red Hat OpenShiftと含め比較対象となるものがこちら。
| ベンダー | サービス名 |
|---|---|
| AWS | EKS(Elastic Kubernetes Service) |
| GCP | GKE(Google Kubernetes Engine) |
| Azure | AKS(Azure Kubernetes Service) |
| Red Hat | Red Hat OpenShift★本記事のメイン★ |
※AWS ECSはAWSオリジナルのソフトウェアをベースに構築されている一方で、EKSはKubernetesをベースに構築されている。
どれを選ぶのかについては下記の記事を参照。
Red Hat OpenShiftの各リソース
OpenShift特有のものは🔴
| リソース名 | 内容 |
|---|---|
| Route🔴 | Host名/SSLサーバ証明書を設定。 ScalingするPodにSSLサーバ証明書設定不要👍 |
| Service | Podが内部公開してるPortと外部公開するPortの紐づけ。 |
| Pod | サーバ本体。 |
| DeploymentConfig🔴 | 後述のReplicationController, Replicat Setを管理。 |
| Replication Controller | Pod のレプリカ(複製)数を維持する。 |
| Replica Set | 安定したPodのセットを維持する。 |
| BuildConfig🔴 | イメージを作成する。 |
| ImageStream🔴 | 作成したイメージの保管場所/レジストリ。 |
負荷分散
OpenShiftにおける負荷分散
AWS EKSにおける負荷分散
AWS Load Balancer ControllerによってEKS外にAWS ELBを作成する。
・L4で負荷分散したければNLB(Network Load Balancer)
・L7で負荷分散したければALB(Application Load Balaner)
を作成する。
無料でハンズオンできる「Red Hat OpenShift Online」
実際に使ってみないとよくわかんないよね、ということで後で使う予定のRed Hat OpenShift Online。60日間まで無料ぽいので、あとで学習用に使ってみる。
Discussion