はじめに
こんにちは！サーバワークスの橋本です。 本ブログではGitLabパイプラインでAWS環境にアクセスし、Lambdaのデプロイまでを行います。
GitLabについて
GitLabは、CI/CDやコード管理にとどまらず、ソフトウェア開発のライフサイクル全体をカバーする統合型DevOpsプラットフォームを提供しています。
計画、開発、テスト、デプロイ、運用までを一元管理できる点が大きな強みです。
さらに、GitLabはクラウド環境だけでなく、オンプレミス環境へのホスティングにも対応しており、企業の要件やセキュリティポリシーに応じた柔軟な環境構築が可能です。
ちなみに間違えられがちですが、ロゴは「きつね」ではなく「たぬき」らしいです。
GitLabを選択する理由
GitLabかその他（GitHubなど）でソース管理をどうするかよく考えますが、その際はプロジェクトをどのように管理したいのかによります。
管理構成による選択
ソース管理を含めてソフトウェア開発の全体をGitLabで一元管理したい場合は、GitLabが最適な選択肢となります。
一方で、例えばJenkinsなど他のツールを使う予定がある場合は、ツールとの連携がしやすいGitHubなどを選ぶのが良いかもしれません。
CI/CDによる選択
例えばGitHubにはGitHub Actionsがあり、直感的な操作で比較的簡単にCI/CDを実装できます。シンプルでわかりやすい構成が魅力です。
一方、GitLab CI/CDは、gitlab-ci.yml を活用することで、より柔軟かつ複雑なパイプラインを構築することができます。
どちらを選ぶかは、要件や運用環境を整理した上で、最適なツールを選択するのがベストだと思います。
結局のところ
小難しいこと言ってますが、一元管理したいならGitLabで、それ以外は使いやすいので良いのではないかなと個人的には思います。
やろうとしていること
さて、前置きはこれくらいにして本ブログでやりたいことの詳細を書いていこうと思います。 冒頭で図を出した通り、GitLabパイプラインでAWS環境にアクセスし、Lambdaのデプロイまでを行います。
それぞれの役割は以下となります。
- ソース管理：GitLab
- CI/CD：GitLab
- デプロイ先：AWS（APIGateway, Lambda, S3）
CI/CDの詳細
- GitLabのリポジトリにmainブランチを用意
- GitLabのmainブランチへのPushをトリガーにGitLabパイプラインが起動
- ビルド実施
- 簡単な静的解析（flake8）実施
- 自動テスト実施
- デプロイ実施
事前準備
ソースの用意
今回はあらかじめローカルでSAMを使ってTemplate（PythonでのHelloWorld）を作成してGitLabプロジェクトにPushしておきます。
GitLabRunner
GitLabには共有Runnerが既に用意されており、.gitlab-ci.ymlファイルに必要な内容を記載すれば、すぐにCI/CDを実行することができます。
ただし、この共有RunnerはGitLabのSaaS環境で動作しており、全ユーザーが利用可能となります。
そのため、利用状況によっては動作が遅くなったり、ジョブの実行が競合するなどの問題が発生する可能性があります。
一方で、プロジェクト専用のランナー（プロジェクトランナー）を作成すれば、そういった問題が解消されて、特定の用途に応じた環境でCI/CDを実現することができます。 ただし、この場合は別途サーバーやインスタンス（EC2など）を用意する必要があるため、ランニングコストや運用コストを考慮しなければいけません。
今回は例で使う小さいプロジェクトなので共有Runnerを使います。
AWS認証情報を登録
CI/CDでのデプロイはSAMで行うためAWS認証情報をセキュアに管理する必要があります。 そこで、GitLabにパラメータをセキュアに管理するVariablesを使って管理していきます。
GitLab左サイドメニューのSettings＞CI/CDで表示された画面からVariablesを選択します。
AWS認証情報を登録します。
※登録した内容はマスクできます。
パイプラインの作成
gitlab-ci-ymlファイルの作成
- 「main」と[dev]ブランチのみ対象
- 「build」⇒「scan」⇒「test」⇒「deploy」の順番でパイプラインを実行
- 「deploy」は「main」ブランチにプッシュされた場合のみ実行
stages:
- build
- scan
- test
- deploy
build:
stage: build
image: amazon/aws-sam-cli-build-image-python3.9
script:
- sam build
artifacts:
paths:
- .aws-sam
only:
- main
- dev
scan:
stage: scan
image: python:3.9
script:
- pip install flake8
- flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
only:
- main
- dev
test:
stage: test
image: amazon/aws-sam-cli-build-image-python3.9
script:
- pip install -r tests/requirements.txt --user
- python -m pytest tests/unit -v
only:
- main
- dev
deploy:
stage: deploy
image: amazon/aws-sam-cli-build-image-python3.9
script:
- aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID
- aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY
- aws configure set default.region ap-northeast-1
- sam deploy --no-confirm-changeset --no-fail-on-empty-changeset
only:
- main
gitlab-ci-ymlの配置について
変更は可能ですが、私は大体プロジェクト直下に配置します。
example_pipeline ├── events ├── hello_world ├── tests ├── .gitignore ├── .gitlab-ci.yml ├── ・・・ ├── ・・ └── ・
実行例
ソースコードを修正し、「dev」ブランチにマージした場合は、 deployは実行されません。
「dev」のソースコードを「main」ブランチにマージした場合は、 deployまで実行します。
さいごに
GitLab CI/CDの.gitlab-ci.ymlファイルの設定を工夫することで、非常に柔軟なパイプラインを構築できます。
例えば、特定のブランチ間でのマージ時のみトリガーする、ブランチごとにデプロイ先を変えるといったことも勿論可能です。
実際プロジェクトでCI/CDを使う場合はシンプルではない場合が多いので、そういった様々な要求に応えるためにGitLabパイプラインは良いのではないかと思いました。
