템플릿을 활용한 관리 아이디어

• 실제로 여러 마이크로 서비스를 운영하다 보면, 우리팀에서 운영해야 하는 서비스가 많지만 대부분의 설정이 중복된다는 사실을 발견하게 된다.

  • 결제 마이크로 서비스의 Deployment 예시

    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: payment-app-deployment
    namespace: payment-app
    spec:
    replicas: 3
    selector:
      matchLabels:
        app: payment-app
    template:
      metadata:
        labels:
          app: payment-app
      spec:
        containers:
        - name: monitoring-agent
          image: registry.spartacodingclub.kr/common-monitoring-agent:1.4.1
        - name: nginx
          image: registry.spartacodingclub.kr/common-nginx:1.27.0
          ports:
            - containerPort: 80
        - name: redis
          image: registry.spartacodingclub.kr/common-redis:7.2.4
          ports:
            - containerPort: 6379
        - name: api
          image: registry.spartacodingclub.kr/payment-app:1.0.0
          ports:
            - containerPort: 8080

  • 유저관리 마이크로 서비스의 Deployment 예시

    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: user-app-deployment
    namespace: user-app
    spec:
    replicas: 5
    selector:
      matchLabels:
        app: user-app
    template:
      metadata:
        labels:
          app: user-app
      spec:
        containers:
        - name: monitoring-agent
          image: registry.spartacodingclub.kr/common-monitoring-agent:1.4.1
        - name: nginx
          image: registry.spartacodingclub.kr/common-nginx:1.27.0
          ports:
            - containerPort: 80
        - name: redis
          image: registry.spartacodingclub.kr/common-redis:7.2.4
          ports:
            - containerPort: 6379
        - name: api
          image: registry.spartacodingclub.kr/user-app:1.1.0
          ports:
            - containerPort: 8080

• 위의 Deploymnet 오브젝트 사례를 보면 알겠지만 일부를 제외하면 거의 모든 부분의 설정을 공통으로 사용한다는 것을 알 수 있다.
  -> 아래와 같이 중복되지 않는 부분을 변수화 시켜서 치환해버리면 어떨까? 하는 아이디어가 나오게 된다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appName }}-deployment
  namespace: {{ .Values.appName }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Values.appName }}
  template:
    metadata:
      labels:
        app: {{ .Values.appName }}
    spec:
      containers:
      - name: monitoring-agent
        image: registry.spartacodingclub.kr/common-monitoring-agent:1.4.1
      - name: nginx
        image: registry.spartacodingclub.kr/common-nginx:1.27.0
        ports:
          - containerPort: 80
      - name: redis
        image: registry.spartacodingclub.kr/common-redis:7.2.4
        ports:
          - containerPort: 6379
      - name: api
        image: {{ .Values.appApiImage }}
        ports:
          - containerPort: 8080

Helm 차트의 구성

• Helm이란 이렇게 오브젝트의 중복된 부분을 하나로 묶어서, 변수 몇 개만 설정하면 오브젝트를 구성할 수 있도록 하는 쿠버네티스의 보조 도구이다.
  • Helm은 쿠버네티스의 패키지 매니저라고 불리고 있다.
  • Java의 Gradle이나, NodeJS의 NPM과 비슷한 개념이라고 생각하면 된다.
• Helm 차트는 Helm에서 다루는 패키지를 이르는 말이다.
  • 즉, Helm 차트에는 여러 오브젝트들의 공통된 부분에 대한 정의와 설정해야 하는 변수들에 대한 정보가 담겨있다.
• Helm 차트는 크게 아래와 같은 구조로 구성된다.
  • Chart.yaml
    • 해당 Helm 차트에 대한 기본 정보(차트의 이름, 버전, 의존성 정보 등)가 담겨있는 yaml 파일
    • Gradle의 build.gradle, NodeJS의 package.json 파일과 비슷하다.
  • templates
    • 오브젝트들의 공통된 내용을 정의해두는 디렉토리(폴더)
  • values.yaml
    • 차트에서 사용하는 변수들의 기본값이 설정되어 있는 파일
• Helm 차트도 다른 도구의 패키지 매니저와 같이 의존성을 설정할 수 있는데, 이때는 아래와 같은 요소가 추가로 필요하게 된다.
  • charts
    • 외부에서 가져온 의존성 데이터가 실제로 담겨있는 디렉토리
    • Gradle의 dependencies, NodseJS의 node_modules와 비슷하다.

Helm의 주요 명령어

• 전체 명령어는 https://helm.sh/docs/helm/ 에서 확인할 수 있다.