커스텀 서비스 차단 목록

기본적으로 Migrate to Containers는 개발자가 컨테이너로 마이그레이션할 때 VM에서 불필요한 서비스를 중지합니다. 일부 경우에 이러한 서비스는 마이그레이션된 컨테이너에 문제를 일으킬 수도 있고 컨테이너 컨텍스트에 필요하지 않습니다.

또한 사용자 고유의 서비스 커스텀 목록을 정의해서 커스텀 차단 목록을 사용하여 마이그레이션된 컨테이너를 사용 중지할 수도 있습니다. 차단 목록에서는 마이그레이션된 컨테이너에서 사용 중지할 서비스를 하나 이상 지정합니다.

차단 목록 정의

.yaml 파일에서 다음 형식으로 맞춤설정된 차단 목록을 정의합니다.

service_list:
  - name: <var>group-name-1</var>
    services:
      - <var>service-name</var>
  - name: <var>group-name-2</var>
    services:
      - <var>service-name</var>
      - <var>ervice-name</var>

각 항목의 의미는 다음과 같습니다.

그룹은 서비스의 논리적 모음이므로, 단일 그룹으로 비슷한 서비스를 모을 수 있습니다. 그룹 이름에 문자열 값을 지정합니다.
서비스 이름은 마이그레이션된 컨테이너에서 사용 중지할 서비스를 지정합니다.

예를 들어 my-blocklist.yaml 파일을 다음과 같이 정의합니다.

service_list:
  - name: lvm-related
    services:
      - lvm2-lvmetad
  - name: hardware-related
    services:
      - microcode
      - microcode.ctl

커스텀 차단 목록 적용

다음과 같이 컨테이너에 커스텀 차단 목록을 적용합니다.

차단 목록이 포함된 Kubernetes configmap을 만들고 이를 컨테이너의 배포 사양에 추가합니다.

이 방법을 사용하면 컨테이너를 다시 빌드할 필요 없이 차단 목록을 추가할 수 있습니다. 하지만 컨테이너를 호스팅하는 데 사용되는 모든 클러스터에서 configmap을 다시 만들어야 합니다.
컨테이너의 Dockerfile을 수정하고 컨테이너 이미지를 다시 빌드합니다.

이 방법을 사용하려면 차단 목록을 추가할 컨테이너 이미지를 다시 빌드해야 합니다. 이제 차단 목록이 컨테이너에 포함되었으므로, 배포 전 클러스터에서 추가 구성을 수행할 필요가 없습니다.

configmap 사용

configmap을 사용하여 차단 목록을 만들려면 다음 안내를 따르세요.

소스 VM을 컨테이너에 마이그레이션합니다.
위에 표시된 대로 사용 중지하려는 서비스가 나열된 차단 목록 .yaml 파일을 만듭니다. 이 예시에서는 파일 이름을 my-blocklist.yaml로 지정합니다.

차단 목록 .yaml 파일에서 configmap을 만듭니다.

kubectl create configmap configmap-name --from-file=path-to-yaml

이 예시에서 configmap은 blocklistcm입니다.

kubectl create configmap blocklistcm --from-file=./my-blocklist.yaml

configmap을 확인합니다.
```
kubectl describe configmaps
```
컨테이너를 마이그레이션할 때 생성된 deployment_spec.yaml을 수정합니다.
```
vi deployment_spec.yaml
```
배포 사양에서 다음을 추가합니다.
1. volumes 아래의 configmap에 대해 새 볼륨을 추가합니다.
```
volumes:
- configMap: 
     name: blocklistcm # Name of the config map you created above. 
   name: blocklistvol # Name of the configmap volume.
```
2. configmap의 볼륨 마운트를 추가합니다.
```
spec:
  containers: 
    volumeMounts: 
    - mountPath: /etc/bl # Mount path for the configmap volume. 
      name: blocklistvol # Name of the configmap volume. 
```
3. 차단 목록 .yaml 파일의 경로를 지정하여 HC_CUSTOM_SERVICE_BLOCKLIST라는 새 환경 변수를 추가합니다. 환경 변수 이름은 HC_CUSTOM_SERVICE_BLOCKLIST여야 합니다.
```
containers:
 - image: container-image-location
   env:
   - name: HC_CUSTOM_SERVICE_BLOCKLIST
     value: "/etc/bl/my-blocklist.yaml"
```
  값으로 지정된 경로는 configmap의 mountPath와 blocklist .yaml 파일 이름인 my-blocklist.yaml을 연결한 것입니다.
4. 파일을 저장합니다.
컨테이너를 배포합니다.
```
kubectl apply -f deployment_spec.yaml
```

컨테이너 배포 후 컨테이너를 조사하여 서비스가 실행 중이 아닌지 확인할 수 있습니다. 예를 들면 다음과 같습니다.

# Get pod name.
$ kubectl get pod
# Connect to pod.
$ kubectl exec -it POD_NAME -- /bin/bash
# View running services. This step is OS dependent. For example:
$ service --status-all```

Dockerfile 수정

이 섹션에서는 마이그레이션으로 만들어진 Dockerfile을 편집하여 커스텀 차단 목록을 만드는 방법을 설명합니다.

소스 VM을 컨테이너에 마이그레이션합니다.
편집기에서 Dockerfile을 엽니다.
다음 COPY 명령어를 추가하여 컨테이너의 파일 시스템에 차단 목록 .yaml 파일을 추가합니다.
```
COPY src dest 
```
예를 들면 다음과 같습니다.
```
COPY my-blocklist.yaml /etc/mybl/my-blocklist.yaml
```
대상 경로는 컨테이너 내의 모든 경로가 될 수 있습니다.
COPY 명령어로 지정된 파일 대상을 기반으로 차단 목록 .yaml 파일의 경로를 지정하는 HC_CUSTOM_SERVICE_BLOCKLIST라는 새 환경 변수를 추가합니다. 환경 변수 이름은 HC_CUSTOM_SERVICE_BLOCKLIST여야 합니다.
```
ENV HC_CUSTOM_SERVICE_BLOCKLIST /file-path
```
예를 들면 다음과 같습니다.
```
ENV HC_CUSTOM_SERVICE_BLOCKLIST /etc/mybl/my-blocklist.yaml
```
컨테이너 이미지를 업데이트합니다.

컨테이너 이미지를 업데이트하는 방법은 빌드 환경에 따라 달라집니다. 다음을 사용할 수 있습니다.
1. gcloud: 빠른 시작: 빌드의 설명에 따라 이미지를 빌드하고 이를 Container Registry에 업로드합니다.
2. docker build: 이미지 빌드 및 실행을 참조하세요.
새 이미지를 빌드한 후 편집기에서 deployment_spec.yaml 파일을 열어 이미지 위치를 업데이트합니다.
```
spec:
  containers:
  - image: new-image-location
```
예를 들어 gcloud를 사용하여 이미지를 빌드하고 Container Registry에 업로드한 경우 new-image-location이 gcr.io/my-project/my-new-image:v1.0일 수 있습니다.
컨테이너를 배포합니다.
```
kubectl apply -f deployment_spec.yaml
```

컨테이너 배포 후 컨테이너를 조사하여 서비스가 실행 중이 아닌지 확인할 수 있습니다. 예를 들면 다음과 같습니다.

# Get pod name.
$ kubectl get pod
# Connect to pod.
$ kubectl exec -it POD_NAME -- /bin/bash
# View running services. This step is OS dependent. For example:
$ service --status-all