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

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

タグ:bluemix

IBM SecureGateway は、プライベート環境内のデータをクラウド環境から利用する際のトンネリングを行う上で簡単かつセキュアに環境を用意することができて、ハイブリッドクラウドを実現する上で非常に便利なサービスです(詳しくはこちらも参照ください):
2017041804


このトンネリング環境を作る方法として3つのクライアント環境が用意されています。この3つの環境を比較してみました:
2017041900


まず1つ目は「IBM インストーラー」と名付けられている、専用ソフトウェアです。ハイブリッド化の対象となるプライベートネットワークに接続された Windows/Mac/RHEL/Ubuntu(z, PPC, x86_64) に、各システム向けにビルドされた軽量な専用モジュールからインストールして利用します:
2017041801


2つ目は「Docker」です。ハイブリッド化の対象となるプライベートネットワーク内に Docker 環境があれば(または用意して)、専用の Docker イメージをダウンロードしてコンテナ上で稼働させます:
2017041802


そして3つ目が「IBM DataPower」と呼ばれる専用アプライアンスサーバーです。ハイブリッド化の対象となるプライベートネットワークに直接接続して電源を入れると稼働する、専用サーバーおよびハードウェアです:
2017041803


ちなみに DataPower サーバーの実体の外見はこんな感じです。「ザ・サーバー」って感じ:
ibm datapowers



Secure Gateway のクライアントとして利用する場合、いずれも機能そのものとしての違いはないのですが、選択する上で考慮する要素はいくつかあるので考えてみました。

まずは配布形態と、その形態による依存条件です。IBM インストーラーの場合はソフトウェアとしての配布なので、(仮想)マシンと OS があれば導入できます。Docker の場合は Docker 環境が必要です。プライベートネットワーク内に Docker 環境が用意されていればいいのですが、新たに構築可能かどうか、という点は問題になるかもしれません。そして DataPower は専用サーバーハードウェアなので、このハードウェア資産の購入とネットワークに新たに1サーバーを接続するという必要があります。

次に操作画面の違いです。IBM インストーラーと DataPower の場合はサービスとしてクライアントが実行され、その設定や操作は専用のウェブアプリケーションにアクセスして行うことになります。良く言えば詳しくなくてもウィザート通りにすすめていけるので便利、悪くいうとブラウザ環境必須(コマンドラインからは操作できないのでターミナルでリモートログインして・・というわけにはいかない)のです。Mac や Windows などの GUI 環境が用意されているマシンをネットワーク内で使える場合はいいですが、(現実的な)Linux でやろうとすると X Window まで用意された環境が必要になります:
2017041901


一方 Docker の場合は専用イメージを起動すると操作専用のコマンドラインが起動します。このコマンドラインから目的の操作を直接入力できるので、ターミナルを用いたリモート操作も可能です。Linux 環境前提で、ある程度コマンドライン操作に慣れた人が使うのであれば、こちらの方が便利かもしれません:
2017041902


まとめるとこんな感じですかね。トンネリング部分として同じ機能を提供するものなので、後は前提ネットワーク環境内のルールや操作する人のスキルを元にどれを選ぶかを判断することになると思います:
 IBM インストーラーDockerIBM DataPower
配布形態ソフトウェアDocker イメージアプライアンスサーバー
プライベート環境側に必要な事前準備このソフトウェアをインストール可能な Windows/Mac/RHEL/Ubuntu システムが同一ネットワーク内に存在している(或いは接続できる)こと同一ネットワーク内で Docker 環境が構築されていること特になし
クライアント起動形態サービスDocker コンテナ内で常に実行中サービス
クライアント操作画面GUI(ウェブブラウザ)専用のコマンドラインGUI(ウェブブラウザ)
メリットウィザード形式に沿って設定可能
既存環境の活用
コマンドラインから目的のコマンドを直接実行可能
新たにリソースを調達する場合のコスト
ウィザード形式に沿って設定可能
別途システムやハードウェア、ソフトウェアの準備準備不要
デメリット慣れてくると GUI が面倒
別途 OS が必要
Docker 環境必須
全てコマンドライン操作
(仮想環境なので)パフォーマンスの担保が難しい
専用アプライアンスサーバーの購入が必要


個人的な感想ですが、DataPower は「専用機を買う」という選択肢なので対象外。Docker 環境を用意できるなら Docker が一番楽で、用意できない場合は仮想サーバーの Linux に X Window と専用ソフトウェアをインストール、かな。


久しぶりに IBM BluemixNode-RED を使ったら、ちょっと挙動というか、使い始めるまでのステップが変わっていたことに気付きました。クラウド環境なので今後も UI 含め色々な変更があるかもしれませんが、このブログエントリを書いている2017年4月18日時点での「Bluemix 環境下での Node-RED の使い方」をまとめてみることにしました。

