公開前の記事が見えてしまったので、サイトの公開範囲を見直した

前回までのあらすじ

第1回で独自ドメインを取り、第2回ではCloudFront（サイトの配信入口に使うサービス）とOAC（CloudFrontからだけS3へアクセスさせる仕組み）をつなぎました。S3（サイトのファイルを置くストレージ）は非公開です。

入口もファイル置き場も狙った形になり、サイト公開はひとまず成功しました。今回は、その入口から何を見せるのかを見直した話です。

公開後に記事一覧と実験ノートを眺めていたら、まだ仕上げていない記事や、これから検証する予定のテーマまで普通に並んでいました。

「ちゃんと公開できた」と喜んだ直後に、「いや、ここまで見せるつもりではなかった」となりました。S3が外から直接見えたのではなく、公開用として生成したファイルへ、見せない内容まで含めていたのが原因です。

CloudFrontやS3が想定どおり動いたことがうれしくて、しばらくは「表示できたか」ばかり見ていました。でも、コンテンツの公開範囲まで正しいとは限りません。インフラのアクセス制御と、記事をどの状態で見せるかは別の問題でした。

技術的に表示できることと、公開してよいことを頭の中で同じにしていたのだと思います。ビルド（＝Markdownなどの原本から公開用ファイルを生成する処理）の段階で、公開対象を分ける必要があると、ここでようやく腑に落ちました。

見せたくない内容が混ざっていると気づいた直後は、整理より先に「まず入口を閉じたい」という気持ちになりました。そこでWAF（Webアクセスをルールで制御する仕組み）を使い、自分のIPだけを許可する構成にした時期があります。

外からまとめて見えなくなり、その瞬間は安心しました。ただ、公開してよい記事まで隠れます。見直すと、これでは公開サイトを自分だけで眺めている状態です。何を出すかを管理するほうが目的に合うと考え直しました。

記事のMarkdown原本へ status を持たせました。書きかけはdraft（＝下書き状態）にします。

status: draft

公開してよいと判断した記事はpublished（＝公開対象の状態）へ変えます。

status: published

入口を全部閉じるより、こちらのほうがやりたかったことに近く見えました。公開サイトのホーム、一覧、詳細ページにはpublishedだけを出します。一方、noteへ投稿する準備用のMarkdownはdraftでも生成し、公開前に手元で読み直せるようにしました。

修正はMarkdownへ戻し、npm.cmd run check でサイト用HTMLとnote用Markdownを作り直します。生成済みHTMLを直接直さないこともルールにしました。

実験ノートには、テーマの原本が100件あります。ここも全部消してしまえば早いのですが、これから使う題材まで捨てるのは違うと感じました。名前がそろっていることと、検証結果を公開できることは別です。

公開サイトには「現在準備中です」という案内だけを出し、テーマ一覧と詳細ページは公開用フォルダへ含めません。100件の原本は削除せず、非公開のまま保持しています。

記事本文の原本は content/articles のMarkdownだけにし、サイト用HTMLとnote用Markdownを生成します。

二つを別々に直すと、どちらが最新か分からなくなりそうでした。原本を一つにすると、直す場所で迷いません。

ルールを書いて安心しかけましたが、それだけではまた同じことをやりそうです。変更後は npm.cmd run check で生成と検証をまとめて実行します。

publishedがホーム・一覧・詳細へ出て、draftは出ないことを確認します。実験ノートの準備中表示や、リンクと各種ファイルの参照切れも見ます。

コマンドが成功しただけでは終わらせず、「出したいものが出る」と「出したくないものが出ない」の両方を画面で見ます。そこまで確認して、ようやく公開範囲を直せたと思えました。

公開後も、下書き、更新、生成物、公開範囲の管理は続きます。原本のstatusと生成結果を見れば、公開対象を判断できます。

サイトを作る勢いだけでなく、更新を続けられるルールまで用意しておく必要があると実感しました。

未完成の記事や実験テーマまで見える状態に気づき、Markdownを唯一の原本にして、publishedだけを公開する形へ直しました。実験ノートは準備中表示のまま、100件の原本を残しています。

インフラを公開できたら終わりではなく、何を出すかまで含めて運用でした。次回は、サイト全体を隠すためにWAFを入れ、最終的にやめた話を書きます。