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

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

タグ:domain

Google Apps(無料版)を使って所有するドメインのメール環境を続けてきましたが、無料期間が終了することになり、メールアカウントを残すにはメールサーバー環境を引っ越す必要が生じました。

先日、このブログで Zoho メールで独自ドメインメールを無料運用するための手順を紹介しました。これは1つの解決策ではありますが、5ユーザーまでとか、添付ファイルは最大25MBとか、これまでの環境からの移行としては少し制約の大きなものでもありました(無料、という非常に大きな魅力はありますけど)。
http://dotnsf.blog.jp/archives/1080247716.html

2022030501



ただこの Zoho メールを使う方法には隠れた制約がありました。手順内でも紹介しているのですが、独自ドメインメール環境を申請するためには、その独自ドメインではないメールアドレスを使ってアカウントを作成する必要があり、そのメールアドレスは他のドメインのメール環境には使えないのでした。つまりドメインを複数所有していて、その複数のドメインを全て Zoho メール(無料版)に移行するには同じ数のメールアドレスが必要でした。これは無料メールアカウントを複数発行すればできなくはないのですが、管理対象のメールアドレスが増えるだけでなく、どのメールアドレスをどのドメインの申請に使ったかを把握しておく必要も生じてしまい、色々面倒な運用になってしまいそうでした。


この状況を避けるべく、(無料ではないが)格安で独自ドメインのメール環境を用意してくれる環境を用意することにしました。その例として今回申し込んだのはさくらインターネット様の「さくらのメールボックス」サービスです:
https://rs.sakura.ad.jp/mail/

2022032500



サービス内容はこんな感じです:
・独自ドメインを20個まで利用可※
・メールアドレス数は無制限※
・容量は(全ユーザーの合計で)20GB
・1年間で 1048 円(2週間の無料お試し可)


※異なるドメインの同じ名前のユーザー(例えば admin@domain1.com と admin@domain2.net)のメールアドレスを別々に作ることはできず、いずれのアドレス宛のメールも同じメールボックスに届きます。


データ容量自体は全ユーザーの合計で 20GB と、Zoho メール(1ユーザーあたり 5GB で、5ユーザーまで)と比べても小さいのですが、独自ドメインを 20 個まで登録できることに加え、メールアドレスを無制限に持てるというアドバンテージがあります(ユーザーあたりのメール容量があまり大きくないケースであればこちらのほうが向いている可能性があります)。また価格も個人利用と考えても決して高くはなく、このくらいならお小遣いでなんとか・・・ というレベルだと思っています。

今回、これまで Google Apps でメール運用してきた所有ドメインの1つ(welove.bz)をさくらのメールボックス環境に移行してみたので、その手順を記録として残しました。他のドメイン※も同様に移行するつもりですが、その内容を以下に公開します。なお以下の作業は「 Google Apps からの移行」に特化した内容はほぼなくて(現在どこで運用してるとかしてないとかに関係なくて)、単に「さくらのメールボックスで独自ドメインのメールを運用するための設定」の紹介となります。


※ドメイン管理を移管する場合、「さくらのインターネット」へのドメイン移管ができるのは .com, .net, .org, .info, .biz, .tokyo, .mobi のみのようです。今回はドメインの移管をせずに DNS の設定だけで実施する方法を紹介します:
https://help.sakura.ad.jp/206205811/#trouble01



【「さくらのメールボックス」と契約】
契約手続きそのものを詳しく紹介するつもりはありませんが、何はともあれ「さくらのメールボックス」と契約する必要があります。上述のページから「2週間無料ではじめる」と書かれたリンクをクリックして契約内容を入力していきます。クレジットカードが必要ですが、特に難しいことはないと思います:
2022032501


契約が完了すると、さくらインターネットの会員メニューにログインできるようになり、「契約中のサービス一覧」に「さくらのメールボックス」が表示されるようになります。この時点ではまだ独自ドメインの設定はできていませんが、初期ドメインと呼ばれる *****.sakura.ne.jp という値が付与されます。この値は後で DNS 設定時に使うので覚えておきましょう。

この「コントロールパネルを開く」と書かれたボタンをクリックして独自ドメインを含むメールボックスの設定画面に移動します:
2022032502


