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

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

タグ:cms

自作のマークダウン CMS を一週間ほど自分だけで使ってみて、まあまあな感じだったので一般公開します。

"My info" を略して "Mynfo" と名付けています。ソースコードは GitHub に公開してます。自分でも使ってみたい場合はフォークして使ってください(フォーク先は public でも private でも構いませんが、public の場合は GitHub 上のコンテンツが公開される点に注意してください):
https://github.com/dotnsf/mynfo


また、サンプルとして(皆さんには編集権限はありませんが)この公開ソースコードで作ったコンテンツサービスを以下で公開しています:
https://mynfo.herokuapp.com/


実際にみなさんもこの仕組みを使ってコンテンツサービスを公開する場合、必須ではありませんが heroku のアカウントを所有している場合は自分の GitHub リポジトリにコンテンツをコミットすることで CI/CD で最新コンテンツに更新できる仕組みがあります(しかもこの方法だとコンテンツの更新履歴が Git 側に残る、という大きなメリットがあります)。この機能を使う想定で設定方法を README.md 内で解説しているので、heroku アカウントと併せて使うことを推奨します(試しにローカルホストで動かしてみる、程度であれば不要です)。


【ローカルホストで動かしてみる】
試しにローカルホストで動かすには Node.js 環境が必要です。事前にセットアップしておきましょう。

フォークしたコードを git clone して、npm install してから node app で実行します:
$ git clone https://github.com/dotnsf/mynfo.git ("dotnsf" 部分はあなたの Github アカウント名に読み替えてください)

$ cd mynfo

$ npm install

$ node app

デフォルトでは 8080 番ポートで HTTP リクエストを待ち受けます。ウェブブラウザで localhost:8080 にアクセスします。以下のような画面が表示されれば起動成功です(初期状態では README.md にシンボリックリンクした md/index.md の内容が(マークダウンが HTML に変換されて)表示されています。英語で一通りの使い方が紹介されています):
2022021901

(↑皆さんが使うときには md/index.md と README.md とのシンボリックリンクは切っちゃって構いません)


