Onishiお久しぶりです。最近またAWSのサービスを一通り触ってみていて、プロビジョニングまでAWSマネージドでやってくれるOpsWorksを本番環境で使ってみたいと思い、Chefに取り組んでいます。いうgemのツールがあるのですが、これを初めて使ってみたところ非常に使い勝手がよく、当然ながらEC2でも試したいという気になりました。EC2を扱える、kitchen-ec2を使ってみます。DKに付いてくるので真っ新な環境ではこっちを入れた方がよいと思います。認証情報を設定kitchen-ec2では、AWSの認証情報(APIキーとトークン)は環境変数か、aws-cliの認証情報から読み込むことになります。行ってAPIキーを登録してください。設定https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-getting-started.htmlインストールと準備ChefDKで入れたtest-kitchenにはkitchen-ec2は付いてこないので、個別にgemで入れます。kitchen-ec2適当なディレクトリでmetadata.rbを作り、それを元にinitし、サンプルとして、適当なディレクトリを作成するレシピを用意します。見返しつつセットアップを進めていたら、どうやら今はphp7.1系がリリースされているとのこと。基本的に同じremi-php70のリポジトリで7.1のphpも参照できるようなので、特に難しいことはないですが備忘録として簡単にメモ。これらはそのままインストール可能。諸々は古い記事をご参考ください。Onishiごぶさたです。Beanstakで実装してみたので備忘録をば。構築した環境へデプロイするには、ソースコード一式をzipに固めたソースバンドルファイルを作成し、マネジメントコンソール等からアップロードします。この方法ではデプロイの度に手作業でzipアーカイブを作成しなくてはならず、CI環境を構築した自動化を行わない限り、毎回のデプロイに待ち時間が発生してしまいます。CLIを使ったデプロイメントを紹介します。gitを使ったデプロイといえば、SalesforceのHeroku等もPaaSとして有名なのですが、まさにソースバンドルのバージョン管理等も似た感覚で利用できます。Herokuと違い、直接インスタンスへのSSHも可能なので何か問題が発生したときも簡単に対応できます。Linuxに持って行くときの補填記事です。6系ライクだから、EC2に持って行くことを前提とするならVagrantの開発環境も6系で作った方が良かった気がしている。Linuxで構築するときのコマンドを差分として備忘録に。nginxはそのままインストール違いとしては、Amazonのリポジトリがデフォルトで提供してくれているから、nginxのリポジトリをインストールする必要がなくなった。Encryptをnginxで使ってみる)SSLの更新時期を思い出したウソです忘れてました。忘れてたところ、こんなメールが先週届いていました。これはありがたい・・・本当にエラーになってから思い出すところでした。Encrypt本体をアップデートしておきます。OnishiVagrantは基本的にVirtualBoxみたいな仮想化ソフトウェアをローカルにインストールして使っている人が多いと思いますが、この仮想化ソフトウェアのことをプロバイダと呼びます。EC2をプロバイダとして使うことができます。あちこちで解説されているネタでもあるので備忘録的なsomethingとして軽く流します。AWSについての知識も少なからず必要になるので、事前にVPCとEC2を触って知識をつけてから試すことをおすすめします。ELBに証明書を登録しようとしたときにエラーになったので、その回避策をメモ。ELBではHTTPSで行われた通信をELBデコードして、バックエンドのサーバーとはHTTPで通信することができます。しておくと証明書更新などで複数台のEC2を直接手を入れることなく、またウェブサーバー側のSSL通信に関わるオーバーヘッドも無くなるため、AWS内で構築する場合には採用することが多いかと思います。秘密鍵をELBにアップロードする必要があります。Onishi以前から挑戦したかったAWSの課題のひとつを解決してみようと思います。EC2やRDSなどのステータスを監視してアラームを上げてくれる、大変便利なCloudWatchですが、管理コンソール以外からアラームを確認する方法としては、SNSトピックに通知した後に自分でSNS連携のアプリケーションを作るなどして対応する必要がありました。今回はこのアラームを、Slackの任意のチャンネルにポストすることをゴールにしてみます。upしたところ、次のエラーでプロビジョニングがコケました。ゲストOSにchefをインストールするスクリプトで、opscode.comからダウンロードしてくるのですが、3行目でこれが失敗しています。原因はホストアドレスの名前解決ができなかったようですね。いうことで、ゲストOSから名前解決が正しくできていないために、インターネットに出て行けなかったのではないかと推測できます。詳細が記載されていました。Vagrantfileから有効にします。VMを立ち上げ直すと、正しく名前解決が行われるようになります。このオプションを有効化することによる副作用はなさそうなので、配布する場合は付けておいたほうがよさそうです。所感この原因が解明できておらず曖昧なのですが、Vagrantを使っているとネットワーク周りの問題にはよく遭遇します。自分の中でネットワークに関しては知識面において弱点でもあるので、克服できるように精進したいと思います。引っ越しが行われており、古いドメインでもリダイレクトされますが、DNSルックアップが2度走ることになるので気になる方は新しい方を参照するように修正すると良いでしょう。Onishiたいそうなタイトルだけど実際そんなことない。思ったより長くなってしまったのでお時間のあるときにどうぞ。今までWordPressのデプロイにはrsyncを使って同期させていたんですが、WordPress専用のRuby製デプロイツール、WordMoveを使ってみようと思い立ちこちらの記事を参考にしながら準備しました。WordMoveはSSHやFTPでログインしてファイルを置き換えるために、ログインユーザーがドキュメントルート以下への書き込み権限を持っていないとデプロイできません。前述の参考記事ではドキュメントルート以下の所有者と、ウェブサーバーの実行ユーザーをec2-userに変更する荒技で解決しています。ここが自分の中でめちゃくちゃ引っかかったので、セキュリティ的により良いと考える権限管理ついて書いてみます。Hatが共有ディレクトリのベストプラクティスとして提案していたようです。)今回のゴールデプロイ用の専用ユーザーを作り、WordMoveはデプロイ用のユーザーからデプロイを実施するウェブサーバーの実行ユーザーは変更しない(apacheまたはnginx)上記のままうまく回るようにユーザーとディレクトリのパーミッションを変更するデプロイ元の環境で鍵ペアを作る今回はVCCWを使ったVagrant内のWordMoveを使います。WordMoveはrootになって使う必要もないので、今回はvagrantユーザーで鍵を作ります。~/.ssh/id_rsa.pub秘密鍵のパスフレーズは必要に応じて設定してください。ように最後にpubが付いたものだけです。これがWordMoveの公開鍵になるので控えておきます。これを漏らしてしまうとデプロイ対象のドキュメントルート以下を丸々書き換えることができてしまうので、十分に気をつけてください。いう名前で作成します。authorized_keysを保護デプロイユーザーが対象のディレクトリに書き込めるようにする今回のデプロイ対象はウェブサーバーの実行ユーザーが所有しているドキュメントルートです。今回はnginxを使っており、所有権はnginx:nginxです。戦略としては、nginxのグループにdeployerユーザーを追加し、ドキュメントルート以下のディレクトリに対してグループ内からの書き込み権限を付与します。グループに書き込み権限を与えるこれで終わり...なら簡単で、記事にすることもないんですが、2つ問題があります。deployerでファイルの編集をしてみます。/usr/share/nginx/html/index.php次はデプロイ先にないファイルをデプロイしてファイルを作成することを想定してtouchしてみます。/usr/share/nginx/html/index-new.php次にパーミッションをチェックします。index-new.php1つめの問題です。deployerグループにnginxを追加してしまう方法もありますが、一貫性が無くなってしまう上に、何かグループに対して権限を付与する際にも複数のグループを気にすることとなり運用コストが高まります。これを解決する方法として特殊なパーミッションビット、setgidを使います。並んで紹介されることの多いLinux系ファイルシステムにおける特殊なパーミッションビットのことです。bitは使わないので省略します。idの略で、このパーミッションを有効にしたディレクトリ内でファイルやサブディレクトリを作成すると、setgidを付与したディレクトリと同じグループが所有グループとなります。グループを継承することができるということです。指定することで設定できます。/usr/share/nginx/html/index-new2.phpチェックしてみます。index-new2.phpデフォルトでグループがnginxに割り当てられています。思ったら、新しく作られたファイルのグループはnginxになっていますが、よく見るとグループへの書き込み権限がありません。デフォルトパーミッションを変更するここまでで、ファイルやディレクトリを作成したときに所有グループを継承できるようになりました。最後は、デフォルトのパーミッションでグループに書き込み権限を付与することです。これにはumaskを使います。umaskは許可*しない*ビットを指定する方法なのでかなり柔軟に設定できます。002(=664、自分とグループの人が書き込み可)に変更したいわけです。002テストしてみます。index-new3.php新規ファイルも664のパーミッションで、グループを継承できました!念のためにサブディレクトリを作って、その中でファイルを作っても同様の結果になることを確認しておきましょう。テストが済んだらテスト用ファイルはすべて消しておきます。WordMoveでデプロイしてみる今回はWordMoveを使っていますがWordMoveの紹介ではないので簡単に。実際にdeployerユーザーを使ってデプロイしてみます。Databaseで、サーバー側でmysqldumpが効かなくて一度コケましたがmysqlをyumで入れて解決しました。--themesちゃんとプッシュできていることを確認して終わりです。雑感ここまで書いておいて何ですが、本当はこのように役割ごとにユーザーを切り分けるべきだと信じています。面倒くさくて、最後デプロイツールでも一工夫必要なことを考えると、同一ユーザーでやってしまいたくなるのもとても分かります。