【GCP入門編・第7回】知らなきゃ損！ Google Container Engine (GKE) での Dockerイメージを使ったコンテナの起動方法！

本記事では、 Google Cloud Platform (GCP) のコンテナ環境である、 Google Container Engine (GKE) を使ったコンテナイメージのデプロイに関して解説します。実際に GKE 上で Docker コンテナを動作させることで、 GKE の持つ可能性を感じて頂こうと思います。

この記事の目的

• Google Container Engine の概要を理解しよう。
• Docker の概要を理解しよう。
• Google Container Engine を使って Docker イメージを立ち上げてみよう。

Google Container Engine (GKE) とは

Google Container Engine (GKE) は Google が開発した、現在オープンソース化されている Kubernetes をベースとしたコンテナ環境です。 Kubernetes は、1つ以上のコンテナから構成されるクラスターの自動的な管理やスケールを行う、オーケストレーションツールです。類似するシステムとしては、 Apache 財団が開発する Marathon や、 Docker社 の開発する Docker Swarm というものがあります。
最近頻繁に利用される、複数の小さなサービスの連携により１つのサービスを構成する、いわゆるマイクロサービス環境を実現するにあたり、 Kubernetes はサービスの構成や各役割を持ったクラスターの定義を宣言し、自動的に管理することが可能です。
Kubernetes を開発した Google が運営する GCP では、 GKE 上で Kubernetes の機能をフルに活用することができます。

Docker とは

Google Compute Engine では、操作する対象はインスタンスでした。インスタンスとは仮想マシンのことで、物理的なサーバーと同じく OS が動作し、ネットワークインターフェースやストレージを接続することのできる、仮想化されたサーバーです。通常、1つの物理的なサーバー上で複数の仮想マシン(インスタンス)を動作させます。この概念によれば、仮想マシンは物理マシンとほぼ同じように考えることができるため、理解しやすいのではないでしょうか。
それでは、 GKE を使う場合、操作する対象はなんなのでしょうか。 GKE の製品紹介ページを見ると、 ”Google Container Engine is a powerful cluster manager and orchestration system for running your Docker containers” と書かれています。 GKE はクラスターの管理を行うものであり、 Docker コンテナを動作させるためのオーケストレーションシステム、というわけです。
それでは、Docker とはどのようなシステムなのでしょうか。
Docker は、仮想化技術の1つである、コンテナ型仮想化を使ってアプリケーションを実行するためのソフトウェアです。 Docker は、1つのOS上で任意の数の Docker コンテナと呼ばれる環境を作成します。 Docker コンテナは、ファイルシステムやプロセスツリー、ネットワークが他のコンテナと隔離されていて、直接お互いが干渉することはできません。
アプリケーションは Docker コンテナ内で動作するため、1つのアプリケーションを動作させるための Docker コンテナは、そのアプリケーションが必要とする依存ライブラリなどを持っておけばよいことになります。
Docker コンテナの元となるのが、 Docker イメージです。 Docker イメージは元となる最小限の OS イメージに対して、アプリケーションを動作させるまでに行った差分が保存されています。 Docker は、Docker コンテナを起動する際に、この差分が含まれた Docker イメージをロードすることで、アプリケーションとそれを動作させる環境を作成します。
Docker イメージは状態を持たず、作成後は変化することがありません。このため、アプリケーションのアップデートを行うためには、新しいバージョンの Docker イメージを作成して、 Docker コンテナを起動することになります。
Puppet や Chef といった構成管理ツールでは、依存するライブラリのバージョンを上げていくといった作業を何回も行っているうちに、ライブラリ同士の依存がコンフリクトするケースなども多くありました。また、開発環境と本番環境で環境が大きく異なってしまい、本番環境でのみ起こるバグが発生するといった問題も見られました。
Docker を用いたコンテナ型仮想化では、常にベースとなるまっさらな OS に対しての差分となりますので、コンフリクトを気にしなくても良いといったメリットがあります。
また、開発環境と本番環境の差がほとんどないため、安心してデプロイを行うことができます。
Docker が登場したことで、コンテナは jail の時代に比べて非常に身近なものになりました。これを読まれている方の中にも、 Docker で開発し、そのまま Docker イメージをデプロイする、というスタイルで開発をされている方もいらっしゃると思います。コンテナは仮想マシンと比べると、フルセットの OS が動作している訳ではないため、起動のオーバーヘッドが低く、仮想マシンよりも気軽に立ち上げて捨てることが可能です。

