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

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

タグ:open

私自身、ふだん CMS (コンテンツ管理システム)といえばワードプレスを使うことが多かったのですが、思い立って自分でも CMS を作ってみることにしました。それもせっかくなので(?)あまり例のない Node.jsIBM Cloudant をベースとした、IBM Cloud 環境向きのインフラで実装し、かつオプションで、この中で管理するコンテンツが IBM Watson の自然言語分類機能の学習コンテンツにできるような機能も付与して BlueCMS という名称で github.com で公開しました:
https://github.com/dotnsf/bluecms

使い方やセットアップ手順は README.md に(英語で)記載していますが、いちおうここでは日本語で(図解入りで)、2017/Jul/11 時点での実装内容やセットアップ手順を紹介します。

なお、このブログエントリのタイトルで「IBM Cloud 向き」と表現していますが、この意図は「IBM Cloud (の PaaS)を使うとセットアップが楽」という意味であって、普通の PC や仮想環境、各種 IaaS サーバーなどからでもセットアップ可能です(ただし IBM Cloud の Cloudant は必要です)。


BlueCMS はコンテンツ管理システムの実装の1つです。現時点では機能的にはまだまだ足りない部分もあると思いますが、CMS としての最小限の機能に加えて、以下のような特徴を持っています:
(1) 実装は Node.js、データストアには IBM Cloudant を利用
(2) IBM Cloud のライトアカウント(無料版)でも使える
(3) コンテンツ管理だけでなく、ユーザー管理機能を内蔵している
(4) 添付ファイルを格納することもできる(IBM Cloudant 内にバイナリデータとして格納)
(5) IBM Cloud ライトアカウントの範囲ではないが、IBM ワトソンと連動する機能をビルトインで使える
(6) ソースは MIT ライセンスで公開


BlueCMS そのものは IBM Cloud 以外の環境でも動きますが、IBM Cloud のアカウントを所有していると PaaS の機能を活用して比較的すぐ&簡単に環境構築できます。なお BlueCMS 自体は無料のライトアカウントでも(他にランタイムやサービスを使っていなければ)環境構築可能ですが、後述するオプションのワトソン NLC(Natural Language Classifier) 機能を利用する場合はクレジットカードを登録してスタンダードアカウント等にしておく必要があります(その場合でも利用量によっては無料枠内で運用可能です)。


セットアップ手順

IBM Cloud アカウントを所有している場合、以下の4ステップで最低限の動作環境を構築します:

(1) インフラ(ランタイムインスタンスとサービスインスタンス)の作成

とりあえず IBM Cloud にログインします:
2018071001


まず BlueCMS を実行するための Node.js ランタイムを作成します。ログイン直後の画面(ダッシュボード)右上の「リソースの作成」ボタンをクリックします:
2018071002



「Compute」カテゴリーから「SDK for Node.js」ランタイムを選択します:
2018071102


ランタイムを作成する場合は名称と地域に注意が必要です。名称は URL の一部になるためユニークな文字列を指定します(下図では bluecms としていますが、この名称は僕が使っているので使えません)。また地域はどこでもいいのですが、以降で Cloudant や NLC を作成する場合に同じ地域を指定する必要があるので、どこを選択したかを覚えておきましょう。最後に「作成」ボタンをクリック:
2018071004


これで Node.js のランタイム(アプリケーションサーバー)を作ることができました:
2018071005


このまま次のステップに移りますが、ダッシュボードへの戻り方をガイドしておきます。IBM Cloud の画面のどこからでも画面左上の三本線メニュー(「ハンバーガーメニュー」)からダッシュボードに戻ることができます。まずはここをクリック:
2018071006


そしてポップアップメニューから「ダッシュボード」を選択します。これでダッシュボードに戻ります:
2018071007


ダッシュボードに戻ると、上記で作成したランタイムが一覧に加わっていることが確認できるはずです:
2018071008


次にデータをストアするための IBM Cloudant サービスインスタンスを作成します。やはりダッシュボードから「リソースの作成」をクリックし、今度は「Databases」カテゴリの「Cloudant」を選択します:
2018071103


サービスの地域は先程 Node.js ランタイムを作成した時と同じ地域を選択し、またプランは "Lite" を選択しておくと容量やトランザクションパフォーマンスに制約があるものの、料金はかかりません。最後に「作成」をクリック:
2018071010


これだけで IBM Cloudant のインスタンスを作ることができました:
2018071011


なお Cloudant のライトプランでの制限やライトプラン以外での料金についてはこの画面内の記述を参照してください。ライトプランの場合、容量は 1GB、パフォーマンスとしては 20 データ読み取り/秒、10 データ書き込み/秒、5 データクエリー/秒となります:
2018071105



