GitLab: CI/CD

GitLab CI/CD の使い方

👋 Stackheroドキュメントへようこそ！

Stackheroは、チーム向けに設計された、すぐに使えるGitLabクラウドソリューションを提供しています。高速・安全・スケーラブルな環境をお求めの方に最適です：

ユーザー数、リポジトリ、データ転送量、CI/CD処理時間が無制限で、柔軟性を最大限に確保できます。

ワンクリックで簡単にアップデートでき、ダウンタイムなしで常に最新の環境を維持できます。

HTTPSで保護されたカスタムドメイン名（例：https://git.your-company.com）により、プロフェッショナルなブランディングとセキュリティを実現します。

プライベートかつ専用インフラ上での安定したパフォーマンスと強固なセキュリティ。他の利用者の影響を受けず、完全な分離環境を提供します。

ホスティング場所は🇪🇺 ヨーロッパまたは🇺🇸 USAから選択可能。コンプライアンスやレイテンシー要件に合わせてお選びいただけます。

すぐに利用を開始し、コード開発に集中できます。StackheroのGitLabクラウドホスティングソリューションは、約5分でご利用可能です。

はじめに

GitLab CI/CD は、バージョン管理とコラボレーションのための人気のオープンソースプラットフォームである GitLab に統合された強力な機能です。このツールを利用することで、ソフトウェアのビルド、テスト、デプロイといった重要な工程を効率化・自動化でき、高品質なアプリケーションをより迅速かつ信頼性高く提供できます。

例えば、GitLab CI/CD を使えば、GitLab リポジトリに新しいコミットがプッシュされるたびに自動でユニットテストを実行するよう設定できます。これらのテストに合格すると、コードはビルドされ、さらに検証するためにステージング環境へデプロイされます。すべてのステージングテストをクリアした後、システムはコードを本番環境へ昇格させ、エンドユーザーが利用できるようにします。

GitLab CI/CD の大きな特徴の一つは、GitLab 本体との高い統合性です。これにより、プロジェクトリポジトリ内で直接 CI/CD パイプラインを定義・管理でき、ワークフロー全体のオーケストレーションや進捗管理が容易になります。

GitLab CI/CD は多様なプログラミング言語、フレームワーク、ツールに対応しており、さまざまなプロジェクトに柔軟に適用できます。パイプラインはカスタマイズ可能で、ビルド、テスト、複数環境へのデプロイなど、CI/CD プロセスの各ステージをニーズに合わせて調整できます。

まとめると、GitLab CI/CD はソフトウェアデリバリーの自動化と最適化を目的とした包括的なソリューションです。開発者はコードの作成や改善に集中でき、運用面のタスクはプラットフォームが効率的に管理します。

GitLab CI で Docker イメージをビルドする方法

プロジェクトリポジトリに Dockerfile が含まれている場合、Docker イメージのビルド、実行、必要に応じてレジストリへの公開まで自動化できます。

ステップ 1: Docker in Docker (DinD) サポートを有効化する

まず、Stackhero ダッシュボードで「Docker in Docker（DinD）」サポートを有効にしてください。

DinD サポートを有効にすると、特にユーザー同士のプロジェクト隔離やアクセス制御を重視する場合、セキュリティリスクが発生します。

ステップ 2: GitLab CI パイプラインを設定する

次に、gitlab-ci.yml ファイルを編集し、DinD を利用して Dockerfile をビルドするパイプライン設定を追加します。以下はその一例です：

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # docker CLI を Docker-in-Docker サービス（非 TLS ポート）に向けます。
    # DOCKER_HOST の重要性については下記の注意を参照してください。
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # "my-docker-image" をご希望のイメージ名に置き換えてください：
    - docker build -t my-docker-image .
    # 必要に応じて、Docker イメージのテストも可能です：
    # - docker run my-docker-image /script/to/run/tests

docker:29-dind サービスはジョブの横で Docker デーモンを起動し、DOCKER_HOST で docker CLI にそのデーモンを使うよう指示します。docker:dind サービスを宣言する際は必ず DOCKER_HOST を設定してください。 省略すると CLI は別のデーモンに静かに接続し、サービスが誤設定でもビルドが成功してしまい、本来の問題が隠れてしまいます。DOCKER_TLS_CERTDIR: "" により、ジョブ内部ネットワークの非 TLS ポート 2375 を利用します。

よりシンプルな方法として、services ブロックと両方の変数を省略することも可能です。Stackhero の runner では、マウントされたソケット経由で Docker デーモンがすでに利用可能なため、docker build だけでそのまま動作します。

GitLab CI で Docker イメージをビルドする詳細については、公式 GitLab ドキュメントをご参照ください。

Testcontainers でテストを実行する

テストスイートで Testcontainers（テスト実行中に実際のサービス（データベースやメッセージブローカーなど）を一時的な Docker コンテナとして起動するライブラリ）を利用している場合、上記の設定でそのまま対応できます。docker:29-dind サービスと両方の変数を維持してください。Testcontainers は DOCKER_HOST を使って Docker デーモンにアクセスし、自身が起動するコンテナに接続しますので、追加の設定は不要です。

DOCKER_HOST の設定漏れは、CI での Testcontainers の失敗原因として最も多いものです。この場合、ライブラリは runner によってマウントされた Docker ソケットを使おうとし、自身のテストコンテナに接続できず、Ryuk ヘルパーコンテナのタイムアウトとして現れることが一般的です。