Google Container Engine (GKE) の概要

GKE は多数のコンテナを使って1つのサービスを実現する際に、サービスがどのようなコンテナで構成されるかを定義すれば、コンテナの立ち上げ、モニタリング、ロードバランシング、サービスの自己修復などを行うことができます。このように、多数のコンテナを協調動作させるためのシステムを、コンテナオーケストレーションシステムと呼びます。
Kubernetes で扱う最小単位は、 Pod と呼ばれます。 Pod は1つ以上のコンテナを含み、１つの機能を実現する論理的な単位です。例えば、 nginx が動作する Pod というように、単一の役割を担います。
この Pod を複数集めた構成を作成するのが、 Deployment と呼ばれる単位で、 ReplicaSet を管理します。
ReplicaSet は、複数の Pod を組み合わせてアプリケーションの機能を実現したものとなります。 Deployment はこの ReplicaSet を管理し、アップデートの際に新規の ReplicaSet を作成してアプリケーションのバージョンアップを行います。
このような流れで、 Deployment はサービスを停止せずにアプリケーションのアップデートを実現しています。
そして、この Deployment に対して外部からアクセス可能な IP アドレスを付与し、外部からアクセスできるようにしたものが Service です。 Service として外部からアクセス可能にする際には、ロードバランサーを設定することも、ポートを指定して公開することも可能です。
Kubernetes では、この Service が複数動く環境をクラスターとしています。クラスターは1つの Master と複数の Node から構成されます。 Node はコンテナを動かすためのサーバー、 Master はこれらの Node を管理し、スケジューリングやオートスケールを行います。
少し説明が長くなりましたが、 Kubernetes の概念がなんとなく理解できたのではないでしょうか。 Kubernetes の概念や構成についてより詳しく知りたい場合は、Kubernetesのチュートリアルと、
GKEのドキュメントが参考になるでしょう。
それでは、 GKE を使って Web アプリケーションを動作させてみましょう。

Container Engine を使って Docker イメージを立ち上げる

さて、ここからは GCP のコンソールから実際にクラスター(ここでは1ノードのクラスター)を立ち上げて見ましょう。
まずは、 GCP のコンソール左側メニューから、 API Manager をクリックし、 Datastore の時と同様に、 Library から Container Engine API を Enable にします。

次に、左側のメニューの Container Engine をクリックします。
初期状態ではクラスターが作成されていないため、クラスターを作成するボタンが表示されますので、 ”Create a container cluster” をクリックしましょう。すると、新規クラスターの作成画面が表示されます。

Name, Description には任意の値を入力し、 Zone は東京リージョンである asia-northeast-1a を指定します。 machine type は small を、 Node image は gci を選択。 Size には1を指定します。 Size に指定した分だけインスタンスが起動します。
ここまで指定したところで、 Create ボタンをクリックすることで、コンテナが起動します。

さて、ここでローカルのターミナル上で、以下のコマンドを打ちます。
すると gke-クラスター名-default-pool-... というインスタンスが、表示されているのではないでしょうか。

$ gcloud compute instances list

次に Docker コンテナをこのクラスター上で起動します。先ほど書いたように、 Kubernetes では Pod という単位で1つ以上のコンテナのグループを管理します。今回は、 WordPress の Docker イメージが1つ動作する Pod を、このクラスター上で動作させます。
Kubernetes の操作は、 kubectl というコマンドラインツールを通して行います。 kubectl を使うと、クラスターに対する操作を行うことができます。
まずは以下のコマンドで、 kubectl をインストールします。

$ gcloud components install kubectl

kubectl のインストールが完了後、 kubectl が Container Engine のクラスターを認識可能にするため、環境変数を設定し、 gcloud の設定にデフォルトの zone を指定します。

$ export PROJECT_ID="プロジェクトID"
$ gcloud config set compute/zone asia-northeast1-a

そして、 kubectl が先ほど作成したクラスターにアクセスできるよう、認証情報を取得します。 gcloud auth コマンドを入力すると、 OAuth の認証画面がブラウザに表示されるので、アクセスを許可します。

$ gcloud auth application-default login
$ gcloud container clusters get-credentials クラスター名

次に、 kubectl を使って Pod を立ち上げます。次のコマンドを打つことで、 WordPress の Image (tutum/wordpress) が起動します。

