この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
はじめに
最近はAWS Certified Developer – Associate (DVA) を受けるために勉強しています。
しかし、使ったことのないサービスというのは本を読んでもあまり頭に入ってきません。
特にCodeシリーズが理解しにくかったので、ハンズオンをやりながらサービスの内容を整理したいと思います。
ハンズオンは初心者向けに細かく説明をしていく予定です。
目的
-
Codeシリーズの概要を理解する。
-
AWS Codepipeline を利用して、S3の静的ウェブサイトホスティングを自動化する。
説明
AWS Code シリーズ
ソフトウェアを開発してリリースするまでの工程を簡単に表現すると次のようになります。
- コーディング
- 構築
- テスト
- デプロイ
それぞれの工程で利用できるAWSのサービスをまとめてCodeシリーズと呼んでいます。
Codeシリーズ一覧
- AWS CodeCommit
- AWS CodeBuild
- AWS CodeDeploy
- AWS Codepipeline
- AWS CodeStar
このような工程を自動化することをCI/CD(Continuous Integration/Continuous Delivery(Deployment))と言います。
CIとCDの違いが難しかったのでそれぞれまとめてみました。
CI(Continuous Integration)
継続的インテグレーション
コーディングは複数のエンジニアが別々に行っている場合が多いです。
それぞれのソースコードを統合(インテグレーション)して、変更されたら自動でビルドとテストを行い、問題を早期発見することを目的としています。
簡単に手順をまとめると、以下のような順番になります。
- バージョン管理システム(Gitなど)を使用してソースコードを管理
- エンジニアがソースコードの変更をコミット
- リポジトリの変更を検出して、自動でビルドとテストを実行
つまり、CIはコードの品質を保証し、複数の開発者が同時にコードを変更しても問題なく統合できるようにしています。
CD(Continuous Delivery(Deployment))
継続的デリバリー、デプロイメント
CDは、ソフトウェアの開発プロセスを自動化し、アプリケーションの変更を自動的にビルド、テスト、およびデプロイすることを目的としています。
CIの成果物(ビルド済みのアプリケーションなど)を自動的に適切な環境にデプロイし、テストやリリースの手順を自動化します。
つまり、CIはCDの一部だと考えてよいのだと思います。
CIはコードの統合とテストまでを自動化し、CDはそれを含めてデプロイまでの全体を自動化していると理解しました。
開発の工程と関連するAWSサービス、CI/CDのイメージをまとめて図にしてみました。
AWS CodeCommit
CodeCommitはコードのバージョンを管理します。
バージョン管理ツールとして一般的なGitを利用できます。
Gitコマンドを使用することで、Visual Studio Code などのIDEから直接、ソースコードをCodeCommitのリポジトリにアップロードできます。
マネジメントコンソール上で以下のことができます。
- リポジトリのコンテンツ参照
- コミット間の差分表示
- コミットグラフの表示:変更履歴をグラフで見られる
- プルリクエスト機能:コードレビューができる
AWS CodeBuild
CodeBuildはアプリケーションをビルドしてテストします。
ビルドとはソースコードをコンパイルし、リンクを行い、実行可能なファイルを作成することです。
Jenkinsというオープンソースの開発自動化ツールも利用できます。
DockerfileからDockerイメージをビルドすることもできます。
CodeBuildのコンセプト
- ビルドプロジェクトを作成
- ビルドプロジェクトに基づいてビルド環境を構築
- ソースコードをダウンロード
- ビルドのアウトプットをS3にアップロード
- ビルド実行中、CodeBuildとCloudWatchLogsに情報を送信
- ビルド実行中、CodeBuildコンソール、AWS CLI、AWS SDK、AWS APIでビルド情報を取得
AWS CodeDeploy
CodeDeployはアプリケーションをデプロイします。
CodeDeployの概要
- コードのデプロイメントを自動化
- アプリケーションの複雑なアップデートに対処
- デプロイ中のダウンタイムを回避
- 失敗を検知したら自動的にロールバック
- 言語やOSに依存せずにAmazon EC2やオンプレミスサーバーにデプロイ
- AWS Lambdaへのカナリアデプロイをサポート
AWS Codepipeline
AWS CodePipelineはパイプラインによる展開を行います。
ソフトウェアをリリースするために必要なステップのモデル化、視覚化、および自動化に使用できる継続的なデリバリーサービスです。
コードが変更されるたびにビルド、テスト、デプロイを自動で行います。
これまでのCodeCommit、CodeBuild、CodeDeployなどを利用することができます。
AWS CodeStar
AWS CodeStar は、アプリケーションを迅速に開発および構築して AWS にデプロイするために必要なツールを備えたクラウドベースの開発サービスです。
AWS CodeStar では、継続的デリバリーのツールチェーン全体を数分で設定でき、コードのリリースをすばやく開始できます。
https://aws.amazon.com/jp/codestar/faqs/?nc=sn&loc=4
これまで説明したCodeCommit、CodeBuild、CodeDelpoy、CodePipelineを総合的に管理するサービスだと理解しました。
テンプレートを使用することで、すぐにプロジェクトを作成して開始することができます。
構成
今回はシンプルにCodePipelineとCodeCommitを利用して、S3の静的ウェブサイトホスティングを自動化してみたいと思います。
また、統合開発環境としてAWS Cloud9 を使用しました。
gitがインストールされていない、などの環境の違いで上手くいかない場合を避けるためです。
ハンズオンの流れ
1. Amazon S3で静的ウェブサイトをホスティングする
2. AWS CodeCommit のリポジトリを作成する
3. AWS Cloud9 の環境を作成する
4. AWS CodePipeline を設定する
ハンズオン開始
1. Amazon S3で静的ウェブサイトをホスティングする
1-1. S3バケットを作成する
バケット名:任意の値
静的ウェブサイトを公開するためのバケットなのでパブリックアクセスを許可する必要があります。
「パブリックアクセスをすべてブロック」のチェックを外す。
「このバケットとバケット内のオブジェクトが公開される可能性があることを承認します。」のチェックを入れる。
1-2. S3バケットの設定をする
下記の二点を設定します。
- 静的ウェブサイトホスティング設定
- バケットポリシーでバケット内のオブジェクトの取得を許可する
まずは、静的ウェブサイトホスティングの設定を行います。
バケットを選択し、「プロパティ」のタブを選択する。
「静的ウェブサイトホスティング」の「編集」を選択する。
「静的ウェブサイトホスティングを編集」
- 静的ウェブサイトホスティング: 有効にする
- インデックスドキュメント: index.html
これで、静的ウェブサイトホスティングの設定は完了しました。
次はバケットポリシーを設定します。
バケットを選択し「アクセス許可」のタブを選択する。
「バケットポリシー」の「編集」を選択する。
「ポリシー」欄に下記のコードを貼り付ける。
<作成したバケット名>の部分は自分のものに変更する。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::<作成したバケット名>/*"
]
}
]
}
「変更の保存」を行う。
1-3. index.htmlファイルをアップロードする
まず、index.htmlファイルを作成します。
ローカル環境のエディタ(メモ帳でも何でもよい)で下記のコードを貼り付け、「index.html」という名前で保存する
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8">
<title>S3 Static Web Hosting</title>
</head>
<body>
Hello, AWS World!!
</body>
</html>
バケットを選択し、「オブジェクト」のタブを選択する。
アップロードを選択し、作成した「index.html」ファイルをドラッグ&ドロップする。
「プロパティ」のタブより「静的ウェブサイトホスティング」の項目を見て、バケットウェブサイトエンドポイントが作成されていることを確認する。
エンドポイントのアドレスをクリックし、「index.html」の内容が確認できれば成功。
2. AWS CodeCommit のリポジトリを作成する
サービス一覧からCodeCommitを選択する。
「リポジトリの作成」を選択する。
リポジトリ名に任意の値を入力し、「作成」を選択する。
作成が完了し、「接続のステップ」が表示されれば成功です。
3. AWS Cloud9 の環境を作成する
3-1. Cloud9の環境を作成する
サービス一覧からCloud9を選択する。
「環境を作成」を選択する。
「名前」に任意の値を入力し、その他はデフォルトの設定で大丈夫です。
作成が完了したら選択して「Cloud9で開く」を選択します。
Cloud9のコンソール画面が開きます。
左上の雲のマークをクリックし、「Preferences」を選択すると設定変更ができます。
今回はTabでインデントする数を4→2に変更しました。
Preferences > Project Setting > Soft Tabs で設定できます。
Preferences > Themes で背景色なども変更できます。
3-2. 認証ヘルパーを設定する
AWS CodeCommit に初めて接続する前に、最初の設定手順を完了する必要があります。
ほとんどのユーザーにとっては、これは Git 認証情報を使用した HTTPS ユーザーのセットアップ の手順に従って簡単に行うことができます。
ただし、ルートアカウント、フェデレーテッドアクセス、または一時的な認証情報を使用して CodeCommit に接続する場合は、AWS CLI に含まれている認証情報ヘルパーを使用できます。端末から、Git を使って git config を実行し、Git 認証情報ヘルパーと AWS 認証情報プロファイルの使用を指定し、Git 認証情報ヘルパーがリポジトリにパスを次のように送信できるようにします。
以上は公式ドキュメントからの引用です。
Cloud9のターミナルで下記のコードを実行します。
git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true
成功すれば何も返ってきません。
次はユーザー名とメールアドレスを登録します。
下記のコードのとを任意に変更して実行します。
git config --global user.name "<name>"
git config --global user.email "<email>"
成功すれば何も返答はありません。
これでCloud9の環境からGitコマンドでリポジトリを操作することができるようになりました。
3-3. CodeCommitのリポジトリをClone(クローン)する
CodeCommitで管理してるリポジトリをローカルの環境にコピーしてくることをクローンすると言います。
先ほど作成したリポジトリの画面にクローンするコマンドが記載されていますのでコピーしてきて、実行します。
クローンが成功すると、リポジトリのコピー(ローカルリポジトリ)が作成されます。中身はまだありません。lsコマンドなどで確認します。
ローカルリポジトリに先ほど作成した「index.html」をコピーします。
Cloud9のメニューから「File」を選択し、「Upload Local Files」を選択します。
ここにドラッグ&ドロップすればOKです。
ローカルリポジトリ内にindex.htmlがコピーされました。
3-4. ローカルリポジトリをCodeCommitのリモートリポジトリにpush(プッシュ)する
開発者のローカル環境にあるのがローカルリポジトリです。
ここでコードを編集して、リモートリポジトリにアップロードすることでバックアップが取れたり、共同で開発している人に共有できます。
このアップロードする作業がpushです。ここでのリモートリポジトリはCodeCommitで管理してるリポジトリのことです。
Pushするにはターミナル上で下記のコードを順番に実行します。
git add -A
addコマンドは変更したファイルをステージと呼ばれる状態にします。
詳細は割愛しますが、ステージ状態になったものは次回のCommitでコミット対象となります。
オプションの「A」はディレクトリ内のすべてのファイルが更新されます。
git commit -m "init"
commitコマンドはGitのリポジトリに変更内容を登録(保存)します。
オプションの「m」は保存するときにコメントを付けることができます。
どんなことを変更したのかを記述しておくと、後から変更履歴を見るときに便利です。
今回は初めのコミットなのでinitにしてあります。
git push origin master
pushコマンドはコミットをローカルリポジトリからリモートリポジトリに送信します。
originはリモートリポジトリのアドレスの名前です。実際は長いアドレスが設定されますが、originという名前で呼び出しています。
masterは自動で作成されるメインのブランチ名です。
pushが成功すると次のようになります。
マネジメントコンソールでCodeCommitのリポジトリ内を確認します。
git pushでリモートリポジトリに変更を保存することができました。
次はいよいよ、CodePipelineと連携し、この変更をそのままS3バケットに反映するようにします。
4. AWS CodePipeline を設定する
4-1. パイプラインを作成する
サービス一覧からCodePipelineを選択します。
「パイプラインを作成する」を選択してください。
「パイプラインの設定」では「パイプライン名」だけを入力します。任意の値を設定してください。その他はデフォルトでかまいません。
「ソースステージを」追加するでは「ソースプロバイダー」に「AWS CodeCommit」を選択します。
「リポジトリ名」と「ブランチ名」を選択します。
「ビルドステージを追加する」では何も設定せず「ビルドステージをスキップ」を選択してください。
今回は、ビルドをしないので必要ありません。
「デプロイステージを追加する」では「デプロイプロバイダー」に「Amazon S3」を選択してください。
「デプロイする前にファイルを抽出する」にチェックを入れてください。通常、圧縮されてデプロイされるので、解凍しないとファイルとして読み込めません。
レビューを確認したら「パイプラインを作成」してください。
少し時間がかかります。Sourceが「失敗しました」になることもありますが、もう少し待ってから「再試行する」と成功すると思います。
4-2. ソースコードを変更しgit pushをすることでウェブサイトの内容が変更されるか確認する
Cloud9の画面から「index.html」を編集します。
今回は「Hello, AWS World!!」の後に文字を追加しました。
File > Save で変更を保存し、git pushします。
コマンドは下記を参照してください。commitのコメントが違うだけであとは一緒です。
git add -A
git commit -m "fix"
git push origin master
pushが成功したらパイプラインの情報を更新してみます。
Sourceの「成功しました」にある番号もgitのステータスに表示されたものと一緒です。
この番号はgit commit したときに付けられる一意の番号なので、正しくpushされていることがわかります。
では、先ほどのウェブサイトにアクセスしてみましょう。
表示されるテキストが更新されています。
これで、ソースコードをエディタで編集した後にgit pushを行うだけで、ホームページの内容を変更することができます。
便利ですね。
まとめ
Codeシリーズについて、それぞれのサービスの概要をまとめ、流れが理解できました。
CodePipelineとCodeCommitを利用して、S3の静的ウェブサイトを簡単に更新することができることを確認できました。
CodeBuildとCodeDeployも利用したハンズオンは次回作をご期待ください。