このブログでの画像管理

カテゴリー:  Tech タグ:  blogging images nikola

このブログで使用している画像をAmazon S3に移行 していましたが、やはりGitのリポジトリに戻すことにしました。

Amazon S3からGitリポジトリに

このブログで使用している画像をAmazon S3に移行 していましたが、やはりGitのリポジトリに戻すことにしました。

ビルド時間が短くなるとか、Pull時間が短縮できるとかメリットはありますが、 運用しているうちに次のような問題が感じていました。

  • リポジトリのPull時間、Nikola1のビルド時間は短くなるが、執筆時に別途Amazon S3に画像をアップロードする手間、S3のバックアップとしてクラウドに画像をバックアップする手間がかかり、総じて私の手間は増えてしまっていた。
  • S3のバケットをPublicにしているのも懸念がある。
  • 月に数十円といえど、S3の料金が発生する。

Git LFSはどうか

では、Git LFSはどうでしょうか。

Git LFSとは Git Large File Storageのことで、リポジトリに実際のファイルではなく、ファイルへの参照を保存することで大きなファイルを扱います。 Git のアーキテクチャを回避するため、Git LFS では実際のファイル (どこか別の場所に格納されています) への参照として働くポインター ファイルが作成されます。 GitHubはこのポインタファイルをリポジトリ中で管理します。

有効にするには以下のようなステップで実行します。

# MacへのGit lfsのインストール
$ brew install git-lfs

# Git lfsの有効化
$ cd your_repository
$ git lfs install

# LFS対象とするファイルの定義
$ git lfs track "*.jpg"
$ git lfs track "*.webp"
$ git lfs track "*.png"
$ git lfs track "*.gif"

GithubなりGitlabにPushすると、何も設定しなければリポジトリとは別のそれぞれが管理するストレージで管理されるようです。設定すればS3などにストレージを設定することもできます。

とやってみましたが、次のような問題があります。

  • pushに異様に時間がかかる。
  • 結局ビルド時も git lfs pull が必要となり、運用も面倒になり時間もかかる
  • ブログの画像なんて追加のみで書き換えることなんて無いので、そもそもスナップショットであろうが差分であろうがあまり影響がない。

100MBを超えるような大きなファイルを扱う必要がある場合にメリットがありそうですが、 ブログの画像程度ではさしてメリットがないようです。

結局リポジトリに全部ぶち込む

結局、元通り元の通りリポジトリに画像ファイルも格納することにしました。

前回作ったスクリプトの逆の処理を 行うスクリプトを作って戻しました。

あぁ、無駄な数ヶ月でした。


  1. このブログはNikolaで生成しています。 

コメント

Comments powered by Disqus