既に Bluemix や Node-RED を使っている方にとっては復習の部分も多く含まれていると思いますが、ユーザー名やパスワードの設定など比較的最近になって変わった部分もあるので参考にしてください。


まず PC のウェブブラウザ(FireFox, Chrome 推奨)で Bluemix 環境にログインします。アカウントをお持ちでない方は無料体験版のアカウントを申し込むなどしてアカウントをご用意の上でログインしてください。


では早速 Node-RED 環境を用意します。ログイン後のダッシュボード画面で「アプリの作成」をクリックします:
2017041801


Bluemix の Node-RED は「ボイラープレート」の「Node-RED Starter」として簡単に環境が用意できるテンプレートが用意されています。こちらを選択します:
2017041802


これから作成する Node-RED 環境の名称(URL の一部)を入力します。例えばここで test という名称を付けると、デフォルト状態では(カスタムドメインを使わなければ)Node-RED 環境のホスト名は test.mybluemix.net となります。URL の一部になる名称のため、簡単すぎる名前だと既に使われている可能性があり、その場合は利用できません(先に進めません)。例えば (自分の名前)-(日付) など、他と被らないような名称を指定してください(以下の例では dotnsf-nodered-20170418 という名称を指定しています。この場合のホスト名は dotnsf-nodered-20170418.mybluemix.net となります)。指定し終わったら最後に「作成」ボタンをクリックしてこの環境を作成します:
2017041803


(おまけ)
なお、上記画面をよく見ると分かるのですが、この Node-RED Starter ボイラープレートを使って Node-RED 環境を構築すると、Node.js ランタイム(アプリケーションサーバー)と Cloudant NoSQL データベースが1インスタンスずつ作成されます:
2017041804


Node.js ランタイムは Node-RED の実行前提環境として必要なサーバーなのですが、Cloudant の使いみちについて補足しておきます。通常の(Bluemix 環境ではない、オープンソース版の)Node-RED も Node.js サーバー上で動くウェブアプリケーションですが、そのままでは1つのサーバーインスタンス上で稼働する前提の挙動がいくつかあります。具体的にはフロー図の情報などはファイルシステムとして保存しています:
2017041801


そのため、例えばクラウド環境で使う場合のインスタンス数を2つや3つなどに増やした場合、最新の保存情報は複数あるインスタンスのどれかのファイルシステムに保存されている、ということが発生してしまい、インスタンスによって定義されているフローが異なる、という事態が発生してしまいます。そのため負荷が高くなったからといって単純にスケールアウトさせるわけにはいかなくなります:
2017041802



一方、Bluemix 環境ではこの辺りが拡張されており、フロー情報などは全て Cloudant のデータベース内に格納されます(これらのファイルを書き換えるイベントをフックして、ファイルではなくDBを書き換えるような拡張が加えられています)。全てのインスタンスは同データベースにバインドされており、インスタンスの増減があっても常に(論理的に)1つのデータベースに対してこれらの情報を読み書きするため、スケールメリットの大きなクラウド環境においても Node-RED が安心して利用できる環境となっています。ここも Bluemix で Node-RED を利用する上でのメリットだと思っています:
2017041803


(おまけおわり)


話を戻します。Node-RED ボイラープレートから「作成」ボタンを押すと一瞬画面が暗転して・・・
2017041804


しばらくするとこの環境(Node.js + Cloudant NoSQL の2つのサーバー)を作成中のステータスに変わります。しばらくお待ち下さい:
2017041805


しばらくするとステータスが「実行中」に変わります。この段階では Node-RED が利用できるようになっているので、横のホスト名部分をクリックして、Node-RED にアクセスします(ここまでは今までの Node-RED と同じです):
2017041806


最新の Bluemix の Node-RED はここからが少し変わりました。以前はここから早速フローエディタが使えるようになっていましたが、現在はもう1段階の簡易設定を行う画面に移行します。まずは Next をクリック:
2017041807


Node-RED のフローエディタにアクセスできる人を制限する設定画面が表示されます。上の "Secure your editor as only authenticated users can access it" にチェックを入れると、その下に指定するユーザー名/パスワードを入力できた人だけが編集できるようになります。なお、更にその下の "Allow anyone to view the editor, but not make any changes" にチェックすると、「誰でもフローエディタを見ることはできるが、変更はできない」というモードになります(下図ではチェックしていません):
20170418075


一方、下のように "Not recommended: Allow anyone to access the editor and make changes" にチェックを入れると(これまで同様に)URL を知っている誰もがフローエディタにアクセスし、変更できるようになります。このいずれかをチェックした上で "Next" をクリックします:
2017041808


