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

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

タグ:custom

かなり以前に Bluemix(IBM Cloud) の CloudFoundry ランタイム環境でカスタムドメインを運用する手順を紹介したことがありました。今回はその IKS(IBM Kubernetes Services) 版とも言える内容で、特にカスタムドメイン管理を適用する部分については IBM Cloud から提供されるドメイン単位でのオール・イン・ワン・セキュリティーサービスでもある CIS(Cloud Internet Services) を使った場合の手順を確認する機会があったので、その流れを紹介します。

なお、今回紹介する手順を実行するための前提条件として (0) カスタムドメインを所有していること、(1) ベーシックプラン以上の IBM Cloud アカウントを取得していること、(2) IKS(+ Ingress)サービスが利用できること、そして (3) CIS サービスが利用できるという3点が必要です。(0) は今回の作業では当然必要です。また (1) がないと (2) も (3) も利用できないので IBM Cloud アカウントは取得しているとして、このアカウントは無料のライトプランではなく、ベーシックプラン以上でないと (2) も (3) も作成できない点にご注意ください。

また (2) について、IKS は1ヶ月間無料の Free プランもありますが、今回紹介する内容では(Free プランでは使えない) Ingress によるサーバー名管理が必要なため、事実上この (2) は無料では試せない点をご了承ください。シングルゾーンの最弱スペックで1ワーカーノード環境(1時間で約13円)でも構いませんが、IKS を利用するための料金が必要です。なお IKS ではなく上位版の OpenShift 環境でも大丈夫です:
2021062501


(3) の CIS は1アカウントにつき1回だけ、30日間無料プランを申し込むことが可能です。このプランを利用せずにスタンダードプランを利用する場合は、ドメイン1つにつき1ヶ月約30000円です:
2021062502



では以下で具体的な手順を追いながら説明します。

【IKS + Ingress を使ってアプリケーションをデプロイする】
まずは IKS + Ingress 環境で動くウェブアプリケーションを用意します。この時点ではカスタムドメインを意識せずに環境を作ります。

自分で IKS にデプロイしたアプリケーションがあればそれを使っていただいても構いませんが、動作確認用のサンプルとして、以前のブログエントリでも紹介したこのアプリケーションを使う方法も紹介します(アクセスすると、サーバーの /etc/hostname ファイルの内容を表示するだけのアプリケーションです)。ソースコード内に IKS + Ingress 環境を想定したデプロイ用の yaml ファイルが含まれているのでこれを自分の環境向けに編集してデプロイに使うことにします。

まずはソースコードを git clone するかダウンロードしてください:
$ git clone https://github.com/dotnsf/hostname

厳密には今回の作業で最低限必要になるのは yaml/app_deployment_ingresssample.yaml ファイル1つだけなので、ソースコード等に興味なく単に動作確認するだけであれば、このファイルをダウンロードしていただくだけでも構いません:
https://raw.githubusercontent.com/dotnsf/hostname/master/yaml/app_deployment_ingresssample.yaml


次にダウンロードした (yaml/)app_deployment_ingresssample.yaml ファイルを自分の環境向けに編集するのですが、まずは自分の Ingress サブドメインを確認しておく必要があります。IBM Cloud にログインし、利用中の IKS のダッシュボードを開いて Overview メニューから Ingress Subdomain 欄を参照して、その値を確認します:
2021062403


ダウンロードした app_deployment_ingresssample.yaml ファイルをテキストエディタで開き、以下の部分を上で参照した自分の Ingress Subdomain の値に書き換えます。また k8s クラスターを東京( jp-tok )以外のリージョンで作成した場合はサブドメイン情報に続くリージョン情報も自分のリージョンに書き換えてください。最後に保存します:
apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
  - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080


これでデプロイの準備が完了したので、実際に IKS へデプロイします:
$ kubectl apply -f yaml/app_deployment_ingresssample.yaml 

デプロイが成功すると Ingress が有効になり、https://(上述の spec.tls.hosts の値)/ でアプリケーションにアクセスできるようになります:
2021062401


