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

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

2019/09

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


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

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


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

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

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


2019091602


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


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



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

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


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


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


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


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


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




 

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

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


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


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


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

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

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


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

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


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

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

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

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


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

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


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


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


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


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


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


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


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

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


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


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


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

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


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

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

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


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


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

Windows 10 で kubernates の開発環境を構築する際の方法の1つとして、以下のケースで構築する場合のメモです:
・Kubernetes 本体は minikube を使って Windows 10 に導入
・kubectl は WSL から利用


Kubernetes 本体はローカルで動く minikube を使ってシングルノード環境を構築します。この部分は正しく導入できていさえすれば Windows だろうが、Linux だろうが、Mac だろうが、システム環境の違いを意識することはあまりないと思っています。 ただ実際に利用する段になって kubectl コマンドを実行する環境としては Windows よりもより実践に近い Linux を使いたくなります。というわけで、Windows 10 の WSL (今回は Ubuntu を想定)から利用できるようにしました。

なお、この環境構築をする場合のマシンスペックとして、メモリ 8GB だと構築して minikube start した時点でほぼメモリを使い尽くしてしまいます。動作確認するだけならいいのですが、本格的に開発して動作確認してテストして・・・という段階まで考えるとやはり 16GB くらいはほしいところです。


【前提条件】
- Windows 10
- WSL(Ubuntu 18.0.4) 導入済み


【VirtualBox のインストール】
Windows 10 で minikube を動かす場合、仮想環境のハイパーバイザーが必要です。今回は VirtualBoxを使います。VirtualBox 自体のインストールはごく普通に公式ページから Windows 版をダウンロードし、デフォルト設定のままインストールすればOKです。


【Windows 版 minikube のインストール】
minikube の Github ページから、Windows/amd64 版の minikube 単体をダウンロードします:
2019090801


ダウンロードしたファイルは minikube-windows-amd64.exe というファイル名になっていますが、これを minikube.exe とリネームしてファイルシステムの適当なフォルダに保存します(以下は C:\MyApps\minikube\ というフォルダを作成して、その中に C:\MyApps\minikube\minikube.exe という名前で保存しているものと仮定して以下を続けます)。

このフォルダに PATH を通します。Windows + S キーを押して検索ボックスに「システムの詳細設定」と入力すると「システムの詳細設定の表示」が見つかるので、これを選択します:
2019090802


システムのプロパティウィンドウが表示されたら、「詳細設定」タブを選択し、「環境変数」ボタンをクリック:
2019090803


ユーザー環境変数の Path を選択してから「編集」ボタンをクリック:
2019090804


そして「新規」に minikube.exe が保存されたフォルダ名を追加して、最後に OK ボタンをクリック。これで minikube.exe に PATH が通りました:
2019090805


念の為、動作確認してみます。コマンドプロンプトを起動して、 "minikube version" と入力して実行します。minikube のバージョン番号が表示されれば、ここまでの手順は OK です:
2019090801


【minikube の起動】
コマンドプロンプトから "minikube start" と入力して、minikube を起動します。自動的に必要な VM イメージを見つけて(初回はダウンロードして)自動構築します。通常は minikube が kubectl を見つけてくれるのですが、この方法だと(Windows 版 kubectl を使わない&インストールしていないので)見つからない、という警告が表示されますが、今回は WSL 側に kubectl を用意するので無視します:
2019090802


【WSL に kubectl をインストール】
WSL を起動し、以下のコマンドを入力して kubectl を(/usr/local/bin/ 以下に)導入します:
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

$ chmod 755 kubectl

$ sudo mv kubectl /usr/local/bin

最後に "kubectl version" を実行して動作確認します(初回は Client Version が表示されれば OK です):
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:54Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

【minikube のエンドポイント情報の取得】
コマンドプロンプトに戻って、"minikube status" を実行し、minikube のエンドポイント情報を確認します。以下の例では 192.168.99.100 というアドレスが表示されていますが、これにポート番号 8443 を加えたもの(192.168.99.100:8443)がエンドポイントとなり、以下で利用することになります:
2019090803


【kubectl の設定】
上記で取得したエンドポイント情報を使って kubectl の設定を行います。WSL から以下のコマンドを順次実行します。なお以下で <コマンドプロンプト実行時のユーザー名> と表示されている部分にはコマンドプロンプト実行時のユーザー名がフォルダ名の一部になっているのでそれをそのまま指定します(上記の画像例の場合であれば、ここには KEIKIMURA が入ります)、また 192.168.99.100:8443 部分は上記で取得したエンドポイント情報です:
$ kubectl config set-credentials minikube --client-certificate=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/client.crt --client-key=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/client.key

$ kubectl config set-cluster minikube --server=https://192.168.99.100:8443 --certificate-authority=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/ca.crt

$ kubectl config set-context minikube --user=minikube --cluster=minikube

$ kubectl config use-context minikube