後で詳しく説明しますが、標準の Node-RED には含まれていない拡張機能を後から追加することもできるようになっています。そのような拡張機能の代表的なものが紹介されています:
2017041809


例えば node-red-dashboard という箇所をクリックすると、ダッシュボード機能を追加する拡張モジュールの説明が表示され、内容を確認できます。このモジュールの追加方法については後述します:
20170418095


最後に設定内容の確認を行います。なお、ここで行った設定については実行環境の環境変数でも挙動を指定/変更することが可能です。最後に "Finish" をクリックします:
2017041810


すると一瞬このような画面になってから・・・
2017041811


改めて Bluemix 環境での Node-RED のスタート画面が表示されます。ここでは "Go to your Node-RED flow editor" ボタンをクリックしてフローエディタ画面に移動します:
2017041812


先程の画面でパスワードによる認証が設定されていると、ここでユーザー名とパスワードを入力する画面になります:
2017041813


設定時に自分で指定したユーザー名/パスワードを入力して「ログイン」します:
2017041814


正しい情報が入力されていると、Node-RED フローエディタ画面に移動します。これで Bluemix 環境下の Node-RED が利用できるようになりました:
2017041815



さて、比較的最近のアップデートで Node-RED 環境に GUI 操作でカスタムノードモジュールを追加できるようになりました(今まではソースコードの package.json を編集する必要があったので、それを意識せずに環境を構築できる Bluemix ではこの作業のためにソースコードを用意する必要があったりして不便に感じていました)。最後にその方法を紹介しながら、先程参照したダッシュボード機能のモジュールを追加してみます。Node-RED 画面右上のハンバーガーメニューから「処理ノードの追加削除」を選択します:
2017041801


すると画面左に「処理ノードの追加削除」というペインが現れ、ここで現在利用中のノードモジュールの一覧を参照したり、追加/削除といったカスタマイズが可能になります:
2017041802


ここで「処理ノードを追加」タブを選び、検索フィールドに dashboard と入力すると、検索結果一覧の中に "node-red-dashboard" が出て来るはずです(似た名前もあるので注意)。これを選んで「処理ノードを追加」ボタンをクリックします:
2017041807


ノードを追加インストールする確認メッセージが表示されます。ここでは "Install" を選択:
2017041803


しばらくするとノードが追加され、成功を示すメッセージが(一瞬)表示されます:
2017041804


この状態でノード一覧を下の方にスクロールすると、"dashboard" カテゴリの中にいくつもの node-red-dashboard ノードが追加されたことが確認できるはずです。またこの dashboard ノードが利用するための "dashboard" タブが右ペインにも追加されているはずです:
2017041806


動的なノード追加も簡単にできるようになっていることが確認できました!








 

以前に紹介した SaaS 型のデータ解析サービス IBM Watson Analytics は強力な解析エンジンが安価で使えて、面白いサービスだと思っています:
2017040501



ただちょっと不便に感じたのは、データのインポート方法でした。手元に CSV などのファイルがあれば Watson Analytics 側に用意された機能でインポートできます。またデータが Box や Twitter などのクラウドに公開されたものであれば、やはり Watson Analytics に用意された機能で取り込むことができました:
2017040502


しかし現実的にはデータベースサーバーから直接取り込むことができると便利です。更に言うと、インターネットに公開されたデータベースサーバーではなく、プライベートネットワーク内にあるデータベースのデータを簡単に取り込むことができると、プライベートデータを(いちいち CSV にしてから手動インポートする必要がなくなって)便利なのですが、現在 Watson Analytics 単体にそこまでの機能は提供されていません。


しかし、単体では提供されていなくても、IBM Bluemix から提供されるいくつかの機能を組み合わせることで上記の要件は可能になります。具体的には Secure Gateway サービスと Data Connect サービスを使います。Secure Gateway でプライベートネットワークのデータベースに対してセキュアなトンネリングを貼った上で Data Connect を使い、そのプライベートデータベースと Watson Analytics との間での自動データマイグレーションが実現できます(そのマイグレーションを定期的に実行するようなスケジューリングまで含めて可能になります)。






以下に実際の手順を紹介しますが、実際にこの手順を行うにはプライベートネットワーク内のデータベースに加えて、IBM Bluemix および IBM Watson Analytics 両方のアカウントが必要です。そして IBM Bluemix では Secure Gateway と Data Connect の2つのサービスインスタンスが有効になっている必要があります。無料版にサインアップするなどして、あらかじめご用意ください。


