まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:cloud

このブログエントリの続きです。IBM CIS(Cloud Internet Services) とその設定方法についてはこちらをどうぞ:
IBM Cloud で CIS を使って証明書作成なしにカスタムドメインの https アクセスを行う


上記リンク先の設定を行うことで、アプリケーションファイアウォールや DDOS 対策など、簡単に安全なインターネット運用環境を構築することができます。これはこれで便利なのですが・・・

一方でこの設定が不要なタイミングもあります。典型的な例は「アプリケーション開発時」です。CIS の防御モードが有効になっている環境では、ウェブブラウザからアクセスした時にいったんそのリクエストを受け取った上で「そのリクエストが攻撃でないことを確認」します:
2019110706
 ↑リクエスト確認中の画面

 ↓問題ないと判断されるとオリジンサーバーへ転送されます
2019110707


つまりウェブブラウザからのアクセスであればリクエストの転送機能を使って安全なアクセスが可能になる、という仕組みで実現されています。サービスの運用段階であれば、これが問題になることはあまりないと考えられます。

一方でサービスの開発段階においては少し事情が異なります。API の単体テストなど、ウェブブラウザを使って行うこともありますが、curl などのコマンドやツールを使って行われることも珍しくありません。この場合、curl のリクエストに対して上記「リクエスト確認中」画面の HTML が返ってくるだけで、確認された結果のレスポンス(テストではこれを知りたい)が返ってくるわけではないのです:
$ curl https://XXXXX.XXXXX.com/api/users

