Chapter1. 要約
OpenShift3はコンテナ技術をベースにし構築されており、Kubernetesによるオーケストレーション、管理機能を提供する。OpenShift3はAtomic HostもしくはRed Hat Enterprise Linuxで動作する。
OpenShift Originは開発・デプロイを効率化するための機能拡張を行なっているアップストリームプロジェクトである。
KubernetesとAmazon Web Serviceの高可用性を利用して、可用性の高いOpenShift環境を構築するためのサンプルを提供する。
サンプルは、masterノードを3ノード、infrastructureノードを3ノード、applicationノードの2ノード及びAWSとのネイティブな統合機能で構成する。
環境の設定に加え、管理タスクの使用例を紹介する。
Chapter2. コンポーネントと構成
この章では、Amazon Web Services(以下、AWS)上にHA構成のOpenShift Container Platform 3を構築するためのリファレンスアーキテクチャについて説明する。
以下の図はリファレンスアーキテクチャ内で登場するコンポーネントの概要である。AWSを利用することでリソースに可用性をもたせることができる。例えば、リージョンをまたがる構成、Elastic Load Balancers (ELB)によるロードバランサ、S3バケットの使用などがあげられる。配置されたそれぞれのEC2インスタンスには、OpenShiftを動かすためにそれぞれ役割を割り当てる。Bastin hostと名付けるEC2インスタンスは外部からのアクセスを制限するために使用する。これは全てのsshのアクセスをBastin host経由とすることで実現する。masterと名付けるEC2インスタンスはetcd(キーバリュー形式の分散データストア)やOepnShift APIのようなmasterコンポーネントを配置する。OpenShiftのルータ機能や内部レジストリはインスラストラクチャと名付けるEC2インスタンスに配置する。Applicationと名付けるEC2インスタンスにはユーザ(開発者)がコンテナを配置する。
認証認可機能はGitHubのOAuth機能を利用する。AWS上のOpenShiftは永続化に関しては、2つの選択肢を用途に応じて使い分ける。Elastic Block Storage(以下、EBS)はEC2インスタンスのファイルシステムもしくはコンテナのPersistent Storageとして利用する。EBSに並ぶもう一つの選択肢であるS3(オブジェクトストレージ)はOpenShift Registoryの永続化に利用する。ネットワークに関しては、OpenShift API, OpenShift console及びOpenShiftルータのために3つのELBを準備する。一つ目のELBは外部からOpenShift API, OpenShift consoleにアクセスする際に利用する。二つ目のELBはOpenShiftのクラスタ内のAPI呼び出しに利用する。三つ目のELBはルータを経由して公開されるクラスタ内に構築したサービスrにアクセスするために利用する。DNSについては、AmazonのDNSサービスであるRoute53で管理する。このケースでは、DNSのエントリーは全てRoute53で定義することとする。
この参照アーキテクチャでは、環境構築を3つのフェーズに分けている。
- Phase1: AWS上での基盤(EC2,EBS,S3,ELB,Route53など)のプロビジョニング
- Phase2: OpenShift Container Platformのプロビジョニング
- Phase3: デプロイ後の作業
Phase1では、以下のURLにあるAnsible Playbookを用いてプロビジョニング作業を行う。
https://github.com/openshift/openshift-ansible-contrib/tree/master/reference-architecture
playbookにより基盤が構築されると、Phase2の手順を自動的に実行する。Phase2では、Ansible playbookによるOpenShift Container Platformのインストールを行う。使用するplaybookはopenshift-ansible-playbooksというrpmパッケージによりインストールされる。openshift-ansible-contribの中のplaybookはOpenShiftのインストールやAWS固有のパラメータ設定を行うためにopenshift-ansible-playbooks中のplaybookを利用する。Phase2の中でrouterとregistryの配置を行う。最後のPhase3ではOpenShift適切に構築されたか確認を行う。これはoadam diagnosticsのようなツールや検証用に準備したAnsible playbookで実施する。
注記
GitHub経由で提供されるスクリプトは、RedHatのサポート対象ではない。これらのスクリプトはAWSでOpenShiftを構築するときのメカニズムを示すことを目的としている。
EC2(Elastic Compute Cloud) インスタンスの詳細
このアーキテクチャで使用するインスタンスはデフォルト設定では、us-east-1リージョンの複数のavailability zoneに配置される。
デフォルトRegionの設定は変更可能であるが、このアーキテクチャでは、3つ以上のavailability zoneを持つRegionで利用されることを前提としている。
構築するOpenShiftのmaster用インスタンスはインスタンスタイプをm4.xlargeとする。Docker Storage,OpenShift ephemeral volumesおよびETCD用に3つのディスクを追加する。node用インスタンスはインスタンスタイプをt2.largeとする。Docker Storage,OpenShift ephemeral volumes用に2つのディスクを追加する。bastion(砦の意味)用のEC2インスタンスはインスタンスタイプをt2.microとする。インスタンスのサイズは、インストーラで使用するファイルの中で指定可能である。この章の後続で説明する。
ELB(Elastic Load Balancers)の詳細
このリファレンスアーキテクチャでは、ロードバランサを3つ定義している。以下のテーブルはロードバランサのDNS名、それぞれのELBのアタッチされているEC2インスタンス、インスタンスが起動中か確認するためにELBが監視するポート番号を示す。
| ELB名 | 割当られたインスタンス | ポート番号 |
|---|---|---|
| openshift-master.sysdeseng.com | master01,master02,master03 | 443 |
| internal-openshift-master.sysdeseng.com | master01,master02,master03 | 443 |
| *.apps.sysdeseng.com | infra-node01,infra-node02,infra-node03 | 80, 443 |
ELB(internal-openshift-maeter)とELB(openshift-master)はOpenShift Master APIを使用したコミュニケーションで使用される。ELB(internal-openshift-maeter)はAPIによる内部クラスタの通信をよりセキュアにするため、プライベートサブネットを使用する。ELB(openshift-master)はAPIやWeb管理コンソールのような外部からのOpenShiftへのアクセスに使用される。ELB(openshift-master)はパブリックサブネットを使用し、外部からのアクセスを443番のポート番号のみ許可する。ELB(*.apps)は、パブリックサブネットを使用し、infrastructureノードにマッピングされる。infrastructureノード上ではルーターポッドが稼働している。ルータは外部からの通信を事前定義したルーティング定義に従って、OpenShiftへ転送する。
使用ソフトウェアのバージョン
表2.2はOpenShiftをHA構成でインストールするために必要なソフトウェアである。
| ソフトウェア名 | バージョン |
|---|---|
| Red Hat Enterprise Linux 7.3 x86_64 | kernel-3.10.0.x |
| Atomic-OpenShift {master/client/node/sdnovs/utils} | 3.5.x.x |
| Docker | 1.12.x |
| Ansible | 2.2.1.x |
チャネル
リファレンスアーキテクチャの環境を構築するには、以下のチャネルに対するサブスクリプションが必要となる。
| チャネル名 | Yumリポジトリ名 |
|---|---|
| Red Hat Enterprise Linux 7 Server (RPMs) | rhel-7-server-rpms |
| Red Hat OpenShift Container Platform 3.5 (RPMs) | rhel-7-server-ose-3.5-rpms |
| Red Hat Enterprise Linux 7 Server - Extras (RPMs) | rhel-7-server-extras-rpms |
| Red Hat Enterprise Linux Fast Datapath (RHEL 7 Server) (RPMs) | rhel-7-fast-datapath-rpms |
AWSのリージョンに関する要件
＊＊＊
Virtual Private Cloud (VPC)
リファレンスアーキテクチャでは、OpenShiftをデプロイするのに使用する安定したネットワークを提供するために、同時に動く全てのOpenShift内のサービスに対して、専用のVPCを作成する。
VPCはAWSの論理的なネットワーク環境である。以下の表に使用するサブネットとCIDRを定義する。
作成する環境で使用中のサブネットやCIDRが存在した場合は、適宜値を読みかえること。それらの値は以下のファイルに定義してある。
/home/<user>/git/openshift-ansible-contrib/reference-architecture/awsansible/playbooks/vars/main.yaml
表2.4 VPCネットワーク
| CDIR/サブネット | 設定情報 |
|---|---|
| CIDR | 10.20.0.0/16 |
| Private Subnet 1 | 10.20.1.0/24 |
| Private Subnet 2 | 10.20.2.0/24 |
| Private Subnet 3 | 10.20.3.0/24 |
| Private Subnet 4 | 10.20.4.0/24 |
| Private Subnet 5 | 10.20.5.0/24 |
| Private Subnet 6 | 10.20.6.0/24 |
VPCで定義したサブネットには、人が理解しやすいようにタグが割り当てられる。3つのサブネットはパブリックとして、3つのサブネットはプライベートとして定義する。HA構成とするため、1つのアベイラビリティ・ゾーンには1つのパブリックなサブネットと、1つのプライベートなサブネットを割り当てる。パブリック用サブネットはbastinインスタンスと2つのELBに使用する。bastinインスタンスは、SSH接続の踏み台として利用するため、パブリック用サブネットに割り当てる。2つの外部向けのELBはOpenShiftのmasterとアプリケーションのルーティングに利用する。パブリック用のルーティングテーブルではインターネットゲートウェイとルートを定義し、VPCにアタッチする。そのルーティングテーブルは、インターネットゲートウェイ向きの定義があるため、通信トラフィックは、VPCの外に出ることができる。パッケージ(rpm)、コンテナイメージ、GitHubリポジトリとやりとりするため、プライベート用のサブネットはNATゲートウェイを使用する。masterノード、infrastructureノード及びapplicationノード、internal-openshift-master (ELB)はプライベートなネットワーク内に存在する。そのためこれらのノード群は、外部からアクセスされない。
詳細は、以下を参照
NATゲートウェイ
参照アーキテクチャでは、AWSのNATゲートウェイサービスを使用する。このサービスを利用することで、プライベートサブネット内のインスタンスは、パッケージ(rpm)、コンテナイメージ、GitHubリポジトリをダウンロードすることができる。プライベートサブネットから外部に向けての通信トラフィックは、必ずNATゲートウェイを通過しなければならない。ゲートウェイをことで不必要なパブリックIPアドレスやDNSエントリを定義する必要がなくなるので、外部向けのフットプリントを小さくすることができる。
セキュリティグループ(ファイアウォールに相当)
参照アーキテクチャでは、8つのセキュリティグループを作成する。VPCの外からVPCの中にあるサーバに対する通信を制限することである。セキュリティグループは、VPC内にあるサーバ間の制御にも利用される。セキュリティグループは、ファイアウォールに相当するセキュリティ機能を提供する。あるインスタンスが任意のポートを解放していたとする。その場合でも、明示的にそのポートの定義がセキュリティグループ上に存在しなければ、そのポートを通して通信を行うことはできない。それぞれのセキュリティグループの設定情報を記載する。