最後に WSL で "kubectl cluster-info" コマンドを実行して動作を確認し、エンドポイントで正しくクラスタ状態が取得できれば kubectl の設定完了です。シングルノードの kubernetes (kubectl) がローカルの WSL から使えるようになりました:
$ kubectl cluster-info

Kubernetes master is running at https://192.168.99.100:8443
KubeDNS is running at https://192.168.99.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.



(参考)
https://dokupe.hatenablog.com/entry/20180408/1523116886

業務やプライベートでウェブアプリを作る際に colorbox を使う機会が少なからずあります。jQuery に対応したモーダルダイアログの軽量プラグインで、メイン画面にオーバーラップするダイアログ画面を呼び出し、ダイアログを閉じるまではメイン画面が使えなくなります。HTML 的な言い方をすると、ボックス領域の表示/非表示を切り替えつつ、ここが表示されている間は他の要素にアクセスできなくさせたい場合などに便利です。

加えて、個人的によく Google MAPs API を使った地図アプリを作っています。他にも多くの地図 API はありますし、実際に使うこともありますが、ストリートビューなど他にはない機能もあって、マンホールマップを始め、多くのアプリで Google MAPs API を活用しています。

今回紹介するのはこの2つを組み合わせて使う方法、つまり colorbox のモーダルダイアログ内で Google MAPs の地図を表示する方法です。特に考慮することなく普通に(colorbox で表示する領域の中に Google MAPs の地図領域を定義しておくだけで)使えそうな気がしていたのですが、どうもこれらの初期化処理時における相性があまりよくないようで、ちょっとしたコツが必要だということがわかりました。

この「ちょっとしたコツ」の結論は
・colorbox のダイアログを表示して、
ダイアログの表示が完了した後で Google MAPs を初期化してダイアログ内に表示する
という順序で実現する必要がありそうでした。一般的には HTML ページの初期化時に Google MAPs を初期化することが多いと思うのですが、colorbox と組み合わせて使う場合は、その初期化タイミングをダイアログの表示後に(ダイアログの表示が完了したことを検知した上で動的に)行う必要がありそうでした。


以下は具体的な実現方法です。まず jQuery や colorbox、Google MAPs API の JavaScript や CSS を一通りロードします(Google MAPs API をロードする際に API KEY の取得と指定が必要です):
  :
<script src="//code.jquery.com/jquery-2.2.4.min.js"></script>
<script type="text/javascript" src="//maps.google.com/maps/api/js?key=(your api key)"></script>
<link href="/css/colorbox.css" rel="stylesheet"/>
<script src="/js/jquery.colorbox-min.js" type="text/javascript"></script>
  :

HTML 内に colorbox で表示するモーダルダイアログ部分(id="mapModal")を定義します。ここは初期状態では表示されていてはまずいので display:none のスタイル指定をしておきます。またモーダルダイアログ表示した際にこの id="map_canvas" のブロックの中で Google MAPs の地図を表示することになりますが、初期段階では何も定義しません:
  :
<div style="display:none">
  <div id="mapModal">
    <div id="map_canvas" style="width:100%; height:520px"></div>
  </div>
</div>
  :

ではこのブロックをモーダルダイアログ表示するための colorbox のアクションを作成します。以下の例では <span> で括られたエリア(id="span1")をクリックした時に colorbox のモーダルダイアログを 90% x 90% でインライン表示するようにしています。加えてこのモーダルダイアログが表示されきった直後に $('#map_canvas').modalMap() が実行されるように定義しています:
  :
<span href="#mapModal" id="span1">ここをクリック</span>

<script>
$(function(){
  $('#span1').colorbox({
    inline: true,
    transition: 'none',
    width: '90%',
    height: '90%',
    onComplete: function(){
      $('#map_canvas').modalMap();
    }
  });
});
</script>
  :

↑この時の <span> 要素に href 属性を付けて対象モーダルの id を指定するのが肝のようです。。

最後にこの modalMap() 関数を定義して、この中で動的に Google MAP を初期化して表示するまでのコードを記述します:
  :
<script>
$.fn.modalMap = function(){
  var latlng = new google.maps.LatLng( 35.690625, 139.699788 );
  var opt = {
    zoom: 8,
    center: latlng,
    mapTypeId: google.maps.MapTypeId.ROADMAP,
    scaleControl: true
  };

  var map = new google.maps.Map( document.getElementById( 'map_canvas' ), opt );
  map.setCenter( latlng );

  var marker = new google.maps.Marker({
    position: latlng,
    map: map
  });
};
</script>
  :

これで <span> 部分をクリックすると colorbox のモーダルダイアログを出し、ダイアログ内で動的にGoogle MAP の地図を初期化&表示する、という一連のコードが完成です:
2019090801

  ↓

2019090802

(↑わかりにくいかもしれませんが、地図部分はモーダルダイアログ表示されています)



このページのトップヘ