GitHub Actions에서 GitLab CI/CD로 마이그레이션하는 경우, GitHub Action 워크플로우를 복제하고 개선하는 CI/CD 파이프라인을 만들 수 있습니다.

수동으로 직접 할 수도 있고, GitHub Actions to GitLab CI/CD agent skill을 사용하여 원하는 AI 에이전트를 활용할 수도 있습니다.

주요 유사점 및 차이점#

GitHub Actions와 GitLab CI/CD는 모두 코드 빌드, 테스트, 배포를 자동화하는 파이프라인을 생성하는 데 사용됩니다. 두 도구는 다음과 같은 유사점을 공유합니다:

• CI/CD 기능이 프로젝트 저장소에 저장된 코드에 직접 접근 가능합니다.
• 파이프라인 구성은 YAML로 작성되어 프로젝트 저장소에 저장됩니다.
• 파이프라인은 구성 가능하며 다른 스테이지에서 실행될 수 있습니다.
• 각 잡은 다른 컨테이너 이미지를 사용할 수 있습니다.

또한, 두 도구 사이에는 몇 가지 중요한 차이점이 있습니다:

• GitHub에는 서드파티 액션을 다운로드할 수 있는 마켓플레이스가 있으며, 추가 지원이나 라이선스가 필요할 수 있습니다.
• GitLab Self-Managed는 수평 및 수직 확장을 모두 지원하는 반면, GitHub Enterprise Server는 수직 확장만 지원합니다.
• GitLab은 모든 기능을 자체적으로 유지 및 지원하며, 일부 서드파티 통합은 템플릿을 통해 접근할 수 있습니다.
• GitLab은 기본 제공 컨테이너 레지스트리를 제공합니다.
• GitLab은 네이티브 Kubernetes 배포 지원을 제공합니다.
• GitLab은 세분화된 보안 정책을 제공합니다.

기능 및 개념 비교#

많은 GitHub 기능과 개념은 동일한 기능을 제공하는 GitLab의 동등 개념이 있습니다.

구성 파일#

GitHub Actions는 워크플로우 YAML 파일로 구성할 수 있습니다. GitLab CI/CD는 기본적으로 .gitlab-ci.yml YAML 파일을 사용합니다.

예를 들어, GitHub Actions workflow 파일에서:

on: [push]
jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World"

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

stages:
  - hello

hello:
  stage: hello
  script:
    - echo "Hello World"

GitHub Actions 워크플로우 구문#

GitHub Actions 구성은 특정 키워드를 사용하는 workflow YAML 파일에 정의됩니다. GitLab CI/CD도 유사한 기능을 가지며, 일반적으로 YAML 키워드로 구성됩니다.

공통 구성#

이 섹션에서는 자주 사용되는 CI/CD 구성을 설명하며, GitHub Actions에서 GitLab CI/CD로 변환하는 방법을 보여줍니다.

GitHub Action 워크플로우는 새 커밋 푸시와 같이 특정 이벤트가 발생할 때 트리거되는 자동화된 CI/CD 잡을 생성합니다. GitHub Action 워크플로우는 저장소 루트에 있는 .github/workflows 디렉토리에 정의된 YAML 파일입니다. GitLab의 동등한 개념은 저장소의 루트 디렉토리에도 위치하는 .gitlab-ci.yml 구성 파일입니다.

잡#

잡은 특정 결과를 달성하기 위해 일정한 순서로 실행되는 명령의 집합입니다. 예를 들어 컨테이너를 빌드하거나 프로덕션에 배포하는 것입니다.

예를 들어, 이 GitHub Actions workflow는 컨테이너를 빌드한 다음 프로덕션에 배포합니다. deploy 잡이 build 잡에 의존하기 때문에 잡은 순차적으로 실행됩니다:

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    container: golang:alpine
    steps:
      - run: apk update
      - run: go build -o bin/hello
      - uses: actions/upload-artifact@v3
        with:
          name: hello
          path: bin/hello
          retention-days: 7
  deploy:
    if: contains( github.ref, 'staging')
    runs-on: ubuntu-latest
    container: golang:alpine
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: hello
      - run: echo "Deploying to Staging"
      - run: scp bin/hello remoteuser@remotehost:/remote/directory

