アーティファクトの管理について、あるいは go-apt-cacher / go-apt-mirror の紹介

誰も本名で呼んでくれないので社内でもハンドルで通そうと ymmt と呼ぶよう社内に本部長命令を出したお願いしている @ymmt2005 です。

今回はサイボウズ社内でどのようにアーティファクトを管理しているか紹介します。アーティファクトというのはソフトウェア開発では成果物のことを指します。成果物もいろいろありますが、もっぱら興味の対象になるのはデータセンターにデプロイしたりお客様に配布したりする JAR や実行ファイルやアーカイブです。

忙しい人のために 4 行でまとめておきます。

• JFrog Artifactory をアーティファクト管理に利用している
• Debian パッケージ(deb)を作成・管理する仕組みがある
• 各地のデータセンターで利用するため go-apt-cacher / go-apt-mirror を作った
• 既存の apt-mirror ã‚„ apt-cacher-ng の問題を解消しているので試してみてね

JFrog Artifactory とは

JFrog Artifactory (以下 Artifactory)は JFrog 社が提供しているアーティファクト管理用の Web アプリケーションです。無償のオープンソース版では Maven リポジトリの機能だけ使えますが、商用版では Debian/Ubuntu で使われる APT, Node.js で使われる NPM, Python で使われる PyPI など多数のリポジトリがサポートされています。

サイボウズでは Artifactory 商用版の一番安いエディションを一つ導入しています。一番安いものでもリポジトリの機能数に違いはなく、高いエディションは冗長化が主な差異なので、自社技術である冗長化ストレージ square や自動障害回復システム 月読を利用して節約というわけです。

Debian/Ubuntu パッケージの利用

サイボウズ社内では非常に多くの Ubuntu サーバーが動作しています。VM・実機合わせると数千台というところでしょうか。Debian/Ubuntu では deb というファイル形式で各種プログラムがパッケージングされています。インストール時やセキュリティパッチなどの際にはこの数千台のサーバーが多数の deb ファイルをダウンロードすることになります。

deb ファイルのリポジトリは APT というツールがサポートする形式で管理されますが、Artifactory を利用すると独自の APT リポジトリを構築して、REST API で Jenkins や Drone のような CI サービスから自動的にアップロードすることが簡単に実現できます。CI から Artifactory に自動デプロイすると継続的デリバリーの完成ってなわけです(そこから先の道程もまだありますが)。

サイボウズでは自社製のプログラムを簡易に deb パッケージ化する仕組みを考案して、Artifactory に自動アップロードするようにしています。仕組みについては「社内利用のための deb パッケージング入門」をご覧ください。

Artifactory は Ubuntu の公式 APT リポジトリをキャッシュする仕組みはあるのですが、ミラーする仕組みは持っていません。当社では定期的にセキュリティ更新を適用するようにしているため、キャッシュでは都合が悪いので必要なタイミングで別のツールを使ってミラーするようにしています。

キャッシュとミラー

Artifactory は 1 台しかないため、地理的に離れた各拠点・データセンターではそれぞれのリージョン内で deb ファイルをキャッシュしたりミラーする必要があります。さもないと拠点間のネットワーク帯域の浪費や、インストールやパッチ適用に長時間を要するということになるためです。

頻繁に更新があるリポジトリはキャッシュ、定期的に更新があるリポジトリはミラーするのが適切です。前者にあたるのが社内アーティファクト用 APT リポジトリ、後者にあたるのが Ubuntu 公式リポジトリです。

キャッシュは Squid のような通常の HTTP プロキシも利用できないことはないのですが、APT のインデックスファイルや各種ファイルの更新は独自の仕組みとなっているため、HTTP のキャッシュの仕組みは相性が良くないです。そこで、APT 専用のキャッシュサーバーである apt-cacher-ng を当初は利用していました。

ミラーについては必要なアーキテクチャのサブセットのみミラーできる apt-mirror を利用していました。

go-apt-cacher / go-apt-mirror

ようやく本題ですが、apt-cacher-ng と apt-mirror にはそれぞれ解消が困難な課題があったため、問題を解消した自社製の APT 専用キャッシュ/ミラーツール go-apt-cacher / go-apt-mirror を作成しました。

apt-cacher-ng の問題は、HTTPS な上流サーバーに多数の同時接続をするとクラッシュすることでした。デバッグを試みたのですが、内部構造が複雑なため時間がかかり諦めました。自作なら数日で作れそうと踏んで実際に作ったのが go-apt-cacher となります。

go-apt-cacher の特長は以下の通りです。

• Release ã‚„ Packages を認識しチェックサム情報を抽出
• チェックサムに合致しないファイルは破棄してキャッシュしない
• Release は自動定期更新
• チェックサムが更新されたら該当ファイルはキャッシュから破棄
• LRU なディスクキャッシュ
• 千台単位の同時クライアント接続をサポート
• 高速(キャッシュ済みファイルなら 1 ms 以下で処理)

apt-mirror の問題はミラー結果が壊れていることがあるというものです。他にもポート番号が付いた URL を適切に扱えない等の問題があるのですが、開発が活発でなく提案されている修正がマージされず放置されている状況でした。そこで go-apt-cacher の成果を流用してこちらも独自に開発したのが go-apt-mirror となります。

go-apt-mirror の特長は以下の通りです。

• 必要なアーキテクチャ等を指定して部分的なミラーを構築可能
• rsync より高速な更新処理
• 不完全なミラーは決して作らない
• ミラーの更新がアトミックで、更新途中のミラーはクライアントに見せない

詳しくは先日の東京 Debian 勉強会で同僚の湯谷が発表した資料をご覧ください。

go-apt-cacher/mirror from yutannihilation

まとめ

サイボウズ社内のアーティファクト管理の仕組みを紹介しました。

go-apt-cacher / go-apt-mirror はリリースしたばかりですが、すでにサイボウズ社内の apt-cacher-ng / apt-mirror は置き換え済みです。同様の課題にお悩みのかたは是非お試しください。

ソースは https://github.com/cybozu-go/aptutil で公開しています。