まずプライベートネットワーク内のデータを確認しておきます。今回対象とするのはプライベートネットワーク内のデータベースサーバーで管理されている(仮想の)人事情報とします。名前(name)や年齢(age)、収入レベル(income)、容姿(looking)、血液型(blood_type)、出身地(prefecture)といった情報が格納されているものです(注 乱数で生成した偽データです)。これは認証は当然ですが、現時点ではプライベートネットワーク内からのアクセスしか許可していないものです。目的はこれらのデータを(一度 CSV ファイルにして取り出して手動アップロードしたりするのではなく)Watson Analytics で解析可能なデータとしてシステマチックにインポートすることとします:
2017040513


では実際の手順を紹介します。まずは Secure Gateway でこのプライベートネットワーク内のデータベースを IBM Bluemix 環境からアクセスできるようにします。その手順はこちらを参照してください。
SecureGateway で Bluemix とプライベートネットワークをセキュアに接続する


次に Secure Gateway で参照できるようになったプライベートデータを Data Connect のデータセットとして定義します。この手順についてはこちらを参照してください。
Data Connect サービスでデータベースをマイグレーションする


ここまで完了したら、次は Data Connect の接続先として利用できるよう、Watson Analytics を追加します。Data Connect サービスのダッシュボード画面左メニューから "Connections" を選択し、画面右上の "Create New" をクリックします:
2017040501


接続先のデータベースタイプの選択画面では "IBM Watson Analytics" を選択します:
2017040502


詳細設定画面に移動しますが、ここで設定する項目は接続名称を入力するだけです。最後に画面右上の "Create Connection" をクリックします:
2017040503


この接続情報が保存される際に IBM Watson Analytics への認証が行われます。IBM Watson Analytics を利用している IBM ID とパスワードを指定してログインしてください:
2017040504


正しく有効な ID が確認されると、Data Connect の接続情報として IBM Watson Analytics が追加されます:
2017040505


では作成した Watson Analytics にプライベートデータベースからデータをマイグレーションします。引き続き Data Connect ダッシュボードの画面左メニューから "Activities" を選び、右上の "Create New" をクリックします:
2017040506


まずマイグレーション元を指定します。あらかじめ作成してある Secure Gateway 経由の(プライベートデータベースの)データセットを選択します。選択したら画面右上の "Copy to Target" をクリックします:
2017040507


次にマイグレーション先を指定します。今回のマイグレーション先は IBM Watson Analytics なので、Connections から上記で定義した IBM Watson Analytics の接続名を選択します。このままマイグレーション実行スケジュールの指定("Schedule Activity")も可能ですが、まず1回手動で実行してみることにします。画面右上の並んだボタンから "Run" をクリックします:
2017040508


指定したとおりの(プライベートデータベースから Watson Analytics への)マイグレーション処理が実行され、アクティビティとして記録されます。なお、このアイコンから実行スケジュール(定期実行など)を編集することも可能です:
2017040509


実際にマイグレーションが行われたかどうかを確認してみます。改めて IBM Watson Analytics にログインすると、元々は存在していなかったデータセットが作られているはずです。これをクリックして、実際に解析してみます:
2017040510


解析テンプレートが表示されます。いくつかありますが、"What is the trend of looking over age by blood_type?"(血液型別に年齢と容姿にどういったトレンドがあるか?)が面白そう(笑)なので選択してみます:
2017040511


この解析用の画面に移動します。画面左側に年齢ごとの容姿の推移が血液型ごとの折れ線になって表示されます。また画面右にはこれらの分析からの発見として、「43歳の収入が一番高い」とか「年収をトータルすると AB 型が一番低い」といったインサイトも併せて表示されています(※繰り返しますが、乱数を使って生成した偽データです):
2017040503


特別何もしなくてもデータを与えるだけでここまで分析してくれる Watson Analytics もすごいのですが、その Watson Analytics に直接プライベートデータや社内データをセキュアにマイグレートしてくれる Secure Gateway や Data Connect と併せて利用することで、より便利に大事な情報を簡単に解析できるようになると感じます。


IBM Bluemix が提供するデータサービスの1つに "Data Connect" があります:
2017040401


このサービスは DB2, Oracle, dashDB, MySQL, cloudant, ・・・など、異なるデータベースサーバー間でのデータマイグレーションを実現するものです。マイグレーション元とマイグレーション先を定義し、相互システム間の型変換などを考慮してデータを扱い、(必要であれば)マイグレーションの実行スケジュールを指定することでデータのマイグレーション処理をその場で行ったり自動化したりする、というサービスです。更に必要に応じて Secure Gateway サービスを併用することで、クラウド上に公開されたデータベースだけでなく、オンプレミスデータベースを対象にすることも可能です。


