緊急バックアップ - コンテナコマンドラインへの直接接続

インストール
1

役立つかもしれないことを学びました。

背景: 他の場所で詳述されているように、私のDiscourseインストールは、アップグレードを完了するにはディスクが小さすぎたVPSでホストされていました。最初に管理コントロールパネルで「アップグレード」をクリックしました。アップグレードは失敗し、GUIは二度と機能しなくなりました。その後、VPSのコンソールにログインし、有名な./launcher rebuild appコマンドを実行しました。それも完了しませんでした。ディスクストレージが決定的に不足していました。より多くのスペースを確保し、予算を抑えるために、私はセットアップ全体を別のホスティング会社の新しいVPSに移動することにしました。貴重なサイトデータを保存することが最優先事項でした。

失敗: バックアップを作成するための最も明白な2つの方法は機能しませんでした。

  • 最初のアップグレードの試みは、WebベースのGUIを壊したため、管理コントロールパネルにアクセスしてそこからバックアップを開始する方法がありませんでした。
  • Dockerコンテナに入り、シェルコマンドを実行しようとしても機能しませんでした。これに対する推奨コマンドは/var/discourse/launcher enter appです。しかし、少なくとも私の場合は、launcherスクリプトはコンテナに入らせる前にアプリを再構築しようとし、再構築は一貫して失敗していたため、このコマンドはコンテナにさえ入らせてくれず、ましてやその中のシェルにさえ到達できませんでした。

成功: 諦めようとしていたとき、嬉しい驚きがありました。小さなVMのコマンドラインで作業していて、docker psを実行したところ、appという名前のアクティブなコンテナがあることがわかりました。そして、Dockerには実行中のコンテナに直接入る方法があります。コマンドはdocker exec -it app bashです。

コンテナ内では、進捗することができました。discourse backupコマンドを実行し、数分待ってから、<backup>.tar.gzファイルを安全な新しい場所にコピーしました。最新のバックアップがあれば、セットアップの新しいホームへの移行を完了することができました。（これを行う方法については、これらのフォーラムに他のスレッドがあります。）

ここでの重要な点は、コンテナに入るための上記のdockerコマンドが、Discourse固有の./launcherコマンドが機能しなかった場合でも機能したということです。

この優れた製品の発明者と維持管理者に感謝します。

「いいね！」 3
2

試しましたか

./launcher cleanup

または、いくつかのバックアップを削除しましたか？

「いいね！」 1
3

お尋ねいただきありがとうございます。

元のセットアップを機能させようとしていた数日間、ディスク容量を確保するために考えられる限りのことを行ったと思っていました。もちろん ./launcher cleanup も含みますが、それ以上に、古いカーネルの削除、apt キャッシュのクリア、不要なソフトウェアの削除なども行いました。

サイト全体を移行することを決意し、そのプロセスにかなりの時間を費やした後、もっと何かできたのではないかと考えましたが、その時にはさらに調査する意欲を失っていました。（cf. 「サンクコスト効果」）。具体的には、私がまさに放棄しようとしていた VPS のディスク容量は名目上 25G でした。そのうち約 19G は /var/lib/docker/overlay2 ディレクトリに割り当てられていました。そして、私が実行していた Docker コンテナは、Discourse とその関連の Mail-receiver だけでした。経験上、Discourse は強力ですが、ディスク上で 19G 未満で動作するはずです。しかし、インターネット検索では overlay2 ディレクトリ内部を変更することは安全ではないという情報が多く、その時点で私は立ち往生していると感じました。

新しくセットアップした環境では、/var/lib/docker/overlay2 ディレクトリは 13G を占めています。それでもまだ巨大です。

ホビー用の小規模ウェブサイトでフォーラムを運営するために Discourse を選択したのは、「ただ動くだろう」という希望、つまり、多くの新しいことを学ぶことなく非常に簡単に管理できるだろうという期待からです。これは、十分な（過剰な？）リソースを割り当てることができるのであれば、ほとんど正しいようです。

私の新しい計画は、overlay2 ディレクトリが時間とともに成長して、新しい VPS の 50G ディスクを水浸しにしないことを盲目的に願うことです。もしあなたが（または他の誰かが）Docker と Discourse のダイナミックデュオのサイズを管理下に置く方法を知っていれば、ぜひ教えていただきたいです。それは、ここ数日間で行った他の学習の集大成となるでしょう。改めて感謝します。

4

自分で解決できたようで何よりです。私は20Gストレージと25Gストレージの2つの小さなフォーラムを運営しています。それらを機能させ続けるために、かなりの時間と創意工夫を費やす必要があります。しかし、私はいつも同じような戦術を使用し（そしてそれについて投稿し）ているようです。以下を参照してください。

Discourse開発は、最小コストのハードウェアで実行すること以外の最適化を行っています。しかし、私の制約のある環境では、なんとか機能し続けています。それが長く続くことを願っています。

小容量ストレージ環境で作業する鍵は、何が起こっているかを測定することです。人々が何が起こっているかを推測しているのをあまりにも多く見かけます。私のやり方は常に以下から始まります。

さらに詳しい情報については、私の投稿でpruneとjournalctl、そしてkernelを検索してみてください。

「いいね！」 2