Kubernetes에 Mattermost 배포

Mattermost 서버는 다양한 Kubernetes 플랫폼에 배포할 수 있으며, 팀 커뮤니케이션에 필요한 확장 가능하고 견고한 인프라를 제공합니다. 이 가이드는 주요 클라우드 공급자와 일반 Kubernetes 설치 환경의 배포 옵션을 다룹니다.

플랫폼

구체적인 배포 방법은 아래에서 원하는 플랫폼을 선택해 확인하세요.

Mattermost Operator

Mattermost Kubernetes Operator를 사용하면 S3 호환 스토리지와 관리형 데이터베이스 서비스를 사용해 Kubernetes에 Mattermost를 배포할 수 있습니다. Operator는 다양한 구성을 지원하지만, 프로덕션 환경에서는 클라우드 네이티브 방식을 강력히 권장합니다.

사전 요구 사항

시작하기 전에 다음을 준비하세요.

• 동작 중인 Kubernetes 클러스터(Kubernetes 설정 가이드 참고). 클러스터는 지원되는 Kubernetes 버전으로 실행되어야 합니다.
• 로컬 머신에 설치된 kubectl 명령줄 도구(kubectl 설치 가이드 참고).
• 디플로이먼트, 파드, 매니페스트 적용 등 Kubernetes 개념에 대한 기본적인 이해.
• 예상 사용자 부하에 따라 충분히 할당된 Kubernetes 리소스. 규모별 리소스 요구 사항은 엔터프라이즈 확장 문서를 참고하세요.

설치 단계

설치 과정은 필요한 Operator를 설정한 뒤 Mattermost 자체를 배포하는 순서로 진행됩니다.

1단계: NGINX Ingress Controller 설치

Kubernetes 배포 문서의 안내에 따라 Kubernetes 클러스터에 NGINX ingress controller를 설치합니다. Mattermost는 설치 대상 플랫폼과 관계없이 helm을 통한 Nginx Operator 설치를 권장합니다.

2단계: Mattermost Operator 설치

Mattermost Kubernetes Operator는 Helm으로 설치할 수 있습니다.

1. Helm(3.13.0 이상)을 설치합니다. 설치 방법은 Helm 빠른 시작 문서를 참고하세요.

2. Mattermost Helm 저장소를 추가합니다.

   helm repo add mattermost https://helm.mattermost.com

3. config.yaml이라는 파일을 만들고 Mattermost operator values 파일의 내용을 채워 넣습니다. 이 파일로 Operator를 맞춤 구성할 수 있습니다.

4. Mattermost Operator용 네임스페이스를 만듭니다.

   kubectl create ns mattermost-operator

5. Mattermost Operator를 설치합니다. 버전을 지정하지 않으면 최신 버전의 Mattermost Operator가 설치됩니다. 최신 버전의 Mattermost Operator 사용을 권장합니다.

   helm install <your-release-name> mattermost/mattermost-operator -n <namespace_name>

   예를 들면 다음과 같습니다.

   helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator

   맞춤 config.yaml 파일을 사용하려면 다음과 같이 실행합니다.

   helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator -f config.yaml

3단계: Mattermost 배포

1. (Mattermost Enterprise 전용) Mattermost 라이선스 시크릿을 만듭니다. mattermost-license-secret.yaml이라는 파일을 만들고 다음 내용을 넣되, [LICENSE_FILE_CONTENTS]를 실제 라이선스로 교체합니다.

   apiVersion: v1
   kind: Secret
   metadata:
     name: my-mattermost-license
   type: Opaque
   stringData:
     license: <LICENSE_FILE_CONTENTS>

2. mattermost-installation.yaml이라는 Mattermost 설치 매니페스트 파일을 만듭니다. 이 가이드의 파일 이름은 제안일 뿐이며 다른 이름을 사용해도 됩니다. 다음 템플릿을 사용하고 값을 필요에 맞게 조정하세요.

   apiVersion: installation.mattermost.com/v1beta1
   kind: Mattermost
   metadata:
     name: <INSTALLATION_NAME_HERE>        # Example: mm-example-full
   spec:
     size: <SIZE_VALUE_HERE>               # Example: 5000users
     ingress:
       enabled: true
       host: <FULL_DOMAIN_NAME_HERE>       # Example: example.mattermost-example.com
       annotations:
         kubernetes.io/ingress.class: nginx
   version: <VERSION_HERE>               # Example: 9.3.0
   licenseSecret: ""                     # If you created a license secret, put the name here

   매니페스트의 주요 필드는 다음과 같습니다.

   • metadata.name: Kubernetes에서 사용할 Mattermost 배포의 이름입니다.
   • spec.size: 설치 규모입니다(예: "100users", "1000users" 등).
   • spec.ingress.host: Mattermost 설치의 DNS 이름입니다.
   • spec.version: Mattermost 버전입니다. 사용 가능한 버전은 버전 아카이브를 참고하세요. 최신 버전의 Mattermost Operator와 함께 지원되는 버전의 Mattermost를 사용해야 합니다.
   • spec.licenseSecret: 라이선스가 담긴 Kubernetes 시크릿의 이름입니다(Enterprise에 필요).

   구성 가능한 필드 전체 목록은 예시 매니페스트와 Custom Resource Definition을 참고하세요.

