Discourse 인스턴스에서 핵심 유지보수 작업을 수행할 때 다운타임을 최소화하거나 없애는 방법에 대한 모범 사례에 대해 논의하고 싶습니다.
UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL과 같은 중요한 리소스 설정을 변경하거나 주요 업데이트를 적용하는 작업은 일반적으로 launcher rebuild app을 필요로 하며, 이는 상당한 시간, 때로는 30분 이상을 소요될 수 있습니다.
제 질문은 다음과 같습니다: 시스템 관리자가 이러한 필수 업데이트와 설정 변경을 사용자 체감 다운타임이 최소가 되도록 수행하기 위한 권장 전략은 무엇입니까?
블루/그린 배포나 기타 제로 다운타임 배포 전략과 같은 고급 기법이 Discourse에서 지원되거나 권장됩니까? 아니면 표준 rebuild 프로세스가 유일한 지원되는 방법이며, 재빌드 시간 자체를 최적화하는 데 초점을 맞춰야 하는 것입니까?
대규모 또는 트래픽이 많은 인스턴스를 관리해 본 경험이 있는 분들의 워크플로우에 대해 듣고 싶습니다.
If you have a two container install, the new container builds while the old one runs. Downtime is just the amount of time it takes to launch the new container. The only issue is that you need enough ram to build a container while the other runs.
If you want zero down time then you need a load balancer that keeps the old container running until the new one has fully started. Then you shut down the old container and do the post update migrations.
Discourse is so stable this is pretty unnecessary for most installs (but I guess you might consider it for very high availability requirements or if you are hosting others?!)
I don’t think I’ve had a single outage in 7 years due to a production “glitch” …
The riskiest moments in a Discourse’s life is always at rebuild.
the two container setup gives you the ability to bootstrap a new build before committing to it though that won’t catch some runtime errors of course.
The issue is that if your migrations have run, you might need to commit to the new build and so you would usually try to track down and fix the source of those errors rather than roll back.