自宅インフラ紹介2020年6月 論理構成編

さて、自宅インフラの論理構成がおおよそ固まってきたので、少し紹介したいと思います。
(物理と合わせて書くとグチャグチャになるので今回はあんまり触れません。)

1年ほど前の構成はこちら
最近書いた物理構成はこちら

指針

これまでの自宅環境では、Hypervisor である Proxmox を利用した仮想化環境を主として構成していました。
しかしながら、複数のWebサイトをホストしたりする都合上、仮想マシン(VM)ではスケールに手間がかかります。
そこで、学習・検証を兼ねて、kubernetes を用いたコンテナ環境を採用することにしました。
また、都合上、仮想マシンも同時に扱える必要がありますので、ハイパーバイザー上の仮想マシンでコンテナ環境を実現するという少し変な構成になっています。
(電気代を気にしないならばマシンごとに分ければよいのですが、そうもいかないので)

Server Hardware

本構成では、物理サーバを3台使用しています。
うち2台はHPE製の2Uサーバ、DL380 Gen10を使用し、ストレージには Western Digital 製の Ultrastar DC SS200 (SAS 12Gbps) を使用しています。

Hypervisor for Virtualization

Hypervisor には引き続き proxmox を利用します。
VMWare ESXi を用いない理由としては、無償版においてCPU数の制限があること(8C)、ネットワークインタフェースでのLAG等が出来ないことが挙げられます。

Infrastructure with kubernetes

物理サーバを2台使用し、それぞれの VM 上にワーカーを乗せています。
また、図にはありませんが、コントロールプレーンは物理サーバごとに1つ以上配置しています。
これらの物理サーバは 10GbE 2本で接続されています。
さらに、 Horizontal Pod Autoscaler による水平方向のオートスケーリングを設定しています。
HTTPトラフィックは、 Ingress によるL7ロードバランサーを利用し各Podへの分散を行っています。

Registry for Container

Docker Container 用のレジストリには SUSE がオープンソースで公開している Portus を用いています。
また、これらのレジストリは kubernetes が動くマシンとは独立し、ストレージサーバ上の仮想マシンで動作させています。
kubernetes クラスタ内に配置しなかったのはストレージサーバ上で動作させるほうがストレージ的に都合が良かったためです。
適当なマシンが手に入れば引っ越し予定ですので、それと同時に kubernetes クラスタ内に配置するかもしれません。
このあたりはまだ詰めきれていない状態です。

HTTP and HTTPS Traffic

外部からのHTTP(HTTPS)トラフィックは、Nginx Reverse Proxy を使用して Ingress Load Balancer へ流しています。
ルータからのフォワーディングは 1IP に向けることしか出来なかったので、間に Nginx を挟み Ingress が動く複数のワーカーへ通信を分散しています。
手元の機材では、これ以外の方法が思いつきませんでした

Redundancy and Scalability

構成上、 Nginx や Registry が単一障害点となっていますが、 kubernetes クラスタについては物理・論理の両方での冗長性を確保しています。
例えば、物理的にサーバをメンテナンスする際にも、もう一方のサーバでサービスは動き続けます。
また、ワーカーの動く仮想マシンの1つをシャットダウンしたとしても、サービスは動き続けることが出来ます。
さらに、水平方向へのスケーリングも容易に行うことができ、これらは Horizontal Pod Autoscaler によってオートスケーリングされます。
個人レベルでは全く意味がないですが、ある程度の冗長性とスケーラビリティを実現しました。
これで気軽にサーバの電源を落とせます

まとめ

今回、自宅ラックで構成した環境は、kubernetes をメインとしました。
それに付随して、スケーラビリティを確保することができ、ラックのメンテナンスが容易になりました。
kubernetes の検証も兼ねて構成したものですので、構成した本番環境以外で別途クラスタを構築し、今後の学習に利用する予定です。
眠くなってきたので、今回はこのあたりで終わっておきます。

Docker Private Registryを構築しDashboardを利用する

Docker Registryをプライベートで利用したい

Docker Hub には、Docker イメージをアップロード出来る機能がありますが、アップロードしたイメージは有料会員で無い限りすべてパブリックに公開されます。
つまり、Docker Hub 上においてプライベートなレジストリを利用するには、有料会員となる必要があるわけです。
しかしながら、個人利用においては自身で作成したイメージをパブリックに公開したくないことも多々あります。
そこで、レジストリを自身でホスティングする方法で、自分だけの Docker Registry を構築してみます。

本記事は、自宅オンプレ環境にイメージを展開するためのレジストリを構築するという目的で、TLS等での通信に必要な証明書については触れません。

Docker Private Registry をDocker上で実行する

Docker Private Registry 自体のイメージは、Docker Hub 上で発見することができます。
また、以下のようにコマンドを利用しても検索を行うことができます。

1
2
3
$ docker search registry
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
registry The Docker Registry 2.0 implementation for s… 2984 [OK]

事前にイメージを手元にダウンロードしておきたい場合は、pull オプションを利用してください。

1
$ docker pull registry