今回は Data Connect の紹介例として、社内システムで運用中の MySQL データベースが存在していると仮定し、このデータベースの一部の内容(people テーブルの内容)を統計処理するために、クラウド上の dashDB に週に一度追加マイグレーションしたい、という要望があるものとして、この要望を実現するための設定を紹介します:
2017040402


こういった処理は JDBC などを使ってプログラミングすることも可能ですが、作成したアプリケーションを自動的に定期実行したり、同様のアプリケーションを作る際の流用性が少なかったりします。 そのような要望を一元的に管理・実現するためのサービスが Data Connect です:
2017040403


例えば上記のようなケースであれば、
(1) (マイグレーション元とマイグレーション先の2つの)データベースへの接続を定義し、
(2) データセット(マイグレーション元)を定義し、
(3) セータセットとマイグレーション先の2つの結びつきを定義し、
(4) マイグレーションの実行タイミングを定義して実行
することになります。 以下ではそれぞれの手順を実際の画面を使って紹介します。


まず IBM Bluemix で Data Connect サービスインスタンスを作成し、そのサービスインスタンスの画面を開くと、このように表示されます。画面内の "LAUNCH" ボタンをクリックすることで Data Connect サービスのダッシュボード画面に移動します:
2017040408


Data Connect のダッシュボード画面です。左上の "Data Connect" という箇所をクリックすると、いつでもこの画面に戻ってこれます:
2017040401


まずは上記 (1) の(マイグレーション元とマイグレーション先の)2つのデータベースへの接続方法を定義します。左メニューで "Connections" を選択します。現在は何も定義されていないので、画面には何も表示されないはずです。では画面右上の "Create Now" をクリックします:
2017040402


接続データベースの種類を選択する画面です。今回のケースではまずマイグレーション元となる MySQL の定義をするため、"MySQL" を選択します:
2017040403


次に MySQL の詳細情報を入力します。接続名、説明(オプション)、ホスト名、ポート番号、データベース名、Secure Gateway の利用有無、そしてユーザー名/パスワードを入力し、最後に右上の "Create Connection" をクリックします:
2017040404


(おまけ)
なお、もし対象とするデータベースサーバーがプライベートネットワーク環境内にある等、インターネットから直接参照できないような場合は、Bluemix の Secure Gateway サービスを併用します。Secure Gateway サービスがプライベートネットワーク環境とのセキュアなトンネリングを実現し、このトンネルを経由してプライベートネットワーク環境のデータベースを対象とすることができるようになります。なお Bluemix の Secure Gateway の利用手順については別途紹介したエントリがあるのでこちらを参照ください:
2017040503


Secure Gateway サービスを利用する場合の Connection 定義は以下のようにして行います。"Use a secure gateway" にチェックを入れ、設定済みの Secure Gateway 接続名を選択します。その上でデータベースサーバーのホスト名(IPアドレス)やポート番号は、プライベートネットワーク内でのものを指定します:
2017040504


なお、この Secure Gateway を使ってプライベートネットワーク内のデータベースに接続する場合ですが、データベース側はゲートウェイクライアント(または同一ネットワーク)から指定したユーザー名とパスワードで外部接続できるような設定をあらかじめ行っておく必要がある点に注意してください。例えばあるユーザーに同一ネットワーク(192.168.0.*)からの参照アクセスを許可する場合であれば以下のような MySQL コマンドを実行することになります:
> grant select on (データベース名).* to (ユーザー名)@"192.168.0.%" identified by '(パスワード)';

このコマンドの後でないと(外部からの接続ができないため)上記の接続定義が作成できないはずです。設定変更後に再度接続定義を行ってください。
(おまけ終わり)


接続定義の作成に成功すると1つ前の画面に戻り、いま作成した MySQL データベースへの接続情報アイコンが追加されていることが確認できるはずです。では続けてもう1つの(マイグレーション先の)接続情報を定義するため再度 "Create New" をクリックします:
2017040405


再び接続先データベースの種類を選択する画面です。今回は IBM dashDB に接続するので、"IBM dashDB" を選択します:
2017040406


データベースの種類によって入力する詳細項目が異なります。接続先が IBM dashDB の場合は接続名、説明(オプション)、ホスト名、データベース名、Secure Gateway の利用有無、そしてユーザー名/パスワードを入力し、最後に "Create Connection" をクリックします:
2017040407


先程の画面に戻り、今度は dashDB の接続情報アイコンが追加されたことが確認できるはずです。今回はこの2つの接続情報だけで充分ですが、マイグレーションで対象とする接続先の数だけこの作業を繰り返します(または後から追加します):
2017040408


