Twitter Facebook github

Category “インフラ”

Amazon Linux に php7.1 をインストール

昔の記事 Amazon Linuxで nginx + php7 環境構築 を見返しつつセットアップを進めていたら、どうやら今はphp7.1系がリリースされているとのこと。

基本的に同じremi-php70のリポジトリで7.1のphpも参照できるようなので、特に難しいことはないですが備忘録として簡単にメモ。

nginx、php-fpm 諸々は古い記事をご参考ください。

雑な記事を量産しないようにしたい

Elastic Beanstalk にEB CLIから簡単デプロイ

ごぶさたです。
今趣味で作っているプロダクトのテスト環境を、AWS Elastic Beanstakで実装してみたので備忘録をば。

Beanstalk でのデプロイメント

AWS Elastic Beanstalk (以下EB) で構築した環境へデプロイするには、ソースコード一式をzipに固めたソースバンドルファイルを作成し、マネジメントコンソール等からアップロードします。
この方法ではデプロイの度に手作業でzipアーカイブを作成しなくてはならず、CI環境を構築した自動化を行わない限り、毎回のデプロイに待ち時間が発生してしまいます。

もっと簡単にデプロイするために、今回は gitとEB CLIを使ったデプロイメントを紹介します。

gitを使ったデプロイといえば、SalesforceのHeroku等もPaaSとして有名なのですが、まさにソースバンドルのバージョン管理等も似た感覚で利用できます。Herokuと違い、直接インスタンスへのSSHも可能なので何か問題が発生したときも簡単に対応できます。

Read More »

Amazon Linuxで nginx + php7 環境構築

以前書いた「nginx + php7 + Lumen な開発環境をVagrantでつくる」をAmazon Linuxに持って行くときの補填記事です。

AmazonLinuxはCentOS 6系ライクだから、EC2に持って行くことを前提とするならVagrantの開発環境も6系で作った方が良かった気がしている。。

ベースは上の記事内で紹介している通りだから、ここではAmazon Linuxで構築するときのコマンドを差分として備忘録に。

nginxはそのままインストール

違いとしては、Amazonのリポジトリがデフォルトで提供してくれているから、nginxのリポジトリをインストールする必要がなくなった。ちょっぴり楽に。

Read More »

Let’s Encrypt の証明書を更新した

