ほんの数日前、サーバーの XNUMX つで Docker ストレージ (Docker がすべてのコンテナーとイメージ ファイルを保存するディレクトリ) を別のセクションに移動することが決定されました。
より大きな容量がありました。 その仕事は些細なことのように見え、トラブルの予兆はありませんでした...
始めましょう：
1. アプリケーションのすべてのコンテナを停止して強制終了します。
docker-compose downコンテナが多数あり、それらの構成が異なる場合は、次のようにすることができます。
docker rm -f $(docker ps -q)2. Docker デーモンを停止します。
systemctl stop docker3. ディレクトリを目的の場所に移動します。
cp -r /var/lib/docker /docker/data/storage4. docker デーモンに新しいディレクトリを参照するように指示します。 いくつかのオプションがあります。 -g フラグを使用してデーモンに新しいパスを指定するか、systemd configs を使用します。 またはシンボリックリンク。 これについては、インターネット上にあるので詳しくは説明しません。 docker root を新しい場所に移動するためのマニュアル。
5. Docker デーモンを起動し、それが正しい場所にあることを確認します。
systemctl status docker出力行の XNUMX つには次のように表示されます。
├─19493 /usr/bin/dockerd --data-root=/docker/data/storageオプションがデーモンに渡されたことを確認しました。次に、それが適用されたかどうかを確認してみましょう (ありがとう) )!
docker info | awk '/Root Dir/ {print $NF}' 6. アプリケーションを開始しましょう。
docker-compose up -d7. 確認
ここからが楽しみの始まりです。DBMS、MQ、すべて問題ありません。 データベースは無傷で、nginx を除いてすべてが動作します。 私たちは、Kerberos と花魁を使用した独自の nginx ビルドを持っています。 また、コンテナーのログを確認すると、/var/tmp に書き込めない - アクセス許可が拒否されたことが示されました。 指でこめかみをこねて状況を分析しようとします...どうやってこれが可能ですか？ Docker イメージは変更されませんでした。 ディレクトリを移動したところです。 それはいつもうまくいきました、そしてここにそれがあります...実験のために、私は手でコンテナに入り、このディレクトリへの権限を変更しました。 ルート、ルート 755、与えた ルート、ルート 777。 そしてすべてが始まりました...ある考えが私の頭の中で響き始めました-ある種のナンセンス...私は思いました、まあ、おそらく何かを考慮に入れていなかったのでしょう...
私は、転送中のファイルへのアクセス権に惚れ込んだと判断しました。 アプリケーション、docker デーモンを停止し、新しいディレクトリを削除し、次を使用して /var/lib/docker ディレクトリをコピーしました。 rsync -a.
これですべてがうまくいったと思います。Docker アプリケーションを起動しましょう。
ああ、そして...問題はまだ残っていた...私の目はピクピクと動きました。 私は仮想マシンのコンソールに急いで行き、そこでさまざまなテストを実行しました。この nginx イメージがあり、コンテナー内に入りました。ここでは、/var/tmp ディレクトリに対する権限は root、root 777 です。手動で設定しなければならなかったのと同じです。 でも画像は全く同じです！
xfs ファイル システムはあらゆる場所で使用されていました。
コマンドを使って比較してみました
docker inspect my-nginx:12345すべてのハッシュは同一であり、すべて XNUMX 対 XNUMX です。 サーバーと仮想マシンの両方で。 ローカルの nginx イメージを削除し、レジストリから再度プルしました。さまざまな理由から、このイメージは同じマシン上にあります。 そして問題は同じです...今、私の第二の目がピクピクしています。
「ああああああ」と叫んだこと以外、頭の中でどんなことを考えていたのかもう思い出せません。 午前 4 時、Docker ソース コードを使用してイメージ レイヤーのハッシュの原理を理解しました。 エナジードリンクのXNUMX缶目を開けました。 そして最終的に、ハッシュ化ではファイルとその内容のみが考慮されることに気づきましたが、 アクセス権ではありません！ つまり、何らかの不可解な方法で私たちの権利が失われ、selinux が無効になり、acl が使用されなくなり、スティッキー ビットがなくなりました。
ローカルイメージを削除し、dockerレジストリからもイメージを削除して、再度プッシュしました。 そしてすべてがうまくいきました。 転送中に、ローカル イメージ内とレジストリにあるイメージ内の両方の権利が失われたことが判明しました。 すでに述べたように、さまざまな理由から、それは同じ車両に設置されていました。 その結果、XNUMX つのディレクトリ /var/lib/docker に作成されます。
そして、港湾労働者の視線を古いディレクトリに戻そうとしたのかという疑問を予想しながら、いいえ、試みませんでした。残念ながら、状況がそれを許しませんでした。 はい、本当にそれを理解したかったのです。
この記事を書いた後、私には問題の解決策が明らかであるように思えますが、分析時点ではそうではないようでした。 正直に言って、グーグルで調べても同様の状況は見つかりませんでした。
結果: 問題は解決しましたが、理由はまだわかりません =(
誰かがこの問題の考えられる原因について知っている、推測している、というビジョンを持っていたのであれば、コメントで知らせていただけると非常にうれしいです。
出所： habr.com