DUICUO

現在の場所： ホーム > 記事 > GitLab で CI/CD を実行するとどんな感じでしょうか? 素晴らしいですよ!

GitLab で CI/CD を実行するとどんな感じでしょうか? 素晴らしいですよ!

GitLab CI/CD は、継続的なソフトウェア開発のために GitLab に組み込まれたツールです。

  • 継続的インテグレーション（CI）
  • 継続的デリバリー（CD）
  • 継続的デプロイメント（CD）

継続的インテグレーションは、Gitリポジトリにホストされているアプリケーションコードベースに小さなコードチャンクをプッシュすることで機能します。コードがプッシュされるたびに、一連のスクリプトが実行され、コードの変更がビルド、テスト、検証された後、メインブランチにマージされます。

継続的デリバリーとデプロイメントは、本質的には CI のさらなるステップであり、アプリケーションがリポジトリのデフォルト ブランチにプッシュされるたびに、実稼働環境にデプロイできるようになります。

これらの方法により、開発サイクルにおけるバグやエラーの早期検出が可能になり、運用環境に展開されるすべてのコードがアプリケーション用に確立されたコード標準に準拠していることが保証されます。

GitLab CI/CDは、リポジトリのルートディレクトリにある`.gitlab-ci.yml`というファイルを使用して設定されます。このファイルに指定されたスクリプトは、GitLab Runnerによって実行されます。

GitLab CI/CD 入門

継続的ソフトウェア開発アプローチは、スクリプトの自動実行を基盤としており、アプリケーション開発中にエラーが発生する可能性を最小限に抑えます。新しいコードの開発からデプロイまで、人間の介入はほとんど、あるいは全く必要ありません。

小さな反復ごとにコードの変更を継続的に構築、テスト、展開することで、すでにバグや障害がある以前のバージョンに基づいて新しいコードを開発する可能性を減らします。

  • 継続的インテグレーション（CI）は、GitLabのGitリポジトリにコードが保存されているアプリケーションを想定しています。開発者は1日に複数回コード変更をプッシュします。リポジトリへのプッシュごとに、一連のスクリプトを作成してアプリケーションを自動的にビルドおよびテストすることで、バグの混入リスクを軽減できます。このプラクティスは継続的インテグレーションと呼ばれ、アプリケーションにコミットされたすべての変更（開発ブランチであっても）を自動的かつ継続的にビルドおよびテストし、導入された変更がアプリケーションに対して設定したすべてのテスト、ガイドライン、およびコードコンプライアンス基準を満たしていることを確認します。
  • 継続的デリバリーは、継続的インテグレーションをさらに一歩進めたものです。コード変更がコードベースにプッシュされるたびにアプリケーションがビルドおよびテストされるだけでなく、手動でトリガーされた場合でも、追加ステップとして継続的にデプロイされます。このアプローチでは、コード検査の自動化は保証されますが、変更のデリバリーを戦略的にトリガーするには手動による介入が必要になります。
  • 継続的デプロイメントは継続的デリバリーに似ていますが、手動でデプロイする必要がなく、自動的にデプロイするように設定できる点が異なります。つまり、アプリケーションは人間の介入なしにデプロイできます。

GitLab CI/CDの仕組み

GitLab CI/CD を使用するには、GitLab でホストされているアプリケーション コードベースが必要であり、ルート ディレクトリの .gitlab-ci.yml ファイルでビルド、テスト、およびデプロイメント スクリプトを指定する必要があります。

このファイルでは、実行するスクリプトの定義、依存関係の定義、順番に実行するコマンドと並列実行するコマンドの選択、アプリケーションのデプロイ場所の定義、スクリプトを自動で実行するか手動で実行するかの指定を行うことができます。

プロセスを視覚化するために、構成ファイルに追加されたすべてのスクリプトが、コンピューターの端末で実行されるコマンドと同じであると仮定します。

`.gitlab-ci.yml` をリポジトリに追加すると、GitLab はファイルを検出し、GitLab Runner というツールを使用してスクリプトを実行します。このツールはターミナルと同様に機能します。

これらのスクリプトはジョブにグループ化され、それらが組み合わさってパイプラインを形成します。非常にシンプルな .gitlab-ci.yml ファイルは次のようになります。

  1.  before_script:  
  2.  - apt-get install ruby​​gems ruby​​-dev -y  
  3. 実行テスト:  
  4. スクリプト：  
  5.  - ルビー - バージョン6

`before_script` プロパティは、実行前にアプリケーションの依存関係をインストールし、`run-test` というジョブはシステムの現在の Ruby バージョンを出力します。これらを組み合わせることで、リポジトリの任意のブランチにプッシュが行われるたびにトリガーされるパイプラインが形成されます。

GitLab CI/CD は、設定したジョブを実行するだけでなく、ターミナルに表示されるのと同じように、実行中に何が起こったかを表示することもできます。

アプリケーション用の戦略を作成すると、GitLab は定義に従ってパイプラインを実行します。パイプラインのステータスも GitLab に表示されます。

最後に、何か問題が発生した場合、すべての変更は簡単にロールバックできます。

