今年参加するアドベントカレンダー

ansible のソースコードを実行する

ansible のソースコードを直接実行したい

  • 頻繁にバージョンを切り替えたり、なんなり色々したい

誤り検出についての整理

誤り制御について頭の中を整理〜。誤り制御の方法は以下の二つ。

  1. 誤り検出 により再送
  2. 誤り訂正 により自己修復

参考資料

誤り検出: パリティチェック

  • 誤り検出用のパリティビットを付加してデータの整合性を検査する方法
    • 偶数パリティ: データの和が偶数になるようにパリティビットを付加する
    • 奇数パリティ: データの和が奇数になるようにパリティビットを付加する

例えば、7bitデータを送出する場合に偶数パリティを採用するとすれば以下のように、パリティビットを付加すればよい

[0,0,0,0,0,0,0] [0] ← パリティビット
[0,1,0,0,0,0,0] [1]
[0,1,1,0,1,0,0] [1]

VRC(Vertical Redundancy Check) – 垂直パリティ

  • キャラクタ単位でパリティチェックを行う

偶数パリティの場合8bit目をパリティビットとすれば次のような感じ

LRC(Longitudinal Redundancy Check) -水平パリティ

  • 伝送した文字列の終端に Block Check Character(BCC) と呼ばれる誤り検出のためのキャラクタを付加する
  • 伝送した各ビットの正当性を確認することによりキャラクタ単位ではなく文字列全体のなかに誤りがあることを検査することができる

偶数パリティの場合以下のような具合で

群係数チェック

  • 水平方向の和の下2桁を取り、下位ビットのチェックビットとする

偶数パリティであれば以下のような具合

CRC(Cyclic Redundancy Check) – 巡回冗長検査

  • バースト誤りを検出できるのが特長的
  • 書いてる途中で飽きた(続き暇なときにまとめる)

play 2.5 のアレコレ

playがいろいろと変わっているので、いろいろと走り書き

logback.xml を使え

  • WARN がうるさい
  • logback.xml という名前でとりあえず次のようなファイルを作っとけばOK
  • https://www.playframework.com/documentation/2.5.x/SettingsLogger

GlobalSettings それ死んだよ

  • ドキュメント曰く、ライフサイクル系は Guice の eagerSingleton に便乗して実現するっぽい
  • JDBCConnectionPoolまわりなんかもここで Application が Inject されることを期待して、記述すればよいっぽさ
  • https://www.playframework.com/documentation/2.5.x/ScalaDependencyInjection#Stopping/cleaning-up

sbt 0.13.12 から build.sbt 使え

  • https://github.com/sbt/sbt/pull/2530
  • nrhd…

Apache Bench

使う機会があったのでサクッとメモ

導入

使い方

terraform を使ったAWS構成管理 ハンズオン

terrafrom は、インフラの構築や設定などをコードで表現して管理できるようにするツールです。AWS や Azure、 Heroku など様々な環境に対応しています。

この資料はラビットハウス社内で開催される、 AWS リソースを terrform で管理するためのハンズオン向けに作成した資料になります。AWS 構成管理をコードで管理したいなどと思っている方のなかにも、こういったツールが面倒臭そうだとか、すぐ使えなくなってしまいそうだとお思いの方が多いかと思いますが、 terraform の挙動はとてもシンプルで学習コストはものすごい低いツールです。また AWS 構成をコード化することでより深く AWS について理解することできる側面もあると考えています。

是非この機会に terraform に入門してみませんか…? この記事の通りにコマンドを入力していけば、きっとあなたも1時間もしないうちに terraform を使いこなせるようになっているでしょう。

1. 環境構築

このハンズオンでは terraform v0.7.4 を前提として話を進めます

Mac の場合

Windows の場合

https://www.terraform.io/downloads.html

AWS 側の準備

