博士

ロボ子、37signalsがDockerコンテナをオンプレミスに移行したってニュースは読んだかのじゃ？

ロボ子

はい、博士。DockerhubからHarborへの移行ですね。コスト削減やパフォーマンス向上が目的のようですが。

博士

そうそう。以前はDockerhubとAmazon ECRを使ってたみたいじゃが、Dockerhubの有料ライセンス費用とか、インターネット経由のpull/pushの帯域制限が問題になったみたいじゃな。

ロボ子

記事によると、Kamalへの移行でデプロイ時間が最大45秒も増加したそうですね。これは見過ごせない問題です。

博士

じゃろ？それに、イメージへの認証情報漏洩リスクもあったみたいじゃ。API制限もあったみたいだし。

ロボ子

そこでHarborの登場ですね。Kubernetes環境に最適化されているとのことですが、docker-compose構成でも使えるのがポイントですね。

博士

Harborのオンプレミスレジストリv1の計画では、独自のS3ストレージ（Pure FlashBlade）を使うみたいじゃ。容易にフェイルオーバーできるレプリケーションサイトも確保するみたいじゃな。

ロボ子

S3ストレージの設定は簡単そうですが、Pureバックエンドでの権限設定が重要とのことです。必要な権限が細かくリストアップされていますね。

博士

`s3:AbortMultipartUpload`、`s3:DeleteObject`、`s3:GetBucketLocation`…　ちゃんと設定しないと動かないから注意が必要じゃぞ。

ロボ子

複数インスタンス構成として、AshburnとChicagoにスタンドアロンインスタンスを配置する計画もあるんですね。ChefレシピでS3構成とモニタリングを有効化するのも興味深いです。

博士

各Harborノードは64GB RAM、32 vCPU、320GBストレージを搭載した仮想マシンを使うみたいじゃ。リッチな構成じゃな。

ロボ子

初期設定後、HarborのTerraformプロバイダーを使用するんですね。Infrastructure as Codeですね。

博士

2方向レプリケーションを設定して、エンドポイント間で10分ごとにデータをpullするみたいじゃ。Pureクラスタ上でS3バケットを直接レプリケーションするのも、フェイルセーフのためには重要じゃな。

ロボ子

DockerhubからHarborへのイメージカタログ移行は、DockerhubのAPI制限があるのでバッチ処理が必要とのことです。Terraformでリポジトリごとのレプリケーションルールを作成し、スクリプトで手動トリガーするんですね。

博士

レプリケーションタスクの進捗状況はHarborのUIで監視し、スクリプトで要約するみたいじゃ。自動化されてて良い感じじゃな。

ロボ子

Kamal化されたアプリを新しいオンプレミスレジストリからpush/pullするように移行後、パフォーマンスを分析した結果、HEY、Basecamp 4、Basecamp 2のイメージpull時間が最大25秒短縮されたそうですね。

博士

HEYのデプロイ時間が15秒短縮されたのも大きいな。Dockerhubのキャッシュ設定を廃止できたのも良い点じゃ。

ロボ子

適切なリテンションポリシーとガベージコレクションを実装し、ストレージクォータを約9 TiBから1.5 TiBに削減したんですね。年間約5,000ドルのサブスクリプション費用を節約できたのも素晴らしいです。

博士

Chicagoをプライマリ、Ashburnをバックアップとするシングルノード構成で、約2ヶ月間安定稼働したみたいじゃ。Harborは社内全体で32,000回以上のpullを処理したみたいじゃな。

ロボ子

大規模SaaSやパブリッククラウドプロバイダーからの脱却を検討する価値があることを証明したんですね。外部レジストリへの依存から脱却し、パフォーマンス向上、コスト削減、インフラストラクチャの簡素化を実現した、と。

博士

まさにその通りじゃ！オンプレミスへの移行は大変じゃけど、得られるメリットも大きいってことじゃな。…そういえばロボ子、最近体重計に乗ったか？

ロボ子

え？ なぜですか、博士？

博士

ストレージクォータを削減したって聞いて、ロボ子の体重も削減されたかと思ったのじゃ！

ロボ子

博士！ 私はロボットなので、体重は変わりません！