インフラ

準備中のサイトを、URLでは共有したい。でも、検索や一般ユーザーにはまだ見せたくない。 Hugoで作っているサイトの公開前チェック、WordPressのリニューアル確認、ローカルで動かしている検証アプリの共有では、この状態がよくあります。自分だけで見るならlocalhostで足りますが、確認相手に見てもらうには外から開けるURLが必要です。 そこで使いやすいのが、Cloudflare Zero TrustのAccessです。 この記事では、preview.araisun.comのような確認用ホスト名にCloudflare Accessをかけ、許可したメールアドレスだけOne-time PINで通す流れを整理します。Cloudflare Tunnelは「previewを外へ出す道」として短く扱い、Tunnel自体の作り方はローカルで立ち上げたサーバーをSSL経由で外部URL公開できるCloudflare Tunnel に任せます。 主役は、Cloudflare Accessのapplication、policy、One-time PIN、動作確認です。 先に結論 Cloudflare配下のドメインで準備中サイトを共有するなら、Basic認証だけでなくCloudflare Accessも候補になります。 Accessを使うと、originへリクエストを通す前にCloudflare側で認証できます。確認してほしい人のメールアドレスをAccess policyに入れ、その人だけOne-time PINでログインできるようにします。共有するのは共通パスワードではなくURLとメール認証の案内です。 今回の例では、preview.araisun.comを準備中サイトの確認用URLにします。Access applicationでこのホスト名を保護し、policyで許可メールを指定し、許可メール、未許可メール、別ブラウザ、スマホ回線、Access logsを順番に確認します。 Tunnelを使う場合でも、この記事ではTunnelの細かい手順には入りません。Tunnelは公開URLへつなぐ道、Accessはその手前で誰を通すかを決める関門、と分けて考えます。 Cloudflare Accessで守れるもの Cloudflare Accessは、Cloudflareを通るリクエストの前段に認証レイヤーを置く機能です。self-hosted applicationとしてpreview.araisun.comのような公開ホスト名を登録し、Access policyに一致したユーザーだけをoriginへ通します。 準備中サイトで使うなら、守る対象は次のような入口です。 preview.araisun.comのホスト名全体 /adminのような特定path stagingやpreview用のサブドメイン この記事では、準備中サイト全体を見せるか見せないかを制御したいので、preview.araisun.com全体を保護対象にします。/adminだけを守る設定にはしません。 Access applicationは、作っただけで全員を通すものではありません。基本は「許可条件に一致した人だけ通す」という考え方です。だから、applicationを作ったあとに、誰を通すかをAccess policyで決めるところが重要になります。 ただし、Accessが守れるのはCloudflare経由の入口です。VPSやnginxのorigin IP、別ホスト名、直アクセス用の経路が残っている場合は、そこから迂回される可能性があります。この点は後半で分けて確認します。 Basic認証とAccessの使い分け Basic認証は、origin側でIDとパスワードを確認する方法です。nginxやApacheで設定でき、Cloudflareを使わない環境でも動きます。短期間の簡単な保護や、自分だけが見るページなら今でも選択肢になります。 一方で、確認相手へ見せる運用になると、Basic認証には少し面倒なところがあります。 IDとパスワードを相手へ送る必要がある 複数人へ同じパスワードを共有しがち 確認が終わった人だけ外す運用がやりにくい ブラウザ標準の認証ダイアログが確認用として少し硬い Cloudflare Accessなら、確認してほしい人のメールアドレスをpolicyに追加します。確認が終わったら、そのメールアドレスを外します。共通パスワードを配って後から変更するよりも、人単位の出し入れがしやすくなります。 もちろん、AccessがBasic認証を常に置き換えるわけではありません。Cloudflareを使っていない環境、サーバー内だけで完結したい環境、単純な一時保護ならBasic認証の方が早いこともあります。 すでにCloudflareをCDN / proxyとして使っていて、メールアドレス単位で少人数に見せたい。そういう準備中サイトでは、Accessの方が自然に扱える場面があります。 Tunnelは道、Accessは認証の関門 Cloudflare TunnelとCloudflare Accessは、役割を分けて考えると混乱しにくくなります。 Cloudflare Tunnelは、ローカルサーバーやprivateなoriginをCloudflareへつなぐ道です。たとえばローカルでHugo previewを動かしているなら、Tunnel側では次のような対応を作ります。 preview.araisun.com -> http://localhost:1313 この設定を作ると、preview.araisun.comからローカルのHugo previewへ届く道ができます。Tunnelの作成、public hostname、DNS、cloudflaredの常駐化などはCloudflare Tunnelの記事 で扱っているので、ここでは広げません。 Accessは、その道の手前に置く認証の関門です。preview.araisun.comに来た人をCloudflare側で止め、メールアドレスとOne-time PINで確認します。許可した人だけをTunnelの先へ通し、Hugo previewを見せます。 ...