$ kubectl run wordpress --image=tutum/wordpress --port=80

deployment "wordpress" created というメッセージが表示されれば成功です。

以下のコマンドで、デプロイされた Deployment の情報を閲覧することができます。

$ kubectl describe deployments

さて、デプロイした WordPress はこの状態ではアクセスすることができません。 Pod は IP アドレスを持っていますが、これはクラスター内部からしかアクセスすることができないため、 Service を作成して外部からのアクセスを LoadBalancer 経由でアクセス可能にしなければなりません。この操作を、 kubectl では ”kubectl expose deployment” コマンドで行います。

$  kubectl expose deployment wordpress --type=LoadBalancer

これでサービスの公開が開始されます。以下のコマンドで IP アドレスなどの状態をチェックします。

$ kubectl describe services wordpress

コマンドの実行からしばらくは、一番下の ”Events” に Creating load balancer と表示されているかと思います。何度か kubectl describe services コマンドを実行していると、この下に、 Created load balancer と表示されます。これが表示されたということは、ロードバランサーの準備が完了したことを意味しており、クラスター外部からのアクセスが可能になっています。
kubectl describe services コマンドの出力に表示された ”LoadBalancer Ingress” をブラウザで開くと、 WordPress の管理画面が表示されているかと思います。

いかがでしたでしょうか。立ち上げた WordPress は、放っておくと勝手に使われかねない状態になっていますので、 Service と Deployment を削除します。

$ kubectl delete services wordpress

$ kubectl delete deployment wordpress

Container Engine を使って複数のコンテナを起動する

GKE では、複数のコンテナを同時に起動することも簡単にできます。試しに、複数の nginx が動作するコンテナを立ち上げてみます。以下のコマンドを実行することで、2つの nginx が動作する Pod が起動します。

$ kubectl run nginx --image=nginx --replicas=2

describe コマンドにより、 Replicas: の項目が2となっていることが確認できます。

また、ここで以下のコマンドで起動中の Pod を確認すると、2つの Pod が立ち上がっていることが分かります。

$ kubectl get pods

先ほどの WordPress の場合と同様、 LoadBalancer として Service を作成します。

$ kubectl expose deployment nginx --type=LoadBalancer

describe services コマンドで IP を確認します。

$ kubectl describe services

ブラウザで LoadBalancer Ingress に表示された IP を開くと、 nginx が起動していることがわかります。

このように、 GKE では簡単に複数のコンテナを立ち上げることができ、アクセスを LoadBalancer で振り分ける、といったことも可能です。
先ほどと同様、 Deployment と Service を削除します。

$ kubectl delete services nginx

$ kubectl delete deployments nginx

最後に、クラスターを終了します。クラスターの終了には gcloud コマンドを使用します。

$ gcloud container clusters delete クラスタ-名

おわりに

いかがでしたでしょうか。このように GKE では、単一の Docker コンテナでクラスターを構成する、複製された複数のコンテナを素早く立ち上げる、といったことが可能です。これは特に、 Web アプリケーションでよく使われるワーカーをスケールさせる際に非常に強力なツールとなるのではないかと思います。
次回は、自分で作成した Docker Image を Container Registry に登録し、起動させる方法を解説します。

弊社トップゲートでは、Google Cloud (GCP） 利用料3%OFFや支払代行手数料無料、請求書払い可能などGoogle Cloud (GCP）をお得に便利に利用できます。さらに専門的な知見を活かし、

• Google Cloud (GCP）支払い代行
• システム構築からアプリケーション開発
• Google Cloud (GCP）運用サポート
• Google Cloud (GCP）に関する技術サポート、コンサルティング

など幅広くあなたのビジネスを加速させるためにサポートをワンストップで対応することが可能です。

Google Workspace（旧G Suite）に関しても、実績に裏付けられた技術力やさまざまな導入支援実績があります。あなたの状況に最適な利用方法の提案から運用のサポートまでのあなたに寄り添ったサポートを実現します！

Google Cloud (GCP）、またはGoogle Workspace（旧G Suite）の導入をご検討をされている方はお気軽にお問い合わせください。

お問合せはこちら


メール登録者数3万件！TOPGATE MAGAZINE大好評配信中！
Google Cloud（GCP）、Google Workspace（旧G Suite） 、TOPGATEの最新情報が満載！

メルマガ登録はこちら