「Raspberry Pi」タグの記事が3件件あります

これまでこのウェブサイト上の画像は、Unsplashとローカルのサーバーでホストされていました。しかしこれではちょっとした問題があるので、その問題を解消する為に画像ホストを変更しました。

現状​

サーバーはRaspberry Pi 3 B+で動作しており、ウェブサイトはDockerでdeployされています。テーマはGitHubで管理しており、Commitされたら自動的にウェブサイトへ公開されるようになっています。

ウェブサイト上でアップロードされた画像などのデータは、ローカルディスク上にVolumeをマウントして永続データとしています。

問題点​

問題としているのは２点あります。

１．ローカルディレクトリにマウントして永続データ化している。​

今後サーバーを変更する際に、ローカルのデータをいちいち移動しなくちゃいけません。コンテナ化したそもそもの理由がホストのディレクトリを汚さず、必要ならばすぐにアプリケーションを移行できる事が目的でした。現状では本来の目的を達成できません。

またこれに関連する問題として、データが失われるリスクがあります。これは私に限った話だと思いますが、サーバーを大規模にいじったりした時に誤ってデータを飛ばすことがあったり、そもそもディスクがエラー吐いて二度と読み込めなく事があります。前者に関しては、私のリスク管理の問題ですが、個人の趣味でやっているウェブサイトなのでリスクもクソもないと考えています。よって性格的な観点から解消不可能。候者に関しては、お金でリスクを下げられますが私がそこまでお金を払うのは難しいし、何より管理が大変になるのでやりたくない。

どちらのリスクを踏んだとしても新しいサーバーへ移行したり、新しいウェブへ作り変えた際には、パスが変わったり、データがなかったり、形式が違かったりで面倒なことになります。

２．ネットワーク帯域幅を節約しながら、読み込みの高速化をしたい。​

このウェブサイトもCloudflareを挟んで可能な限り帯域幅を節約しようと試みていますが、それでも限界はあります。そして速度が出なかったりするので、そういった諸々の問題を一気に解消したいです。

解決策​

この２点を手軽に個人ですぐにできる範囲で解決する事が求められます。

とはいってもできることなんてそう多くは有りません。一つ確実に言えるのが、画像データのセルフホストをやめるべき。ブログ自体のデータや文章のデータなどを外部に移行するには無理があります。この問題解決に工数かけていいならJamStack化するなど解決策は考えられますが、作るのにも管理するのにも手間がかかります。

画像データのセルフホストをやめるとなると、２つの解決策が考えられます。１つ目は、そもそも画像データを扱うのを止める（もしくは最小限にする）。これはブログである関係上却下です。２つ目は、画像データを外部サーバーで扱うようにする。これが現実的です。

それで画像データをどこへアップロードするべきなのかという問題ですが、使っているCMSから考えて３通り考えられました。

1. Google Drive
2. Amazon S3
3. 画像アップローダー

一応これ以外にもありましたが、日本向けのサービスじゃなかったりしたので断念しました。

Google Driveを使う場合​

CMSのプラグインを利用すれば利用可能です。ただDockerでやる場合、少々面倒くさいです。このウェブサイトは最小限の管理の手間で済むようにしたいので、Dockerfileで色々書いてやるのは本意では有りません。あとGitHubでほぼ更新されていませんでした。一応現在も使えるようですが、今後いつ使えなくなるのか分かりませんし、サポートされているか不明でした。

Amazon S3を使う場合​

そもそも画像データが膨れ上がった場合の懸念からクラウドに移行しようとしているのに、画像データが膨れ上がったらどんどんお金が吸われていくようなサービスを使いたくはありません。

プラグインが、Google Driveに比べて積極的にサポートされていて利用者数もかなり多い印象でした。

画像アップローダーを使う場合​

