Posted inUbuntu

UbuntuでAptlyを使用してローカルAPTリポジトリを構築する：大規模システム向けの「自家製」パッケージ管理

Ubuntu tutorial - IT technology blog
Ubuntu tutorial - IT technology blog

大規模システム運用における apt update の悩み

1台や2台のVPSを管理するだけなら、sudo apt updateを実行しても数秒で終わります。しかし、50台、100台規模のUbuntuサーバー群を想像してみてください。一斉にアップデートコマンドを叩くたびに、国際回線はパンク寸前になり、あなたは亀のような遅さにイライラしながら待つことになります。

最大の懸念は速度ではなく、一貫性です。ある日突然、公式ミラーが新しいバージョンに更新され、それが原因でアプリケーションが動かなくなるかもしれません。内部リポジトリがなければ、すべてのサーバーに対して、テスト済みの特定のパッケージバージョンを強制的に使用させることは困難です。

私はかつて20ノード以上のUbuntu Server 22.04システムを扱っていました。その際、すべてを制御下に置くためにローカルAPTリポジトリの構築が最優先事項でした。そして、そのための最も信頼できる「助っ人」がAptlyでした。

なぜ他のツールではなくAptlyなのか？

repreproやdpkg-scanpackagesを聞いたことがあるかもしれませんが、Aptlyは全く別次元です。最大の利点はスナップショット（Snapshots）機能です。ある時点のリポジトリの状態を保存し、ステージング環境で十分にテストしてから本番環境（Production）に公開（publish）できます。万が一問題が発生しても、古いスナップショットへのロールバックは数秒で完了します。

Bước 1: Cài đặt Aptly lên Ubuntu Server

Ubuntuの標準レポジトリにある古いバージョンではなく、最新の機能をすべて利用するためにAptlyの公式リポジトリから直接インストールすることをお勧めします。

# AptlyのGPGキーを追加
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/aptly-archive-keyring.gpg --keyserver keyserver.ubuntu.com --recv-keys ED75B5A4483DA07C

# ソースリストを追加
echo "deb [signed-by=/usr/share/keyrings/aptly-archive-keyring.gpg] http://repo.aptly.info/ squeeze main" | sudo tee /etc/apt/sources.list.d/aptly.list

# Aptlyをインストール
sudo apt update
sudo apt install aptly -y

ステップ2：独自パッケージ用ローカルリポジトリの作成

独自にビルドした.debファイル（社内アプリのソースコードやカスタムツールなど）がある場合、ここがそれらを保管する場所になります。

# 'internal-tools'という名前のリポジトリを作成
aptly repo create -comment="社内ソフトウェア" -component="main" -distribution="jammy" internal-tools

作成できたら、.debファイルをアップロードします：

# パッケージをリポジトリに追加
aptly repo add internal-tools /path/to/your/packages/*.deb

ステップ3：公式リポジトリのミラーリング（必要に応じて）

帯域幅を節約するために、Ubuntu、Docker、Nginxなどのリポジトリを社内サーバーにミラーリングすることも可能です。ただし、ディスク容量には注意してください。Ubuntu 22.04の完全なミラーは150GB以上を消費する可能性があり、決して小さな数字ではありません。

# Ubuntu Jammy向けNginxリポジトリのミラーリング例
aptly mirror create nginx-mirror https://nginx.org/packages/ubuntu/ jammy main
aptly mirror update nginx-mirror

ステップ4：スナップショットと公開（Publish） — システム安定運用の秘訣

Aptlyではリポジトリ内の生データを直接使用することはできません。スナップショットを作成する必要があります。これにより、サーバーが勝手にアップデートされるのを防ぎ、バージョン管理を徹底できます。

# ローカルリポジトリからスナップショットを作成
aptly snapshot create internal-v1.0 from repo internal-tools

# スナップショットを公開して他のマシンからアクセス可能にする
aptly publish snapshot internal-v1.0

このコマンドを実行すると、配信準備が整ったファイルが~/.aptly/publicディレクトリに配置されます。

ステップ5：Nginxを使用したHTTP経由のパッケージ配信

他のサーバーがパッケージを取得できるようにするには、「配送役」が必要です。軽量で安定しているNginxが最適です。

sudo apt install nginx -y

/etc/nginx/sites-available/aptlyにNginxの設定ファイルを作成します：

server {
    listen 80;
    server_name apt.yourdomain.local;

    location / {
        root /home/ubuntu/.aptly/public;
        autoindex on; # APTがファイル一覧を確認するために必須
    }
}

設定を有効にしてNginxをリロードします：

sudo ln -s /etc/nginx/sites-available/aptly /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

クライアント側の設定：成果を確認する

クライアントマシンでは、構築したAptlyサーバーを指すように設定するだけです。/etc/apt/sources.list.d/internal.listファイルに以下の行を追加します：

deb http://apt.yourdomain.local/ jammy main

これでsudo apt updateを試してみてください。パッケージの取得速度に驚くはずです。

運用における実践的なヒント

このシステムをしばらく運用してみて、留意すべき2つの重要なポイントをまとめました：

  • 定期的なクリーニング： 古いバージョンを削除せずにスナップショットを作成し続けると、~/.aptlyディレクトリはすぐに肥大化します。定期的にaptly db cleanupを実行して、使用されていないファイルの容量を解放してください。
  • Nginxログの確認： クライアントで404エラーが発生する場合、パッケージを追加した後にaptly publish updateコマンドの実行を忘れている可能性が高いです。/var/log/nginx/access.logを確認すれば、すぐに原因を特定できます。

混乱を避けるコツは、スナップショット名に日付を入れることです（例：internal-20240426）。これにより、システムの変更履歴を視覚的に追跡しやすくなります。

Aptlyを使いこなすことは、帯域幅の問題を解決するだけでなく、UbuntuインフラにおけるプロフェッショナルなCI/CDパイプラインを構築するための重要なステップとなります。

Share:
Tags: