インストール問題のトラブルシューティング
docker-containerd-shim や docker-runc が検出されない場合
エラーの説明: 実行ファイルが検出されない
Diamond v1.4.3 および Diamond v1.5.3 では、インストール環境で使用される Docker のバージョンは v18.09.2 です。Mercury のテスト環境では、いくつかの理由から Docker バージョンが v18.09.7 にアップグレードされています。バージョンのアップグレードにより、特定のアプリケーションパスや実行パスが変更されます。k8s でポッドが稼働したり、Docker を使用してコンテナを直接起動すると、エラーが表示されます。
docker: Error response from daemon: failed to start shim: exec: "docker: Error response from daemon: failed to start shim: exec: "docker-containerd-shim": executable file not found in $PATH: unknown.
": executable file not found in $PATH: unknown.もしくは
docker: Error response from daemon: OCI runtime create failed: unable to retrieve OCI runtime error (open /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/b123c36ddea60f7bf562946b7ffb9520023fcb4946b3e7f9941a564a46bad28c/log.json: no such file or directory): exec: "docker-runc": executable file not found in $PATH: unknown.問題の原因
原因はまだ特定されていません。 Docker のバージョンが 18.09.2 から 18.09.7 にアップグレードされたため、一部の実行ファイルが再計画されています。
問題の解決方法
アップグレードが実行されていない環境で、/usr/bin/ ディレクトリを探し、docker-containerd-shim と docker-runc ファイルを問題のマシンの /usr/bin/ディレクトリにコピーします。
この問題の発生を防ぐには、Ubuntu / CentOSマシンで APT 自動アップグレードサービスを無効にします。スクリプトを実行して、このサービスを停止します。以下のスクリプトは、環境デプロイメントスクリプトに組み込まれています。Diamond のデプロイメントパブリックキーを設定する際、このキーをデプロイメントマニュアル内に見つけることができます。
# Disable apt package auto upgrade service
sudo systemctl stop apt-daily.service apt-daily.timer apt-daily-upgrade.timer apt-daily-upgrade.service
sudo systemctl disable apt-daily.service apt-daily.timer apt-daily-upgrade.timer apt-daily-upgrade.serviceupstreamDNS を設定すると k8s インストールのタイムアウトが発生する場合
タイムアウトの説明
Diamond のインストール中に発生
ディスク構造のクリーンアップを要する場合
問題の説明
デプロイメントで init_data_fs_vdb のディスクパーティションの初期化を実行中、Error mounting /mnt/locals/xxx/volume0: mount: mount /dev/vdbx on /mnt/locals/xxx/volumevolume0 failed: Structure needs cleaning というエラーが発生する場合があります。
問題分析
原因は不明です。この問題は毎回発生するわけではありません。同じデプロイメントスクリプトを使用して、初回実行時にエラーが発生する場合もあれば、繰り返し実行した場合にのみエラーが発生する場合もあります。
問題の修正手順
この問題が発生した場合は、fsck ツールを使用して修正します。たとえば、前述した /dev/vdb5 のエラーが発生した場合、関連ノードにログインして sudo fsck.ext4 /dev/vdb5 -y コマンドを実行すると、問題を修正できます。エラーの修正後、再度デプロイメントを実行します。
engine-alert-feature-db サービスの初期化でタイムアウトが発生する場合
remove-services.sh の実行中に PV の削除がフリーズする場合
問題の説明
インストールパッケージには、すべてのデプロイメントサービスを削除する remove-services.sh スクリプトが用意されています。これにより、デプロイメント全体をテストしてから、もう一度インストールをやり直すことができます。しかし、remove-services.sh スクリプトを実行すると、pv の削除時にスクリプトがフリーズします。一定時間待機すると、問題は解決します。
問題分析
原因は不明です。Kubernetes でも同様の問題が発生する場合がありますが、実際の原因は分かっていません (https://github.com/kubernetes/kubernetes/issues/69697)。ただし、この問題を解決するための対応策はあります。
問題の修正手順
別のコンソールを開き、以下のコマンドを実行します。pv のステータスが Terminating になっていることを確認します。これは、pv が削除を完了できないことを示し、削除スクリプトの処理に影響します。
上記例の場合、 以下のように kubectl edit pv local-pv-12bd5454 の pv を編集します。pv の中にある finalizers フィールドを探し、値を null に変更します。保存して終了すると、問題が解決します。元のコンソールのスクリプトは、継続して実行されます。
変更後
(テスト環境にのみ適用) デプロイされたすべてのサービスリソースの削除
デプロイメントのテスト中にデプロイメントのテストを最初からやり直すためには、デプロイされたすべてのリソースを完全に削除してデプロイメント前の状態に戻す必要があるがあります。プロジェクトのインストールパッケージには、これに対応したリソース削除スクリプトが用意されています。このスクリプトでは、互換性の多くが考慮されていません。既存のデプロイメント Ansible をインストールし、実行内容を戻すステップにすぎません。Ansible のデプロイメントコンテンツに変更があった場合、削除スクリプトのコンテンツを同時に変更する必要があります。
mercury/bin/remove-services.sh: すべてのコンポーネント、ライセンスサービス、ローカルボリューム、pv、pvc およびエンジン層とインフラ層のラベルの削除に使用
mercury/bin/remove-volumes.sh: データディスクのデータとパーティション情報の削除に使用
すべてのサービスの削除が必要な場合は、インストールパッケージのディレクトリで以下のコマンドを実行します。ホスト部分は該当する IP で置き換える必要があります。
最終更新
役に立ちましたか?