有料アカウントを利用している場合で、かつワトソン連携機能を有効にしたい場合は IBM Watson NLC サービスインスタンスを作成します。再度ダッシュボードに戻り、「リソースの作成」から「AI」カテゴリーの「Natural Language Classifier」を選択します:
2018071101


こちらでも Node.js ランタイムを作った時と同じ地域を選択し、「作成」をクリックします:
2018071013


なお NLC の料金や無料枠についてはこの画面内の記述を参照してご注意ください。1ヶ月あたりで最初の1インスタンス、4 回の学習実行、1000件の問い合わせまでは無料ですが、それらを超えた分は課金対象となります:
2018071104


こちらもサービスを作ることができました:
2018071014


ここまでの作業でアプリケーションサーバーとデータベース(、とオプションでワトソン)の各サービスが IBM Cloud 内で有効になりました。 PaaS だとこういう所が簡単で便利です:
2018071003



(2) ランタイムとサービスのバインド

IBM Cloud を利用している場合、ランタイムとサービスをバインドすることで面倒な認証情報の設定や交換を安全かつ簡易化することができます。BlueCMS はこの仕組に対応しているので、そのための設定を行います。

まずダッシュボードを表示し、ランタイム一覧から作成した Node.js ランタイムを選択します:
2018071015


現在のランタイム動作状況が確認できる画面が表示されます:
2018071016


ここで画面左のメニューから「接続」を選択します。バインド済みサービスの一覧が表示されますが、この時点では何もバインドされていないので、何も表示されません。ここに上記で作成した IBM Cloudant(とワトソン NLC)サービスをバインドします。「接続の作成」ボタンをクリックします:
2018071017


バインド可能なサービスの一覧が表示されます。上記のインスタンス作成の過程で作成地域が全て同じであれば、この一覧の中に IBM Cloudant (とワトソン NLC)が含まれているはずです。まずは IBM Cloudant サービスを選び(マウスオーバーし)、「Connect」ボタンをクリックします:
2018071018


環境を再ステージングするか、という確認ダイアログが表示されるので「再ステージ」を選択して、再起動します。再起動が完了するまで5分弱かかります:
2018071019


再ステージが完了すると、Node.js ランタイムに IBM Cloudant がバインドされた状態になり、接続一覧からも確認できるようになります:
2018071020


ワトソン NLC サービスも作成している場合は、こちらも続けてバインドします。接続メニューの一覧から NLC を選択(マウスオーバー)し、「Connect」をクリックします:
2018071021


こちらも再ステージして、Cloudant と NLC 両方のサービスがバインドされた状態になりました:
2018071022


ここまでの作業で作成した各インスタンスがバインドされ、連携できる準備が整いました:
2018071004



これでアプリケーションインフラ部分の構築が完了しました。後は BlueCMS の中身をアップロードするだけです。


(3) ソースコードの用意とランタイムにプッシュ

あとは BlueCMS のソースコードを用意して、ランタイムにプッシュ(転送)すればいいのですが、そのためには cf というツールを使います。最初に cf ツールをダウンロード&インストールします:
https://github.com/cloudfoundry/cli/releases

上記ページから自分の環境にあった cf ツールをダウンロードしてインストールします。

改めて、いよいよソースコードを用意します。github のリポジトリからソースコードを git clone するか、(その意味がわからなければ)zip ダウンロード&展開します:
2018071001


本来であればここで認証情報の取得や設定が必要になるのですが、IBM Cloud を使っているとその部分を上記の「バインド」設定で済ませていることになります。設定を行う場合はソースコード内の settings.js 内の各種値を変更します(IBM Cloud 環境を使う場合、変更する必要があるとしたら exports.search_analyzer(検索インデックスで使う言語)と、exports.nlc_language(ワトソン NLC の学習時に指定する言語)くらいです。コンテンツが日本語の場合はともに変更の必要はありません):
2018071002


settings.js の準備が完了したら、いよいよ cf を使ってコードをランタイムにプッシュします。コマンドプロンプトやターミナルを開き、まずは cf コマンドで IBM Cloudant にログインします(ログインパスワードを聞かれるので入力します):
$ cf login -a https://api.ng.bluemix.net/ -u (IBM Cloud のログイン名)

ログインできたらランタイムにプッシュするだけです:
$ cf push (ランタイムの名前(上記例だと bluecms となっている所に指定したもの))

プッシュが成功すると BlueCMS が Node.js ランタイム上で動き出します。BlueCMS は起動と同時に Cloudant 上にデータベースをインデックスごと作成するので、あらかじめ Cloudant 側で準備しておく必要はありません:
2018071005


まだ必要な管理用/編集用のユーザーを作っていないため投稿はできないのですが、この時点でトップページを表示することはできます。