有料のサービスも数多くありますが、無料のサービスも多数存在しています。懸念点として、ブログに貼り付ける際に適しているかという点。例えばHTMLで貼り付ける場合、ロゴや枠など色々邪魔なものがついてきてしまうのは良く有りません。そのため貼り付けた際にロゴや枠など邪魔なものが表示されない、もしくは最低限である事が条件になります。

次にこれが重要ですが、画像を失う可能性が小さいサービス選択が求められます。サービスの方針転換でブログに貼り付けられなくなったり、サービスそのものが消えてしまいデータも一緒に消える可能性は可能な限り潰しておきたいです。

という事で色々サービスを当たった結果、Imgurだけが残りました。もともとサービス自体は知っていて、過去に使ったこともあったのですぐ候補に上がりました。Imgurは長いことサービスやってますし、買収されてから色々懸念されていましたが、現状では特に大きな問題は見当たらないので、使うにあたって問題なしと判断しました。

結果​

まだ完全に結果が出ていませんが、画像データがローカルから無くなるのは確定しているので、サーバー側管理のやりやすさは断然上がります。また、画像の読み込みが自宅からではなくなるので、記事のロード速度も向上されました。ただし、CMS的に投稿のサムネイル画像はImgurにできなかったので、ここに関しては速度は変わっていません。

記事の画像を置き換えていく作業が積み重なっていますが、面倒なのであまりはかどっていません。。地道にやっていこうと思っています。

Twitchで配信をしながら、勉強しつつ１０時間かけてクラスタ構築とクラスタへの移行を行いました。

クラスタを構築したのは良いもののデータベースを実行してるメインサーバが吹き飛んだので、やってからこの記事を書くまで時間が経過しました。

サーバが吹き飛んだことに関するIQ3まとめについては下記の投稿を見てください。

サーバーがカーネルパニック起こしたと思ったらハードウェアごと吹き飛んだ件

なぜクラスタを構築したのか？​

大きく２つの理由があります。

１つ目は学習目的です。クラスタに関して興味深くQiitaやZennその他様々な記事を目にしていましたが、いままで一度も構築したことがありませんでした。そこでやってみようと考えました。好奇心的なところが強いです。そもそもとして、私が自宅にサーバを持っている理由が学習目的なので、こういう感じで結構色々気軽にやってたりします。

２つ目は複数台管理が面倒くさかったです。クラスタ構築して運用できれば、個別にSSHでいちいちつないで細かく設定する必要がなくなるので、かなり管理の手間が減ると思いました。実際、楽になりました。初期に色々設定するという面ではかなり手間はありますが、そこさえ乗り越えれば楽です。

上記の２つの理由からクラスタ構築を自宅サーバ群で行いました。

自宅サーバ群について​

サーバ群なんて言っていますが、今回のクラスタ構築では３台のみで考えました。今後追加することも一応考慮しています。

１台目​

データベースやゲームサーバー、その他諸々一番色々やっているサーバ。スペックもメモリも一番ある。

ストレージは、SSDにOS、HDD２枚にそれぞれバックアップと本番の運用データが乗ってます。

OSはUbuntu Server 20.04、もともとはCentOSで運用していましたがCentOS 8でなくなるということでDebian系に乗り換えました。Ubuntuを選択した理由は、割と安定しながらも、バージョンを比較的新しいのを使ってくれるからです。後は最近のOSSとかがUbuntuで動かすことを想定して作ってることが多かったりするなんて理由もあります。あまり細かいことは考えてません。

２台目及び３台目​

Raspberry Pi 3 Model B+です。

どちらもTeam GroupのSDカード32GBを指してあります。

OSはUbuntu Server 20.04です。

基本的にデータを保持せず、サービスをDockerなどで動かしているだけです。このウェブサイトのウェブサーバーもラズパイで動作しています。データはデータベースやNASなどに放り込んであります。

後日、外部HDDをつなげてNAS化する計画がありますが、それはおいおいの話なので、ストレージは無いものとして扱います。

３台目以降​