이 예시:

• golang:alpine 컨테이너 이미지를 사용합니다.
• 코드 빌드를 위한 잡을 실행합니다.
  • 빌드된 실행 파일을 아티팩트로 저장합니다.
• staging에 배포하는 두 번째 잡을 실행하며, 이 잡은:
  • 실행 전에 빌드 잡이 성공해야 합니다.
  • 커밋 대상 브랜치 staging이 필요합니다.
  • 빌드 실행 파일 아티팩트를 사용합니다.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

default:
  image: golang:alpine

stages:
  - build
  - deploy

build-job:
  stage: build
  script:
    - apk update
    - go build -o bin/hello
  artifacts:
    paths:
      - bin/hello
    expire_in: 1 week

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to Staging"
    - scp bin/hello remoteuser@remotehost:/remote/directory
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'

병렬 실행#

GitHub와 GitLab 모두에서 잡은 기본적으로 병렬로 실행됩니다.

예를 들어, GitHub Actions workflow 파일에서:

on: [push]
jobs:
  python-version:
    runs-on: ubuntu-latest
    container: python:latest
    steps:
      - run: python --version
  java-version:
    if: contains( github.ref, 'staging')
    runs-on: ubuntu-latest
    container: openjdk:latest
    steps:
      - run: java -version

이 예시는 서로 다른 컨테이너 이미지를 사용하여 Python 잡과 Java 잡을 병렬로 실행합니다. Java 잡은 staging 브랜치가 변경될 때만 실행됩니다.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

python-version:
  image: python:latest
  script:
    - python --version

java-version:
  image: openjdk:latest
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
  script:
    - java -version

이 경우, 잡을 병렬로 실행하기 위한 추가 구성이 필요하지 않습니다. 잡은 기본적으로 병렬로 실행되며, 충분한 러너가 있다고 가정하면 각각 다른 러너에서 실행됩니다. Java 잡은 staging 브랜치가 변경될 때만 실행되도록 설정됩니다.

매트릭스#

GitLab과 GitHub 모두에서 매트릭스를 사용하여 단일 파이프라인에서 잡을 여러 번 병렬로 실행할 수 있지만, 잡의 각 인스턴스에 대해 다른 변수 값을 사용합니다.

예를 들어, GitHub Actions workflow 파일에서:

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Building $PLATFORM for $ARCH"
    strategy:
      matrix:
        platform: [linux, mac, windows]
        arch: [x64, x86]
  test:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Testing $PLATFORM for $ARCH"
    strategy:
      matrix:
        platform: [linux, mac, windows]
        arch: [x64, x86]
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying $PLATFORM for $ARCH"
    strategy:
      matrix:
        platform: [linux, mac, windows]
        arch: [x64, x86]

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

stages:
  - build
  - test
  - deploy

.parallel-hidden-job:
  parallel:
    matrix:
      - PLATFORM: [linux, mac, windows]
        ARCH: [x64, x86]

build-job:
  extends: .parallel-hidden-job
  stage: build
  script:
    - echo "Building $PLATFORM for $ARCH"

test-job:
  extends: .parallel-hidden-job
  stage: test
  script:
    - echo "Testing $PLATFORM for $ARCH"

deploy-job:
  extends: .parallel-hidden-job
  stage: deploy
  script:
    - echo "Deploying $PLATFORM for $ARCH"

트리거#

GitHub Actions에서는 워크플로우에 트리거를 추가해야 합니다. GitLab은 Git과 긴밀하게 통합되어 있으므로 트리거를 위한 SCM 폴링 옵션이 필요하지 않지만, 필요한 경우 잡별로 구성할 수 있습니다.

GitHub Actions 구성 예시:

on:
  push:
    branches:
      - main

동등한 GitLab CI/CD 구성은 다음과 같습니다:

rules:
  - if: '$CI_COMMIT_BRANCH == main'