ウェブブラウザで https://(ランタイム作成時に指定したアプリケーション名).mybluemix.net/ にアクセスします:
2018071000
 (まだ中身がないので今はこれだけ)

↑こんな感じのトップ画面が表示されればほぼ完成、あともう少しです!


(4) 最初の管理ユーザー ID の作成

(注 この部分の手順は将来変更の可能性がありますが)専用の API を使って BlueCMS の最初の管理ユーザーを作成します。

BlueCMS には2種類のユーザーがいます。1つが管理者ユーザー、もう1つが編集者ユーザーです。BlueCMS のコンテンツを作成/編集することができるのは管理者ユーザーと編集者ユーザーで、ユーザーの作成/変更/削除といったことができるのが編集者ユーザーです。

BlueCMS の場合、ログインしなくてもコンテンツの一覧や1つ1つを参照することはできます。ただコンテンツの中身を編集したり、編集者ユーザーを登録したりするにはユーザー登録が必要になります。これらの編集/登録作業は BlueCMS にログインした後のコンソールから行うことが可能ですが、一番最初の管理者ユーザーだけは(まだ誰もコンソールにアクセスできないため)別の方法で作成する必要があります。その方法を以下に紹介します。

最初の管理者ユーザーは curl コマンドを使って、以下の REST API を使って作成します:
$ curl -XPOST -H 'Content-Type: application/json' 'https://(ランタイム作成時に指定したアプリの名前).mybluemix.net/adminuser' -d '{"id":"abc@xyz.com","password":"yourpassword","name":"yourname","email":"abc@xyz.com"}'

-d オプションに続いてパラメータが指定されています。それぞれ以下のような意味があります:
 id: ログインID(ログイン時に指定するユーザーID)
 password: ログインパスワード(ログイン時に指定するパスワード)
 name: 画面に表示される時の名前、省略時は id が使われる
 email: メールアドレス、省略時は admin@admin となる


管理者権限で編集することはあまり想定しておらず、あくまで管理者権限で編集者を作成し、編集者権限でログインしてコンテンツを編集、することを想定しています。そのためこの最初の管理者ユーザーはどちらかというと「編集者ユーザーの管理者」的な位置づけになりますが、その管理者ユーザーを上記コマンドで作成しました:
2018071006


このコマンドが成功(結果に status:true が含まれている)すれば、このユーザーで BlueCMS にログインすることができるようになります。これで BlueCMS を使うために必要な最低限の準備は完了です。


ログイン

では作成した管理者ユーザーでログインしてみます。ウェブブラウザで https://(ランタイムに作成したアプリ名).mybluemix.net/ にアクセスし、画面右上の login ボタンをクリックします:
2018071000


ログインフォームが表示されたら、先程の REST API で作成した管理者ユーザーの id とパスワードを指定して login をクリックします:
2018071001


正しい情報が指定されていればログインし、管理用コンソールに移動します:
2018071002


この管理用コンソールでユーザーの作成/編集/削除を行ったり、コンテンツの作成/編集/追加、添付ファイルの作成と削除を行うことができます。その使い方についてはまた別の機会に、とりあえず BlueCMS とその初期セットアップ方法の紹介でした。


(2018/Jul/12 追記)
続きの使い方の説明はこちら:
ワトソン対応の IBM Cloud 向き CMS "BlueCMS" を公開しました(使い方)


実を言うと前回このブログエントリを書いたのは、今日のエントリへの前フリでした:もともと以下で紹介する Swagger Editor を使う様子を紹介したかったのですが、そのためには扱う題材となる API が必要でした。というわけで簡単な仕様で、かつ試験的にクロスオリジン問題を解決することのできる(←ここ大事!)REST API を Node-RED で作ってみる、というのが上記の内容でした。同様に自分で管理可能な API があればそれを使って読み替えていただいてもいいのですが、そうでない場合まずは上記エントリを参照して、この後の紹介で管理する REST API を作っておいてください。


さて本題は「REST API のドキュメントをどのように用意するか」です。REST API の仕様書として最低限必要な情報は HTTP メソッドと URL のパス、実行時に与えるパラメータ、結果、そしてその API が何をするものかをざっと紹介したものでしょうか?気が利いているものだと各パラメータ毎の必須/オプションの情報、エラー時の情報などがあったりしてより便利になります。上記の Node-RED で作った API の場合だと対象の API は1つでこんな感じでしょうか:
メソッドパスパラメータの指定方法パラメータとその意味実行例結果の Content-Type結果
GET/getDateURLパラメータtimestamp : タイムスタンプ値(オプション、未指定時は現在時刻)curl -XGET 'http://xxx.com/getDate?timestamp=1000'text/plain指定した日付時刻の文字列