IKS 上にデプロイされたアプリケーションの稼働までができました。この時点では IBM Cloud のドメインによるサーバー名でアクセスされていますが、引き続いて CIS を使い、このアプリケーションをカスタムドメインのサーバー名でアクセスできるようにしていきます。


【CIS にカスタムドメインを登録する】
次の手順は CIS 側の設定です。CIS はドメイン単位で設定を行います。したがってカスタムドメインを使う場合はそのカスタムドメインを登録した上で証明書等を発行する必要があります。

今回は私個人が所有する pi314.jp というドメインを使って説明します。最終的には上述の IKS 上で動く hostname アプリケーションを https://hostname.pi314.jp/ という URL で利用できるように設定していくことにします。以下、"pi314.jp" 部分を皆さんが所有するドメイン名に置き換えて参照してください。

カスタムドメインを CIS に登録する際の最初の手順は利用ドメインの登録ネームサーバーの置き換えです。まず何はともあれ自分のドメインを CIS に管理させるために登録を行います。自分の CIS サービスを開き、Overview メニューから Add domain ボタンをクリックします:
2021062401


画面右にウィザード形式のダイアログが現れるので、指示に従って入力していきます。まずは利用するドメイン(下図では pi314.jp)を入力して Next を選択します:
2021062402


次の DNS レコード登録画面はスキップします。そのまま Next を選択:
2021062403


最後にドメイン管理のためのネームサーバーを変更しろ、という以下のような画面が現れます:
2021062404


DNS で利用するネームサーバーを CIS が管理するネームサーバーに変更する必要があります。この具体的な手順は独自ドメインを取得した業者によって異なりますが、プライマリネームサーバーとセカンダリネームサーバーをそれぞれ以下の内容に変更してください(画面は GoDaddy での DNS 管理画面のものです):
2021062401

 プライマリネームサーバー: ns012.name.cloud.ibm.com
 セカンダリネームサーバー: ns091.name.cloud.ibm.com


変更が完了したら、少し待ってから上図の Next を選択します。変更内容がネット上に反映されるまで少し時間が必要なので、すぐに実行すると「1時間後に再実行しろ」といった内容のエラーになるかもしれません。その場合は少し待ってから再実行してください。

無事に変更内容が確認できた場合は以下のような画面になります。最後に Done を選択:
2021062405


CIS のコンソール画面に移動します。この時点で登録したカスタムドメインが Active になっていることが確認できます。これでドメインの登録とネームサーバーの置き換え作業は完了しました:
2021062406


【CIS に DNS を登録し、エッジとサーバーの接続方法の選択】
ネームサーバーの置き換え後に行う必要があるのは、DNS 設定でカスタムドメインを使ったサーバー名(今回は hostname.pi314.jp)で実際に動いているサーバー(IKS の yaml ファイルで spec.tls.hosts に書かれた値、つまりウェブブラウザで動作確認した時の URL のサーバー名)にアクセスさせるための CNAME の登録と、カスタムドメインのエッジ証明書の作成(確認)、そして CIS のエッジサーバーから IKS のサーバーへどのような方法で接続するかの接続方法の選択です。すべて CIS コンソールから行います。

まずは CNAME を登録します。"Reliability" メニューから "DNS" タブを選択します。画面下部に "DNS records" 欄がありますが、おそらく最初は中身が空のはずです。ここに新しいレコードを作成するため、Add ボタンを選択します:
2021062407


画面右に "Add record" ダイアログが表示されるので、ここで以下のように入力します:
 Type: "CNAME" を選択
 TTL: "Automatic" のまま
 Name: カスタムドメインを使ってアクセスさせるホスト名のドメインを抜いた部分
  (例えば hostname.pi314.jp でアクセスさせたい場合であれば hostname)
 Alias domain name: 現在動いているサーバー名
  (上述のウェブサーバーで動作確認した時に入力した IBM Cloud ドメインのサーバー名)

