目次


Minecraft とIBM Cloud, 第 3 回

Kubernetes 内で Spigot サーバーを稼働させる

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Minecraft とIBM Cloud, 第 3 回

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Minecraft とIBM Cloud, 第 3 回

このシリーズの続きに乞うご期待。

第 2 回では、Eclipse 内で Spigot サーバー用のプラグインを作成し、それらのプラグインをローカルの Docker 環境内でテストする手順を説明しました。今回は、次の大きなステップに取り組みます。そのステップとは、シリーズのこれまでのチュートリアルで開発した Spigot サーバーを、IBM Cloud 内のクラウドにデプロイすることです。

皆さんがその方法を理解できるよう、まずは Docker ファイルが IBM Cloud 内でどのように実行されるのかを説明するところから始めます。この仕組みを説明するには、IBM Container Service がベースとしているテクノロジー、Kubernetes について少々説明しなければなりません。

Kubernetes とは何か

第 1 回と第 2 回で、Docker がコンテナーの実行環境を提供する仕組みを説明しました。けれども場合によっては (実のところ、ほとんどの場合)、それぞれに孤立したコンテナーでは必要を満たせないことがあります。それは、複数のコンポーネント (Web サーバー、アプリケーション・サーバー、データベースなど) からなる複雑なアプリケーションを実装する場合です。この場合、これらのコンポーネントの相互関係を指定する手段が必要になります。さらに、これらの複数のコンポーネントを 1 つの包括的アプリケーションとしてデプロイするための手段も必要です。

コンテナー業界では、1 つの統合されたアプリケーションとして複数のコンテナーのデプロイメントと管理を調整する機能を、オーケストレーションと呼んでいます。複数のコンポーネントを 1 つのアプリケーションとして実装する場合、オーケストレーションの問題に加え、本番アプリケーションの一部としてコンテナーを稼働させることに関連する、これまでは考慮していなかった問題にも対処しなければなりません。そのような問題は、スケーリング (特定のサーバーのコピーをいくつ実行するか)、ロード・バランシング、ネットワーキングをはじめ、他にも多数あります。これらすべての問題と、さらにその他の問題を解決するのが Kubernetes です。Kubernetes の機能の一端を理解するために、次のセクションで、Kubernetes 関連で使用するいくつかの用語の意味を明らかにします。

クラスター、ポッド、サービス、デプロイメント

最初に紹介すべき Kubernetes の概念は、クラスターという考え方です。Kubernetes でのクラスターは、それぞれに Kubernetes の異なる部分を実行する一連のマシンまたは仮想マシンからなります。クラスターを構成するノードは、クラスターの管理を担当する 1 つのマスター・ノードと、アプリケーションを実際に実行する 1 つ以上のワーカー・ノードに分かれます。これらの異なるノードのすべてが Docker を実行します。これが、複数のマシン全体にわたって Docker を実行する際のソリューションです!

ノードのすべてで Docker を実行する理由は、ポッドを作成することにあります。ポッドとは、論理的に接続された、同時に稼働させる 1 つ以上のコンテナーの集合を指します (「ポッド」という名前がどこから来ているのかを知るには、Docker のロゴ画像がクジラであることを思い出してください。クジラの群れは、ポッドと呼ばれます。ポッドに属するすべてのクジラは常に離れることなく、同じ宛先を目指して同じ向きになって泳ぎます)。このチュートリアルでは、ポッド内のコンテナーをまとめて接続するために共有 IP アドレスのようなものを使用し、さらにはコンテナー間でストレージも共有します。

コードの詳細を探る前に知っておかなければならない最後の概念は、デプロイメントです。デプロイメントとは、ポッドをどのように作成するか、そしてそれらのポッドをどのようにサービスと ReplicaSet にリンクしてポッドの状態を設定するかを記述するファイルのようなものだと考えてください。この場合のサービスとは、まとまった 1 つの論理単位を形成する 1 つ以上のポッドのことです。サービス定義により、特定のサービスのクライアント (Minecraft クライアントなど) に必要な情報は、ポッドを 1 つにまとめるための実装の詳細から切り離されます。最後に、ReplicaSet とは、Kubernetes が実行するコピー (レプリカ) の数と、それらのコピーのいずれかで障害が発生した場合の対処方法を決定するために使用するメカニズムのことです。

クラスターを作成する