<!DOCTYPE HTML>
<html lang="en-US">
<head>
  <meta charset="UTF-8" />
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" />
  <meta name="robots" content="noindex, nofollow" />
  <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" />
  <title>Just a moment...</title>
  <style type="text/css">
    html, body {width: 100%; height: 100%; margin: 0; padding: 0;}
    body {background-color: #ffffff; font-family: Helvetica, Arial, sans-serif; font-size: 100%;}
      :
      :
  ↑青字部分はリクエスト確認中画面の HTML 、これでは動作確認にならない


つまり開発段階で CIS を使う場合、ドメイン設定や SSL 対応などはそのまま使えますが、防御モードに関しては一時的に無効にしたくなるケースが出てくるのでした。この防御モードを無効にするための設定方法を紹介します。


といってもその手順は極めてシンプルで、サービスモードを無効にするだけです:
2019111500


この解除を行うことでドメインの DNS や SSL 対応などを残したまま、防御チェックだけを一時的に無効にすることができるようになります。



IBM Cloud から提供されている、Web コンテンツ向けにセキュリティやパフォーマンスといった非機能要件を統合的に設計するサービス、それが CIS(Cloud Internet Services)です。mybluemix.net などの IBM Cloud から提供される標準ドメインではなく、独自ドメインを使うことが前提となりますが、そのドメインで運用するウェブアプリケーションやコンテンツ全般を保護して、安全なインターネット環境を提供することができる便利なサービスです:

https://www.ibm.com/jp-ja/cloud/cloud-internet-services
2019111600


この CIS は(独自ドメインの)DNS を使うことでオリジンサーバーとは別の( Cloudflare 社の)サーバーを経由してオリジンサーバーにアクセスします。この中間サーバーを経由することで必要なセキュリティ要件やコンテンツ保護要件を提供する、というものです。

この CIS を利用して、クライアント(ウェブブラウザ)からの SSL(https) 通信を実現するには大きく3種類の方法があります:

(1)クライアント→中間サーバー→オリジンサーバー 間すべての通信をセキュアに行う方法
(2)クライアント→中間サーバー 間はセキュアに行い、 中間サーバー→オリジンサーバー 間の通信は自己証明書を使った暗号化通信を行う方法
(3)クライアント→中間サーバー 間はセキュアに行い、 中間サーバー→オリジンサーバー 間の通信は HTTP 通信で行う方法
2019110703


①、②、③いずれも共通でクライアントと中間サーバーとの間はセキュアな SSL 通信を行います。中間サーバーとオリジンサーバー間の通信をどう考えるか、という点が異なります。ざっくりいうと①がもっともセキュアで、③がもっともセキュアでない方法となります。

①は理想的といえる方法で、全ての区間がセキュアな通信となります。②も通信自体は SSL で暗号化通信となりますが、その際に利用する証明書はいわゆる「自己証明書」となります。①と比較すると(外部の業者などを使わずに)自分で証明書を作ることができるので、コストや有効期限の自由度などの面でメリットがありますが、「要は誰でも(ドメインのオーナーでなくても)作れる証明書」を使った暗号化通信を行う点が異なります。この証明書を普通に使って直接 SSL 通信を行うと、普通は「セキュアな通信でないが、それでも通信するか?」といった確認メッセージを経て通信可能になったりしますが、中間サーバーとして CIS を入れることにより、クライアントはそういった手順を経ずに通信できるようになります。

そして③の方法ですが、これは中間サーバーとオリジンサーバーとの間の通信は暗号化しない方法です。セキュアかどうか、という観点では暗号化しない経路が存在しているわけで他の2つよりは劣っています。一方で、この方法では証明書の作成を必要としません。クライアントから見た証明書は CIS の中間サーバーが自動で発行されたものが使われ、オリジンサーバーには(そもそも暗号化通信をしないので)証明書が不要です。開発段階や試験段階など、インフラに関わる権限が小さい状況下で、かつ(API の仕様など)https 通信が必須となるような場合においては非常に有要な選択肢となります。またこの方法であれば(そもそも取得しないので)証明書の有効期限切れを心配する必要もありません。 また特にオリジンサーバーとして IBM Cloud の PaaS 環境を利用する場合であれば、オリジンサーバーのルーティングを編集してカスタムドメインでのホスト名でしかオリジンサーバーにアクセスできないように設定することで(HTTPS を使わずにアクセスするような)迂回路を遮断する設定にすることも可能です。

今回はこの③の方法でカスタムドメインの https アクセスを行うための設定を紹介します。

まず IBM Cloud の CIS サービスを利用してプロビジョン済みの状態とし、普通にドメインを登録して設定します。その上で「セキュリティ」カテゴリーの「TLS」内で動作モードを「クライアントからエッジ」に設定します(これが③の通信のための設定となります):
2019110701


なお、このモードの設定内容によって上記図の①~③の通信方法が変わります。以下のような関係です:
2019110704


また DNS の CNAME でオリジンサーバーとの紐付けを行います(下図の「信頼性」-「DNS」)。このカスタムドメインの頭につけるホスト名を指定して、CNAME の参照先となる別名を指定します。IBM Cloud の PaaS (米国南部リージョン)を使う場合は参照先を us-south.cf.cloud.ibm.com を指定します。また「プロキシー」を有効にします:
2019110702


なお、ここで指定する参照先と IBM Cloud PaaS のリージョンとの関係については以下を参照ください:
https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-custom-domains

最後にオリジンサーバー側を用意します。IBM Cloud PaaS の場合であれば(CNAME で指定した名前).mybluemix.net でアクセスできるようなアプリケーションサーバーを CloudFoundry ランタイムとして作成します(このルーティングは最終的に削除します)。


また IBM Cloud PaaS の場合は「管理」メニューからカスタムドメインを登録する必要があります。この手順の詳細はこちらを参照ください(このリンク先では証明書をインポートする手順まで紹介していますが、今回ここでは SSL の設定を行う必要がないので不要です):
http://dotnsf.blog.jp/archives/1075713365.html


最後に上記で作成した Cloud Foundry ランタイムのルーティングを編集します。経路の編集から「経路の追加」を実行し、mybluemix.net ドメインと同じ名前を指定したカスタムドメイン用の経路を追加します(証明書をインポートしていないので鍵マークには×がついているはずです)。そしてもともとの mybluemix.net 側の経路を削除します。これでカスタムドメインを使った指定でないとアクセスすることはできなくなりました。最後に「保存」します:
2019110705


この状態でカスタムドメインを指定したホスト名で https アクセスを行ってみます。まず最初に CIS がリクエストを受け取ってアクセス内容を(アタックに相当するアクセスでないか)判断します:
2019110706


問題がないと判断されるとオリジンサーバーにルーティングが行われます。結果的に証明書を独自に発行することなくカスタムドメインを使った https 通信ができるようになりました:
2019110707



【参考】
IBM Cloud Certificate Manager で Let's Encrypt 無料 SSL 証明書を取得する



マンホールマップの新バージョンを開発中です。暇を見つけて開発しているので、作業が進む時期も進まない時期もあったりしていましたが、とりあえず最低限の機能の実装はできつつあり、だんだんアプリケーションとしての形になってきました。まだ開発中なので、画面は変更する可能性もありますが、一部の機能をチラ見せしつつ予告編のような形で紹介します。


【新バージョンのテーマ】
ずばり「地図へのこだわり」と「技術の無駄遣い」です。現行版もおなじテーマで開発しており、マップのネーミング通り、地図機能にこだわりつつも、人工知能など比較的あたらしい技術要素を含んだりしていましたが、自分的にはそろそろ更に新しい技術テーマにも挑戦したいと考えていました。既存バージョンからの機能拡張では済まないような、基盤よりの新技術テーマにも挑戦したかったので、新バージョンという形でまったくゼロからのスクラッチ開発に取り組みました。

ちなみに開発言語は現行版が Java でしたが、新バージョンでは Node.js を使います。過去のマンホールマップのプラットフォームは Google App Engine だったり、J2SE だったりしましたが、開発言語はずっと Java を使っていました。その意味でも全くのゼロからの作り直しとなります。


【新バージョンの技術目標】
大きなものは以下の3つです:
- レスポンシブ対応を含めた新ユーザーインターフェース
- ハイブリッドクラウド化
- ブロックチェーン対応

「レスポンシブ対応」とは「PC ブラウザでもスマホブラウザでも、使っているデバイスの画面サイズにあわせてそれなりに使えるようにする」ことを意味しています。現行版も一応スマホ対応していますが、これはスマホ用の画面を PC 用とは別に作っていて、「スマホの人はこっちのページ」という対応でした。 この方法はメンテナンス時に互いの影響を少なくすることはできますが、2つのアプリを同時に開発するような側面もあって、開発する側としては面倒なものでもありました(現実的にはスマホからは使えない機能も多くあります)。 今回ははじめからレスポンシブ化を目指して開発を進めています。今の所 100% レスポンシブ対応できるようになるかどうかは微妙な予感がしていますが(苦笑)、数カ所を除いてなんとかがんばる予定です(←既に数箇所諦めています (^^;)

なお、現在開発中の画面の一部を公開します:
2019091601


2019091602


このカレンダー機能は実は現行版にも含まれていますが「隠し機能」的な位置づけでした。新バージョンではメニューから表示できるようにします:
2019091603


ゲーム要素にも新しい画面を取り入れる予定です。これは「アタック25」モードのページ:
2019091604



次に「ハイブリッドクラウド化」。まず現行版は私の自宅にある ThinkPad 内にアプリケーションサーバーとデータベースサーバーをインストールして動いています。要は(一部の機能は外部APIを使っていますが)ほとんどを自宅内のリソースで提供しています。クラウド時代をある意味で逆行しているものです(ただ個人開発者としては今でもこの形のアドバンテージはあると思っています)。これを一部パブリッククラウドに移して(一部は自宅に残して)コンテナ化するようなハイブリッドシステムを構築する方向で進めています。詳しいシステム構成は後述します。

最後の「ブロックチェーン対応」、これは改ざんが困難な仕組みである「ブロックチェーン」の技術を使い、利用者がマンホールマップにアップロードしたデータが正しいものである(改ざんされていないものである)ことを保証する仕組みを提供するつもりです。


【新バージョンのシステム構成(予定)】
上記の要素を取り入れ、マンホールマップのシステム構成は現行のこの形から、
2019091501


最終的にはこのような形に変更する予定です。今まで以上に公私混同具合が大きくなります(苦笑):
2019091502
(↑ブロックチェーン部分のネットワーク構成は面倒なのでかなり省略)


なお、データベースサーバーのみ独立して自宅サーバーで稼働し続ける形になりますが、これもいずれはパブリッククラウド化を考えています(当面自宅に残す理由はコストパフォーマンスの問題です。クラウドのデータベースサービスは高い・・)。


リリースを優先する意志もあるので、新バージョン公開段階でどこまで実装できているかはまだ不確定要素もありますが、この最終形を目指して開発を進めていくつもりです。なお UI はまだ変更の可能性が高いのですが、ハイブリッドクラウド化とブロックチェーン対応は試験的にはもう動いていて、技術的な目処はついています。


【新バージョンの公開予定】
新バージョンは現時点では令和元年11月2日に開催予定の「マンホールナイト11」にてお披露目予定です。可能であれば(そして大きなトラブルがなければ)この日に前後する形でシステム公開するつもりでいます。




 

IBM Cloud の PaaS を独自ドメインで、かつ SSL で使ってみました。あまり日本語情報が見つからなかったこともあり、備忘録メモとしてブログエントリにしました。

まず IBM Cloud の PaaS を使うことで、Java や Node.js、PHP などのランタイム(アプリケーション・サーバー)が選択するだけで利用可能になります。利用者はそのランタイムの上で動くアプリケーション(Java なら war ファイルとか、プロジェクトのディレクトリとか)を作って Push(アップロード)するだけでアプリケーションが動きます。 また IBM Cloud の PaaS ではデフォルトで利用可能なドメイン(米国南部データセンターであれば mybluemix.net)があり、このデフォルトドメインを使って稼働させる場合は標準で SSL に対応しているため、特に証明書などを意識することなく SSL 通信可能なアプリケーションを動かすことができます:
2019091307


一方で IBM Cloud の PaaS を(別途取得した)独自ドメインで利用することも可能です(IBM Cloud では「カスタムドメイン」と呼んでいます):
2019091305


カスタムドメインの設定自体は(単純に指定するだけなので)あまり難しくないのですが、カスタムドメインで運用するサーバーを SSL 対応させたことはいままでにありませんでした。今回その機会があり、個人的に躓いた箇所もあったので、一通りの手順を確認してメモ目的で残すことにしました。


【前提条件】
以下の前提条件を元に以降を記載します:
(1)独自ドメインは取得ずみ、DNS設定可能
(2)IBM Cloud はスタンダードアカウント

(1)は今回利用する独自ドメインを既に取得済みであるものとします。今回は僕が個人で取得している teyan.de ドメインを使うことにします。今回の手順の中でこのドメインの DNS 設定を変更する必要があり、その方法は DNS 取得業者によって変わってくるのですが、そのための権限を持っていて、DNS を変更する手順などを理解しているものとします。

また(2)ですが、IBM Cloud は無料のライトアカウントで利用することも可能です。ただ今回のカスタムドメインの利用についてはライトアカウントでは許可されておらず、Pay-As-You-Go などのスタンダートアカウントでの ID を取得している必要があります。


【目的】
IBM Cloud 上で稼働する test20190912.mybluemix.net をカスタムドメイン化して test20190912.teyan.de でアクセスできるようにして、かつ SSL 対応する。つまり https://test20190912.teyan.de/ でアクセスできるようにする
2019091306

↑今回はこれを実現するための手順を以下で紹介しますが、他のホスト名で利用する場合の設定は "test20190912" の部分を適宜読み替えてください。


【ドメインのワイルドカード証明書の準備】
この目的を達成するためには test20190912.teyan.de の証明書が必要になりますが、IBM Cloud の場合はドメインのワイルドカード証明書、つまり *.teyan.de の証明書を用意する必要があります。

試験的な利用であれば(スマホからのアクセスを考慮するとちと面倒ですが)オレオレ証明書でもいいと思いますし、自動更新ができないデメリットを理解した上で Let's Encrypto のワイルドカード証明書を用意してもいいです。もちろん有償でワイルドカード証明書を用意しても構いません。とにかく目的のドメイン(今回は *.teyan.de)のワイルドカード証明書(の公開鍵ファイル、秘密鍵ファイル、中間鍵ファイル)を取得してください。

自分は Let's Encrypto を使いました。Let's Encrypto でのワイルドカード証明書は3ヶ月程度で手動更新する必要がありますが、無料という強力な魅力があります。Let's Encrypto を使ったワイルドカード証明書の取得手順はこちらを参考にさせていただきました:
Let's Encrypt ワイルドカード証明書の取得手順メモ

この手順に従うなどして、目的ドメインのワイルドカード証明書である公開鍵ファイル(cert1.pem)、秘密鍵ファイル(privkey1.pem)、中間鍵ファイル(chain1.pem)を取得したと過程して以下を続けます。


【IBM Cloud にカスタムドメインを追加設定】
次に IBM Cloud 側に自分の独自ドメインを利用するための設定を行います。上述しましたが、この手順は IBM Cloud の(無料の)ライトアカウントでは行うことができません。スタンダードアカウントにアップグレードした上で行う必要がある点にご注意ください。

まず IBM Cloud に(ライトアカウント以外のアカウントで)ログインして、画面上部のメニューから 「管理」 - 「アカウント」 を選択してから、画面左のメニューで 「CloudFoundry の組織」 を選択し、「ドメイン」タブを開きます。そして「ドメインの追加」ボタンを押します:
2019091301


ダイアログが表示されるので、追加する取得済みドメイン(下図では "teyan.de" )を「追加」します。またこの時にアプリケーションをデプロイするデータセンターのロケーション(下図では「米国南部」)を指定します:
2019091302


1つ前の画面に戻り、指定したドメインが一覧に追加されていることを確認します。SSL を使わない場合はこれだけで設定完了ですが、SSL を使う場合は続けて上述の手順で取得した証明書ファイルをアップロードする必要があります。「アップロード」と書かれた箇所をクリックします:
2019091303


SSL 証明書の追加ダイアログが表示されるので、証明書、秘密鍵、中間証明書のファイルをそれぞれ指定し、最後に「追加」します:
2019091304


再度1つ前の画面に戻ります。追加直後は SSL 証明書欄が「保留中」となっているはずで、しばらく(数分)待つ必要があります:
2019091305


処理が反映されると SSL 証明書欄が鍵のかかったアイコンに代わります。これでカスタムドメインの IBM Cloud への追加設定は完了しました:
2019091306


【IBM Cloud にアプリケーションをデプロイ】
クラウド上にアプリケーションを(今回の例では test20190912 という名前で)デプロイします。最終的には test20190912.teyan.de というホスト名でアクセスできるようにしますが、まずは普通に(デフォルトドメインを使って)test20190912.mybluemix.net でアクセスできるものを作成します(今回は標準の HelloWorld アプリ(NodeJS Starter Application)をそのまま使います)。デフォルトドメインはこの時点で SSL 対応しているので、 https://test20190912.mybluemix.net/ でアクセスできます:
2019091307


【カスタムドメイン用のルーティングを追加】
その後、このアプリケーションにカスタムドメインのルーティングを追加します。

アプリケーションの概要ページへ移動し、画面右上の「経路」メニューから「経路の編集」を選択します:
2019091301


ダイアログが表示されます。この時点で test20190912.mybluemix.net だけが表示されていると思いますが、「経路の追加」ボタンをクリックし、下図のように test20190912.teyan.de の経路にも対応するよう追加します。ここまでの手順が正しく実行されていればカスタムドメイン(teyan.de)の経路も証明書がインポートされているので鍵がかかったアイコンになっているはずです。最後に「保存」をクリックします:
2019091302


ここまでの手順を行ってから再度「経路」ボタンをクリックすると、設定した2つの経路が表示されるようになります。これで IBM Cloud 側では test20190912.teyan.de を SSL で表示できるようにするための設定が完了しました:
2019091303


【DNS の CNAME 設定】
後は test20190912.teyan.de へのアクセスがあった場合に、このアプリケーションサーバーにアクセスされるよう DNS 側で CNAME を設定してあげるだけです。が、この最後のステップがかなり戸惑いました。

独自ドメインを購入したサイトへ行き、以下のような設定を追加します:
2019091304


目的のホスト名(この例では test20190912.teyan.de)へのアクセスがあった場合の CNAME 先として、
 (IBM Cloud でのアプリ名、今回は test20190912).us-south.cf.cloud.ibm.com
にルーティングする、という設定をしています。

実は僕自身はここで躓いていました。何も考えずにここは CNAME 先を test20190912.mybluemix.net にするものだと決めつけていたのですが、これだとうまくいきません(https で接続した先で mybluemix.net の証明書が使われてしまうため)。後述のドキュメントを参照すると、ここは mybluemix.net ではなく、us-south.cf.cloud.ibm.com を指定するのが正しいようです。

なおデータセンターが米国南部の場合はこの内容でいいのですが、米国南部以外の場合は us-south 部分を変更する必要があります。詳しくは以下のページを参照してください:
https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-custom-domains


【動作確認】
上記 DNS の設定後、しばらく待って設定が反映されると、https://test20190912.teyan.de/ に(SSL 接続で)アクセスできるようになります。これで目的であった独自ドメインを使った SSL 対応ができました:
2019091306


これで IBM Cloud の PaaS を使って独自ドメインのアプリケーションを SSL 対応で運用することできるようになります。
 

これらの記事の続きです:
IBM Cloud の無料版 Kubernetes サービスを使ってみた(1)
IBM Cloud の無料版 Kubernetes サービスを使ってみた(2)


IBM Cloud の Kubernetes サービスを使って、無料のワーカーノードにアプリケーションをデプロイして、(いったん)削除する所までを紹介しました。最終回である今回は実際にアプリケーションにアクセスしたり、デプロイしたアプリケーションをスケールさせてみたり、外部(インターネット)に公開してみたりします。

今回の作業も基本的にすべて Web Terminal から行います。というわけで、まず Web Terminal を起動します:
2019041109


改めてアプリケーションをデプロイします。が、今回は後述の RC(ReplicatoinController) としてデプロイするため、デプロイ用のファイル(rc.yaml)を作成します:
apiVersion: v1
kind: ReplicationController
metadata:
  name: kubernetes-bootcamp
spec:
  replicas: 1
  selector:
    app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: myk8x
        image: gcr.io/google-samples/kubernetes-bootcamp:v1
        ports:
        - containerPort: 8080

デプロイ時にはこのファイル(rc.yaml)を指定して、以下のコマンドを実行します:
$ kubectl create -f rc.yaml
replicationcontroller/kubernetes-bootcamp created

このコマンドで前回とほぼ同様に kubernetes-bootcamp アプリケーションを1つのポッドにデプロイします。また app: web というセレクターを指定していますが、この後で使います。

この時点で kubernetes-bootcamp アプリケーションが1つのポッドにデプロイされます。一応ポッドと、そして(詳しくは後述の)サービスの状態を確認しておきます(緑字はコメント):
$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-jfswt   1/1     Running   0          41s  1ポッド

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.21.0.1   <none>        443/TCP   3d21h  ここはクラスタサービスなので無視、つまり起動したサービスなし

この時点で1つのポッドにアプリケーションがデプロイされたことが確認できました。しかしこのポッドはまだコンテナの外部からアクセスすることができません。コンテナの外部からでもアクセスできるように紐付けるサービスを作成します。

作成するサービスのための設定ファイル(service.json)を以下の内容で用意します:
{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "web"
        },
        "ports": [
            {
                "protocol": "TCP",
                "port": 80,
                "targetPort": 8080,
                "nodePort": 30000
            }
        ],
        "type" : "NodePort"
    }
}

