必要なプロバイダーのみを使用して Fog gem を構築し、依存関係を制限する

概要

私は、Rackspace Cloud Files サービスだけにアクセスするために、優れた Fog gem を使用しています。私の課題は、Cloud Files にアクセスするサービスを軽量に保とうとしていることですが、Fog にはその柔軟性により、私には決して必要のない依存関係とコードがたくさんあるようです。

プロバイダーのサブセットを含めて依存関係を制限するためだけに、Fog のスリム化されたコピーを構築しようとした人はいるでしょうか?たとえば、Rackspace Cloud Files API だけを使用する場合、net-ssh、net-scp、nokogri gem や、Amazon、Rackspace、およびまだ提供されていないその他 20 のプロバイダーの未使用のコードを使用せずに、すべてを処理できると期待しています。使用済み。メモリ使用量を抑えながら、使用されていないプロバイダーのいずれかがバグに気づくたびに gem をアップグレードすることを避けたいと考えています。

これを行う際に誰かが経験したこと、または私が取り出せるものと取り出せないものについてFogを構築することに精通している人からのアドバイスをいただければ幸いです。

間違った gem を使用しているだけであれば、それは同様に問題ありません。もっと焦点を絞ったものに移ります。

解決策

私は霧の管理者なので、説明やギャップを埋めるために協力させていただきます。簡単に言うと、それはたくさんありますが、ほとんどの場合、あなたに悪影響を与えることはありません。

まず、霧は時間の経過とともに非常に自然に成長したため、意図したよりも大きくなりました。これに対処する方法の 1 つは、本当に必要になるまでファイルの要求やロードを積極的に避けることです。そのため、フォグのインストールに使用しないプロバイダーファイルを大量にダウンロードする必要がありますが、実際にはそれらがメモリ内に残ることはありません。これは、メモリ使用量 (およびロード時間) を削減しながら、物事を「正常に動作」させ続けるためにできる最も簡単な方法でした。

リリーススケジュールはそれほど突飛なものではなく (平均して月に 1 回程度)、ほとんどのプロバイダーのものが混在する傾向があります。したがって、ここではそれほど多くのチャーンは発生しないと予想されます（通常のサイクルを短縮する必要がある緊急/セキュリティタイプの修正を除く）。

したがって、うまくいけば、最先端技術についての洞察が得られます。また、長期的には物事をより分割し始めることについても議論しました。それが起こったら、ラックスペース関連のすべてをフォグラックスペースのようなものにすることになると思います。そして、fog-core などを通じて共有できるようになります。大まかな概要はありますが、これは大きなメリットのないかなり大規模な事業であるため、実際に積極的に始めたものではありません。

ご参考になれば幸いです。さらにご質問やご不明な点がございましたら、喜んでご相談させていただきます。