GitHub Actions에서 GitLab로 마이그레이션

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

GitHub Actions에서 GitLab CI/CD로 마이그레이션하는 경우 GitHub Action 워크플로우를 복제하고 향상시킬 수 있는 CI/CD 파이프라인을 생성할 수 있습니다.

주요 유사점과 차이점

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

CI/CD 기능이 프로젝트 리포지토리에 저장된 코드에 직접 액세스할 수 있습니다.
YAML로 작성된 파이프라인 구성은 프로젝트 리포지토리에 저장됩니다.
파이프라인은 구성 가능하며 다양한 단계에서 실행할 수 있습니다.
각 작업은 서로 다른 컨테이너 이미지를 사용할 수 있습니다.

추가로, 두 시스템 간에는 몇 가지 중요한 차이점이 있습니다:

GitHub에는 3rd-party 액션을 다운로드하기 위한 마켓플레이스가 있으며, 이는 추가적인 지원 또는 라이센스가 필요할 수 있습니다.
Self-managed GitLab 인스턴스는 수평 및 수직 스케일링 모두를 지원하는 반면, GitHub Enterprise Server는 수직 스케일링만 지원합니다.
GitLab은 모든 기능을 자체적으로 유지 관리 및 지원하며, 일부 3rd-party 통합은 템플릿을 통해 접근할 수 있습니다.
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 키워드를 사용하여 구성됩니다.

GitHub	GitLab	설명
`env`	`variables`	`env`는 워크플로우, 작업 또는 단계에서 설정된 변수를 정의합니다. GitLab은 `variables`를 사용하여 CI/CD 변수를 전역 또는 작업 수준에서 정의합니다. UI에서 변수도 추가할 수 있습니다.
`jobs`	`stages`	`jobs`는 워크플로우에서 실행되는 모든 작업을 그룹화합니다. GitLab은 `stages`를 사용하여 작업을 그룹화합니다.
`on`	해당 없음	`on`은 워크플로우가 트리거되는 시점을 정의합니다. GitLab은 Git과 긴밀하게 통합되어 있어 트리거를 위한 SCM 폴링 옵션이 필요하지 않지만 필요할 경우 작업별로 구성할 수 있습니다.
`run`	해당 없음	작업에서 실행할 명령입니다. GitLab은 `script` 키워드 아래 YAML 배열을 사용하여 실행할 각 명령에 대해 하나의 항목을 정의합니다.
`runs-on`	`tags`	`runs-on`은 작업이 실행해야 하는 GitHub 러너를 정의합니다. GitLab은 `tags`를 사용하여 러너를 선택합니다.
`steps`	`script`	`steps`는 작업에서 실행되는 모든 단계를 그룹화합니다. GitLab은 `script`를 사용하여 작업에서 실행되는 모든 명령을 그룹화합니다.
`uses`	`include`	`uses`는 `step`에 추가할 GitHub Action을 정의합니다. GitLab은 `include`를 사용하여 다른 파일의 구성을 작업에 추가합니다.

일반적인 구성

이 섹션에서는 일반적으로 사용되는 CI/CD 구성을 다루며, GitHub Actions에서 GitLab CI/CD로 전환하는 방법을 보여줍니다.

GitHub Action workflows는 특정 이벤트가 발생할 때 트리거되는 자동화된 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에서는 별도의 격리된 Docker 컨테이너에서 CI/CD 작업을 실행할 수 있습니다 image 키워드를 사용하여.

예를 들어, 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

변수

GitLab에서는 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"

변수는 GitLab UI를 통해 CI/CD 설정에서 설정할 수도 있으며, 여기에서 변수를 보호하거나 마스킹할 수 있습니다. 마스킹된 변수는 작업 로그에서 숨겨지고, 보호된 변수는 보호된 브랜치나 태그에 대한 파이프라인에서만 액세스할 수 있습니다.

