運用中

ポートフォリオ運用基盤

ポートフォリオを、コンテンツだけでなくデプロイと運用まで含む実サービスとして扱っています。

日本語優先のポートフォリオをNext.jsで構築し、Docker ComposeとCloudflare Tunnelで再利用ノートPCから運用しています。

リンク

リンクが開き、知りたい情報へすぐ届くポートフォリオ

採用担当者は、すべてのページを順番に読むとは限りません。最初の数秒で主要プロジェクトを見つけ、詳しい説明や履歴書へ迷わず進めるよう、日本語・英語・韓国語の内容を同じデータから管理しました。

同時に、リンク自体が開かなければ内容への信頼も失われます。そこで画面の情報設計と、その画面を動かし続ける環境を一つの課題として扱いました。

公開までの経路

ルーターへ外部の入口を作らず、訪問者をホームサーバーへつなぐ

再利用ノートPCをホームサーバーにすると、外部からポートフォリオへ届く公開経路が必要です。

自宅ルーターの受信ポートを直接開けず、アプリのコンテナと公開経路を分離したいと考えました。コンテナごとにlocalhostが異なる点も設定で明示する必要がありました。

Cloudflare Tunnelを公開経路にし、アプリとcloudflaredを同じDocker Composeネットワークで動かしてサービス名で接続しました。

この構成でwondde.comをホームサーバーから運用しています。

公開経路とコンテナネットワークの境界を設定に残すことで、接続先を運用者の記憶に頼らず再現できるようになりました。

再利用ノートPCをサーバーとして使うため、再起動やコンテナ停止のたびに手作業で起動順を合わせると、ポートフォリオの復旧が自分の記憶と在席に依存します。

RAMが限られた個人サーバーであり、現時点では自動CI/CDや外部監視、バックアップからの復元検証まで備えた商用運用ではありません。その範囲を広げず、現在の構成で繰り返せる復旧手順が必要でした。

必要なファイルだけを含むNext.jsのスタンドアロンイメージを非rootユーザーで実行し、Composeのヘルスチェックと再起動ポリシーでアプリの準備状態と再起動を管理しました。手動更新とログ確認の手順もリポジトリに残しました。

現在のDockerfileとCompose設定でwondde.comを運用しています。自動復旧時間や稼働率はまだ測定しておらず、外部監視も導入していません。

デプロイは起動だけでなく、停止後にどこまで自動で戻り、残りをどの手順で復旧するかまで設計する必要があると学びました。

wondde.comの日本語ページを実際に運用し、Dockerfile、Compose、Tunnel、更新手順をリポジトリに残しています。

公開を、コードを一度配置するだけの作業とは考えなくなりました。再起動後に復旧するか、接続先の境界を間違えないか（ネットワーク境界）、秘密情報を守れるか（秘密情報管理）、状態確認とログ調査ができるかまで含めて、運用として捉えています。

自動CI/CD、稼働率の目標値、外部監視、負荷試験、バックアップからの復元検証はまだありません。