基本的なCI/CDワークフロー

リモートリポジトリのブランチにコミットをプッシュすると、プロジェクト用に設定したCI/CDパイプラインがトリガーされます。GitLab CI/CDは、以下の方法でこれを実行します。

  • 自動化されたスクリプト（シリアルまたは並列）を実行し、コードを確認して承認を取得します。
    • アプリケーションをビルドしてテストする
    • ローカル マシンで表示するのと同じように、レビュー アプリを使用して各マージ リクエストの変更をプレビューします。
  • コードレビューと承認
  • 機能ブランチをデフォルト ブランチにマージし、変更を本番環境に自動的にデプロイします。
  • 問題が発生した場合、ロールバックを簡単に実行できます。

すべてのステップは GitLab UI を通じて視覚化されます。

基本的なCI/CDワークフローの深い理解

基本的なワークフローを詳しく見ていくと、次の図に示すように、DevOps ライフサイクルの各段階で GitLab で利用できる機能がわかります。

確認する：

  • 継続的インテグレーションを通じてアプリケーションの構築とテストを自動化します。
  • GitLab Code Quality を使用してソースコードの品質を分析します。
  • ブラウザのパフォーマンス テストを通じて、コード変更によるパフォーマンスへの影響を判断します。
  • コンテナ スキャン、依存関係スキャン、JUnit テストなどの一連のテストを実行します。
  • レビュー アプリを使用して変更をデプロイし、各ブランチでアプリケーションの変更をプレビューします。

パッケージ：

  • コンテナレジストリを使用してDockerイメージを保存する
  • NPM レジストリを使用して NPM パッケージを保存する
  • Maven リポジトリを使用して Maven アーティファクトを保存する
  • Conan リポジトリを使用して Conan パッケージを保存する

リリース：

  • 継続的デプロイメントは、アプリケーションの運用環境へのデプロイメントを自動化します。
  • 継続的なデリバリー。手動でクリックしてアプリケーションを本番環境にデプロイします。
  • GitLab Pages で静的ウェブサイトをデプロイする
  • 機能を単一の Pod にのみデプロイし、一定の割合のユーザーがカナリア デプロイメント (PS: つまり、カナリア デプロイメント) を通じて一時的にデプロイされた機能にアクセスできるようにします。
  • 機能フラグの後に機能をデプロイする
  • GitLab Releases を使用して任意の Git タグにリリースノートを追加します
  • デプロイ ボードを使用して、Kubernetes 上で実行されている各 CI 環境の現在の健全性とステータスを表示します。
  • Auto Deploy を使用して、Kubernetes クラスター内の本番環境にアプリケーションをデプロイします。

GitLab CI/CD を使用すると、次のことも可能になります。

  • Auto DevOps でアプリケーションのライフサイクル全体を簡単に構成できます
  • アプリケーションをさまざまな環境にデプロイする
  • 独自のGitLab Runnerをインストールする
  • パイプラインのスケジュール
  • セキュリティ テスト レポートを使用して、アプリケーションの脆弱性をチェックします。

GitLab CI/CD クイックスタート

.gitlab-ci.yml ファイルは、GitLab Runner に何をすべきかを指示します。シンプルなパイプラインは通常、ビルド、テスト、デプロイの 3 つのステージで構成されます。

パイプラインは、CI/CD > パイプライン ページにあります。

.gitlab-ci.yml ファイルを作成する

.gitlab-ci.yml ファイルを設定することで、CI にプロジェクトに対して何を行うかを伝えます。このファイルはリポジトリのルートディレクトリにあります。

リポジトリがプッシュを受信すると、GitLab はすぐに .gitlab-ci.yml ファイルを探し、ファイルの内容に基づいてランナーでジョブを開始します。

以下は Ruby プロジェクト構成の例です。

  1. 画像: "ruby:2.5" 
  2.   before_script:  
  3.  - apt-get update -qq \&\& apt-get install -y -qq sqlite3 libsqlite3-dev nodejs  
  4.  - ルビー -v  
  5.  - どのルビー 
  6.  - gem をインストール バンドラー --no-document  
  7.  - バンドルインストール --jobs \$\(nproc\) "\$\{FLAGS\[\@\]\}"   
  8.   rspec:  
  9. スクリプト：  
  10.  - バンドル実行rspec  
  11. ルボコップ:  
  12. スクリプト：  
  13.  - バンドル実行rubocop

上記の例では、rspecとrubocopという2つのジョブが定義されています。各ジョブの実行を開始する前に、before_scriptで指定されたコマンドをまず実行する必要があります。

.gitlab-ci.yml を GitLab にプッシュする

  1. git で .gitlab-ci.yml を追加します。  
  2.  git commit -m ".gitlab-ci.yml を追加"  
  3.  git プッシュ origin マスター

ランナーを設定する

GitLab では、ランナーが .gitlab-ci.yml で定義したジョブを実行します。

ランナーは、仮想マシン、物理マシン、Docker コンテナ、またはコンテナ クラスターになります。

GitLab は API 経由でランナーと通信するため、必要なのはランナーが配置されているマシンがインターネットにアクセスでき、GitLab サーバーにアクセスできることです。