最後に Add ボタンをクリックします:
2021062408


1つ前の画面に戻り、DNS records が1件追加されていることを確認し、Proxy を ON の状態にしておきます。これで DNS の登録も完了して、hostname.pi314.jp というホスト名で IKS で稼働中のアプリケーションを指し示すようになりました:
2021062409


続けて https 接続のためのエッジ証明書を確認します。CIS コンソールから "Security" メニューを選び、画面下部に Edge certificates 欄を参照します。ここにはカスタムドメインとそのワイルドカード名(今回の例であれば pi314.jp と *.pi314.jp)のエッジ証明書が入力されていればそのままで大丈夫です(2021/06/23 時点の仕様では自動的に作成されているはずです)。もしもここが空になっていたら、右上の Add ボタンを押して、この2つを指定してエッジ証明書を追加してください:
2021062401


最後に CIS のエッジサーバーと、実際のサーバーとの間の通信手段を選択します。同じ "Security" メニューの画面内の TLS mode を確認します(デフォルトは End-to-end CA signed)。ここでセキュリティ要件に合わせて通信方法を選択します。最もセキュリティが高いのは End-to-end CA signed ですが、この場合は別途ドメインのワイルドカード証明書を取得する必要があります。今回は1つ下の End-to-end flexible を選択します(自動発行する自己証明書を使った暗号化通信を行うモードです)。なおこれらの選択肢の違いについて、詳しくはこちらを参照ください:
2021062401


以上で CIS コンソールでの作業も完了です。


【デプロイ設定を変更して IKS にアプリケーションを再デプロイ】

最後にデプロイ設定を変更してアプリケーションを再デプロイします。現在は IBM Cloud ドメイン名でアクセスされる前提でデプロイしていますが、今後はカスタムドメインを使ったアクセスを想定する必要があり、そのための変更を app_deployment_ingressample.yaml ファイルに反映させた上で再デプロイします。

この方法には2つあります。1つは旧サーバー名でのアクセスはできないようにした上でカスタムドメインでの新サーバー名のアクセスを許可する場合、もう1つは旧サーバー名でのアクセスを許可しながら(残しながら)カスタムドメインでの新サーバー名でもアクセスを許可する場合です。両方のケースを順に説明します。

まず旧サーバー名でのアクセスが不要になる場合は前者の(旧サーバー名ではアクセスできないようにする)ケースになります。この場合は app_deployment_ingressample.yaml ファイルの2箇所を以下のように書き換えます:
apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
#   - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    - hostname.pi314.jp
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
# - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
  - host: hostname.pi314.jp
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080

"#" で始まる行はコメントなので無くても構いません。要するに spec.tls.hosts と spec.rules.hosts の値を旧サーバー名ではなく新サーバー名に変更する、という作業が必要になります。

もう一方の、旧サーバー名でのアクセスを残しながら新サーバー名でもアクセスできるようにする場合は app_deployment_ingressample.yaml ファイルに新しい Ingress 設定を書き足す形で以下のように書き換えます:
apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
 - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.pi314.jp
  rules:
 - host: hostname.pi314.jp
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080

目的に応じた変更をした上で、改めて新しい yaml ファイルを使ってアプリケーションを再デプロイします:
$ kubectl apply -f yaml/app_deployment_ingresssample.yaml

再デプロイ後に新しいホスト名で https アクセスができるようになったことを確認します:
2021062401


以上、CIS + IKS( + Ingress ) の環境でカスタムドメインを使った https アクセスを実現するための設定手順でした。CIS は今回紹介した DNS 関連の機能だけでなく、本来得意とするセキュリティ強化の機能が簡単に使える強みもあるので、IBM Cloud を使って k8s 環境のアプリケーションを安全に使う上での非常に便利なコンパニオンサービスだと感じています。



IBM Cloud から提供されているユーザーディレクトリ管理サービスである App ID の UI カスタマイズに挑戦しています。自分的にはまだ道半ばではありますが、途中経過という意味でいったん公開・紹介します。


