Github ActionsからGitlab CI/CDに移行

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 の設定は、特定のキーワードを使用してワークフロー YAML ファイルに定義されます。GitLab CI/CD も同様の機能を持ち、通常 YAML キーワードで設定されます。

GitHub	GitLab	説明
env	variables	env はワークフロー、ジョブ、またはステップで設定される変数を定義します。GitLab はグローバルまたはジョブレベルで CI/CD 変数を定義するために変数を使用します。変数は UI に追加することもできます。
jobs	stages	jobs はワークフローで実行されるすべてのジョブをグループ化します。GitLab はジョブをグループ化するために stages を使用します。
on	該当なし	on はワークフローがトリガーされるときの条件を定義します。GitLab は Git と緊密に統合されているため、トリガーの SCM ポーリングオプションは必要ありませんが、必要に応じてジョブごとに設定できます。
run	該当なし	ジョブで実行するコマンドを定義します。GitLab は script キーワードの下に YAML 配列を使用し、実行する各コマンドのエントリを定義します。
runs-on	tags	runs-on はジョブを実行する GitHub ランナーを定義します。GitLab はランナーを選択するためにタグを使用します。
steps	script	steps はジョブで実行されるすべてのステップをグループ化します。GitLab は script を使用して、ジョブで実行されるすべてのコマンドをグループ化します。
uses	include	uses はステップに追加する GitHub Action を定義します。GitLab は include を使用して、他のファイルからジョブに設定を追加します。

一般的な設定

このセクションでは、よく使用される CI/CD 設定について説明し、GitHub Actions から GitLab CI/CD への変換方法を示します。

GitHub Actions ワークフローは、例えば新しいコミットをプッシュしたときなど、特定のイベントが発生したときにトリガーされる自動化された CI/CD ジョブを生成します。GitHub Actions のワークフローは、リポジトリのルートにある .github/workflows ディレクトリに定義された YAML ファイルです。GitLab の同等のものは .gitlab-ci.yml 設定ファイルで、同じくリポジトリのルートディレクトリにあります。

Jobs

Jobsは、特定の結果を達成するために一連のコマンドを実行するプロセスです。例えば、コンテナをビルドしてプロダクションにデプロイするなどです。

例えば、次の GitHub Actions ワークフローはコンテナをビルドしてからプロダクションにデプロイします。このジョブは連続して実行され、デプロイジョブはビルドジョブに依存します。

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 であることを要求します。
• ビルドした実行ファイルアーティファクトを使用します。

同等の 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 のワークフローファイルでは：

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 ブランチが変更された場合にのみ実行されます。

Matrix

GitLab と GitHub の両方で、matrix を使用して、単一のパイプラインで異なる変数値を持つ複数のジョブを並列に実行できます。

例えば、GitHub Actions のワークフローファイルでは：

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"

Trigger

GitHub Actions では、ワークフローにトリガーを追加する必要があります。GitLab は Git と緊密に統合されているため、トリガーの SCM ポーリングオプションは不要ですが、必要に応じてジョブごとに設定できます。

サンプル GitHub Actions 設定：

on:
  push:
    branches:
      - main

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

パイプラインは Cron 構文を使用してスケジュール設定することもできます。

Container Images

GitLab を使用すると、image キーワードを使用して、CI/CD ジョブを個別の独立した Docker コンテナで実行できます。

例えば、GitHub Actions のワークフローファイルでは：

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

GitLab では、variables キーワードを使用して、実行時に異なる CI/CD 変数を定義します。パイプラインで設定データを再利用する必要がある場合に variables を使用します。変数はグローバルに、またはジョブごとに定義できます。

例えば、GitHub Actions のワークフローファイルでは：

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 のワークフローファイルでは：

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 は、パイプラインおよびリポジトリに関連するデータを含む組み込み変数を提供します。

Conditionals

