Excellent. Nope that will be perfect. Thanks again! Very much appreciated.
「いいね！」 1
The command is now ./discourse-setup --two-container
worked as expected just now 
「いいね！」 2
Good catch! Did it print a message that made it easy to figure that out?
I’ve been meaning to clean up this topic since they change.
「いいね！」 1
Yes, very helpful thanks.
「いいね！」 2
Are there any plans to migrate from the old “container links” thing to proper setup with a custom network with two containers being connected to it?
“Links” are legacy and may be removed in the future according to Docker docs
「いいね！」 1
That sounds like a good idea.
Unless someone beats me to it, I’ll see about subunits /creating a PR to switch to networks and /or sockets (which some prefer anyway) and creating a howto to convert an existing setup to the new configuration.
「いいね！」 5
@pfaffman それが済んだかどうか分かりませんが、もし済んだのであれば、ここにリンクしていただけますか？ 
「いいね！」 3
これらのコマンドの最後に && ./launcher cleanup を追加すべきでしょうか？
2コンテナインストールに切り替えた後、古いイメージで利用可能なストレージがいっぱいになるのに時間がかからないことに気づきました。
「いいね！」 1
私のガイドでもそのことを強く推奨しています… DOのドロップレットのような比較的小さなシステムにデプロイする人が多く、スペースがどこに使われているのかを十分に理解していない人もいることを知っています。
「いいね！」 2
@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 必要になるため、そうではないかもしれません。
「いいね！」 1
[上記の投稿とは関係ありません]
2つのコンテナを使用する利点は何ですか？通常の単一コンテナではだめなのですか？
フォーラムのアップグレード/プラグインのインストール時のダウンタイムを避けるためだと思います。
「いいね！」 2
私にとっては、すでに短いダウンタイムが言及されています。それに、私は頻繁にアップグレードします。少なくとも週に一度はアップグレードするので、私のセットアップはバグに遭遇しやすいです。それほど頻繁ではありませんが、時々発生します。
原因がプラグインである場合、それほど頻繁ではありませんが、ほとんどの場合、何らかのコンポーネントが原因です。問題のあるものを特定するには、3〜4回試す必要があります。そして、各試行が約30分かかると、たとえそれが小さく趣味ベースのフォーラムであっても、ダウンタイムが長すぎることになります。
そして3番目の理由は、私がそれをできるからです。
「いいね！」 2
再構築が失敗してサイトがダウンした場合、非常にストレスを感じます。基本的に、それを解決または回避策を見つけるために、私の即時（そして時には長時間の）注意が必要になります。まったく楽しくありません!!!
2つのコンテナインストールは、これを単なる不便に変換し、根本的な問題は通常、都合の良い時に処理できます。また、問題を引き起こした原因は、その段階で既に解決されていることがよくあります。
stableを使用している場合、おそらく気にする必要はないでしょう。しかし、tests-passedを使用してエッジに近い状態にいる場合、再構築/更新中の回復力は非常に貴重です。
「いいね！」 2
ああ、わかりました。説明ありがとうございます！
投稿したことすら忘れていました！
「いいね！」 1
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分かかりました。
ありがとうございます。
「いいね！」 2
既存のサーバーを正常なデータベースに移行する場合、この手順が必要な理由を誰か説明してもらえますか？
移行直前に安全なオフサイトバックアップを作成することは良い習慣であることは理解していますが、なぜダウンロードが必要なのでしょうか？
「いいね！」 2