あらかじめterraformで用いるIAMユーザーを作成しておきましょう

  1. IAM ユーザー管理ページにアクセス
  2. 新規ユーザーの作成
  3. 必要なポリシーのアタッチ
  4. access_key, secret_key の作成

2. S3 bucket を管理する

まずは S3 bucket を作ったり変更したり壊したりして遊んでみましょう。下準備として、適当な作業用ディレクトリを作成してください。次に AWS リソースにアクセスするための設定を書きます。

2-1. S3 bucket を作る

早速 S3 bucket を作ってみましょう。次のようなファイルを作成してください。ただし bucket の名称はグローバルで一意になるように定めてください。

以上のようなファイルを作ったら、terraform validate で正しい .tf ファイルを記述できているかを確認してみましょう。きっと上記の通りに書けば問題なくコマンドが通ると思います。

つづいて terraform plan コマンドで、これからどのようなことが実行されるのかを確認します。この操作は常に安全で、AWSに対して情報の読みとり操作しか行われません。

+ aws_s3_bucket.terraform_tutorial とあるように S3 の bucket が作成されることが確認出来たので terraform apply コマンドで実際に実行してみましょう。

無事、成功したようですので、とりあえず aws cli から s3 bucket が本当に存在するのか確認してみましょう。

ちゃんと s3.tf ファイルで指定した com.github.53ningen.terraform.tutorial という名前の bucket ができていることがわかります。さて、terraform apply が無事に成功したあとには terraform.tfstate というファイルができていると思います。

このファイルの中身はリモート(今の場合AWS)の状態を保存するファイルになります。この中にはアクセスキーやシークレットキーがふくまれているため、git 管理対象外にしておきましょう。このファイルの管理についてはのちほど 「remote state の管理」の節でご説明します。とりあえず以下のような .gitignore ファイルを追加しておきましょう。

2-2. S3 bucket の状態を変更する

さきほど作った S3 bucket はバージョニングが有効になっていますが、これを無効にしてみましょう。s3.tf を次のように修正します。

続いて terraform validate コマンドで tf ファイルのシンタックスを検証し、 terraform plan で AWS リソースに対してどうのような変更が行われるか確認しましょう。

Plan: 0 to add, 1 to change, 0 to destroy. とあるので、既存の S3 は削除されず、表示されたパラメータのみが変更されることがわかります。確認をしたら apply をすれば S3 の状態の変更は完了です。

2-3. S3 bucket を破棄する

さて、いままでチュートリアルとして S3 bucket を作成してきましたが、不要なので削除しておきましょう。terraform destroy コマンドを使えば OK ですが、この操作もやはり実行する前に確認しておきたいものです。そんな場合はまず terraform plan --destroy を実行してみましょう。これで terraform destroy 時の実行計画を見ることができます。

実行計画に問題がなさそうであれば、terraform destroy を実行してみましょう。

terraform destroy を実行すると本当にリソースを削除して良いのか聞かれます。yes と入力すると、ここまでに作った S3 bucket は削除されます。

2-4. tf ファイルをフォーマットする

terrform fmt でファイルをフォーマットできます

2-5. terraform 基本コマンドのまとめ

以上で terraform の基本的な 5 コマンドは理解できたかと思います。まとめると以下のようになります。

  • terraform validate: .tf ファイルのシンタックスを検証する
  • terraform plan: terraform がこれから行う実行計画を表示する。--destroy オプションで destroy 時の実行計画を表示できる。
  • terraform apply: plan を実行する。
  • terraform destroy: terraform で作ったリソースを破棄する
  • terraform fmt: tfファイルをフォーマットする

基本的には apply の前にかならず plan で実行計画を確認することを徹底してください。 destroy は実際にはほとんど使うことはないと思います。また、terraform.tfstate を git で管理したり、他人の目に触れるような状態にすることをお忘れなく。

3. remote state を管理する

terraform.tfstate ファイルはリモートの状態を管理するファイルです。apply が成功すると、どのようなリソースがどのようなパラメータで作成されたのかを細かく記録しています。

