InfoGrab Docs

GitLab Managed Apps에서 Cluster Management Projects로 마이그레이션 (더 이상 사용되지 않음)

요약

GitLab Managed Apps는 사용자 제어 Cluster Management 프로젝트를 선호하여 GitLab 14.0에서 더 이상 사용되지 않습니다. GitLab Managed Apps에서 Cluster Management Project로 마이그레이션하려면 아래 단계를 따르세요.

GitLab Managed Apps는 사용자 제어 Cluster Management 프로젝트를 선호하여 GitLab 14.0에서 더 이상 사용되지 않습니다. 프로젝트를 통해 클러스터 애플리케이션을 관리하면 기존 GitLab Managed Apps보다 클러스터를 훨씬 더 유연하게 관리할 수 있습니다. 클러스터 관리 프로젝트로 마이그레이션하려면 GitLab Runner를 사용할 수 있어야 하며 Helm에 익숙해야 합니다.

Cluster Management Project로 마이그레이션#

GitLab Managed Apps에서 Cluster Management Project로 마이그레이션하려면 아래 단계를 따르세요. 예시가 있는 동영상 안내도 참조하세요.

  1. Cluster Management Project 템플릿을 기반으로 새 프로젝트를 만듭니다.

  2. 이 프로젝트를 위해 클러스터에 에이전트를 설치합니다.

  3. Project Template의 .gitlab-ci.yml에 지시된 대로 KUBE_CONTEXT CI/CD 변수를 새로 설치된 에이전트의 컨텍스트로 설정합니다.

  4. 사전 구성된 .gitlab-ci.yml 파일을 사용하여 Helm v2 릴리스를 통해 배포된 앱을 감지합니다:

    • 기본 GitLab Managed Apps 네임스페이스를 재정의한 경우 .gitlab-ci.yml을 편집하고 스크립트가 올바른 네임스페이스를 인수로 받는지 확인합니다:

      script:
        - gl-fail-if-helm2-releases-exist <your_custom_namespace>
      
    • 기본 이름(gitlab-managed-apps)을 유지한 경우 스크립트가 이미 설정되어 있습니다.

    어느 경우든 수동으로 파이프라인 실행하고 detect-helm2-releases job의 로그를 읽어 Helm v2 릴리스가 있는지와 어떤 것들이 있는지 확인합니다.

  5. Helm v2 릴리스가 없으면 이 단계를 건너뜁니다. 그렇지 않으면 Helm v2에서 Helm v3로 마이그레이션하는 방법에 대한 공식 Helm 설명서를 따르고, 성공적으로 마이그레이션된 것이 확인되면 Helm v2 릴리스를 정리합니다.

  6. 이 단계에서는 이미 Helm v3 릴리스만 있어야 합니다. 이 프로젝트로 관리하려는 애플리케이션의 경로를 메인 ./helmfile.yaml에서 주석 해제합니다. 한번에 원하는 모든 것을 주석 해제할 수 있지만, 프로세스 중에 길을 잃지 않도록 각 앱에 대해 다음 단계를 별도로 반복해야 합니다.

  7. 앱에 배포된 차트 버전과 일치하도록 관련 applications/{app}/helmfiles.yaml을 편집합니다. GitLab Runner Helm v3 릴리스를 예시로 들겠습니다:

    다음 명령은 릴리스와 해당 버전을 나열합니다:

    helm ls -n gitlab-managed-apps
    
    NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
    runner gitlab-managed-apps 1 2021-06-09 19:36:55.739141644 +0000 UTC deployed gitlab-runner-0.28.0 13.11.0
    

    {release}-v{chart_version} 형식인 CHART 열에서 버전을 가져온 다음 ./applications/gitlab-runner/helmfile.yamlversion: 속성을 편집하여 배포한 버전과 일치시킵니다. 이 마이그레이션 중에 버전 업그레이드를 방지하는 안전한 단계입니다. 앱이 다른 네임스페이스에 배포된 경우 이전 명령에서 gitlab-managed-apps를 교체하는 것을 잊지 마세요.

  8. 앱에 대한 applications/{app}/values.yaml을 편집하여 배포된 값과 일치시킵니다. 예를 들어 GitLab Runner의 경우:

    1. 다음 명령의 출력을 복사합니다(클 수 있음):

      helm get values runner -n gitlab-managed-apps -a --output yaml
      
    2. applications/gitlab-runner/values.yaml을 이전 명령의 출력으로 덮어씁니다.

    이 안전한 단계는 예상치 못한 기본값이 배포된 값을 덮어쓰지 않도록 보장합니다. 예를 들어 GitLab Runner의 gitlabUrl 또는 runnerRegistrationToken이 실수로 덮어쓰일 수 있습니다.

  9. 일부 앱은 특별한 주의가 필요합니다:

    • Ingress: 기존 차트 이슈로 인해 ./gl-helmfile 명령을 실행하려고 할 때 spec.clusterIP: Invalid value가 표시될 수 있습니다. 이를 해결하기 위해 applications/ingress/values.yaml의 릴리스 값을 덮어쓴 후 모든 omitClusterIP: false 항목을 omitClusterIP: true로 설정해야 할 수 있습니다. 다른 접근 방식으로 kubectl get services -n gitlab-managed-apps를 실행하여 이 IP를 수집한 다음 불평하는 각 ClusterIP를 해당 명령에서 얻은 값으로 덮어쓸 수 있습니다.

    • Vault: 이 애플리케이션은 Helm v2에서 사용된 차트에서 Helm v3에서 사용된 차트로 주요 변경 사항을 도입합니다. 따라서 이 Cluster Management Project와 통합하는 유일한 방법은 이 앱을 제거하고 applications/vault/values.yaml에서 제안된 차트 버전을 받아들이는 것입니다.

    • Cert-manager:

      • Kubernetes 버전 1.20 이상의 사용자의 경우 더 이상 사용되지 않는 cert-manager v0.10이 더 이상 유효하지 않으며 업그레이드에는 주요 변경 사항이 포함됩니다. 따라서 cert-manager v0.10을 백업하고 제거한 다음 최신 cert-manager를 설치해야 합니다. 이 버전을 설치하려면 ./helmfile.yaml에서 applications/cert-manager/helmfile.yaml의 주석을 해제합니다. 이렇게 하면 새 버전을 설치하는 파이프라인이 트리거됩니다.

      • Kubernetes 버전 1.20 미만의 사용자의 경우 프로젝트의 메인 Helmfile(./helmfile.yaml)에서 applications/cert-manager-legacy/helmfile.yaml의 주석을 해제하여 v0.10을 유지할 수 있습니다.

        [!warning] Cert-manager v0.10은 Kubernetes가 버전 1.20 이상으로 업그레이드될 때 중단됩니다.

  10. 이전의 모든 단계를 따른 후 수동으로 파이프라인 실행하고 apply job 로그를 지켜보며 애플리케이션이 성공적으로 감지, 설치되었는지와 예상치 못한 업데이트가 있었는지 확인합니다.

    일부 주석 체크섬이 업데이트될 것으로 예상되며 다음 속성도 마찬가지입니다:

    --- heritage: Tiller
    +++ heritage: Tiller
    