以上が Kubernetes で提供している機能ですが、Kubernetes を使用するにはどうすればよいのでしょうか?そのための最初のステップは、新規の Kubernetes クラスターを作成することです。Kubernetes 自体をローカル・デスクトップ上で実行することはできますが (minikube を参照)、それは私たちが目標としているアプローチではありません。ここで目標としているのは、Kubernetes に格納されている状態の Docker コンテナーを IBM Cloud クラウド内で実行することです。そのためには、IBM Service の提供しているサービスを利用する必要があります。

IBM Container Service を利用すると、IBM Cloud 内で独自の Kubernetes クラスターを作成することができます。ここで、前述の Kubernetes クラスターの構成部分についての定義を振り返ってください。クラスターはマスター・ノードと 1 つ以上のワーカー・ノードで構成されるという定義です。IBM Container Service 内で作成できるクラスターには 2 つのタイプがあります。タイプによって、使用できるワーカー・ノードの数と、ワーカー・ノードに対する請求方法が異なります。

すべてのアカウントには、IBM Container Service 内で無料のライト・クラスターを 1 つ作成する許可が与えられています。ライト・クラスターは、事前にサイズが決められた単一ワーカー・ノードのクラスターです。開発目的や、このチュートリアルの Minecraft を使用して行っているような単純な実験には、この無料のライト・クラスターが役立ちます。複雑なマルチホスト型アプリケーションを開発する必要がある場合や、さらに重要なことに、回復力を備え、1 つ以上のワーカー・ノードを失っても機能し続けるアプリケーションをデプロイする場合には、IBM Container Service 内に標準的なクラスターをデプロイする必要があります。その方法は、このチュートリアルの範囲外ですが、このような高可用性アプリケーションのデプロイについては、このリンク先のドキュメントで詳しく調べることをお勧めします。いずれの場合にしても、IBM が管理の部分に対処するために、各ケース内に同じようにマスター・ノードを作成します。このことは、もう少ししてくると重要になってきます。

まずは、無料のライト・クラスターを作成しましょう。以下に説明する手順では、IBM Cloud コマンド・ライン・ツールおよびチュートリアルの第 1 回で参照した Container Service ツールのインストール手順をすでに完了していることを前提とします。また、開発用の無料の Kubernetes ライト・クラスターをまだ作成していないということも前提とします。

始めに、Ubuntu OS にログインしてターミナルを開き、以下の 3 つのコマンドを入力します。

bx login -a api.ng.bluemix.net

bx cs init --host https://us-south.containers.bluemix.net

bx cs cluster-create —name Minecraft

最初のコマンドは、IBM Cloud にログインするためのものです。このコマンドを実行すると、IBM Cloud ユーザー ID とパスワードを入力するよう求められます。フェデレーテッド ID を使用しているとしたら、このリンク先のページで、1 回限りのログインを使用する手順に従ってください (IBM Cloud の企業向けアカウントを使用している場合や、IBM 社員の場合は、フェデレーテッド ID を使用しているのが通常です)。

2 番目のコマンドで、クラスター・サービスを初期化します。クラスター・サービスの初期化は、IBM Cloud に対してクラスターを作成する物理的な場所を指示する、1 回限りのステップです。このチュートリアルを作成している時点で、クラスターを実行する場所として選択できるのは、米国南部 (ダラス)、欧州中央 (フランクフルト)、欧州南部 (ロンドン)、またはアジア太平洋南部 (シドニー) のいずれかです。居住地近くのリージョンとして、最後にリストアップした 3 つのリージョンのいずれかを選択する場合は、-host の後に続くアドレスを、以下の該当するアドレスで置き換えてください。

  • https://eu-central.containers.bluemix.net
  • https://uk-south.containers.bluemix.net
  • https://ap-south.containers.bluemix.net

最後のコマンドで、クラスターを作成します。ここでは 1 つのオプション (–name) しか指定していないことから、IBM Cloud はライト・クラスターを作成します。クラスターには任意の名前を付けられますが、このシリーズでは以降、「Minecraft」というクラスター名を使用します。

注: Kubernetes クラスターが作成されるまでには時間がかかることがあります (数分またはそれ以上)。以下のコマンドを実行することで、クラスターがサービスに対応できる状態になったかどうかを確認できます。

bx cs clusters

以下に、上記のコマンドをライト・クラスターに対して実行した結果を示します。

