エンタープライズ Kubernetes 環境である Red Hat OpenShift には、Source-to-Image という機能があります。この機能は、イメージを生成するのに極めて有用で便利な手段です。アプリケーション・コードを格納した GitHub リポジトリー内の任意のランタイム・イメージ (例えば Node.js) をポイントし、数回クリックするだけで、アプリケーションを稼動中の状態にすることができます。一方、比較的複雑なアプリケーションの場合には、テンプレート機能を使用することで、複数のコンポーネントからなるデプロイメントを簡単に作成できます。テンプレートには最初からベース・イメージが用意されていて、それらのイメージをベースに首尾一貫したアプリケーションを作成できます。
この記事では、Red Hat OpenShift on IBM Cloud™ 上での場合を例に、テンプレートの仕組みを調査します。そのために、まずはテンプレートが依存するイメージを作成する手段となる Podman について調べます。
Podman という名前は、MP3 を再生するために使うもののように聞こえるかもしれません。実際には、Podman はソフトウェアであり、ポッド、コンテナー、コンテナー・イメージを作成および管理するために使用できます。しかも、コンテナー・デーモンを使う必要は一切ありません。
以下の図は、ポッド、コンテナー、イメージが連動する仕組みを示しています。
Kubernetes では、アプリケーションをホストする特定のノード上でポッドを作成します。要件に応じて、ポッドは 1 つのコンテナーで構成することも、複数のコンテナーで構成することもあります。コンテナーを実行するには、単一のイメージ (アプリケーションの実行可能バージョンを指定する一連の命令から作成するイメージ) を使用します。このイメージのビルダーとしての役割を果たすのが、Podman です。
歴史
Podman の歴史において、Open Container Initiative (OCI) は重要な存在となっています。Linux Foundation プロジェクトの 1 つである OCI の任務は、コンテナー・イメージ・フォーマットとランタイム環境の公式の仕様を策定することです。OCI は 2015 年 6 月に発足し、当時から今に至るまで主に Docker によってサポートされています。
Podman テクノロジーは OCI との協力によって開発されました。α版として Podman バージョン 0.6.1 がリリースされたのは、この記事を書いているわずか 1 年前の 2018 年 6 月のことです。
Podman を使用する利点
Podman が認識するイメージのタイプには、主にdocker と oci の 2 つがあります。
Podman を使用する主な利点の 1 つは、セキュリティーの強化です。第一に、Podman は root 権限がなくても実行可能であり、ほぼあらゆる機能を使用できます。また、Docker はクライアント/サーバー・モデルに従うのに対し、Podman は従来のフォーク/実行モデルに従います。このモデルを使用すると、systemd から接続済みソケットにタスクを渡して、その通知をスタックに返し、Podman がタスクの受け取りを待機するスタックの最上位にまで届けることができます。
Podman が明らかに対応しない機能
Podman は docker-compose 機能をサポートしません。また、Kubernetes Container Runtime Interface (CRI) と連動するコンテナー・ランタイム・デーモンも処理しません。これを処理するには、CRI-O という別のツールを使用できます。
Podman のリリース・マイルストーンと今後の行方
Podman 1.2 ではヘルス・チェックが導入されました。
今後のリリースでは、コマンド・ライン・インターフェースを介し、varlink バックエンドを使用してリモート Podman インスタンスに接続できるようになる予定です。
Podman の基本的なセットアップ手順と共通タスク
Podman はユーティリティーであり、libpod ライブラリーの一部として提供されます。Podman をインストールするには yum install podman を実行すればよいだけですが、特定のオペレーティング・システムに応じた詳細や、自分でビルドする方法を調べる場合には、インストール手順を参照してください。
コンテナーを実行するには、podman run を使用します (detached モードで実行する場合は、-d スイッチを追加します)。実行中のコンテナーと作成中のコンテナーのリストを表示するには、podman ps を実行します。-a スイッチを追加すると、/all/ のコンテナーのすべてが一覧表示されます。
inspect コマンドを使用すると、コンテナーに関するメタデータ (IP アドレスなど) を調べることができます。
$ podman inspect -l | grep IPAddress\":
"SecondaryIPAddresses": null,
"IPAddress": "",
(注: コンテナーが rootless モードで実行されている場合、IP アドレスは割り当てられません)。
Docker を使い慣れているとしたら、Podman のコマンド・ライン・インターフェースを簡単に使いこなせるでしょう。実際のところ、このインターフェースは Docker をベースとしているからです。使用するイメージを取得したら、podman build コマンドを実行すると、docker build と同じ処理が行われます。これによって生成されたイメージをテンプレート内で使用できます。
Red Hat OpenShift におけるテンプレートとは？
テンプレートとは、イメージまたはアプリケーションを、Red Hat OpenShift Container Platform Web コンソールに表示されるサービス・カタログに追加する手段を指します。以下のスクリーン・キャプチャーは、IBM Cloud 内の Red Hat OpenShift Web コンソールに表示されたサービス・カタログの一例を示しています。
カタログ内の各アイコンが 1 つのテンプレートです。テンプレートは単純な単一のイメージにすることも、複数のビルド、イメージ、デプロイメントからなるアプリケーション全体を含めたものにすることもできます。
通常、テンプレートには以下のリソースが含まれています。
- Red Hat OpenShift イメージ: コンテナーをビルドするためのベース・イメージ。
- ビルド: アプリケーションまたは Dockerfile に含まれるソース・コードから生成されたイメージ。
- イメージ: ビルドによる成果物。
- デプロイメント: どのイメージをどのようにデプロイするかについての定義。
- アプリケーションに必要なその他のリソース: ストレージ、ネットワーキング、または他のタイプのリソース。
IBM Cloud 内で初めて Red Hat OpenShift クラスターを作成する際に、かなりの数のプロジェクトがすでに自動的に作成されていることに気付くはずです。openshift プロジェクトには、クラスター用の既存のテンプレートが格納されています。これらのテンプレートは、GitHub 上で一般公開されているリポジトリーを使用してビルドするようにデフォルトでセットアップされています。さらに、サンプル・アプリケーションのコードも含まれています。
例えば、nodejs-mongodb-example のテンプレートには、github.com/sclorg/nodejs-ex/ でホストされているサンプル・コードが含まれています。このリポジトリーの openshift\templates ディレクトリー内に、テンプレートを作成するために使用されるファイルがあります。テンプレート・ファイルの先頭にはテンプレートに関する一般的な情報として、一意のユーザー・フレンドリーな名前と説明などが記述されています。
"kind": "Template",
"apiVersion": "v1",
"metadata": {
"name": "nodejs-mongodb-example",
"annotations": {
"openshift.io/display-name": "Node.js + MongoDB (Ephemeral)",
"description": "An example Node.js application with a MongoDB database. For more information about using this template, including OpenShift considerations, see https://github.com/sclorg/nodejs-ex/blob/master/README.md.\n\nWARNING: Any data stored will be lost upon pod destruction. Only use this template for testing.",
"tags": "quickstart,nodejs",
"iconClass": "icon-nodejs",
"openshift.io/long-description": "This template defines resources needed to develop a NodeJS application, including a build configuration, application deployment configuration, and database deployment configuration. The database is stored in non-persistent storage, so this configuration should be used for experimental purposes only.",
"openshift.io/provider-display-name": "Red Hat, Inc.",
"openshift.io/documentation-url": "https://github.com/sclorg/nodejs-ex",
"openshift.io/support-url": "https://access.redhat.com",
"template.openshift.io/bindable": "false"
}
},
"message": "The following service(s) have been created in your project: ${NAME}, ${DATABASE_SERVICE_NAME}.\n\nFor more information about using this template, including OpenShift considerations, see https://github.com/sclorg/nodejs-ex/blob/master/README.md.",
"labels": {
"template": "nodejs-mongodb-example",
"app": "nodejs-mongodb-example"
},
"objects": [
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "${NAME}"
},
"stringData": {
"database-user": "${DATABASE_USER}",
"database-password": "${DATABASE_PASSWORD}",
"database-admin-password" : "${DATABASE_ADMIN_PASSWORD}"
}
下のほうに、テンプレートの主要セクションがさらに 2 つあります。オブジェクト・セクションとパラメーター・セクションです。パラメーター・セクション内で、アプリケーションのメモリー使用量の上限やサービス名などの値を設定します。オブジェクト・セクションには、テンプレートが使用するイメージの詳細が示されています。このセクションに、以下の nodejs イメージが指定されています。
"strategy": {
"type": "Source",
"sourceStrategy": {
"from": {
"kind": "ImageStreamTag",
"namespace": "${NAMESPACE}",
"name": "nodejs:${NODEJS_VERSION}"
}
Then mongo:
"type": "ImageChange",
"imageChangeParams": {
"automatic": true,
"containerNames": [
"mongodb"
],
"from": {
"kind": "ImageStreamTag",
"namespace": "${NAMESPACE}",
"name": "mongodb:${MONGODB_VERSION}"
}
まとめ
これらのイメージのいずれかを (例えば、データベース・エンジンを置き換えるために) 独自のイメージと交換するには、前のセクションに記載したファイルをコピーして、'mongodb' の部分を目的のイメージで置き換えます。 あるいは、ゼロから初めて完全に異なるアプリケーションを作成することもできます！テンプレートのドキュメントで詳細を調べてください。
Red Hat OpenShift on IBM Cloud では、実際にテンプレートを使ってみることができます。