目次

きっかけ

とある仕事に参加したエンジニアが、
CodeCommit、CodeBuild、CodeDeploy、CodePipelineを使って
リリースする仕組みを実装して感動したので
勉強がてらレビューを書きます。

※AWSのCodeCommit、CodeBuild、CodeDeploy、CodePipelineって何?
という方向けの記事なので、既に知見がある方には物足りないかもしれません。

目次へ戻る

AWS Codeシリーズ

多くの場合、dockerイメージを使ってサーバー構築、
Git管理したプログラムを、都度サーバーでpullしてリリース
という事をしてます。

ですが、とあるお仕事で、運用開始時はEC2が1台、
サイトのアクセス負荷が大きくなってきたら
台数を増やすという要件がありました。

普通にやると、都度EC2を1台作って、dockerイメージ+設定でサーバー構築、
Gitからプログラムを引っ張ってくるという流れになります。

都度、1台となると大した作業じゃないのですが、
一気に2台、3台と増やすとなると
ちょっと面倒になってきます。

そこで、開発に参加していたエンジニアの提案で、
CodeCommit、CodeBuild、CodeDeploy、CodePipeline
を使ってみる事になった訳です。

目次へ戻る

Codeシリーズとはどんなサービスなのか

まず、それぞれどんなAWSのサービスかというと、

【CodeCommitとは】

AWS上でGit管理が出来るようになるサービスです。

数年前は、バージニアリージョンでしか使えなかったのですが、
2017年5月25日から東京リージョンでも使えるようになったので
使っている方も増えてるかもしれないですね。

個人的には、バックログのプロジェクト毎のソース管理が多いので、
Gitと連携するうまい方法がないかなーというところです。

【CodeBuildとは】

AWS上でソースコンパイル、ユニットテスト、デプロイ出来るサービスです。

DockerfileをCodeCommitでバージョン管理し、
CodeBuildでDockerイメージを作成、テスト、デプロイというのが
ここ最近はよく使われてるんじゃないでしょうか。

開発中等、毎回、Dockerイメージをコマンドで作り直して
デプロイという面倒な作業が、一気に楽になる訳です。

今回も、まさにこの利用方法をしてます。

【CodeDeployとは】

簡単に言うと、デプロイ自動化サービスです。

このサービスの特徴は、指定した複数台のサーバーに
同じデプロイを実行出来るという所です。

ロードバランスの意味も含めて、
2台、3台と、徐々に本番運用サーバー台数が増えるような場合、
修正を個々にデプロイするという作業がかなり楽になりますね。

【CodePipelineとは】

ここまでで紹介したCodeCommit、CodeBuild、CodeDeployを
まとめて1つ流れとして繋げられるサービスです。

目次へ戻る

簡単な使い方の說明

それでは、それぞれの簡単な使い方を說明します。

■CodeCommitの使い方

1.CodeCommitでリポジトリを作成。
 AWSのCodeCommit管理画面で、使用するリポジトリを作ります。

2.公開鍵の登録。
 大抵はローカルPCで開発すると思うので、まず、ローカルPCからアクセス出来るように
 公開鍵を作成します。

3.CodeCommit用ユーザーをIAMで作成。
 CodeCommitへのアクセスは、IAMからアクセスコントロールします。
 なので、まず、CodeCommit用のユーザーをIAMで1つ作って、
 2.で作成した公開鍵をアップロードします。

4.SSHキーIDをGit用のツールに登録。
 3.で公開鍵を登録すると、作ったIAMのユーザーの画面に
 SSHキーIDが表示されていると思います。
 そのSSHキーIDを、Sourcetree等のGit用のツールに登録すれば、
 ローカルPCからGit操作するのと同じ感覚でCodeCommitを使用できるようになります。

自分はMACを使ってます。なので、公開鍵を作る事に煩わしさはあまり感じ無いですが、
windows環境で開発している方にとっては、公開鍵を作るというのは
少し面倒かもしれないですね。

■CodeBuildの使い方

 ※選択内容によって設定項目が変わるので、今回はわかりやすくする為に、
 「AWS CodeCommit」のソースを選択した場合の設定項目を説明します。

1.プロジェクト名の設定。
 CodeBuildの「ビルドプロジェクト」メニューから、「ビルドプロジェクトを作成する」ボタンを押下して
 「プロジェクトの設定」を行います。まずは、最低限、好きなプロジェクト名を設定します。

2.ソースの設定
 CodeBuildのビルド対象とするソースプロバイダを選択します。

 ソースプロバイダは、
「AWS CodeCommit」「Amazon S3」「GitHub」「Bitbucket」「Bitbucket Enterprise」
 の中から選択出来ます。今回は、「AWS CodeCommit」を選択します。

3.リポジトリ、Gitクローンの深さの設定
 利用したい「AWS CodeCommit」のリポジトリを選択します。
 Gitクローンの深さは、選択したリポジトリのルートディレクトリの深さを指定します。
 特に指定がなければ「1」を設定します。

 【注意】
 CodeBuildでは、独自のビルド方法を定義ファイル(buildspec.yml)で定義する事ができます。
 定義ファイルを利用する場合は、Gitクローンの深さは、定義ファイルと同じ深さにする必要があるので、
 注意して下さい。