Listing clusters...
OK
Name        ID        State      Created                Workers   Datacenter   
Minecraft   XXXXXXX   normal   2017-07-19T01:36:50+0000   1         hou02

「State (状態)」が「normal (正常)」以外の結果になっている場合は、数分待ってからコマンドを再実行してください。クラスターが「normal (正常)」状態になったら、次のステップに進むことができます。次のステップでは、クラスターを構成して、そのクラスターにアクセスできるよう、kubectl (Kubernetes クラスターを管理するために使用するコマンド・ライン・インターフェース) をローカル・マシン上にセットアップします。

bx cs cluster-config Minecraft

上記のコマンドでダウンロードされる YML ファイルによって、マシン上の kubectl がクラスターにアクセスできるようになります。このコマンドを実行すると、以下のような出力が表示されるはずです。

Downloading cluster config for Minecraft
OK
The configuration for Minecraft was downloaded successfully. Export environment variables to start using Kubernetes.

export KUBECONFIG=/home/kylebrown/.bluemix/plugins/container-service/clusters/Minecraft/kube-config-hou02-Minecraft.yml

この出力の最後の行 (export で始まる行) をコピーしてペースト・バッファーに貼り付けた後、そのコードをコマンド・ラインで実行します (ペースト・バッファーからコマンド・ラインにコードを貼り付け、そのままの状態で Return キーを押します)。エクスポートが正しく実行されたことを確認するために、以下のコマンドを実行します。

echo $KUBECONFIG

上記のコマンドの出力と、cluster-config コマンドによって返された KUBECONFIG 環境変数の値を比較します。さらに最後の確認ステップとして、以下のコマンドを実行します。

kubectl version —short

出力が以下のような内容であることを確認してください。

Client Version: v1.6.4
Server Version: v1.5.6-4+abe34653415733

このような出力になっていれば、正しく構成されたことになります。一方、エラー・メッセージが表示された場合は、環境変数をコピーして、もう一度エクスポートを試してください。

コンテナー・レジストリー・プラグインをインストールする

次のステップでは、コンテナー・レジストリー・プラグインをインストールします。コンテナー・レジストリーとは、Kubernetes 内の Docker で使用するイメージを、セキュアに保管できる場所でしかありません。IBM Cloud コンテナー・レジストリーの「無料」プランで使用できるディスク・スペースは 512MB に制限されています。このサイズは、チュートリアルで作成する Minecraft イメージを辛うじて保管できるだけの大きさです。コンテナー・レジストリー・プラグインをインストールするには、以下の 2 つのコマンドを実行します。

bx plugin install container-registry -r Bluemix
sudo bx cr login

第 1 回で Kubernetes クラスター・サービス・プラグインをインストールしたときと同じように、最初のコマンドは container-registry プラグインをインストールして、レジストリーをデフォルト IBM Cloud レジストリーとして設定します。

2 番目のコマンドによって、コンテナー・レジストリーにログインし、プランで確保されているスペースを使用できるようにします。この例ではコンテナー・レジストリーの「無料」プランを使用しますが、これには 1 つの欠点があります。各ユーザーに割り当てられるディスク・スペースの量はかなり制限されていて、クラウド内で 512MB のストレージしか使用できません。このサイズは、Ubuntu イメージをベースに作成された小さい単一のイメージを保管するのに辛うじて十分な大きさです。実際のところ、制限内に収まるようにイメージのサイズを縮小するために、Dockerfile にいくつかの変更を加えなければなりません。どのように変更するのか、そしてそれらの変更によってどのような効果があるのかについては、この後のセクションで説明します。

コンテナー・レジストリーを使用する

コンテナー・レジストリー・プラグインで差し当たり行う必要のある最初の作業として名前空間の作成があります。名前空間とは、イメージを整理するフォルダーのようなものです。この例の場合、IBM Cloud ユーザー名と同じ名前の名前空間を作成します。つまり、IBM Cloud に「yourname@yourcompany.com」でログインするとしたら、「yourname」の部分だけを名前空間に使用します。山括弧で囲まれている部分をユーザー名で置き換えて、以下の 2 つのコマンドを実行してください。最初のコマンドは名前空間を作成します。2 番目のコマンドによって、最初のコマンドで作成された名前空間のリストが出力されるので、名前空間が正常に作成されたことを確認できます。

bx cr namespace-add <yourname>
bx cr namespaces

