はじめに
ホームサーバーや業務で Ubuntu を使っていると、apt update / apt install は日常的に実行するコマンドです。 ところがある日、Canonical / Ubuntu の公式リポジトリ（archive.ubuntu.com / security.ubuntu.com）側が不調になり、手元の環境で apt update が通らなくなりました。 結果として Docker コンテナのビルドや CI パイプラインまで失敗し、しばらく作業が止まってしまいました。
今回は、このときの現象・切り分け方法・ミラーサイトを使った回避策・セキュリティ上の注意点をまとめます。 同じ状況に遭遇したときにスムーズに復旧できるようにするのが目的です。
何が起こったか
新環境のセットアップをしていた際、最初に sudo apt update を実行したところ、いつまで待ってもリポジトリのインデックスが取得できない状態になりました。 apt install 同様にインストールできない状態になってしまい、OS の更新も依存パッケージの追加もできない状態になりました。
この時点ではローカルの DNS やネットワークの不調にも見えるため、上流側の障害なのかどうかの切り分けが重要になります。
影響範囲
apt update / apt install が使えない
OS パッチの適用や依存パッケージの追加が止まります。新規の環境のセットアップなど apt update を通さないと何も始まらない構成では作業が完全に停止します。
Docker ビルドが失敗する
Dockerfile でよく見かける以下のパターンも、上流の外部リポジトリに依存しています。
RUN apt-get update && apt-get install -y curl ca-certificates git上流が不調になるとこの行でビルドが落ちます。GitHub Actions や GitLab CI などでコンテナを都度ビルドする構成だと、同時多発的にパイプラインが失敗することになります。
切り分け方法：公式ステータスページを確認する
今回の決め手は公式ステータスページを確認することでした。
このページでは archive.ubuntu.com / security.ubuntu.com など主要コンポーネントの稼働状況が公開されています。 ここを見て「自分の環境の問題ではなく上流が不調」と分かるだけで、切り分けにかかる時間を大幅に短縮できます。
注意：外部のステータス集約サイトもありますが、ユーザー報告ベースで揺れがあるため、一次情報としてはまず公式を確認するのが確実です。
対処法：ミラーサイトへ切り替える
上流の復旧を待つのがベターですが、開発や CI を止められない場合はミラーサイトへ切り替えることで回避できます。
1. ミラーの候補を探す
Ubuntu には公式・準公式のミラーが存在します。日本国内であれば Ubuntu Japanese Team のページに具体的な URL がまとまっているため、ここから選ぶのが手っ取り早いです。
2. 参照先を変更する
最近の Ubuntu（24.04 以降）では、従来の /etc/apt/sources.list ではなく /etc/apt/sources.list.d/ubuntu.sources での管理が主流になっています。
変更の内容としては、URIs: の http://archive.ubuntu.com/ubuntu/ を国内ミラーの URL に差し替えます。
# 変更前
URIs: http://archive.ubuntu.com/ubuntu/
# 変更後（例：筑波大学ミラー）
URIs: http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu/また、復旧後はスムーズに戻せるようにコメントアウトで変更前の行を残しておくと便利です。
3. security.ubuntu.com の扱い
セキュリティリポジトリ（security.ubuntu.com）については、むやみに全部ミラーへ置換するのは避けたいところです。 ミラーへの同期には遅延が発生する場合があり、セキュリティパッチの適用が遅れるリスクがあります。
現実的な運用としては以下のような使い分けになります。
| 状況 | 対応 |
|---|---|
| 通常時 | security.ubuntu.com はそのまま使用する |
| 障害時 | 必要に応じて一時的にミラーへ逃がす（復旧後に戻す） |
ミラー利用時のセキュリティ上の注意点
ミラーを使う際に「改ざんされないのか」と不安になりますが、APT には署名検証の仕組みがあります。
APT の署名検証（apt-secure）
APT はパッケージの真正性を暗号学的署名で検証します。この検証は配布経路（HTTP / ミラー）とは独立しているため、ミラー経由であっても改ざんされたパッケージは検出されます。
そのため「ミラー＝危険」ではなく、APT の署名検証が最後の砦として機能します。
信頼できるリポジトリだけを設定する
署名検証がある一方で、「どのリポジトリを信頼するか」は利用者が判断する必要があります。 Ubuntu の公式ドキュメントでも「信頼できるリポジトリのみ設定すべき」と明記されています。
ミラーを選ぶ際の指針は以下のとおりです。
- 公式に登録されているミラーを優先する（Ubuntu Japanese Team の一覧など）
- 運用実績が不明なミラーは避ける
- 可能であれば HTTPS 対応のミラーを選ぶ
検証の無効化は避ける
障害時に焦って Acquire::AllowInsecureRepositories や allow-insecure=yes などの設定を入れたくなりますが、これは基本的に避けるべきです。 apt-secure の manpage でも、未署名・不正な署名のリポジトリを許可する設定は非推奨とされています。
復旧後にこの設定が残っていると事故要因になるため、どうしても必要な場合でも一時的な措置に留めてください。
Docker / CI 側でできる再発防止策
上流障害の影響を小さくするために、Docker や CI の構成側では以下のような対策が考えられます。
リトライを入れる
apt に限らずネットワークに依存する処理にはリトライを入れておくと、突発的な障害の影響を減らせます。
RUN for i in 1 2 3; do apt-get update && break || sleep 5; done \
&& apt-get install -y curl ca-certificates gitベースイメージに依存を寄せる
毎回 Dockerfile 内で大量に apt-get install するのではなく、よく使う依存をまとめたベースイメージを用意しておくことで、上流障害の影響範囲を減らせます。
キャッシュを活用する
Docker レイヤキャッシュを効かせたり、依存パッケージを内部でプロキシ（apt-cacher-ng など）しておくことで、上流障害の影響を受けにくくすることができます。
まとめ
apt update などの上流障害は、OS 更新だけでなく Docker ビルドや CI まで波及するため、影響範囲が広くなります。 切り分けには Canonical and Ubuntu Status を確認するのが最短ルートです。 回避策としてはミラーサイトへの一時的な切り替えが現実的で、ミラーを使う際も APT の署名検証が安全性を担保してくれます。 信頼できるミラーのみを選ぶことと、検証の無効化を避けることを守っておけば安心です。参考になれば幸いです。
コメント