사용자:Hsl0/SSoT

현재 아키텍쳐와 문제점[편집 | 원본 편집]

지금은 미디어위키 컨테이너를 수정하지 않고 확장기능, 스킨, 설정 등 수정할 부분만 볼륨으로 빼놔서 해당 부분을 수정해왔습니다. 기존에 하나의 서버만 운용할 때는 이 방식이 간단했지만, 여러 서버를 운용하게 된 지금은 이 아키텍쳐가 비효율적이고 문제가 많습니다.

여러 서버 간의 설정을 일괄적으로 변경하려면 각 서버에 접속해서 설정 파일을 일일이 수정해야 합니다.
파일이 따로 관리되기 때문에 서버 간 세팅이 달라질 수 있습니다.
설정 변경, 확장기능 설치 등의 작업을 프로덕션 환경에서 바로 진행하므로 위험성이 큽니다.
테스트를 위해 서버 환경을 복제하기 어렵습니다. SSH를 통해 volume의 모든 파일을 복사 붙여넣어야 합니다.
문제가 발생하면 되돌려야 하는데, 버전을 관리하지 않기 때문에 수정한 부분을 일일이 찾아서 수동으로 되돌려야 합니다. 수동으로 되돌리는 것은 불완전할 수 있습니다.
주석을 달지 않는 이상 수정사항이 기록되지 않기 때문에 누군가 서버를 수정해서 문제가 발생했을 때 다른 사람은 서버가 수정되었다는 사실을 인지하는 것 부터 쉽지 않습니다.
확장기능, 스킨을 설치/업데이트 할 때 일일이 압축 파일을 다운받고 풀어야 합니다.
서버가 백업되지 않았기 때문에 사고 발생시 복구가 어렵습니다.

같은 사이트를 위한 서버는 동일하게 유지되어야 합니다. 여러 서버에서 동일한 환경을 조성하려면 이미지로 배포하는 것이 바람직합니다. 저는 다음과 같은 방식을 제안합니다:

그렇게 한다면 다음과 같은 장점이 있습니다.

모든 서버에 같은 이미지를 편리하고 안전하게 배포할 수 있습니다.
문제가 생길 때 롤백이 용이합니다.
로컬 및 개발 서버에서 완전히 동일한 환경으로 테스트해서 안정성을 더 높일 수 있습니다.
약간 불안정한 기능은 브랜치로 빼내서 빠르게 적용할 기능과 천천히 테스트할 기능을 나눠서 개발 서버와 메인 서버에 배포할 버전을 나눌 수도 있습니다.
서버가 유실되는 사고가 발생했을 때 컨테이너 이미지는 git 및 레지스트리에 저장되므로 빠르게 복구할 수 있습니다.
git 서브모듈을 사용해 확장기능 및 스킨 업데이트가 간편해집니다. 모든 확장기능이나 스킨을 업데이트 할 때 단 한줄의 명령어만 치고 커밋하면 끝납니다.
컨테이너 관리를 단순화시킨다면 Kubernetes같은 도구를 도입하기도 쉬워집니다.