Proxy配下で動いているGitLabから、パイプライン (GitLab Runner) を用いてAWS上のS3にファイルをアップロードする方法のメモを残します。
はじめに
おはよう。@bioerrorlogです。
社内環境など、Proxy環境下にあるGitLabから、GitLab Runnerを介してAWSのS3バケットにファイルをアップロードするやり方を残します。
Proxy環境下で動いているGitLabで開発している際、レポジトリへのPushをトリガーとしてコードをS3にアップロードしたいと思ったのですが、自分はproxyを跨いだGitLabとAWSとの繋ぎで詰まりました。
備忘録として、この手順を書き出していきます。
Proxy配下の環境となると、ものによって大きく事情が異なるかもしれませんが、少しでも自分と同じ状況にあたった方の役に立てば幸いです。
※なお、本記事中の参考画像は実際のProxy下の環境で撮ったものではなく、後で個人的にgitlab.com上のレポジトリで再現したものです。 画面に細かい違いはあるかもしれませんが、流れは変わらないのでご容赦ください。
Proxy配下のGitLab PipelinesからS3にファイルをアップロードする
S3バケットの作成
まずは、最終的にファイルをアップロードするS3バケットを作成します。
S3のマネジメントコンソールから、以下のように任意のリージョン・バケット名でS3バケットを作成します。
今回はとりあえずバージョニングを有効化して次へ。
アクセス許可の設定も、デフォルトのまま次へ。
後にIAMユーザーを作成し、その権限でS3バケットにファイルをアップロードするので、パブリックアクセスをブロックしたままで問題ありません。
バケットを作成したら、リージョンとバケット名をメモしておきます。 これらは後の設定で使います。
今回の場合だと、
リージョン: ap-northeast-1
バケット名: gitlab-pipeline-test
となります。
S3バケットの作成は以上です。
次は、このS3バケットにファイルをアップロードする権限を持つIAMユーザーを作成します。
[関連記事] S3バケットポリシーとIAMポリシーの関係を整理する
IAMユーザーの作成
IAMのマネジメントコンソールから、次の手順でIAMユーザーを作成していきます。
ユーザー名は任意、アクセスの種類は"プログラムによるアクセス"を選択します。
アクセス許可の設定では、作成したS3バケットへのPut権限を持つ新規のポリシーを作成します。
ポリシーには以下のようにして、S3バケットへのPutを許可します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": ["arn:aws:s3:::XXX/*"] } ] }
※"Resource"の"XXX"は、先ほど作成したバケット名に置き換えてください。
ポリシーを入力したら、任意の名前でIAMポリシーを作成します。
IAMポリシーを作成したら元のIAMコンソールに戻り、いま作成したIAMポリシーをアタッチします。
この後のタグ等の設定は今回は特に行わず、そのままIAMユーザーを作成します。
無事にIAMユーザーを作成したら、忘れずにセキュリティ認証情報をダウンロードします。
これは後の認証に使う重要な情報です。
IAMユーザーの作成は以上です。
[関連記事] aws s3 cpとsyncの違い | AWS CLI
GitLabの設定
次に、GitLabレポジトリのPipelineを設定していきます。
レポジトリ画面から Settings > CI/CD に行きます。
ここでは、RunnersとVariablesを設定します。
Runnersの設定
Runnersとは、GitLabパイプラインのジョブを実行主体となるツールです。
RunnerにはSpecific RunnersとShared Runnersの二種類があります。
Specific Runnersはプロジェクト専用にインストールできるもので、
Shared Runnersは共用利用されるものです。
利用可能なShared Runnersがある場合は、そのままパイプラインを走らせることが出来ます。
Shared Runnersがない場合は、Specific Runnersをインストールする必要があります。
今回私はSpecific RunnersをインストールせずにShared Runnersを利用しますが、Specific Runnersが必要な場合は以下のページなどを参考にインストールしてください。
Install GitLab Runner | GitLab
GitLab RunnerでCI/CDしてみる(前編) | Developers.IO
Variablesの設定
次に、Variablesに設定変数を埋め込んでいきます。
ここにIAMユーザーのアクセスキーやS3のバケット名などを与えておくことで、ソースコードにこれら機密性の高い情報をハードコーディングせずに、パイプラインに環境変数として渡すことができます。
またここでプロキシ情報を与えておくことで、プロキシを介して通信を行わせることが出来ます。
以下のように情報を埋め込んでいきます。
| Key | Value | 説明 |
|---|---|---|
| AWS_DEFAULT_REGION | ap-northeast-1 | S3バケットを作成したリージョン |
| S3_BUCKET | gitlab-pipeline-test | S3バケット名 |
| S3_OBJECT_KEY | pipeline-test | オブジェクトキー名を任意に設定 |
| AWS_ACCESS_KEY_ID | XXX | 作成したIAMユーザーのAccess key ID |
| AWS_SECRET_ACCESS_KEY | XXX | 作成したIAMユーザーのSecret access key |
| http_proxy | http://your.proxy:PORT | Proxyとポート番号 |
| https_proxy | http://your.proxy:PORT | Proxyとポート番号 |
| HTTP_PROXY | http://your.proxy:PORT | Proxyとポート番号 |
| HTTPS_PROXY | http://your.proxy:PORT | Proxyとポート番号 |
ちなみにMaskedを有効にすると、ジョブ実行のログにおいても変数を隠すことが出来ます。
AWS_ACCESS_KEY_IDやAWS_SECRET_ACCESS_KEYなど重要情報は、Maskedをオンにすることがお勧めです。
Variablesの設定は以上です。
次は、パイプラインの処理を.gitlab-ci.ymlに定義していきます。
.gitlab-ci.ymlの作成
.gitlab-ci.ymlは、パイプラインの処理を定義するymlファイルです。
.gitlab-ci.ymlを含めてレポジトリにPushすると、その中の記述に従ってパイプラインがジョブを実行します。
今回は以下のように.gitlab-ci.ymlを記述して、S3バケットにレポジトリのソース (今回はREADME.mdのみ) をアップロードさせます。
pipeline: image: python:3.6.5 before_script: - apt-get update - apt-get install -y zip - pip install --upgrade awscli script: - SOURCES="./README.md" - rm -f src.zip - zip -r src.zip $SOURCES - aws s3api put-object --bucket $S3_BUCKET --key $S3_OBJECT_KEY --body src.zip
パイプラインの実行
では、作成した.gitlab-ci.ymlを含めてGitLabレポジトリにPushし、パイプラインを走らせます。
パイプラインの実行が成功したかどうかは、CI/CD > Pipelines から確認できます。
表示がpassedになっていれば、成功です。
念のためS3バケットも確認し、確かにファイルがアップロードされていることを確認します。
見事、S3にファイルがアップロードされていることが確認できました。
おわりに
Proxy配下のGitLabから、パイプラインを用いてS3にファイルをアップロードするやり方を記録しました。
自分にとってのポイントは、GitLab PipelinesのVariablesに環境変数を渡せるという部分です。 この環境変数を介して、IAMユーザーの認証やプロキシ設定を行うことが出来ます。
これに気付かなかったために、少しの間右往左往することになりました。
世の中にはほかにも多くのパイプラインツールがあるので、色々と触ってこなれていきたいところです。