4.環境の設定。
 環境イメージ、オペレーティングシステム、ランタイム、ランタイムバージョン、イメージのバージョンを設定します。

 もし、CodeCommitで管理したDockerイメージを、Linux環境でビルドをする場合は、
 下記のように設定します。

 環境イメージ:マネージド型イメージ
 オペレーティングシステム:Linux
 ランタイム:Docker
 ランタイムバージョン:(利用するDockerのバージョンを指定)
 イメージのバージョン:(ここは最新バージョンしていのまま)

 もし、定義ファイル(buildspec.yml)を利用する場合は、環境変数も適時設定して下さい。

5.Buildspecの設定。
 デフォルトのままでOKです。

6.アーティファクトの設定。
 処理結果ファイルをアーティファクトというのですが、
 それをAmazon S3に置くか設定します。
 CodeBuildでDockerイメージを作成する場合は、
 ここで設定すると、イメージがS3に置かれます。

 一応、ZIPで圧縮するか選択出来ますが、そこはお好みで。

細かい設定が多いですが、一応、これがCodeBuildで主に必要な設定項目です。
利用したい環境によってい設定項目が違ったりするので、途中で迷った場合は、
公式サイトのドキュメントを見直した方がいいです。

■CodeDeployの使い方

1.アプリケーションの作成。
 まず、CodeDeployのメニューの中から「アプリケーション」を選択して、
 アプリケーションを作成します。

 任意のアプリケーション名を入力し、コンピューティングプラットフォームを選択します。
 コンピューティングプラットフォームでは、「Amazon ECS」「AWS Lambda」「EC2/オンプレミス」
 などが選択できるので、環境に合わせて選択して下さい。

2.デプロイグループの作成。
 1.で作ったアプリケーションの中にデプロイグループを作成します。
 デプロイグループでは、任意のデプロイグループ名の入力、サービスロール、デプロイタイプを選択します。

 サービスロールで指定するロールは、事前に、別途「AWSCodeDeployRole」のポリシー設定した
 専用のロールを作って指定して下さい。

 デプロイタイプは、「インプレース」「Blue/Green」が選択出来ます。
 特に目的がなければ、「インプレース」を選択します。
 
 「インプレース」・・・インスタンス上にあるアプリケーションだけを入れ替える。
 「Blue/Green」・・・新しいインスタンスにアプリケーションを入れ、インスタンスを置き換える。

3.環境の設定。
 デプロイする対象として、
 「Amazon EC2 Auto Scalingグループ」「Amazon EC2 インスタンス」「オンプレミスインスタンス」が選択できます。
 「Amazon EC2 インスタンス」の場合は、指定したタググループの付いた複数のインスタンスに対してデプロイが可能です。

 デプロイの設定欄があり、もし、デプロイ対象のインスタンスをロードバランシングしている場合は、
 複数台を一気にデプロイする等、どのようにデプロイするか設定をします。

 ロードバランサーの設定欄では、デプロイ中のアクセス管理にロードバランサーを利用する場合に指定します。
 (別途、事前にロードバランサーを作成しておく必要があります)

複数台のデプロイ方法に細かい指定が出来るので、ロードバランサーで複数台運用しているサービスでは、
かなり有用な機能に感じます。

■CodePipelineの使い方

1.パイプラインの設定。
 パイプラインの設定では、パイプライン名、サービスロール、アーティファクトストアの設定をします。
 パイプライン名には、任意の名前を設定します。
 
 サービスロールで指定するロールは、事前に、
 別途「CodePipeline」用のロールを作って指定して下さい。

 処理結果ファイルをアーティファクトというのですが、
 それをAmazon S3に置くか設定します。

2.ソースステージの追加。
 作成するパイプラインのソースプロバイダを指定します。AWS CodeCommitを使用する場合は、
 ソースプロバイダにAWS CodeCommitを指定し、リポジトリ、ブランチを設定します。

 変更検出オプションには、特に指定がなければデフォルトのままを指定します。

3.ビルドステージの追加。
 作成するパイプラインのビルドプロバイダを指定します。AWS CodeBuildを使用する場合は、
 ビルドプロバイダにAWS CodeBuildを指定します。

4.デプロイステージの追加。
 作成するパイプラインのデプロイプロバイダを指定します。AWS CodeDeployを使用する場合は、
 デプロイプロバイダにAWS CodeDeployを指定します。

CodePipeline自体が何か単独で動きのある機能ではなく、
主に、今まで紹介したCodeCommit、CodeBuild、CodeDeployを組み合わせ、
1つの流れとして利用する為のサービスというイメージです。

目次へ戻る

まとめ

CodeCommit、CodeBuild、CodeDeploy、CodePipelineを通して見てみると、
ソース管理からデプロイまでもAWS上で完結出来る環境が整って来たのが実感できました。

AWS上で、複数台のロードバランシングをしているサービスでは、
非常に扱いやすい機能だと思います。

この記事をシェアする:

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

東日本橋の制作・開発会社 プレスマンのスタッフブログ