仮想マシンをインストールしていると、aptの通信ロスが時間ロスになって気になった。
１分程度だけど、何度も実行してると疲れてくるので、apt-cacher-ngを使うことにした。
apt-cacher-ng をdocker で起動する
---
version: '2'
services:
apt-cacher:
container_name: proxies-apt-cacher
image: sameersbn/apt-cacher-ng
ports:
- 3142:3142
docker-compose で起動する
sudo docker-compose pull sudo docker-compose up
apt に設定して使う場合
echo 'Acquire::HTTP::Proxy "http://172.17.0.1:3142";' |sudo tee /etc/apt/apt.conf.d/01proxy
名前解決ができる場合。
echo 'Acquire::HTTP::Proxy "http://apt-cacher.lan";' |sudo tee /etc/apt/apt.conf.d/01proxy
preseedで使う場合
preseed.cfg に次のとおりに記載する。(ip は環境依存)
d-i mirror/country string manual d-i mirror/http/hostname string debian-mirror.sakura.ne.jp d-i mirror/http/directory string /debian d-i mirror/http/proxy string http://172.17.0.1:3142
使ってみた結果
ローカルホストでミラーは速いですよね。やっぱり。ボトルネックは純粋にディスクIOだけになった。
docker で作ったapt-cacher-ngの場合、apt-cacherのまれなエラーで自動処理が止まることがある。
proxies-apt-cacher | [warn] Epoll ADD(1) on fd 12 failed. Old events were 0; read change was 1 (add); write change was 0 (none); close change was 0 (none): Bad file descriptor
apt-cacher-ng は概ね良好に起動するが、まれにエラーが出て、APTパッケージの取得に失敗する。再度トライすれば問題なくインストールが終わる。
手作業でインストールするときはもんだ無いが、完全無人だと気づかずにインストールが死ぬので、問題が多い。
無人インストールでapt-cacherを使うなら、手作業で初回キャッシュさせたほうが無難かもしれない。
apt-cache-ng は単なるプロキシ
ちょっと変わったプロキシなので、ubuntu/debian だけでなく、cygwin や centos(yum)でも使えるので、ローカルや組織内に１つくらいあってもいいかもしれない。
ubuntu側で指定の仕方 インストール時点
ubuntu の場合、ここでインストールで指定することもできる
指定の仕方 インストール済み
OSが起動後に指定するには
echo 'Acquire::HTTP::Proxy "http://172.17.0.1:3142";' >> /etc/apt/apt.conf.d/01proxy
https の apt のキャッシュ
HTTPS で指定された APTソースのキャッシュをするには、次のようにする。
## brefore # deb [arch=arm64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu jammy stable ## after https -> http deb [arch=arm64 signed-by=/etc/apt/keyrings/docker.gpg] http://download.docker.com/linux/ubuntu jammy stable
https を http に変えればいい。こうすれば apt::proxy 設定が動くようになる。
しかも apt-cacher が http->https の内部リダイレクトを処理しキャッシュてくれます。（プロキシなんで）
え？httpのセキュリティ？なんのために、gpgを指定すると思ってるのですか？gpg で署名ですよ？gpgで、整合性確保、通信内容の改竄検出ができますよ？
動作チェック( キャッシュの場所）
docker 起動した apt-cacher-ng がキャッシュを溜め込んでくれているかどうかをチェックする。
キャッシュは次のフォルダに溜め込まれる
/var/cache/apt-cacher-ng
なので次のように、キャッシュのフォルダを見れば動作を確認が可能。
docker exec -it apt-cacher find /var/cache/apt-cacher-ng
キャッシュを溜め込んでくれてるのがわかる。
takuya@docker:~$ docker exec -it apt-cacher find /var/cache/apt-cacher-ng /var/cache/apt-cacher-ng /var/cache/apt-cacher-ng/_xstore /var/cache/apt-cacher-ng/_xstore/rsnap /var/cache/apt-cacher-ng/_xstore/qstats /var/cache/apt-cacher-ng/_xstore/qstats/i /var/cache/apt-cacher-ng/_xstore/qstats/o /var/cache/apt-cacher-ng/raspbian.raspberrypi.org /var/cache/apt-cacher-ng/raspbian.raspberrypi.org/raspbian /var/cache/apt-cacher-ng/raspbian.raspberrypi.org/raspbian/pool /var/cache/apt-cacher-ng/raspbian.raspberrypi.org/raspbian/pool/main /var/cache/apt-cacher-ng/raspbian.raspberrypi.org/raspbian/pool/main/s /var/cache/apt-cacher-ng/raspbian.raspberrypi.org/raspbian/pool/main/s/sudo /var/cache/apt-cacher-ng/raspbian.raspberrypi.org/raspbian/pool/main/s/sudo/sudo_1.9.5p2-3+deb11u2_armhf.deb /var/cache/apt-cacher-ng/raspbian.raspberrypi.org/raspbian/pool/main/s/sudo/sudo_1.9.5p2-3+deb11u2_armhf.deb.head
キャッシュの削除
キャッシュの削除は、手動・専用コマンド・WebGUI、またはtmpfs 。などにより削除する
apt-cacher-ng のキャッシュを消すとき、docker で起動していると工夫が必要。
キャッシュをtmpfs においておいて、再起動したり。色々と省力化は可能になる。メモリが潤沢にあれば、/var/cache/apt-cacher-ng を tmpfs にしておくとか、念の為にスワップしておくのが楽ちんと思う。
docker で起動した場合の注意。
docker のボリュームで/var/cache/apt-cacher-ngをマッピングした場合は、再起動で消えないのでボリュームを明示的に消す必要がある。
例えば以下のように起動した場合
services:
apt-cacher:
image: sameersbn/apt-cacher-ng
container_name: apt-cacher
volumes:
- 'apt-cacher-ng-vol:/var/cache/apt-cacher-ng'
上記の設定の場合はボリュームが永続化するので再起動でキャッシュが消えないので、キャッシュを再利用して使い続けることが可能になる。
しかし、再起動で消えないので、キャッシュ期限切れを確認し削除する必要が出てくる。それは専用コマンド（後述）かWebGUI（後述）を使う必要がある。
もしくは、定期的なタイミングでDockerボリュームを削除する必要がある。
tmpfs を使ってしまうのもいい
services:
apt-cacher:
image: sameersbn/apt-cacher-ng
container_name: apt-cacher
ports:
- '10.160.195.160:3142:3142'
# volumes:
# - 'tmpfs:/var/cache/apt-cacher-ng' <-- これはできない
# tmpfs こうする。
tmpfs:
- /var/cache/apt-cacher-ng
こうすると、インスタンスの再起動にボリュームが消える。しかもtmpfs(メモリ）に書くので速度向上も狙える。
上記のようにtmpfs で起動すると、結果は以下のようになる
$ docker exec apt-cacher bash -c 'mount | grep tmpfs | grep apt' tmpfs on /var/cache/apt-cacher-ng type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=2755,inode64)
acngtool キャッシュ管理( 特にdocker 版で注意）
acngtool キャッシュ管理を知る必要がある。とくに aptcacher-ng をdocker で使うなら、真っ先に知っておくべきことだ。
キャッシュは次の場所で期限切れチェックがされる。
cat /etc/cron.daily/apt-cacher-ng
acngtool で APT のキャッシュの期限切れをチェックしている。またそれは自動で行われる。
自動キャッシュの管理はcron 設定で行われる。そのファイルは /etc/cron.daily/apt-cacher-ng である。
このおかげで自動でキャッシュが管理され、ストレージを浪費せずに住む。
自動管理は、crond から起動される。cron 処理設定の内部にある/usr/lib/apt-cacher-ng/acngtool が作れている。このファイル内部でacngtoolが実行され、apt-cacher の古いキャッシュが削除される。
cronがないと自動管理されない。特に注意すべきなのが dockerだ。
「*docker インスタンス では cron 処理されずキャッシュがたまり続ける**」のだ。
特に、docker run sameersbn/docker-apt-cacher-ng で使っている場合は sameersbn/docker-apt-cacher-ngに crond が含まれない。
docker インスタンスに crondが含まれるはずもない。
だって docker は再起動したらインスタンスのデータ消すじゃん？
その時点でキャッシュも消えるわけ。だからdocker build 時に使うならともかく、サーバ郡の内部プロキシとして常時起動で使うなら キャッシュの削除が必要になる。
dockerの場合は、手動で動かすか、定期的なdockerインスタンス再起動でボリューム削除が必要になることをお忘れなく。
docker exec apt-cacher /etc/cron.daily/apt-cacher-ng
または、手作業で、コマンドからacngtoolを実行する
# acngtoolは cron-daily から実行する docker exec apt-cacher /etc/cron.daily/apt-cacher-ng
または、管理画面のキャッシュ期限切れチェックを定期的に実行する
curl 'http://apt-cacher.lan/acng-report.html?abortOnErrors=aOe&doExpire=Start+Scan+and%2For+Expiration&calcSize=cs&asNeeded=an'
または、docker volumeを使い捨てにして、docker インスタンスを再起動
## 永続化ストレージをつかわない docker kill apt-cacher
または、docker volume を使って、ボリュームも削除する
docker-compose down docker volume rm $vol_name docker-compose up -d --remove-orphans
など、docker で起動すると考慮する事が増えて面倒も多い。
cacher は遅い？そりゃキャッシュするまでは遅い。事前キャッシュしろ
初回は遅いです。キャッシュの効果が得られるのは２度目からです。効果が出てくるのは ubuntu や debian が複数台存在したリ、何度もインストールを繰り返す場合です。当たり前なのに「やってみたけど、遅かった。。。」とか書いてるのを見つけて、例のAAが思い浮かぶ。
せめて事前にバックグラウンドでaptをミラー化しとけよ。pre-cache設定あるだろ。
管理画面がある。
http://apt-cacher.lan:3142/acng-report.html のように アクセスすると、状況を見ることができる。
キャッシュの削除や特定レポジトリのミラーリングなど管理画面を使ったほうが楽な場合も多い。
HTTPS の問題解決の方法
https のレポジトリをいい感じに、apt-cacher を通すにはhttp:// を使う。
https:// -> http://とすれば、apt-cacher がレポジトリ取得時にWEBサーバーから https へリダイレクト要求に従ってくれる（稀にリダイレクトせずに４０４を返してくるレポジトリがある）
http で プロキシ側でリダイレクトする例
## https -> http にする deb [signed-by=..] http://packages.gitlab.com/gitlab/gitlab-ce/debian/ bookworm main deb-src [signed-by=..] http://packages.gitlab.com/gitlab/gitlab-ce/debian/ bookworm main
https を使うようなレポジトリだと、キャッシュする必要がないことも多い。
そのようなときは、以下のように HTTPS はプロキシを通さないようにする。
Acquire::HTTP::Proxy "http://apt-cacher.lan"; Acquire::HTTPS::Proxy "DIRECT";
キャッシュする必要がない理由として、 再利用をしないことが多いことが挙げられる。
複数台のインストール時に apt udpate で 何度も参照される debian / ubuntu の公式レポジトリはキャッシュしておけば楽になる。
それとは違い、HTTPSするようなレポジトリはシステム固有でインストールしたソフトが多いので、キャッシュしておく必要性が乏しいことが多い。
個人的には node source をキャッシュしてるが、gitlab.com や docker.io 自体をキャッシュする必要を感じない。
過去の関連記事
apt-cacherで docker buildを速くする - それマグで！
更新履歴
- 2025-10-01 キャッシュ利用の確認について
- 2025-10-01 キャッシュ削除について
- 2025-10-01 管理画面ついて
- 2025-10-09 HTTPs に付いて。
