これまでこのウェブサイト上の画像は、Unsplashとローカルのサーバーでホストされていました。しかしこれではちょっとした問題があるので、その問題を解消する為に画像ホストを変更しました。
現状
サーバーはRaspberry Pi 3 B+で動作しており、ウェブサイトはDockerでdeployされています。テーマはGitHubで管理しており、Commitされたら自動的にウェブサイトへ公開されるようになっています。
ウェブサイト上でアップロードされた画像などのデータは、ローカルディスク上にVolumeをマウントして永続データとしています。
問題点
問題としているのは2点あります。
1.ローカルディレクトリにマウントして永続データ化している。
今後サーバーを変更する際に、ローカルのデータをいちいち移動しなくちゃいけません。コンテナ化したそもそもの理由がホストのディレクトリを汚さず、必要ならばすぐにアプリケーションを移行できる事が目的でした。現状では本来の目的を達成できません。
またこれに関連する問題として、データが失われるリスクがあります。これは私に限った話だと思いますが、サーバーを大規模にいじったりした時に誤ってデータを飛ばすことがあったり、そもそもディスクがエラー吐いて二度と読み込めなく事があります。前者に関しては、 私のリスク管理の問題ですが、個人の趣味でやっているウェブサイトなのでリスクもクソもないと考えています。よって性格的な観点から解消不可能。候者に関しては、お金でリスクを下げられますが私がそこまでお金を払うのは難しいし、何より管理が大変になるのでやりたくない。
どちらのリスクを踏んだとしても新しいサーバーへ移行したり、新しいウェブへ作り変えた際には、パスが変わったり、データがなかったり、形式が違かったりで面倒なことになります。
2.ネットワーク帯域幅を節約しながら、読み込みの高速化をしたい。
このウェブサイトもCloudflareを挟んで可能な限り帯域幅を節約しようと試みていますが、それでも限界はあります。そして速度が出なかったりするので、そういった諸々の問題を一気に解消したいです。
解決策
この2点を手軽に個人ですぐにできる範囲で解決する事が求められます。
とはいってもできることなんてそう多くは有りません。一つ確実に言えるのが、画像データのセルフホストをやめるべき。ブログ自体のデータや文章のデータなどを外部に移行するには無理があります。この問題解決に工数かけていいならJamStack化するなど解決策は考えられますが、作るのにも管理するのにも手間がかかります。
画像データのセルフホストをやめるとなると、2つの解決策が考えられます。1つ目は、そもそも画像データを扱うのを止める(もしくは最小限にする)。これはブログである関係上却下です。2つ目は、画像データを外部サーバーで扱うようにする。これが現実的です。
それで画像データをどこへアップロードするべきなのかという問題ですが、使っているCMSから考えて3通り考えられました。
- Google Drive
- Amazon S3
- 画像アップローダー
一応これ以外にもありましたが、日本向けのサービスじゃなかったりしたので断念しました。
Google Driveを使う場合
CMSのプラグインを利用すれば利用可能です。ただDockerでやる場合、少々面倒くさいです。このウェブサイトは最小限の管理の手間で済むようにしたいので、Dockerfileで色々書いてやるのは本意では有りません。あとGitHubでほぼ更新されていませんでした。一応現在も使えるようですが、今後いつ使えなくなるのか分かりませんし、サポートされているか不明でした。