次に (2) のマイグレーション元となるデータセットを定義します。今回は MySQL データベース内の people というテーブルの情報を dashDB にマイグレーションすることが目的なので、データセットは MySQL 内の people テーブルということになります。

このテーブルをデータセットとして定義するため、Data Connect ダッシュボードの左メニューから "Data Sets" を選択します。ここでも定義済みのデータセットがまだ存在していないので何も表示されません。では画面右上の "New Data Set" をクリックします:
2017040401


定義済みの接続情報名が(下画面では2つ)表示されます。今回は MySQL データベース内のデータを取り出したいので、MySQL の接続情報名を選択します:
2017040402


次にこのデータベース接続で対象とするデータベース名を指定します。今回は1つしか定義していないので、ただ1つ表示されるデータベースを選択しますが、複数ある場合は対象のものを選択します:
2017040403


次に対象となるテーブルやビューを選択します。今回は people テーブルを対象としたいので、"people" を選択します:
2017040404


必要であれば、このテーブルから取り出す列をカスタマイズします。全ての列を取り出す場合はデフォルトのまま全てにチェックを入れてください。最後に画面右上の "Publish Data Set" をクリック:
2017040405


すると1つ前の画面に戻り、データセット一覧に今作成した people テーブルが追加されたことが確認できます。これで (2) の作業も完了しました:
2017040406


続いて (3) データの結びつきと (4) マイグレーションスケジュールを定義します。今回の例では MySQL データベースの people データセットを dashDB データベースにマイグレーションしたいので、この関係を定義します。

改めてダッシュボード画面の左メニューから "Activities" を選択します。ここに定義済みのアクティビティ一覧が表示されますが、この時点ではまだ何も表示されていません。画面右上の "Create New" で新たに1つ追加します:
2017040401


アクティビティではまずマイグレーション元を指定します。今回は最初に作成した people データセットをマイグレーション元とするので、"Data Sets" を選択します:
2017040402


Data Sets 一覧から people を選択(1つしかないけど)します。全ての列にチェックが入っていることを確認して、次にマイグレーション先を指定するため画面右上の "Copy to Target" をクリックします:
2017040403


マイグレーション先は dashDB のデータベースなので、"Connections" の dashDB の接続情報名を選択し、マイグレーション先となるデータベーススキーマを指定します:
2017040404


people テーブルをマイグレーションするのですが、このデータベースが指定したスキーマに存在していない場合はどのようにマイグレーションするかを選択します。下図では "Recreate the table"(テーブルごと作り直してマイグレーションする)を選択しています。これで定義自体は完了で、必要に応じてこのアクティビティ定義に名前を指定することもできます(画面左上から編集できます)。 そしてこの定義を保存(Save)するか、そのまま実行(Run)することもできますが、今回は更に実行スケジュールを指定します。画面右上の "Schedule Activity" をクリックします:
2017040405


カレンダーが表示されます。このマイグレーションアクティビティを実行する日付を指定します:
2017040406


次に実行時刻(指定日の何時に実行するのか)を指定します。1回だけ実行するのであればこのまま "APPLY" をクリックしてもいいのですが、定期的に繰り返して実行する場合は "Schedule this activity to repeat" を選択します:
2017040407


引き続いて繰り返しの条件を指定します。下図の例では毎日(Daily & Every 1 day)実行して、終了日を指定せず(Never)に定義しています。繰り返し条件が確定したら "APPLY" をクリックします:
2017040408


指定した実行スケジュール(の直近のもの)が画面右側に表示されます。内容を確認して画面右上の "Done" をクリックします:
2017040401


1つ前の画面に戻り、いま定義したアクティビティが追加されたことが確認できます。このアクティビティの内容を確認したり、内容を変更する場合はこのアクティビティを選択します:
2017040402


この画面からアクティビティそのものを編集したり、スケジュールを変更したり、或いはスケジュールに関係なく一度実行したりすることができます:
2017040403


このアクティビティが実行されると、元の(MySQL の)データが dashDB へマイグレーションされます。ちなみにこちらが両者のテーブル内をプレビューした様子です(前者が MySQL 、後者が dashDB):
2017040400
  ↑MySQL


2017040401
  ↑dashDB


マイグレーションの定義とスケジューリングができ、正しく動いていることが確認できました。今回のケースであれば、いわゆるトランザクション用途で使っていた MySQL のデータを、統計処理目的で dashDB に移したかったわけですが、それが簡単に実現できたことになります。

このような異なるデータベース間のデータマイグレーションは、まあパターンが1つ程度であればプログラミングで可能になるかもしれませんが、何種類ものデータベースを対象としたり、順序などが複雑に絡み合っていたり、その実行スケジュールを考慮したりすると、システマチックに済ませたくなります。そんなケースで手軽にマイグレーションが行える Data Connect はかなり便利だと感じました。