파이프라인은 Cron 구문을 사용하여 스케줄링할 수도 있습니다.

컨테이너 이미지#

GitLab을 사용하면 image 키워드를 사용하여 별도의 격리된 Docker 컨테이너에서 CI/CD 잡을 실행할 수 있습니다.

예를 들어, GitHub Actions workflow 파일에서:

jobs:
  update:
    runs-on: ubuntu-latest
    container: alpine:latest
    steps:
      - run: apk update

이 예시에서 apk update 명령은 alpine:latest 컨테이너에서 실행됩니다.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

update-job:
  image: alpine:latest
  script:
    - apk update

GitLab은 컨테이너 이미지를 호스팅하기 위해 모든 프로젝트에 컨테이너 레지스트리를 제공합니다. 컨테이너 이미지는 GitLab CI/CD 파이프라인에서 직접 빌드하고 저장할 수 있습니다.

예를 들어:

stages:
  - build

build-image:
  stage: build
  variables:
    IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $IMAGE .
    - docker push $IMAGE

변수#

variables 키워드를 사용하여 런타임에 다른 CI/CD 변수를 정의할 수 있습니다. 파이프라인에서 구성 데이터를 재사용해야 할 때 변수를 사용합니다. 변수는 전역적으로 또는 잡별로 정의할 수 있습니다.

예를 들어, GitHub Actions workflow 파일에서:

env:
  NAME: "fern"

jobs:
  english:
    runs-on: ubuntu-latest
    env:
      Greeting: "hello"
    steps:
      - run: echo "$GREETING $NAME"
  spanish:
    runs-on: ubuntu-latest
    env:
      Greeting: "hola"
    steps:
      - run: echo "$GREETING $NAME"

이 예시에서 변수는 잡에 대해 다른 출력을 제공합니다.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

default:
  image: ubuntu-latest

variables:
  NAME: "fern"

english:
  variables:
    GREETING: "hello"
  script:
    - echo "$GREETING $NAME"

spanish:
  variables:
    GREETING: "hola"
  script:
    - echo "$GREETING $NAME"

변수는 또한 CI/CD 설정 아래의 GitLab UI를 통해 설정할 수 있으며, 여기서 변수를 보호하거나 마스킹할 수 있습니다. 마스킹된 변수는 잡 로그에서 숨겨지며, 보호된 변수는 보호된 브랜치 또는 태그의 파이프라인에서만 접근할 수 있습니다.

예를 들어, GitHub Actions workflow 파일에서:

jobs:
  login:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY }}
    steps:
      - run: my-login-script.sh "$AWS_ACCESS_KEY"

AWS_ACCESS_KEY 변수가 GitLab 프로젝트 설정에 정의된 경우, 동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

login:
  script:
    - my-login-script.sh $AWS_ACCESS_KEY

또한 GitHub Actions와 GitLab CI/CD는 파이프라인 및 저장소와 관련된 데이터를 포함하는 기본 제공 변수를 제공합니다.

조건문#

새 파이프라인이 시작되면 GitLab은 파이프라인 구성을 확인하여 해당 파이프라인에서 실행할 잡을 결정합니다. rules 키워드를 사용하여 변수 상태 또는 파이프라인 유형과 같은 조건에 따라 잡을 실행하도록 구성할 수 있습니다.

예를 들어, GitHub Actions workflow 파일에서:

jobs:
  deploy_staging:
    if: contains( github.ref, 'staging')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to staging server"

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  rules:
    - if: '$CI_COMMIT_BRANCH == staging'

러너#

러너는 잡을 실행하는 서비스입니다. GitLab.com을 사용하는 경우, 자체 셀프 매니지드 러너를 프로비저닝하지 않고도 인스턴스 러너 플릿을 사용하여 잡을 실행할 수 있습니다.

러너에 대한 몇 가지 주요 세부 정보:

• 러너는 인스턴스 전체, 그룹 또는 단일 프로젝트 전용으로 구성할 수 있습니다.
• tags 키워드를 사용하여 더 세밀하게 제어하고 러너를 특정 잡과 연결할 수 있습니다. 예를 들어, 전용되거나 더 강력하거나 특정 하드웨어가 필요한 잡에 태그를 사용할 수 있습니다.
• GitLab에는 러너 자동 확장이 있습니다. 자동 확장을 사용하여 필요한 경우에만 러너를 프로비저닝하고 필요하지 않을 때는 축소합니다.

예를 들어, GitHub Actions workflow 파일에서:

linux_job:
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello, $USER"

windows_job:
  runs-on: windows-latest
  steps:
    - run: echo "Hello, %USERNAME%"

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

linux_job:
  stage: build
  tags:
    - linux-runners
  script:
    - echo "Hello, $USER"

windows_job:
  stage: build
  tags:
    - windows-runners
  script:
    - echo "Hello, %USERNAME%"

아티팩트#

GitLab에서는 모든 잡이 artifacts 키워드를 사용하여 잡이 완료될 때 저장할 아티팩트 세트를 정의할 수 있습니다. 아티팩트는 이후 잡에서 사용할 수 있는 파일입니다.

예를 들어, GitHub Actions workflow 파일에서:

on: [push]
jobs:
  generate_cat:
    steps:
      - run: touch cat.txt
      - run: echo "meow" > cat.txt
      - uses: actions/upload-artifact@v3
        with:
          name: cat
          path: cat.txt
          retention-days: 7
  use_cat:
    needs: [generate_cat]
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: cat
      - run: cat cat.txt

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

stage:
  - generate
  - use

generate_cat:
  stage: generate
  script:
    - touch cat.txt
    - echo "meow" > cat.txt
  artifacts:
    paths:
      - cat.txt
    expire_in: 1 week

use_cat:
  stage: use
  script:
    - cat cat.txt

캐싱#

캐시는 잡이 하나 이상의 파일을 다운로드하고 향후 더 빠른 접근을 위해 저장할 때 생성됩니다. 동일한 캐시를 사용하는 후속 잡은 파일을 다시 다운로드할 필요가 없으므로 더 빨리 실행됩니다. 캐시는 러너에 저장되고 분산 캐시가 활성화된 경우 S3에 업로드됩니다.

예를 들어, GitHub Actions workflow 파일에서:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - run: echo "This job uses a cache."
    - uses: actions/cache@v3
      with:
        path: binaries/
        key: binaries-cache-$CI_COMMIT_REF_SLUG

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

템플릿#

GitHub에서 액션은 자주 반복해야 하는 복잡한 작업의 집합으로, CI/CD 파이프라인을 다시 정의하지 않고 재사용할 수 있도록 저장됩니다. GitLab에서 액션에 해당하는 것은 include 키워드로, 이를 통해 GitLab에 내장된 템플릿 파일을 포함한 다른 파일의 CI/CD 파이프라인을 추가할 수 있습니다.

GitHub Actions 구성 예시:

- uses: hashicorp/setup-terraform@v2.0.3

동등한 GitLab CI/CD 구성은 다음과 같습니다:

include:
  - template: Terraform.gitlab-ci.yml

이 예시에서 setup-terraform GitHub 액션과 Terraform.gitlab-ci.yml GitLab 템플릿은 정확히 일치하지 않습니다. 이 두 예시는 복잡한 구성을 재사용할 수 있는 방법을 보여주기 위한 것입니다.

보안 스캐닝 기능#

GitLab은 SLDC의 모든 부분에서 취약점을 감지하기 위해 다양한 보안 스캐너를 기본 제공합니다. 템플릿을 사용하여 GitLab CI/CD 파이프라인에 이러한 기능을 추가할 수 있습니다.

예를 들어 파이프라인에 SAST 스캐닝을 추가하려면 .gitlab-ci.yml에 다음을 추가합니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

CI/CD 변수를 사용하여 보안 스캐너의 동작을 사용자 지정할 수 있습니다. 예를 들어 SAST 스캐너를 사용합니다.

시크릿 관리#