3. 데이터베이스 자격 증명을 담을 mattermost-database-secret.yaml 파일을 만듭니다. 이 시크릿은 Mattermost 설치와 동일한 네임스페이스에 있어야 합니다.

   apiVersion: v1
   data:
     DB_CONNECTION_CHECK_URL: <DB_CONNECTION_CHECK_URL>
     DB_CONNECTION_STRING: <DB_CONNECTION_STRING>
     MM_SQLSETTINGS_DATASOURCEREPLICAS: <MM_SQLSETTINGS_DATASOURCEREPLICAS>
   kind: Secret
   metadata:
     name: my-postgres-connection
   type: Opaque

   PostgreSQL을 사용하는 AWS Aurora 예시입니다.

   apiVersion: v1
   data:
     DB_CONNECTION_CHECK_URL: cG9zdGdyZXM6Ly91c2VyOnN1cGVyX3NlY3JldF9wYXNzd29yZEBteS1kYXRhYmFzZS5jbHVzdGVyLWFiY2QudXMtZWFzdC0xLnJkcy5hbWF6b25hd3MuY29tOjU0MzIvbWF0dGVybW9zdD9jb25uZWN0X3RpbWVvdXQ9MTA=
     DB_CONNECTION_STRING: cG9zdGdyZXM6Ly91c2VyOnN1cGVyX3NlY3JldF9wYXNzd29yZEBteS1kYXRhYmFzZS5jbHVzdGVyLWFiY2QudXMtZWFzdC0xLnJkcy5hbWF6b25hd3MuY29tOjU0MzIvbWF0dGVybW9zdD9jb25uZWN0X3RpbWVvdXQ9MTA=
     MM_SQLSETTINGS_DATASOURCEREPLICAS: cG9zdGdyZXM6Ly91c2VyOnN1cGVyX3NlY3JldF9wYXNzd29yZEBteS1kYXRhYmFzZS5jbHVzdGVyLXJvLWFiY2QudXMtZWFzdC0xLnJkcy5hbWF6b25hd3MuY29tOjU0MzIvbWF0dGVybW9zdD9jb25uZWN0X3RpbWVvdXQ9MTA=
   kind: Secret
   metadata:
     name: my-postgres-connection
   type: Opaque

   참고

   DB_CONNECTION_CHECK_URL 값은 Operator의 레거시 postgres:13 + pg_isready 준비성 init 컨테이너(spec.database.readinessCheck의 기본값인 external 모드)가 사용합니다. 새로 배포하는 경우에는 spec.database.readinessCheck.mode: builtin 설정을 권장합니다(아래 5단계 참고). 이 경우 준비성 init 컨테이너가 이미지에 내장된 mattermost db ping 명령을 실행하므로 DB_CONNECTION_CHECK_URL 필드가 더 이상 필요하지 않습니다. 레거시 external 모드는 하위 호환성을 위해 여전히 기본값이지만, 향후 Operator 릴리스에서 지원 중단될 예정입니다.

4단계: 파일 저장소 시크릿 생성

객체 스토리지 서비스(예: AWS S3 또는 S3 호환 서비스)의 자격 증명을 저장할 mattermost-filestore-secret.yaml 파일을 만듭니다. 이 시크릿은 Mattermost를 설치할 네임스페이스와 동일한 네임스페이스에 만들어야 합니다. 파일에는 다음 YAML 구조가 들어가야 합니다.

apiVersion: v1
kind: Secret
metadata:
  name: <secret-name>  # Choose a descriptive name (e.g., my-s3-credentials)
type: Opaque
data:
  accesskey: <base64-encoded-access-key>
  secretkey: <base64-encoded-secret-key>

apiVersion: v1
kind: Secret
metadata:
  name: my-s3-credentials
type: Opaque
data:
  accesskey: QUNDRVNTX0tFWQo=  # Example: Replace with your actual encoded key
  secretkey: U1VQRVJfU0VDUkVUX0tFWQo=  # Example: Replace with your actual encoded key

5단계: Mattermost 설치 매니페스트 구성