サーバコントロールパネルというサーバーの設定変更画面にログインします。契約時に送付されたドメイン名とパスワードを入力して「ログイン」ボタンをクリックします:
2022032503


ログインに成功すると以下のような「サーバコントロールパネル ホーム」画面が表示されます。ここから独自ドメインを利用するための設定を行っていきます:
2022032504


以下では自分が所有していて、Google Apps で運用していた "welove.bz" というドメインのメール環境を移行する様子を紹介します。なお、このドメイン自体は GoDaddy.com で取得したものです。他のドメインプロバイダーを使っている場合は一部異なる設定内容が含まれると思いますのでご了承ください。


【「さくらのメールボックス」で独自ドメイン利用の設定】
改めて「さくらのメールボックス」のコントロールパネルを使って独自ドメインのメール環境を構築します。今回は自分が取得している独自ドメイン(welove.bz)のメールサーバー環境を構築する様子を紹介します。

画面左のメニューから「ドメイン/SSL」 - 「ドメイン/SSL」 を選択します:
2022032501


ドメイン/SSL の設定画面になり、現在までに登録されているメールのドメイン(デフォルトの1つ)が表示されています。ここで「ドメイン新規追加」をクリックします:
2022032502


「ドメインの新規追加」画面に切り替わります。追加するドメインの指定方法によっていくつかの選択肢が用意されていますが、(これから取得して追加するのではなく)すでに取得済みのドメインを追加する場合は画面下にスクロールします:
2022032503


ドメインの管理そのものを移管する場合は「他社で取得したドメインを移管して使う」から先に進むことになりますが、今回はドメイン管理をそのままにして、メールサーバーの設定のみを行います※。というわけで一番下までスクロールして「他社で取得したドメインを移管せずに使う」の「追加」をクリックします:
2022032901


※上の画面にも書かれていますが、このオプションはさくらのブログでの動作を保証していないようです。


次の画面ではメールサーバーで移管するドメイン(下図では "welove.bz")を指定して「追加」します。ネームサーバーについて云々・・・と書かれていますが、今回ネームサーバーを現行のものから変更するつもりはないので、ここは無視します:
2022032902


するとドメイン/SSL の画面に戻り、指定したドメインが追加されていることを確認します:
2022032903


さくらのメールボックス側で必要な作業は以上です。続けてドメインを管理しているプロバイダー側での DNS 設定画面で変更作業を行います。



【「さくらのメールボックス」向けの DNS 設定変更】
対象ドメインの DNS 変更を行います。自分の場合、対象ドメイン(welove.bz)を GoDaddy.com で取得&管理しているので、以下は GoDaddy.com での作業イメージとなります。が、他のプロバイダーでも同様の作業を行えばよいだけなので、以下のスクリーンショットを参考に同様の作業を行ってください。

具体的には対象ドメインの MX レコードを編集します。またメールサーバーを mail.welove.bz のような名称にしたい場合は合わせて CNAME レコードも編集します。 というわけで、対象ドメインの DNS 管理画面に移動します:
2022032901


まずは MX レコードを以下のように変更(または追加)します。これ以外の MX レコードが存在していたら併せて削除します:
ホスト名: (対象ドメイン名)
TYPE: MX
VALUE: xxxxx.sakura.ne.jp(初期ドメイン名)
状態: 有効
優先度: 10 (など、適当な値)
2022032901


また単にさくらのメールボックス機能を使うだけでなく、メールサーバーに mail.welove.bz という名前をつけて管理したい場合は以下の CNAME レコードも追加します。なお、これをやっておくとウェブメール以外の(POP3/IMAP/SMTP などの)メーラーを使う際のメールサーバーを "mail.welove.bz" などと指定できるようになります:
ホスト名: mail  (メールサーバーを mail.対象ドメイン名 にしたい場合)
TYPE: CNAME
VALUE: xxxxx.sakura.ne.jp(初期ドメイン名)
状態: 有効
2022032902


これで DNS の設定も終わりです。スクリーンショットは GoDaddy.com のものでしたが、他のプロバイダーを使っている場合も同様の作業をすればいいはず。

あとはしばらく(TTL次第ですが、おそらく数分)待てば指定したドメインのメール環境が整います。すでにさくらのメールボックスにユーザーの登録が済んでいればすぐに使えるようになりますが、まだの場合はユーザーを登録します。