画面右上のハンバーガーメニューをクリックすると、リポジトリ内の md/ フォルダ以下を対象フォルダとするファイル選択画面が表示されます(デフォルト状態では md/ フォルダ以下に about_markdown.md, index.md, sample.md の3つのマークダウンファイルが存在しており、それらが(.md 拡張子が省略された形で)一覧表示されています:
2022021902


試しに一番上の about_markdown を選択すると md/about_markdown.md ファイルの内容が HTML に変換されて表示されます:
2022021901


また初期画面で表示されている README.md の最初にも記述していますが、実行時の環境変数や settings.js ファイル内で値を指定することで挙動を変えることができます。例えばサービスを不特定多数の人に公開するのではなく、一部の人向けにクローズドな形で公開したい場合は環境変数 BASIC_USERNAME と BASIC_PASSWORD を指定して実行することでベーシック認証が有効になり、正しい ユーザー ID とパスワードを入力しないとコンテンツは見ることができません。

見栄えに関しては環境変数 CONTENTS_TITLE でサイトの題名(デフォルト値は "Mynfo")を、BOOTSTRAP_THEME で Bootstrap のテーマ(デフォルト値は "warning")を指定できます。例えば前者を ".NSF Mynfo"、後者を "info" に指定するとこのような見栄えになります:
2022021904


基本機能としてはこのような感じです。プロジェクトフォルダ内の md/ フォルダ内にあるマークダウン(.md)ファイルを参照することができる、というものです。ただこのサービス自体にはマークダウンの編集機能はありません。このままサーバー上で(普通に)公開する場合は、別途 md/ フォルダ内のマークダウンファイルを編集する仕組み(サーバー上で直接編集するなど)が必要です。

動くか動かないかでは動くのですが、個人的にはこのような使い方はあまり想定していません。あくまで後述のような、GitHub リポジトリと連携する使い方を想定して開発しています。


【heroku のデプロイパイプラインを使う】
サーバー上の .md ファイルを直接編集するような使い方は本来想定したものではありません。この Mynfo の最大の特徴は以下のような使い方ができることです:

・ローカルホストで(好きなマークダウンエディタで).md ファイルを編集して、
・Github にコミット&プッシュすると、
・デプロイパイプラインによって、サービス側のコンテンツも更新される

この流れを heroku を使って実現する方法も README.md に(英語で)記載していますが、このブログでは同じ内容を日本語で紹介します。

まず heroku のアカウントを作成します。heroku には複数種類のアカウントが存在していますが、ただ動かすだけであれば(容量や可用性などを考慮せずに、小規模1インスタンスだけで動かす前提であれば)無料プランで構いません。

※なお heroku の無料プランで作成するアプリは 30 分間アクセスがないと止まってしまい、次にアクセスした時に再起動してからアプリが稼働します(この場合、アプリ画面が表示されるまで再起動のぶん少し時間がかかります)。24 時間ずっと稼働状態をキープしたい場合は有料プランで運用することを推奨します。

そして heroku にログインし、画面右上から New - Create new app を選択します:



次にアプリケーション名(下図では "mynfo")を入力し、サービスを作成する地域(下図では "United States")を指定します。そして次に(Create app ではなく) Add to pipeline を選択します:



Choose a pipeline と書かれた箇所をクリックし、Create new pipeline を選択します:



そして作成するパイプラインの名称(下図では "mynfo-pipeline")を適当に入力し、デプロイ先のステージを指定します。例えば「一度ステージング環境にデプロイし、動作確認ができたらプロダクション環境へデプロイ」するようなケースも想定できますが、今回はそのままプロダクション環境へデプロイするシンプルな例を紹介します。というわけでここではパイプラインのデプロイ先として production を直接指定します。最後に Create app をクリックします:



これでパイプラインそのものは作成されましたが、まだ GitHub リポジトリとの連携ができていません。このまま作業を続けます。

デプロイ方法として GitHub 連携をしたいので Deployment Method に GitHub を選択します:



そして対象となる GitHub リポジトリ(クローンしたリポジトリ)を指定します。Connect to GitHub 欄で自分の GitHub アイコンを選択し、対象リポジトリ名(そのままであれば "mynfo")を入力して Search します:



すると該当の GitHub リポジトリが見つかるので、横にある Connect ボタンをクリックします:



これで GitHub との接続ができました。最後に自動デプロイのための対象ブランチを指定するので、このまま続けます:



Automatic Deploy 欄でパイプラインが参照する GitHub リポジトリのブランチを指定します。特にブランチを作っていない場合は main だけが選択できるので、この main が選択された状態で Enable Automatic Deploy ボタンをクリックします(別途ブランチを作成して、main 以外のブランチを指定することも可能です):



これでフォークした GitHub リポジトリの main ブランチに変更がコミットされると、パイプラインが動いて最新コードが heroku 上のアプリケーションとして https://(アプリ名).herokuapp.com/ という URL で動き出すようになります:



また、この時点で作成したパイプラインの状態を参照すると、GitHub リポジトリの指定したブランチを接続されて、更新時の自動デプロイが有効になっている旨を確認できます:



この状態で試しに1ファイルを追加して動作確認しています。ローカルホスト上で1ファイル追加して git コマンドでコミットしてもいいのですが、今回は GitHub のウェブ画面を使って追加コミットする例を紹介します。

まずはウェブブラウザで該当 GitHub リポジトリのページ(フォークしたリポジトリのページ)を開き、md フォルダを選択します:



ここからファイルを指定して編集することもできますが、今回は新しいファイルを1つ追加することにします。画面右の Add file ボタンをクリックして、表示されるメニューから Create new file を指定します:



GitHub リポジトリに直接ファイルを追加する編集画面が表示されるので、試しにファイル名を test.md 、ファイルの中身には "# テスト" と見出し行だけ入力します:



画面を下にスクロールすると、GitHub に直接コミットする情報を指定する箇所が現れます。ここでコミットコメント(下図では "md/test.md added.")、を指定し、"Commit directly to the main branch" が選択された状態のまま Commit new file ボタンをクリックします:



これで GitHub リポジトリにマークダウンファイルが1つ追加でコミットされました(ローカルホストでも編集する場合はこの状態を git pull して、ローカルホスト側も更新しておいてください)。

そして指定ブランチがコミットされたことで、heroku に作成したパイプラインが自動実行されます。パイプライン実行そのものも数秒で終わってしまいますが、下図はビルド中(デプロイ完了前)のパイプライン画面です。アプリケーションのビルド中である旨が表示されています:



デプロイが完了するとこのような画面になり、ここから最新の(追加コードが反映された状態の)アプリケーションを開くこともできます:



確認のため、アプリケーションを開きます(Open app と書かれたボタンで開きます)。そして画面右上のハンバーガーメニューをクリックします:



すると存在していなかった test.md というファイルが確認できます。試しにこのファイルを選択します:



作成した通りの内容( "# テスト")であることが確認できます:



このように GitHub リポジトリと連携して、ローカルホストや GitHub 画面でマークダウンファイルを追加・更新・削除してサーバーにコミットすると、自動で公開アプリにも反映される仕組みができました。こうしておくことでローカルホストでは VSCode など好きなマークダウンエディタで編集することができるようになって、後は編集後にコミット&プッシュすればアプリにも反映される、という仕組みになりました。

冒頭でも書きましたが、このコンテンツサービスそのものはベーシック認証を有効にすることで一部の人だけに公開することもできます。ただそれとは別に GitHub リポジトリを公開するか/しないかを考慮する点があることに注意してください。基本的にベーシック認証をかけるサービスであれば、フォーク先の GitHub リポジトリも private 扱いにするべきだと思っています。

また環境変数 GITHUB_REPO_URL (リポジトリURL)と GITHUB_BRANCH (ブランチ名)を指定して実行すると、コンテンツの各画面内に GitHub のコンテンツメニューが追加され、各ページやファイル選択画面内から GitHub の対象ページ画面に移動したり、直接編集ページに移動したり、フォルダに新しいファイルを追加することも可能です(編集は編集権限を持っているユーザーのみ使えます):
2022021906

2022021905


この GitHub と連携した使い方はちょっとクセがあるので、普段 Git を使っていない人からすると(編集画面も無いし)むしろ不便に感じるかもしれません。が、Git やマークダウンに慣れたエンジニアであれば、むしろこの使い方で(慣れたマークダウンエディタとも連携して)コンテンツを更新情報まで含めて管理ができることになって便利だと思っていて、このようなサービスを作ってみました。

ちなみに、このアプリでブログ的な使い方をする場合は、コンテンツのファイル名を日付(例えば 20220219.md)にして、環境変数 REVERSE_FILES の値を 1 にして実行することで(新しい日付のファイルがリストの上にくるように並ぶので)使いやすいのでは、と思っています。



Git やマークダウンをバッチリ使っている自分からはなかなか便利に使えているサービスなので、同様の属性を持った人に使ってみていただきたいです。

なお現時点では GitHub と heroku のパイプラインを使う想定で README.md を記述していますが、GitLab など GitHub 以外の Git システムや、GitHub Actions など heroku パイプライン以外の自動デプロイ化の仕組みを使って運用することもできると考えています。ぜひ多くのパターンで挑戦していただきたいです。

IBM ワトソン対応の CMS である BlueCMS を公開しました。IBM Cloud を使ったセットアップ手順はこちらをご覧ください:
ワトソン対応の IBM Cloud 向き CMS "BlueCMS" を公開しました(セットアップ手順)


今回は初期セットアップ後の、実際の使い方を紹介します。


コンテンツタイトル等

初期セットアップの中で管理者権限を持った最初のユーザーを作っているので、このユーザーの ID とパスワードでログインします:
2018071001


管理コンソール画面が表示されます。管理コンソールにはコンテンツタイトルなどコンテンツ全体に関係する設定項目に続き、現在までに登録されている文書の一覧テーブルと、添付ファイルの一覧テーブルが表示されますが、ログインユーザーが管理者権限を持っている場合はコンテンツの設定項目の下にユーザー一覧テーブルも表示されます:
2018071101
(↑上からコンテンツ設定、ユーザー一覧)

2018071102
(↑上から文書一覧、添付ファイル一覧)

コンテンツ設定は以下のようになっています:
2018071103


これらは OGP(Open Graph Protocol) と言われる設定項目になっており、有名どころでは facebook で BlueCMS のトップページや各記事を共有した場合に表示される内容を定義します。

また title と desc は BlueCMS トップ画面の jumbotron の中で表示される内容でもあります。自分のブログのタイトルとその説明を記述するようにしてください。url はブログの URL、image_url は OGP イメージ画像の URL を指定します(指定していない場合は無視します)。

なお、現時点(2018/Jul/12)では個別ページの OGP を設定する機能がなく、個別ページをシェアするとトップページと同じ OGP が表示されます(リンク先の URL だけは個別ページになります)。この辺りは今後の機能拡張で対応したいと思っています。


ユーザー追加/管理

管理者権限を持ったユーザーはユーザー一覧テーブルで登録済みユーザーの一覧を確認したり、編集したり、削除したり、新規にユーザーを追加することができます:
2018071104


新規作成は一番下の編集行の各フィールドに入力して "update"、既存ユーザーの変更は右にある "edit" をクリックすると編集行に値がコピーされるので、ここで変更して "update"、ユーザーの削除は右にある "delete" をクリックします。

なおユーザー編集時には role の値に注意してください。この値が 0 のユーザーは管理者、1 のユーザーは編集者として扱われます。name は画面表示用の名称で、email はメールアドレスですが、これらは現時点では特に利用していません。


文書追加/管理

管理コンソールには現在までに登録されている文書の一覧も表示されます:
2018071105


新規作成は一番下の編集行の各フィールドに入力して "update"、既存文書の変更は右にある "edit" をクリックすると編集行に値がコピーされるので、ここで変更して "update"、文書の削除は右にある "delete" をクリックします。

なお文書の status は 1 のものが公開、0 のものは非公開(ドラフト)となります。body は nicEdit を使ったリッチテキスト編集が可能です。category はカテゴリー文字列を直接指定して入力します(category と body の値は IBM ワトソン連携時に利用する値となります)。

body の入力が狭い nicEdit を使っている点が不便であると理解しています。この辺りも今後も機能拡張の対象と考えています。


添付ファイル追加/管理

管理コンソールには現在までに登録されている添付の一覧も表示されます:
2018071106


添付ファイルの新規作成はファイルを選択後、一番下の編集行の name フィールドに入力して "update"、添付ファイルの削除は右にある "delete" をクリックします。添付ファイルには編集機能はありません。


ワトソン連携

セットアップ時に IBM ワトソンの NLC(Natural Language Classifier) 連携も含めて行っている場合は、BlueCMS 内のコンテンツを NLC に学習させたり、学習結果を使って問い合わせを行うことができます:
2018071107


文書一覧の下に NLC 関連のボタンが3つあります。それぞれ以下のように使います:

- "update NLC" : 現在までに BlueCMS に格納された全文書を NLC のトレーニングデータとして学習を初期化&再学習します。学習時には各文書の body 値と category 値だけを取り出して、body 値の内容を category 値として学習します。これを全ての文書に対して行います。

- "NLC status" : 上記学習命令を発生した後の、ワトソンのトレーニングステータスを確認します。この実行結果が "Available" となれば学習準備は完了していて、後述の "classify" で問い合わせが可能になります。一方、実行結果が "Training" であればまだ学習中なので、いましばらくお待ち下さい。

- "classify" : 学習が済んだ後に問い合わせを実行します。具体的には編集行の body に何か文章を入力した後にこのボタンをクリックすると、上述で学習させたコーパスに対してこの body 内容を問い合わせ、「今までの学習データから、どのカテゴリーがふさわしいか」の結果を取得し、category フィールドを更新します。いわば「ワトソンがその内容に相応しいカテゴリーを自動的に決めてくれる」機能です。


現時点での制限事項等

このブログエントリを編集している 2018/Jul/12 時点での BlueCMS の機能と使い方を紹介しました。上述のように CMS として足りない機能や使いにくい部分も多くあり、ワードプレスなどと比較するとまだまだだと思っています。

一方で新しくスクラッチで開発したからこそできた挑戦的な機能もあります。特に標準で IBM ワトソンと連動する機能については BlueCMS の特徴の1つだと思っています。

自分でも少しずつ使っていきながら感じた機能を拡張させていく予定ですが、もしお試し程度でも使ってみていただける場合は、感想や希望を伝えていただければと思っています。


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

使い方やセットアップ手順は README.md に(英語で)記載していますが、いちおうここでは日本語で(図解入りで)、2018/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" を公開しました(使い方)


このページのトップヘ