1. 2단계에서 만든 mattermost-installation.yaml 파일을 수정해 Mattermost를 외부 데이터베이스 및 객체 스토리지에 연결합니다. YAML 구조의 어디에 이 구성을 추가해야 하는지는 지원되는 필드 목록을 참고하세요.

2. 데이터베이스에 연결합니다.

   1. 매니페스트의 spec 섹션에 다음을 추가합니다.

      spec:
        database:
          external:
            secret: <database-secret-name>  # The name of the database secret (e.g., my-postgres-connection)

   2. (권장) 데이터베이스 준비성 init 컨테이너가 레거시 postgres:13 + pg_isready 흐름 대신 이미지에 내장된 mattermost db ping 명령을 사용하도록 구성합니다. 이렇게 하면 별도의 postgres:13 이미지를 받아올 필요가 없고(이미지를 미러링할 수 없는 에어갭 클러스터에서 특히 중요합니다), 준비성 검사가 실행 중인 Mattermost 릴리스와 항상 동기화됩니다.

      spec:
        database:
          external:
            secret: <database-secret-name>
          readinessCheck:
            mode: builtin
            timeout: 5m   # optional; default is 5m

      builtin 모드를 사용하려면 mattermost db ping 명령이 포함된 Mattermost 릴리스가 필요합니다(가용 여부는 Mattermost 서버 풀 리퀘스트 참고).

      readinessCheck를 생략하거나 mode: external로 설정하면 레거시 postgres:13 + pg_isready 동작이 유지됩니다. 레거시 모드는 하위 호환성을 위한 현재 기본값이며 향후 Operator 릴리스에서 지원 중단될 예정입니다. readinessCheck 필드의 전체 스키마는 Mattermost CRD 레퍼런스를 참고하세요.

3. 객체 스토리지에 연결합니다.

   1. 매니페스트의 spec 섹션에 다음을 추가합니다.

      spec:
        fileStore:
          external:
            url: <storage-service-url>  # The URL of your storage service (e.g., s3.amazonaws.com)
            bucket: <bucket-name>      # The name of your storage bucket
            secret: <filestore-secret-name> # The name of the filestore secret (e.g., my-s3-credentials)

4. Amazon S3를 사용한다면 서버 측 암호화(SSE)와 SSL을 활성화하는 것을 권장합니다. mattermostEnv 섹션에 다음 환경 변수를 추가하세요.

   spec:
     mattermostEnv:
       MM_FILESETTINGS_AMAZONS3SSL: true
       MM_FILESETTINGS_AMAZONS3SSE: true

Mattermost 리소스 상태 확인

Operator로 Mattermost 설치를 만든 뒤에는 다음 명령으로 상태를 확인할 수 있습니다.

kubectl -n [namespace] get mattermost

kubectl describe 명령으로 Mattermost 서버 파드에 대한 더 자세한 정보를 얻을 수 있습니다.

kubectl -n [namespace] describe pod

로그 확인

다음 명령으로 모든 Kubernetes 파드의 로그를 따라갈 수 있습니다.

kubectl -n [namespace] logs -f [pod name]

-n [namespace]를 생략하면 현재 컨텍스트의 기본 네임스페이스가 사용됩니다. 배포에 맞춰 네임스페이스를 명시하는 것을 권장합니다.

이 명령은 필요에 따라 Mattermost Operator 또는 Mattermost 서버 로그를 확인하는 데 사용할 수 있습니다.

자주 묻는 질문

Operator는 Mattermost 서버와 어떤 버전 호환성을 갖나요?

일반적으로 Operator는 대부분의 Mattermost 서버 버전, 또는 모든 버전과 호환되지만, 항상 최신 버전의 Operator를 지원되는 버전의 Mattermost 서버와 함께 사용하는 것을 권장합니다.

Azure

지원되는 Azure Marketplace 컨테이너 오퍼를 사용하면 기존 Azure 인프라에 Mattermost를 설치할 수 있습니다.

시작하기 전에

배포하기 전에 다음을 준비했는지 확인하세요.

• AKS 클러스터: Application Gateway Ingress Controller(AGIC) 애드온이 활성화되어 있거나 다른 Ingress controller가 배포되어 있어야 합니다.

• PostgreSQL v13.0 이상 데이터베이스: Private Access를 사용하는 Azure Database for PostgreSQL - Flexible Server를 권장합니다. Microsoft 빠른 시작 가이드에 따라 배포하세요.

• 프라이빗 네트워크 연결: AKS 클러스터와 PostgreSQL 데이터베이스 사이에 네트워크 연결이 있는지 확인하세요.

• 유효한 DNS 이름과 TLS 인증서: DNS 영역에 접근할 수 있어야 하며, Ingress Controller에 유효한 TLS 키와 인증서를 제공해야 합니다.

