皆さんこんにちは。 インフラ開発部の田中と申します。

10月12、13日に開催された、「Yahoo! JAPAN Hardening 2017」という演習型のサイバーセキュリティイベントに参加いたしました。今回はこちらのイベントを、参加者の視点を交えながら皆さんにご紹介いたします。

Hardeningとは

「Hardening」とは、インシデントへの対応力を磨くことを目的としたサイバーセキュリティイベントです。Web Application Security Forumというコミュニティが主催する「Hardening Project」というイベントを筆頭に、近年注目が集まっています。

「Yahoo! JAPAN Hardening」は、ヤフー社内で行われるHardeningのイベントです。第2回目の本イベントでは、当社を含むグループ会社の従業員もイベント参加者の対象となりました。

本イベントでは、参加者はチームに分かれ演習中の約7時間、架空のECサイトを運営し売り上げ高を競いました。演習に用いるECサイトの環境には多数の脆弱性が含まれており、演習中は運営スタッフからさまざまな攻撃が試みられました。 それに対して各チームは、脆弱性対応や復旧作業のみならず、お客様への問い合わせ対応や広報活動までの一連のフローを実施することで、売り上げ高への悪影響を抑えます。技術だけではなく、人対人のコミュニケーションまで含めた包括的な対応能力が問われることがポイントです。

また本イベントは当社も協賛しており、演習環境は当社サービスのIDCFクラウド上に構築されていました。

演習時間中の流れ

インシデント発生前の事前対策

IDCフロンティアからは私のほかに、ビジネス開発部の金杉と永岡、広報グループの山下が参加し、ヤフー社のシステム統括本部とCS本部との合同チーム「Benkei」として演習に取り組みました。

私はBenkeiの技術担当の1人として、序盤はrootパスワードの変更やssh接続における公開鍵認証の設定など、基本的かつ優先度の高い作業に取り組みます。またSYN flood攻撃に対するSYN cookiesの有効化や、Smurf攻撃に対するブロードキャスト無視のパラメータ有効化など、対処法が確立している攻撃については、事前に作成したスクリプトを流すことでセキュア化を進めていきます。

こうした脆弱性対応の作業中も、監視サーバを通してシステムの状態をチェックしECサイトの環境に異変が起きていないことを確認します。演習開始から数十分の間は特に何事も起こらず、売り上げ高の伸びも順調です。

「事前に想定していたよりも余裕があるのかな」と考えられていたのも、最初のインシデントが発生するまででした。

怒涛のサイバー攻撃とインシデント対応

商品画像の改ざん、価格の不正操作、ECサイトのダウン……。

怒涛の勢いで押し寄せてくるインシデントを前に、チームに緊張が走ります。中盤以降はこうしたインシデントに対して暫定対処、侵入経路の特定、原因究明など、ECサイトを守るために必要な作業へと食らいついていきます。 例えば価格の不正操作へのインシデント対応であれば、管理ページから手動で価格を元に戻す操作が暫定対処、アプリケーションサーバのアクセスログ分析が侵入経路の特定、ECサイトの管理システムにおけるSQLインジェクション脆弱性の特定が原因究明にあたります。

技術担当としては、つい目の前の作業に没頭してしまいがちになりますが、これらの作業中でもサイバー攻撃は待ってはくれません。ごく単純な暫定対処でもしばらくの間しのげそうであれば、一旦そのインシデントへの対応に区切りを入れ、新たなインシデントへの対応に切り替える必要もあります。

思わぬ伏兵の出現とチーム内コミュニケーション

インシデントはサイバー攻撃だけに留まりません。

「当社ではお客様の同意なく個人情報を提供する場合がございます。ご了承ください。」

企業ページに設定されていた不適切なプライバシーポリシーに、お客様役の運営スタッフから問い合わせによる突っ込みが入ります。慌てて修正してしまいそうになりますが、黙って行えばインシデントの発生を隠蔽したと取られかねません。お詫びの文言をお客様に対して、どのように、どのタイミングで周知するのか？技術担当もコンソール上で完結する作業だけではなく、チーム内での密なコミュニケーションが必要とされるのです。

終盤付近になると、Benkeiを含む多くのチームでサイバー攻撃によるECサイトへの影響が表面化していきます。そうしたなかで、記者役の運営スタッフからの取材対応に関する相談で、思わず言葉に詰まる場面がありました。　　

「『SQLインジェクション』を記者に説明するにはどうすれば良いか？」　　

SQLインジェクションはWebアプリケーションに対する典型的な攻撃手法であり、私もその概要については理解していたつもりでした。しかし、伝える相手は非専門家の記者です。 説明に際してSQL文という語彙は使えません。かといって、限られた時間で言葉の定義を長々しく伝えることもできません。正確に、簡潔に、平易な言葉で内容が説明できて初めてそのサイバー攻撃の手法を理解していることになるのだと痛感させられた局面でした。

終了後の振り返り

終了後は緊張感も解け、談笑を交えつつチーム内でも簡単な振り返りが行われます。事前に対策できた脆弱性もあれば、最後まで尾を引いてしまうインシデントもありました。 Benkeiチームでは、ポイントが商品価格より高額な値で付与されるという改ざんへの原因究明が遅れ、売り上げ高が低下し続ける状態に陥ってしまっていました。

もう少し時間があれば、アクセスログのあの部分に着目して、WordPressのあのプラグインを調べて……と後になって思いつくこともあります。約7時間もの間、昼食の離席時間も惜しいほどに集中して取り組んでさえ、もう少しやりたかったと自然に思えてしまうほどに夢中になれる演習でした。

演習での学び

本年度に新卒で入社した、まだまだエンジニアとして未熟な私にとって、本演習は多くのことが学べる貴重な機会になりました。演習の主目的であるセキュリティ・インシデント対応への実践力はもちろんのこと、個人的には「プレッシャー下での対応作業の難しさ」という点が強く印象に残りました。例えば、前述のssh接続における公開鍵認証の設定ですが、正しく設定できているはずなのになぜか接続できないというトラブルがありました。速やかに作業を完了させなければならない局面で、何度もやったことのある作業なのにうまくいかない……一瞬、頭が真っ白になってしまいます。最終的にはチームメイトの助けもありトラブルの原因はアクセス権の問題であることが判明しましたが、当初想定していた完了時間を超過してしまっていました。

プレッシャーの影響は作業時間の超過だけに留まりません。
実は演習中、誤操作で必要なプロセスをキルしてしまい、当該サーバに一切ssh接続ができなくなるというインシデントも起こしてしまっていました。ssh接続が切断されてから、会場の専用端末でサーバを再起動するまでの間は、1秒でも早く再起動が完了しますようにと冷汗三斗の思いでした。

私はこれまでセキュリティ・イベントに参加した経験はなかったため、必要以上に緊張してしまった側面もあるかもしれません。しかし、演習にも関わらずここまで心理的な影響が出るならば、本当のインシデント対応であれば推して知るべしです。焦ってしまう場面だからこそ、チーム内で密なコミュニケーションを行い、必要に応じて確認作業を実施しなければならない、という事を、実感を伴う形で学ぶことができました。

最後に

本記事では、インシデントへの包括的な対応力が試されるセキュリティ・イベント「Yahoo! JAPAN Hardening 2017」について、その概要を感想も交えつつご紹介いたしました。もし本記事をご覧になって、本イベントの雰囲気について理解の一助となりましたら幸いです。
ご興味がありましたら、ぜひ参加してみてください。

こんにちは。この IDCF テックブログには２度目の寄稿となる木村です。
今回はオープンソースのブロックチェーン環境である Hyperledger Fabricを紹介し、特に IDCF クラウドを使ってその環境構築を行うための手順を紹介します。

自己紹介

某外資系クラウド会社で、クラウドや人工知能、DevOps といった比較的新しい技術を使ってお客様アプリケーションのプロトタイプ開発を行ったり、その技術紹介を行ったりしています。会社の方針でもあるのですが、最近はブロックチェーンを使った案件にも多く関わっており、多くの会社が業種内でのトップランナーとなるべく興味を持っていることを実感しています。

Hyperledger Fabric v1.0 について

ビットコインに代表されるブロックチェーン技術に注目が集まる中、 「企業利用に適した分散台帳フレームワーク」を目的としたオープンソースブロックチェーン環境開発プロジェクトがスタートしました。それが Hyperledgerプロジェクトです。Hyperledger プロジェクトではフレームワークの開発と同時に、オープンソースのテクニカルコミュニティを作り、ソリューションプロバイダーやユーザーエコシステムへの便益提供を目的としています。

この Hyperledger プロジェクトの中で行われたハッカソンを通じ、いくつかのインキュベーションプロジェクトが生まれています。その中の１つがブロックチェーンプラットフォームやその SDK/API を含めて提供する Hyperleger Fabricでした。IBM は Hyperledger Fabric が生まれた当初からコードを提供し、発展に貢献してきました。そのベータ版は IBM Bluemix（現 IBM Cloud）を通じて世の中に提供されていましたが、2017年7月に正式バージョンである Hyperledger Fabric v1.0 がリリースされました。

Hyperledger Fabric はオープンソース製品として公開されていると同時に、テクニカルコミュニティ向けにも多くの情報が提供されています。今回は「サポートツール」と呼ばれる、Docker を使って開発者向けに比較的簡単な方法で Hyperledger Fabric v1.0 環境を構築するキットを紹介し、IDCF クラウドの仮想マシン内で同環境を構築する手順を紹介します。

なお Hyperledger Fabric の公式ドキュメントはこちらです：
https://hyperledger-fabric.readthedocs.io/en/release/

作成する環境のシステム図

今回は「サポートツール」を使って Hyperledger Fabric 環境を構築します。このサポートツールは Docker および Docker-Compose が導入されていることを前提として稼働し、Hyperledger Fabric の構成や開発、動作検証に最小限必要な環境を作ります。具体的には今回紹介する手順で次のようなネットワーク構成を（1台の Docker サーバー内に）作ります：

• CA: 認証局ノード

• Orderer: ブロック追加の順序を管理するノード

• Peer: ブロックを持つノード（実際には複数ピアで運用することになるが、サポートツールでは１つだけ作る）

• DB: ステートデータベース

図1　システム図

仮想マシン作成

まずは Hyperledger Fabric 環境を導入するためのサーバーを用意します。今回は IDCF クラウドの仮想マシンを利用しました。

IDCF クラウドのコンソールにログインし、仮想マシンを１台作成します。今回はマシンタイプに（自分が普段使っている環境に近いという理由で） standard.S8 を使用しましたが、環境構築の手順を確認するだけであればもっと小さくても（light.S2 クラスでも）できると思います。

Hyperledger Fabric 自体は後述する Docker および Docker-Composer 上で動きますが、今回利用するサポートツールは macOS および Ubuntu 用に用意されています。今回はサーバーを作成する際に OS としては Ubuntu Server 16.04を選択したものとして、次の説明を続けます。

ネットワーク設定とSSHログイン

仮想マシンが起動したらまずはネットワークの構成を行います。

ファイアウォール

開発用途限定などで、ブロックチェーンを外部からアクセスさせない場合はファイアウォールの設定は必ずしも必要ではありませんが、外部からアクセスさせる場合は IP アドレスのファイアウォールの設定が必要です。具体的には（今回のサポートツールで作る構成の場合は）GRPC と呼ばれるプロトコルが使う次のポートを公開する必要があります：

図2　ファイアウォールの設定

必要に応じて、次の環境設定をする時のために SSH を使う場合は SSH のポート（デフォルトは22）も開けておきます。IDCF クラウドの場合は Web コンソールから仮想マシンのコンソールに直接アクセスすることもできるので、その機能を使って構成する場合は必須ではありません。

ポートフォワード

ファイアウォールで開けたポートを仮想マシンにフォワードするための設定を追加します：

図3　ポートフォワードの設定

なお SSH のポートを開けた場合は、SSH のポートについてもフォワード設定を追加します。

SSH でログイン

SSH か、または IDCF クラウドの場合であれば Web コンソールから仮想マシンのコンソールに直接アクセスする機能があるので、いずれかを使ってターミナル画面にアクセスし、次の準備作業および設定作業を行います。

図4　SSH でログイン

なお、後者の（Web コンソールから仮想マシンのコンソールに直接アクセス）方法については以前にテックブログを書かせていただいた際に紹介しているので、その方法はこの記事内を参照ください：

Secure Gateway を使って、マルチクラウドの環境間でのセキュアなデータ通信を実現する

Hyperledger Fablic導入準備

メモリがキツい可能性あり。スワップを増やす場合はこちら：

今回は Docker を使って、１台の（仮想）マシン内にブロックチェーン環境を構築します。したがって Docker 環境となるホストのメモリは多めに用意しておくべきです。

IDCF クラウドで仮想マシンのスワップメモリを増やす（というか有効にする）方法についてはこちらを参照してください。場合によってはこの方法で仮想的にメモリを増やしておいてください：

http://dotnsf.blog.jp/archives/1019097767.html

とりあえず環境をアップデート

ターミナル画面を開いたら、まずは次のコマンドでライブラリなどの環境をアップデートしておきます：

$ sudo apt-get update -y
$ sudo apt-get upgrade -y

前提条件

Hyperledger Fabric を導入するために必要となる前提条件がこちらです：

• Docker
• Docker-Compose
• Node.js V6.x

Ubuntu 16.04 の場合は次に紹介する手順でこれらを順に導入していきます。導入済みのものがあれば飛ばしていただいて構いません。なお Node.js は V8.x ではなく V6.x をご用意ください。また環境が異なる場合は導入手順も異なると思いますが、これら３つの前提となるミドルウェアが正しく導入されていれば次に進んでいただいて構いません。

Docker CE 17.x のインストール

参考にした記事はこちらです。
公式サイト：
https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/

次の手順では無料版の Docker CE(Community Edition) を導入します：

• リポジトリ設定／更新

$ sudo apt-get -y install apt-transport-https ca-certificates curl software-properties-common  
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -  
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"  
$ sudo apt-get update 

• Docker CE インストール

$ sudo apt-get -y install docker-ce

• Docker CE がインストールされたことを確認

$ sudo docker -v
Docker version 17.09.0-ce, build afdb6d4

↑Docker v17.09.0-ce がインストールできたことが確認できました。

• 権限の変更

Docker のインストールは完了しました。ただし一般ユーザーの場合、このままでは常に sudo を付けないと docker コマンドが使えません。sudo なしで docker コマンドを実行できるようにする場合は次の手順まで実行してください：

$ sudo usermod -aG docker $(whoami)

（この後、一度 Ubuntu からログアウトして再ログインする）

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
 Images: 0
 Server Version: 17.09.0-ce
 Storage Driver: overlay2
 Backing Filesystem: extfs
 :

↑Docker の情報が出力されます。sudo なしで docker コマンドが動くことが確認できました。

Docker-Compose

参考記事はこちら
公式サイト：
https://docs.docker.com/compose/install/

次の手順で docker-compose コマンドを直接ダウンロードします：

$ curl -L "https://github.com/docker/compose/releases/download/1.12.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ chmod +x /usr/local/bin/docker-compose

（この後、一度 Ubuntu からログアウトして再ログインする）

$ docker-compose -v
docker-compose version 1.12.0, build b31ff33

↑Docker-Compose v1.12.0 がインストールできたことが確認できました。

Node.js V6.x

最新版ではなく V6.x を導入するために n package を使ってバージョンを指定してインストールします。

こちらの記事を参考にしました。
公式サイト：
https://nodejs.org/ja/download/package-manager/#debian-and-ubuntu-based-linux-distributions-debian-ubuntu-linux

• まず普通に apt-get コマンドで nodejs と npm をインストールします。

$ sudo apt-get install -y nodejs npm

これで nodejs （とnpm）はインストールできているのですが、この方法だと node コマンドではなく nodejs コマンドを実行する必要があります。またバージョンが古く、今回の環境構築に必要な V6.x ではないバージョンが導入されているはずです。