IBM Bluemix が提供するサービスの1つである Secure Gateway を紹介します:
2017040501


IBM も提唱する「ハイブリッド・クラウド」環境では、パブリックなクラウドだけでなく、一部のデータベースがセキュアなプライベート環境やオンプレミス環境上に存在したままでシステムシステムを実現する必要があります。ではどのような仕組みでパブリッククラウドとセキュアなデータベース接続を実現することができるでしょうか?
2017040501


一般的には VPN などの仕組みを使うことも考えられますが、そのためのサーバー機器やソフトウェア、およびそれらの仕組みをプライベートネットワーク側にも用意する必要があり、運用・管理も含めた負担は軽いものではありません。 今回紹介する Secure Gateway はプライベートネットワークの Docker イメージとしてトンネリングクライアントを用意し、Bluemix 側のトンネリングサーバー(ゲートウェイ)との間で通信して、目的のプライベートデータベースとの接続をシームレスに実現する、というものです:
2017040501


この Secure Gateway を利用する場合、その環境構築は非常に簡単です。ゲートウェイサーバー側は SaaS のサービスをインスタンス化するだけ、クライアント側はソフトウェアを導入してゲートウェイサーバーと接続するコマンドを実行するだけですが、導入方法の1つとして専用の Docker イメージが用意されているので、そのコンテナを Docker から起動するだけで済みます。管理・運用の負担が非常に小さくなります。


また Secure Gateway には利用量に応じたいくつかのプランがあります。無料版である Essentials プランでは1つのゲートウェイにつき接続先は1つ(例えば1つのデータベース)だけですが、1ヶ月間に 500MB のトンネリング通信を行うことができます。Bluemix の画面からプランを選択して「作成」ボタンをクリックすると、このサービスが利用可能になります(この時点ではまだインスタンス化していません):
2017040502


この(サービスを作成した直後の)時点で Bluemix の Secure Gateway サービス画面を見ると以下のようになります。ダッシュボードから利用状況が確認できますが、まだゲートウェイインスタンス(上記図の Secure Gateway サーバー)が生成されていないので通信は行われていません。ゲートウェイサーバーを作成するには、画面左下の「ゲートウェイの作成」をクリックします:
2017040503


ゲートウェイの追加画面が表示されます。ここではゲートウェイの(つまりは接続先の)名称を指定します。必要に応じてセキュリティ・トークンの設定を行い(下図では設定していません)、最後に「ゲートウェイの追加」をクリックします:
2017040504


これでゲートウェイサーバーインスタンスが生成されました。が、まだゲートウェイクライアントが作られていないので、未接続状態です(画面右上のチェーンが赤)。そこで続いて「クライアントの接続」をクリックします:
2017040505


ゲートウェイクライアントを導入するにはプライベートネットワーク内に専用のソフトウェアをインストールする他にも、専用の Docker イメージを使う方法や IBM DataPower アプライアンスサーバーを使う方法があります。今回はゲートウェイクライアントを Docker イメージから作るものとします(プライベートネットワーク内に Docker が導入されたマシンが存在するものとして、以降「Docker ホストマシン」と表現します)。そして接続方法に "Docker" を選択します。すると、Docker ホストマシン上で実行するべきコマンドが表示されます。ここに書かれている "docker run -it" で始まるコマンドを、プライベートネットワーク内の Docker ホストマシンで実行します:
2017040506


多くの場合、ここで作成する Docker イメージを起動したまま Docker ホストマシンのコマンドを抜けることになると思うので、Docker ホストマシンでコマンドを実行する前に一度 screen などでターミナルを多重化しておくのがいいと思います:
$ screen

その上で上記コマンドを実行するとこのような画面になり、最後にプロンプトが表示されます。Secure Gateway クライアントが起動した状態で Docker イメージが起動し、コマンド待ち状態になっています:
$ docker run -it ibmcom/secure-gateway-client XXXXXXXX_prod_ng
IBM Bluemix Secure Gateway Client Version 1.7.0
************************************************************************************************
You  are running the  IBM Secure  Gateway Client for Bluemix. When you enter the provided docker
command the IBM Secure Gateway Client  for Bluemix automatically downloads as a Docker image and
is executed on your system/device. This is released under an IBM license. The  license agreement
for IBM  Secure Gateway Client for Bluemix is available at the following location:

http://www.ibm.com/software/sla/sladb.nsf/lilookup/986C7686F22D4D3585257E13004EA6CB?OpenDocument