【IBM Cloud AppID とは?】
IBM Cloud App ID サービス(以下「App ID」)はアプリケーションで利用するユーザーディレクトリを管理するサービスです。オンラインサインアップを含めたユーザー管理機能を持ち、アプリケーションにログイン機能を付加させたい場合に非常に簡単にログイン機能を実装できるようになります。IBM Cloud の(無料の)ライトアカウントを持っていれば(2要素認証など、一部機能が使えなかったり、1日の実行回数などに制限もありますが)無料のライトプランで利用することも可能です:
2021052900



【IBM Cloud AppID のカスタマイズに挑戦した背景】
App ID はユーザー管理機能が必要なアプリケーション開発を行う上で非常に便利な一方、UIのカスタマイズに関する情報が少なく(管理メニューに用意されているのは、ログイン画面内にロゴ画像を貼り付けることができる程度)、ほぼあらかじめ用意された(英語メインの)画面を利用する必要がありました。

機能的には満足なのですが、この UI カスタマイズがどの程度厄介なものなのかを調べる意味も含めて、AppID の UI カスタマイズに挑戦してみました。結論として 2021/06/02 のこのブログエントリ公開時点では 100% の実装ができているわけではないのですが、ログイン画面およびパスワードリセット画面のカスタマイズには成功しているため、ここでいったん公開することにしました。


【IBM Cloud AppID のカスタマイズサンプル】
AppID UI カスタマイズを使ったサンプルアプリケーションのソースコードはこちらで公開しています:
https://github.com/dotnsf/appid_fullcustom


サンプルアプリケーションを利用するには IBM Cloud にログインして、App ID サービスのインスタンスを作成し、サービス資格情報を作成・参照する必要があります:
2021060201


そして以下の値を確認します:
{
  "apikey": "*****",
  "appidServiceEndpoint": "https://us-south.appid.cloud.ibm.com",
  "clientId": "*****",
  "secret": "*****",
  "tenantId": "*****",
    :
    :
}

これらの値をソースコード内 settings.js のそれぞれの変数に代入して保存します:
//. IBM App ID
exports.region = 'us-south';
exports.tenantId = '*****';
exports.apiKey = '*****';
exports.secret = '*****';
exports.clientId = '*****';

exports.redirectUri = 'http://localhost:8080/appid/callback';
exports.oauthServerUrl = 'https://' + exports.region + '.appid.cloud.ibm.com/oauth/v4/' + exports.tenantId;


※exports.region の値は appidServiceEndpoint の値の "https://" と ".appid.cloud.ibm.com" の間の文字列です。それ以外はサービス資格情報にかかれている値をそのまま記載します。

また exports.redirectUri の値はアプリケーションの OAuth ログインのリダイレクト先 URL を記載します。このサンプルアプリケーションでは 8080 番ポートで待ち受けて /appid/callback にリダイレクトする想定で作られているのでこのような値になりますが、実際にパブリックなインターネットで利用する場合はこの値を実際の URL 値に書き換えてください。

準備の最後に AppID サービスのリダイレクト URI にここで指定した export.redirectUri の値と同じものを登録します。サービスの「認証の管理」メニューから「認証設定」タブを選択し、「Web リダイレクト URL の登録」欄に export.redirectUri に指定した値と同じものを追加してください。これで準備は完了です:
2021060202


このサンプルアプリケーションを実際に動かしてみましょう。まずは npm install して node app で起動します:
$ cd appid_fullcustom

$ npm install

$ node app

8080 番ポートで待ち受ける形で起動するので、ウェブブラウザで http://localhost:8080/ にアクセスします。正しく動作すると http://localhost:8080/login にリダイレクトされ、以下のようなシンプルなログイン画面になります(この画面はカスタムUIで作った画面です):
2021060203


AppID サービスに登録した ID とパスワードを入力して "Login" します:
2021060204


ログインに成功すると、そのユーザーの名前などが表示される画面になります。この画面で "logout" すると元のログイン画面に戻ります:
2021060205