$ node -v
bash: node: command not found

↑node コマンドが使えない

$ nodejs -v
v4.2.6

↑nodejs コマンドであれば使える。ただしバージョンは古い。

• n package をインストール

上記手順で導入した（古い）npm を使って、Node.js のパッケージバージョン管理ツールである n package をインストールします：

$ sudo npm cache clean
$ sudo npm install n -g

• node v6.x をインストール

n package を使って node v6.x をインストールします。まずは Node.js のバージョン一覧を確認します：

$ sudo n list
    :
  6.11.4
  6.11.5   <- 6.x はこれが最新（2017.11.12時点）
  7.0.0
    :

6.x 系では（この画面では）6.11.5 が最新のようでした。このバージョンをインストールする場合は次のように指定して実行します：

$ sudo n 6.11.5

ログインし直して（一度ログアウトして再ログイン）、改めて node コマンドと、そのバージョンを確認します：

$ node -v
v6.11.5

念のため、npm のバージョンも確認します：

$ npm -v
3.10.10

• 最初に入れた nodejs と npm を削除

このままでもいいのですが、最初に apt-get コマンドで導入した nodejs と npm が入ったままだと混乱の原因にもなるので、削除しておきます：

$ sudo apt-get purge -y nodejs npm

これで Hyperledger Fabric を導入する上での前提条件は全て揃いました！

図5　前提となるソフトの導入完了

Hyperledger Fabric

では改めてここから Hypderledger Fabric を導入する手順を紹介します。

（参考） http://dotnsf.blog.jp/archives/1066949876.html

Hyperledger Fabric コマンドラインインターフェース

まず npm を使って Hyperledger Fabric のコマンドラインインターフェースである composer-cli をインストールします：

$ sudo npm install -g composer-cli

↑このコマンドは終了まで結構時間がかかります。コマンドが完了したら composer-cli がインストールできていることを確認します：

$ composer -v
v0.14.2

↑composer-cli の v0.14.2 が導入できています。（バージョンは2017.11.12時点）

サポートツール

docker サービスが止まっている場合はここで起動しておいてください：

$ sudo service docker restart

ではメインディッシュである Hyperledger Fabric サポートツールを導入します。次の例ではホームディレクトリ直下に ~/fabric というフォルダを作って、その中にサポートツールを導入しています。フォルダを変更したい場合は適宜読み替えてください：

$ cd
$ mkdir fabric  （ホームディレクトリ配下の ~/fabric/ にサポートツールを導入する場合）
$ cd fabric
$ curl -O https://raw.githubusercontent.com/hyperledger/composer-tools/master/packages/fabric-dev-servers/fabric-dev-servers.zip
$ unzip fabric-dev-servers.zip

ダウンロード＆展開したサポートツールのファイルを確認します：

$ ls
createComposerProfile.sh  _loader.sh      teardownAllDocker.sh
downloadFabric.sh         package.json    teardownFabric.sh
fabric-dev-servers.zip    startFabric.sh
fabric-scripts            stopFabric.sh

↑バージョンによっては多少変わるかもしれませんが、次で使うシェルスクリプトが展開されることを確認します。

Hyperledger Fabric v1.0 のインストール

サポートツール内のシェルスクリプトを使って Hyperledger Fabric v1.0 をインストールします：

$ ./downloadFabric.sh

このコマンドの中で必要な docker イメージのダウンロード等が行われ、Hyperledger Fabric v1.0 がセットアップされます。

コマンドが終了したら、いったんこの時点で docker のプロセスを確認します。Hyperledger Fabric 関連のプロセスが１つも動いていないことを確認してください。

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

↑Hyperledger Fabric のプロセスが何も動いていない状態

Hyperledger Fabric の起動

では Hyperledger Fabric を起動します：

$ ./startFabric.sh

このコマンドが完了した後、改めて docker のプロセスを確認します。今度は Hyperledger Fabric 関連のプロセスが動いていることが確認できます。

$ docker ps
CONTAINER ID        IMAGE                                     COMMAND                  CREATED             STATUS              PORTS                                            NAMES
59ce8e49b410        hyperledger/fabric-peer:x86_64-1.0.3      "peer node start -..."   25 seconds ago      Up 25 seconds       0.0.0.0:7051->7051/tcp, 0.0.0.0:7053->7053/tcp   peer0.org1.example.com
352f9fe8c96f        hyperledger/fabric-ca:x86_64-1.0.3        "sh -c 'fabric-ca-..."   28 seconds ago      Up 26 seconds       0.0.0.0:7054->7054/tcp                           ca.org1.example.com
d9ad480318bd        hyperledger/fabric-orderer:x86_64-1.0.3   "orderer"                28 seconds ago      Up 25 seconds       0.0.0.0:7050->7050/tcp                           orderer.example.com
5cbf663372fe        hyperledger/fabric-couchdb:x86_64-1.0.3   "tini -- /docker-e..."   28 seconds ago      Up 26 seconds       4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp       couchdb

↑Hyperledger Fabric のプロセスが起動しています！

デフォルトプロファイルの作成

$ ./createComposerProfile.sh
（~/.composer-connection-profiles/hlfv1/connection.json および ~/.composer-credentials/ 以下が作成される）

Hyperledger Fabric の停止

起動した Hyperledger Fabric を停止する場合は stopFabric.sh を実行します：

$ ./stopFabric.sh

コマンド完了後、改めて docker のプロセスを確認して、動いていた Hyperledger Fabric 関連のプロセスが消えていることを確認します。

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

↑Hyperledger Fabric のプロセスが停止しました。

最後に、ダウンロードしたサポートツールのアーカイブファイルはもう不要なので削除しておきます：

$ rm fabric-dev-servers.zip

Hyperledger Fabric

以上でブロックチェーン環境のインフラとも言える Hyperledger Fabric の（最小限の）インフラ環境を構築することができました。もちろん実際の運用時にはピアノード数を増やしたり、（Docker 上で構成されたものだけではなく）他のネットワークとも接続してビジネスネットワークを構成することになると思いますが、一方でこれだけでアプリケーション開発および動作確認程度はできる環境にはなっています。

Hyperledger Fabric を使ってアプリケーションを開発する場合にはいくつかの方法がありますが、その中でも Hyperledger Composer フレームワークを使うと（ChainCode や Go 言語といった知識がなくても）アプリケーションの定義や開発ができて便利＆オススメです。そちらについても機会があればこのテックブログで紹介させていただきたいのですが、導入手順については別サイトで以前に紹介したことがあるので、そちらを参照ください：

http://dotnsf.blog.jp/archives/1066959724.html

こんにちは、藤城（@tafujish）です。今回もidcfcloud-cliの話をします。
予定どおり開発が進みまして、このたびDNS/GSLBとコンテンツキャッシュに対応しました。ここでは、追加された機能について紹介します。

idcfcloud-cliはその名のとおり、IDCFクラウドをコマンドラインから操作するためのインターフェースで、今回のように対応サービスを順次拡張していき各サービスを統合しようとしています。idcfcloudコマンドから簡単にAPIを実行できますので、ちょっとしたスクリプト化など自動化を簡単にはじめられます。

インストールや初期設定については以下のエントリーを参照ください。

Ubuntu 16.04 環境
blog.idcf.jp

CentOS 7.x 環境
blog.idcf.jp

既にインストール済みの方は、

$ sudo gem update idcfcloud
$ sudo idcfcloud init

でアップデート可能です。

では、新機能について見ていきましょう。

• 列選択のオプションが入りました（--fields、--json-path）
  • --fields
  • --json-path
• コンテンツキャッシュを試してみる
• DNS/GSLBを試してみる
• コンピューティング（Beta）を試してみる
• まとめ

