メインコンテンツまでスキップ

「home server」タグの記事が5件件あります

全てのタグを見る

snake

DockerのSwarm modeには、ルーティングメッシュと呼ばれる機能があります。この機能により、外部からのアクセスをロードバランシングすることができます。ルーティングメッシュにより、接続先のノード自身がタスクを実行していなくても、タスクが利用可能なノード上へリクエストを転送してくれるようになります。 Use swarm mode routing mesh

この機能は便利であり、Swarmを冗長構成にするのであれば、必要不可欠な機能の一つです。ただし、ルーティングメッシュが有効になっている場合、アクセス元のIPアドレスを取得できない可能性がある問題が存在しています。正確には取得できますが、接続元のIPアドレスではなく、アクセスを受け付けたノードのIPアドレスが取得されます。

最初に提示した画像を元に説明を行います。

仮に203.0.113.10から Node-03（192.168.10.102:8080）へアクセスがあったとします。Node-03上に利用可能なタスクがないため、全てのリクエストは利用可能なタスクの存在する異なるノードへ転送されます。そのためNode-01もしくはNode-02のnginx.1がアクセスを受けます。この時、アクセスを受けたnginx.1でアクセスログを確認すると、接続元のIPアドレスはNode-03のIPアドレスである192.168.10.102が記録されています。

という訳で、ルーティングメッシュによりリクエストが転送された場合、転送元のノードのIPアドレスが記録されてしまいます。

一般的に元のIPアドレスを取得場合、httpではX-Forwarded-Forと呼ばれるプロキシを通した際に元のIPアドレスを保持する仕組みを利用し、L4ではProxy Protocolと呼ばれるロードバランサを通した際に元のIPアドレスを保持する仕組みを利用します。

しかしながら、ルーティングメッシュによって転送されたリクエストは、X-Forwarded-ForやProxy Protocolが対応してないんですね。類する代替手段が用意されている訳でもないため、Docker Swarmのみで元のIPを取得することは不可能です。

この問題はすでに把握されており、issueは立ち上げられています。しかし、2016年から開かれ続けており、すぐに解決される問題ではない気がします。

Unable to retrieve user’s IP address in docker swarm mode · Issue #25526 · moby/moby

Proxy Protocolのサポートも同様にissueは立ち上がっているものの、すぐに解決される問題ではなさそうです。

Proxy Protocol support in Swarm ingress · Issue #39465 · moby/moby

対処法１​

この問題に対する対処法として、ルーティングメッシュの無効化があります。しかし、Overlay Networkの利点を失うことになる点は注意してください。

Docker-composeの場合、long syntaxでポートを以下のように指定することでルーティングメッシュを無効化することができます。

  • target: 80 published: 80 protocol: tcp mode: host
  • target: 53 published: 53 protocol: udp mode: host

modeを省略した場合、もしくは、ingressを設定した場合はルーティングメッシュが有効になります。

Docker Swarmを使う意味がよく分からなくなりますが、クラスタの外側にHAProxyのようなロードバランサを設置してあげることで、ルーティングメッシュみたいなことはできるようになります。

対処法２​

docker-ingress-routing-daemonなるものを利用することで、元のIPアドレスを取得できるようになるらしいですが、使ったことがないので詳しいことはよく分かりません。少なくとも、私は複雑になり過ぎるので使おうと思いませんでした。

GitHub - newsnowlabs/docker-ingress-routing-daemon: Docker swarm daemon that modifies ingress mesh routing to expose true client IPs to service containers

snake

これまでこのウェブサイト上の画像は、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にできなかったので、ここに関しては速度は変わっていません。

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

snake

先日のサーバー障害でおそらくCPUとマザーボードのどちらも壊れたので、どちらも載せ替えることにしました。載せ替え後のCPUについてと、なぜそれを選んだのかについて話しておきます。

載せ替え前のCPU​

  • Intel i5 4世代
  • 4コア8スレッド（多分）

詳細覚えてません。

載せ替え後のCPU（結局壊れてたやつ）​

  • Intel(R) Xeon(R) CPU E5-2650L
  • 8コア16スレッド
  • クロック 1.80GHz
  • TDP 70W

インテル® Xeon® プロセッサー E5-2650L (20M キャッシュ、1.80 GHz、8.00 GT/s インテル® QPI) 製品仕様

最終的なCPU（今のサーバーで使ってるやつ）​

  • Intel(R) Xeon(R) CPU E5-2650 v2
  • 8コア16スレッド
  • クロック2.60GHz
  • TDP 95W

製品仕様

これを選んだ理由ですが、マザーボードが対応しているCPUとして一番手頃な価格帯で入手可能で、TDPが95Wと結構現実的だったので選択しました。