設定 ➔ CI/CD に移動して、プロジェクトにランナーがすでに関連付けられているかどうかを確認できます。ランナーの設定は簡単です。

パイプラインとジョブのステータスを確認します。

ランナーを正常に構成すると、最新のコミットのステータスを確認できるようになります。

すべてのジョブを表示するには、パイプライン➔ジョブ ページに移動します。

ジョブのステータスをクリックすると、ジョブの実行ログが表示されます。

確認してみましょう:

  • まず、`.gitlab-ci.yml` ファイルを定義します。このファイルでは、実行するジョブとコマンドを定義します。
  • 次に、ファイルをリモート リポジトリにプッシュします。
  • 最後に、ジョブを実行するようにランナーを構成します。

オートDevOps

Auto DevOpsは、アプリケーションの検出、ビルド、テスト、デプロイ、監視を自動化できる、事前定義されたCI/CD構成を提供します。CI/CDのベストプラクティスとツールを活用することで、Auto DevOpsは成熟した最新のソフトウェア開発ライフサイクルのセットアップと実行を簡素化することを目指しています。

Auto DevOpsは、各プロジェクトが最小限の設定で検証から監視までのワークフロー全体を完了できるため、ソフトウェア開発プロセスの構築を大幅に簡素化します。コードをプッシュするだけで、GitLabが残りのすべてを処理します。これにより、新規プロジェクトの開始が容易になり、社内全体でアプリケーションのセットアップの一貫性が維持されます。

次の例は、Auto DevOps を使用して、GitLab.com でホストされているプロジェクトを Google Kubernetes Engine にデプロイする方法を示しています。

この例では、GitLab のネイティブ Kubernetes 統合を使用しているため、別の Kubernetes クラスターを手動で作成する必要はありません。

この例では、GitLab テンプレートから作成されたアプリケーションを作成してデプロイします。

GitLabテンプレートからプロジェクトを作成する

Kubernetes クラスターを作成して GitLab プロジェクトに接続するには、Google Cloud Platform アカウントが必要です。

以下では、GitLab プロジェクト テンプレートを使用して新しいプロジェクトを作成します。

プロジェクトに名前を付け、公開されていることを確認します。

GitLab テンプレートから Kubernetes クラスターを作成する

[Kubernetes クラスターの追加] ボタンをクリックするか、[操作] > [Kubernetes] に移動します。

Helm、Ingress、Prometheus をインストールします。

Auto DevOps を有効にする（オプション）

Auto DevOps はデフォルトで有効になっています。

ナビゲーション バー: 設定 > CI/CD > Auto DevOps。

「Auto DevOps パイプラインをデフォルトにする」チェックボックスをオンにして選択します。

最後に、展開戦略を選択します。

上記の手順をすべて完了すると、新しいパイプラインが自動的に作成されます。パイプラインを表示するには、「CI/CD」>「パイプライン」に移動してください。

アプリケーションを展開する

ここまででパイプが動いているのがわかると思いますが、正確には何を実行しているのでしょうか?

パイプラインは4つのステージに分かれています。次の図に示すように、各ステージで実行されている操作の数を確認できます。

ビルド -> テスト -> デプロイ -> パフォーマンステスト

アプリケーションは正常にデプロイされました。ブラウザで確認してみましょう。

まず、「操作」>「環境」に移動します。

「環境」では、デプロイされたアプリケーションの詳細情報を確認できます。右端に3つのボタンがありますので、一つずつ見ていきましょう。

最初のアイコンをクリックすると、本番環境にデプロイされたアプリケーションのURLが開きます。非常にシンプルなページですが、重要なのはちゃんと動作するということです！

その横には小さな画像のアイコンがあり、ここで Prometheus は Kubernetes クラスターに関するデータと、アプリケーションがクラスターに与える影響 (メモリ/CPU 使用量、レイテンシなど) を収集します。

3 番目のアイコンは Web ターミナルで、アプリケーションが実行されているコンテナー内でターミナル セッションを開きます。

例

GitLab CI/CD を使用して Spring Boot アプリケーションをデプロイします。

例: .gitlab-ci.yml

  1. 画像: java:8 
  2.  ステージ:  
  3.  - 建てる 
  4.  - 展開する
  5.   before_script:  
  6.  - chmod +x mvnw  
  7.  建てる：  
  8. ステージ: ビルド 
  9. スクリプト: ./mvnw パッケージ
  10.  アーティファクト:  
  11. パス: 
  12.   - ターゲット/デモ-0.0.1-SNAPSHOT.jar   
  13.  生産：  
  14. ステージ: デプロイ 
  15. スクリプト：  
  16.  - curl --location "https://cli.run.pivotal.io/stable\? release = linux64 -binary\& source = github " | tar zx  
  17.  - ./cf ログイン -u \$CF\_ユーザー名 -p \$CF\_パスワード -a api.run.pivotal.io
  18.  - ./cf プッシュ 
  19. のみ：  
  20.  - マスター

ラベル

関連するおすすめ記事

ランダムにおすすめされた記事

人気のタグ