GitHub Actionsから移行する

GitHub ActionsからGitLab CI/CDへの移行を行う場合、GitHub Actionワークフローをレプリケートするだけでなく、強化するCI/CDパイプラインを作成できます。

主な類似点と相違点

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コンテナイメージを使用します。
• コードをビルドするジョブを実行します。
  • ビルド実行ファイルをアーティファクトとして保存します。
• 2番目のジョブを実行して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

この場合、ジョブを並列実行させるための追加の設定は必要ありません。ジョブはデフォルトで並列実行され、すべてのジョブに対して十分なRunnerがある場合、それぞれ異なるRunnerで実行されます。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

変数

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'

Runner

Runnerはジョブを実行するサービスです。GitLab.comを使用している場合、独自のセルフマネージドRunnerをプロビジョニングすることなくジョブを実行するために、インスタンスRunnerフリートを使用できます。

Runnerに関するいくつかの主要な詳細:

• Runnerは、インスタンス、グループ全体で共有されるように設定したり、単一のプロジェクト専用にしたりできます。
• よりきめ細かな制御のためにtagsキーワードを使用し、Runnerを特定のジョブと関連付けることができます。たとえば、専用の、より強力な、または特定のハードウェアを必要とするジョブにはタグを使用できます。
• GitLabにはオートスケール機能があります。オートスケールを使用して、必要なときにのみRunnerをプロビジョニングし、不要なときにスケールダウンします。

たとえば、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では、任意のジョブがアーティファクトキーワードを使用して、ジョブの完了時に保存するアーティファクトのセットを定義できます。アーティファクトは、後のジョブで使用できるファイルです。

たとえば、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

キャッシュ

A キャッシュは、ジョブが1つ以上のファイルをダウンロードし、将来のアクセスを高速化するためにそれらを保存するときに作成されます。同じキャッシュを使用する後続のジョブは、ファイルを再度ダウンロードする必要がないため、より高速に実行されます。キャッシュはRunnerに保存され、分散キャッシュが有効になっている場合は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テンプレートは正確には一致しません。これらの2つの例は、複雑な設定をいかに再利用できるかを示すものです。

セキュリティスキャン機能

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 Runnerを使用するか、新しいRunnerをインストールして、Runnerが利用可能であることを確認します。

移行ステップ

1. GitHubからGitLabへのプロジェクトを移行します:
   • (推奨) 外部SCMプロバイダからの大量のインポートを自動化するために、GitHubインポーターを使用できます。
   • URLでリポジトリをインポートできます。
2. 各プロジェクトに.gitlab-ci.ymlを作成します。
3. GitHub ActionsジョブをGitLab CI/CDジョブに移行し、マージリクエストに結果を直接表示するように設定します。
4. クラウドデプロイテンプレート 、環境 、およびKubernetes向けGitLabエージェントを使用して、デプロイメントジョブを移行します。
5. 異なるプロジェクト間で再利用できるCI/CD設定があるか確認し、CI/CDテンプレートを作成して共有します。
6. パイプライン効率性ドキュメントを確認して、GitLab CI/CDパイプラインをより高速で効率的にする方法を学びます。

追加リソース

• 動画: GitHubからGitLabへの移行方法（Actionsを含む）
• ブログ: GitHubからGitLabへの移行を簡単に

ここで回答されていない質問がある場合は、GitLabコミュニティフォーラムが優れたリソースとなりえます。