【「さくらのメールボックス」へのユーザー追加】
さくらインターネットのサーバーコントロールパネルに戻ります。今回はメールのユーザーを指定するので「メール」メニューを選択してメールアドレスの一覧を表示し、「新規追加」ボタンをクリックします:
2022032901


新規に登録するユーザーの情報を入力します「ユーザ名」と書かれた部分がメールアドレスの @ の左にくる部分となります。また「パスワード」も必須情報です:
2022032902


全ての情報が入力できたら画面下の「作成する」ボタンをクリックします:
2022032903


メールアドレス一覧画面に戻ります。作成したユーザーが追加されていることを確認します:
2022032904


【「さくらのメールボックス」のウェブメールを使う】
ドメイン側の設定変更が済んでいればウェブメールを使うことができるようになります。ウェブメールを使うには以下の URL にアクセスします:
https://secure.sakura.ad.jp/rscontrol/?webmail=1


認証を聞かれるのでメールアドレスと(作成時に指定した)パスワードを入力してログインします:
2022032901


ウェブのメール画面が開きます。この画面を使って受信メールを確認したり、送信・返信が可能です:
2022032902


なお、さくらのメールボックスでウェブメールを使う場合はこちらのドキュメントも参照ください:
https://rs.sakura.ad.jp/function/webmail/

またウェブメール以外の各種メーラーやその設定についてはこちらを参照ください:
https://help.sakura.ad.jp/mail/



同様にして(プラン容量内であれば)更にドメインを追加したり、ユーザーを追加して使うこともできます。ドメインの移管をしない場合は、現行のドメインプロバイダーによって DNS の設定方法が異なるため、画面とかは用意できないのですが、ちょっとした手間をかけるだけで実現できるはずです。また Cloudflare などのドメインレベルでのファイアウォールを使っている場合だとメールのためにドメインの移管をするわけにもいかない(この影響がデカい)ので、この方法のほうがより柔軟性高く実現できると思っています。



Google Apps の無料運用が終わることになり、これまで運用してきた独自ドメインのメールアカウントをどこかへ移行する必要が生じました。

いくつかの移行先候補の中で、「無料で」続けることができる数少ない選択肢が Zoho メール だと思っています。というわけで、Google Apps からの移行を視野に入れて、Zoho メールで独自ドメインのメールアカウントを運用する方法を調べました(ちなみに以下のスクリーンショットを撮った時には FireFox を使っています):
2022030500


【Zoho メールとは】
個人や小規模組織を対象に無料のメール環境を提供しています。GMail 同様、個人でも @zohomail.jp ドメインのメールアカウントを取得することもできますが、今回は独自ドメインでメールを運用できる点に絞って紹介します。なお無料で Zoho の独自ドメインメールを運用する場合の条件は以下のようになります:
・最大5ユーザー
・1ユーザーあたり 5GB のメール容量
・添付ファイルは最大 25MB まで
・Webメールとモバイルアプリのみ(POP3/IMAPなし)



【Zoho メールを独自ドメインで利用するまでの手順】
以下に実際に自分が所有しているドメイン(yellowmix.net)で利用できるようにするまでの手続きの様子を紹介します。Zoho は Zoho Japan が日本人向けのサービスも提供していますが、この Zoho メールの手続きは途中から英語のみになるので、その点にご注意ください。

まずは Zoho メールのトップページへ行き、「広告表示なしメールの使用を開始する」と書かれた箇所で「メールアドレス」を選んで「無料プランに登録する」ボタンを選択します:
2022030501


※ちなみにここで「個人向け」を選ぶと、@zohomail.jp ドメインの無料メールアカウントを取得できます。

このような画面が表示されます。この辺りは有料サービスなので下にスクロールします:
2022030502


「永久に無料のプラン」と書かれたサービスの「無料お試し登録」をクリックします:
2022030503


次の画面では新たに申し込むアカウントの設定に利用する氏名とメールアドレス(今回申し込むメールアドレスのドメインとは別のもの)、そしてパスワードを入力します(既にそのメールアドレスで Zoho のアカウントを取得している場合はログインします)。最後に「登録する」ボタンをクリックします:
2022030501