tfstate ファイルを誤って削除すると terraform はリモートにリソースが存在しないと認識して、tf ファイルに定義された構成を新規作成しようとしてしまいます。しがって何らかの形で、このファイルを管理する必要があるのですが、秘匿情報が多分に含まれているため単純に git で管理するわけにはいきません。

管理する方法は何通りかあるのですが、ここでは private な S3 bucket を使ってこのファイルを管理する方法をご紹介します。

3-1. tfsate管理用 S3 bucket の作成

S3 bucket の作成は前節でやったのでもうきっと理解できていると思います。復習がてらやってみましょう。remote_state.tf という名前で次のようなファイルを作ってみましょう。

terraform plan で実行計画を確認したのち、terraform apply で bucket を作成します。terraform 公式ドキュメントによると versioning を有効にすることが推奨されています。

3-2. tfstate管理設定を行う

無事 S3 bucket が作成されたら terraform remote config コマンドを使って tfstate ファイルの管理設定を行います。次のコマンドの bucketaccess_key などは自分のものに適宜変更してください。

ここで key というのは S3 上でどのような名前で tfstate ファイルを管理するかという指定になります。今コマンドが無事通るとカレントディレクトリにあった terraform.tfstate はきっと .terraform 下に移動するかと思います。

3-3. remote に tfstate を push する

さて、管理設定が無事おわったら S3 に tfstate ファイルを転送しておきましょう。

リモートへの terraform apply を行った場合は必ず terraform remote push を行いましょう。

3-4. remote から tfstate を pull する

普通にいかのような感じになります。複数人での開発で、他人が apply したあとの remote state を反映させたい場合などに使います。

4. より高度なリソース定義を行う

4-1. 変数を用いる

aws の access_keysecret_keyvariable.tf に直接書き込んでいますが、変数という機能を使えば、実行時に指定することができます。

このようにした上で、terraform plan を実行すると各パラメータとしてどの値をとるかを対話式に尋ねられます。

また、次のように変数のデフォルト値を指定しておくこともできます。

4-2. 環境変数を用いる

CLIから access_keysecret_key を毎回指定するのも面倒なので、環境変数を用いると楽そうです。terraform では TF_VAR_ というプレフィックスがついた環境変数を .tf ファイルの中で用いることができます。さっそく、これを用いて access_key, secret_key を環境変数から取ってくるように変更しましょう。

続いて variable.tf を以下のように変更しましょう

terraform plan を変数指定なしで利用できるようになっていれば、無事環境変数の利用ができているということになります。

4-3. 依存管理のあるリソース定義を行う

より複雑なリソースを構成するときには、リソース同士に依存関係が生じます。たとえば terraform で作成した IAM ユーザーにポリシーをアタッチしたいときに、リソース間に依存が生じていると思います。

いま、 IAM ユーザー cocoa さんを作成し IAMReadOnlyAccess ポリシーをアタッチしたいとします。その場合の .tf ファイルは以下のように記述すればOKです。

terraform plan を実行すると依存関係が解決されていることがわかるでしょう。

4-4. 設定ファイルを使う

複雑なリソースを管理するときには設定だけをまとめた設定ファイルが使えると便利そうです。 terraform には設定ファイルを使う仕組みも備わっています。今回は AWS のリージョン指定を設定ファイルに切り出しましょう。variable.tfregion 変数から default 値を削除してください。

そして config.tfvars という名前で次のように設定を記述しましょう。

あとは terraform planterraform apply 時に設定ファイルを指定してあげればOKです。設定ファイルの指定は -var-file= オプションを使います。

4-5. 出力を行う

terrform apply 後に作成されたリソースのARNが知りたい場合などは output という機能を使うとよいでしょう。たとえば先ほど作成した cocoa ユーザーのARNを出力させるには次のようにすれば OK です。

terraform plan, terraform apply を実行してみましょう

しっかりと ARN が出力されていることが確認できます。

