サービス名を変えたのでドメインの変更をしてみた
自己紹介
zacker(ざっかー)といいます。
アプリ開発が大好きな大学院生です。
「komichi」という2時間くらいの暇つぶしプランを作ってくれるサービスを作っています。
ぜひ、一度触ってみてください!
Instagram、TikTokもはじめたので、よろしければフォローをお願いします!
コトの経緯
「komichi」というサービスはもともと「poroto」という名前で運用していました。
なぜ、名前が変わったのかという経緯は ↓ の記事で紹介しています。
もし、よければチェックしてみてください!
この記事を読むと何がわかるか?
- すでに運用しているサービスの名前を変更するときに何が発生するか
- 既存の資源をどれだけ変更しなければならないのか
- サービス名を変更するときに注意するべき箇所
補足すると、拙作のアプリはユーザー数が片手で数えられる弱小サービスなので
大規模サービスと違い気軽に変更を行うことができます。
既にビジネス展開している場合は、ソフトウェアの範囲外のことも気に掛ける必要がありますが、
この記事では単純にサービス名を変更したときのソフトウェアの影響だけを紹介します。
利用している技術・サービス
影響範囲の説明も兼ねて、サービス内で利用している技術を紹介します。
要素 | 採用技術・サービス |
---|---|
フロントエンド | Next.js |
バックエンド | Gin(Golang) |
ホスティング | Google App Engine |
認証 | Firebase Authentication |
広告 | Google Adsence |
ドメイン管理 | Google Domain -> Squarespace |
やらなければいけないこと
- ドメインの取得
- DNSの登録
- Google Search Consoleからサイトマップの更新
- 旧サービス名を含む画像、コードを新しいものに置き換える
- 旧ドメインアクセス時に、新ドメインにリダイレクトする
- Google Adsenceのドメイン変更
- Firebaseの設定修正
全てを書くととても長くなるので
「ここは人によって違うだろうなぁ」というところだけをピックアップします。
どんな課題があるか?
旧ドメインで動作しているサービスを止めたくない
今まで知り合いにporoto.app
として宣伝していましたが、
アクセスしたときに404 Not Found
となってしまっては、
「開発をやめてしまったのかな 🤔」と思われてしまいます。
弱小サービスではありますが、既に存在を知ってくれている人への心がけは忘れたくありません。
どの順番で行うか
戦略としては、「とりあえず動く」を小さく積み重ねていくことです。
そうすると、うまくいかないときの原因を特定しやすく
何より小さな達成感を味わいながら作業できます。
-
影響範囲の調査
一番つらいのは手戻りの発生です。
そこで、まずは影響範囲の調査から始めました。
旧ドメインを参照している場所をgrepしたり
実際にアプリケーションを使って通信している場所を調べる地道な作業です。 -
Google App Engineと新しいドメインを結びつける
Google App Engineとドメインは1対1対応ではなく、複数のドメインを登録することができます。
旧サービスを止めないために、移行中は旧ドメインを残しながら、新しいドメインを追加します。
変更が完了すると、新しいドメインからアプリケーションを利用できるようになります 🎉 -
Firebase Authenticationの設定更新
Firebase Authentiacationではログインをするのに
認証元のドメインを指定する必要があります(今回はkomichi.app
)。
修正が完了すると旧ドメインのログイン機能を維持しながら、新ドメインからもログインを行うことができます。 -
ソースコードの変更
サービス名やリンク、ロゴ等の画像を書き換えていきます。 -
🚀 デプロイ
これでアプリケーションの準備は整ったのでデプロイを行います。 -
旧ドメインにアクセスしたときに、新しいドメインにリダイレクトする
poroto.app
というドメインをしっているユーザーに新しいサービス名を知らせるためです。
半年くらいはこの運用を続けるつもりです。 -
Google Adsence, Analyticsの設定更新
アプリケーションの動作に関わらない分析や広告に関わる部分はデプロイ後に修正を行いました。
Google Adsenceは今まで利用していたものに、新しいドメインを追加登録するだけで完了です。
広告ID等も変更が無いので、コードの修正は発生しませんでした。
ただ、新しいドメインの承認が完了するまでに2週間程度かかりました。
アプリケーション内の旧サービス名を新サービス名に置き換える
このときはまだ、新しい名前が決まったばかりで
新しいアプリロゴができていなかったため
grepで置換できる場所だけ置換を行い、
画像などの資源は別のPRで修正を行うという方針で進めました。
システム名を変更するか?
システム内の名称やリポジトリの名前まで変更するかという判断がありました。
結論からいうと、ユーザーに見えない部分は修正を行いませんでした。
私はサービス名はUIのように、「変化しやすい」ものと考えています。
そのような変更をシステムが全てうけてしまうと、その度に改修が必要となるため大変です。
したがって、ユーザーに見える部分だけを変更することにしました。
バックエンドの修正
「ユーザーに見える部分だけ変更する」という方針をとったため、
バックエンドの修正はCORSの許可設定の修正のみとなりました。
フロントエンドの修正
フロントエンドを修正していて感じたのは、アプリロゴ等のファイル名は
具体的なサービス名ではなく、logo.png
のようにすると、
それを参照するコードを変更する必要がなく楽だなと思いました。
また、grepしまくるのがつらかったので
URLが含まれるところだけ環境変数として切り出しました。
ロゴを新しいものに置き換える
アプリケーション内で用いているものに加えて、以下のものを変更しました。
- OGP画像
- PWA用のアプリロゴ
- favicon
それぞれ便利なツールがあるのでご紹介します。
PWA用のアプリロゴの作成
PWAを利用する端末やブラウザによってアプリアイコンの形が異なることがあります。
(画像はProgressierから引用しました。)
このようにアイコンの外枠の形が変わっても、アイコンが見切れたりしないように
いい感じにしてくれるサービスがあるようなので、
こちらを用いてもととなるアイコン画像を作成します。
このアイコン画像から、以下のサービスを用いて複数サイズのアイコンを作成しました。
faviconの作成
svg画像からも作ることができるので、画質の劣化を防ぐことができます。
旧ドメインアクセス時に、新ドメインにリダイレクトする
最初はDNSの設定を修正するのかなと思いましたが
調べてみるとNginx等のWebサーバやアプリケーションを修正する必要があるようです。
GAEでのルーティング設定
komichiではGoogle App Engine(GAE)を利用しています。
GAEではアプリケーションはサービスという単位で管理されます。
GAEではdispatch.yaml
という設定ファイルを用いて
サービスごとのルーティングの設定を行うことができます。
具体的に、フロントエンドのサービスがdefault
サービスとして起動していて
以下のようにルーティングしたいとします。
リクエストURL | ルーティング先 |
---|---|
example.com | default サービス |
これに対応するdispatch.yaml
は、このようになります。
dispatch:
- url: "example.com/*"
service: default
バックエンドをサービス(backend
)を増設したいとなっても簡単です。
リクエストURL | ルーティング先 |
---|---|
example.com | default サービス |
backend.example.com | backend サービス |
dispatch:
- url: "example.com/*"
service: default
- url: "backend.example.com/*"
service: backend
このルーティング機能を使って、poroto.appに来たリクエストを
「すべてのリクエストをkomichi.appにリダイレクトするくん」に割り当てます。
これによって、poroto.appのリクエストをkomichi.appにリダイレクトするようにします。
リダイレクト専用のサーバを建てる
やることが決まれば、あとは簡単です。
以下のように、Express.jsを使ってリダイレクト専用サーバを起動します。
const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;
app.use((req, res) => {
res.redirect(301, 'https://komichi.app');
});
app.listen(PORT, () => {
console.log(`Server is running on http://localhost:${PORT}`);
});
GAEにデプロイするための設定ファイルを用意して
runtime: nodejs20
service: redirect-komichi
デプロイします🚀
gcloud app deploy
poroto.appに来たリクエストをこのサービスに紐づけるようにして
dispatch:
...
- url: "poroto.app/*"
service: redirect-komichi
ルーティングの設定を反映させます。
gcloud app deploy dispatch.yaml
これで、リダイレクトができるようになりました。!
沼ったところ
Firebase Authenticationの承認済みドメインの追加
認証済みドメインの追加はFirebaseの設定画面から行うことができます。
これだけで新しいドメインからログインできて、めでたしめでたし
……となると思いきや、そうは問屋が卸しません。
ブラウザからFirebaseを利用するときには、Firebaseが発行したAPIキーを用います。
私はこのAPIキーに対して、リクエストもとの制限をかけていたため利用することができませんでした。
設定を変更するには Google Cloud コンソール > APIとサービス > 認証情報 のページに移動し、
対象となる鍵の「ウェブサイトの制限」に以下のように新しいドメイン名を追加する必要があります。
Next.js によるリダイレクト
Next.jsのmiddlewareという機能を使うと、Next.jsに来る全てのアクセスに対して介入することができます。
この機能を使って以下の用にリダイレクトを行おうとしました。
export function middleware(req: NextRequest) {
const { hostname } = req.nextUrl;
if (hostname === "poroto.app") {
const url = new URL("https://komichi.app/");
return NextResponse.redirect(url, 301);
}
return NextResponse.next();
}
しかし、実際にデプロイしてみると、poroto.app
に来たリクエストも
hostname
がlocalhost
となってしまい、うまく動作しませんでした。
有識者の方がいれば教えていただけると嬉しいです!
おわりに
このような記事を書くのが初めてなので、読みづらい部分がたくさんあったと思います🙇
これからも少しずつ発信を続けていきたいと思うので、ウォッチしてもらえると嬉しいです!
おしまい。
Discussion