Your use of the components of the package and  dependencies constitutes your acceptance  of this
license agreement. If you do  not want to accept the license, immediately quit  the container by
closing the  terminal  window or by  entering 'quit' followed by the ENTER key. Then, delete any
pulled Docker image from your device.

For client documentation, please view the ReadMe located at:
.rpm and .deb installers: /opt/ibm/securegateway/docs/
.dmg installer:           <installation location>/ibm/securegateway/docs/
.exe installer:           <installation location>\Secure Gateway Client\ibm\securegateway\docs\
************************************************************************************************


<press enter for the command line>
[2017-04-04 11:20:59.269] [INFO] (Client ID 1) No password provided. The UI will not require a password for access
[2017-04-04 11:20:59.278] [WARN] (Client ID 1) UI Server started. The UI is not currently password protected
[2017-04-04 11:20:59.279] [INFO] (Client ID 1) Visit localhost:9003/dashboard to view the UI.
[2017-04-04 11:20:59.521] [INFO] (Client ID 15) Setting log level to INFO
[2017-04-04 11:21:01.562] [INFO] (Client ID 15) The Secure Gateway tunnel is connected
[2017-04-04 11:21:01.752] [INFO] (Client ID XXXXXXXX_eoF) Your Client ID is XXXXXXXX_eoF
XXXXXXXX_eoF>

(追記)
ダッシュボード画面に表示されている Docker コマンドは上記(docker run -it ****)なのですが、実際にはネットワークモードをデフォルトのブリッジではなくホストモードで起動しないとエラーが発生する、という症状が出ることもあるので、その場合はホストモード(docker run --net=host -it ****)での起動を試みてください。自分はホストモードで起動しています。
(追記終わり)


このクライアントのワーカー ID (Essentials プランの場合は大抵1だと思いますが)を後で使うので確認しておきます。このプロンプトにおいて "L" という List の短縮コマンドを実行して、Worker ID を確認します:
XXXXXXXX_eoF> L
----------------------------------------
-- Current Secure Gateway Client Connections --

 Worker ID   Client ID     Description
      1     XXXXXXXX_eoF          木村家GW
----------------------------------------
XXXXXXXX_eoF>

もしもここでワーカー ID が確認できなかった場合は、何らかの原因でゲートウェイサーバーとの接続がうまく行ってないことになります。その場合は手動でゲートウェイ ID を指定して接続する必要があります。ゲートウェイ ID を確認するには Secure Gateway ダッシュボードで接続名(下図の場合は「木村家GW」)の右にある歯車マークをクリックします:
2017040502


すると以下のような画面が表示され、ゲートウェイ ID が表示されるので、この値をコピーしておきます:
2017040508


改めてゲートウェイクライアントのプロンプトで、以下のように指定してゲートウェイサーバーと接続します:
XXXXXXXX_eoF> c (ゲートウェイID)

その後、上記の L コマンドで接続を再確認してください。


ではここで確認したワーカー ID を使って、接続を許可するリソースを指定します。例えばプライベートネットワーク内のデータベースサーバーの IP アドレスが 192.168.0.101 で、データベースシステムが MySQL (ポート番号 3306)だった場合、以下のコマンドを実行して、Secure Gateway による接続を許可します:
XXXXXXXX_eoF> A 192.168.0.101:3306 1

  ↑最後の1はワーカーID


なお、上記で触れたようにゲートウェイクライアントで screen を実行してから Docker イメージを起動していた場合、キーボード操作で Ctrl + A, D (Ctrl を押しながら A 、続いて Ctrl を離して D)を実行すると Docker イメージを起動したまま screen を抜ける(デタッチする)ことができます:
XXXXXXXX_eoF> (Ctrl + A, D を実行)
$ 

こうしてデタッチした screen に再び接続(アタッチ)するには screen -r コマンドを実行します:
$ screen -r

XXXXXXXX_eoF>


これだけで Bluemix のランタイム(アプリケーションサーバー)などから、Secure Gateway を経由してプライベートネットワークのデータベース等に接続することができるようになります。 実際に接続する場合にランタイム側からどのようなサーバーとポートに対して接続すればよいのかを確認します。


先程の Secure Gateway のダッシュボード画面の、作成したゲートウェイの画面において、「宛先」タブを選び、上記で定義済みの宛先の設定ボタン(右下の歯車アイコン)を選択します:
2017040701


すると以下のような画面になります。ここで「リソース・ホスト:ポート」にはオンプレミス上の接続先リソースの情報が表示されますが、「クラウド・ホスト・ポート」に表示されているホスト名とポート番号の組み合わせをコピーしてください。そして実際のアプリケーションランタイムからは、このホスト名とポート番号に対して接続することでハイブリッドなクラウド環境が実現できます:
2017040702




このページのトップヘ