• 노드 용량: 100명 이상 규모로 배포할 때 고가용성을 확보하려면 최소 2개의 AKS 노드가 필요합니다.

• 라이선스 키: 고가용성 및 기타 Enterprise 기능을 테스트하려면 체험판 또는 Enterprise 라이선스가 필요합니다.

설치 단계

설치 과정은 Mattermost 배포와 서버 업데이트로 구성됩니다.

1단계: Mattermost 배포

1. Azure Marketplace 컨테이너 오퍼에서 Mattermost를 배포하고 Get it now를 선택합니다.

   또는 AKS 클러스터의 Extensions + Applications 섹션으로 이동해 거기서 Mattermost 오퍼링을 설치할 수도 있습니다. 자세한 내용은 Microsoft 클러스터 확장 문서를 참고하세요.

2. 설치된 AKS와 PostgreSQL 데이터베이스의 Resource Group과 Region을 선택합니다.

   

3. AKS 클러스터를 선택합니다.

   

4. PostgreSQL 데이터베이스 세부 정보를 입력합니다. 지정한 사용자에게 전체 접근 권한이 있는지 확인하세요.

   

5. 배포 이름과 배포 규모를 포함한 배포 세부 정보를 지정합니다. Mattermost 인스턴스용 파일 스토리지를 구성해야 합니다. S3 호환 스토리지 서비스 또는 NFS 호환 서버 사용을 권장합니다.

   

6. Mattermost 설치 호스트 이름과 Ingress 세부 정보를 구성합니다. 다음 예시에서는 필요한 ingress 어노테이션을 보여 주기 위해 AGIC 애드온을 사용합니다.

   Kubernetes Ingress와 TLS 종료를 지원한다면 클러스터에 미리 설치된 어떤 Ingress Controller도 사용할 수 있습니다.

   kubernetes.io/ingress.class: azure/application-gateway
   appgw.ingress.kubernetes.io/ssl-redirect: "true"

7. 추가로 다음 사항을 고려하는 것을 권장합니다.

   1. 최소 TLS 버전 적용(예: TLS 1.2).
   2. ingress controller가 지원한다면 추가 보호를 위해 웹 애플리케이션 방화벽(WAF) 배포.
   3. Kubernetes 네트워크 정책을 사용한 접근 제한.

   

8. 모든 것이 정상 실행 중인지 확인합니다. Settings 메뉴 아래 AKS Extensions + Applications 페이지에서 설치된 플러그인을 확인할 수 있습니다.

   배포가 완료되면 다음 명령으로 Mattermost 배포의 호스트 이름 또는 IP 주소를 확인합니다.

   kubectl -n mattermost-operator get ingress

9. ADDRESS 열의 IP 주소를 사용해 도메인 등록 서비스에서 DNS 레코드를 만듭니다.

10. DNS 레코드에서 정한 URL로 동작 중인 Mattermost 설치에 접속합니다.

Mattermost 서버 관리에 대해 더 알아보려면 Administration Guide 문서를 참고하세요.

2단계: AKS 클러스터를 통한 Mattermost 업그레이드

1. Mattermost 설치가 배포된 AKS 클러스터의 Extensions + Applications 섹션으로 이동합니다.

2. 마이너 버전 자동 업그레이드는 Mattermost 버전을 변경하지 않으므로 활성화해도 됩니다.

3. Configuration Settings 표를 펼쳐 아래 구성과 설치하려는 버전을 값으로 추가합니다.

   global.azure.mattermost.version

   

4. Save를 선택하고 업그레이드가 완료될 때까지 기다립니다.

Azure Local에서의 주권형 배포를 찾고 있나요?

데이터 주권이 필요한 온프레미스 배포를 요구하는 조직에는 Azure Local(이전 명칭 Azure Stack HCI)이 하이브리드 클라우드 플랫폼을 제공합니다. 이를 통해 Microsoft Teams 및 M365와의 연동을 유지하면서 Mattermost를 온프레미스에서 실행할 수 있습니다.

Azure Local 배포에서는 최적의 구성과 보안 요구 사항 준수를 위해 Mattermost Professional Services와 협업하는 것을 권장합니다. Azure Local 배포 요구 사항을 논의하려면 전문가와 상담하기를 이용하세요.

Oracle

지원되는 Oracle Cloud Marketplace 리스팅인 Mattermost - OCI-Native (Kubernetes-based)를 사용하면 Oracle Cloud Infrastructure(OCI)에 고가용성 Mattermost 환경을 배포할 수 있습니다. 하나의 가이드형 스택이 새 Oracle Kubernetes Engine(OKE) 클러스터, 관리형 OCI Database with PostgreSQL 시스템, 파일 첨부용 Object Storage 버킷, Mattermost Kubernetes Operator, 그리고 OCI Native Ingress Controller를 통한 HTTPS ingress를 프로비저닝합니다.

