🐞 버그 설명
상황
OPENVIDU
가 로컬에서는 되지만 다른 클라이언트에서는 되지 않는 오류가 발생했다.
자신의 캠은 연결이 되지만, 정작 다른 클라이언트와는 통신이 되지 않는 문제였다.
버그 해결
팀원분이 관련하여 찾아보였고 결국 도커 이미지가 잘못되었다는 것을 확인하였다.
우리가 사용한 OPENVIDU
도커 이미지는 openvidu/openvidu-dev:2.29.0
였다.
하지만, 해당 이미지는 적혀있는데로 dev
를 위한 버전이였어서 실제 배포시에는 동작이 되지 않았다.
그래서, 실제 배포시 OPENVIDU
를 사용하기 위한 방법을 찾아보았고, 직접 설치를 진행해야 된다는 사실을 깨닫게 되었다.
OPENVIDU
를 설치하는 방법은 다음 명령어를 사용하면 되었다.
curl <https://s3-eu-west-1.amazonaws.com/aws.openvidu.io/install_openvidu_2.29.0.sh> | bash
참고한 블로그
https://whitedevelper.tistory.com/85
위의 블로그를 참고하여 진행했지만, 해당 블로그에는 OPENVIDU
를 설치하기 위해선
- NGINX 완전 삭제
- 전체 도커 컨테이너 작동중지
- 방화벽 활성화/비활성화
- SSL 인증서 새롭게 발급
위 작업이 동반되어야 한다고 설명이 되어있었다.
하지만, 현재 우리 서버에서 NGINX를 완전 삭제하는 것은 너무 잘 연계되어 있는 것들이 많아 불가능했으며,
서비스중인 전체 도커 컨테이너를 중지하는 것도 불가능했다.
또한, GCP에서 지원하는 VPC 네트워크의 방화벽을 이용했기에 ufw
명령어를 사용하여 직접 방화벽을 조절하는 것도 애매했다.
그래서, 해당 블로그를 참고만 하여 커스텀을 진행했다.
우선 OPENVIDU
를 GCE에 설치하여 ./openvidu start
를 하게되면 서버가 열리게 된다.
이때, 기본적인 디렉토리들이 생기게 된다.(certificates 등)
그 후, nano .env
명령어를 사용하여 환경변수와 관련된 설정을 해주어야 한다.
.env 설정
하지만, 블로그처럼 위와 같이 설정했을 때 오류가 발생했다.
오류 로그는 SSL 인증서가 존재하지 않거나 충돌된다는 오류였다.
OPENVIDU
설치시 docker-compose.yml
도 같이 생기게 되는데
여기서 OPENVIDU
용도의 NGINX가 따로 실행이 되며 기존의 SSL 인증서가 인식이 되지 않는 오류가 발생하는 것 같았다.
하지만, 앞서 말했던 것처럼 SSL 인증서를 새롭게 발급하는건 다른 문제를 발생할 수도 있을 것이라는 생각이 들었다.
그렇기에 OPENVIDU
의 NGINX에 직접 도커 볼륨 마운트를 하여 기존 서버에서 사용하던 /etc/letsencrypt
인증서를 연결하려 하였다. 그러나, docker-compose.yml
파일을 다시 살펴보았는데 놀랍게도 이미 볼륨 마운트 설정이 되어있었다.OPENVIDU
첫 실행시 생성되었던 certificates 디렉토리로 마운트가 되어있었다.
그렇다면, 기존 서버의 `/etc/letsencrypt' 경로에 있던 모든 파일을 certificates에 복사하면 정상 구동이 되지 않을까라는 생각이 들었다.
따라서, 모든 파일을 복사해주었고 예상대로 정상 구동은 되었다.
하지만, 아직 다른 클라이언트와의 연결이 안되는 문제는 해결되지 않은 상태가 지속되었다.
물론, .env
설정대로 8443
, 8081
등의 포트도 열어주었다.
하지만, 클라이언트 쪽에서는 세선 졉속을 계속 시도하다가 결국 끊어지는 현상이 반복되었다.
해당 문제와 관련해서 내용을 찾아보니 Stun
서버가 필요하다는 글을 보았는데,
우리는 이미 Stun
서버가 잘 구동되고 있었다.
그래서, 혹시나 하는 마음에 Stun
서버의 컨테이너 로그를 확인해보았고,
해당 로그에서 반복적으로 3478
포트 오류가 발생하는 것을 확인했다.
따라서, 3478
포트에 대해 TCP, UDP 방화벽을 열어주었고 정상적으로 클라이언트간의 통신이 됨을 확인하였다.
🙋🏻 More
OPENVIDU
라는 오픈소스를 만들어낸 쪽에서 NGINX 완전 초기화, 모든 컨테이너 종료를 시켜야만OPENVIDU
를 실행하게 설정했다는 것은 너무 불친절한 것 같다는 생각이 들어
해당 블로그를 의심한 것이 오류 해결의 씨앗이 된 것 같습니다.
블로그를 포스팅하는 쪽, 포스팅한 블로그를 참고하는 쪽 개발자로서 모두 배워나가는 과정이므로,
블로그에 적혀있는 내용을 무조건적으로 믿는 것은 좋지 않겠다는 것을 다시 깨달았습니다.
이 글을 보는 다른 분들도 블로그 참조하실 때 주의하시면 좋을 것 같습니다! :)
'프로젝트 > FitTrip' 카테고리의 다른 글
[커뮤니티 서비스] 커뮤니티 서비스 기능정리 (0) | 2024.06.29 |
---|---|
[트러블슈팅] 각 서비스의 로그 확인을 위한 로깅 시스템 구축 (0) | 2024.06.26 |
[트러블슈팅] SSE 적용시 게이트웨이와 유저 서비스 연동간 발생 오류 해결 (0) | 2024.06.25 |
[트러블슈팅] 무중단 배포간 Docker Compose 오류 해결 (2) | 2024.06.25 |
[트러블슈팅] JPA의 deleteAll() 대신 IN을 사용한 성능 최적화 (0) | 2024.06.25 |