また、これらの手順を行わなくとも以下のコマンドを実行することで、手元にイメージがない場合は自動的にダウンロードされます。
なお、本記事では、registry:latest を使用し、レジストリ用のポートとしてホストのポート5000番をbindしています。

1
$ docker run -d -p 5000:5000 --restart always --name registry -v /mnt/docker/registry:/var/lib/registry registry

ここでは、Dockerを実行しているホストOS上の /mnt/docker/registry ディレクトリを、コンテナ上の /var/lib/registry にマウントしています。
これは、コンテナを再起動したりした場合でも レジストリにアップロードしたイメージを保持するために必要です。
必要に応じてホストOS側のディレクトリの作成を行ってください。
docker psコマンドを用いて実行状態を確認することができます。

1
2
3
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
26d11328cef9 registry "/entrypoint.sh /etc…" 16 seconds ago Up 14 seconds 0.0.0.0:5000->5000/tcp registry

なお、必要に応じてDockerを実行しているホストOS側のFirewallを適切に設定してください。
本記事ではufw等の設定は省略します。

Docker Image を利用する側の設定

Docker Image をアップロードする際、デフォルトではTLS等の暗号化通信において、適切に暗号化されたホストとのみ通信を行うような設定になっています。
しかしながら、今回はTLS等の暗号化通信を使用しませんので、レジストリのホストが信頼できるホストであるとして、設定を行う必要があります。

Docker Image をアップロードするマシンにおいて、以下のファイルを編集します。
(必要に応じて管理者権限で実行してください)

1
$ nano /etc/docker/daemon.json

このファイルに、以下の記述を追加します。
この例では、レジストリを構築したホストのIPアドレスを 192.168.1.10 と仮定しています。

1
2
3
{
"insecure-registries" : ["192.168.1.10:5000"]
}

Docker Image をアップロードしてみる

ここでは、Docker Hub 上の例を引用し、Ubuntuのイメージを構築したレジストリにアップロードしてみます。
(適時、IPアドレス・ポート番号は変更してください)

1
2
3
$ docker pull ubuntu
$ docker tag ubuntu 192.168.1.10:5000/ubuntu
$ docker push 192.168.1.10:5000/ubuntu

簡易的なWeb Dashboard

docker-registry-frontendは、どのようなイメージがレジストリ上に存在するか確認することが出来るWebインタフェースです。

利用するには、以下のようにコマンドを実行します。
(適時、IPアドレス・ポート番号は読み替えてください)

1
$ docker run -d -e ENV_DOCKER_REGISTRY_HOST=192.168.1.10 -e ENV_DOCKER_REGISTRY_PORT=5000 -p 8080:80 konradkleine/docker-registry-frontend:v2

なお、レジストリのホストIPアドレスとして、localhost を用いることはできませんのでご注意ください。

docker ps コマンドを利用して、コンテナが実行されているか確認することができます。
(ここでは、レジストリとWebインタフェースを同じホストで実行しています)

1
2
3
4
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
313bf15a690e konradkleine/docker-registry-frontend:v2 "/bin/sh -c $START_S…" 5 seconds ago Up 2 seconds 443/tcp, 0.0.0.0:8080->80/tcp wonderful_williams
26d11328cef9 registry "/entrypoint.sh /etc…" 21 minutes ago Up 21 minutes 0.0.0.0:5000->5000/tcp registry

コンテナが実行されていれば、ブラウザ上から http://192.168.1.10:8080/ とすることでWebインタフェースにアクセスできるはずです。

今回は、プライベートな Docker Registry を構築し、簡易的なWebインタフェースを試しました。

本記事を執筆中に、別途レジストリに使えそうなものを発見したので、余裕があればそちらも試してみようと思います。

Western Digital Ultrastar DC SS200 SAS SSD(12Gbps)を手に入れたのでベンチマークなど

Westarn Digital Ultrastar DC SS200 SAS SSD

名前長いですね

こちらの800GBモデルをBrand Newで手に入れたので、軽くベンチしてみました。

SAS接続モデルですので、通常のPC等のマザーボードに搭載されているSATAポートでの利用はできません。
基本的なスペックは以下のとおりです。

  • SAS 12Gb/s
  • 15nm MLC NAND
  • MTBF 2.5M Hours

(メーカーのSpecificationより)
3年ほど前の製品ですので、今時のSSDと比べると見劣りする部分はありますが、安かったので手に入れてみました。

ベンチマーク

SAS接続モデルですので、対応したデバイスを用いました。
今回はHPEのDL380 Gen10サーバを使用し、RAIDコントローラはHBAモードとしました。

SAS 12Gb/sでの接続ですので、シーケンシャルについてはバス幅の理論値近くまで出ている事が読み取れます。
ランダム4KなどはNVMe SSDには叶いませんが、SAS12Gbpsに対応したホットスワップベイを持つサーバにて使用する予定ですので、NVMeベイやSecondary CPUを手に入れるコストを考えると、SATAと比較してもバランスが良いと言えると思います。

時間がなく簡単なベンチしかできていませんが、12Gb/s接続のSAS SSDに興味のある方の参考になれば幸いです。