(関連記事: Let’s Encryptをnginxで使ってみる

SSLの更新時期を思い出した

ウソです忘れてました。忘れてたところ、こんなメールが先週届いていました。

これはありがたい・・・本当にエラーになってから思い出すところでした。

本体のアップデート

3ヶ月ぶりなので、まずはLet’s Encrypt本体をアップデートしておきます。

Read More »

VagrantでEC2をプロバイダとして使う

Vagrantは基本的にVirtualBoxみたいな仮想化ソフトウェアをローカルにインストールして使っている人が多いと思いますが、この仮想化ソフトウェアのことをプロバイダと呼びます。Vagrant AWS Providorプラグインを使うことにより、AWS EC2をプロバイダとして使うことができます。

結構あちこちで解説されているネタでもあるので備忘録的なsomethingとして軽く流します。
なお、AWSについての知識も少なからず必要になるので、事前にVPCとEC2を触って知識をつけてから試すことをおすすめします。

環境

以下の環境が既にインストール済み
– Mac OS X El Capitan 10.11.3
– Vagrant 1.7.4

Read More »

ELBに証明書を登録できない時はAWS CLIを試す

AWS ELBに証明書を登録しようとしたときにエラーになったので、その回避策をメモ。

AWS ELBではHTTPSで行われた通信をELBデコードして、バックエンドのサーバーとはHTTPで通信することができます。
こうしておくと証明書更新などで複数台のEC2を直接手を入れることなく、またウェブサーバー側のSSL通信に関わるオーバーヘッドも無くなるため、AWS内で構築する場合には採用することが多いかと思います。

この構成を取る場合、証明書、証明書の秘密鍵をELBにアップロードする必要があります。

Read More »

CloudWatchのアラームをSlackに通知する

以前から挑戦したかったAWSの課題のひとつを解決してみようと思います。

AWS EC2やRDSなどのステータスを監視してアラームを上げてくれる、大変便利なCloudWatchですが、管理コンソール以外からアラームを確認する方法としては、SNSトピックに通知した後に自分でSNS連携のアプリケーションを作るなどして対応する必要がありました。

今回はこのアラームを、Slackの任意のチャンネルにポストすることをゴールにしてみます。

Read More »

VagrantのゲストOSから名前解決できない件

昔の記事「Vagrant+Chef-Zero入門」でprovisionを行おうと思い、vagrant upしたところ、次のエラーでプロビジョニングがコケました。

よく見るとinline scriptとchef両方でコケてる

inline script はゲストOSにchefをインストールするスクリプトで、opscode.comからダウンロードしてくるのですが、3行目でこれが失敗しています。
原因はホストアドレスの名前解決ができなかったようですね。

chefがインストールできていないので、chef provisionがコケるのは当然なのですが、14行目でも network is unreachable ということで、ゲストOSから名前解決が正しくできていないために、インターネットに出て行けなかったのではないかと推測できます。

解決策

ゲストOSから名前解決がうまくいかないとき、ホストOSで名前解決するようプロキシする設定にすることが可能なようで、VirtualBoxの NAT Networking settings に詳細が記載されていました。

https://www.virtualbox.org/manual/ch08.html#idp46608649138592

今回はこの設定の中の natdnshostresolver をVagrantfileから有効にします。

vagrant up でVMを立ち上げ直すと、正しく名前解決が行われるようになります。

このオプションを有効化することによる副作用はなさそうなので、配布する場合は付けておいたほうがよさそうです。

所感

この原因が解明できておらず曖昧なのですが、Vagrantを使っているとネットワーク周りの問題にはよく遭遇します。
自分の中でネットワークに関しては知識面において弱点でもあるので、克服できるように精進したいと思います。

余談ではありますが、本記事内や以前の記事で書いた opscode.com は chef.io に引っ越しが行われており、古いドメインでもリダイレクトされますが、DNSルックアップが2度走ることになるので気になる方は新しい方を参照するように修正すると良いでしょう。

デプロイ用ユーザーの在り方を考える

たいそうなタイトルだけど実際そんなことない。思ったより長くなってしまったのでお時間のあるときにどうぞ。

 

今までWordPressのデプロイにはrsyncを使って同期させていたんですが、WordPress専用のRuby製デプロイツール、WordMoveを使ってみようと思い立ちこちらの記事を参考にしながら準備しました。

WordMoveはSSHやFTPでログインしてファイルを置き換えるために、ログインユーザーがドキュメントルート以下への書き込み権限を持っていないとデプロイできません。

前述の参考記事ではドキュメントルート以下の所有者と、ウェブサーバーの実行ユーザーをec2-userに変更する荒技で解決しています。ここが自分の中でめちゃくちゃ引っかかったので、セキュリティ的により良いと考える権限管理ついて書いてみます。

(後から調べたことですが、Red Hatが共有ディレクトリのベストプラクティスとして提案していたようです。)

 

今回のゴール

  • デプロイ用の専用ユーザーを作り、WordMoveはデプロイ用のユーザーからデプロイを実施する
  • ウェブサーバーの実行ユーザーは変更しない(apacheまたはnginx)
  • 上記のままうまく回るようにユーザーとディレクトリのパーミッションを変更する

 

デプロイ元の環境で鍵ペアを作る

今回はVCCWを使ったVagrant内のWordMoveを使います。特にWordMoveはrootになって使う必要もないので、今回はvagrantユーザーで鍵を作ります。

秘密鍵のパスフレーズは必要に応じて設定してください。

ssh-keygenコマンドで鍵ペアが生成されますが、触れていいのは ~/.ssh/id_rsa.pub のように最後にpubが付いたものだけです。これがWordMoveの公開鍵になるので控えておきます。なお、当然ですが ~/.ssh/id_rsa は秘密鍵です。これを漏らしてしまうとデプロイ対象のドキュメントルート以下を丸々書き換えることができてしまうので、十分に気をつけてください。

 

デプロイ用のユーザーを準備する

ここでは deployer という名前で作成します。

 

デプロイユーザーが対象のディレクトリに書き込めるようにする

今回のデプロイ対象はウェブサーバーの実行ユーザーが所有しているドキュメントルートです。

今回はnginxを使っており、所有権はnginx:nginxです。戦略としては、nginxのグループにdeployerユーザーを追加し、ドキュメントルート以下のディレクトリに対してグループ内からの書き込み権限を付与します。

 

これで終わり…なら簡単で、記事にすることもないんですが、2つ問題があります。

deployerでファイルの編集をしてみます。問題なくできます。

 

次はデプロイ先にないファイルをデプロイしてファイルを作成することを想定してtouchしてみます。

次にパーミッションをチェックします。

1つめの問題です。このように、新規でファイルを作成してしまうと所有権は deployer:deployer になってしまいます。deployerグループにnginxを追加してしまう方法もありますが、一貫性が無くなってしまう上に、何かグループに対して権限を付与する際にも複数のグループを気にすることとなり運用コストが高まります。

これを解決する方法として特殊なパーミッションビット、setgidを使います。

 

setgidを理解する

setgidというのは、setuid, setgid, sticky bit と並んで紹介されることの多いLinux系ファイルシステムにおける特殊なパーミッションビットのことです。今回はsetuidとsticky bitは使わないので省略します。

setgidはset group idの略で、このパーミッションを有効にしたディレクトリ内でファイルやサブディレクトリを作成すると、setgidを付与したディレクトリと同じグループが所有グループとなります。グループを継承することができるということです。

setgidはchmodコマンドで g+s を指定することで設定できます。

チェックしてみます。

デフォルトでグループがnginxに割り当てられています。

今度こそ終わり… と思ったら、新しく作られたファイルのグループはnginxになっていますが、よく見るとグループへの書き込み権限がありません。2つめの問題です。

 

デフォルトパーミッションを変更する

ここまでで、ファイルやディレクトリを作成したときに所有グループを継承できるようになりました。最後は、デフォルトのパーミッションでグループに書き込み権限を付与することです。これにはumaskを使います。

umaskは許可*しない*ビットを指定する方法なのでかなり柔軟に設定できます。デフォルトではumask 022(=新規ファイルは644、自分だけ書き込み可)になっていますので、今回はumask 002(=664、自分とグループの人が書き込み可)に変更したいわけです。

今回はdeployerユーザーにumask 002を付与したいので、deployerユーザーの .bash_profile を利用します。

テストしてみます。ただし、sudo -u deployerを使うとrootのログインシェルに入ってしまいumask 022が適用されてしまいますので、su – を使います。

新規ファイルも664のパーミッションで、グループを継承できました!念のためにサブディレクトリを作って、その中でファイルを作っても同様の結果になることを確認しておきましょう。テストが済んだらテスト用ファイルはすべて消しておきます。

 

WordMoveでデプロイしてみる

今回はWordMoveを使っていますがWordMoveの紹介ではないので簡単に。実際にdeployerユーザーを使ってデプロイしてみます。

Pulling Databaseで、サーバー側でmysqldumpが効かなくて一度コケましたがmysqlをyumで入れて解決しました。

ちゃんとプッシュできていることを確認して終わりです。お疲れ様でした。

 

雑感

ここまで書いておいて何ですが、本当はこのように役割ごとにユーザーを切り分けるべきだと信じています。ただめちゃくちゃ面倒くさくて、最後デプロイツールでも一工夫必要なことを考えると、同一ユーザーでやってしまいたくなるのもとても分かります。難しいですね。

nginxでHTTP/2ことはじめ

このエントリを書いているうちにクリスマスイブになりましたね。いよいよ年末ムードですが、今年は年の瀬ギリギリまでお仕事です。クリスマスなんて無かった

前回のエントリの最後でHTTP/2, SPDYやりたいって書いたので有言実行ということで。この記事は既にstable(1.8)なnginxでSSLサイトを構築している環境が前提になります。

 

一昔前にGoogleが開発した次世代WebプロトコルのSPDYが流行っていましたが、SPDYを受け継いだHTTP/2の出現から、新たにSPDYを導入することはほとんどないようです。

Google自身もHTTP/2へ移行したようですので、今回はSPDYではなくHTTP/2を使ってみようと思います。cssやjs、画像などを多くロードしているページでは、表示速度がかなり向上するようですよ。

nginxでhttp/2を導入する場合は、–with-http_v2_module というパラメータをつけてビルドしないといけません。ただ、nginx公式のリポジトリから落とせるバイナリはこのパラメータ付きでビルドされているようですので、今回はこれを使う方針で進めます。(ちなみにSPDYは古いnginxで利用できていましたが、HTTP/2に載せ替えられる形で使えなくなりました。)

 

古いnginxの削除

まずは今インストールされているバージョンを確認します。

執筆時点のAmazon Linuxで標準のリポジトリからyumでインストールすると、上の通りstableな1.8がインストールされます。nginxは今年の9月末にリリースされたv1.9.5でHTTP/2をサポートするようになったので、1.8.0のnginxは削除します。

 

メインラインnginxをインストール

前述の通り標準のリポジトリからインストールすると1.8が落ちてきてしまいます。メインラインのnginxをインストールするには、公式のドキュメントを参考にnginxのリポジトリを参照するように変更します。

正しくメインラインのnginxが取得できるか確認し、問題なければインストールします。今回はnginx.repoにpriority=1を追記したので、Amazon標準リポジトリよりnginxリポジトリが優先して参照されます。このほかyumのコマンドに –disablerepo=amzn-main を記述することでもインストール可能ですが、yum updateなどで問題になることがあるので特に理由がなければ優先度を変更しましょう。

すんなりインストールできました。念のために自動起動の設定を確認しておきましょう。

 

http2の設定

次は1.9.9のnginxでhttp2を使えるようにします。

今回は1.8系のnginxからの乗り換えなので、古いnginxをremoveした時に残っている設定ファイルをベースに書き換えていきます。

SSLは前回設定していますので、書き換えるのはここだけですね。本当に簡単です。

なお、http2はSSLなしでも利用できる仕様ですが、事実上SSL対応しないと使えませんので、SSLに対応していない場合は過去のエントリ「Let’s Encryptをnginxで使ってみる」などをご参考ください。

 

動作確認する

ちゃんとHTTP/2で通信してくれているかどうかは、Chromeの場合デバッグ機能のnet-internalsを開くことで確認できます。新しいタブで、

chrome://net-internals/#http2

を開いてみてください。

HTTP/2 sessionsのテーブルに、今回対応したドメインが表示されていればうまく動いています。

スクリーンショット 2015-12-24 2.55.28

 

また、Chrome Extensionの「HTTP/2 and SPDY indicator」もオススメです。これをインストールしておくと、ブラウズしているページがHTTP/2またはSPDYに対応しているかどうかをURLバー右側の雷アイコンで視覚的に表示してくれます。

表示されている雷アイコンが青色であればHTTP/2、緑色であればSPDY、灰色であればこれらのプロトコルに対応していないことを表します。正常に動いているようですね。

 

雑感

数年前にSPDYで賑わったことは比較的記憶に新しいのですが、暫くその動向を追っていない間にHTTP/2が策定され移行が進んでいるようです。Web技術の変革スピードの早さを再認識しました。時代に取り残されないよう、新しい技術も積極的にキャッチアップしていきたいですね。