新しいパイプラインが開始されると、GitLab はパイプライン設定をチェックし、そのパイプラインで実行するジョブを決定します。rules キーワードを使用して、変数のステータスやパイプラインの種類などの条件に応じてジョブを実行するように設定できます。

例えば、GitHub Actions のワークフローファイルでは：

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'

Runners

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

ランナーに関する主要な詳細情報：

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

例えば、GitHub Actions のワークフローファイルでは：

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%"

Artifacts

GitLab では、任意のジョブで artifacts キーワードを使用して、ジョブが完了したときに保存されるアーティファクトのセットを定義できます。アーティファクトは後のジョブで使用できるファイルです。

例えば、GitHub Actions のワークフローファイルでは：

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 ファイルは以下のようになります：

stages:
  - 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

Caching

キャッシュは、ジョブが一つまたは複数のファイルをダウンロードし、それを将来のより高速なアクセスのために保存するときに作成されます。同じキャッシュを使用する後続のジョブはファイルを再ダウンロードする必要がないため、より迅速に実行されます。キャッシュはランナー上に保存され、分散キャッシュが有効化されている場合は S3 にアップロードされます。

例えば、GitHub Actions のワークフローファイルでは：

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/

テンプレート

Templates

GitHub では、アクションは頻繁に繰り返す必要のある複雑なタスクのセットであり、CI/CD パイプラインを再定義せずに再利用できるように保存されます。GitLab では、アクションに相当するものは 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 アクションと Terraform.gitlab-ci.yml GitLab テンプレートは完全には一致しません。これらの二つの例は、複雑な設定を再利用する方法を示すためのものです。

セキュリティスキャン機能
GitLab は、SDLC のすべての部分で脆弱性を検出するためのさまざまなセキュリティスキャナーを標準で提供します。これらの機能を GitLab CI/CD パイプラインに追加するには、テンプレートを使用します。

例えば、SAST スキャンをパイプラインに追加するには、以下を .gitlab-ci.yml に追加します：

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

SAST スキャナーなどのセキュリティスキャナーの動作は、CI/CD 変数を使用してカスタマイズできます。

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

GitLab は、SDLC のすべての部分で脆弱性を検出するためのさまざまなセキュリティスキャナーを標準で提供します。これらの機能を GitLab CI/CD パイプラインに追加するには、テンプレートを使用します。

例えば、SAST スキャンをパイプラインに追加するには、以下を .gitlab-ci.yml に追加します：

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

SAST スキャナーなどのセキュリティスキャナーの動作は、CI/CD 変数を使用してカスタマイズできます。

秘密管理

「秘密」とも呼ばれる特権情報は、CI/CD ワークフローで必要となる機密情報または認証情報です。秘密を使用して、ツール、アプリケーション、コンテナ、クラウドネイティブ環境の保護されたリソースや機密情報にアクセスすることができます。

GitLab での秘密管理には、サポートされている外部サービスとの統合を使用できます。これらのサービスは、GitLab プロジェクトの外部に秘密を安全に保存しますが、サービスのサブスクリプションが必要です：

• HashiCorp Vault
• Azure Key Vault

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 ジョブに移行し、マージリクエストで結果を直接表示するように構成します。
4. クラウドデプロイメントテンプレート、環境、GitLab エージェントを使用してデプロイメントジョブを移行します。
5. さまざまなプロジェクトで再利用できる CI/CD 設定があるか確認し、CI/CD テンプレートを作成して共有します。
6. GitLab CI/CD パイプラインを高速かつ効率的にする方法について、パイプライン効率に関するドキュメントを確認します。

追加リソース

• ビデオ: GitHub から GitLab への移行とアクションの実装方法
• ブログ: 簡単な方法で GitHub から GitLab への移行
• ここに記載されていない質問がある場合は、GitLab コミュニティフォーラムが有用なリソースとなる場合があります。

訳したページ

Migrating from GitHub Actions | GitLab

GitLab product documentation.

docs.gitlab.com