素晴らしいです。いや、それで完璧です。改めてありがとうございます!大変感謝しています。
コマンドは ./discourse-setup --two-container になりました。
まさに今、期待通りに動作しました ![]()
よく見つけましたね!その点を簡単に特定できるようなメッセージは表示されましたか?
彼らが変更してから、このトピックを整理しようと思っていたんです。
はい、とても役立ちました。ありがとうございます。
古い「コンテナリンク」という仕組みから、2 つのコンテナを接続するカスタムネットワークによる適切な設定への移行計画はありますか?
「リンク」はレガシーであり、Docker ドキュメントによると、将来削除される可能性があります。
それは良いアイデアですね。
誰かが先にやらない限り、サブユニットとしてネットワークやソケット(どちらか、あるいは両方を使うことを好む人もいます)への切り替えのためのプルリクエストを作成し、既存のセットアップを新しい構成に変換する方法をまとめたハウツーを作成する予定です。
@pfaffman それが済んだかどうか分かりませんが、もし済んだのであれば、ここにリンクしていただけますか? ![]()
これらのコマンドの最後に && ./launcher cleanup を追加すべきでしょうか?
2コンテナインストールに切り替えた後、古いイメージで利用可能なストレージがいっぱいになるのに時間がかからないことに気づきました。
私のガイドでもそのことを強く推奨しています… DOのドロップレットのような比較的小さなシステムにデプロイする人が多く、スペースがどこに使われているのかを十分に理解していない人もいることを知っています。
@pfaffman、こんにちは。
数日前にAWS EC2に単一コンテナをインストールし、すべて正常に動作しました。しかし、WebのみをEC2に、データをAWS RDS(ポート5432のPostgreSQL 15.3 = >別のバージョンを選択できません。データベースにDB_NAMEパラメータがありません)に設定する、まさに2コンテナ構成が必要です。RedisクラスターとしてAWS ElastiCacheを使用しようとしましたが、既存のテンプレートへのリンクをdata.ymlに残しました。
#- "templates/postgres.template.yml"
- "templates/redis.template.yml"
dataとweb_onlyのブートストラップに成功した後、Webページを開くことができません。「このサイトにアクセスできません」
DNSレコードの変更やAWSセキュリティグループ(Webおよびデータベースのファイアウォール)のアクセス設定の変更は行っていません。
ブートストラップに成功しました。起動するには ./launcher start data を使用してください
root@ip-172-31-3-68:/var/discourse# ./launcher start data
x86_64 arch detected.
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -h ip-172-31-3-68-data -e DOCKER_HOST_IP=172.17.0.1 --name data -t -v /var/discourse/shared/data:/shared -v /var/discourse/shared/data/log/var-log:/var/log --mac-address <...> local_discourse/data /sbin/boot
27b66e577d250e4178f5e145c9962be7b5f2d905cfacd233d3d2278e7b83aa93
ブートストラップに成功しました。起動するには ./launcher start web_only を使用してください
root@ip-172-31-3-68:/var/discourse# ./launcher start web_only
x86_64 arch detected.
+ /usr/bin/docker run --shm-size=512m --link data:data -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET= -e DISCOURSE_DB_HOST=database-discourse.<...>.rds.amazonaws.com -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=talk.furtherium.com -e DISCOURSE_DEVELOPER_EMAILS=hello@furtherium.com -e DISCOURSE_SMTP_ADDRESS=email-smtp.us-east-2.amazonaws.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=A<...>S -e DISCOURSE_SMTP_PASSWORD=B<...>M -e DISCOURSE_NOTIFICATION_EMAIL=noreply@talk.furtherium.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -e DISCOURSE_DB_NAME= -e DISCOURSE_DB_USERNAME=postgres -e DISCOURSE_DB_PASSWORD=7<...>1 -e DISCOURSE_REDIS_HOST=data -h ip-172-31-3-68-web-only -e DOCKER_HOST_IP=172.17.0.1 --name web_only -t -p 80:80 -p 443:443 -v /var/discourse/shared/web-only:/shared -v /var/discourse/shared/web-only/log/var-log:/var/log --mac-address <...> local_discourse/web_only /sbin/boot
1233f1c660eb7cecc48d2a840aae037b46ecfd7afe029ef89b2e686b136b9886
- SSHからデータベースへの接続をtelnetで確認しました - OK
- AWS RDSダッシュボードでデータベース接続を確認できます
- インスタンスを3回再起動しました
- エラーなしで3〜4回再構築を実行しました
- アクティブなコンテナとイメージのリストを確認し、不要なものをクリーンアップしました
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1233f1c660eb local_discourse/web_only "/sbin/boot" 18 minutes ago Up 18 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp web_only
27b66e577d25 local_discourse/data "/sbin/boot" 47 minutes ago Up 47 minutes data
他に何をすればよいでしょうか?ご尽力とご時間ありがとうございます!
必要ありません。Webコンテナのみが必要で、PostgresとRedisのテンプレートを削除する必要があります。Elasticacheは、私見では非常に高価なので、単一ホストを使用している場合はEC2で実行できます。
既存のapp.ymlに環境変数を追加し、不要なテンプレートを削除するだけです。最近、このサイトはPG15で稼働していると聞きましたので、問題ないはずです。
Jay(@pfaffman)様、返信ありがとうございます。確認したいことがあります。
- シングルコンテナの
app.ymlインストールを使用し、データベースとRedisに関する行をコメントアウトすべきでしょうか?また、app.ymlのENVフィールドで、AWSのデータベース(DB_USERなど - 現在のweb_onlyから)の行を追加すべきでしょうか? - それとも、現状のままにして、データコンテナを停止し、web-onlyのみを残すべきでしょうか?
- ElastiCacheを使用しない場合、「templates/redis.template.yml」の行を残す必要がありますか?
標準から2コンテナに変更するのは、ほぼスムーズに進みました。ymlファイルにスペースがいくつか不足していたため、ローカリゼーションの問題だと確信させられましたが(全く違います)、それはユーザーエラーでした。そのため、かなりの時間を無駄にしました。
しかし、フォーラムを起動したところ、完全に新規のフォーラムになっていました。S3に最新のバックアップがあったため、これは簡単に修正できましたが、そもそもなぜ発生したのか疑問に思っています。何か推測はありますか?
つまり、完全に新しい2コンテナセットアップをインストールしてからバックアップから復元するという方法をとれば、時間を節約できたかもしれません。あるいは、プラグインの追加、メール設定の修正、maxmindなどの編集は still 必要になるため、そうではないかもしれません。
[上記の投稿とは関係ありません]
2つのコンテナを使用する利点は何ですか?通常の単一コンテナではだめなのですか?
フォーラムのアップグレード/プラグインのインストール時のダウンタイムを避けるためだと思います。
私にとっては、すでに短いダウンタイムが言及されています。それに、私は頻繁にアップグレードします。少なくとも週に一度はアップグレードするので、私のセットアップはバグに遭遇しやすいです。それほど頻繁ではありませんが、時々発生します。
原因がプラグインである場合、それほど頻繁ではありませんが、ほとんどの場合、何らかのコンポーネントが原因です。問題のあるものを特定するには、3〜4回試す必要があります。そして、各試行が約30分かかると、たとえそれが小さく趣味ベースのフォーラムであっても、ダウンタイムが長すぎることになります。
そして3番目の理由は、私がそれをできるからです。
再構築が失敗してサイトがダウンした場合、非常にストレスを感じます。基本的に、それを解決または回避策を見つけるために、私の即時(そして時には長時間の)注意が必要になります。まったく楽しくありません!!!
2つのコンテナインストールは、これを単なる不便に変換し、根本的な問題は通常、都合の良い時に処理できます。また、問題を引き起こした原因は、その段階で既に解決されていることがよくあります。
stableを使用している場合、おそらく気にする必要はないでしょう。しかし、tests-passedを使用してエッジに近い状態にいる場合、再構築/更新中の回復力は非常に貴重です。
ああ、わかりました。説明ありがとうございます!
投稿したことすら忘れていました!
Nice tuto. It takes me 5 minutes, with a new server, create and restore the backup then `./discourse-setup --two-container’.
Thank you
素晴らしいチュートリアルです。新しいサーバーでバックアップを作成・復元し、./discourse-setup --two-container を実行するのに5分かかりました。
ありがとうございます。
既存のサーバーを正常なデータベースに移行する場合、この手順が必要な理由を誰か説明してもらえますか?
移行直前に安全なオフサイトバックアップを作成することは良い習慣であることは理解していますが、なぜダウンロードが必要なのでしょうか?