예를 들어, 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에서 Action은 자주 반복해야 하는 복잡한 작업 집합이며 CI/CD 파이프라인을 재정의하지 않고 재사용 가능한 형태로 저장됩니다. GitLab에서 Action과 동등한 것은 include 키워드로, 이는 다른 파일에서 CI/CD 파이프라인을 추가할 수 있게 해주며, GitLab에 내장된 템플릿 파일들을 포함합니다.

샘플 GitHub Actions 구성:

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

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

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

이 예제에서 setup-terraform GitHub Action과 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를 지원하는 기타 제3자 서비스에 대한 OIDC 인증도 지원합니다.

또한, CI/CD 변수를 통해 작업에 자격 증명을 사용할 수 있도록 저장할 수 있지만, 평문으로 저장된 비밀은 우발적인 노출에 취약합니다. 민감한 정보는 항상 마스킹된 및 보호된 변수에 저장해야 하며, 이는 일부 위험을 완화합니다.

또한, .gitlab-ci.yml 파일에 비밀을 변수로 저장하지 않도록 하세요. 이는 프로젝트에 접근할 수 있는 모든 사용자에게 공개됩니다. 민감한 정보를 변수에 저장하는 것은 프로젝트, 그룹 또는 인스턴스 설정에서만 수행해야 합니다.

보안 가이드라인을 검토하여 CI/CD 변수의 안전성을 개선하세요.

마이그레이션 계획 및 수행

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

마이그레이션 계획 만들기

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

전제 조건

마이그레이션 작업을 시작하기 전에 먼저:

GitLab에 익숙해지세요.
- 주요 GitLab CI/CD 기능에 대해 읽어보세요.
- 첫 번째 GitLab 파이프라인 및 보다 복잡한 파이프라인을 만드는 튜토리얼을 따라해 보세요. 이들은 정적 사이트를 빌드, 테스트 및 배포합니다.
- CI/CD YAML 구문 참고를 검토하세요.
GitLab을 설정하고 구성하세요.
GitLab 인스턴스를 테스트하세요.
- 러너가 사용 가능하도록 하세요. 공유 GitLab.com 러너를 사용하거나 새로운 러너를 설치하세요.

마이그레이션 단계

GitHub에서 GitLab으로 프로젝트를 마이그레이션하세요:
- (권장) GitHub Importer를 사용하여 외부 SCM 제공업체에서 대량으로 가져오는 작업을 자동화할 수 있습니다.
- URL로 리포지토리 가져오기를 사용할 수 있습니다.
각 프로젝트에 .gitlab-ci.yml 파일을 만드세요.
GitHub Actions 작업을 GitLab CI/CD 작업으로 마이그레이션하고, 이를 통해 병합 요청에서 결과를 직접 표시하도록 구성하세요.
클라우드 배포 템플릿, 환경, Kubernetes용 GitLab 에이전트를 사용하여 배포 작업을 마이그레이션하세요.
다양한 프로젝트에서 재사용할 수 있는 CI/CD 구성이 있는지 확인한 후, CI/CD 템플릿을 생성하고 공유하세요.
파이프라인 효율성 문서를 확인하여 GitLab CI/CD 파이프라인을 더 빠르고 효율적으로 만드는 방법을 배우세요.

추가 리소스

여기에서 답변되지 않은 질문이 있는 경우, GitLab 커뮤니티 포럼이 유용한 리소스가 될 수 있습니다.

GitHub Actions에서 GitLab로 마이그레이션

주요 유사점과 차이점

기능 및 개념 비교

구성 파일

GitHub Actions 워크플로우 문법

일반적인 구성

작업

병렬

매트릭스

트리거

컨테이너 이미지

변수

조건문

러너

아티팩트

캐싱

템플릿

보안 스캔 기능

비밀 관리

마이그레이션 계획 및 수행

마이그레이션 계획 만들기

전제 조건

마이그레이션 단계

추가 리소스

도움말

기능 사용 가능성과 제품 평가판

도움받기