5. モジュールと複数のステージへの対応

terraform はカレントディレクトリに置かれている .tf ファイルを実行するというとても単純なふるまいを持っています。しかし複数ディレクトリに構造化してファイルを保存したい場合や、複数のステージを作るためにパラメータだけ変えて呼び出したいなどさまざまに理由により、異なるディレクトリ下にあるものを呼び出したいことがあるでしょう。そのときに使えるのが、モジュールという機能です。

5-1. モジュールの利用の基礎

モジュールを試すためにまずは以下のようなディレクトリ構造を作りましょう。

modules に それぞれのリソースを定義していくことになります。今回はサンプルとして dev/prod 向きそれぞれの S3 bucket を作ってみましょう。まずは modules/s3/s3.tf の中身から。

続いて dev/modules.tf, prod/modules.tf というファイルにそれぞれ、modules/s3 以下のファイルを取り込んで実行するコードを書いてみましょう。modules という新たな構文を利用します。

最後に、dev/variable.tf, prod/variable.tf に対して、AWS を操作する設定値などを記述します。

これで準備が整いました。dev ディレクトリ下から実行すると dev 環境向けの構成、prod ディレクトリ下から実行すると prod 環境向けの構成を管理することができます。 dev 環境向けのリソースを実際に作ってみましょう。 dev ディレクトリに移動して、terraform get を実行して依存モジュールのコードを取り込みを前もってやっておく以外は、いままでと基本的には同じ操作で OK です。

5-2. 複数ステージへモジュールを用いたの対応例

このようなモジュールの機能を用いて dev や production など複数のステージ向けにデプロイできるように更生する場合、ディレクトリ構造として特に決まっているものはないのですが、優れたものとして以下のような形があるので、参考にしながら進めると良いと思います。

6. 既存のAWSリソースを terraform で管理する

6-1. terraforming の導入

terraforming は既存のAWSリソースにアクセスしてterraformのコードを生成してくれたり、tfstateを生成してくれたりするツールです。導入は Gemfile に次のように書いて、bundle install すればOKです。

6-2. 既存の IAM user を terraform で管理する

AWSアカウントを持っているほぼ全ての人は、すでに IAM user などのリソースを持っていると思います。従って、まずここを terraform で管理する形にしましょう。次のようにすると現在のIAM userリソースに応じたHCLが出力されます。

これをファイルに書き出しましょう。

またリモートの状態を手元の .tfstate ファイルに反映させるなければ、terraform はリソースを新規に作成しようとしてしまいます。そのために以下のようにしておきましょう。

terraforming iamu --tfstate --profile default --merge=.terraform/terraform.tfstate

出力をみて問題なさそうであれば、このコマンドに --overwrite オプションを付加して反映させます。こののちに terraform plan をして差分がでなければ、晴れて IAM user の管理を terraform に移行できたことになります。

terraform plan 時にもしも、 destroy されるリソースが表示されたとしたら、既存のリソースやシステムが破壊される可能性がありますので、特に慎重に操作してください。また、IAM policy などについては JSON の改行位置やインデントなどが差分として出やすいので、悩んだときはそのあたりが既存のポリシー設定と食い違っていないか確認することをお勧めします。

さて、terraforming はよく使われるほとんどの AWS リソースに対応しているため、まずはこれを使ってできるところまで terraform に移行すると良いでしょう。v0.7.0 では以下のようなものに対応しています。

6-3. terraform のコードを管理するリポジトリを作成する

個人アカウントのaws構成をopenなgithub repositoryに配置するのは、はばかられるので code commit リポジトリを作成しておくと良いでしょう。

code commit 上に作成したレポジトリにアクセスするためポリシーのアタッチ、ならびに公開鍵登録も terraform を使って行うことができます。

この状態で terraform plan, terraform apply をしてみます

すると以上のように作成された ssh_public_key_id が出力されるので、あとはこいつを ~/.ssh/config に反映させれば手元のマシンから作成した code commit レポジトリに疎通がとれるようになります。

