업그레이드 과정에서 몇 가지 문제가 발생했습니다. 첫 번째 포럼은 대시보드를 통한 첫 번째 시도에서 실패했고, 다시 빌드(rebuild)를 시도해도 실패했지만 두 번째 빌드 시도에서는 작동하는 것 같았습니다. 다만 그 후에도 한 번 더 빌드해야 했습니다. 이를 계기로 PG12 업데이트로 업그레이드를 수행할 때 모든 Discourse 인스턴스를 중지해야 한다는 사실을 기억해냈습니다(이 서버에는 개별 컨테이너를 가진 세 개의 Discourse 포럼이 있습니다). 그 결과 나머지 두 포럼에는 다음 방법이 잘 작동했습니다:
그러나 어떤 이유에서인지 첫 번째 포럼은 더 이상 접근할 수 없으며, Safari에서는 서버가 의도치 않게 연결을 끊었다고 표시합니다. 빌드를 수행하면 정상적으로 진행되는 것 같지만, 포럼에는 접근할 수 없으며, 앱과 Rails 콘솔에는 진입할 수 있고 데이터베이스도 온전한 상태인 것으로 보입니다.
빌드 시 관련이 있을 수 있는 경고 메시지 중 확인된 것은 다음과 같습니다:
168:M 31 Jan 2021 21:39:22.459 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
168:M 31 Jan 2021 21:39:22.459 # Server initialized
168:M 31 Jan 2021 21:39:22.459 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
168:M 31 Jan 2021 21:39:22.459 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo madvise > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled (set to 'madvise' or 'never').
168:M 31 Jan 2021 21:39:22.459 * Loading RDB produced by version 6.0.9
168:M 31 Jan 2021 21:39:22.459 * RDB age 21 seconds
168:M 31 Jan 2021 21:39:22.459 * RDB memory usage when created 4.03 Mb
168:M 31 Jan 2021 21:39:22.466 * DB loaded from disk: 0.006 seconds
168:M 31 Jan 2021 21:39:22.466 * Ready to accept connections
production.log:
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.5/lib/redis/client.rb:367:in `rescue in establish_connection'
unicorn.stderr.log와 unicorn.stdout.log에도 유사한 메시지가 나타납니다.
컨테이너에 진입하여 redis-cli ping을 실행하면 PONG이 반환됩니다. Redis는 서버에서 실행 중입니다(개별 컨테이너에서는 실행되지 않지만, AFAIK로 알고 있기로는 항상 그랬습니다).
무엇이 문제일 수 있는지 아이디어가 있을까요?
(안전장치를 위해 서버를 재부팅하고 이 도메인에 대한 새로운 Let’s Encrypt 인증서를 생성했지만, 여전히 동일한 상태입니다.)
디스크 사용량은 31%로 표시되었지만, 그래도 ./launcher cleanup을 실행했습니다:
docker container ls
(세 개의 포럼 컨테이너가 모두 실행 중인지 확인)
./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
...
Total reclaimed space: 32.56GB
HAProxy를 사용 중이며, 이를 확인하고(재시작도 했습니다) 정상적으로 실행 중입니다. 또한 http에서 https로의 리다이렉트도 HAProxy를 통해 처리하고 있으며 도메인에서도 정상적으로 작동하므로, HAProxy에 문제가 있다고 생각하지 않습니다. 게다가 이번 업데이트 전까지는 정상적으로 작동했었거든요.
컨테이너에 여전히 접근할 수 있고, Rails 콘솔에도 접속할 수 있으며, DB도 컨테이너에 연결되어 여전히 존재합니다. 따라서 상황이 매우 이상합니다. 다른 아이디어나 문제 해결을 위한 단계가 있으신 분은 조언 부탁드립니다.
문제가 무엇인지 디버깅할 수 없다면, 명령줄에서 백업을 수행한 후 PG13으로 실행되는 새로운 사이트로 복원하는 것이 하나의 대안이 될 수 있습니다. 또는 사이트를 다시 가동해야 한다면, 버전을 PG12로 되돌리고 기존 shared/postgres_data_old 디렉토리를 shared/postgres_data로 다시 이동한 후 재구축하면 됩니다. 그러나 이 문제는 데이터베이스 업그레이드 자체와 관련이 없는 것으로 보이므로, 백업/복원 방식을 시도하는 것을 권장합니다.
이 문제를 조사하기 위한 다른 아이디어가 있다면 마이클, 기꺼이 시도해 보겠습니다. 다행히 이 포럼이 읽기 전용 모드였기 때문에(다른 포럼으로 대체되었기 때문에) 오프라인인 것이 큰 문제가 아닙니다.
아이디어가 더 이상 없다면 백업 복원을 시도해 보겠지만, 가능하면 이것이 왜 발생했는지 배우고 싶으므로 문제 해결을 하고 싶습니다(당신도 그럴 것이라고 추측합니다). 따라서 당신이 동의하신다면 이 문제를 더 깊이 조사하는 것에 동의합니다.
솔직히 말해서, 이것은 제 다른 포럼 중 일부를 Discourse로 전환하는 것에 대해 조금 불안하게 만들었습니다. 무엇이 잘못되었는지 아는 것이 우리 모두에게 유용할 것입니다.
이것은 표준 멀티 컨테이너 설치이며, 각 포럼은 자체 app.yml과 host: discourse/shared-site-name/standalone 및 host: discourse/shared-site-name/standalone/log/var-log 기반 컨테이너 설정을 가지고 있습니다(이 포럼에서 제가 질문한 것과 게시글에 따라).
각 컨테이너에 진입하여 psql(sudo -u postgres psql discourse)와 \l+를 실행하면 컨테이너당 하나의 discourse 데이터베이스만 표시되며(각각 크기가 다름), 따라서 저는 이것이 독립적인 Discourse 인스턴스라고 추측합니다.
서버에서 여러 독립적인 Discourse 포럼을 실행하는 ‘표준’ 방법에 대한 링크가 있으신가요? 제 환경이 그것과 동일한지 확인할 수 있지만, 제가 가진 설정이 Discourse 팀의 게시글과 가이드라인에 기반하고 있다는 데 꽤 확신이 있습니다.
/var/log/nginx와 /shared/log/rails를 살펴봤지만 특별히 눈에 띄는 내용은 없었습니다. 사실 오늘(4일)에는 /shared/log/rails/production.log를 제외하고 로그가 업데이트된 것이 없었습니다. 해당 로그에는 다음과 같은 작업(Jobs) 몇 가지만 기록되어 있습니다:
# docker logs f2
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 42
ok: run: redis: (pid 55) 0s
ok: run: postgres: (pid 54) 0s
chgrp: invalid group: ‘syslog’
supervisor pid: 51 unicorn pid: 82
(51) Reopening logs
(51) Reopening logs
(51) Reopening logs
(51) Stopping Sidekiq
(51) Reloading unicorn (82)
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid... 22039
(51) Old pid is: 82 New pid is: 22039
(51) Stopping Sidekiq
(51) Reloading unicorn (22039)
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid... 23358
(51) Old pid is: 22039 New pid is: 23358
(51) Reopening logs
(51) Reopening logs
로그를 확인하고 이전 답변들을 다시 읽어보니, 애플리케이션은 컨테이너 내부의 localhost:6379에서 redis에 접근을 시도하고 있으며, redis도 정상적으로 시작되는 것으로 보이지만, 어떤 이유에서인지 연결할 수 없습니다(의아하게). 다만, message_bus가 redis 시작 전에 연결을 시도하거나, 재시작 시 redis가 종료된 후에 발생한 에러 메시지일 수도 있습니다.
redis는 서버에서 실행 중이지만 개별 컨테이너에서는 실행되지 않는다고 언급하셨는데, 이 부분을 좀 더 자세히 설명해 주실 수 있을까요?
이 구성을 사용하면 Redis는 컨테이너 내부에서 실행됩니다(docker logs 출력에서 확인할 수 있음).
그 외 참고로, 작동하지 않는 사이트의 URL로 이동했을 때 nginx 로그에 무엇이 표시됩니까? error.log는 비어 있어야 하고, access.log에는 다양한 HTTP 요청이 기록되어 있어야 합니다. 어디에서 문제가 발생하고 있는지 좁혀 내려는 중입니다.
혼동해서 말씀드린 것 같습니다. 실제로 Redis는 각 컨테이너에서 정상적으로 작동하고 있으며, 서버 자체에서 그리고 세 개의 Discourse 컨테이너 각각에서 다음 명령을 실행하여 동일한 출력을 확인했습니다:
$ redis-cli ping
PONG
$ redis-server
# Creating Server TCP listening socket *:6379: bind: Address already in use (이미 시작되어 있음을 의미)
$ redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get mykey
(nil)
127.0.0.1:6379> set mykey somevalue
OK
127.0.0.1:6379> get mykey
"somevalue"
세 컨테이너 모두 동일한 결과를 보이며(참고: 첫 번째 get mykey는 항상 nil을 반환합니다), 따라서 Redis가 모든 컨테이너에서 독립적으로 실행되고 있다고 볼 수 있습니다.
해당 디렉토리에 오늘 기록된 내용이 없으며 파일이 비어 있습니다:
drwxr-xr-x 2 www-data www-data 4096 Feb 4 21:26 .
drwxrwxr-x 9 root root 4096 Feb 2 08:03 ..
-rw-r--r-- 1 www-data www-data 0 Feb 3 07:38 access.log
-rw-r--r-- 1 www-data www-data 0 Feb 2 08:03 access.log.1
-rw-r--r-- 1 www-data www-data 294 Feb 1 09:43 access.log.2.gz
-rw-r--r-- 1 www-data www-data 37598 Jan 30 23:56 access.log.3.gz
-rw-r--r-- 1 www-data www-data 58059 Jan 30 07:36 access.log.4.gz
-rw-r--r-- 1 www-data www-data 55988 Jan 29 07:34 access.log.5.gz
-rw-r--r-- 1 www-data www-data 73964 Jan 28 07:49 access.log.6.gz
-rw-r--r-- 1 www-data www-data 78069 Jan 27 07:53 access.log.7.gz
-rw-r--r-- 1 www-data www-data 0 Feb 3 07:38 error.log
-rw-r--r-- 1 www-data www-data 0 Feb 2 08:03 error.log.1
-rw-r--r-- 1 www-data www-data 20 Feb 1 00:31 error.log.2.gz
-rw-r--r-- 1 www-data www-data 632 Jan 30 23:46 error.log.3.gz
-rw-r--r-- 1 www-data www-data 265 Jan 29 09:07 error.log.4.gz
-rw-r--r-- 1 www-data www-data 20 Jan 28 07:50 error.log.5.gz
-rw-r--r-- 1 www-data www-data 3107 Jan 28 07:41 error.log.6.gz
-rw-r--r-- 1 www-data www-data 20 Jan 26 07:53 error.log.7.gz
다른 컨테이너의 액세스 로그를 확인해 보니 정상적이므로, 문제는 이 컨테이너 하나에서만 발생하는 것으로 보입니다.
HAProxy가 요청을 전달하고는 있지만 컨테이너가 이를 처리하거나 수락하지 못하는 것 같습니다. 해당 부분에서 리셋할 수 있는 것이 있는지 궁금합니다. (컨테이너를 다시 빌드하면 당연히 이런 작업이 수행될 것이라고 생각했지만요?)
IMAGE COMMAND CREATED STATUS PORTS
local_discourse/1 "/sbin/boot" 20 hours ago Up 20 hours 0.0.0.0:2225->22/tcp, 0.0.0.0:8892->80/tcp
local_discourse/2 "/sbin/boot" 4 days ago Up 4 days 0.0.0.0:2223->22/tcp, 0.0.0.0:8889->80/tcp
local_discourse/3 "/sbin/boot" 4 days ago Up 4 days 0.0.0.0:2224->22/tcp, 0.0.0.0:8890->80/tcp
직감적으로 대시보드를 통한 실패한 시도가 원인인 것 같습니다. 보통 PG/메이저 업데이트 시에는 대시보드에서 리빌드가 필요하다고 표시되고 대시보드를 통한 업데이트가 비활성화되지만, 어떤 이유에서인지 이번에는 그렇게 표시되지 않았습니다(아마도 해당 포럼을 꽤 오랫동안 업데이트하지 않아서 대시보드를 통해 먼저 업데이트해야 한다고 생각했기 때문일 수도 있습니다). 또는 리빌드 전에 제대로 종료되거나 시작되지 않았을 가능성도 있습니다
이 문제와는 관련이 없다고 확신합니다. 이전에는 잘 작동했거든요. 그 업그레이드/재빌드 이후에 이런 일이 발생했습니다.