Zoho メールの設定ウィザードがスタートします。まずはドメインを追加します。今回は既に所有済みのドメインを利用するため「既存のドメインを追加する」「今すぐ追加する」ボタンをクリックします:
2022030502


以下のようなダイアログが表示されるので、登録するドメイン名(www. が表示されているので、そこに続けてドメイン名を入力)、組織名、そして組織の分類(自分は IT を選びました)を指定して「追加する」を選択します:
2022030503


すると次のような画面になり、ドメインの追加ができました。ただ本当にこのドメインを所有しているかどうかを確認する必要があります。続けて「ドメイン認証に進む」をクリックします:
2022030501


ドメインの所有権を認証する画面が表示されます。ここから先はドメインを取得したプロバイダーによって作業内容が変わると思いますが、自分の場合は GoDaddy.com でこのドメインを取得しており、GoDaddy.com の場合は左の「自分の DNS にログインする」を選ぶことで先にすすめることができました。以下、この方法を選んだ場合として説明を続けます:
2022030501


「自分の DNS にログインする」を選択すると DNS プロバイダー(自分の場合は GoDaddy.com)へのログイン認証が行われるので、該当プロバイダーへログインする ID とパスワードを入力してサインインします:
2022030502


正しくサインインできると、Zoho Mail Hosting を有効にする許可を与えるかどうかの確認画面になります。内容を確認して「接続」をクリックします:
2022030503


すると元の画面に戻り、「ドメインの所有者が確認されました」のメッセージが表示されます。これで指定したドメインを本当に自分が取得していることを証明できました。

続けてこのドメインでのユーザーを作成します。

"Your login mail address" と書かれたテキストフィールドに作成するメールアドレスを入力(@yellowmix.net は入力済みなので、その前の部分を入力)して、「作成する」をクリックします:
2022030501


すると以下のような画面が表示され、ユーザーが追加されたことが確認できます。必要に応じてここで「追加する」を選択して、このドメインのメールユーザーを(無料プランであれば最大5ユーザーまで)追加できます。ユーザーの追加が完了したら「グループの設定に進む」をクリックします:
2022030501


グループはユーザーが共有して利用することができるメールアドレスです。必要に応じて「作成する」からグループを作成してください(不要であれば作る必要はありません)。次に進む場合は「DNSの関連付けに進む」をクリックします:
2022030502


次に MX レコードなどのメール用 DNS 設定を行います。が、この前の手続きでドメイン認証が済んでいれば「MX、SPF、DKIM を自動で設定できます」ボタンをクリックするだけです:
2022030503


続いてデータ移行の画面になります。既存メール環境からのデータ移行ができるようですが、今回の自分の場合は新規のメール環境登録なので既存メール環境がありません。ここは何もせずに次の「モバイル設定に進む」を選択しました。ここは実際に試した人からの情報があればいただきたいです:
2022030501


スマホからこのメールを使うための設定画面です。といっても実際にはモバイルアプリへのリンクがあるだけのページでした。必要であればこのページのリンクから Zoho メールのモバイルアプリをダウンロード&インストールしてください。最後に「設定の完了に進む」をクリックします:
2022030502


※上のリンクをクリックするとこのような画面になって、モバイルアプリのダウンロードができるようです:
2022030503


これで全ての設定が完了しました。「受信トレイを確認してください」をクリックします:
2022030501


新しいメール環境が確認できるようになりました。が、改めて最初からのアクセス方法を確認するため、一旦ログアウトしましょう。右上のアイコンをクリックします:
2022030502


そして「サインアウトする」を選択して、サインアウトします:
2022030503



では改めて Zoho メールに作成した独自ドメインのユーザーでログインしてメールを使ってみます。まずは Zoho メールのトップページにアクセスします:
https://www.zoho.com/jp/mail/


そして右上の「サインイン」をクリックします:
2022030501


先程登録した独自ドメインのユーザー名とパスワードでサインインします:
2022030502


初回ログイン時には2段階認証を有効にするよう注意画面が表示されます。必要に応じてここで2段階認証を有効にしてください(後から設定することも可能です)。ここでは一旦「後で確認する」をクリックして先に進みます:
2022030501