시작하기 전에

배포하기 전에 다음을 준비했는지 확인하세요.

• 리소스를 만들 권한이 있는 Oracle Cloud 테넌시와 컴파트먼트(VCN, OKE, IAM 정책, OCI Database with PostgreSQL, Object Storage, Resource Manager)
• 새 OKE 클러스터와 기본 워커 풀(노드 3개, 각각 VM.Standard.E5.Flex 2 OCPU/16GB), 그리고 OCI Database with PostgreSQL 시스템을 위한 충분한 서비스 한도
• Mattermost 로드 밸런서를 가리키는 DNS A 레코드를 만들 수 있는 등록된 도메인 이름
• OCI Certificate Service에 가져온 해당 도메인용 TLS 인증서와 배포 전에 준비된 OCID. 스택은 원시 PEM/개인 키를 허용하지 않고 인증서 OCID만 받습니다.
• 100명이 넘는 사용자 규모로 배포할 계획이라면 Mattermost Enterprise 라이선스. 더 큰 규모에서는 Mattermost와 PostgreSQL이 고가용성 모드로 실행되며 라이선스가 필요합니다.

설치 단계

설치 과정은 Mattermost 배포와 필요한 구성 요소 설정으로 이루어집니다.

1단계: Oracle Cloud Marketplace에서 시작

Mattermost - OCI-Native (Kubernetes-based) 리스팅으로 이동해 Launch Stack을 선택합니다.

2단계: 스택 정보

Create stack 페이지에서 정보를 확인한 뒤 스택 이름, 설명, 컴파트먼트, Terraform 버전을 설정합니다.

3단계: 변수 구성

Mattermost 배포에 필요한 모든 세부 정보를 설정합니다. 변수는 영역별로 묶여 있으며, 고급 그룹은 Show advanced options 토글 뒤에 숨겨져 있어 기본 흐름은 단순하게 유지됩니다.

General Configuration

• Compartment:

  • 스택이 만드는 모든 리소스(OKE 클러스터, VCN, PostgreSQL DB 시스템, Object Storage 버킷)의 대상 컴파트먼트입니다.

• Cluster Name Prefix:

  • 스택이 만드는 모든 OCI 리소스의 접두사로 사용됩니다(기본값: mattermost).

• Show Recovery Options:

  • 일반 배포에서는 끈 상태로 둡니다. 이전 apply가 실패해 재적용을 막는 리소스가 남은 경우에만 활성화하세요. 활성화하면 새 리소스 이름을 강제하는 Deploy ID Revision 필드가 나타납니다.

Mattermost Installation

• Mattermost Installation Name:

  • 이 설치의 이름입니다(기본값: mattermost-prod).

• Mattermost Installation Size:

  • 예상 활성 사용자 수에 맞는 규모를 선택합니다: 100users, 1000users, 5000users, 10000users, 25000users(기본값: 100users). 이 값이 Mattermost 파드 리소스와 PostgreSQL 토폴로지(인스턴스 수, 셰이프)를 함께 결정합니다. 생성 시에만 설정할 수 있는 값으로, OCI가 PostgreSQL 토폴로지를 제자리에서 변경할 수 없기 때문에 나중에 바꾸려면 새 스택을 배포해야 합니다. 100 사용자를 넘는 규모는 Mattermost와 PostgreSQL을 고가용성 모드로 배포하며 Enterprise 라이선스가 필요합니다.

• Mattermost Version:

  • 설치할 Mattermost 서버 버전입니다.

• Mattermost License Key:

  • Enterprise 라이선스 파일을 업로드합니다. 100users에서는 선택 사항이며, 비워 두면 라이선스 없이 시작한 뒤 System Console > Edition and License에서 나중에 라이선스를 추가할 수 있습니다. 그보다 큰 모든 규모에서는 필수입니다.

• Mattermost FQDN:

  • 최종 사용자가 접속할 호스트 이름입니다(예: mattermost.domain.com). 배포 후 이 호스트 이름의 DNS A 레코드를 스택의 출력 로드 밸런서 IP로 지정합니다.

• OCI Certificate Service OCID:

  • 해당 FQDN용으로 OCI Certificate Service에 가져온 인증서의 OCID입니다.

• Mattermost LB Allowed CIDR Blocks:

  • HTTPS로 Mattermost에 접근할 수 있는 IP 범위입니다. 기본값(0.0.0.0/0)은 어디서든 접근을 허용하므로, 사내 전용이나 내부 전용 배포에서는 범위를 제한하세요.