"spec" 内で app:web のラベルをセレクターに指定しています。これが先程作成したデプロイメント時の指定内容となっていて、kubernetes-bootcamp に紐づく形になります。また 8080 番ポートをターゲットに接続し、80 番ポートで公開する、という指定も行い、"my-service" という名前でサービスを作るよう指示しています。

ではこのファイル(service.json)を使ってサービスを作成します。同時に再びポッドとサービスの内容を照会してみます:
$ kubectl create -f service.json
service/my-service created

$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-jfswt   1/1     Running   0          13m  1ポッド

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.21.0.1   <none>        443/TCP   3d21h
my-service   NodePort    172.21.30.70 <none>        80:30000/TCP   94s 追加されたサービス

サービスの追加に成功しました。またその追加されたサービスはクラスター内の内部 IP アドレスである 172.21.30.70:80 上で稼働していることがわかりました。

ではこのサービスを使ってアプリケーションにアクセスしてします:
$ curl http://172.21.30.70/
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-jfswt | v=1

アプリケーションにコンテナ外部からアクセスでき、正しく動作していることも確認できました。ただし、この時点ではまだあくまで内部ネットワーク内からのアクセスが確認できただけで、まだインターネットからはアクセスできません(後述します)。


コンテナの外部からアプリケーションにアクセスできることは確認できましたが、せっかくなので Kubernetes っぽい挙動もさせてみます。現在1つのポッドで動作しているこのアプリケーションをスケールアウトして複数の(今回は2つの)ポッドで起動するようにしてみます:
$ kubectl scale -f rc.yaml --replicas=2
replicationcontroller/kubernetes-bootcamp scaled

