HeQihan

HeQihan

ブログフロントエンドShiro低メモリデプロイ ✨

前天六点多、私のブログサーバーがダウンしました。アリババクラウドから警告通知が届きましたが、全く役に立ちませんでした。日常的に私のインターネット 2C2G3M の領域を巡回していると、ホームページだけが見られ、他のページはすべて 504 Gateway-Timeout でした。アリババクラウドの監視を見てみると、メモリリークが原因で、メモリがいっぱいになっていました。どの悪者のせいか見てみると、全く動かなくなり、ssh にも接続できなくなりました。

これは普通の故障ではなく、重い手を打たなければ、私の 2C 可用 0G3M の領域を取り戻すことができません。

強制的に再起動すると、メモリ使用量も下がり、ちょうど私のブログのフロントエンドとバックエンドを更新することができました。私のデプロイは玖月のチュートリアルを参考にしており、具体的にはこれこれです。もちろん、私は不完全なバージョンを使っていますが、動けばそれでいいです。

docker を使ってバックエンドを更新するのはとても簡単です。詳しくは省略しますが、とにかくアップグレードが完了しました。フロントエンドの更新はあまりうまくいきませんでした。ビルドにはかなりのメモリが必要で、前回の方法はアリババクラウドで十分なメモリを持つマシンを按量課金でレンタルし、内部ネットワークで一気に転送するものでした。しかし、今は昔とは違い、私はローカルの ubuntu の予備機を持っているので、アリババの威光を高める必要はありません。

残念ながら、すべてを一気に転送するには、外部ネットワークの 3M の小さな水道管ではまだ足りず、私のネットワークのアップロード速度も残念なことに、再び同じ過ちを繰り返すのでしょうか?

以下の内容を読む前に、Mix-Space デプロイ最新フロントエンド Shiroを先に読むことをお勧めします。


Shiro プロジェクトで使用されている Next.js の先進的な機能に感謝します。プロジェクトの next.config.mjs を見てみると、 output: 'standalone' が設定されていることがわかりました!これはまさに私が必要としていた神兵利器です!これにより、 next build の後、実際に必要な依存ファイルだけを賢くパッケージ化し( node_modules も「スリム版」が作成されます)、それを一気に .next/standalone ディレクトリに詰め込みます。出てくるのは超ミニマルなビルドパッケージです!

勝利

// プロジェクトの next.config.mjs はこんな感じです:
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone', // これがその行です!
  // ... その他の設定
};
export default nextConfig;

プロジェクトには、 standalone モードの出力を自動的にパッケージ化するスクリプトもあり、デプロイに直接使用できます。

勝利勝利

#!env bash
set -e
CWD=$(pwd)

cd .next # ビルド出力ディレクトリに移動
rm -rf cache # ビルドキャッシュをクリア
cp -r ../public ./standalone/public # public静的リソースをstandaloneディレクトリにコピー

cd ./standalone # standaloneディレクトリに移動
echo ';process.title = "Shiro (NextJS)"' >>server.js # プロセスタイトルを追加
mv ../static/ ./.next/static # サーバーに必要な静的リソースを移動(standaloneサーバー用)
cp $CWD/ecosystem.standalone.config.cjs ./ecosystem.config.js # PM2設定ファイルをコピー

cd .. # .nextディレクトリに戻る
mkdir -p $CWD/assets
rm -rf $CWD/assets/release.zip
zip --symlinks -r $CWD/assets/release.zip ./* # 準備した.nextフォルダ全体を圧縮

スクリプトは最適化された standalone 出力を取得し、PM2 設定や静的リソースなどの「調味料」を加え、最終的に assets/release.zip の圧縮パッケージを生成します。これで簡単に転送してデプロイできます。

勝利勝利勝利

理論は実行可能です。次は実践です。

開発機で何をするか#

まず pnpm をインストールし、プロジェクトのルートディレクトリで実行します。

pnpm install # または pnpm i
pnpm build

これで next build が実行され、 .next フォルダが生成され、私たちが心待ちにしていた .next/standalone ができます。

その後、

bash standalone-bundle.sh

と実行すると、 assets/release.zip のデプロイパッケージが生成されます。🥳

最後にこの圧縮パッケージをサーバーに送信すれば、開発機のタスクは完了です。

サーバーで何をするか#

まず適切なバージョンの node.js と PM2 をインストールし、権限を与えます。

sudo mkdir -p /srv/shiro-app
sudo chown -R user:usergroup /srv/shiro-app # 自分に権限を付与
cd /srv/shiro-app
sudo unzip /圧縮パッケージのパス/release.zip

次に standalone ディレクトリに移動し、 server.jsecosystem.config.js がここにあります。

cd standalone
pm2 start ecosystem.config.js

これで本当に大成功ですが、以前のデプロイでずっとエラーが出ていて、最終的に半日かけて調査した結果、.env のドメイン名を間違えて書いていたことが判明し、大失敗でした。

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。