ログイン画面下部に2つのリンクがあります。「オンラインサインアップ」と書かれたリンクをクリックすると、オンラインサインアップ用の画面に切り替わります(この画面もカスタム UI です):
2021060201


ここでメールアドレスなどを入力してサインアップ可能です:
2021060202


サインアップしてしばらく待つと、メールアドレスの有効性確認を行う必要があるため、指定したメールアドレスにメールが届きます(なお、自分の環境では「迷惑メール」扱いで届きました(苦笑))。メールを開いてリンクをクリックし、有効性確認処理をしてください:
2021060203


メールアドレスの有効性が確認されるとオンラインサインアップが完了したとみなされ、これ以降はメールアドレスとサインアップ時に指定したパスワードでログインできるようになります:
2021060203


ログイン画面下部のもう1つのリンク「パスワードを忘れた場合」はパスワードリセット用のリンクです:
2021060204


こちらをクリックするとパスワードを忘れてしまったメールアドレスを指定する画面(これもカスタムUIです)が表示されるので、ここにパスワードを忘れたアカウントのメールアドレスを指定します:
2021060205


すると指定したメールアドレスにパスワードリセット用の URL が書かれたメールが届きます。このメールを開いて、URL にアクセスします:
2021060206


すると新しいパスワードを入力する画面(この画面だけはカスタムUIではなく、あらかじめ用意されたものです)が表示されるので、新しいパスワードを入力します:
2021060207


これで新しいパスワードを使って再びログインが可能になります:
2021060203


念の為、カスタマイズ無しの場合の AppID の各種画面UIを以下に紹介しておきます。(Your Logo Here) と書かれた箇所にロゴ画像を貼り付けることは可能ですが、それ以外のカスタマイズをしようとすると今回紹介したサンプルのような方法を取る必要があります。その代わり、これらの画面を使う場合は非常に簡単に実装することができるものです。

(ログイン画面)
2021060301

(パスワード忘れ)
2021060302

(オンラインサインアップ)
2021060303



【まとめ】
以上、AppID を独自のカスタム UI で利用する手順を紹介しました。一連の手順の中でパスワードリセット時の新パスワードを指定する画面だけは元の(英語の)UIになってしまっていますが、それ以外はすべて独自の UI で実現できているのがおわかりいただけると思います。この残った箇所の対応は前後関係含めて対応する必要があってちと面倒そうな印象も持っているので、いったんこの状況で公開しました。細かな実装についてはソースコードを参照ください。

便利な AppID を好みの UI で使えるメリットは大きいと思っていますので、興味ある方の参考になれば。


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 対応で運用することできるようになります。
 

今月(2018年5月)から GitHub ページがカスタムドメインでも HTTPS 対応された、という発表がありました:
Custom domains on GitHub Pages gain support for HTTPS

2018051001


というわけで、自分が取得しているドメインを使って試してみました。以下、GitHub ページの紹介と、その手順を含めた報告です。


GitHub ページとは?

GitHub ページとは GitHub の仕組みを使った静的ウェブサイトのホスティングサービスです。GitHub アカウントを持っていれば、誰でも簡単にウェブサイトを作って公開することができるので、非常に便利です。


GitHub ページの作り方

index.html 一枚だけの非常にシンプルな例で紹介します。まずは普通に Github でリポジトリを作成し、GitHub ページ(ウェブサイト)に含めたい HTML ファイルその他をまとめてプッシュし、公開します:
2018051002


この時点で、同リポジトリが GitHub で普通に公開されている状態になりました:
https://github.com/dotnsf/githubpagessample


(今回、公開する index.html ファイルの中身)
https://raw.githubusercontent.com/dotnsf/githubpagessample/master/index.html


次にこのリポジトリを GitHub ページとして公開します。リポジトリのページから "Settings" メニューを選択します:
2018051003