$ idcfcloud ilb list_loadbalancers
{
  "status": 200,
  "message": "",
  "data": [
    {
      "id": "476b0e9f-ee26-4630-ab64-51edaa10aad4",
～略～

$ idcfcloud ilb list_loadbalancers --fields=name,id
[
  {
    "name": "clitest",
    "id": "476b0e9f-ee26-4630-ab64-51edaa10aad4"
  },
  {
    "name": "clitest2",
    "id": "9b6fbe71-ead1-4b74-afb6-db8447065d76"
  },
  {
    "name": "clitest3",
    "id": "d3bca49d-c70a-42b1-9cdb-376843db4ea5"
  }
]

$ idcfcloud ilb list_loadbalancers -o csv --fields=name,id
name,id
clitest,476b0e9f-ee26-4630-ab64-51edaa10aad4
clitest2,9b6fbe71-ead1-4b74-afb6-db8447065d76
clitest3,d3bca49d-c70a-42b1-9cdb-376843db4ea5

$ idcfcloud ilb list_loadbalancers --json-path='$..configs'
[
  [
    {
      "id": "65ac4726-4ec1-45aa-8168-71bdad2997c5",
      "port": 80,
      "loadbalancer_id": "476b0e9f-ee26-4630-ab64-51edaa10aad4",
～略～

$ idcfcloud ilb list_loadbalancers --json-path='$..configs' --fields=id
[
  [
    {
      "id": "65ac4726-4ec1-45aa-8168-71bdad2997c5"
    }
  ],
  [
    {
      "id": "4d5ecb9d-a54a-4ce8-8092-39304018bae4"
    }
  ],
  [
    {
      "id": "20d0e565-e876-4bc3-8960-1a9569ae7236"
    }
  ]
]

$ idcfcloud cdn get_fqdn_list '{"api_key":"eHECQ5pdKKIoyxEJOFrzgwN-JqSyR3JMc1Ivf_AmN4uoj3LxzJmmImxgs9CEeorts-JXDRdO4NvmxkviPc-sDG"}'
{
  "status": 200,
  "message": "",
  "data": {
    "status": "success",
    "customer_domain": [
      {
        "id": "4436",
        "customer_id": "65",
        "cache_fqdn": "p1irv22ozsvv61.cdn.jp.idcfcloud.com",
        "cache_dir": "/",
        "origin_fqdn": "cdnorg.ds.jp-east.idcfcloud.com",
～略～

$ idcfcloud cdn delete_cache '{"api_key":"eHECQ5pdKKIoyxEJOFrzgwN-JqSyR3JMc1Ivf_AmN4uoj3LxzJmmImxgs9CEeorts-JXDRdO4NvmxkviPc-sDG","delete_path":"http://cdnorg.ds.jp-east.idcfcloud.com/img003.png"}'
{
  "status": 200,
  "message": "",
  "data": {
    "status": "success",
    "messages": "We accept the cache deleted successfully."
  }
}

$ idcfcloud dns list_zones -o table --fields=uuid,name
+------------------------------------+---------------+
|uuid                                |name           |
|92b7067a-75c0-4cd6-aaa4-7d8a4c1349ac|example.com    |
|faafa764-75d6-468a-b572-c0688ee141d0|example.net    |
|698ff2f7-0f03-48b3-bf8d-85f0789479fe|example.org    |
|d2656f15-80de-4191-81c0-b168f883c7ec|example.jp     |
|058ec764-7e47-41a6-9939-758ad9ecb265|sub.example.com|
+------------------------------------+---------------+

$ idcfcloud dns list_records "92b7067a-75c0-4cd6-aaa4-7d8a4c1349ac" -o table --fields=uuid,name,type,content
+------------------------------------+----------------+----+-----------+
|uuid                                |name            |type|content    |
～略～
|3641e5d9-f3eb-413b-927e-f28fb3eced7e|www.example.com |A   |203.0.113.1|
|4c200167-5679-49ea-b7aa-d77e72c91165|example.com     |A   |203.0.113.1|
|27fba561-4f42-41a5-8c98-0d87f3ec759c|www.example.com |AAAA|2001:db8::1|
+------------------------------------+----------------+----+-----------+

$ idcfcloud dns update_record "92b7067a-75c0-4cd6-aaa4-7d8a4c1349ac" "3641e5d9-f3eb-413b-927e-f28fb3eced7e" '{"content":"203.0.113.99"}'
{
  "status": 200,
  "message": "",
  "data": {
    "uuid": "3641e5d9-f3eb-413b-927e-f28fb3eced7e",
    "name": "www.example.com",
    "type": "A",
    "content": "203.0.113.99",
    "ttl": 3600,
    "description": "",
    "created_at": "2017-12-01T11:56:42+09:00",
    "updated_at": "2017-12-04T20:40:11+09:00"
  }
}

$ idcfcloud compute listVirtualMachines

$ idcfcloud compute listZones

$ idcfcloud compute listServiceOfferings

$ idcfcloud compute listTemplates '{"templatefilter":"featured"}'

$ idcfcloud compute listSSHKeyPairs

$ idcfcloud compute deployVirtualMachine '{"zoneid":"f4583787-7bff-461a-b026-73942911ca8b","serviceofferingid":"bd226b3b-6ae7-454d-b53d-c886f7eebe42","templateid":"49160f13-abbf-4f57-a711-110069d4da7b","keypair":"keyname1","name":"vmtest1"}'

お久しぶりです。ビジネス開発部の神谷です。

みなさん、Webサイトの暗号化はされていますか？ユーザーが安全に通信を行ったり、個人情報の盗難を防ぐためには必須ですね。 また、暗号化しているWebサイトはGoogleの検索で上位に表示されたりと、SEO対策という観点でも注目を浴びています。

今回は、そんな暗号化に使われる「SSL/TLS」について書いていきたいと思います。

• SSL/TLSとは
  • SSL/TLSの歴史
• TLS1.2に移行しましょう
  • クライアント側の対応
• IDCFでの対応状況
  • インフィニットLB（ILB）
  • コンテンツキャッシュ
  • 構成例
• まとめ

SSL/TLSとは

• SSL（Secure Sockets Layer）
• TLS（Transport Layer Security）

上記2つはどちらも、クライアント <->サーバー間の通信を暗号化する技術です。 TLSはSSLを元にして定められたプロトコルであるため、名称は違いますが技術的には同じものを指しています。

ご存知の方がほとんどだと思いますが、HTTP通信をセキュアに行うためのプロトコルであるHTTPSは、SSL/TLSが使用されています。

SSL/TLSの歴史

2017年12月現在の最新バージョンはTLS 1.2となります。 更に暗号強度を高めたTLS 1.3も現在策定中であり、2017年7月3日にドラフト仕様のバージョン21が標準化団体IETFによって公開されています。

▲SSL/TLSのバージョン表

上記の表の通り現在までに様々なバージョンがリリースされていますが、SSLはRFCによってすべて使用を禁止されています。 ですが、一般的にサーバー証明書のことは「SSLサーバー証明書」と呼び、「TLSサーバー証明書」という言葉を聞いたことがない人がほとんどではないでしょうか。 実態はTLSでも用語として「SSL」が普及しているため、まだまだ表記上は「SSL」が使われる傾向にあります。

TLS1.2に移行しましょう

さて、SSLがRFCによって使用が禁止されていることは記載した通りですが、TLSはどうでしょうか。

クレジットカード業界における国際セキュリティ基準であるPCI DSS v3.2に、TLSに関して記載があります。 一部抜粋し要約すると、次のようになります。

• セキュリティ機能の新規実装時には、SSLと早期のTLS（1.0と1.1の一部の実装）を使用してはいけない
• 既存で実装されているSSLと早期のTLSに関しては、2018年6月30日までに廃止し、TLSの安全なバージョンのみを使用しなければならない

早期のTLSを利用してはいけない主な理由としては、暗号化通信の一部を解読可能な「POODLE」という脆弱性が存在しているからです。
発見された当初はSSL3.0 のみが対象とされていましたが、その後TLS1.0/1.1の一部の実装においても影響を受けると発表されました。 そのため、様々な企業・団体が「TLS1.0/1.1」の使用をやめ、「TLS1.2」への移行や使用の推奨を始めています。

• Apple
  ・Apple will require HTTPS connections for iOS apps by the end of 2016 | TechCrunch

• Microsoft
  ・[IT 管理者向け] TLS 1.2 への移行を推奨しています

• スターバックスコーヒージャパン
  ・ 「重要なお知らせ」

2017年12月現在、脆弱性が確認されていないバージョンはTLS1.2のみとなります。 新規に使用する場合、特別な理由がない限りTLS1.2を使用しましょう！

クライアント側の対応

サーバー側でTLS1.2対応を行ったとしても、クライアント側が対応していなければ意味がありません。
クライアントのOSやブラウザのバージョンが古いと、警告が表示されたり接続ができなかったりすることがあります。
TLS1.2対応をする際は、Webサイトで事前にアップデートの案内をするなどの対応も検討すべきでしょう。
各クライアント端末における対応状況を、次にまとめます。

IDCFでの対応状況

さて、ここまでTLS1.2の推奨をしてきましたが、実際の移行はそう簡単ではありません。 大きな課題の一つとして、HTTPSの暗号化/復号が多くのサーバーリソースを必要とすることによる、インフラへの負荷が挙げられます。 Appleが発表しているATSなどは暗号化アルゴリズムの要件も厳しく、インフラへの負荷はかなり大きいです。

IDCFなら、そんな悩ましい課題を次の2つのサービスで解決できます。

インフィニットLB（ILB）

www.idcf.jp SSLオフロード機能をもった高性能ロードバランサーサービスです。
暗号化/復号処理をインフィニットLBに集約できるだけでなく、負荷によって自動でスケールアウトするためボトルネックになることはありません。

コンテンツキャッシュ

www.idcf.jpコンテンツ配信の高速化を行うCDNのサービスです。インフィニットLB同様、SSLオフロード機能によってSSL/TLSを用いた通信を簡単に実現できます。

構成例

IDCFクラウドとインフィニットLB、コンテンツキャッシュを組み合わせることによって、たとえば次のような構成が考えられます。
★構成のポイント★

• インフィニットLBは負荷によって自動でスケールするため、ボトルネックになる心配なし
• 暗号化/復号処理をインフィニットLB・コンテンツキャッシュに集約しているため、既存サーバーのスペック変更なしでOK
• オリジンサーバー <->コンテンツキャッシュ間の通信は仮想ルーターを通すことにより、帯域を分散

このように、インフィニットLB・コンテンツキャッシュによってアプリケーションのパフォーマンスを向上させつつ、SSL/TLSの対応が可能です。

まとめ

• SSL/TLSは、クライアント <->サーバー間の通信を暗号化する技術
• 2017年12月現在、SSL/TLSにおいて脆弱性がないバージョンはTLS1.2のみのため、移行しましょう
• IDCFなら、インフィニットLBとコンテンツキャッシュでお手軽にSSL/TLSの対応が可能

TLS1.2への移行が終わっていない方は、早めの対応をおすすめします。

また、過去に本記事と関係が深い「常時SSL化」についてもIDCFテックブログで紹介しています！

blog.idcf.jp

ぜひ合わせて読んでみてください！
それではまた次回の記事でお会いしましょう！

こんにちは藤城（@tafujish）です。IDCFクラウドでは、HighIOタイプやベアメタルサーバーにより高速なIOPSを利用できるプランを用意しており、データベースなどの高IOPSを求める用途で好評いただいています。
その一方で、「●●のタイプは何IOPS出ますか？」という質問もしばしばいただきますが、一言で回答できそうで実は難しいんです。IOPSの上限値のことなのか、ベンチマークの値なのか。それが、リードなのかライトなのか混合なのか、シーケンシャルなのかランダムなのか、ブロックサイズは？並列度は？プリコンディショニングした？キャッシュ効いてる状態？などなど、「1万IOPSです」といったように一言で回答できないのです。

「10万IOPS出ます」なんて言った日には、Queue Depthが大きいときの値だから実アプリからはそんなに出ないし、これが元になってトラブルが起きるのではと余計なことまで考え込むと回答できなくなってしまいます。そこで今回は、様々な利用目的の人が見ても、「このIOPSの値が欲しかったんだ」と言える方法を紹介し、IDCFクラウドの高速なIOPSを提供する全タイプに対してベンチマークによるIOPSを計測してみます。具体的には、ezFIOというツールを使えば、様々なI/O性能をベンチマークしレポーティングまでを一気にやってくれるのです。

• ezFIOとは
• ezFIOの使い方
  • fioをインストール
  • ezFIOをインストール
  • ezFIOの実行例
    • --utilization
    • --output
    • --yes
• ezFIOの結果の見方
• IDCFクラウド上でベンチマーク
• まとめ

# yum install epel-release -y
# yum install fio sdparm -y

# apt update
# apt install fio sdparm -y

# wget https://github.com/earlephilhower/ezfio/archive/v1.1.tar.gz
# tar zxf v1.1.tar.gz
# cd ezfio-1.1

# ./ezfio.py --drive /dev/sdb

こんにちは、河合です。サービスを運用する上で止めないこと(可用性)はとても重要ですよね。考慮すべきテーマとしてBCP(事業継続計画)・DR(Disaster Recovery：災害復旧)対策があります。このとき活躍するのがGSLB(Global Server Load Balancing：広域負荷分散)サービスです！GSLBを使えば、災害などの有事によるメインサイトダウン時のバックアップサイトもしくはSorryサーバーへの自動切り替えや、大規模なアクセスがきた時の分散の仕組みを実現することができます。 今回はIDCFクラウドDNS/GSLBのGSLBサービスにフォーカスして、次の流れで設定方法や用途を紹介します。

• GSLB概要
• 設定方法
  • Step1. GSLBサービス申込み＆ログイン
  • Step2. 振り先サーバーの登録
  • Step3. ヘルスチェック詳細設定
• 切り替わりの確認
• まとめ

GSLB概要

GSLBとは、DNSの名前解決を用いたロードバランシング機能です。DNSラウンドロビンとの最大の違いは、ヘルスチェックや重み付けができるところです。

GSLBを使ったグローバルレベルでの分散は、大規模アクセス時の負荷分散や災害発生時のサイト切り替えを実現し事業継続性を高めます。例えばBCP対策としてのGSLB導入には、次のようなメリットが挙げられます。
　・複数拠点間での分散
　　物理的に離れた環境間でサイト分散することで可用性を向上し、自然災害やテロなどの緊急時にもサービスが継続できます。

　・重み付けによる自由な構成
　　各レコードに対して重み付けができるため、Active/ActiveやActive/Standbyなど自由度が高い構成を実現できます。 例えばActive/Standbyは、メインサイトと障害時のみ使うバックアップサイトとわけたり、Active/Active構成であれば両サイト同時にサービス提供するような完全冗長ができます。リソースやコストなどを踏まえてユーザーが最適に選択することができます。

　・自動切り替わりによるダウンタイムの軽減・回避
　　ヘルスチェックに失敗した時には、自動で切り替わりが発生するので、サービスのダウンタイムを軽減できます。また、上記で紹介したActive/Active構成を採用している場合、完全冗長されているため、万が一障害や災害が発生してもサービスへの影響を最小限に留めることができます。

このGSLB、以前テックブログで紹介させていただきましたがIDCFコーポレートサイトでも取り入れています。東日本のメインサイトダウン時には西日本のバックアップサイトへ切り替わるよう、ダウンタイムを最小限に抑えた構成にしています。

関連記事
コーポレートサイトのセキュリティ対策は万全ですか？

GSLBはDNSサービスと一緒にお使いいただくサービスとなります。最小構成ならワンコインから始められるので、無理なく導入を始めることができます。また、IDCFクラウドDNSのネームサーバーは国内3拠点に分散配置、すべてプライマリの冗長構成となっているため安心してお使いいただけます。詳しい仕様はサービスページからぜひチェックしてみてください！

設定方法

これから紹介する3ステップで簡単に分散環境やDR環境が作成できるので、さっそく設定していきましょう。例で構築するのはApache Webサーバーの簡単なDR環境です。東日本と西日本の2拠点でActive/Standby構成とします。GSLBではレコードごとに重み付けの設定ができ、Standbyにするには重み0となります。重み付けについてはこの後Step2で説明します。

▲図1. 作成する環境イメージ

Step1. GSLBサービス申込み＆ログイン

IDCFクラウドコンソールからオンラインでお申込みいただけます。グローバルメニューから「DNS/GSLB」を有効化してください(図2)。

▲図2. グローバルメニュー

Step2. 振り先サーバーの登録

対象ゾーンを選択し、「レコード登録」を選択します。

▲図3. 選択したゾーンの設定画面
※GSLB単体での利用は出来ないので、あらかじめDNSサービスでゾーン作成の必要があります。ゾーンの作成方法については次のドキュメントをご参考ください。

参考ドキュメント
IDCFクラウド DNS　スタートアップガイド

レコード作成画面でAレコードを選択するとGSLBの欄が見えるようになります。ここで「有効」を選択するとGSLBで設定するパラメータ(図4)が表示されるので、利用に応じて記入しましょう。今回、レコード名はwwwとしています。

▲図4. GSLB設定項目

各設定項目は次の通りです。

▲表1. GSLBパラメータ

※1 例えばA,B,C 3つの振り先に対して1:2:3の重み付けにすると、それぞれ1/6、2/6、3/6の割合になります。ですのでDNSの問い合わせが6回来た場合、Aを1回、Bを2回、Cを3回返答します。
※2 ゾーン認証が完了していないとヘルスチェックの有効化ができないのでご注意ください。

ヘルスチェック失敗時の動作
ヘルスチェックで異常と判断した場合、振り分け対象から切り離されます。その後1分に1度自動で復旧の確認が行われ、チェックが2回連続で成功すると復旧と判断します。
ヘルスチェックの設定が「あり自動有効化」であれば、復旧時に自動的に振り分け対象として切り戻され、「あり手動有効化」の場合は手動で切り戻しを実施していただく必要があります。

詳細設定が終了したら、右端の「＋」をクリックすると振り分け対象のサーバーとして登録されます。ここまでの操作を登録するサーバーごとに行ってください。
今回の環境ではWeb-1(東日本リージョン)を重み1の手動切り替え、Web-2(西日本リージョン)を重み0の自動切り替えで登録します。

Step3. ヘルスチェック詳細設定

ヘルスチェックを「あり」にしてレコードを登録すると、さらにヘルスチェックの詳細設定項目が出てきます(図5)。ヘルスチェックの種類をHTTP/HTTPS/TCPから選択し、使用するポートを指定します。
※ヘルスチェックなしにすると単純な重み付けありのDNSラウンドロビンとして利用できます

▲図5 ヘルスチェック設定

「チェック」項目ではヘルスチェックの間隔や失敗回数などを指定することが可能です。

▲表2. ヘルスチェック項目

HTTP/HTTPSの場合、ステータスコードが100,200,300番台を正常と判断します。TCPの場合はSYN/ACKの返答によって正常を確認します。
なお、ヘルスチェック対象IPアドレス側でヘルスチェックサーバーからの通信の許可を忘れずにしてください。次のグローバルIPアドレスがIDCFヘルスチェックサーバーのIPアドレスです。
　210.140.111.128/25
　202.239.51.128/25
　210.152.239.128/25

通知先にはメール/Slackの2種類が選択でき、ヘルスチェック失敗/復旧時の際に通知が実施されます。
すべての設定が終わったら「登録する」をクリックしてGSLBレコードの設定完了です！

切り替わりの確認

では、設定したGSLBが想定通りに動いているか確認してみましょう。 まずはブラウザから登録したドメインにアクセスします。

▲図6 Web-1 (Activeサイト)

Active(重み1)に設定したWeb-1サーバーのページが表示されていることを確認したところで、Web-1のhttpdをDownさせます。
その後ブラウザをリロードすると、Web-2サーバーのページが表示されました。うまく切り替わっています。

▲図7 Web-2 (Standbyサイト) への切り替わり確認

GSLBによる自動切り替えが確認できたところで、先ほどDownさせたWeb-1を再度立ち上げて手動切り替えを実践します。
IDCFクラウドコンソールのDNS/GSLBページを開くと手動切り替え待ちの状態になっているので(図8)、マウスオンして「有効化する」をクリックし、元のWeb-1がActive、Web-2がStandbyの状態に戻します。

▲図8 手動切り替え待ち状態

その後再度Webページをリロードし、Web-1が表示されていることを確認します。 これで今回構築したDR環境の動作確認ができました。今回は手動で切り戻しをしましたが、自動で切り戻すことも可能です。

まとめ

ここまで、GSLBの設定～動作確認までを紹介しました。GSLBレコード自体はわずか3ステップで登録できてしまうので、とても簡単に始められますね！

GSLBの特長は、インフラ関係なく複数拠点を対象として設定できることです。また、IDCFの環境のみにとどまらず、外部のサービスとも組み合わせてご利用いただけます。そのため、IDCFクラウド間に限らずハウジング×IDCFクラウド、他社クラウド×IDCFクラウドといった柔軟な構成が実現できます。もしGSLBを使うためIDCFクラウドDNSへ切り替えを検討される場合は、こちらで無停止切り替えの手順を公開していますので、ご参考ください。
近日中にGSLBの機能アップデートを予定しておりますので、その際は改めて紹介したいと思います。
それではお楽しみに！

こんにちは、河合です。今回はIDCFクラウド DNSについて、12月14日にリリースされた2つの機能をご紹介します！

• お待たせしました♪ NSレコード対応
• レコード一括登録機能が登場
• さいごに

お待たせしました♪ NSレコード対応

これまでレコード操作の対象にネームサーバー(NS)が含まれておらず、追加・削除・編集ができませんでしたが、今回の機能改修でNSレコードも編集できるようになりました。これによって権限委任が可能になりますので、例えばサブドメインをIDCFクラウド環境以外のDNSサーバーで運用したいという方などにもご活用いただけます。
ご利用方法はこれまでの「レコード追加」と同様です(図1)。レコードタイプ選択の一番右に「NS」が追加されていますのでぜひご利用ください！

▲ 図1　NSレコード追加の画面

設定時は次の制限がありますのでご注意ください。詳細は仕様書にも記載がありますのでご参照ください。

※ TTL範囲は600〜86400
※ 一部登録不可のドメイン(RFC2606で予約されているトップレベルドメインなど)があります

では、続けて新機能についてお話します！

レコード一括登録機能が登場

今までは「レコード登録」から1行ずつレコードを登録していただいていましたよね。今回リリースした新機能「バルクインポート」では、このレコード登録を一括でできてしまいます！DNS移管など、大量の設定が必要な際にお役立ていただけます。

▲ 図2 バルクインポート イメージ

登録方法は次の2パターンあります。

1. BIND形式のゾーンファイルをインポート
2. テキストをコピー&ペースト or 直接入力

▲ 図3　ゾーン選択後の画面でバルクインポートをクリック

パターン1は所有しているゾーンファイルをそのままインポートする方法です。バルクインポートを選択後「ファイルを選択」からレコード登録を行う対象ゾーンのファイルをインポートします。そうするとファイルの記述内容がテキストボックスに反映されます(図4)。この時もし不適切なレコード形式があればエラー文が表示されるので、テキストボックス上でそのまま修正することが可能です。

▲ 図4 ゾーンファイル[idcf-dns.zone]を選択した状態

形式が整ったら右下の「適用」をクリックするとインポート内容が表示されるので(図5)、問題なければ再度「適用」をクリックいただき、最後の確認をするとインポートが完了します(図6)。

▲ 図5 インポート前のレコード確認画面

▲ 図6 インポートしたレコードが追加されているのを確認

パターン2はファイルを読み込ませず、コピー&ペーストでテキストボックスに入力して登録する方法です。また、その場でテキストボックス上に記述していくことも可能です。複数のレコードを一括で手間をかけずに設定できるので、例えば一時的にDNSの挙動を確かめたい時などにも有効的です。テキストボックスにレコード情報が書かれている状態になれば、その先はパターン1で説明した手順と同様になります。

さいごに

今回はIDCFクラウド DNSのアップデート情報についてご紹介しました。
また、このアップデートがあった12月14日、もう1つの変化があったことにお気づきの方はいらっしゃいますでしょうか？実は、同日にIDCFクラウド DNSのロゴをリニューアルしています！

本記事の[図2 バルクインポート イメージ]でもさらっと載せていたのですが、これまでのロゴよりもわかりやすく、IDCFがイメージするDNSサービスがより伝わるようにと生まれ変わりました！ちょっとした変化ではありますが、ユーザーのみなさんにはチェックしてほしいポイントなのでこの場を借りてお伝えしました！(もし古いロゴを見かけたら教えてくださいね)
今後もさらなるパワーアップを目指していますので、ぜひご期待ください。

Serverspecとは

こんにちは。山田です。 まさかとは思いますが、2017年にもなってサーバーのテストを片手にエクセルのテスト項目をもち、目視で確認している人はいないとは思います。 実はまだ、お手てで頑張ってテストをしている。そんな人に今回の記事を贈ります。 いつまでも旧態然としたエクセル主義を撲滅するためにもServerspecでテストを自動化し、周りの上司へ「一台ずつ確認してるんですか〜？」と言ってやってください。 今回はIDCFクラウド上にてServerspecを構築し、実際のテストを行うまでの手順をご紹介します。

Serverspecのすごいところは以下通りです。

• サーバーの設定/状態が正しいか一瞬でチェックできる。
• サーバーにエージェントなどをインストールする必要がない。
• プログラミング未経験でもなんとかなるようにできている。

使用目的

Serverspecは元々、インフラコードのリファクタリングを目的に開発されていますが、 様々な目的に使用することが可能です。

• サーバー・ネットワーク機器の設定/構築作業における確認手順の自動化
• 既存サーバーの状態確認
• Serverspecの真の目的であるインフラコードのリファクタリング

今回のお話では、サーバーの設定/構築作業における確認手順の自動化に絞ってお伝えします。 例えば手順書ベースで確認作業を行なう場合、見落としが発生したり、確認作業の長期化などの問題があります。 そこでServerspecを使うと下記のメリットがあります。

• 見落としがない
• 属人化の解消
• 作業時間の圧倒的短縮
• あるべき姿が定義されるので、設定/状態の厳密な確認が可能

では実際どのようにしてサーバーの状態をチェックするのか具体的にみてみましょう。 例えばWordPressをインストールしたサーバーをテストするためには次のようなコードを書きます。

require 'spec_helper'

describe package('nginx') do
  it { should be_installed }
end

describe service('nginx') do
  it { should be_enabled }
  it { should be_running }
end

describe port(80) do
  it { should be_listening }
end

コードとか書いたことのない人でも、何がしたいのかがわかりますね。
では、実際にServerspecをIDCFクラウド上に構築し、サーバーのテストを行ってみましょう。

IDCFクラウド上に作成する仮想マシンのスペック

今回はIDCFクラウド上でCentOS 7.3がインストールされている仮想マシンを作成します。 詳細は下の表に記載しています。
※IPはDHCPで動的に割り当てられたIPをそのまま利用しています。

それでは早速Serverspecサーバーを作成していきましょう。

Serverspecユーザー作成

今回はServerspecユーザーを作成し、ユーザーのホームディレクトリ以下に インストールをしていきます。
※今回は検証のため、Serverspecユーザーをwheel(管理者)グループへ追加していますが、皆様の環境に合わせて正しく権限付けしてください。

# useradd serverspec
# usermod -G wheel serverspec
# su - serverspec

ruby,rbenvのインストール

まずは、必要パッケージをインストールします。

$ sudo yum -y groupinstall "Development Tools"
$ sudo yum -y install git openssl-devel readline-devel zlib-devel

上記をインストールしたら、つづいてrubyをインストールします。

まずはgitからクローン

$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
$ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

パスの設定

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
$ echo 'eval "$(rbenv init -)"' >> ~/.bashrc
$ source ~/.bash_profile

Ruby2.3.4をインストール

$ rbenv install 2.3.4
$ rbenv global 2.3.4

Serverspecのインストール

ユーザーディレクトリにてGemfileを作成します。

$ gem install bundler
$ bundle init

直下にGemfileが作成されるので、 内容を以下に変更

$ vi Gemfile

こんな感じにします。

$ cat Gemfile
source "https://rubygems.org"

gem 'serverspec'
gem 'rake'
gem 'highline'

それではbandleコマンドでServerspecをインストールします。

bundle install --path /home/serverspec/

するとServerspec直下にディレクトリが作成されます。

$ ls
Gemfile  Gemfile.lock  ruby

Serverspecの設定を行います。

$ bundle exec serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1　←今回はCentOSを使用しているので「1」を選択

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 1 ←今回はsshで行なうので「1」を選択

Vagrant instance y/n: n　　　　←今回はVagrantはつかわないので、「n」を選択
Input target host name: wordpress-server
 + spec/
 + spec/wordpress-server/
 + spec/wordpress-server/sample_spec.rb
 + spec/spec_helper.rb
 + Rakefile
 + .rspec

現在のディレクトリ状況

$ tree  --charset=o  -L  3
.
|-- Gemfile
|-- Gemfile.lock
|-- Rakefile
|-- ruby
|   `-- 2.3.0
|       |-- bin
|       |-- build_info
|       |-- cache
|       |-- doc
|       |-- extensions
|       |-- gems
|       `-- specifications
`-- spec
    |-- spec_helper.rb
    `-- wordpress-server
        `-- sample_spec.rb

11 directories, 5 files

この状態で、Serverspecを使えるようになりました。

複数ホストを指定できるように設定変更

デフォルトのままだと、1つのホストに対してしかServerspecを実行できません。 なので、二つのファイルを書き換え、複数ホストに対応させていきます。

Rakefile

require 'rake'
require 'rspec/core/rake_task'
require 'yaml'
require 'highline/import'

properties = YAML.load_file('properties.yml')

#ENV['SSH_USER'] = ask("Enter ssh user: ") { |q| q.echo = true }
#ENV['SSH_PASSWORD'] = ask("Enter ssh password: ") { |q| q.echo = false }

desc "Run serverspec to all hosts"
task :serverspec => 'serverspec:all'

namespace :serverspec do
  task :all => properties.keys.map {|key| 'serverspec:' + key }
  properties.keys.each do |key|
    desc "Run serverspec to #{key}"
    RSpec::Core::RakeTask.new(key.to_sym) do |t|
      ENV['TARGET_HOST'] = properties[key][:hostname]
      t.pattern = 'spec/{' + properties[key][:roles].join(',') + '}/*_spec.rb'
      t.fail_on_error = false
    end
  end
end

spec_helper.rb

require 'serverspec'
require 'pathname'
require 'net/ssh'
require 'yaml'

set :backend, :ssh
set :path, '/sbin:/usr/sbin:$PATH'
set :request_pty, true

RSpec.configure do |c|
  c.before :all do
    set :host, ENV['TARGET_HOST']
    options = Net::SSH::Config.for(c.host)
    ## for login key + passphrase configurations
    options[:keys] = ENV['KEY'];
    options[:user] = ENV['SSH_USER']
    #options[:password] = ENV['SSH_PASSWORD']
    set :ssh_options, options
  end
end

上記を書き換えたら実行環境は完成です。

では、実際のテスト内容を記載していきます。
まずはspecディレクトリに移動に移動します。
本環境では対象サーバー名を「wordpress-server」としたので、 その名前のディレクトリが作成され、中にsample_spec.rbファイルが格納されています。
この.rbファイルに確認したいテスト内容を記載します。 今回はsample_spec.rbを編集して、実行してみましょう。

$ cd /home/serverspec/spec/wordpress-server
$ vi sample_spec.rb

require 'spec_helper'

describe package('nginx') do
  it { should be_installed }
end

describe service('nginx') do
  it { should be_enabled }
  it { should be_running }
end

describe port(80) do
  it { should be_listening }
end

describe service('mariadb') do
  it { should be_enabled }
  it { should be_running }
end
describe port(3306) do
  it { should be_listening }
end

describe service('php-fpm') do
  it { should be_enabled }
  it { should be_running }
end

• Nginxはインストールされているか。
• Nginxは自動起動設定されているか。サービスが上がっているか。
• ポート80はLISTENしているか
• MariaDBは自動起動設定されているか。サービスが上がっているか。
• ポート3306はLISTENしているか
• php-fpmは自動起動設定されているか。サービスが上がっているか。
  を確認しています。 その他の設定や、サービスの起動状態なども確認できるので、公式サイトをチェックしてみてください。
  http://serverspec.org/resource_types.html

最後にServerspecをでテストしたい対象と、テストの内容を properties.ymlに記載します。
デフォルトでは存在しないので、新規で作成します。

vi /home/serverspec/properties.yml
wordpress-server:
  :roles:
    - wordpress-server
  :hostname: wordpress-server

今回は一台のみ記載しましたが、この上記と同様の記載を追記していくことで複数のホストを登録できます。 roles部分に記載したものの実態は spec/wordpress-server/sample_spec.rbです。 wordpress-serverディレクトリ以下の*.rbがこのroleで実行されます。 複数のroleを記載して実行することも可能です。

Serverspecを実行

※実行前にテスト対象へのssh接続ができるようにしてください。
　テスト対象への名前解決ができるようにしてください。

$ pwd
/home/serverspec
$ bundle exec rake serverspec --trace KEY=~/.ssh/id_rsa

[serverspec@serverspec ~]$ bundle exec rake serverspec --trace KEY=~/.ssh/id_rsa
** Invoke serverspec (first_time)
** Invoke serverspec:all (first_time)
** Invoke serverspec:wordpress-server-syamada (first_time)
** Execute serverspec:wordpress-server-syamada
/home/serverspec/.rbenv/versions/2.2.3/bin/ruby -I/home/serverspec/ruby/2.2.0/gems/rspec-core-3.6.0/lib:/home/serverspec/ruby/2.2.0/gems/rspec-support-3.6.0/lib /home/serverspec/ruby/2.2.0/gems/rspec-core-3.6.0/exe/rspec --pattern spec/\{wordpress-server-syamada\}/\*_spec.rb

Package "nginx"
/home/serverspec/ruby/2.2.0/gems/specinfra-2.68.0/lib/specinfra/backend/ssh.rb:76:in `create_ssh': Passing nil, or [nil] to Net::SSH.start is deprecated for keys: user
  should be installed

Service "nginx"
  should be enabled
  should be running

Service "mariadb"
  should be enabled
  should be running

Port "3306"
 should be listening

Service "php-fpm"
  should be enabled
  should be running

Port "80"
  should be listening

Finished in 0.41725 seconds (files took 0.24948 seconds to load)
9 examples, 0 failures

** Execute serverspec:all
** Execute serverspec

上記のように完了します。
成功した場合は緑の文字で出力され、失敗の場合は赤字で出力されます。

まとめ

IDCFクラウド上でさくっとServerspecサーバーを立ててサーバーのテストをする方法を紹介しました。 皆様も是非、Serverspecを使って、エクセル管理のテスト項目書の撲滅を目指しましょう。 次はよく使用するテスト項目などの紹介をしてみたいと思います。

はじめまして＆こんにちは。某外資系クラウド会社にて「ブルーなんとか（注　下に答が・・）」というサービスの洗脳活動エバンジェリストをしている木村と申します。前職を含めた IDCF 歴は３年、MORIO Dojoでは青帯を拝命しております。ご縁あって IDCF テックブログにデビューさせていただく機会を頂戴しました。よろしくお願いします。

お客様がクラウドを利用する場合、「特定の一社だけと契約する」というケースは珍しく、検証も含めて多くのケースでいわゆるマルチクラウド環境をご利用いただく機会が多いと実感しています。

今回はそんなマルチクラウド環境における相互ネットワーク間をセキュアに接続する例として、IBM Bluemix と IDCF クラウド環境間で Secure Gateway というサービスを利用した通信方法の実現について、その概要と具体的な手順を紹介します。

マルチクラウド間接続

複数のクラウド環境を併用する、いわゆる「マルチクラウド」環境は、各社の提供するサービスや機能のイイトコ取りをするようなケースでは珍しくないと思っています。その環境下では各社の提供するネットワーク条件やセキュリティ用件が全く同じということは考えにくく、それらを意識した上でマルチクラウド間の接続を実現する必要が出て来ることも考えられます。Secure Gatewayならこれらの課題をクリアするセキュアな接続が実現できます。その方法について本ブログで紹介します。

背景

マルチクラウド環境を利用していると、多くのケースでこのようなことを実現したくなることもあるでしょう：

▲図1 マルチクラウド間のセキュア接続

１つのクラウドはいわゆる「パブリッククラウド環境」として利用し、別のクラウドは「プライベートクラウド環境」として利用するようなケースです（後者は「オンプレミスの社内ネットワーク」を想定していただいても構いません）。この２つの環境ではネットワーク要件やセキュリティ要件は全く異なっているのですが、パブリックネットワーク側からプライベートネットワーク内のデータを利用したい（実際ありますよね）、という要件が出てきたようなケースです。

このようなケースでは「プライベートネットワーク内のデータを、どこまでセキュアな状態で／どれだけ他の環境に影響を与えずに／どれだけ簡単にパブリックネットワークのサーバーから接続させるか？」が鍵となります。今回は IBM Bluemix環境（パブリックネットワークと想定）と IDCF クラウド環境（プライベートネットワークと想定）を使い、この２つのネットワーク間を IBM Secure Gatewayでセキュアに接続する、という方法とその実現手順を紹介します：

▲図2 IBM Secure Gatewayによるセキュア接続イメージ

準備

• IDCF クラウドのアカウント、および IBM Bluemix のアカウント

• IDCF クラウド内の仮想サーバーインスタンス（グローバルIPアドレスは不要）

• IBM Bluemix 内の PHP ランタイム（PHP でなくてもよいが、今回は PHP でサンプルアプリを用意）

２つの環境内にそれぞれサーバーが用意されている、という状態になっている所までが準備されているものとします(図3)：

▲図3 両ネットワークに仮想マシン準備

Secure Gateway

今回は IBM Bluemix の Secure Gatewayサービスを使います。Secure Gateway は２つの異なるネットワーク間のデータおよびアプリケーションをセキュアに接続するトンネリングサービスです。特に IBM Bluemix で SaaS として用意されている Secure Gateway サービスには以下の特徴があります：

• IBM Bluemix 上のアプリケーションとプライベートネットワーク内との通信を簡単に実現

• トンネリング実現のための特別なハードウェアを用意する必要はなく、docker 環境または専用のソフトウェアをプライベートネットワーク内に用意するだけ

• プライベートネットワーク内の接続先（IPアドレス＋ポート番号）が１つであればSecure Gatewayサービスが無料で使える

環境設定手順

プライベートネットワーク（IDCF クラウド）側で docker 環境を用意

まずは IDCF クラウド内に 「プライベートネットワーク内のサーバー」に相当する仮想マシンを用意します。プライベートネットワーク想定なので、グローバル IP アドレスは 不要 です（light.S1 プランなら 500 円／月で作れます）。この例では個人的に使い慣れた CentOS 6 のサーバーを作りました：

▲図4 IDCFクラウドコンソール 仮想マシン詳細画面

IDCF クラウドの場合、Web画面からコンソールにアクセスしてコマンドを実行できる、という便利な機能が用意されています（これを使えば SSH などを使う必要もなく、グローバル IP アドレスがなくてもコマンドラインアクセスが可能になります）。今回の環境設定等はこのコンソールを使うことにします(図5)：

▲図5 仮想マシン コンソールアクセス

こんな感じの画面(図6)が現れるので、ログインします。なお、ここで使用するパスワードは仮想マシン作成時にログインしているユーザーのメールアドレスに送付されるものを使います。：

▲図6 Webコンソール画面

普通に root でログインしちゃいました。良い子はマネしちゃだめよ：

▲図7 Webコンソール ログイン時

ここでネットワーク環境についてあらためて確認しておきます。 Secure Gateway をインストールする際には docker 環境または専用のソフトウェアがインストールされたサーバーがプライベートネットワーク内に必要になります（今回は前者を想定）。 またプライベートネットワーク上の１つのデータベースサーバーに対する外部からのセキュアな接続を実現する方法を紹介するのですが、今回はこのプライベートネットワークを１台のマシンで実現します。つまり docker 環境とデータベースサーバーを同じ仮想マシン上に構築します。

外部ネットワークからの接続先データベースが複数あるようなケース（この場合は有償版 Secure Gateway で対応）だったり、そもそも docker 環境とデータベース環境を分けて構築するようなケースで応用することも可能です。ただしその場合は docker の仮想マシンからデータベースに接続できるようなセキュリティ設定があらかじめなされていることが前提となることをご注意ください。

というわけで、改めて docker 環境を用意します（ちなみに CentOS 6.x の場合、6.6 以上である必要があります。また docker 1.8 以上は公式には CentOS 6.x では非サポート環境となるので、docker 1.7 を使うことになります）。こんな感じのコマンドを実行して docker 環境をインストール＆起動します：

# yum -y --enablerepo=remi,epel,rpmforge install docker-io
# service docker start

▲図8 Webコンソール Docker起動

同様にしてプライベートネットワーク内にデータベースサーバーを構築します。今回は MySQL を使うことにします（ポート番号は3306）。今回は docker と同じ仮想マシン上に作成しますが、（docker の仮想マシンからアクセスできるサーバー上であれば）どこにあっても構いません。以下のコマンド等を実行して、MySQL サーバーが実際に動いている状態にします：

# yum -y install mysql-server
# service mysqld start

テーブルやデータ、ユーザーは適当に作っておきます。ただしこのユーザーは docker 環境からアクセスできる必要があります。MySQL と docker が異なる環境となる場合は外部接続を許可するよう設定しておいてください。

パブリックネットワーク（IBM Bluemix）側で Secure Gateway サービスをインスタンス化

次に IBM Bluemix 側で Secure Gateway サービスをインスタンス化します。まだアカウントをお持ちでない場合は 30 日間無料トライアルにお申込みください。

アカウントをお持ちの場合は IBM Bluemix にログイン後、カタログ一覧画面から Secure Gatewayサービスを検索して選択します：

▲図9 IBM Bluemixカタログ一覧

そしてプランを選択して「作成」します。"Essentials"プランであれば、接続先が１つに限られてしまい、通信量は月500MBまでとなりますが無料で提供されているサービスです（今回のケースはこれでもOKです）：

▲図10 Essentialsプラン

作成後にダッシュボード画面を見ると “Secure Gateway-XX” と書かれたサービスがインスタンス化されていることが分かります。これをクリックして管理画面に移動します(図11)：

▲図11 ダッシュボード画面

このような画面が表示されればパブリックネットワーク（IBM Bluemix）側の Secure Gateway は準備できたことになります。 ただ、この時点ではまだトンネリングの接続先がまだ存在していない、以下のような状態です(図12)：

▲図12 IBM Bluesmix側 Secure Gateway準備

このまま続けてプライベートネットワーク（IDCF クラウド）側にも Secure Gateway クライアントを用意する手順に進むため、画面内の＋マークをクリックします：

▲図13 Secure Gatewayダッシュボード

「ゲートウェイの追加」画面にて接続先を定義します。ここではとりあえず名称（図では「クララのゲートウェイ」）、セキュリティトークンの有無と期限を設定（図では使用せず）し、「ゲートウェイの追加」ボタンをクリックします：

▲図14 ゲートウェイ追加手続画面

「クララのゲートウェイ」という接続先が定義できました。この時点ではまだ実際の接続先が用意されていないので切断されています（図15：右上が赤くなっている）： 最後に接続先を設定するための方法を確認しましょう。画面内の「クライアントの接続」と書かれた部分をクリックします：

▲図15 クライアントの接続

Secure Gateway をプライベートネットワーク側に導入する場合の手順が表示されます。 実際には３種類の方法で導入することができます（図の左から専用クライアントアプリ／docker イメージ／専用ハードウェア）。今回は docker を使うので docker アイコンをクリックし、その手順を確認します。 この Secure Gateway と接続するために docker 環境上で実行するコマンドが表示されるので、この内容をメモしておきます(図16)：

▲図16 Secure Gateway接続方法

プライベートネットワーク（IDCF クラウド）側で Secure Gateway クライアントを導入

ここからはあらためてプライベートネットワーク側での作業になります。先程表示されたコマンドを docker 環境で実行します。

（注）実際にはホストモードで実行しないと接続できないケースがあるようなので、先程の画面に表示されたメッセージに --host=netというオプションを追加して実行します。

初回のみ Secure Gateway のイメージがダウンロードされ、docker コンテナ上で実行され、コマンド待ちの状態で Secure Gateway が起動します：

▲図17 Secure Gateway起動画面

この時点でプライベートネットワーク側にも Secure Gateway のインスタンスが用意できました：

▲図18 プライベートネットワーク側 Secure Gateway準備

なお、この時点で IBM Bluemix 内の Secure Gateway サービス画面を確認すると、右上の先程まで赤くなっていた部分が緑色に変わり、クライアントとの接続ができたことが分かります。ここまで確認できたら Bluemix 側の Secure Gateway 画面は閉じてしまっても構いません（図19：右上の×をクリック）：

▲図19 Secure Gatewayサービス画面

この時点でパブリックネットワークの Secure Gateway と、プライベートネットワークの Secure Gateway とが接続できている状態になりました。ただ実際のデータベースサーバーとはまだ繋がっていません。最後にそのための設定を行います。

まず、docker 上で稼働している Secure Gateway の Worker ID を確認します。Secure Gateway のコマンドで “L”を実行し Worker ID （図20では 1）を確認します：

▲図20 Worker ID確認

Worker ID がわかったら、アクセスを許可するリソースを IP アドレスとポート番号、そして Worker ID のセットで “A”コマンドで指定します。今回は MySQL サーバーへのアクセスを許可するので、以下のようなコマンドを実行します：

> A （MySQL サーバーのIPアドレス）:3306 1

（注） MySQL サーバーが docker 環境と異なるホストの場合は、MySQL サーバーの設定で docker ホストからのリモート接続を許可するような設定が別途必要です。

▲図21 MySQLへのアクセス許可

これでパブリックネットワーク（IBM Bluemix）とプライベートネットワーク（IDCF クラウド）とが Secure Gateway を介して接続され、パブリックネットワーク側からプライベートネットワーク内の MySQL サーバーへの接続が許可された状態になりました。

パブリックネットワーク（IBM Bluemix）側からプライベートネットワーク（IDCF クラウド）のデータベースにアクセスする

ここまでの手順でパブリックネットワーク側からプライベートネットワーク内の MySQL サーバーにアクセスを許可する設定が完了しました（この時点では許可までが完了しただけであって、まだ接続設定はできていない）。では最後にパブリックネットワーク側からプライベートネットワーク内の MySQL サーバーに接続する設定を行います。

再度 IBM Bluemix のダッシュボード画面から Secure Gateway サービスの管理画面を開き、宛先タブの＋印をクリックします：

▲図22 Secure Gatewayサービス画面

今回はパブリックネットワークのクラウドから、プライベートネットワーク（オンプレミス）ネットワーク内の MySQL へのアクセスを行いたいので、リソースはオンプレミス側にあることになります。というわけでリソースの場所に「オンプレミス」を指定します：

▲図23 リソース選択

オンプレミス側の MySQL リソースの IP アドレスとポート番号を指定します。ここで指定する IP アドレスは当然プライベートネットワーク内の IP アドレスになります：

▲図24 宛先ホスト、ポート設定

通信プロトコルを指定します。今回は MySQL のネイティブプロトコルで、特に認証も行わないので “TCP”を選択します：

▲図25 通信プロトコル選択

認証の種類を指定します（今回は “None"）：

▲図26 宛先での認証方法選択

更にリクエスト元の IP アドレスを絞る場合はこの画面で指定します（今回は空白のまま）：

▲図27 リクエスト元IPアドレス指定

最後にこの接続に名前（下図では「プライベート MySQL」）を付けて「宛先の追加」をクリックします：

▲図28 宛先追加

ここまでの手順で、プライベートネットワーク内の MySQL に接続するための設定が完了しました：

▲図2 IBM Secure Gatewayによるセキュア接続イメージ(再掲)

管理画面にも宛先が追加されています。 この宛先の右下にある歯車部分をクリックします(図29)：

▲図29 Secure Gateway管理画面

するとこのようなダイアログが表示されます(図30)。 クラウド・ホスト：ポートと書かれた部分に注目してください。これが パブリッククラウド(IBM Bluemix)側からみた MySQL サーバーの接続先となる情報です：

▲図30 MySQLサーバー接続先情報

接続アプリを作ってパブリックネットワーク上で動かす

あとは上記で作成した環境を使ったアプリケーションをパブリックネットワーク上の（IBM Bluemix 上の）サーバーで実行するだけです。試しにこんな PHP アプリを作って、サーバー上に配置してみました：

▲図31 構築したマルチクラウド間のセキュア接続

<?php

// プライベートMySQLへの接続
$hostname = 'XXXXX.integration.ibmcloud.com';
$port = NNNNN;
$dbname = 'mydb';
$username = 'username';
$password = 'password';


// ここは編集不要
$dsn = 'mysql:dbname='.$dbname.';host='.$hostname.';port='.$port;
?>


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html> 
<head> 
<title>MySQL 接続テスト</title> 

<meta http-equiv="viewport" content="width=device-width, initial-scale=1" />
<meta http-equiv="apple-mobile-web-app-capable" content="yes" />
</head> 
<body> 
  <h1>MySQL 接続テスト</h1>
  <br/>
  <table border="1">
  <tr><th>#</th><th>名前</th><th>年齢</th></tr>

<?php
try{
  $dbh = new PDO( $dsn, $username, $password );
  if( $dbh != null ){
    $sql = "select id, name, age from people order by id limit 10";
    $stmt = $dbh->query( $sql );
    while( $row = $stmt -> fetch( PDO::FETCH_ASSOC ) ){
      $id = $row['id'];
      $name = $row['name'];
      $age = $row['age'];
        
      $tr = "<tr><td>" . $id . "</td>"
          . "<td>" . $name . "</td>"
          . "<td>" . $age . "</td></tr>\n";
      echo $tr;
    }
    
    $dbh = null;
  }
}catch( PDOException $e ){
  print( 'Error: ' . $e->getMessage() );
  die();
}
?>
</table>
</body>
</html>

このアプリケーションにアクセスするとこのようになります(図32)。無事にパブリックネットワーク上のアプリケーションから、プライベートネットワーク内の MySQL データベースサーバーにアクセスして動いていることがわかります：

▲図32 MySQL接続確認

感想

パブリックネットワークとプライベートネットワークとの間をセキュアで簡単に接続できる Secure Gateway を紹介し、実際に接続環境を作るまでを説明しました。 今回の紹介の中では専用のハードウェアやトンネリングのための設定を用意する必要もなく、ファイアウォールを通す必要もなく、そしてプライベートネットワーク側にはグローバル IP アドレスも用意していないことを改めて思い出してください。 そうして作成したプライベートネットワーク内の MySQL サーバーにここで書かれている情報を使ってセキュアにアクセスできるようになっている、ということを意味しています。

今回は IBM Bluemix と IDCF クラウドという２つの異なるネットワークの間をセキュアに接続する、というケースで紹介しましたが、この Secure Gateway を使えば同様のトンネリングネットワークを簡単に作成することができます。 マルチクラウド時代における、クラウドネットワーク間の接続ツールとして紹介させていただきました。

この記事を作成するにあたり、IDCF クラウドを「プライベートクラウド環境」と位置付けて紹介させていただきました。他の多くのクラウドベンダー環境と異なり、専用のWebコンソールが用意されていることで、グローバルIPアドレスを付与したり、SSHなどを利用することなく外部からホストにアクセスして利用することができました。プライベートネットワークを実現したり、あるいはプライベートネットワークをエミュレートする環境として非常にユニークであり、簡単でかつ使いやすいと感じました。

今回紹介したメイン機能である Secure Gateway は IBM Bluemix からは SaaS として提供しており、これを各クラウドから外部利用いただくことも可能ですが、「自分のクラウド環境の中に Secure Gateway インスタンスを作りたい」という要望もあると思います。その場合はソフトウェア製品版である WebSphere CastIronをお使いください。

こんにちは。UX開発部　ディベロップメントグループの品川と申します。
IDCFクラウドのサービス立ち上げ期から、主にフロントエンド（たまにバックエンド）を担当してます。

htmlでtable表記をする際になにかと便利なのがdatatablesですよね。IDCFクラウドのサービスサイト内でも頻繁に実装されているjqueryの追加ライブラリですが、最近、サイト内のリファクタリングを進めることになりまして、今いろいろな箇所を見直しています。 見直しの際、せっかくだからBootstrap4をベースに使ってみようと思い 元サイトを見てみたら bootstrap4 用のcssとjsが用意されているじゃありませんか！！こんな便利なのに、より使いやすくなるなんて！これはもう記事にするしかなし！！！

ということで、今回はdatatablesをbootstrap4ベースで利用してみようというお話です。実質 15分程度でステキな高機能テーブルができました。が、少しだけハマったところがあったので注意点も含めてまとめたいと思います。

前提

• 全ての外部ファイル(CSS,JS)は CDNを利用する。
• スタイルやデザインは一切いじらない。
• datatablesのロケールは日本語にする。(datatablesのプラグイン設定を使う。)
• jqueryは 3.2.1を使用する。(ちゃんとdatatablesの手前で宣言しておいてね。)

DataTablesってなに？

一応datatables知らないよって人のために簡単にdatatablesの機能を簡単にまとめてみます。
一言でいうとtableにポピュラーな機能を付加してくれるステキなjqueryの拡張機能です。

• tableタグそのものに手を加える必要がない。
• jqueryのID指定 #("table").datatable();をするだけで次の機能が付加される。
• 自動的に付加される機能
  • ページネーション
  • 表示件数の変更
  • カラムソート
  • 部分検索

ということで実際に実装してみましょう。

bootstrap4、jQuery3の宣言

2017/11時点ではまだbeta版ですが気にせず使っていきましょう。
bootstrap本家サイトに書いてあるとおりに宣言します。

<linkrel="stylesheet"href="//maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/css/bootstrap.min.css"integrity="sha384-PsH8R72JQ3SOdhVi3uxftmaW6Vc51MKb0q5P2rRUpPvrszuE4W1povHYgTpBfshb"crossorigin="anonymous">

jsの宣言は </body>の手前に。

<scriptsrc="https://code.jquery.com/jquery-3.2.1.slim.min.js"integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN"crossorigin="anonymous"></script><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.3/umd/popper.min.js"integrity="sha384-vFJXuSJphROIrBnz7yo7oB41mKfc8JzQZiCq4NCceLEaO4IHwicKwpJf9c9IpFgh"crossorigin="anonymous"></script><scriptsrc="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/js/bootstrap.min.js"integrity="sha384-alpBpkh1PFOepccYVYDB4do5UnbKysX5WZXm3XxPqe5iKTfUKjNkCk9SaVuEZflJ"crossorigin="anonymous"></script>

datatablesの宣言

準備が整ったので、datatablesの宣言をします。
datatablesのサイトにアクセスし、CDNのページに遷移します。
bootstrap4のトグルボタンを押下して選択したら、その下にあるRelease部分のソースをコピペします。
※宣言はbootstrap4,jQuery3の後にそれぞれ追加してください。

<linkrel="stylesheet"href="https://cdn.datatables.net/1.10.16/css/dataTables.bootstrap4.min.css"/>

<scriptsrc="//cdn.datatables.net/1.10.16/js/jquery.dataTables.min.js"></script><scriptsrc="//cdn.datatables.net/1.10.16/js/dataTables.bootstrap4.min.js"></script>

datatablesの日本語化

全ての宣言を終えたらちょっとだけカスタマイズします。

<script>$(function(){// datatableの設定を変更$("#table1").DataTable({"language":{"url":"//cdn.datatables.net/plug-ins/1.10.16/i18n/Japanese.json"}});});</script>

table属性を記述する。

上記全てが完了したらtableタグを書きます。

<tableid="table1"class="table table-bordered"><thead><tr><th>No</th><th>氏名</th><th>メールアドレス</th></tr></thead><tbody><tr><td>1</td><td>ほげほげ太郎</td><td>hogehoge@example.com</td></tr><tr><td>2</td><td>ほげふが次郎</td><td>hogefuga@example.com</td></tr></tbody></table>

ハマった点

これでもう完成！と思いブラウザで表示させてみたら・・・あれ？テーブル表示以外何にも出ない・・・
デバッガツールのコンソールを見てみたら次のエラーが。

TypeError: $.ajax is not a function

ajaxなんて使ってないのに・・・と思ったのですが、datatablesはajaxでデータのやり取りをする機能がデフォルトでついているので、jQueryの初期化で怒られてました。
何かいけないのか調べていたところ、jqueryの宣言を見ると・・・

jquery-3.2.1.slim.min.js

ん？ slim？
minは良いとしてslimってなんぞ？？

ググってみたところ、このslimっていうのは余分なjQueryの機能をそぎ落としてパフォーマンスを向上させている版でajax部分の記述がどうやらなくなっているらしいです。

参考にさせて頂いたサイト
TypeError: $.ajax is not a function エラーが出た時の対策(jQuery 3.x)

ということで、改めてjQueryCDNのサイトからslimじゃないバージョンの宣言をコピペします。

<scriptsrc="https://code.jquery.com/jquery-3.2.1.slim.min.js"integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN"crossorigin="anonymous"></script>

↓

<scriptsrc="//code.jquery.com/jquery-3.2.1.min.js"integrity="sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4="crossorigin="anonymous"></script>

おぉ、できた！！

完成

完成形のソースは次のとおりです。そのままコピペして頂ければローカル環境でも見られると思います。

<!DOCTYPE html><htmllang="en"><head><metacharset="UTF-8"><title>datatebles site</title><metaname="viewport"content="width=device-width, initial-scale=1, shrink-to-fit=no"><!-- Latest compiled and minified CSS --><linkrel="stylesheet"href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/css/bootstrap.min.css"integrity="sha384-PsH8R72JQ3SOdhVi3uxftmaW6Vc51MKb0q5P2rRUpPvrszuE4W1povHYgTpBfshb"crossorigin="anonymous"><!--  datatables css --><linkrel="stylesheet"href="https://cdn.datatables.net/1.10.16/css/dataTables.bootstrap4.min.css"/></head><body><divclass="container"><divclass="col-xs-12"><tableid="table1"class="table table-bordered"><thead><tr><th>No</th><th>氏名</th><th>メールアドレス</th></tr></thead><tbody><tr><td>1</td><td>ほげほげ太郎</td><td>hogehoge@example.com</td></tr><tr><td>2</td><td>ほげふが次郎</td><td>hogefuga@example.com</td></tr></tbody></table></div></div><!-- jQuery first, then Popper.js, then Bootstrap JS --><scriptsrc="https://code.jquery.com/jquery-3.2.1.min.js"integrity="sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4="crossorigin="anonymous"></script><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.3/umd/popper.min.js"integrity="sha384-vFJXuSJphROIrBnz7yo7oB41mKfc8JzQZiCq4NCceLEaO4IHwicKwpJf9c9IpFgh"crossorigin="anonymous"></script><scriptsrc="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/js/bootstrap.min.js"integrity="sha384-alpBpkh1PFOepccYVYDB4do5UnbKysX5WZXm3XxPqe5iKTfUKjNkCk9SaVuEZflJ"crossorigin="anonymous"></script><!--  datatables js --><scriptsrc="https://cdn.datatables.net/1.10.16/js/jquery.dataTables.min.js"></script><scriptsrc="https://cdn.datatables.net/1.10.16/js/dataTables.bootstrap4.min.js"></script><script>$(function(){// datatableの設定を変更$("#table1").DataTable({"language":{"url":"//cdn.datatables.net/plug-ins/1.10.16/i18n/Japanese.json"}});});</script></body></html>

以上です。
html1枚ペラで15分程度でこのクオリティ！
もちろんこの後はajaxでバックエンドと通信したり、実際のレコード部分はレスポンスデータを流し込んだりしますが、ガワを爆速で用意できるのは素晴らしいですね。

datatablesは高機能なので色々とカスタマイズしてみると良いと思います。

こんにちは、UX開発部の橋口です。

今回は、CloudStackのクライアントの１つである、CloudMonkeyを紹介します。

CloudMonkeyはCloudStackを操作するためのCLIツールです。 IDCFクラウドはCloudStackをベースに構成されているため、とても親和性の高いツールになっています。

IDCF Cloud CLIもリリースされましたが、それぞれのCLIツールの良い点を活かして使い分けて便利にご利用いただければと思います。

• 便利なポイント
• インストール方法
  • Mac
  • RHEL/CentOS
  • Ubuntu/Debian
• 初期設定
• 使い方(対話モード)
  • デフォルトの出力
  • jsonでの出力
  • テーブル出力
• 嬉しい機能
  • tab補完
    • 引数の候補
    • 値の候補
  • エラー出力

便利なポイント

• CLIだけではなく、対話モードがある
• 設定値をプロファイルとして持つことができ、簡単に切り替えが可能
• 非同期ジョブの結果を待って出力が可能
• tab補完ができる
• Ctrl+Rでbashと同じように履歴からコマンドを実行できる
• 表形式、JSON形式をサポート
• 結果を色付けして表示できる
• Unicodeのサポート

インストール方法

インストールはとても簡単(ただし、Windowsにインストールするのは手順が多いので今回は紹介しません）。 Python2系が入っていない場合は別途インストールする必要があります。

Mac

$ sudo easy_install cloudmonkey

RHEL/CentOS

$ sudo yum install python-setuptools
$ sudo easy_install cloudmonkey

Ubuntu/Debian

$ sudo apt-get install python-pip
$ sudo pip install cloudmonkey

初期設定

set profileでプロファイルの切り替えができます(存在しない場合は新規作成)。
設定は ~/.cloudmonkey/configに保存されます。

$ cloudmonkey
(local) 🐵 > set profile idcf-east-1
(idcf-east-1) 🐵 > set url  https://compute.jp-east.idcfcloud.com/client/api
(idcf-east-1) 🐵 > set apikey ---apikey---
(idcf-east-1) 🐵 > set secretkey ---secretkey---

使い方(対話モード)

ゾーン一覧のAPIを使って、いろいろな出力を試してみました。

デフォルトの出力

(idcf-east-1) 🐵 > list zones
count = 6
zone:
name = tesla
id = a117e75f-d02e-4074-806d-889c61261394
allocationstate = Enabled
dhcpprovider = VirtualRouter
localstorageenabled = True
networktype = Advanced
resourcedetails:
pool.storage.capacity.disablethreshold = 0.85
securitygroupsenabled = False
tags:
zonetoken = bbbd8944-a3c5-3538-8a2a-71d93a788ab5
================================================================================
※※※中略※※※
================================================================================
name = newton
id = 01738d49-2722-4788-891e-848536663c6e
allocationstate = Enabled
dhcpprovider = VirtualRouter
localstorageenabled = True
networktype = Advanced
resourcedetails:
pool.storage.capacity.disablethreshold = 0.85
securitygroupsenabled = False
tags:
zonetoken = 29683cbb-b762-3bae-b5fb-1d50333dd0ef

jsonでの出力

jqなどと組み合わせて使うと簡単に処理がかけます。

(idcf-east-1) 🐵 > set display json
(idcf-east-1) 🐵 > list zones
{
  "count": 6,
  "zone": [
    {
      "allocationstate": "Enabled",
      "dhcpprovider": "VirtualRouter",
      "id": "a117e75f-d02e-4074-806d-889c61261394",
      "localstorageenabled": true,
      "name": "tesla",
      "networktype": "Advanced",
      "resourcedetails": {
        "pool.storage.capacity.disablethreshold": "0.85"
      },
      "securitygroupsenabled": false,
      "tags": [],
      "zonetoken": "bbbd8944-a3c5-3538-8a2a-71d93a788ab5"
    },
※※※中略※※※
    {
      "allocationstate": "Enabled",
      "dhcpprovider": "VirtualRouter",
      "id": "01738d49-2722-4788-891e-848536663c6e",
      "localstorageenabled": true,
      "name": "newton",
      "networktype": "Advanced",
      "resourcedetails": {
        "pool.storage.capacity.disablethreshold": "0.85"
      },
      "securitygroupsenabled": false,
      "tags": [],
      "zonetoken": "29683cbb-b762-3bae-b5fb-1d50333dd0ef"
    }
  ]
}

例えば、追加IPアドレスを全ゾーンから削除したい時はこのような形で書くことができます。

(idcf-east-1) 🐵 > list publicipaddresses filter=id issourcenat=false | jq -r '.publicipaddress[].id' | xargs -L1 -IUUID cloudmonkey disassociate ipaddress id=UUID

テーブル出力

filterで表示するフィールドを選択したり、パイプでつなぐとgrepなどもできます。

(idcf-east-1) 🐵 > set display table
(idcf-east-1) 🐵 > list zones filter=id,name
count = 6
zone:
+--------+--------------------------------------+
|  name  |                  id                  |
+--------+--------------------------------------+
| tesla  | a117e75f-d02e-4074-806d-889c61261394 |
| henry  | 9703cdbb-aee7-41ba-ba80-4807eaa68b80 |
| pascal | f0954b9b-2626-4549-82ad-ca421073b3bc |
| joule  | baf86a6e-4e3b-428e-8fd0-7fda43e468d4 |
| radian | a53ff3d3-042b-4cbd-ad16-494bb8d33e06 |
| newton | 01738d49-2722-4788-891e-848536663c6e |
+--------+--------------------------------------+
(idcf-east-1) 🐵 > list zones filter=id,name | grep tesla
| tesla  | a117e75f-d02e-4074-806d-889c61261394 |

嬉しい機能

tab補完

引数の候補

VM作成コマンドです。一部非対応のオプションもありますが、かなり便利です。

(idcf-east-1) 🐵 > deploy virtualmachine
account=            deploymentplanner=  displayvm=          hostid=             iptonetworklist=    networkids=         securitygroupnames= templateid=
affinitygroupids=   details=            domainid=           hypervisor=         keyboard=           projectid=          serviceofferingid=  userdata=
affinitygroupnames= diskofferingid=     filter=             ip6address=         keypair=            rootdisksize=       size=               zoneid=
customid=           displayname=        group=              ipaddress=          name=               securitygroupids=   startvm=

値の候補

テンプレートなどの補完は都度問い合わせるので、少し遅いです。

(idcf-east-1) 🐵 > deploy virtualmachine zoneid=
9703cdbb-aee7-41ba-ba80-4807eaa68b80 henry
baf86a6e-4e3b-428e-8fd0-7fda43e468d4 joule
01738d49-2722-4788-891e-848536663c6e newton
f0954b9b-2626-4549-82ad-ca421073b3bc pascal
a53ff3d3-042b-4cbd-ad16-494bb8d33e06 radian
a117e75f-d02e-4074-806d-889c61261394 tesla

01738d49-2722-4788-891e-848536663c6e  a117e75f-d02e-4074-806d-889c61261394  baf86a6e-4e3b-428e-8fd0-7fda43e468d4
9703cdbb-aee7-41ba-ba80-4807eaa68b80  a53ff3d3-042b-4cbd-ad16-494bb8d33e06  f0954b9b-2626-4549-82ad-ca421073b3bc

エラー出力

引数不足時のエラーがわかりやすいです。

(idcf-east-1) 🐵 > deploy virtualmachine
Missing arguments: zoneid serviceofferingid templateid

IDCFクラウドでは、今後も便利なライブラリや、IDCFクラウドCLIなどの統合CLIツールを開発してまいりますので、お楽しみに。 APIからのみ操作できる機能もありますので、みなさまも便利で楽なツールをつかって、良いAPIライフをお送りください。

＜IDCFクラウド便利ツールの関連記事＞

■idcfcloud-cliをリリース！ - IDCF テックブログ

■idcfcloud-cliがアップデート！新機能を紹介 - IDCF テックブログ

■IDCFクラウド APIを利用した仮想マシンの作成からSSH接続まで - IDCF テックブログ

こんにちは、UX開発部の橋口です。

Webサービスを運用する上で、DNSの管理は必須ですよね。 大量に管理しているDNSのゾーンやレコードの設定を、1つ1つ手動でやるのはかなり時間がかかります。既に、PythonやRubyからAPIを操作し、DNSの管理を自動化されている方も多いと思います。
今回は、idcf/clientを用いてPHPでIDCFクラウドDNS/GSLBのAPIを使う方法をご紹介します。

idcf/clientとは

※idcf/clientは、橋口個人が作成した非公式のツールです。IDCフロンティアのサポートおよび動作保障はございませんのであらかじめご了承ください。

idcf/clientは、REST APIのPHP用クライアントです。現在、IDCFが提供している次のサービスのAPIに対応しています。

• コンピューティング
• IDCFクラウド DNS/GSLB
• インフィニットLB
• コンテンツキャッシュ
• ビリング

不具合を発見した場合はこちらからissueを起票していただければ幸いです。

機能はシグネチャーを計算してリクエストを送るだけととてもシンプルです。使用したサービスのAPIドキュメントを参考に、メソッドやパスを設定します。
説明するより試してみたほうが早いので、実際にインストールし使っていきたいと思います。

IDCFクラウドDNS/GSLBのAPIドキュメントはこちら

インストール

PHPのパッケージ管理ツールであるcomposerを使ってライブラリをインストールします（composerについての説明は割愛します）。

$ composer require idcf/client
Using version ^0.0.1 for idcf/client
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing idcf/client (v0.0.1): Downloading (100%)
Writing lock file
Generating autoload files

オブジェクトの作成

インストールが完了したら、はじめにクライアントのオブジェクトを作成します。
API KeyとSecret KeyはIDCFクラウド コンソールからご確認ください。

<?phprequire_once"vendor/autoload.php";
$api_key="";
$secret_key="";
$client=new \Idcf\Client\Dns($api_key, $secret_key);

これで、IDCFクラウド DNS/GSLBを使う準備ができました！

ゾーンの操作

ここからは、ゾーンの操作をご紹介いたします。ゾーン操作では、一覧取得、作成と削除、更新もできます。 紹介する操作では、ゾーン毎にユニークに割り当てられているzone_uuidを使用します。

ゾーン一覧の取得

$client->get("zones");

はじめはゾーンがないため、空の配列が返ります

array(0) {
}

ゾーンの作成

$params = array(
  "name" =>"example.com",
  "email" =>"postmaster@example.com",
  "description" =>"zone description",
  "default_ttl" => 3600
);
$client->post("zones", $params);

ゾーンの作成ができました。 IDCFクラウドDNS/GSLBでは、リソースの識別にUUIDを使用しているので、UUIDを指定して操作を実施します。 今回作成したゾーンのUUIDは e374628a-9f4a-40e7-b5c9-9299590d454cとなっています。

object(stdClass)#2 (8) {
  ["uuid"]=>
  string(36) "e374628a-9f4a-40e7-b5c9-9299590d454c"
  ["name"]=>
  string(11) "example.com"
  ### 中略 ###
}

ゾーン認証情報の取得

$zone_uuid = "";
$client->get("zones/${zone_uuid}/token");

IDCFクラウドDNS/GSLBでは、ゾーン認証が必要となっていますので、認証レコードを新規の場合はNSレコードを委譲元に、移行などの場合はTXTレコードを現用のゾーンに記載します。

object(stdClass)#2 (2) {
  ["TXT"]=>
  array(1) {
    [0]=>
    string(47) "idcf-dns-token=0123456789abcdef0123456789abcdef"
  }
  ### 中略 ###
}

ゾーンの認証

$zone_uuid = "";
$client->post("zones/${zone_uuid}/verify");

認証に成功すると空のオブジェクトが返ります。

object(stdClass)#2 (0) {
}

認証に成功したら実際に名前解決ができるか試してみましょう。 TXTレコードで認証している場合はDNSサーバーを指定して、名前解決ができるか試験してから移行すると事故が未然に防げます！！

$ dig soa example.com @ns01.idcfcloud.com

; <<>> DiG 9.8.3-P1 <<>> soa example.com @ns01.idcfcloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30941
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;example.com.           IN  SOA

;; ANSWER SECTION:
example.com.        3600    IN  SOA ns01.idcfcloud.com. postmaster.example.com. 1 10800 3600 604800 3600

### 略 ###

ゾーン作成後、更新・削除を行いたい場合は次の通り実行可能です。

ゾーンの更新

$zone_uuid = "";
$params = array(
  "description" =>"zone description",
  "default_ttl" => 3600
);
$client->put("zones/${zone_uuid}", $params);

ゾーンの削除

$zone_uuid = "";
$client->delete("zones/${zone_uuid}");

削除に成功すると空のオブジェクトが返ります。

object(stdClass)#2 (0) {
}

レコードの操作

続いて、レコードの操作をご紹介します。ゾーンの操作と同じく、一覧取得や作成削除、更新が可能です。 zone_uuid、record_uuidには、それぞれ操作したいゾーン・レコードにユニークに割り当てられているUUIDをセットしてください。

レコード一覧の取得

$zone_uuid = "";
$client->get("zones/${zone_uuid}/records");

レコードの作成

$zone_uuid = "";
$params = array(
  "name" =>"www.example.com",
  "type" =>"A",
  "content" =>"192.0.2.1",
  "ttl" => 3600
);
$client->post("zones/${zone_uuid}/records", $params);

object(stdClass)#7 (8) {
  ["uuid"]=>
  string(36) "c817a15d-4a90-424f-bd0c-e02366776f95"
  ["name"]=>
  string(15) "www.example.com"
  ### 中略 ###
}

登録ができたらdigをして確認してみましょう。

$ dig www.example.com @ns01.idcfcloud.com

; <<>> DiG 9.8.3-P1 <<>> www.example.com @ns01.idcfcloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21044
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.example.com.       IN  A

;; ANSWER SECTION:
www.example.com.    3600    IN  A   192.0.2.1

レコードの取得

$zone_uuid = "";
$record_uuid = "";
$client->get("zones/${zone_uuid}/records/${record_uuid}");

レコードの更新

$zone_uuid = "";
$record_uuid = "";
$params = array(
  "name" =>"www.example.com",
  "type" =>"A",
  "content" =>"192.0.2.1",
  "ttl" => 3600
);
$client->put("zones/${zone_uuid}/records/${record_uuid}", $params);

レコードの削除

$zone_uuid = "";
$record_uuid = "";
$client->delete("zones/${zone_uuid}/records/${record_uuid}");

削除に成功すると空のオブジェクトが返ります。

object(stdClass)#2 (0) {
}

エラー処理

予期しない事象が発生した場合は次のエラーを返します。
\Idcf\Client\Exception\ClientError : 通信に失敗している
\Idcf\Client\Exception\ServerError : ステータスコードが200番台以外
\Idcf\Client\Exception\DecodeError : JSONのデコードに失敗している

さいごに

今回は、idcf/clientを利用したIDCFクラウドDNS/GSLBのAPIを操作する方法をご紹介しました。 機会があれば、インフィニットLB・コンテンツキャッシュ・ビリングAPIの操作方法もご紹介したいと思います。
IDCFクラウドでは、ライブラリや、IDCFクラウドCLIなどの統合CLIツールを公開しています。 引き続きテックブログにて、お客様の自動化に役立つツールや情報をご紹介できればと思います！

こんにちは、永岡です。

今回は僕からidcfcloud-cliの話をします！
β版として実装されていたコンピューティングを1月30日についに正式リリースいたしました！本記事では追加された機能やcloudstack-apiとの違いについて紹介していきたいと思います。

idcfcloud-cliとはその名のとおり、IDCFクラウドをコマンドラインから操作するためのインターフェースです。今回のアップデートによりIDCFクラウドの主要なサービスにほぼ対応いたしました。これにより1つのコマンドでIDCFクラウドの複数サービスを操作・実行できるようになり、システム連携や管理の自動化などがより簡単に行える環境になりました！

インストールや初期設定、対応サービスの説明はこれまでのエントリーでご覧いただけます！

Ubuntu 16.04 環境
blog.idcf.jp
CentOS 7.x 環境
blog.idcf.jp
idcfcloud-cliアップデート第1弾！
blog.idcf.jp

既にインストール済みの方は、次のコマンドでアップデート可能です。

$ sudo gem update idcfcloud
$ sudo idcfcloud init

それでは、今回追加された機能について見ていきましょう！

• コンピューティングを試してみる
• cloudstack-apiからの変更点
  • コマンドよりコンフィグ設定が可能に
  • オプションの設定方法
    • 表示形式
    • メソッドパラメータへの入力方法
    • 非同期メソッドをCLI上は同期に
• 最後に

$ idcfcloud compute listZones -o table -f name,id
+--------+------------------------------------+
|name    |id                                  |
|augusta |bcb92d62-3d5a-47cf-aba2-01a012d3db07|
|monstera|66466a55-0bbc-45ad-a621-a06ffcdc81f8|
+--------+------------------------------------+

$ idcfcloud compute listServiceOfferings -o table -f displaytext,id
+------------------------------------------------+------------------------------------+
|displaytext                                                  |id        |
|1 CPU x 0.8 GHz / 1 GB RAM                      |b851997e-1c80-429c-9739-390e0a564989|
|1 CPU x 1.6 GHz / 2 GB RAM                      |2504abf9-5db6-45a4-bf58-aea02731010a|
|1 CPU x 2.4 GHz / 4 GB RAM                      |e9a38771-7569-4d7b-a3f9-5445edb5e423|
                                          ~中略~
|24 CPU x 2.5 GHz / 128 GB RAM - Dedicated HighIO|ed444cb7-a06e-49f2-bd39-8b2f125789ad|
|40 CPU x 2.6 GHz / 128 GB RAM - Dedicated HighIO|ef3d51af-f8fe-473a-ad1f-3681c4a62e61|
+------------------------------------------------+------------------------------------+

$  idcfcloud compute listTemplates '{"templatefilter":"featured"}' -o table -f name,id,zonename
+--------------------------------------------------------------------+------------------------------------+--------+
|name                                                                |id                                  |zonename|
|Windows Server 2016 Std + SQL2016 Std SP1                           |e667ba68-f88c-4c67-a115-0382a561a933|monstera|
|CentOS 7.4 64-bit                                                   |29fa0597-b476-45d7-85e2-71be350f155d|monstera|
以下略

$  idcfcloud compute listSSHKeyPairs -o table -f name
+---------+
|name     |
|cli-test |
+---------+

$ idcfcloud compute deployVirtualMachine '{"zoneid":bcb92d62-3d5a-47cf-aba2-01a012d3db07"","serviceofferingid":"b851997e-1c80-429c-9739-390e0a564989","templateid":"29fa0597-b476-45d7-85e2-71be350f155d","keypair":"cli-test","name":"morio"}'
{
  "status": 200,
  "message": "",
  "data": {
    "id": "72c3e278-e0f1-3352-9096-ace543039994",
    "name": "morio",
    "displayname": "morio",
以下略

$ idcfcloud compute listVirtualMachines -o table -f name,id,zonename
+-------+---------------------------------------------+
|name   |id                                  |zonename|
|morio  |97759930-ed0f-4dd0-a526-f913695c1a33|augusta |
+-------+---------------------------------------------+

初期設定：$ sudo idcfcloud init

変更：$ sudo idcfcloud configure

変更前：$ cloudstack-api <メソッド> -t name,id

変更後：$ idcfcloud compute <メソッド> -o table -f name,id

変更前：$ cloudstack-api listTemplates --templatefilter featured 

変更後：$ idcfcloud compute listTemplates '{"templatefilter":"featured"}' 

こんにちは、河合です。以前はIDCFクラウドDNS/GSLBのGSLB機能について紹介いたしました。振り返りになりますが、GSLBはDNSの名前解決を用いたロードバランシング機能です。ヘルスチェックや重み付けができるラウンドロビン方式による分散を実現します。 今月このGSLBの機能拡張がリリースされてCNAMEレコードにも対応可能となったので、それによりできるようになったことと活用事例をお伝えいたします！

関連記事
3ステップで導入！GSLBを使ってDR対策にトライ

CNAMEレコード対応でできること

これまではAレコードのみ分散対象として登録可能でした。そのため、たとえば図1のようなActive/Standby構成を実現したい場合は各環境のWebサーバー1台ずつに対してGSLBを設定していました。

▲図1 GSLBによるAレコード分散

example.comゾーン

gslb.example.com　IN　A　1.1.1.1　重み1
　　　　　　　　　　IN　A　1.1.1.2　重み1
　　　　　　　　　　IN　A　1.1.1.3　重み1
　　　　　　　　　　IN　A　2.2.2.1　重み0
　　　　　　　　　　IN　A　2.2.2.2　重み0
　　　　　　　　　　IN　A　2.2.2.3　重み0

今回の機能アップデートではCNAMEレコードに対しGSLB設定をすることができるようになりました。これによって、たとえばこれまで多くのリクエストをいただいていたILBやコンテンツキャッシュとの連携が可能となります(図2)。

▲図2 分散対象としてILBを登録

example.comゾーン

gslb.example.com　IN　CNAME　ilb1.idcfcloud.net　重み1
　　　　　　　　　　IN　CNAME　ilb2.idcfcloud.net　重み0

ドメインを直接指定できるようになったことでFQDN単位のサービスなどを分散先として登録可能になりました。実現したい構成に沿った、より柔軟な分散方法が選択できるようになりましたね！
実際のGSLB設定画面は図3のようになっています。Aレコードの設定時と同じ要領で、CNAMEレコードに対してもGSLBの「有効」を選択します。

▲図3 CNAMEレコード記述画面 GSLB有効化設定

そうするとFQDNの入力欄が表示されるので、プルダウン形式で任意のFQDNを選択します。ここで表示される選択肢は同一アカウント内で作成されているILBのFQDN・コンテンツキャッシュの独自ドメインとなります。もし別アカウントで作成しているILBやコンテンツキャッシュに分散したい場合はチケットからお問い合わせください。

また、オブジェクトストレージを直接指定することはできませんが、コンテンツキャッシュのオリジンサーバーとしてオブジェクトストレージを登録いただければ、連携させることが可能です。

重み付けに対する動作

GSLBでは重み付けラウンドロビンで分散を実現しているので、各レコードに対し0から10の重みを指定します。Aレコード/CNAMEレコードともに、通常時は重み0以外のレコードに対し設定された重み付けに従って応答します。重み付けがすべて0の場合、各レコードの応答仕様は次の通りとなります。
　■Aレコード：クエリに対し、すべてのレコードが応答
　■CNAMEレコード：クエリに対し、いずれかの１レコードが応答

ヘルスチェック動作

CNAMEレコードの場合、名前解決によって選択された1つのIPアドレスに対してヘルスチェックを行います。 その他の設定項目、挙動についてはこれまでのAレコードと同様となります。細かな仕様については次のFAQに掲載していますのでぜひご参照ください。
　FAQ - GSLBのヘルスチェック仕様

活用事例

上記ではIDCFクラウド上のサービス連携についてお話してきましたが、マルチクラウドでご利用のケースにもご活用いただけます。たとえばIDCFクラウドとAWSの併用でELBを利用している環境(図4)では、GSLBの分散先としてそれぞれのFQDNを登録します。
※セキュリティ上GSLBの分散先として登録できる範囲を同一アカウント内のILB・コンテンツキャッシュに絞っていますので、次のようなケースでご利用になる場合もチケットにてお問い合わせください。

▲図4 マルチクラウド環境例

example.comゾーン

gslb.example.com　IN　CNAME　ilb.idcfcloud.net　重み1
　　　　　　　　　　IN　CNAME　elb.aws.com　重み0

こうすることでマルチクラウド環境間でのActive/Activeの分散や、物理拠点を分けた分散による耐障害性の向上など自由度の高い構成が実現できます。みなさんの用途、要件に応じたご利用方法をぜひ検討してみてください。 なおDNSのルール上(RFC1912)、ホスト名なしのドメイン(ZoneApex)に対するCNAMEレコードは登録できませんのでご留意ください。

こんにちは、IDCFの藤城（@tafujish）です。久しぶりにブログを書きますが、今回はIDCFクラウドからだいぶ遠い話をします。

みなさんは、ロボカップ（RoboCup）という大会を聞いたことがあるでしょうか。「2050年までに、人間のサッカーのワールドチャンピオンチームに自律人型ロボットで勝つ」というランドマークプロジェクトを掲げ、毎年世界で開催されている、ロボットと人工知能(AI)の学術大会です。この世界大会が今年は7月27日から名古屋で開催されます。

https://www.robocup2017.org/www.robocup2017.org

人工知能を搭載した自律型ロボットを用いてサッカーで競い合うわけですが、ヒューマノイドリーグで毎年優秀な成績を収めており、今月の世界大会にも出場するのが、千葉工業大学のチーム「CIT Brains」です。ディープラーニングというキーワードから、CIT Brainsの皆さんと繋がり、今回の大会ではIDCFクラウドとしてもCIT Brainsを応援しています。
CIT Brainsでは、ボール認識にディープラーニングを使用しロボットに実装しています。このあたりの話を教えてもらい大変面白かったので、今回ご紹介いたします。

sites.google.com

おおまかなデータフローとしては下図の通りです。

それでは、ポイントごとに見ていきましょう。

こんにちは。Vuls Slackチーム辺りをうろうろしている、井上と申します。 MORIO Dojoは白帯のままです(そろそろ青帯になりたい)。 某SNSでは、脆弱性情報やセキュリティインシデントを追いかけています。

近年、セキュリティ業界でも「シフトレフト」が叫ばれています。 「テストなどの工程を、プロジェクトライフサイクルのより速い段階で実施する」というアプローチです。 セキュリティに関しても同様で、リリース前にテストをすることで、リリース後のセキュリティ対応負荷を軽減することができます。

今回は、WEBアプリケーションの依存ライブラリの脆弱性を検査する OWASP Dependency Checkを利用して、WEBアプリケーションリリースのシフトレフト、を目指します。

OWASP Dependency Checkとは

OWASPとは、2015年の資料によると以下のように説明されています。

OWASPは、「The Open Web Application Security Project」の略称であり Webアプリケーションのセキュリティ向上や、セキュアなWebサービスの展開を目的として 2001年12月01日に設立されたグローバルなオープンなコミュニティです。 現在、世界198ヶ国ローカルチャプター(現地支部)があり、43,000人以上の メーリングリスト参加者が様々なプロジェクトに参加しています。

そのOWASPから、プロジェクトの依存関係から既知の脆弱性がないかをチェックするユーティリティとして Dependency Checkが公開されています。Javaと.NETがサポートされており、部分的に Ruby, Node.js, Python, C/C+(autoconf, cmake)サポートをしています。

ざっくりいうと、「対象のWEBアプリケーションで古いコンポーネント依存の脆弱性がないかを確認する」為のものです。

概要

リリース前のWebアプリケーションをスキャンする、というシチュエーションを想定してみます。

• Javaアプリケーションとして、Apache Struts2を用意します
  • Java以外のRuby、Node.js、Pythonなども限定的ながらチェックができる可能性があるので、 一度試してみることをお勧めします
• VulsサーバーとOWASP Dependency Checkをするサーバーは、別サーバーとします。同一サーバーでも問題ありません

説明の為、以下のような構成とします。

• Vulsサーバーを、Vulsコミュニティテンプレートから作成する
• 開発用WEBサーバーとして、CentOS6のテンプレートから作成する
  • 開発用WEBサーバーで構成したアプリケーションを、OWASP Depencency Checkで検査する
  • 検査後のアプリケーションを、本番WEBサーバー等(今回は構成せず)に展開する

試してみる

WEBアプリケーションを用意する

今回は、Apache Struts2(現時点の最新版の 一つ前 である 2.3.2)を用意します。 アプリケーションの動作の脆弱性検査(ペネトレーションテスト等)はしないので、Struts2単体を検査します。

$ mkdir tmp
$ cd tmp
$ wget http://archive.apache.org/dist/struts/2.3.32/struts-2.3.32-all.zip
$ unzip struts-2.3.32-all.zip
$ ls
struts-2.3.32  struts-2.3.32-all.zip
$

OWASP Dependency Checkの環境を用意する

OWASP Dependency Checkは Javaが必須であるため、導入します。 実行ファイルは展開したディレクトリの bin/dependency-check.sh です。 個人的には、/opt/OWASP/Depencency-Check/ 辺りにインストールするべきと思っています。

$ sudo yum install java
$ wget http://dl.bintray.com/jeremy-long/owasp/dependency-check-2.0.1-release.zip
$ unzip dependency-check-2.0.1-release.zip
$ ls dependency-check/bin/
dependency-check.bat  dependency-check.sh
$ ./dependency-check/bin/dependency-check.sh -v
Dependency-Check Core version 2.0.1
$

OWASP Dependency Checkで検査する

先ほど導入した OWASP Depencency Checkで、Apache Struts2.3.32を検査します。

初回の検査ではNVDのCVEをダウンロードするため、多少時間がかかかります。

$ ./dependency-check/bin/dependency-check.sh --format HTML --project projectName --scan ./tmp/struts-2.3.32 --out ./result.html
[INFO] Checking for updates
[INFO] Skipping NVD check since last check was within 4 hours.
[INFO] Check for updates complete (54 ms)
[INFO] Analysis Started
[INFO] Finished Archive Analyzer (15 seconds)
[INFO] Finished File Name Analyzer (0 seconds)
[INFO] Finished Jar Analyzer (9 seconds)
[INFO] Finished Central Analyzer (124 seconds)
[INFO] Finished Dependency Merging Analyzer (0 seconds)
[INFO] Finished Version Filter Analyzer (0 seconds)
[INFO] Finished Hint Analyzer (0 seconds)
[INFO] Created CPE Index (7 seconds)
[INFO] Finished CPE Analyzer (14 seconds)
[INFO] Finished False Positive Analyzer (0 seconds)
[INFO] Finished Cpe Suppression Analyzer (0 seconds)
[INFO] Finished NVD CVE Analyzer (3 seconds)
[INFO] Finished Vulnerability Suppression Analyzer (0 seconds)
[INFO] Finished Dependency Bundling Analyzer (0 seconds)
[INFO] Analysis Complete (171 seconds)
$

出力形式をHTMLとしているため、HTMLが出力されています。人間は読みやすいですが、Vulsやその他のプログラムと連携するには少し難しい形式です。

検査結果をVulsと連携させる

まずはVuls等と連携しやすいように、XMLフォーマットで出力します。

$ ./dependency-check/bin/dependency-check.sh --format XML --project projectName --scan ./tmp/struts-2.3.32 --out ./result.xml
$

ここで出力されたXMLファイルを、Vulsサーバーからアクセスできるようにします。

今回は、Vulsのコミュニティテンプレートに従い、/opt/vulsの下に配置します。NFS等でのアクセスでも問題ないです。
その後、Vulsのコンフィグを編集し、scan, reportを実行します。

[vuls@vulsserver ~]$ cd /opt/vuls/
[vuls@vulsserver vuls]$ vi config.toml
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
...
[servers.vuls-server]
host  = "localhost"
port  = "local"
dependencyCheckXMLPath = "/opt/vuls/result.xml"  <--ここを追加
...
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
[vuls@vulsserver vuls]$ vuls scan
[vuls@vulsserver vuls]$ vuls report -to-localfile -format-json
[vuls@vulsserver vuls]$

結果を読む

VulsRepoで結果を確認します。

• Packagesに cpe:/ で始まるものとして、登録されています
  • cpe:/a:apache:tomat:6.0.18　など
    

利用している(依存している)Tomcatなどの脆弱性がこれでわかるので、リリース前にアップデート等を行って、リリース時に脆弱性が残らないようにしましょう。

• 脆弱性対応を、運用ではなく、開発側に「シフトレフト」しましょう。その方が、対策コストは少なくて済みます

Vulsの今後

Vulsですが、今後、OVALに対応予定です。現時点では08月末付近を予定しています。これにより、検知精度の向上等が見込まれます。

リリース後、既存コミュニティテンプレートを更新する方法を公開する予定です。

おわりに

脆弱性対応は運用で行うもの、という環境が多いかと思います。しかしながら、Webアプリケーションのリリース後の修正は運用では難しいです。そのため、開発段階でセキュリティを考慮したテストを行うことで、リリース時点で既知の脆弱性を作りこまないことが重要です。

また、今回は既知の脆弱性を検知しましたが、WEBアクセスを伴った脆弱性診断もこの段階で行うのが良いと思われます。OWASPでは OWASP Zed Attack Proxy (OWASP ZAP)も公開しています。利用には脆弱性に対する知識が必要ですが、機械的に自動スキャンする製品よりは自由度が高いです。

OWASP ZAPについては、例えば脆弱性診断研究会で実施している 「脆弱性診断ええんやで(^^)」という勉強会等で、利用方法を学ぶことができます。

OWASPには、Webアプリケーション開発時に有用な情報がありますので、一度確認されることをお勧めします。

こんにちは藤城（@tafujish）です。今日はいつもと趣向を変えて開発中のサービスをちょっとだけ紹介したいと思います。

そのサービスはRDBです。

ユーザーの皆様からRDBサービスについて一番多くリクエストをいただきます。ですので今回、IDCFクラウド上のコンピューティングのマシンから利用可能なリレーショナルデータベースのサービスを2018年初夏のリリースに向けて開発中です。

↑こちらがIDCFクラウド RDBのアイコンとなります！

上記サイトより、MORIO道場に参加（白帯から始めてみよう！）
↓
Facebook内クローズドコミュニティの案内が来るので参加を。（要Facebookアカウント）
コミュニティ内ではIDCFクラウドの開発メンバーと直接会話して意見が言えますので、
開発へのフィードバックなどご遠慮なくどうぞ！
↓
βテストのスレッドにて参加表明（追ってアカウントをヒアリングします）

こんにちは、UX開発部の橋口です。

Webサービスを開発するうえで、JavaScriptは絶対的に使われる技術だと思います。
みなさんもJavaScriptでエラーの調査をする際に、クライアントで実行されるためエラーの内容やどこで発生したかが分からなかったり、問い合わせ内容の再現ができず困ったことがあるのではないでしょうか？

解決の糸口を作るためには、クライアントサイドで発生したエラーに関する情報を収集してあげる必要があります。
JavaScriptのエラーログも収集できる著名な製品もありますが、クラウド環境への導入の場合には高額になってしまったり、独自に解析する場合でも、環境などを用意するのも大変ですし管理も大変です。 そこで、今回の記事はトレジャーデータサービス by IDCFにJavaScriptのエラーログを収集する方法について紹介します。

課題

JavaScriptのエラーを収集するにあたり問題になった２つの課題と解決策をご紹介します。

JavaScriptの性質

先ほども挙げましたが、JavaScriptはクライアントサイドで実行されるスクリプトです。
最新のブラウザであればエラー発生時にスタックトレースなど調査時に有益な情報が取得できますが、閲覧してくれる方全員が最新のブラウザを使ってくれるとは限りません。

そのため、古いバージョンであっても、擬似的なスタックトレースが取得できるstacktrace.jsを今回は使用します。

収集にあたって

stacktrace.jsにはJSON形式でエラーの情報をPOSTしてくれるメソッドがありますが、今まで収集してこなかったため実際にどのぐらいのエラーが集まってくるか見当がつかず、収集側にどれだけのキャパシティを用意すべきなのか想定もできません。

そのため、今回は、キャパシティー管理が不要なうえ※1に、後日の解析が容易なトレジャーデータサービス by IDCFにエラーを収集します。
※1 全体で1.5億件、月間1,000万件まではスタータープランに入ります。詳細はこちら

実際に収集してみよう

ここまでは、課題などを上げてきました。
ここからは、実際にトレジャーデータサービス by IDCFへ収集する為の準備をしましょう。

DBの設定

まずはじめに、データベースや、テーブルを作成します。

左上から二番目のDatabasesアイコンをクリックします。

新しいデータベースを作成します。

新しいテーブルを作成します。

writeKeyの取得

javascriptには書き込み専用のwriteKeyをセットします。 しかし、データベースやテーブルごとに制限をかけることができないので専用のアカウントを作成するのがオススメです。 writeKeyはMy profileから確認できます。

画面左下のアイコンをクリックしMy profileをクリックします。

API Keysをクリックします。

認証をするとAPIキーが表示されるのでwriteKeyを控えます。ない場合はCREATEを押して作成しましょう。

サンプルコード

必要な情報が揃ったので実際にエラーログをトレジャーデータサービス by IDCFに送信して見ましょう。

今回はイベントリスナに window.onerrorを用いますが、 window.addEventListenerを使用することも可能です。
また、スタックトレースの部分を改行で連結しています。 今回はサンプルのためhtmlファイルに直接記載していますが、必要に応じてJavaScriptファイルにすることをおすすめします。

<html>
<head>
  <!-- Treasure Data -->
  <script type="text/javascript">
!function(t,e){if(void 0===e[t]){e[t]=function(){e[t].clients.push(this),this._init=[Array.prototype.slice.call(arguments)]},e[t].clients=[];for(var r=function(t){return function(){return this["_"+t]=this["_"+t]||[],this["_"+t].push(Array.prototype.slice.call(arguments)),this}},s=["addRecord","set","trackEvent","trackPageview","trackClicks","ready","fetchGlobalID","fetchUserSegments"],a=0;a<s.length;a++){var c=s[a];e[t].prototype[c]=r(c)}var n=document.createElement("script");n.type="text/javascript",n.async=!0,n.src=("https:"===document.location.protocol?"https:":"http:")+"//cdn.treasuredata.com/sdk/1.9.2/td.min.js";var i=document.getElementsByTagName("script")[0];i.parentNode.insertBefore(n,i)}}("Treasure",this);
  </script>
  <!-- StackTrace.JS -->
  <script type="text/javascript" src="//cdnjs.cloudflare.com/ajax/libs/stacktrace.js/2.0.0/stacktrace.min.js">
  <!-- javascript error collector -->
  <script type="text/javascript">
var td = new Treasure({
  host: 'idcf.in.treasuredata.com',
  // 書き込み専用のwriteKeyを記載します
  writeKey: 'YOUR_WRITE_ONLY_APIKEY_IS_HERE',
  // データベース名を記載します
  database: 'DATABASE_NAME'
});
// Enable cross-domain tracking
// td.set('$global', 'td_global_id', 'td_global_id');
var callback = function(stackframes) {
  return stackframes.map(function(sf) {
    return sf.toString();
  }).join('\n');
};
var errback = function() { return null; };
window.onerror = function(msg, file, line, col, error) {
    // callback is called with an Array[StackFrame]
    var stack = StackTrace.fromError(error).then(callback).catch(errback);
    stack.then(function(stringifiedStack) {
      td.set({
        msg: msg,
        url: file,
        line: line,
        column: col || null,
        stack: stringifiedStack
      });
      // テーブル名を記載します
      td.trackEvent('TABLE_NAME');
    });
};
  </script>
</head>
<body>
  sample
</body>
</html>

実際にエラーログを収集すると、次のようにDB内のテーブルに格納されます。

さいごに

IDCFクラウドでもJavaScriptエラーログを取得中です。
どの画面でどの行でどのようなエラーが発生しているかデータベースに記録されるため、リリース後に新規にエラーが発生していないか、定常的に顧客のUXを低下させるような不具合が発生していないかの確認に役立てています。
改善にとても役立つのでみなさんの作成されるWebアプリケーションでもエラーログの継続的な収集と解析をお勧めいたします。

こんにちは藤城（@tafujish）です。前回の記事に引き続き 、IDCFクラウド RDB サービスについてもう少し具体的に紹介したいと思います。

• IDCFクラウド RDB サービスとは
• RDB サービスの特長
• 次回予告

blog.idcf.jp

IDCFクラウド RDB サービスとは

IDCFクラウド コンピューティング 上の仮想マシンから利用可能なリレーショナルデータベース（RDB）を提供するサービスで、現在は MySQL 提供の開発を進めています。

IDCFクラウドのクラウドコンソールから、簡単かつ短時間でセットアップされたRDBを利用することが可能になります。冗長構成で作成され監視と障害時の自動切替や自動バックアップが備わっていますので、可用性の向上やデータの保護が可能です。

では、具体的な構成を見ていきましょう。

RDBマシンには、プライベートIPアドレスが割り当てられ、コンピューティングの仮想マシンから閉域かつ同一セグメントでの接続となり、セキュアで低レイテンシな接続となります。

ここでは、標準のネットワークに接続している例ですが、追加ネットワークに接続することで、階層を分けたネットワーク構成を組むことができます。また、プライベートコネクトやバーチャルブリッジ経由でも接続できるため、他のクラウド環境や、データセンターなどのオンプレ環境との接続も可能です。

RDBマシンはアクティブ-スタンバイによる冗長構成になっています。アクティブのRDBマシンに書き込まれたデータは、スタンバイ側にボリュームミラーリングで同期されるためアクティブ-スタンバイ間でのレプリケーション遅延は起こりえません。

アクティブのマシンが障害等でダウンした場合は、短い断時間の内にスタンバイ側に自動で切り替わります。この切り替りはDNSベースでの提供となりますので、自動切替の機能を利用する場合は、FQDNでRDBへ接続する必要があります。

RDB サービスの特長

IDCFクラウド RDB においても、これまでのIDCFクラウドの各サービスの同様に、シンプルでパワフルなサービスをコンセプトに開発中です。

料金も使い勝手もシンプルに、性能や動きはパワフルに。 と言うことで、βテストを提供する中でよくいただいた質問の一部を紹介したいと思います。

Q)スペック変更は無停止でできますか？

A)マシンタイプのスペックアップは、コンピューティングのダイナミックスケール同様に無停止で変更することができます。ディスクサイズも同様に無停止で拡張することが可能です。

Q)すぐに冗長(スタンバイ)に切り替わりますか？

A)故意にダウンさせて1分半くらいで切り替わってます。 　ユーザー側でも試せるので是非やってみてください。

Q)料金は？お高いんでしょう？

A)決まり次第公開したいと考えてますが、コンピューティング同様に、使いやすい料金で、素晴らしい性能が出せるよう鋭意開発中です！

Q)いつリリースされますか？

A)現時点で、順調に開発進んでいますので2018年初夏から変更なしです。

次回予告

以上、IDCFクラウド RDB の構成や特長の一部を紹介しましたが、あくまでβテスト中のものです。正式版リリース時に変わることかもしれませんので、リリース後に触って試してもらえるとうれしいです。 では、最終回の次回は、もう少し具体的な動作に迫りたいと思います。