흔히 "시크릿"이라고 불리는 권한 정보는 CI/CD 워크플로우에서 필요한 민감한 정보 또는 자격 증명입니다. 시크릿을 사용하여 도구, 애플리케이션, 컨테이너 및 클라우드 네이티브 환경에서 보호된 리소스나 민감한 정보를 잠금 해제할 수 있습니다.

GitLab에서의 시크릿 관리를 위해 외부 서비스에 대한 지원되는 통합 중 하나를 사용할 수 있습니다. 이러한 서비스는 GitLab 프로젝트 외부에 시크릿을 안전하게 저장하지만, 서비스에 대한 구독이 필요합니다.

GitLab은 OIDC를 지원하는 다른 서드파티 서비스에 대한 OIDC 인증도 지원합니다.

또한 CI/CD 변수에 저장하여 잡에 자격 증명을 제공할 수 있지만, 일반 텍스트로 저장된 시크릿은 우발적인 노출에 취약합니다. 민감한 정보는 항상 마스킹 및 보호 변수에 저장해야 하며, 이는 일부 위험을 완화합니다.

또한 프로젝트에 접근 권한이 있는 모든 사용자에게 공개되는 .gitlab-ci.yml 파일에 변수로 시크릿을 저장하지 마십시오. 민감한 정보를 변수에 저장하는 것은 프로젝트, 그룹 또는 인스턴스 설정에서만 해야 합니다.

CI/CD 변수의 안전성을 향상시키려면 보안 가이드라인을 검토하십시오.

마이그레이션 계획 및 수행#

다음 권장 단계 목록은 이 마이그레이션을 신속하게 완료할 수 있었던 조직을 관찰한 후 작성되었습니다.

마이그레이션 계획 수립#

마이그레이션을 시작하기 전에 마이그레이션 준비를 위해 마이그레이션 계획을 수립해야 합니다.

사전 조건#

마이그레이션 작업을 시작하기 전에 다음을 먼저 수행해야 합니다:

1. GitLab에 익숙해지기.
   • 주요 GitLab CI/CD 기능에 대해 읽어보세요.
   • 첫 번째 GitLab 파이프라인 생성 및 정적 사이트를 빌드, 테스트, 배포하는 더 복잡한 파이프라인 생성 튜토리얼을 따라하세요.
   • CI/CD YAML 구문 레퍼런스를 검토하세요.
2. GitLab 설정 및 구성하기.
3. GitLab 인스턴스 테스트하기.
   • 공유 GitLab.com 러너를 사용하거나 새 러너를 설치하여 러너가 사용 가능한지 확인하세요.

마이그레이션 단계#

1. GitHub에서 GitLab으로 프로젝트 마이그레이션:
   • (권장) GitHub Importer를 사용하여 외부 SCM 제공업체에서 대량 가져오기를 자동화할 수 있습니다.
   • URL로 저장소를 가져올 수 있습니다.
2. 각 프로젝트에 .gitlab-ci.yml을 만듭니다.
3. GitHub Actions 잡을 GitLab CI/CD 잡으로 마이그레이션하고 결과가 머지 리퀘스트에 직접 표시되도록 구성합니다. 이 작업은 제공된 Agent Skill을 사용하여 자동화할 수 있습니다.
4. 클라우드 배포 템플릿, 환경, Kubernetes용 GitLab 에이전트를 사용하여 배포 잡을 마이그레이션합니다.
5. CI/CD 구성을 여러 프로젝트에서 재사용할 수 있는지 확인한 다음 CI/CD 컴포넌트를 만들고 공유합니다.
6. 파이프라인 효율성 문서를 확인하여 GitLab CI/CD 파이프라인을 더 빠르고 효율적으로 만드는 방법을 알아보세요.

추가 리소스#

• 동영상: GitHub에서 GitLab으로 마이그레이션하는 방법 (Actions 포함)
• 블로그: 간편한 GitHub에서 GitLab 마이그레이션

여기에서 답을 찾지 못한 질문이 있는 경우, GitLab 커뮤니티 포럼이 훌륭한 리소스가 될 수 있습니다.