名前空間が正常に作成されたことを確認したら、次は、ローカル・イメージを作成して、適切な名前、つまり「タグ」を設定する必要があります。けれどもその前に、サイズを縮小するために Dockerfile に加えた変更内容を確認しましょう。

現時点で、初のサンプル・アプリケーションをビルドして IBM Cloud にプッシュする作業に取り掛かる準備はできています。カレント・ディレクトリーが spigot-plugin-bluemix になっていない場合は、カレント・ディレクトリーをこのディレクトリーに変更してください。カレント・ディレクトリー内にある Dockerfile の内容を表示するために、以下のコマンドを入力します。

cd spigot-plugin-bluemix

カレント・ディレクトリー内にある Dockerfile の内容を表示するために、以下のコマンドを入力します。

cat Dockerfile

表示されるファイルの内容は、以下に記載する内容と一致しているはずです。参考として、第 2 回での Dockerfile と比較することもできます。

# Version 0.0.4
# This version builds a spigot server
# using the recommended build strategy for spigot
# This is advantageous in that it’s better for plugin development
# and fits well with the Docker approach
# it also adds a first Minecraft plugin into the bare spigot server
#
FROM ubuntu:16.04
MAINTAINER Kyle Brown “brownkyl@us.ibm.com”
RUN apt-get update &&\
	apt-get install -y git &&\
	apt-get install -y default-jdk &&\
	apt-get install -y wget &&\
	mkdir minecraft &&\
	wget "https://hub.spigotmc.org//jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar" -O minecraft/BuildTools.jar &&\
	git config --global core.autocrlf input &&\
	java -jar minecraft/BuildTools.jar --rev 1.12 &&\
	rm -r Bukkit &&\
	rm -r CraftBukkit &&\
	rm -r Spigot &&\
	rm -r BuildData &&\
	rm -r apache-maven-3.2.5 &&\
	rm -r work &&\
	rm craftbukkit-1.12.jar &&\
	rm -r minecraft &&\
	apt-get purge -y --autoremove git wget
RUN echo "eula=true" > eula.txt &&\
	mkdir plugins
ADD Tutorial.jar /plugins/Tutorial.jar
CMD java -Xms512m -Xmx1024m -jar spigot-1.12.jar nogui
EXPOSE 25565

このファイルの内容を見て最初に気付く点は、以前は Dockerfile 内に散らばっていた RUN コマンドの多くがまとめられて、かなり長い 1 つの RUN コマンドになっていることです。このような 1 つのコマンドにするために、&& 演算子を使用してコマンドを連結するという、標準的な UNIX シェル・スクリプトのトリックを使用しました。2 番目に気付く点として、第 2 回での場合とは異なり、spigot jar ファイルの作成後に、再帰的削除 (rm –r) コマンドを使用して多数のディレクトリーを削除するコマンドを追加しています。さらに、インストールの開始時にインストールした (BuildTools.jar に必要だった) git ツールと wget ツールも削除されていることに注目してください。

この一連の変更のすべては、スペースを節約するために行っているものです。まず、コマンドを結合すると、Docker イメージ内のの数が減ります。層のそれぞれは完全な仮想ファイル・システムのようなものであり、不変です。層の上に別の層を作成することはできますが、いったん作成した層の内容を変更することはできません。わかりやすい例で言うと、この仕組みは、バージョン管理システム内にあるバージョンのソース・コードを保管する仕組みと同様です。いったん変更をコミットすると、その変更はバージョン管理システム内で永続化されますが、随時、その変更をベースに別の変更を加えることはできます。

Docker では、層がイメージに追加されると、その層で使用されるディスク・スペースはそれを最後に占有されたままになります。Docker build コマンドの出力を観察して気付いたと思いますが、Dockerfile コマンドは、その 1 つひとつが新しい層を作成します。したがって、BuildTools.jar (CraftBukkit、Bukkit、Spigot など) で使用する作業ディレクトリーを削除したとしても、その後に作成する層の中でそれらのディレクトリーが削除されていなければ、ディスク・スペースが節約されることにはなりません。このことから、複数の RUN コマンドを結合して、セットアップ、実行、クリーンアップを含む 1 つの長いコマンドに結合することが、イメージのサイズを縮小する際の共通の Docker のベスト・プラクティスとなっています。

新しい Dockerfile の内容を確認したところで、これから実際に、この Dockerfile を使用します。それには、これまでのチュートリアルですっかりお馴染みになったコマンドを実行しますが、今回のコマンドでは今までよりも長いタグを使用します。タグの前には、IBM Cloud レジストリーのアドレス、その後に名前空間、そして最後にイメージ名 (これまでのチュートリアルで採用してきた命名規則に従ったもの) を追加します。

コマンド・ラインで、以下のコマンドを実行して手順を続けます。いつもどおり、コマンドの最後にピリオド (“.”) を入れることを忘れないでください!

sudo docker build -t registry.ng.bluemix.net/<yourname>/spigot-plugin-bluemix .

これでイメージがビルドされたので、そのイメージを IBM Cloud コンテナー・レジストリーにアップロードまたはプッシュします。それには、以下に示すように docker push コマンドを使用します。

sudo docker push registry.ng.bluemix.net/<yourname>/spigot-plugin-bluemix

ネットワークの速度によっては、このコマンドの実行が完了するまでに数分かかる場合があります。イメージが正常にプッシュされたことを確認するには、以下のコマンドを実行してください。コマンドからの出力に新しいイメージ名がリストアップされていれば、イメージは正常にプッシュされています。

bx cr image-list

構成ファイルの内容を理解する

このチュートリアルの冒頭で説明したように、デプロイメントとは、ポッドをどのように構成してサービスにリンクするかを記述する構成ファイルのことです。この例で使用しているデプロイメント・ファイルの形式は、Dockerfile 形式ではなく、YML です。デプロイメント・ファイルを実際にどのように作成するかについて詳しく掘り下げることはしませんが、サンプル・ファイルに関連する詳細をいくつか指摘したいと思います。ファイル形式の詳細と要素のリストについては、このリンク先の Kubernetes のドキュメントを参照してください。あるいは、以下に記載するファイル (spigot-plugin-bluemix ディレクトリー内にある deploy.yml ファイル) の内容に目を通してください。この後、このサンプル・ファイルに固有の詳細をいくつか取り上げて説明します。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: spigot
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: spigot
    spec:
      containers:
      - name: spigot
        image: registry.ng.bluemix.net/brownkyl/spigot-plugin-bluemix
---
apiVersion: v1
kind: Service
metadata:
  name: spigot-service
  labels:
    run: spigot
spec:
  selector:
    app: spigot
  type: NodePort
  ports:
   - protocol: TCP
     port: 25565

このファイルで最も注目に値する点は、破線「---」で区切られた 2 つのセクションに分かれていることです。最初のセクションには、デプロイメント自体が記述されています。このデプロイメントが作成する (replicas: 1 で示された) 単一のポッドは、spigot-plugin-bluemix イメージだけで構成されます。

2 番目のセクションには、ポッドを外部に公開するために作成するサービスが記述されています。この例の場合、NodePort という、間違いなく最も単純なタイプの公開手段を使用しています。NodePort は、リクエストを特定のポートにルーティングする手段であり、この例ではポート 25565 (Docker イメージによって公開されるポート) にルーティングします。

ポッド内のイメージにルーティングするには、NodePort よりも遥かに回復力に優れた複雑な手段があります。テストでのルーティングのために使用するには NodePort で十分ですが、実際の本番アプリケーションで使用するとなると、いくつかの欠点があります。具体的には、Docker イメージで障害が発生した場合 (障害は発生しがちです!)、NodePort にはトラフィックをポッドの別のインスタンスにリダイレクトするためのメカニズムがありません。同様に、同じポッドの複数のインスタンスにトラフィックをルーティングするためのメカニズムもないため、スケーラビリティーを確保することもできません。このシリーズの範囲外ですが、障害からの回復力とスケーラビリティーを実現するには、Ingress Controller などの複雑なルーティング手段を選択できます (詳細について興味がある場合は、このリンク先の Kubernetes のドキュメントを参照してください)。

話を元に戻すと、ついに初の Kubernetes サービスをデプロイする準備ができました!

ポッドとサービスをデプロイする

deploy.yml の内容を確認したので、このデプロイメント・ファイルを実行すると何が作成されるのかは理解できているはずです。デプロイメントを作成するには、kubectl に含まれている create コマンドを実行します。コマンド・ラインで以下のコマンドを実行して、デプロイメントを作成してください。

kubectl create -f deploy.yml

何らかの理由で、デプロイメントの作成が失敗することもあります。deploy.yml ファイルにエラーがあったり、デプロイメント・ファイル内で指定されている名前と名前が一致する正しいレジストリーにイメージをデプロイできなかったりすると、問題にぶつかります。そのような場合は、以下のコマンドを使用してデプロイメント・ファイルをクリーンアップしてください。

kubectl delete -f deploy.yml --all

デプロイメント・ファイルをクリーンアップした後、ポッドとサービスを再び作成するために、上記の kubectl create コマンドを再実行します。

サーバーをテストする

この実験はあと一息で完了です!ポッドをデプロイし、そのポッドにアクセスするサービスを作成するところまでの作業は終わっています。次は、外部からポッドにアクセスする方法を調べます。NodePort は、Kubernetes クラスター内の各ワーカー・ノード上でポートを公開します。IBM Container Service の無料の料金帯で使用できるワーカー・ノードは 1 つに限られているので、以下のコマンドを実行して表示されるIP アドレスは 1 つだけです。

bx cs workers Minecraft

このコマンドを実行すると、以下のような結果が出力されます。

Listing cluster workers...
OK ID Public IP Private IP  Machine Type   State Status   
kube-hou02-pa223babd2966d473cb031e7812024ce52-w1   189.172.1.211   10.76.193.152   free    normal   Ready

必ず、上記の出力に示されているパブリック IP アドレス (この例では、189.172.1.211) をコピーしておいてください。Minecraft spigot サーバーがどの IP アドレスで稼働しているかを確認した後は、NodePort サービスがイメージ内の 25565 にリダイレクトしたポートを確認する必要があります。それを調べるには、コマンド・ラインで以下のコマンドを実行します。

kubectl get svc

このコマンドを実行すると、以下のような結果が出力されるはずです。

NAME       CLUSTER-IP   EXTERNAL-IP       PORT(S)           AGE
kubernetes 	     10.10.10.1   <none>      443/TCP           14d
spigot-service   10.10.10.217 <nodes>     25565:32225/TCP   8m

前のステップと同様に、2 番目のポート (コロンの後に続くポート。この例では、32225) をコピーします。この後、以上の作業によって確認した IP とポートの組み合わせ (IP:ポート) を Minecraft クライアント内で使用します。

クライアントをテストする

サーバーをテストするプロセスは、第 1 回と第 2 回で行ったプロセスとほとんど同じです。Minecraft クライアント内の「Direct Connect (直接接続)」ボタンを使用することで、サーバーが機能しているかどうかを簡単に調べることができます。Minecraft にログインして、「Multiplayer (マルチプレイヤー)」を選択してから、「Direct Connect (直接接続)」ボタンをクリックします。

「Direct Connect (直接接続)」ボタンを使用してサーバーをテストする画面のスクリーンショット
「Direct Connect (直接接続)」ボタンを使用してサーバーをテストする画面のスクリーンショット

この操作により、Minecraft に、サーバーのアドレスを入力するよう求める画面がポップアップ表示されます。前のステップで確認した、ワーカー・ノードのパブリック・アドレスとルーティングされたポートの組み合わせを入力します。

直接接続するサーバーのアドレスを入力する画面のスクリーンショット
直接接続するサーバーのアドレスを入力する画面のスクリーンショット

アドレスとポートを入力したら、「Join Server (サーバーに参加)」をクリックします。これで、Minecraft サーバーに接続してバーチャル世界を表示できます!

まとめ

このチュートリアルでは、IBM Container Service を利用して Kubernetes ライト・クラスターをセットアップし、必要最小限の Minecraft Spigot サーバーを IBM コンテナー・レジストリーにプッシュするために必要な手順、そして単一インスタンスの Kubernetes ポッドと NodePort サービスを作成するデプロイメントを作成する手順を説明しました。この一連の手順によって、現時点で Minecraft クライアントを IBM Cloud 上で稼働するサーバーに接続できるようになっています。

第 4 回ではシリーズの締めくくりとして、Watson Conversation サービスを利用する、より複雑な Minecraft 用プラグインを作成します。このプラグインによって、Watson と対話し、Minecraft の村民たちを苦しませている病に関する情報を収集できるようになります。次回のチュートリアルでまたお目にかかるまで、IBM Cloud が提供している Docker イメージの管理およびデプロイ機能の調査をお楽しみください!


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Java technology, Cognitive computing
ArticleID=1025326
ArticleTitle=Minecraft とIBM Cloud, 第 3 回: Kubernetes 内で Spigot サーバーを稼働させる
publish-date=03082018