少しスクロールして GitHub Pages の設定欄を表示し、Source が None になっている所を "master branch" に変更して "Save" します。これでこのリポジトリのマスターブランチが Github Pages として公開されることになります:
2018051004


"Save" が成功すると画面内に GitHub Pages として参照する場合の URL が表示されます。一般的にはここは https://(ログイン名).github.io/(リポジトリ名)/ となります:
2018051005


この URL にアクセスしてみると、先程のリポジトリのマスターブランチが HTTP サーバーのドキュメントルートとして扱われる感じになり、index.html ファイルが表示されます。またこの画面からもわかるように、このページは HTTPS 対応しています:
2018051102


以上、ここまでが GitHub ページの説明です。


カスタムドメインで GitHub ページを使ってみる

今回の更新で、上記の GitHub ページがカスタムドメインでも HTTPS 対応されるようになりました。この点を確認したいので、まずは GitHub ページをカスタムドメイン対応してみます。

そのためには GoDaddyお名前.comなどのドメイン業者でドメインを取得しておく必要があります。ここはどうしても無料というわけにはいかず、ドメインの種類にもよりますが、1年間 $10 程度かかってしまうことを理解した上で取得してください。ちなみに自分は(B'z ファンでもないのに) welove.bz というドメインを GoDaddy で取得しているので、このドメインを使って GitHub ページをカスタムドメイン対応する手順を以下に紹介します。

最初に、対象ドメインの DNS 設定を変更する必要があります。このページの "Configuring A records with your DNS provider" という項目によると、ホスト名の A レコードの IP アドレスを以下のように設定する必要があるようです:
2018051103


A レコードの IP アドレスを複数設定できる場合はこの4つの IP アドレスを設定します。僕が使っている GoDaddy では1つしか設定できないようだったので、一番上のアドレスに指定しました:
2018051104


この部分は同様の作業をドメイン業者の用意したツールを使って設定してください。 なおこの作業について、詳しくは GitHub のドキュメントも参照ください:
https://help.github.com/articles/setting-up-an-apex-domain/


この作業の後で、GitHub の該当リポジトリに CNAME という名前のファイルを1つ追加します。CNAME ファイルの中身にはカスタムドメイン名だけを記載します:
2018051105


このファイルをリポジトリに add して commit して push します:
2018051106

2018051107


最後に再びリポジトリの settings 画面を確認して、GitHub ページのカスタムドメインが設定されている(されていない場合は、ドメイン名を入力して "Save")ことを確認します。これで GitHub ページのカスタムドメイン設定ができました:
2018051108


この状態で http://(カスタムドメイン名) にアクセスすると、先程まで ***.github.io ドメインで動いていた GitHub ページが表示されます:
2018051101


これで GitHub ページのカスタムドメイン化が完了しました。



カスタムドメイン GitHub ページの HTTPS 対応

やっと本題です(苦笑)。ここまでの作業で GitHub ページがカスタムドメインで利用できるようになりました。今回の目的は「このページを HTTPS 対応にする」ことです。

そのための設定はリポジトリの settings で、カスタムドメインを指定した下に "Enforce HTTPS" というフィールドがあるので、ここにチェックを入れるだけ・・・
2018051101



・・・なのですが、まだ証明書が有効になっていないようです(チェックできない)。こうなると作業としてできることはないので、ひたすら待つ必要があります。

ちなみに、この状態で無理やり HTTPS を指定して https://(カスタムドメイン名)/ にアクセスすると「安全な接続ではない」と言われます。ここから例外を承認して・・・ということもできないわけではないですが、せっかくなのでしばらく待ちましょう:
2018051102


しばらく待つとこの部分のメッセージが変わり、"Enforce HTTPS" がチェック可能になります:
2018051103


チェックするとこのような画面になり、このリポジトリの GitHub ページは強制的に(HTTP でリクエストしても)HTTPS でアクセスされるようになります:
2018051104


実際にアクセスしてみました。ちゃんと HTTPS に転送されています:
スクリーンショット 2018-05-11 15.38.40


HTTPS のインフォメーションを確認しても(オレオレ証明書とかではなく)"Secure Connection" になっていることが確認できます:
スクリーンショット 2018-05-11 15.39.12



(おまけ)
ではこの証明書は誰がどうやって発行しているのだろう? と疑問に思ったのですが、"Verified by: Let's Encrypt" だそうです。なるほどね・・・:
スクリーンショット 2018-05-11 15.38.58


めでたし、めでたし。
ところでこの welove.bz ドメイン、なんかいい使いみちないかな? (^^;


前2回の続きです:
IBM Bluemix にカスタムサービスを追加する(1/3)
IBM Bluemix にカスタムサービスを追加する(2/3)


前回作成した REST API を実際に IBM Bluemix のカスタムサービスとして登録し、利用するまで(正確には使用を終えてカスタムサービスから削除するところまで)の手順を紹介します。なおこの手順はコマンドラインツールである cf が必要になるので、インストールしていない場合は各自の環境にあった cf をあらかじめダウンロード&インストールしておいてください:
https://github.com/cloudfoundry/cli/releases


また、今回カスタムサービスとして登録する REST API は前回紹介した app.js が https://dotnsf-operation.mybluemix.net/ にデプロイされて動いているものとします。以下の説明でのこのホスト名部分を実際にみなさんがデプロイしたホスト名に合わせて読み替えてください:
2017021401

2017021401


まず最初に、以下で登録するカスタムサービスをバインドして動作確認するためのランタイムを用意しておきます。動作確認用のアプリケーション(後述)を PHP で用意したので、IBM Bluemix 上に PHP のランタイムを1つ作成します(以下の例では teyande-php-env という名前で作成しています)、なおこの段階ではサービスは何もバインドしないでください:
2017021402


このランタイムに以下の内容の PHP アプリケーションをプッシュします:
https://github.com/dotnsf/phpEnv


上記アプリケーション(index.php)はシンプルに「ランタイムサーバー上の全環境変数とその値を表示する」というアプリケーションです。プッシュ後にサーバーにアクセスすると以下のような画面になります。この時点ではサービスを1つもバインドしていないので、環境変数 VCAP_SERVICES の値は空オブジェクトを示す "{}" となっていることが確認できるはずです:
2017021403


ここまでで準備は完了です。では前回紹介したサービスを IBM Bluemix のカスタムサービスとして登録した上でインスタンス化し、このランタイムにバインドした上で、この環境変数がどのように変わるかを確認してみます。

コマンドプロンプトかターミナルを起動し、上記の PHP ランタイムと同じデータセンター(この場合は US-SOUTH)の自分の組織に cf コマンドでログインします:
2017021404


カスタムサービスを利用するにためには Cloud Foundry の「サービスブローカー」(カスタムカタログのように理解してください)に登録しておく必要があります。まず現在のサービスブローカー一覧を確認するため "cf service-brokers" コマンドを実行して、この時点では何も登録されていないことを確認します:
2017021301
 ↑"No service brokers found"(何も登録されていません)です


ではサービスブローカーを新規に1つ作成します。以下のパラメータを付けてコマンドを実行します:
> cf create-service-broker サービスブローカー名 認証ユーザー名 認証パスワード サービスの基本URL --space-scoped
2017021302


今回、サービスブローカー名は "dotnsf-operation" とします。認証のユーザー名とパスワードは dotnsf-operation の Catalog API などが実行される時用に指定した auth_user / auth_pass の値を指定します(詳しくは前回の記事参照)。サービスの基本 URL は今回 "https://dotnsf-operation.mybluemix.net" です。そして最後にオプションの "--space-scoped"(同一組織内のユーザーが使えるサービスとするための指定)を加えています。

コマンドが成功したことを確認し、再度 "cf service-brokers" を実行してみます。先程は結果に何も含まれていませんでしたが、今度は直前に作成したばかりの "dotnsf-operation" サービスブローカーが、指定した URL で登録されていることを確認してください:
2017021303


これで dotnsf-operation API がカスタムカタログに登録された状態になりました。ただ IBM Bluemix のウェブ UI ではカスタムカタログを表示する画面が存在していないので、この時点ではまだウェブ UI には現れませんが、cf からは同様にインスタンスを作成することができるようになっています。

というわけで、続けて cf でこのサービスをインスタンス化してみます:
> cf create-service サービスブローカー名 プラン名 サービス名

サービスブローカー名は dotnsf-operation の Catalog API(GET /v2/catalog) 内で定義したもの(今回の場合は dotnsf-operation-service)を指定します。プランも同様に Catalog API 内で定義したもの(今回は "free" と "enterprise" の2つ)の中から指定できますが、今回は "free" を指定しています。最後に IBM Bluemix 内でのサービス名として "dotnsf-operation-1" と指定しています:
2017021304


ここまでの手続きが完了すると、dotnsf-operation サービスがインスタンス化され、ウェブ UI の利用中サービス一覧の中にも表示されるようになります:
2017021301


この時点でサービスを選択し、管理タブを開くと Dashboard API で定義した内容が表示されるはずです(https で Dashboard API にアクセスできることが条件です):
2017021000


ではこのサービスを最初に作成した PHP ランタイムにバインドしてみましょう。PHP ランタイムの画面に移動し、接続タブの「既存に接続」をクリックします:
2017021302


現在利用中のサービスインスタンスの一覧が表示されます。その中に "dotnsf-operation-1" という名前のサービスが含まれているはずなので、これを選択して「接続」をクリックします。そしてこの内容をランタイムの環境変数にも反映させるため「再ステージング」します:
2017021303


改めて同ランタイムの接続タブを参照すると、"dotnsf-operation-1" サービスが追加されていることを確認できます。ここで「資格情報の表示」をクリックします:
2017021304


今回の dotnsf-service の Bind API では credentials 情報として uri だけを追加していました。そのためこのサービスインスタンスの資格情報にも uri 1つだけが credentials 情報として表示されていることが確認できるはずです:
2017021305


改めてランタイムのトップ画面にアクセス(リロード)します。今回は先程と異なり dotnsf-operation-1 サービスがバインドされているので、環境変数 VCAP_SERVICES は空オブジェクトではなく、dotnsf-operation-1 の情報が表示されているはずです。credentials 情報も先程確認したものと同じものが表示されています:
2017021306



・・・というわけで、IBM Bluemix のカスタムサービスを作成して、登録して、インスタンス化して、ランタイムとバインドして環境変数に反映させる、という一連の作業ができることを確認できました!

最後に使い終わったサービスブローカーを削除する手順を紹介しておきます。まず(同サービスブローカーを使っているランタイムからのバインドを全て解除した上で)サービス一覧画面からインスタンス化されたサービスを削除します:
2017021305


サービスが削除されるとウェブ UI からは見えなくなります。が、まだサービスブローカーには登録されているので、以下の cf コマンドでサービスブローカーからも削除します:
> cf delete-service-broker サービスブローカー名
2017021306


このコマンドが成功すると、サービスブローカー一覧からも削除されます。念のため "cf service-brokers" コマンドで確認します:
2017021307




久しぶりの超大作ブログとなり、3回に分けて紹介しましたが、IBM Bluemix のカスタムサービスを作るために実装しないといけない内容や、実装後の登録方法などを紹介できたつもりです。自分が作った REST API を IBM Bluemix に統合して使いたい場合や、公式なサードパーティ API としての登録を検討する場合に必要となる実装がどんなものかを説明しました。

今回紹介した内容はあくまで「同一組織内でのみ有効なカスタムサービス」の登録方法および手順の紹介でしたが、全 IBM Bluemix ユーザー向けに実装する場合であっても同様の API 実装は必要になります。そういったエコシステムを活性化する上での役立つ情報になれば幸いです。


(参考)
 https://www.ibm.com/blogs/bluemix/2017/01/extend-bluemix-service-broker/

このページのトップヘ