この状態で再びポッドとサービスの状態を確認します。ポッドが2つになっていることがわかります。(一方、サービスは何も変わっていません):
$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-kqkhp   1/1     Running   0          14s スケールアウトして新しく増えたポッド
kubernetes-bootcamp-jfswt   1/1     Running   0          109s

$ kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   172.21.0.1      <none>        443/TCP        3d23h
my-service   NodePort    172.21.30.70    <none>        80:30000/TCP   5m16s

ではこのアプリケーションをインターネットに公開してみます。以下のコマンドを実行します:
$ kubectl expose rc kubernetes-bootcamp --type=NodePort --name=web
service/web exposed

$ kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   172.21.0.1       <none>        443/TCP          4d20h
my-service   NodePort    172.21.199.105   <none>        80:30000/TCP     4m30s
web          NodePort    172.21.64.253    <none>        8080:30703/TCP   4m9s

"web" という名称のサービスが追加され、kubernetes-bootcamp の rc が expose(外部公開)されました。公開先のポート番号が 30703 になっていることも確認できます。

また、公開先の IP アドレスはワーカーノードのパブリック IP アドレスになっています。ダッシュボードから確認するか、または以下のコマンドを実行します:
2019041601
$ ibmcloud cs workers mycluster (最後のパラメーターはクラスタ名)

ID                                                 Public IP       Private IP       Machine Type   State    Status   Zone    Version   
kube-mel01-pa351ddd2ea19441a689a49159389f9d45-w1   168.1.149.201   10.118.243.103   free           normal   Ready    mel01   1.12.7_1548*


この例だと、パブリック IP アドレスが 168.1.149.201 となっているので、この 30703 番ポートに対してウェブブラウザでアクセスし、期待通りの結果になることを確認します:
2019041602


最後に、サービスとポッドを削除する場合は以下のコマンドを実行します:
$ kubectl delete svc web
service "web" deleted

$ kubectl delete -f service.json
service "my-service" deleted

$ kubectl delete -f rc.yaml
replicationcontroller "kubernetes-bootcamp" deleted


IBM Cloud の(無料の)Kubernetes サービスを使って、アプリケーションのデプロイ、スケール、動作確認、ウェブ公開、といった一連の作業ができることが確認できました。すでに Kubernetes 環境を手元に持っているような人であればともかく、これから Kubernetes を使ってみようと思う人にとっては面倒な準備作業も不要で気軽に始められて、スケールやウェブ公開といった一通りの作業ができるところまで使える環境としてとても便利だと思いました。





このページのトップヘ