これで Zoho メールを送受信できる画面に移動できました!安全のため2段階認証も有効にしておきましょう:
2022030501



以上、独自ドメインを Zoho メールで運用する場合の設定手順を紹介しました。1ドメインあたり5ユーザーまで、というのが個人的にはちと厳しい気もするのですが、Google Apps 亡き今となっては無料で独自ドメインメール運用ができる環境の選択肢そのものが少なく、無料となると(格安のはいくつかありますが)個人的にはここしか知りません。この5ユーザーの範囲内でうまく使っていけると、Google Apps 難民にとっても有用な移行先であるように思えました。


かなり以前に 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 環境のアプリケーションを安全に使う上での非常に便利なコンパニオンサービスだと感じています。



普段、あまり Windows サーバーを使うことがない中でクラウド上の Windows サーバーにリモートデスクトップ接続をして作業する、という機会がありました。そこで遭遇したトラブルと、その解決方法の自分向け備忘録です。


まずは発生したトラブルの状況を説明します。某クラウド上に Windows サーバーインスタンスを作成・用意しました。ログイン時のクレデンシャル(ユーザー名&パスワード)も分かっていて、サーバー・ネットワークへの VPN も接続したのでプライベート IP アドレス宛で接続することができるはず、という状況です:
2020091501


いざリモートデスクトップ接続を試みます。コンピューター欄に IP アドレス、そしてユーザー名にはログイン用のクレデンシャルで確認したユーザー名(図では Administrator)を指定して「接続」します:
2020091502


するとログインパスワードを聞かれます、ここまでは想定通り。同様にしてクレデンシャルで確認ずみのログインパスワードを入力して「OK」をクリック。これでリモートデスクトップ接続できるはず・・・:
2020091503


・・・だったのですが、エラーが発生してログインに失敗してしまいました。入力ミスはしていないし、ネットワーク的に繋がっていない相手だとしたらパスワードを聞かれることもないし、、、原因はなんだろう?? と、よく見るとユーザー名が入力した "Administrator" ではなく "Administrator@xxx.xxx" となっていました。なお "@xxx.xxx" 部分は会社のドメイン名です。何度か同じ手順を実行したのですが、常にこのドメイン名部分が自動的に(というか勝手に)付加されてしまい、正しいログインユーザー名ではなくなっていました。ログインエラーの原因はおそらくこれでしょう:
2020091504


作業に使った Windows PC は会社貸与のもので、詳しくはわかりませんが会社の運用ポリシーに従って集中管理されているものです。おそらくですがその関係でリモートデスクトップ接続時のログインユーザー名に "@xxx.xxx" というドメイン名までが(自動的に)付与されてしまっているのだと思います。この辺りあまり詳しくないのですが、そう考えるとこの挙動自体は納得できるものではあります。

ただログインユーザー名が勝手に変更されてしまっては、いつまでたってもクラウドの Windows サーバーにログインすることができません。会社側の運用ポリシーに原因があるのだとすれば、その運用ポリシーを変更することでも解決できるかもしれませんが、残念ながら(多くのケースがそうであると想像しますが)自分は運用ポリシーを変更できるような立場ではありません。直接の原因の究明も去る事ながら、この状況を Windows ユーザー側の操作だけで解決する方法はないか? というのが今回のブログテーマでした。


で、その応急処置的な解決方法がわかりました。先程のエラー画面内の「その他」と書かれた箇所をクリックします:
2020091505


するとログインユーザーを選択する箇所が表示されるので、まずはここで「別のアカウントを使用する」を選択します:
2020091506


改めてログインユーザー名とパスワードを入力する画面に遷移します。ここでログインユーザー名の頭に .\ を付けたものを指定します(パスワードは本来のものをそのまま指定します)。そして「OK」を押します:
2020091507


環境によってはセキュリティ証明書に関する警告ダイアログが出ることがあるかもしれませんが、その場合は「はい」を選択します:
2020091508


すると無事にリモート先の Windows デスクトップが表示されました!:
2020091509


運用ポリシーによって会社ドメインが強制されてしまうようなケースでも、ログイン名の頭に .\ を付けることでログインユーザー名のドメインを強制指定して上書きすることでなんとかエラーが回避できるようでした。


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

このページのトップヘ