2023年8月に入って、このブログはWordPressからHugoに移行しました。
前々から別サイトを実験的に立ち上げて、GitHubにHugoのファイルを置いて、GitHub Pagesを使って独自ドメインでサイトを公開することそのものには、成功していました。
で、いつか似た仕組みでメインのブログもHugoに移行できたらいいなぁと思っていたので、それを実行に移したわけです。
仕組みとしては上手くいきました。詳しくは前々回の記事を見ていただきたいんですが、Hugoでビルドした内容をさくらのレンタルサーバにFTP転送して公開することで、割と理想的なブログ更新環境が実現できたと思います。
ただ、そうして喜んだのも束の間。先日GitHubよりこんなメールが来ました。
GitHub Actionsでビルドしたときにできたファイル、artifactsと呼ばれていますが、そのファイルを保存しておくことができる容量に制限があります。
GitHubの無料プランでプライベートリポジトリだと、なんと512MB。たったの。
いやまぁ、内容によっては全然大丈夫な容量かもしれませんが、このブログの全容量から画像を抜いた状態でも、圧縮した状態でだいたい500MBくらいありました。
それが圧縮前だと、一時的に700MBくらいに膨れ上がってしまったので、この警告メールが送られてきたわけです。
こうなるともう、Hugoがビルドできません。この画像の言うとおりにするなら、9月1日までブログが更新できないことになります。それは困る。
せっかく、良い仕組みでブログのリニューアルができたのに、全然持続可能ではない。
それに、さくらのレンタルサーバーのライトプランがあまりにも安すぎて、もうWordPressを動かすサーバーに戻れません。以前まで利用していたサーバーはwpXで、毎月1320円でした。
今は約130円ですよ。10分の1です。それでWordPressより速いんだから、もうHugoでしょ。
というわけで今回は、GitHub Actionsに似た仕組みがお安く実現できないかを探しました。
目標は、Gitでプッシュしたら、そのデータをHugoでビルドして、ホスティングしているサーバに転送してくれる仕組みづくりです。
GitHub以外のGitサーバの候補
ページが公開されたのが2019年でちと古めの情報かもしれませんが、一覧がこちらに載っていました。
こちらのブログによると、GitLab以外にもいくつか候補がありました。
結論から言うと、僕は今回、Raspberry Pi 4をGitサーバにしようと考えて、GitBucketを選びました。そこで動く。つまりarmで動くことが条件です。
GitBucket環境をDockerで用意する
参考にしたサイトはこちらです。
それと、Docker系のコマンドは、こちらの書籍を参考にしました。
僕は2まで買いました。今回の作業を行うには、ここまでで十分です。
GitBucket環境が用意できたら、GitHub Actionsに相当する部分をPluginで用意します。
GitBucketを作ったNaoki Takezoeさんが作ったgitbucket-ci-pluginを使いました。
GitHubで公開されているJAVAのファイルをPluginディレクトリに入れるだけで、使えるようになります。今回はDocker環境なので、docker exec -itでコンテナに入ってPluginディレクトリ内でwgetしました。
プッシュされたらHugoでビルドして、さくらのレンタルサーバにFTP転送
GitBucketでCIを実現するプラグイン、入れるとGitBucketの項目にBuildが追加されて、まるでGitHub Actionsみたいな見た目で設定できるようになります。
しかも、今回はRaspberry Piなので、そのBuildに書くのはLinuxのコマンドです。Windowsで動かしているならコマンドプロンプトで実行するようなコマンドを入力して、実行できるようになります。
つまり、シェルスクリプトやバッチファイルみたいなのが動くっていうイメージです。
今回は、リモートリポジトリにHugoをビルドするためのファイル群を置きました。MacやiPad、Windowsからgit pushされたタイミングでHugoをビルドして、publicディレクトリに書き出されたhtmlファイルをさくらのレンタルサーバにFTP転送します。
実際にBuild時に実行しているコードがこちらです。
ls
apt-get -y install hugo ncftp
hugo --minify
cd public
ls
ncftpput -R -u USERNAME -p PASSWORD FTPSERVER_ADDRESS PUBLICDIRECTORY *
ls
GitBucketのBuildは、コンソールが表示されて、進捗状況が眺められるようになっているので、その時の状況を知るために定期的にlsコマンドを実行させてます。いらんっちゃいらんですけどね。
流れとしては、apt-getで使うコマンドをインストールして、hugoコマンドでpublicディレクトリにhtmlを書き出し。
そしてpublicディレクトリ内に移動して、ncftpputコマンドでディレクトリ内の全てのファイルをFTPサーバに転送します。
さくらのレンタルサーバのライトプランはFTPサーバを動かしてくれているので、FTP転送します。
最後のlsは、このスクリプトがncftpputコマンドで終わると何故かFailure扱いになってしまったので、最後に適当にlsを実行してみただけです。
自分が自由に使えるGitサーバって、良いよね
GitHubの方が、サーバとしては安心感があります。できれば僕はGitHubだけを使った生活で、書いたソースコードが全部アップしてあってっていう生活を送りたいなと思っていました。
Macを買い替えたり、新しいパソコンやiPadを買ったときに、書き散らかしたコードを移行するのが本当に辛かったんですよ。
でも、GitHubの無料の範囲では容量に限界がありましたし、ブログ記事は僕にとっては著作物なので、リポジトリをPublicにするわけにもいきませんでした。
なので今回は、Raspberry Pi 4で動くGitサーバで、手軽にGitHub Actionsに相当するものが実行できる環境が欲しかったんですよ。
今はDockerという便利な仕組みがあるおかげで、環境を用意するのにいちいち自分で全部を設定しなくても良くなりました。良い時代です。
ちなみにラズパイ4は、Amazonの在庫も潤ってきました。Linuxサーバの練習機として、本当におすすめです。GitBucketがラズパイで動いてよかった。危うくミニPCを買っちゃうところでした。
GitHubにお金を払うことで解決できる問題かもしれませんが、今回はなんとか自前の環境を使って、iPadで書いたmdファイルを元にブログが更新できる仕組みを作ってみたかった。
これが今回の作業の動機です。Gitの勉強をされたい方も、資金面で不安があるが、何故か家にラズパイが転がっているという方も、練習としてやってみてはいかがでしょうか。
失敗談
GitBucketに行き着く前までは、ずっとGitLabと格闘していました。ただこれがかなりの曲者で、まずラズパイ4であってもスペックが不足しがちでサクサク動いてくれませんでした。
それと、GitLab公式が用意してくれたDockerイメージがarm64に対応していませんでした。非公式でビルドされたイメージもあるんですが、そのイメージでコンテナを作っても、Gitのプッシュに合わせてプログラムが動くGitLab runnerという仕組みがうまく動いてくれませんでした。
ここに書いてあるとおりにやってはみたんですけどね、どうしてもgitlab-runnerを入れる前の段階、プロジェクト内でrunnerを新規で作成しようとすると、ずっとクルクルしたままサイトが固まってしまったので、GitLabの利用を断念しました。
ちなみに後に試したamd64版のUbuntu Serverでは、公式が用意したDockerイメージも動きましたし、gitlab-runnerも動きました。ラズパイだけの問題というか、きっと非公式イメージ固有の問題だと思います。
そうこうしているうちにGiteaやGitBucketに出会いました。もっと早く出会いたかったわ。
ラズパイでGitサーバをやるなら、GitLabは現実的ではありません。一人でも参考になったら嬉しいです。