このドキュメントでもある程度は理解できると思いますが、もう少し便利に、というか、Swagger という標準フォーマットを使ってドキュメントを作ってみます。その際に便利なのが Swagger Editor です。Swagger Editor はここにアクセスしてオンライン版をそのまま使うこともできますし、Docker イメージやソフトウェアをダウンロードして専用環境下で利用することもできます。今回はオンライン版を使って紹介します。

Swagger Editor を開いて、API ドキュメントを yaml と呼ばれるテキストフォーマットで書いていきます。今回の例だとこんな感じでしょうか:
swagger: "2.0"
info:
  description: "俺の API"
  version: "0.0.1"
  title: "俺の API"
host: "**********.mybluemix.net"
basePath: "/"
tags:
- name: "myapi"
  description: "俺のAPI"
schemes:
- "http"
- "https"
paths:
  /getDate:
    get:
      tags:
      - "myapi"
      summary: "時刻を文字列で取得する"
      description: "現在時刻または指定したタイムスタンプ値の日付文字列を返す"
      produces:
      - "text/plain"
      parameters:
      - in: "query"
        name: "timestamp"
type: "number"
format: "integer" description: "タイムスタンプ値" responses: 200: description: "成功"

この内容を Swagger Editor の画面左に入力します。するとこの Swagger で定義した Open API ドキュメントが画面右に表示されます:
2017091001


今回定義したのは GET /getDate という1つの API です。ここをクリックすると展開され、パラメータなどより詳しい情報が表示されます。API ドキュメントとしても便利ですが、この Swagger によるドキュメント最大の特徴は「実行できる」ことです。このページから AJAX によるリクエストを発行して API を実行します。一般的には AJAX でリモートサイトにアクセスするにはクロスドメイン問題を考慮する必要がありますが、今回用意した API は(そのための目的もあって)クロスドメインからも実行できるような HTTP レスポンスヘッダを設定しています。というわけで実行してみましょう。"Try it out" と書かれたボタンをクリックします:
2017090902


するとパラメータ部分が入力可能な状態になります。今回は timestamp という必須ではないパラメータを指定できるようにしていることがわかります。とりあえずはここには何も設定せずにそのまま実行してみます:
2017090903


実行するには "Execute" と書かれたボタンをクリックします。すると実行した時の curl コマンドなどと一緒に実行結果も表示されます。この API はパラメータなしで実行すると現在時刻のテキストを返すようになっており、実際に実行したタイミングの日付時刻が表示されます:
2017090904


次にパラメータを指定した上で実行してみます。timestamp に 1000 と入力してみました。これはタイムスタンプの値が 1000 になる日時(1970年1月1日午前零時から1000ミリ秒後)を指定したことになります:
2017090905


この状態で "Execute" ボタンをクリックすると、実行結果は 1970/01/01 00:00:01 になるはずです。API が正しく動いていることがドキュメントの中から実行して確認することができました(クロスドメイン問題を抱えたままだとここでの実行は失敗します):
2017090906


と、これが Swagger で作った API ドキュメントの魅力です。 最後にここで定義した Swagger ドキュメントをエクスポートして(Swagger Editor 上ではない)別のサーバー上でも動くようにしてみます。今回は Node.js 上で実行できるような形式でエクスポートしてみましょう(サーバーサイド JavaScript である Node.js 上で実行する場合はクロスドメインは意識する必要がありません)。画面メニューの "Generate Server" から "nodejs-server" を選択します。すると自動的にダウンロードが始まり、nodejs-server-server-generate.zip というファイルがダウンロードされます:
2017090907


この zip ファイルを Node.js がインストールされたシステム上に展開し、"npm install" 後に "npm run start" すると起動します:
$ cd nodejs-server-server
$ npm install
$ npm run start

> api@0.0.1 prestart /home/pi/src/nodejs-server-server
> npm install

up to date in 5.819s

> api@0.0.1 start /home/pi/src/nodejs-server-server
> node index.js

Your server is listening on port 8080 (http://localhost:8080)
Swagger-ui is available on http://localhost:8080/docs

起動したドキュメントページ(上記例だと http://localhost:8080/docs)にアクセスすると Swagger Editor の右ペインでプレビューとして見ていた部分が表示されます:
2017091002


実際にパラメータを指定するなどして実行することも可能です:
2017091003


以上、自分で作った API に対する実際に動かせる Swagger ドキュメントを作り、そのドキュメントを自分のサーバー上で動かす、という一連の手順を紹介しました。開発者としては API の仕様書を読み解くだけでなく、実際に動かして返ってくる値やそのフォーマットを確認しながら利用できるので、自分が API を使って作ったアプリがうまく動かなかった時の問題切り分けにも使えるツールになるので非常に便利です。

このページのトップヘ