성공적인 파이프라인을 얻은 후 Cluster Management Project로 관리하려는 다른 배포된 앱에 대해 이 단계를 반복합니다.

cert-manager v0.10 백업 및 제거#

  1. cert-manager v0.10 데이터를 백업하는 방법은 공식 문서를 따릅니다.
  2. applications/cert-manager/helmfile.yaml 파일에서 installed: true의 모든 항목을 installed: false로 설정하여 cert-manager를 제거합니다.
  3. kubectl get Issuers,ClusterIssuers,Certificates,CertificateRequests,Orders,Challenges,Secrets,ConfigMaps -n gitlab-managed-apps | grep certmanager를 실행하여 남은 리소스를 검색합니다.
  4. 이전 단계에서 찾은 각 리소스에 대해 kubectl delete -n gitlab-managed-apps {ResourceType} {ResourceName}으로 삭제합니다. 예를 들어 cert-manager-controller라는 ConfigMap 유형의 리소스를 찾은 경우 kubectl delete configmap -n gitlab-managed-apps cert-manager-controller를 실행하여 삭제합니다.

동영상 안내#

GMA에서 Cluster Management 프로젝트로 마이그레이션하는 방법에 대한 예시가 있는 다음 동영상을 시청할 수 있습니다:

GitLab Managed Apps에서 Cluster Management Projects로 마이그레이션 (더 이상 사용되지 않음)

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

