「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- コンテナベースのソフトウェアの配備・管理のRed Hat製品。
- 具体的には、
- DockerコンテナとDevOps?ツールを使用して、アプリケーション開発を高速化する。
- 豊富な機能を備えたポータルとCLIを同梱し、
デプロイされたアプリケーションを操作するためのUI/UXをユーザに提供する。
経緯 †
アーキテクチャ †
v2以前 †
コンポーネントは、大分すると、BrokerとNodeに分けられる。
Broker †
アプリケーションのデプロイ、認証・認可、各種データの保存などを担っている。
Node †
アプリケーションやサービスのホスト。
- Webブラウザなどからのアプリケーションへのアクセスは、
Nodeごとのリバースプロキシを経由し、各Gearに分配される。
- Cartridgeと呼ばれる、各種実行環境のテンプレートが用意されており、
それを基にGearと呼ばれるアプリケーションの実行単位を構成する。
- データベースもCartridgeの1つとして用意され、
アプリケーションごとにGearとして動作する仕組み。
- 対応言語、フレームワーク、データベースを追加したい場合、Cartridgeを追加する。
v3以降 †
OpenShiftがノードのDockerデーモンに実行を要求する。
- 展開された "vanilla"（標準的の意味） Dockerイメージを
取得するために実行する必要があるのは、これらのコマンドのほんの一部。
- ベストプラクティスに従うすべてのDockerイメージで機能する。
- EXPOSEポートの定義
- 開始時に実行する1つの非終了CMDなど
- ルートユーザまたは特定のユーザ名として実行しない
- デフォルトでrootとして実行されるDockerイメージの展開を許可していない。
- root（または特定のユーザ）として実行されることを想定した
Dockerイメージの展開を許可したい場合、小さな構成変更が必要になる。
- コンテナは不変のインフラストラクチャとして扱われる。
- 従って、一般的にコンテナの内容を変更しない。
- しかし、アプリケーションをデバッグするなどの幾つかのユースケースでは、
コンテナに入り、アプリケーションを検査することが有益になることがある。
Image Stream †
OpenShiftにはKubernetesに無いImage Streamというオブジェクトがある。
- 概要
- 内部的にタグに対応するDockerレジストリを管理する。
- それに追加で大きく以下の三つの機能を提供する。
- Dockerレジストリのタグにpushされたイメージの履歴を保持する機能。
- Image Streamのタグが更新されたら、Dockerレジストリに
pushなどのアクションを自動的に起動できるImageChange?更新トリガ機能
- OpenShift内部レジストリとの連携・イメージキャッシュ機能
- バージョン管理
Image Streamによるイメージの種類は大きく次の3つに分かれる。
- ベースイメージ = 公式RHELイメージ
OSレベルのファイルのみが入ったイメージ
- 開発テンプレート・イメージ = 開発環境イメージ
開発に必要なフレームワークなどが入ったイメージ
- アプリケーション・イメージ
実行可能なアプリケーションが入ったイメージ
- = 開発中アプリイメージ
- = 開発済みアプリイメージ
- = テスト済みアプリイメージ
Build Configuration †
次の4つの情報を記載することで、Dockerイメージの作成を行なう。
- めもめもの説明
- イメージ作成方法、必要なファイルの入手先
- イメージの作成方法（Dockerfile、もしくは、s2i）
- イメージの作成に必要なファイルの入手先（GitHubのリポジトリなど）
- 別の説明
- 最低限、ビルド・チェーンには次のものが必要。
- ビルド・イメージのビルド設定
- ランタイム・イメージのビルド設定
- ランタイム・イメージ用のインラインドッカーファイル
- ランタイム・イメージを使用するデプロイメント設定
- 次のオプションが推奨されている。
- Image Stream
- ソースプロジェクトに基づくビルド・イメージのトリガ
- ビルド・イメージに基づくランタイムビルドのトリガ
source-to-image (s2i) †
- Red Hatが主催するオープンソース・プロジェクト。
- Dockerfileを使用にせずに、スクリプトを用いてイメージの作成を自動化する。
- 増分ビルドによる再利用をサポート
- 以前にダウンロードした依存関係、
- 以前構築した成果物など
・・・ †
グループ化 †
プロジェクト †
展開を整理するのに役立つ最上位コンセプト。
- ユーザーが他のユーザーとは別に、
コンテンツを整理して管理することができる。
- 各プロジェクトには、独自の
- リソース、ポリシー（アクションを実行できるかどうか）
- 制約（リソースのクォータと制限など）
などがある。
サービス †
- 外部アクセスのため一意のIPアドレスとポートのペアが割り当てられる。
- ただし、既定では、作成したサービスは外部に公開されない。
- サービスIPは、サービスの生存期間中は決して変更されない。
- また、内部プロキシ/ロード・バランサとしても機能する。
- ポッドのルーティングとロード・バランシングを提供する。
RC/DC †
ほとんどの場合、
などのリソースを一緒に作成・使用することになる。
Deployment Configuration (DC) †
DCは、RCをベースに構築されており、展開方法を定義する。
- 最も単純なケースでは、新しいRCを作成するだけで、ポッドを起動できる。
- イメージの移行が可能になり、RCの作成前または作成後に実行されるフックも定義される。
Replication Controllers (RC) †
必要な数のポッドが存在することを指定して保証する。
- 例えば、サーバを3つのポッドに常にスケーリングする場合は、RCが必要。
- RCは、"自己修復"する方法。RCなしでは、ポッドは自動的に再起動されない。
テンプレート †
概要 †
- 個々のコマンドを個別に実行すると、面倒でエラーが発生しやすくなる。
- この設定はすべて1つのテンプレートにまとめることができる。
- コレを使用して完全なリソースセットを自動的に生成できる。
作成方法 †
- リポジトリへの登録
- テンプレートをバージョン管理システムに保存し、
- 外部URLからOpenShiftにロードすることもできる。
利用方法 †
- 管理者は、全ユーザがポータル経由でテンプレートを利用できるようにできる。
- ユーザはテンプレートを作成し、他のユーザと共有できる。
ocコマンド †
ファースト・ステップで説明されていたコマンド。
oc login †
ログインする。
新規作成 †
oc new-project †
プロジェクトを作成する。
oc new-project <projectname>
oc new-app †
- リソースをバックグラウンドで作成する。
- サービスに一連のポッドをマップする。
参照系 †
oc get †
以下のオプションを指定して取得できる。
- project(s)
- projects
- project ProjectName?
- service(s)
- services
- service ServiceName?
oc describe †
以下のオプションを指定して描画できる。
- project(s)
- projects
- project ProjectName?
- service(s)
- services
- service ServiceName?
更新系 †
oc delete †
設定関連 †
oc expose service †
レプリケートされたアプリケーションをサービスまたはルートとして公開する。
oc env †
リソースの環境変数を操作する。
<resource> <name> or <resource>/<name>
リモート接続 †
oc rsh †
ポッドにRSHを確立
oc exec †
ポッド内でコマンドを実行
step by step的な †
参考 †
openshift.com †
CTC教育サービス †
めもめも †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
