Webアプリができあがると、次はそれをどうやって公開するかを考えることになります。
これまでは、公開用のファイルをZIPにまとめて、サーバーのファイルマネージャーからアップロードする方法も使っていました。
ただ、Chrono Sculptureを公開しようとしたとき、公開用のフォルダを画面からうまく作れませんでした。
SSHで中を確認してみると、同じ場所の親フォルダには書き込めることが分かりました。それなら、画面から手作業でアップロードするのではなく、PCからファイルを送る流れを作ってみてもよさそうです。
そこで今回は、SSHでサーバーへ接続し、rsyncでファイルを送る形を試してみました。
この記事は、そのときにどんな順番で公開したのかを残した覚え書きです。サーバーによって使える機能やフォルダの形も違うので、そのままコピーする手順書というより、「今回はこんな流れにしてみた」という記録として読んでもらえたらと思います。
いきなり公開中の場所へ送るのは少し心配
一番分かりやすいのは、作ったファイルを公開中のフォルダへそのまま送る方法です。
ただ、ファイルを送っている途中で止まると、新しいものと古いものが混ざるかもしれません。
たとえば、ページの本体だけが先に新しくなり、そこから読み込むJavaScriptがまだ届いていない、という状態も考えられます。
そこで今回は、公開中の場所へ直接送るのではなく、その前に一度別の場所へ置くことにしました。
公開前の一時置き場ってどこ？
この一時置き場は、別のサーバーに用意したものではありません。
公開先と同じサーバーの中に、Webからは直接見えない一時フォルダを作り、そこへ一度ファイルを送っています。
ここで行うのは、アプリをブラウザで動かすテストではありません。予定していたファイルだけが入っているか、送る前と後で内容が変わっていないかを確認するための場所です。
確認できたファイルは、そこから公開URLで見えるフォルダへ移します。
まとめると、今回は同じサーバーの中で、次のようにファイルを動かしています。
- Webからは見えない「公開前の一時置き場」へ送る
- 中身に問題がないか確認する
- 問題がなければ「今公開されている場所」へ移す
毎回、空のフォルダで公開用ファイルを作る
公開用のファイルは、毎回新しく作った空のフォルダへ出すようにしました。この公開用ファイルを作る作業が、よく「build」と呼ばれているものです。
前に作ったファイルが残っている場所をそのまま使うと、もう使っていないものや、一時的にできたものが混ざることがあります。最初から空の場所を使えば、今回作られたファイルだけを確認できます。
今回送るのは、index.htmlと、そこから使うJavaScript・CSSだけです。TypeScriptのソースコードや制作中の資料などは送りません。
公開用のファイルができたら、予定していないものが入っていないかも見ておきます。ここで違うものが見つかったら、まだサーバーへは送らずに止めます。
まずは、何が送られるのかを見てみる
ファイルの転送にはrsyncを使いました。
今回は、PCからサーバーへファイルを送るために、rsyncというコマンドを使いました。
いきなり転送するのではなく、最初にdry runという確認を入れました。実際にはまだ送らず、「このまま進めると、どのファイルが送られるのか」だけを見るものです。
内容に問題がなければ、作ったファイルを公開前の一時置き場へ送ります。
送った後は、ファイル名やフォルダの形をもう一度確認しました。さらに、PC側とサーバー側でSHA-256の一覧を作り、同じ内容になっているかも比べています。
SHA-256は、ファイルの中身をもとに、確認用の文字列を作る仕組みです。ファイルにつける確認用の指紋のようなもの、と考えると分かりやすいかもしれません。
中身が変わると、この文字列も変わります。今回は、送る前と送った後の文字列を比べることで、同じファイルが届いているかを確認しました。
確認できてから公開を切り替える
公開前の一時置き場にあるファイルを確認できたら、いよいよ公開中の場所へ移します。
すでに前の版が公開されている場合は、それをすぐ消さず、いったん控えの場所へ移します。そのあとで、確認済みの新しいファイルを公開中の場所へ移します。
初めて公開するときは、まだ前の版がないので、確認済みのファイルをそのまま新しい公開場所へ移します。
公開中のフォルダへ一つずつ上書きするのではなく、確認済みのまとまりを最後に入れ替えるようなイメージです。
切り替えた後は、公開URLから実際にファイルを読み込み、表示されているものも確認します。
もし更新後に問題が見つかったら、新しいものを外し、控えておいた前の版へ戻せます。初回公開で問題が見つかった場合は、新しく置いたものを外して、公開前の状態へ戻す形にしました。
また、同じアプリの公開作業が二重に動かないように、「いま処理中です」という印も置いています。技術的にはlockと呼ばれるものですが、ここでは公開作業が重ならないようにするための札のようなものです。
最初の公開は、途中で止まった
ここまで流れを作ってみましたが、最初の公開は一度で最後まで進みませんでした。
PCでは動いていた確認処理の一部が、サーバーでは同じように動かず、公開前の一時置き場を確認している途中で止まりました。
調べてみると、PCとサーバーで使える仕組みに違いがあったようです。そこで、サーバーでも動く、もう少し単純な書き方へ変更しました。
今回は初回公開で、この時点ではまだ公開中のファイルはありませんでした。公開場所へ移す前に、一時置き場と処理中の印を残したまま止まったため、途中まで送ったファイルが公開されることもありませんでした。
いったん残っている状態を確認し、サーバー側で使えなかった書き方を外してから、もう一度進めました。修正後は、ファイルの転送、内容の確認、公開場所への移動、公開URLからの確認まで進められました。
途中でちゃんと止まれたことも大事だった
公開の仕組みを作るなら、できれば一度で最後まで進んでほしいところです。
今回は途中で止まりましたが、公開場所へ移す前に止まったので、中途半端な状態のファイルは公開されませんでした。
何かあったときに自動で全部を片付けてしまうと、どこまで進んでいたのか分からなくなることもあります。今回は、状態が分からないときは勝手に消さず、確認できるものを残して止まるようにしました。
一度も失敗しないようにするだけでなく、問題が起きたときに途中で止まれるようにしておく。実際に最初の公開が止まったことで、この流れがどんなふうに動くのかも確認できました。
今後ほかのWebアプリを公開するときも、この流れを土台にしながら、その環境で同じように動くかを確認していこうと思います。
今回使ったもの
| 使ったもの | 今回使ったところ |
|---|---|
| SSH | PCから公開先のサーバーへ接続し、ファイルや状態を確認するところ |
| rsync | 公開用のファイルを、サーバーの非公開の一時置き場へ送るところ |
| Vite | Webアプリを公開できる形のファイルにするところ |
| SHA-256 | 送る前と送った後で、ファイルの内容が同じか比べるところ |
| Bash | ファイル作成、確認、転送、公開の順番をまとめるところ |