• Show Advanced Mattermost Options:

  • 이 옵션을 켜면 다음 필드가 나타납니다. 모두 대부분의 배포에 적합한 기본값이 설정되어 있습니다.

    • Kubernetes Namespace: Mattermost가 설치되는 네임스페이스입니다(기본값: mattermost).
    • Helm Repository URL: Mattermost Operator Helm 차트의 출처입니다(기본값: https://helm.mattermost.com).
    • Operator Helm Chart Version: 설치할 Mattermost Operator Helm 차트 버전을 목록에서 선택합니다(기본값: 제공되는 최신 버전).
    • NIC Readiness Wait Timeout: apply를 실패로 처리하기 전에 Native Ingress Controller가 준비될 때까지 기다리는 시간입니다(기본값: 180초).

OKE Configuration

• Kubernetes Version:

  • 비워 두면 OKE가 게시하는 최신 버전이 자동으로 선택됩니다.

• Worker OS Version:

  • Oracle Linux 8 또는 9(기본값: 8).

• Worker Count:

  • 클러스터의 워커 노드 수입니다(기본값: 3, 고가용성 권장값). 나중에 스택을 편집해 다시 적용하는 방식으로 조정할 수 있습니다.

• Show Advanced OKE Options:

  • 이 옵션을 켜면 다음 필드가 나타납니다. 모두 대부분의 배포에 적합한 기본값이 설정되어 있습니다.

    • Virtual Cloud Network (VCN) CIDR: 클러스터 네트워크의 IP 주소 범위입니다(기본값: 10.20.0.0/16). 피어링해야 하는 기존 네트워크와 충돌할 때만 변경하세요.
    • API Endpoint Allowed CIDR Blocks: Kubernetes API에 접근할 수 있는 IP 범위입니다(기본값: 0.0.0.0/0, 즉 어디서든 접근 가능). 보안을 강화하려면 사내 게이트웨이나 VPN 범위로 제한하세요. 대체 경로가 되는 배스천 호스트가 없으므로, 선택한 범위에 본인의 관리자 접근 경로가 반드시 포함되도록 하세요.
    • Cluster CNI: 파드 네트워킹 모드입니다. OCI_VCN_IP_NATIVE(기본값, 더 나은 성능과 긴밀한 VCN 통합을 위해 권장) 또는 FLANNEL_OVERLAY 중에서 선택합니다.
    • Worker Shape: 각 워커 노드의 컴퓨트 셰이프입니다(기본값: VM.Standard.E5.Flex, 2 OCPU / 16 GB 메모리). 대부분의 Mattermost 배포에 적합합니다.
    • Worker Pool Name: OCI 콘솔과 CLI에 표시되는 워커 노드 풀의 이름입니다.

Cluster Tools

• Install Metrics Server:

  • 나중에 자체 오토스케일러를 추가할 경우 kubectl top과 HPA가 의존하는 metrics API를 사용할 수 있게 합니다. 기본적으로 켜져 있으며 모든 배포에 권장됩니다.

• Create OKE IAM Policies:

  • OKE가 클러스터 리소스를 관리하는 데 필요한 IAM 정책을 자동으로 만듭니다. 기본적으로 켜져 있으며, 해당 정책이 컴파트먼트에 이미 있는 경우에만 끄세요.

PostgreSQL

• PostgreSQL Database Name / Description:

  • OCI Database with PostgreSQL 시스템의 표시 이름과 설명입니다(아래의 Mattermost 애플리케이션 데이터베이스 이름과는 별개입니다).

• PostgreSQL Major Version:

  • 14, 15, 16, 17 중 하나입니다(기본값: 16).

• PostgreSQL Admin Username / Password:

  • DB 시스템의 관리자 자격 증명입니다. 비밀번호는 8~32자여야 하며 대문자, 소문자, 숫자, 특수 문자를 각각 하나 이상 포함해야 하고, 작은따옴표·큰따옴표·백슬래시·세미콜론은 사용할 수 없습니다.

• Mattermost Database Name / User / Password:

  • Mattermost가 PostgreSQL 내부에서 연결할 때 사용하는 데이터베이스, 사용자, 비밀번호입니다(기본값: mattermost / mmuser). 비밀번호 규칙은 위의 PostgreSQL Admin Password와 동일합니다(8~32자, 대소문자, 숫자, 특수 문자, 따옴표·백슬래시·세미콜론 불가).

• Create a Subnet for the Mattermost Database:

  • 기본적으로 켜져 있으며 DB 시스템 전용 서브넷을 만듭니다. 기존 서브넷을 선택하려면 끄세요.

• PostgreSQL Backup Retention (Days):

  • 자동 백업 보존 기간으로 7~35일입니다(기본값: 30).

• Show Advanced PostgreSQL Options:

  • 이 옵션을 켜면 다음 필드가 나타납니다. 모두 대부분의 배포에 적합한 기본값이 설정되어 있습니다.

    • PostgreSQL Port: PostgreSQL이 수신 대기하는 포트입니다(기본값: 5432).
    • Backup Window: 자동 백업을 수행하는 일간 UTC 시간 창입니다.
    • Maintenance Window: 유지 관리 작업을 수행하는 주간 UTC 시간 창입니다.
    • Per-Tier Overrides: 각 Mattermost Installation Size 등급별 인스턴스 수, OCPU, 메모리 재정의 값입니다.

Object Storage

• Bucket Compartment:

  • Object Storage 버킷의 컴파트먼트입니다. 기본값은 기본 컴파트먼트입니다.

• Object Storage Bucket Name:

  • Mattermost 파일 첨부를 저장하는 데 사용하는 버킷의 이름입니다.

Tagging

• Tag Resources:

  • 스택이 만드는 모든 리소스에 OCI 자유 형식 태그 또는 정의된 태그를 선택적으로 적용합니다.

4단계: 검토 및 적용

모든 설정을 확인하고 Create를 선택해 배포를 시작합니다. Resource Manager 작업과 로그를 모니터링하세요. 최초 apply에는 약 30분이 걸립니다.

5단계: 배포 후

작업이 완료되면 스택의 Application information 탭을 열어 배포 세부 정보를 확인합니다.

• Load Balancer IP Address: Mattermost 로드 밸런서에 예약된 OCI 공인 IP입니다. Mattermost FQDN에서 이 IP를 가리키는 DNS A 레코드를 만드세요. 이 IP는 재적용을 거쳐도 유지됩니다.
• Mattermost URL(오른쪽 상단 버튼): 공개 HTTPS URL이며 DNS가 전파되면 접속할 수 있습니다.
• OKE Cluster OCID와 Deployed Kubernetes Version: kubectl이나 OCI CLI로 연결해야 할 때 OKE 클러스터를 식별하는 데 사용합니다.

A 레코드가 해석되면 브라우저에서 Mattermost URL로 이동합니다.

6단계: Mattermost 업그레이드

Mattermost 설치를 업그레이드하려면 다음과 같이 진행합니다.

1. Resource Manager 스택으로 이동해 Edit를 선택합니다.
2. Mattermost Version 변수를 대상 릴리스로 변경합니다.
3. 저장한 뒤 Plan을 실행하고 이어서 Apply를 실행합니다.

Native Ingress Controller는 Pod Readiness Gate를 사용해 새 파드의 OCI 로드 밸런서 백엔드가 정상으로 보고될 때까지 해당 파드를 트래픽에서 제외합니다. HA 규모(100users를 초과해 Mattermost 레플리카가 여러 개인 경우)에서는 다른 레플리카가 계속 트래픽을 처리하므로 롤아웃 중 중단이 최소화됩니다. 단일 레플리카로 실행되는 기본 100users 규모에서는 해당 파드가 재시작되는 동안 짧은 중단이 발생하는 것이 정상입니다.

자주 발생하는 오류와 예방 방법

• 오류: 권한 부족으로 스택 생성 실패

  • 원인: 스택을 실행하는 사용자 또는 그룹에 IAM 정책이 제대로 설정되지 않았습니다.
  • 해결: Resource Manager, OKE, Networking, OCI Database with PostgreSQL, Object Storage, Certificate Service에 대한 권한이 있는지 확인하세요.

• 오류: Mattermost 라이선스가 필요해 Plan 실패

  • 원인: 라이선스를 업로드하지 않은 상태에서 Mattermost Installation Size가 100users보다 큰 값으로 설정되었습니다. 더 큰 규모는 Enterprise 라이선스가 필요한 고가용성 모드로 배포됩니다.
  • 해결: 유효한 Mattermost Enterprise 라이선스를 업로드하거나 100users를 선택하세요.

• 오류: 배포 후 Mattermost URL이 해석되지 않음

  • 원인: FQDN에 대한 DNS A 레코드가 아직 만들어지지 않았거나 전파되지 않았습니다.
  • 해결: Mattermost FQDN에서 mattermost_lb_ip 출력값을 가리키는 A 레코드를 만든 뒤 DNS 전파를 기다리세요.

• 오류: 인증서 OCID가 거부되거나 ingress가 정상 상태가 되지 않음

  • 원인: OCI Certificate Service OCID가 존재하지 않거나, 같은 테넌시에 있지 않거나, 구성된 FQDN과 일치하지 않습니다.
  • 해결: OCI Certificate Service에서 인증서를 다시 확인하고 OCID를 올바르게 복사했는지 확인하세요.

• 오류: PostgreSQL 비밀번호 거부

  • 원인: PostgreSQL Admin Password 또는 Mattermost Database Password가 요구되는 복잡도 규칙(8~32자, 대소문자, 숫자, 특수 문자, 따옴표·백슬래시·세미콜론 불가)을 충족하지 않습니다.
  • 해결: 필드 설명에 표시된 패턴을 충족하는 비밀번호를 다시 입력하세요.

• 오류: PostgreSQL 시스템 또는 버킷에서 Terraform destroy 실패

  • 원인: 데이터베이스 시스템은 설계상 삭제 보호가 활성화되어 있으며, OCI는 비어 있지 않은 Object Storage 버킷의 삭제를 거부합니다.
  • 해결: 먼저 버킷을 비우고, 데이터베이스의 수명 주기 보호를 해제한 뒤 삭제하세요.

Mattermost 서버 관리에 대해 더 알아보려면 Administration Guide 문서를 참고하세요.

자주 묻는 질문

Docker 이미지에 맞춤 CA 인증서를 추가한 뒤 파드가 CrashLoopBackOff 오류로 실패하는 이유는 무엇인가요?

Docker 이미지의 /etc/ssl/certs 디렉터리에 맞춤 CA 인증서를 추가하고 Mattermost Enterprise Edition Helm Chart로 Kubernetes 환경에 배포한 뒤 CrashLoopBackOff 오류가 발생할 수 있습니다. 이 문제는 대개 맞춤 CA 인증서가 시스템의 인증서 신뢰 저장소에서 인식되지 않아, 애플리케이션이 해당 맞춤 CA를 요구하는 서비스에 연결하려 할 때 TLS 핸드셰이크가 실패하기 때문에 발생합니다.

핵심 기능은 계속 동작할 수 있지만 다음과 같은 증상이 나타날 수 있습니다.

• 파드가 크래시 루프에 빠지며 backoff - restarting failed container in pod 오류 메시지가 표시됩니다.
• kubectl describe, kubectl logs 같은 디버깅 명령이 유용한 정보를 거의 제공하지 않습니다.
• 연동이 차단될 수 있습니다.

Docker 이미지를 다시 빌드하지 않고 이 문제를 해결할 수 있나요?

가능합니다. 배포 과정을 단순화하고 이미지 재빌드로 인한 중단을 최소화하기 위해 맞춤 CA 인증서를 Kubernetes 네이티브 방식으로 관리하는 것을 권장합니다. Docker 이미지를 수정하는 대신 Kubernetes 리소스를 사용해 인증서를 파드에 직접 주입하면, 인증서가 바뀔 때마다 Docker 이미지를 다시 빌드하고 재배포하지 않고도 맞춤 CA 인증서를 동적으로 관리할 수 있습니다.

Kubernetes 시크릿에 맞춤 CA 인증서를 저장한 뒤 파드에 마운트하세요.

1. 맞춤 CA 인증서를 담은 Kubernetes 시크릿을 만듭니다.
2. Helm 차트의 구성 옵션을 사용해 인증서를 파드에 마운트합니다. 이 방법은 관리가 간단하고, 이후 인증서를 갱신할 때 Docker 이미지를 다시 빌드할 필요가 없습니다.

또는 Docker 이미지를 수정하지 않고 인증서를 동적으로 주입하려면, initContainer를 사용해 메인 컨테이너가 시작되기 전에 인증서를 파드 파일 시스템에 복사하고 인증서 신뢰 저장소를 갱신하세요.

CrashLoopBackOff 오류의 근본 원인은 어떻게 진단하나요?

kubectl describe pods로 상세 이벤트 로그를 확인하세요.

추가 인사이트를 얻으려면 Grafana 같은 로깅 도구로 로그를 집계하고 분석하는 것도 고려하세요.

자체 호스팅 Kubernetes 배포에서 데이터는 어디에 저장되나요?

데이터 저장 위치는 배포 시 구성한 백엔드 데이터베이스(RDS, Azure Postgres, 자체 호스팅 PostgreSQL 등)와 백엔드 파일 저장소(AWS S3, 기타 S3 호환 서비스, 마운트된 볼륨 등)에 따라 달라집니다.

볼륨 마운트를 사용하는 경우, Mattermost 서버에 파일 저장소를 "로컬" 디렉터리로 제공하도록 NFS 볼륨을 사용하는 것을 권장합니다.

모든 종류의 Kubernetes 퍼시스턴트 볼륨이 Mattermost와 함께 테스트된 것은 아니며, 일부는 제약이 있거나 적절한 권한과 접근을 보장하기 위해 추가 설정이 필요할 수 있습니다. 시스템 관리자는 사용하려는 퍼시스턴트 볼륨 유형의 문서를 검토하고 Mattermost와의 호환성을 직접 테스트해 볼 것을 권장합니다.