6-4. terraform import

T.B.D

7. 構成管理方法の整理

7-1. 個人開発の場合

個人のAWSリソースを管理する場合は大きく分けて次の2つの方法があるかと思います

  • .tfstate ごと git で管理して、 code commit にぶちこむ
  • .tfstate は S3 で管理、コードは code commit で管理

7-2. チーム開発の場合

  • .tfstate はセキュリティ上の理由から S3 で管理することが望ましい
  • .tfstate やアクセスキーなどを含むものをコミットせず、GitHub Enterprise, code commit, GitHub private repository に push する

Jakarta Commons CLI

  • Jakarta Commons CLI
    • コマンドライン引数をパースしてというCLI(Command Line Interface)
    • Options: 受け取れるオプション
    • addOptionで受け取れる引数を追加していく
    • parser.parse(options, args)とするとパースした結果を得られる

phax/ph-cssを使う

phax/ph-css の使い方

b080e264-d67f-11e4-845e-c1f3fdff6678

便利

Protocol Buffers を PHP から使う

Protocol Buffers とは

JSON, XML などは人間の目に比較的優しい形 [要出典] でデータを表現することができます。その反面、データが大きくなったり、データ解析が複雑だったりします。

Protocol Buffers は、通信や永続化などを目的に、データサイズの小ささやパース時のパフォーマンスなどを追及したシリアライズフォーマットです。データ構造はあらかじめプロトコル定義ファイル(.proto)に定義をしておき、Google が配布している protoc プログラムによって、各プラットフォーム上でのシリアライザ・デシリアライザを含めた関連コードが自動的に生成できるようになっています。

したがって利用する際の基本的な手順は大雑把に次のようになります

  1. データ構造を IDL で定義した proto ファイルを作成する
  2. proto ファイルからProtocol Buffersの利用に必要なコード(シリアライザ・デシリアライザなどが含まれる)を生成する
  3. 生成されたコードを利用したコードを書く

データ構造をはじめに定義し、そのデータ構造に応じたコードをあらかじめ用意しておくあたりが、JSON, XMLなどと異なります。

環境構築

さて、PHPから Protocol Buffers を使うために環境構築を行いましょう。まずは protoc プログラムをインストールします。

また今回利用するPHPライブラリは pear の Console_CommandLine を必要とするため、これも入れます。

最後に PHP ライブラリを composer で導入します。

インターフェース定義ファイルの作成

Google の proto3 Language Guide を見ようみまねで、簡単なものを定義してみましょう。次のように search_request.proto ファイルを作成してください。

インターフェース定義ファイルは直感的でわかりやすいので、きっと解説はいらないでしょう…。

Protocol Buffers 利用のためのコード生成

composer でひっぱってきたファイルのなかに必要なコードの生成を補助してくれるファイルがあるので、それを使いましょう。

今、ディレクトリ構造が以下のような形だったと仮定します。

vendor/bin 下 に protoc-gen-php.php というファイルが存在しますが、これを使うと簡単に必要なコードを生成することができます。さっそく SearchRequest データ構造を PHP で扱うためのコードを生成してみましょう。

すると src/Dist/Protobuf 下に SearchRequest.php というファイルが生成されるはずです。

これで準備が完了しました。

Protocol Buffers を利用する

まずは SearchRequest のインスタンスを取得し、各フィールドをセットして、シリアライズしてみます。

以上のようなコードを実行すると以下のようなバイナリが出力されます。

バイナリサイズは 30 byte でした。対応する標準的なJSONだと 77 byte あるのでおよそ半分になっていることがわかります。

またデシリアライズは次のようなコードで可能です

`

実行すると次のようになります

ちゃんともとのPOJOを復元できていますね

PHPのアレコレ

たまにしかPHPを触らないので色々問題が発生する

Java, Scala のお仕事依頼お待ちしております → @gomi_ningen