コーポレートサイトなどの静的サイトを、Github+CircleCi+S3webhostingでサーバレスDevOpsを実現。

主な利点

Github操作のみでデプロイを自動化。
サーバレスなのでサーバ運用不要。
**ステージングサイトには閲覧制限(許可IP制）**を設けることで、外部会社との連携も安全。

構築内容

AWS S3 webhosting構築
Githubリポジトリ作成
静的ページを用意　HTML+CSS(bootstrap)
CircleCIでのオートデプロイ
オートデプロイテスト
+αでフォームサイトはlambda,cognitoで実装

6は後編で掲載予定。

想定フロー

各自ローカル環境でHTML編集。Githubで管理。
stagingブランチへのgit pushでステージングサイトへ自動デプロイ (ステージングサイトは自社サイトのみ閲覧可能）
pullreqし、レビュワーがステージングサイトをチェック
OKならmasterマージされ、本番サイトへ自動デプロイ

各フローをchatのbot機能＋chat配信機能を利用するとChatOpsにも対応可能！

必要アカウント

AWSアカウント
Githubアカウント
CircleCiアカウント

Githubアカウントはpublic公開のみなら無償。 CircleCIアカウントはgithubアカウントと連携するので個別に作成する必要はなし。かつ、本構成レベルの利用なら無料（正確には1コンテナまで無料）！

想定費用

前述の通り、Github/CircleCiについては条件により無償枠で実現可能。

HTML分のAWS S3費用(保管費用、転送費用）一般的なサイトで**$2~3**前後 +後編の問い合わせフォーム用のlambda+cognito費用$2~3で実現可能。

サイト作成例

今回のサイト例

s3site.proudit.jp -> 本番サイト
st.s4site.proudit.jp ->　ステージングサイト

と定義して、構築例を進める。

IAMユーザ「s3-deploy-user」の作成

CircleCIからのデプロイユーザを作成。

AWSコンソールより
IAM->ユーザー->新しいユーザの作成
ユーザ名　「s3-deploy-user」で作成

　この時認証用のAccesskey/SeacretKeyを必ずダウンロードし控えておくこと！ 　

IAM->ポリシー作成->独自のポリシーを作成
ポリシー名「s3-deploy」
ポリシードキュメント

作成ポリシー例

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
            "s3:PutObject",
            "s3:DeleteObject",
            "s3:ListBucket"
        ],
        "Resource": [
            "arn:aws:s3:::s3site.proudit.jp",
            "arn:aws:s3:::s3site.proudit.jp/*",
            "arn:aws:s3:::st.s3site.proudit.jp",
            "arn:aws:s3:::st.s3site.proudit.jp/*"
        ]
    }
]
}

作成したユーザ「s3-deploy-user」にポリシー「s3-deploy」をアタッチする。

S3のwebhostingを準備

まずは器の構築。ここは本題ではないので、さらっと要点のみ記載。詳細は以下参照。 Amazon S3 での静的ウェブサイトのホスティング

今回のサイト例 s3site.proudit.jp -> 本番サイト st.s3site.proudit.jp ->　ステージングサイトとして、各バケットを静的ウェブサイトとして作成。

本番サイトの公開用bucketポリシーはすべて許可。

{
  "Version":"2012-10-17",
  "Statement":[{
	"Sid":"AddPerm",
        "Effect":"Allow",
	  "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::s3site.proudit.jp/*"
      ]
    }
  ]
}

ステージングサイトの要件の１つ、自社からのアクセスIPからのみ閲覧許可とする、場合のポリシー例

{
"Version": "2008-10-17",
"Id": "PolicyAccessCtrl",
"Statement": [
	{
		"Sid": "StmtAccessCtrl",
		"Effect": "Deny",
		"NotPrincipal": {
			"AWS": "arn:aws:iam::[AWSアカウントID]:user/s3-deploy-user"
		},
		"Action": "s3:*",
		"Resource": "arn:aws:s3:::st.s3site.proudit.jp/*",
		"Condition": {
			"NotIpAddress": {
				"aws:SourceIp": "[許可IP]"
			}
		}
	},
	{
		"Sid": "StmtAccessCtrl",
		"Effect": "Allow",
		"Principal": {
			"AWS": "*"
		},
		"Action": "s3:GetObject",
		"Resource": "arn:aws:s3:::st.s3site.proudit.jp/*",
		"Condition": {
			"IpAddress": {
				"aws:SourceIp": "[許可IP]"
			}
		}
	},
	{
		"Sid": "AllowBucketAndObjectsAccessFromCircleCI",
		"Effect": "Allow",
		"Principal": {
			"AWS": "arn:aws:iam::[AWSアカウントID]:user/s3-deploy-user"
		},
		"Action": "s3:*",
		"Resource": "arn:aws:s3:::st.s3site.proudit.jp/*"
	}
]
}

[許可IP] [AWSアカウントID] は適宜代入のこと。 AWSアカウントID確認方法はこちら

なお、このままだと、 s3site.proudit.jp.s3-website-ap-northeast-1.amazonaws.com と長いURLのままなので、Route53であればAlias設定、他ドメイン管理DNSであれば適宜cname連携しておくこと。

Route53での設定例スクリーンショット 2015-11-25 10.09.41.png

githubレポジトリ準備

事前にGithubには該当のリポジトリを作成しておく。例ではpublic環境であるが、もちろんprivete環境(有料）でも可。

スクリーンショット 2015-11-24 15.49.59.png 　　

静的サイト準備

既存サイトがあれば、それを利用。今回は新規作成の例。 Bootstrapの無料テンプレート利用を利用する前提で進める。

BootstrapとはWebサイトやWebアプリケーションを作成するフリーソフトウェアツール集である。タイポグラフィ、フォーム、ボタン、ナビゲーション、その他構成要素やJavaScript用拡張などがHTML及びCSSベースのデザインテンプレートとして用意されている。

参考URL BootstrapでレスポンシブなWebサイト制作最近公開されたBootstrapの無料テンプレート 180本まとめ

いいテンプレートが見つかったら、ダウンロードして適宜自社サイト用に編集する。（ここではColorful Flatというテンプレートを利用）


リポジトリ用のTopディレクトリにあらかじめダウンロードしたzipを置く。
$ cd (repo-top)/
$ unzip colorfulflat-new-v2.zip
$ rm -rf colorfulflat-new-v2.zip
$ rm -rf __MACOSX/
$ mv colorfulflat-new-v3 html
 ※html配下をコンテンツデータとする。

Git初期化
$ git init
$ echo "#my campany site example" >> README.md
$ git add .
$ git commit -m "first commit"$ git remote add origin git@github.com:toguma/mycorpsite.git
$ git push origin master

デプロイをCircleCiで自動化

ここまででようやくデプロイ準備が整ったので、 CircleCiにアクセスし、CircleCIアカウントを作成する。 (githubアカウント連動）

初回、Githubアカウントとのアクセス可否を求められるので、許可しておく。その後はCircleCi管理画面からGithubリポジトリが見える状態となる。

スクリーンショット 2015-11-24 18.51.32.png

[Add Project]から、該当リポジトリが表示されることを確認後、 [BuildProject]をクリックする。

スクリーンショット 2015-11-24 18.51.44.png

BuildProject開始した後、自動でビルドが始まるが、このタイミングではデプロイ制御ファイル(circle.yml)がない為、デプロイ失敗(Field)となるが正しい挙動なので、気にしない。　

AWSアクセスキーを設定

CircleCiにはデフォルトでAWSキーの設置箇所がある。　該当projectの[Project Setting]よりスクリーンショット 2015-11-25 10.15.13.png

[Parmissions]->[AWS Parmissions] スクリーンショット 2015-11-24 18.52.53.png 　

IAMユーザ=s3-deploy-user作成時にダウンロードした[AccessKey][SeacretKey]を設置する。

スクリーンショット 2015-11-24 18.53.16.png

デプロイ制御ファイルの設置

GitリポジトリのTop階層に、 circle.ymlというyaml形式のCirclrCI用のデプロイ内容を記述

machine:
  timezone:
    Asia/Tokyo

dependencies:
    override:
        - sudo pip install awscli
    post:
        - aws configure set region ap-northeast-1

test:
  override:
    - echo "Nothing to do here"

deployment:
  production: # just a label; label names are completely up to you
    branch: master
    commands:
      - aws s3 sync html/ s3://s3site.proudit.jp/ --delete
  staging:
    branch: staging
    commands:
      - aws s3 sync html/ s3://st.s3site.proudit.jp/ --delete

内容を補足。　リージョンはS3 bucket、IAMユーザ作成した場所と同じリージョンに指定。

Ci用マシンにAWS CLIをインストール
stagingブランチなら、ステージングサイトにデプロイ
masterブランチなら、公開サイトにデプロイ

という単純な動作を実現。 2,3のデプロイ先は適宜S3 bucket名と入れ替えのこと。 (またtest自体はダミーテストの為、実際にテストはしていない。本当にコードテストを実施したい場合は適宜テストツールを導入して、コードチェックの自動化も可能。)

git pushによるコンテンツデプロイ

以上で準備は完了。まずはステージングサイトへコンテンツをアップ。

staging用のブランチ作成
$ git checkout -b staging

適宜コンテンツ編集

$ git add .
$ git commit -m "staging site up"
$ git push origin staging

git pushに反応して、CircleCI側で自動でstagingブランチのビルド＝Deployが始まる。

Statusが[Success]or[Fixed]となれば、デプロイ成功。

S3 webhostingの閲覧用URLからアクセス可能なことを確認。 http://st.s3site.proudit.jp/

指定したアクセス制御がうまく行っていれば、ステージングサイトはURLにて閲覧可能と成っているはずだ。許可IP以外からのアクセスは拒否しているので下記「403 Forbiddn」が表示される。

何度かステージングサイトへの修正,Pullrequestレビューを行って、公開に問題なしとなったら、masterブランチへマージ。 masterへマージされたタイミングで自動的に本番サイトへコンテンツアップされることを確認する。

http://s3site.proudit.jp/

雑感

今回は master = 本番サイト staging = ステージングサイトと定義してが、もちろんdevelopブランチ、develop用サイトを同手順で作成してもいいし、 releaseブランチで本番サイト公開、というデプロイルールとしてもいい。この辺りは既存のGithub運用に合わせて調整すればいいと思う。

まだ、問い合わせフォームなどの動的ツールが未適用なので、別途cognito＋lambdaを利用して実装すると、よりサーバレスな構成を実現できる。が、それは後編で。

今日は一旦ここまで。