現在はありませんが、今後追加する可能性があるという事を考慮して構築しました。まだ扱いを考えていますが、クラウドのクラスタを自宅サーバのクラスタと混ぜてしまってもいいかなと考えているので、そういった可能性も考慮しつつ作ります。

オーケストレーションに何を使うのか​

クラスタ構築で重要なオーケストレーションシステムをどのように選んだのかという話です。

最も有名なオーケストレーションシステムの１つとして、k8s（Kubernetes）があると思います。Googleが設計したやつで、デファクトスタンダードの立ち位置にあるオーケストレーションシステムです。

k8sは技術トレンドですし、扱えたらなんかカッケー！とは思いますが、ここは現実的な事を考えましょう。まずk8sはプロダクション環境で使われることが多く、そこで使うことを想定した作りとなっています。実際Googleさんとか色々な企業は数千ノードをk8sとかで扱っているとか...

しかし私は一般家庭、プロダクション環境ではないのです。もちろん数千ノードなんて扱うことは有りません。現在稼働させてるサーバーをオンプレ・クラウド合わせてもいいとこ１０数個です。まず２０ノードを超えることは有りません。ということはそこまで高性能である必要も無ければ、プロダクション環境に対応できるだけのスケールアウト可能なシステムである必要もありません。

k8sが無いとすると次に挙がってくるオーケストレーションシステムといえば、Docker Swarmです。これはDocker-ce自体に統合されているものなので、追加のインストールなどは必要なく、Docker engineが使えれば利用可能です。

補足ですが、「Docker Swarm 終了」や「Docker Swarm サポート終了」といったサジェストが出てきて、その旨の記述をするブログが散見されますが、終わったのは、Docker-Swarm-Mode-As-A-Serviceです。Docker Swarmが完全に削除されたわけではなく、開発が終了したわけではないです。

Is Docker Swarm Mode EOL?

これ以外に利用されるオーケストレーションとしてGKEやECS、OpenShift、Rancherなどなど色々ありますが、他のは情報少なかったり、クラウドでやること想定されてたりなので、考えないこととします。後は単純に導入の手間とコストに見合わないです。

Kubernetes vs Docker Swarm​

少なくとも私が自宅サーバ群でクラスタ構築するにあたり、どちらが良いのか。実際に検証したわけではありませんが、ある記事を見つけたのでそちらの情報を参照します。

[和訳]Docker SwarmとKubernetesの比較 #docker - クリエーションライン株式会社

ここでは技術コンサルタントのJeff NickoloffとDockerが契約して、パフォーマンス評価をした結果の和訳が掲載されています。

中身はここでは解説しないので、簡単に呼んで頂くとして、重要な２つのパフォーマンス評価項目とその結果に注目します。

評価項目は「コンテナの起動にかかる時間」と「高負荷状態での応答性」です。後者のような状態になることは想定してないし、プロダクションでもないので最悪time outしてもいいかなぐらいの気持ちではいますが、良いに越したことは有りません。

結果だけ書くと、コンテナの起動にかかる時間はDocker Swarmの方が５倍早く、クラスターの負荷率がほぼ100％であったとき、Kubernetesはクラスターの形成状態が10％～100％に到達するまで、Docker Swarmの98倍の時間がかかっています。

できることの幅は間違いなくk8sの方が良いです。ただしk8sは純粋に複雑なんです。ちょっとしたことをやるためにも色々やる必要があります。大規模なサービスを厳格に動かす場合、おそらくk8sは向いているでしょうが、自宅でちょっとクラスタを動かすぐらいであれば、複雑でパフォーマンスが出ないk8sよりもDocker Swarmの方が良いという結論になりました。

これは私の結論なので、自分で作る場合はぜひ自分で選択してほしいですが、少なくとも少ないサーバー台数で、１人でシンプルに物事を進めたいのであれば、Docker Swarmの方が向いていると思います。

WebUI​

さて一人で管理していくとなると、WebUIがあったほうが楽ですし、やりやすいです。全部CUIでやれという意見も理解はしますが、人間なのでGUIに甘えたいです。

ここに関しては割とすぐに決まりました。というかだいぶ前からクラスタ構築のための構想は頭で練っていて、もともとこれでいいでしょって感じで決めていました。

選ばれたのはPortainerでした。

Container Management | Kubernetes GUI | Docker Swarm GUI | Portainer

Dockerの WebUIで一番有名なのが、Portainerだと思いますね。なぜこれを選んだか話もしたいんですが、いうほど掘れる話題無いです。軽量で簡単に動かせて手間かからないのが、Portainerぐらいで他のWebUI系はパッとしなかった。

クラスタ構築してどうなったのか​

まだ結果は出ていません。現状大きな問題はなく順調に動いており、快適といえば快適という感じになっています。その一方、クラスタである必要はないと思うこともあります。今後の課題です。

また、時間が足りなかったりメンテナンスにそこそこな時間を割かなくてはいけないという点から、一部コンテナはStackとしてデプロイできていないです。さらには新たな問題点も見つけているので、今後の課題が積み重なっています。色々勉強しながら、ベストプラクティスを模索していきたいと思います。

今後、ちょこちょことこういう問題あった！解決した！といった系の投稿を小出ししていこうと思います。

大きなアウトプットしようとすると、時間ばかりが経過して何日も投稿しない日が続くのでね...

ヤフオクに出品されていた格安Raspberry Piを落札したので、ウェブサーバーをRaspberry Piへ移行しました。

ウェブサーバーに使用しているラズパイは、Raspberry Pi 3 Model Bです。OSにはRaspberry Pi OS（Raspbian） 64bitをインストールしました。

Raspberry Pi OSはDebianベースのOSですが、64bitは執筆時点でベータ版です。もしも64bitで使う場合、自己責任で注意して使用してください。

Raspberry Pi 3 Model B+も手に入ったので、そっちにも64Bitのインストールを試みたんですが、何故か全く動かず、ネットで検索しても同じ状況の人はいても解決策らしい解決策を発見できず諦めました。

なお実家がPC欲しいって言ってたので、Raspberry Pi OS Desktop 32bitをインストールしてあげました。動作は遅いので多分使い物にならない気はしますけど、コンパクト感は気に入ってくれたらしいので良しとしましよう。

サーバー間のデータ移行ですが、特に苦労せずぱぱっと終わりました。私のサーバーのサービスはほぼ全て仮想コンテナ化されているので、適当にDockerとDocker-composeをインストールして、コマンド打てばサービスが立ち上がります。とは言っても、この世の中のアーキテクチャを支配しているIntel製CPUからラズパイが使っているARMアーキテクチャへの移行なので、ちょろっといじりはしました。全くARMをサポートしていなくて一から作るみたいなイメージはなかったので、すぐ終わりました。あとはコンテナへアクセスを振り分けるためのNginxとSSL更新用のCertbotも導入すれば完璧です。

本当はこれを機会にNginxもコンテナ化する予定だったのですが、仮想コンテナ化してしまうと、SSL更新のためにコンテナを停止しなくちゃいけなかったり、いくつかの通信は別のPCへ流すっていうリバースプロキシの役割も果たしているので、面倒くさくて止めました。

データベース系は元々のウェブサーバー（私はメインサーバーって呼んでる）で可動しているので、そっちにアクセスしている感じになっています。PostgreSQLを必要としているサービスが一つだけあるので、それだけはコンテナで立ち上げています。コンテンツデータはgitでバックアップ取ってるので、最悪消えても大丈夫。

こんな感じでラズパイへウェブサーバーが移行されました。具体的にどんなことしたのかとかについては、気が向けばあとで投稿しておこうと思います。

---

何故か分からないですけど、移行から一日ぐらいしてラズパイへアクセスできなくなったんですよね。原因がさっぱりなので様子見ということにはしています。もしも問題があったら、メインサーバー（旧ウェブサーバー）に戻すかも知れません。