Cloudflare Tunnelを使うと、手元のPCやVPSで動いているHugoのローカルプレビューを、ポート開放なしでHTTPSの外部URLとして公開できます。 自分のブラウザだけで確認するならlocalhost:1313で十分ですが、誰かに見てもらうには外からアクセスできるURLが必要です。 開発中に一時的に共有したいだけなら、cloudflared tunnel --urlで十分です。 同じURLを継続して使いたい場合は、Cloudflare管理下の独自ドメインをTunnelへ紐付けます。 この記事では、一時URLで試す最短手順と、preview.example.comのような固定URLにする手順を分けて整理します。 先に結論 Hugoのローカルプレビューを一時的に外部共有したいだけなら、次の2ステップで足ります。 Hugoのローカルサーバーをhttp://localhost:1313で起動する 別ターミナルでcloudflared tunnel --url http://localhost:1313を実行する これでtrycloudflare.comの一時的なHTTPS URLが払い出されます。 確認相手へそのURLを送れば、相手は自分のブラウザからHugoプレビューを見られます。 同じURLを継続して使いたい場合だけ、cloudflared tunnel login、cloudflared tunnel create、config.yml、cloudflared tunnel route dnsへ進みます。固定URL化する場合は、Cloudflareに追加済みのドメインと、Cloudflare側のDNS管理が必要です。 Cloudflare Tunnelでできること Cloudflare Tunnelは、ローカルやprivateなoriginをCloudflareへつなぐための仕組みです。 Hugoのプレビュー用途では、次のような場面で便利です。 公開前の記事やデザインを、固定URLで確認してもらいたい ルーターやVPS側のinboundポートを開けずに、外部から見える確認URLを作りたい 手元のHugoサーバーを、HTTPSでスマホや別のネットワークから確認したい 最初は一時URLで試し、必要になったらpreview.example.comのような固定URLにしたい 逆に、公開サーバーとして恒久運用するなら、Tunnelだけでなく、再起動、ログ、監視、nginx側の設定も別で考える必要があります。VPS上で本番配信する流れは、Ubuntuでnginxを導入して最初の公開設定をする手順 も参考になります。 Cloudflare Tunnelは何をしているのか cloudflaredは、手元のPCやVPS上で動くCloudflare Tunnel用のコネクタです。 外から直接localhost:1313へアクセスするのではなく、cloudflaredがローカル側からCloudflareへoutbound接続を張ります。ブラウザから来たリクエストはCloudflareに入り、Tunnelを通ってcloudflaredへ届き、最後にHugoのローカルサーバーへ流れます。 この形にすると、ローカル側でinboundポートを開けたり、ローカルサーバーのために証明書を直接管理したりしなくても、HTTPSの外部URLを作れます。 インストール macOSならHomebrewでcloudflaredを入れます。 brew install cloudflared 最短で一時URLを発行して試す まずHugoのローカルサーバーを起動します。 hugo server --bind 127.0.0.1 --port 1313 --disableFastRender 別ターミナルで、HugoのローカルサーバーをCloudflare Tunnelへ渡します。 cloudflared tunnel --url http://localhost:1313 実行すると、https://xxxx.trycloudflare.comのような一時URLが表示されます。 このURLは開発・テスト・一時共有向けです。固定URLや継続運用が必要になったら、次のnamed tunnel構成へ進みます。 Hugo以外の開発サーバーでも考え方は同じです。ViteやNext.jsなどでlocalhost:3000やlocalhost:5173を使っている場合は、--urlに渡すポートを自分の開発サーバーに合わせます。 独自ドメインで固定URLにする 一時URLではなく、https://preview.example.com/のような固定URLでHugoプレビューを共有したい場合の手順です。 ドメイン準備 固定URL化するには、対象ドメインをCloudflareに追加し、DNSをCloudflareで管理できる状態にしておきます。 ...

Ubuntu で nginx を触り始めるとき、最初に迷いやすいのは「どこまで設定すればひとまず公開できるのか」が見えにくいことです。この記事では、nginx をインストールしてブラウザから確認できる状態にし、必要なら HTTPS 化と www ありなし統一まで進める流れ をまとめます。 最初に読むべき範囲は次の4つです。 nginx のインストール 起動確認と公開確認 ドキュメントルート変更 HTTPS 化と www ありなし統一 後半の PHP、404、ログ、rewrite は、必要になったときに読む応用設定として残しています。 nginx をインストールして最初の公開確認をする アプリケーションインストール前のおまじない 初回実行時は時間がかかる場合があります。 以下のコマンドでパッケージ情報を更新・アップグレードします。 sudo apt-get update sudo apt-get upgrade nginx のインストール 次のコマンドで nginx をインストールします。 sudo apt install -y nginx インストール確認 以下のコマンドで nginx のバージョンが表示されれば、インストールは成功です。バージョン番号は環境によって異なるため、出力例と完全一致する必要はありません。 nginx -v # 出力例: nginx version: nginx/1.xx.x (Ubuntu) nginx の起動と公開確認 起動確認 nginx のインストールと同時にウェブサーバーは自動起動されます。 起動状況は以下のコマンドで確認できます。 sudo systemctl status nginx 出力例: ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-10-20 15:15:44 JST; 53s ago Docs: man:nginx(8) Process: 36839 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 36840 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 36934 (nginx) Tasks: 3 (limit: 1033) Memory: 7.0M CPU: 40ms CGroup: /system.slice/nginx.service ├─36934 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; ├─36937 nginx: worker process └─36938 nginx: worker process 自動起動設定 起動・有効化: ...