そもそもなぜマザーボードも壊れたのに、マザーボードベースでCPUを選んだのか。それはマザーボード取り替えてから、CPUが壊れている可能性（もしくは読み込めない可能性）が浮上した為、後にCPUを取り替えたという順序だからです。

  • おそらくマザーボードが壊れた
  • マザーボード購入＆交換
  • CPUが読込できていない（POSTCODE 00）
  • おそらくCPUも壊れてる（もしくはマイクロコード的に対応していない）
  • CPU購入＆交換

マイクロコード的に対応していない可能性を考えているのは、読み込めなかったCPUがES（Engineering Sample）品である為です。サーバーにES品使うなという意見は受け付けますが、自宅サーバーなので許してください。

とりあえず、マザーボードを先に買ってしまったからにはもう今更ソケットが異なるマザーボードを買おうとはならないので、ソケットとマザボ自体が対応しているCPUを購入することにしました。

ソケット自体に適応するCPUは様々ありますが、マザボもソケット（FCLGA2011）も相当古いものなので、公式が検証し動作保証されているCPUの中から選びました。

CPUを選ぶ基準は以下のとおりです。

  • TDP 100W以下（より低くベンチマークとしても十分でるもの）
  • 8コア以上
  • 16スレッド以上
  • 中古正規品が格安（10,000円以下、高くても15,000円以下）で出回っている
  • すぐ届く（重視、AliExpressのはすぐ届かないから対象外）
  • 動作保証してくれる（返品可）

以上の基準を満たすものを各CPUで検索かけた所、いくつかに絞れました。

ちなみに４つめの「中古正規品が格安（10,000円以下、高くても15,000円以下）で出回っている」この段階でXeon以外のCPUが消滅しました。純粋に公式で動作保証されているCPUが出回っていませんでした。より正確にはあるにはあるけど、高いか国外からで本当に届くかすら分からないような品が少しあるのみでした。

結果Xeon CPU3個ほどに絞れました。本当はXeonの型番にLがつく低燃費モデルが良かったのですが、ずば抜けて高かったので早々に無くなりました。それで、残ったCPUで最もコスパの良いIntel(R) Xeon(R) CPU E5-2650 v2を購入しました。

入れ替え後２日目ですが、随分と快適です。以前よりもスペック自体は上がっているので、特に困ることもなくストレスフリーで動作しています。

snake

タイトルのとおりです。

※この投稿はIQ3で書きました。深いことは考えないでください。

Twitterを見てくださってる方は分かるかも知れませんが、サーバーが壊れました。なぜ壊れたのかは分かりません。後で余裕があったら調べてみようと思います。

取り敢えず何があったかを書くと、

  • カーネルパニック操作不可能！！！
  • 再起動！！！
  • 起動しない！！！
  • BIOSつかない！！！
  • 最小構成にしたり、色々しても何も変わらない！！！
  • 多分、ハードウェアぶっ壊れた！！！
  • ついでに疲弊で精神もぶっ壊れた！！！（１度目の精神崩壊）
  • BIOSつかないし、マザーボード変えればなんとかなるかも！！！（安直）
  • マザーボード、ヤフオクで安く買った！！！
  • 動かない！！！（２度目の精神崩壊）
  • 電源変えたり、色々やってみるもQCODEが00から変わらない！！！（QCODE00はCPUが認識できてない）
  • もしかしたらCPUが逝ったかもしれない！！！（３度目の精神崩壊）
  • CPU買う！！！天下のヤフオクから安く買った！！！（脳死）
  • なんか動かない！！！（発狂、４度目の精神崩壊）
  • QCODE65！！！dxe initialization！！！ナニソレオイシイノ！？
  • 色々検証してたらQCODE00！！！意味がわかんないよ（５度目の精神崩壊）
  • BIOS立ち上がった！！！（歓喜）
  • メモリ8GBしか読み込んでない！！！なんで！！！（死）
  • どうやらメモリスロット左側４つがすべて死んでいるようだ！！！
  • 右側に全部ぶっ刺してOS起動OK！！！
  • ネットワークにつながらない！！！（ただの設定ミス）
  • 起動チェックに使ってたGTX 1050Tiを外した！！！
  • マザーボード「GPU無いぞバカ」
  • GPU買うの忘れた！！！バカ！！！
  • メルカリでやすいのポチる！！！
  • 届く！！！
  • ロープロファイル買っちゃった！！！ブラケットのサイズ違う！！！
  • ブラケット外せばいいっしょ！！！（脳死）
  • 起動！！！
  • なんかクラウドとWEBSOCKET通信できてない！！！（発狂、６度目の精神崩壊、２度目の死）
  • とりま、全部アップデートする！！！（考えるのを止めた）
  • 直った！！！（なんでかはまじで分からん）
  • 起動OK！！！
  • 問題あるけど、今日眠い寝たい！でも報告と忘れないうちにブログ書かなきゃ！←今ここ

以上、２０２１年１１月１７日に発生し、２０２１年１１月２９日に解決したサーバーぶっ壊れ事件、１４日間の出来事です。

snake

ヤフオクに出品されていた格安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でバックアップ取ってるので、最悪消えても大丈夫。

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

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