GitLab Managed Apps는 사용자 제어 Cluster Management 프로젝트를 선호하여 GitLab 14.0에서 더 이상 사용되지 않습니다. GitLab Managed Apps에서 Cluster Management Project로 마이그레이션하려면 아래 단계를 따르세요.

GitLab Managed Apps는 사용자 제어 Cluster Management 프로젝트를 선호하여 GitLab 14.0에서 더 이상 사용되지 않습니다. 프로젝트를 통해 클러스터 애플리케이션을 관리하면 기존 GitLab Managed Apps보다 클러스터를 훨씬 더 유연하게 관리할 수 있습니다. 클러스터 관리 프로젝트로 마이그레이션하려면 GitLab Runner를 사용할 수 있어야 하며 Helm에 익숙해야 합니다.

Cluster Management Project로 마이그레이션#

GitLab Managed Apps에서 Cluster Management Project로 마이그레이션하려면 아래 단계를 따르세요. 예시가 있는 동영상 안내도 참조하세요.

  1. Cluster Management Project 템플릿을 기반으로 새 프로젝트를 만듭니다.

  2. 이 프로젝트를 위해 클러스터에 에이전트를 설치합니다.

  3. Project Template의 .gitlab-ci.yml에 지시된 대로 KUBE_CONTEXT CI/CD 변수를 새로 설치된 에이전트의 컨텍스트로 설정합니다.

  4. 사전 구성된 .gitlab-ci.yml 파일을 사용하여 Helm v2 릴리스를 통해 배포된 앱을 감지합니다:

    • 기본 GitLab Managed Apps 네임스페이스를 재정의한 경우 .gitlab-ci.yml을 편집하고 스크립트가 올바른 네임스페이스를 인수로 받는지 확인합니다:

      script:
        - gl-fail-if-helm2-releases-exist <your_custom_namespace>
      
    • 기본 이름(gitlab-managed-apps)을 유지한 경우 스크립트가 이미 설정되어 있습니다.

    어느 경우든 수동으로 파이프라인 실행하고 detect-helm2-releases job의 로그를 읽어 Helm v2 릴리스가 있는지와 어떤 것들이 있는지 확인합니다.

  5. Helm v2 릴리스가 없으면 이 단계를 건너뜁니다. 그렇지 않으면 Helm v2에서 Helm v3로 마이그레이션하는 방법에 대한 공식 Helm 설명서를 따르고, 성공적으로 마이그레이션된 것이 확인되면 Helm v2 릴리스를 정리합니다.

  6. 이 단계에서는 이미 Helm v3 릴리스만 있어야 합니다. 이 프로젝트로 관리하려는 애플리케이션의 경로를 메인 ./helmfile.yaml에서 주석 해제합니다. 한번에 원하는 모든 것을 주석 해제할 수 있지만, 프로세스 중에 길을 잃지 않도록 각 앱에 대해 다음 단계를 별도로 반복해야 합니다.

  7. 앱에 배포된 차트 버전과 일치하도록 관련 applications/{app}/helmfiles.yaml을 편집합니다. GitLab Runner Helm v3 릴리스를 예시로 들겠습니다:

    다음 명령은 릴리스와 해당 버전을 나열합니다:

    helm ls -n gitlab-managed-apps
    
    NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
    runner gitlab-managed-apps 1 2021-06-09 19:36:55.739141644 +0000 UTC deployed gitlab-runner-0.28.0 13.11.0
    

    {release}-v{chart_version} 형식인 CHART 열에서 버전을 가져온 다음 ./applications/gitlab-runner/helmfile.yamlversion: 속성을 편집하여 배포한 버전과 일치시킵니다. 이 마이그레이션 중에 버전 업그레이드를 방지하는 안전한 단계입니다. 앱이 다른 네임스페이스에 배포된 경우 이전 명령에서 gitlab-managed-apps를 교체하는 것을 잊지 마세요.

  8. 앱에 대한 applications/{app}/values.yaml을 편집하여 배포된 값과 일치시킵니다. 예를 들어 GitLab Runner의 경우:

    1. 다음 명령의 출력을 복사합니다(클 수 있음):

      helm get values runner -n gitlab-managed-apps -a --output yaml
      
    2. applications/gitlab-runner/values.yaml을 이전 명령의 출력으로 덮어씁니다.

    이 안전한 단계는 예상치 못한 기본값이 배포된 값을 덮어쓰지 않도록 보장합니다. 예를 들어 GitLab Runner의 gitlabUrl 또는 runnerRegistrationToken이 실수로 덮어쓰일 수 있습니다.

  9. 일부 앱은 특별한 주의가 필요합니다:

    • Ingress: 기존 차트 이슈로 인해 ./gl-helmfile 명령을 실행하려고 할 때 spec.clusterIP: Invalid value가 표시될 수 있습니다. 이를 해결하기 위해 applications/ingress/values.yaml의 릴리스 값을 덮어쓴 후 모든 omitClusterIP: false 항목을 omitClusterIP: true로 설정해야 할 수 있습니다. 다른 접근 방식으로 kubectl get services -n gitlab-managed-apps를 실행하여 이 IP를 수집한 다음 불평하는 각 ClusterIP를 해당 명령에서 얻은 값으로 덮어쓸 수 있습니다.

    • Vault: 이 애플리케이션은 Helm v2에서 사용된 차트에서 Helm v3에서 사용된 차트로 주요 변경 사항을 도입합니다. 따라서 이 Cluster Management Project와 통합하는 유일한 방법은 이 앱을 제거하고 applications/vault/values.yaml에서 제안된 차트 버전을 받아들이는 것입니다.

    • Cert-manager:

      • Kubernetes 버전 1.20 이상의 사용자의 경우 더 이상 사용되지 않는 cert-manager v0.10이 더 이상 유효하지 않으며 업그레이드에는 주요 변경 사항이 포함됩니다. 따라서 cert-manager v0.10을 백업하고 제거한 다음 최신 cert-manager를 설치해야 합니다. 이 버전을 설치하려면 ./helmfile.yaml에서 applications/cert-manager/helmfile.yaml의 주석을 해제합니다. 이렇게 하면 새 버전을 설치하는 파이프라인이 트리거됩니다.

      • Kubernetes 버전 1.20 미만의 사용자의 경우 프로젝트의 메인 Helmfile(./helmfile.yaml)에서 applications/cert-manager-legacy/helmfile.yaml의 주석을 해제하여 v0.10을 유지할 수 있습니다.

        [!warning] Cert-manager v0.10은 Kubernetes가 버전 1.20 이상으로 업그레이드될 때 중단됩니다.

  10. 이전의 모든 단계를 따른 후 수동으로 파이프라인 실행하고 apply job 로그를 지켜보며 애플리케이션이 성공적으로 감지, 설치되었는지와 예상치 못한 업데이트가 있었는지 확인합니다.

    일부 주석 체크섬이 업데이트될 것으로 예상되며 다음 속성도 마찬가지입니다:

    --- heritage: Tiller
    +++ heritage: Tiller
    

성공적인 파이프라인을 얻은 후 Cluster Management Project로 관리하려는 다른 배포된 앱에 대해 이 단계를 반복합니다.

cert-manager v0.10 백업 및 제거#

  1. cert-manager v0.10 데이터를 백업하는 방법은 공식 문서를 따릅니다.
  2. applications/cert-manager/helmfile.yaml 파일에서 installed: true의 모든 항목을 installed: false로 설정하여 cert-manager를 제거합니다.
  3. kubectl get Issuers,ClusterIssuers,Certificates,CertificateRequests,Orders,Challenges,Secrets,ConfigMaps -n gitlab-managed-apps | grep certmanager를 실행하여 남은 리소스를 검색합니다.
  4. 이전 단계에서 찾은 각 리소스에 대해 kubectl delete -n gitlab-managed-apps {ResourceType} {ResourceName}으로 삭제합니다. 예를 들어 cert-manager-controller라는 ConfigMap 유형의 리소스를 찾은 경우 kubectl delete configmap -n gitlab-managed-apps cert-manager-controller를 실행하여 삭제합니다.

동영상 안내#

GMA에서 Cluster Management 프로젝트로 마이그레이션하는 방법에 대한 예시가 있는 다음 동영상을 시청할 수 있습니다: