そうだ、HTTP/2に移行しよう(実践編)

こんにちは、エンジニアの吉田です。

前回そうだ、HTTP/2に移行しよう(OpsWorks編)の記事を執筆しましたが、今回はその続編となります。
(前回から時間が経ってしまい申し訳ないです汗)

前回はHTTP/2に移行する為にAWS OpsWorksを用いたChef12スタックでの
シンプルな環境を構築するところまでお伝えしました。
しかし実際はChef12スタックは、Chef11以前のスタックと違い
それまでのレシピの運用方法を変えなければなりません。
今回は、現場でのOpsWorks Chef12スタックにおける課題の解決にフォーカスした実践編となります。

実践編

その1. OpsWorksのChef12スタックでコミュニティクックブックを利用したレシピを実行する

Chef12スタックで最も注意しなければならない点は、レシピを実行する際に
利用するコミュニティクックブックの参照が自動的に行われなくなったことです。
試しにコミュニティクックブックを利用したレシピをそのまま実行しようとしたら
「コミュニティクックブック?そんなの見つからないよ!」と怒られます。

なので解決方法としてはコミュニティクックブックを含んだクックブックアーカイブを事前に作成し
s3にアップロードした場所を参照するようにします。

コミュニティクックブックを含んだクックブックアーカイブを作成

[前提条件]
アーカイブ作成にはBerkShelfをインストールしている必要があります。
もし無い方はChefDKをインストールするか、もしくはGemでBerkShelfをインストールしてください。
ChefDK: https://downloads.chef.io/chefdk
Gem: gem install berkshelf

[手順]
1. ローカルでクックブックのディレクトリに移動する

2. berks packageコマンドを実行してアーカイブを作成する
デフォルトだとcookbooks-1506749951.tar.gzといったタイムスタンプ付きのアーカイブが出来上がります。
もしファイル名を指定したい場合はberks package {ファイル名}.tar.gzのようにコマンドを実行します。

3. アーカイブを格納する為のs3バケットを作成する

4. 手順3で作成したバケットにアーカイブをアップロード

AWS CLIのS3コマンドが便利です。
aws s3 cp cookbooks.tar.gz s3://{バケット名}

実行後、S3にアーカイブファイルがアップロードされていることを確認します。

5. OpsWorksスタックでアーカイブファイルを参照するよう設定

AWSコンソールで先程作成したアーカイブファイルを選択して表示されたダイアログ内のリンクURLをコピーします。

OpsWorksスタック設定編集ページに移動して、以下の様に設定します。
・Use custom Chef cookbooks: ON
・Repository type: S3 Archive
・Repository URL: コピーしたアーカイブファイルリンクURLを貼り付け

以上でコミュニティクックブックを利用したレシピを実行できるようになります。

その2. クックブックアーカイブ作成&S3へのアップロードを自動化する

その1でコミュニティクックブックををOpsWorksで利用出来る様になりました。

しかしレシピを修正する度にクックブックアーカイブ作成してS3へアップロードするのはあまりに面倒くさいですよね。
さらには現場でクックブックを格納しているGitリポジトリがあるとしたら
ブランチをmaster, stage, developと各環境に沿って作成し
それらのブランチごとにクックブックアーカイブがS3に格納されているのが望ましいです。

これらの作業は自動化してしまいしょう。

自動化手順

自動化する為にここではTravis CIというCIツールを使用します。
Travis CIでなくてもGithubと連携できるCIツールであれば可能だと思いますのでお試しください。

自動化の前提としてクックブックのGitリポジトリもGitフローに沿ってブランチを切って開発しているとします。
そしてmaster, stage, develop等それぞれのブランチのクックブックは各環境(スタック)で参照するようにしましょう。

例えばmasterブランチは、S3にはmaster.tar.gzというクックブックアーカイブがあり本番環境用のスタックで参照する。
stageブランチであればstage.tar.gzというクックブックアーカイブを検証環境用のスタックで参照する、といった具合です。

よって自動化のゴールは
指定したブランチにソースがマージされた時に自動的にクックブックアーカイブを作成してS3にアップロードする
です。

Travis CI設定ファイル(.travis.yml)を作成

Travis CIを使うにはまず.travis.ymlという設定ファイルを作成する必要があります。
クックブックリポジトリのルートディレクトリに以下の.travis.ymlファイルを置いてください。
このままコピペするだけで完成です。

どのような設定をしているのか順に説明します。

ブランチ指定

最初のbranches~の部分はどのブランチにマージされた時にTravisを実行するか指定するための記述です。
ここではmaster,stage,developブランチを指定しています。
この指定をしておくことで、余計なアーカイブを作成せずに済みますので、なるべく記述することをおすすめします。

S3設定

TravisでS3にファイルアップロードする為の設定を行います。
公式ドキュメントはこちらです。
Uploading Artifacts on Travis CI

アップロード先のS3バケットのリージョンを指定します。
バケットが東京リージョンであれば「ap-northeast-1」、もしそうでないなら指定を変更してください。

アップロード元のクックブックアーカイブのファイルパスを指定します。
ここではわかりやすいようにブランチにちなんだファイル名とする為「$TRAVIS_BRANCH.tar.gz」とします。
※$TRAVIS_BRANCHはTravisでの対象ブランチ名を指す変数

アップロード先のS3バケット内でのファイルパスを指定します。
もしtarget_pathsを指定しない場合、デフォルトでGitリポジトリ名のディレクトリも含んだ
かなり深い階層に配置されますのでご注意ください。
シンプルにバケット内直下に収める為に”./”を指定します。

実行コマンド設定

最後にTravisで実行するコマンド、つまりクックブックアーカイブを作成するまでの処理を設定します。

アーカイブを作成するには前述した通りBerkShelfをインストールしなければなりません。
まずrubyをインストールした後、gemでBerkShelfを落としましょう。

仕上げにberks packageでアーカイブを生成します。

Travis CI実行対象リポジトリの各種設定

もちろん.travis.ymlをGitにプッシュしただけではTravisは実行されません。
Travis CIの管理画面でクックブックのリポジトリで諸々の設定が必要となります。

まずリポジトリ設定画面へ移動する為、管理画面でクックブックのリポジトリを指定します。
次に以下のように画面右上に表示される「More options」ボタンを押すと各種メニューが表示されるので
一番上にある「Settings」をクリックしてください。

Travis実行タイミング設定

設定画面の上部ではこのように設定します。

特に重要なのが
Build branch updatesをONにしてBuild pull request updatesをOFFにします。
Build branch updatesは対象のブランチが更新された時にTravisを実行するかどうかです。
例えばfeatureブランチからdevelopブランチへのプルリクエストを作成した後マージした時にこの設定をONにしておかないと
developブランチのクックブックアーカイブはS3にアップロードされません。

Build pull request updatesはGitHubのプルリクエストが更新された時にTravisを実行するかどうかです。
これがONになっているとプルリクエストをマージする前に
修正をマージ元ブランチにプッシュする度にTravisが無駄に実行されますのでOFFにします。

S3アップロードに必要な認証情報設定

最後にS3アップロードに必要な認証情報を設定します。

必要となるのは
ARTIFACTS_KEY=(AWS access key id)
ARTIFACTS_SECRET=(AWS secret access key)
ARTIFACTS_BUCKET=(S3 bucket name)
の3つです。

これも公式ドキュメントに記載していますのでご参照ください。
Uploading Artifacts on Travis CI

以上でTravis CIによってOpsWorksスタックで参照するクックブック作成を自動的に行える様になりました!

前回からの記事と併せて、OpsWorksを使用しているプロジェクトでHTTP/2に移行するには
このような手順が必要になるということがお分かり頂けたかと思います。

それでは良きHTTP/2ライフを!

おすすめ記事