awsでruby on railsとapacheとの連携構築方法

すべての手順

必要なミドルウェアのインストール

$ sudo yum update
$ sudo yum install curl-devel ncurses-devel gdbm-devel readline-devel sqlite-devel ruby-devel
$ sudo yum install gcc gcc-c++ openssl-devel zlib-devel make patch git gettext perl rpm-build libxml2

rbenvのインストール

$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
$ echo 'export PATH="$HOME/.rbenv/bin:${PATH}"' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ source ~/.bash_profile
$ env | grep RBENV
RBENV_SHELL=bash
$ rbenv --version
rbenv 1.1.0-2-g4f8925a

ruby2.4.0 のインストール

$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
$ rbenv install -l
.....
2.3.0-dev
  2.3.0-preview1
  2.3.0-preview2
  2.3.0
  2.3.1
  2.3.2
  2.3.3
  2.4.0-dev
  2.4.0-preview1
  2.4.0-preview2
  2.4.0-preview3
  2.4.0-rc1
  2.4.0
  2.5.0-dev
  jruby-1.5.6
  jruby-1.6.3
  jruby-1.6.4
  jruby-1.6.5
  jruby-1.6.5.1
...
$ rbenv install -v 2.4.0
$ rbenv rehash
$ rbenv global 2.4.0
$ ruby -v
 ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]

Railsのインストール

$ gem update --system
$ gem install bundler --no-rdoc --no-ri
$ gem install --no-ri --no-rdoc rails
$ rbenv rehash    
$ rails -v
Rails 5.0.2
$ gem install bundler

sqlite3のインストール

$ wget https://www.sqlite.org/2017/sqlite-autoconf-3170000.tar.gz
$ tar xvzf sqlite-autoconf-3170000.tar.gz
$ cd ./sqlite-autoconf-3170000
$ ./configure
$ make
$ make install
$ source ~/.bash_profile
$ rm -rf sqlite-autoconf-317000*
$ sqlite3 --version
; 3.17.0 2017-02-13.....

Hello World アプリ作成

$ cd ~
$ rails new hello_world
$ cd hello_world
$ vim Gemfile
$ bundle install
- # gem 'therubyracer', platforms: :ruby
+ gem 'therubyracer', platforms: :ruby
$ bundle exec rails s -e production
=> Booting Puma
=> Rails 5.0.2 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.8.2 (ruby 2.4.0-p0), codename: Sassy Salamander
* Min threads: 5, max threads: 5
* Environment: production
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop

apache2.4のインストール

$ sudo yum install httpd24 httpd24-devel

Passengerのインストール

$ gem install passenger
$ rbenv rehash
$ sudo dd if=/dev/zero of=/swap bs=1M count=1024
$ sudo mkswap /swap
$ sudo swapon /swap
$ passenger-install-apache2-module
.....
linking shared-object passenger_native_support.so

--------------------------------------------
Almost there!

Please edit your Apache configuration file, and add these lines:

   LoadModule passenger_module /home/ec2-user/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/passenger-5.1.2/buildout/apache2/mod_passenger.so
   <IfModule mod_passenger.c>
     PassengerRoot /home/ec2-user/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/passenger-5.1.2
     PassengerDefaultRuby /home/ec2-user/.rbenv/versions/2.4.0/bin/ruby
   </IfModule>

After you restart Apache, you are ready to deploy any number of web
applications on Apache, with a minimum amount of configuration!
....

Apacheの設定

$ sudo chown -R apache. ~/hello_world

$ sudo vim /etc/httpd/conf.d/passenger.conf
+   LoadModule passenger_module /home/ec2-user/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/passenger-5.1.2/buildout/apache2/mod_passenger.so
+   <IfModule mod_passenger.c>
+     PassengerRoot /home/ec2-user/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/passenger-5.1.2
+     PassengerDefaultRuby /home/ec2-user/.rbenv/versions/2.4.0/bin/ruby
+   </IfModule>
$ sudo vim /etc/httpd/conf.d/apps.conf
 <VirtualHost *:80>
    ServerAlias ip address
    ServerName ip address

    <Directory "/home/ec2-user/hello_world/public/">
        PassengerAppRoot /home/ec2-user/hello_world
        RailsEnv production        
        Options -MultiViews
        Options Indexes FollowSymLinks
        Require all granted
    </Directory>
 </VirtualHost>

Apacheの起動

$ sudo service httpd start
$ sudo service httpd status

続きを読む

Rundeckで参照権限追加(readonly,gest)

投稿の目的

Rundeckで、アプリ開発者様に参照権限を追加する。
既に本番稼動しているRundeckを停止しないで、追加できることを目指す。

背景

Rundeckインストール直後はadmin権限しかない。
危険かつ責任所在が不明確になるので、参照権限がないと後々面倒。

手順

1./etc/realm.propertiesにユーザ追加(guests)

admin定義の直下あたりに追加すると良い。

/etc/realm.properties
guests:guests,user

この状態でもログインできるが、見れるプロジェクトが無い。
スクリーンショット 2017-03-19 19.02.15.png

2.guests権限を定義する。

2-1.定義ファイル雛形を作る。(adminのコピー)

# cp admin.aclpolicy guests.aclpolicy

2-2.guest.aclpolicyを編集

ポイントは「参照権限」と書いている行と「username:」でgusetを指定している部分

guests.aclpolicy
description: Project settings for guest user.
context:
  project: 'XXXX_Test' # XXXX_Testは、参照権限を付与したいプロジェクト
for:
  resource:
    - allow: [read] # allow read/create all kinds 参照権限
  adhoc:
    - allow: [read] # allow read/running/killing adhoc jobs 参照権限
  job:
    - allow: [read] # allow read/write/delete/run/kill of all jobs参照権限
  node:
    - allow: [read] # allow read/run for all nodes参照権限
by:
  username: guests

---

description: Rundeck settings for guest user.
context:
  application: 'rundeck'
for:
  resource:
    - allow: '*' # allow create of projects
  project:
    - allow: '*' # allow view/admin of all projects
  project_acl:
    - allow: '*' # allow admin of all project-level ACL policies
  storage:
    - allow: '*' # allow read/create/update/delete for all /keys/* storage content
by:
  username: guests

2-3.ログインして確認

プロジェクトが見えるようになりました。
スクリーンショット 2017-03-19 19.24.40.png
ジョブを選択しても右上に緑色「Run Job Now」のボタンがありません。成功です!!
スクリーンショット 2017-03-19 19.26.33.png
実行権限のあるユーザでログインしなおすと緑色「Run Job Now」のボタンが表示されます。
スクリーンショット 2017-03-19 19.27.19.png

結びに代えて

より良い方法ございましたらご教示願います。

続きを読む

ECSのチュートリアル – コンテナ運用を現実のものにする

皆さんこんにちは

以前にコンテナの何がいいのかを説明する資料を作りました。
「やっぱりコンテナ運用しか無いな」
「コンテナを使わざるを得ない」
「とりあえずdocker入れとけばいいや」
という声が聞こえてきそうです(幻聴)

一方で、コンテナで運用するとなると、新たなる監視体制が必要となります。
例えば、Dockerのコンテナが突然停止した場合、その状況を検知し、新しくコンテナを立ち上げる必要があります。
また、そもそもコンテナが乗っている環境をスケールする必要が出たりして、その場合は新しくスケールされた環境でもコンテナを立ち上げなければならないし、その設定をサーバに書かなければならないけど、そうなると結局コンテナが乗っているサーバがブラックボックス化したりするわけで、なんとかうまく回そうとすると、それなりに気を配ることが多くなってきます。

最近はlaradockを使用する開発者が増えてきた(ような気がする)ので、コンテナ運用で幸せになるためにECSを使ってみた記録をチュートリアル形式で再現しておきます。

え?備忘録?ははは

ECSとは

ECSはAWSが提供しているコンテナ運用サービスです。
ECSの概念のちょっとしたものは以前に書いたECSで困ったときに読むための俺的Q&Aに書いてありますが、今回はECSでたてるWEBサーバに絞って超かんたんなポンチ絵を作ってみました。

ecs.png

あまりややこしいところはなさそうですが、簡単に見ていきましょう。

クラスター、コンテナインスタンス

コンテナインスタンスはdockerのコンテナのホストになるインスタンスで、クラスターはこのコンテナインスタンスの群れ( オートスケーリンググループ )です。
コンテナインスタンスにはdockerとコンテナの状態を監視してこちらに伝えてくれるエージェントが入っています。
コンテナ運用時には、個々のインスタンスには興味が無いので、「クラスター」と一括りにしてしまいます。

タスク、ECR

タスクはアプリケーションのまとまりを一つ以上のコンテナ動作で定義します。
今回の例ではnginxを動かすコンテナとphp-fpmを動かすコンテナのふたつで、webサーバのタスクを定義していて、nginxが外部からのリクエストを受け付け、php-fpmに渡しています。
コンテナを定義するイメージはECRというAWSが提供しているプライベートなdockerイメージのレジストリから取得しています。

サービス

サービスは3つの仕事をします。
1つ目はタスクが現在必要とされている個数を保っているかを監視し、その数を下回っていた場合、タスクを立ち上げて必要数を保つことです。
2つ目は現在の負荷状況を鑑みて、タスクを増減させます。この設定はCloudWatchのアラーム機能と連携させます。
3つ目はtarget groupと立ち上がったタスクを紐付けることです。

また、タスクの配置を各AZに均等に配置したりと、よく気配りのきくやつです。

ALB、target group

ALBはロードバランサーです。昔のクラシックなELBと違って、間にtarget groupと言うものを設置して、細かくルーティングできるようになっています。
target groupは実際のサーバへの振り分けを実施し、ヘルスチェックもします。

今回はこれらを利用して簡単なWEBサーバを運用できる状況に持っていきましょう

コンテナの準備

とりあえずコンテナを作る

運用したくとも、そのもととなるコンテナイメージがないと何も始まりません。
そこで、例によってLaraDockを利用してlaravelアプリを作ってみましょう。
プロジェクトの作成はここを見てもらうとして(ダイマ)、LaraDockとほぼ同じ動作をしてもらうために、Dockerfileをコピーしちゃいましょう。

$ cp -r ../laradock/nginx ./
$ cp -r ../laradock/php-fpm ./

これでDockerfileと設定ファイルをコピーできます。

今回、コンテナの中は完全に固定化…つまり、スクリプトを内部に含ませてしまうため、各Dockerfileの後部に

COPY ./ /var/www/

これを追加しておきます
また、nginxのdefaultのコンフィグファイルも必要なので、nginxのDockerfileには

COPY nginx/sites/default.conf /etc/nginx/conf.d/

も追加しておきます。
なにはともあれ、イメージを作成してみましょう。

$ cp nginx/Dockerfile ./ && docker build -t niisan/nginx .
$ cp php-fpm/Dockerfile-70 ./Dockerfile && docker build -t niisan/php-fpm .

これでイメージが作られているので、試しにサーバを立ててみましょう。

$ docker run -d --name php-fpm niisan/php-fpm
$ docker run -d --link php-fpm:php-fpm -p 80:80  niisan/nginx
$ curl 127.0.0.1
<!DOCTYPE html>
<html lang="en">
    <head>
...

うまく動いているようです。

コンテナをアップロードする

次にECRにコンテナをアップロードするのですが、初めての場合、ちょっとビビります。
けばけばしいタイトルとともに「今すぐ始める」ボタンが登場し、その次のページで妙な選択肢を迫ってきます。

ECSを始めることを。。。強いられているんだ!

(こういうところ、あまり好きじゃないです)
ここではとりあえず、「Amazon ECR によりコンテナイメージをセキュアに保存する」だけを選択しておきます。
すると、リポジトリの作成用のウイザードが迫ってきます。

ECR

とりあえずリポジトリ名にnginxと入れて次のステップへ
今度はECRにイメージをアップロードする手順が出てきますので、この通りにやってみます。
前回の記事でも言及したように、ここだけはAWS CLIを使用する必要がありますので、頑張って入れておきましょう。

$ aws ecr get-login

これで出てくるログインコマンドをコマンドラインにコピーして実行すればログイン完了です。
既にイメージは作ってあるので、タグを張り替え、アップロードしましょう。

$ docker tag niisan/nginx:latest **************.ecr.ap-northeast-1.amazonaws.com/nginx:latest
$ docker push *****************.ecr.ap-northeast-1.amazonaws.com/nginx:latest

これで完了です。
手順ページの完了ボタンを押すと、いまアップロードしたイメージのレジストリができていることを確認できます。

そのまま、左のバーにあるリポジトリを選択し、同じようにphp-fpmもアップロードしてみましょう。
1分もかからず終わるでしょう。

ECR登録済み

デプロイ

タスクを定義する

コンテナのイメージもアップロードできたことですし、早速タスクを定義していきましょう。
と言っても、今回の場合、内容は異様なほど簡単ですんで、すぐに終わるでしょう。

タスクの名前は適当に決めていいと思います。(今回は webtest という名前にしました。)
早速コンテナを入れていきましょう。まずはphp-fpmから行きます。「コンテナを追加」ボタンを押すと次のモーダルが出てきます。

タスクを設定

php-fpmの設定はこれだけで十分でしょう。
次にnginxを設定します。基本的にはphp-fpmと同様にイメージと名前を設定するわけですが、二つほど、違う設定があります。

ポートフォワード

まずはポートの設定です。
nginxは外部から接続できなければならないので、ホストからポートフォワードするように設定しました。

内部リンク

もう一つはphp-fpmへのリンクです。
これで、タスクの定義は完了しました。

クラスターを作る

タスクを作ったので、こいつを動かしてみましょう。
こいつを動かすためには、動作環境が必要となりますが、それがクラスターです。
早速クラスターを作っていきましょう。

クラスターの作成

せこいですが、コンテナが動作するインスタンスは一番ちっちゃいやつを使います。
次にネットワーキングの設定ですが、これはデフォルトのvpcを使ってお茶を濁しておきます。

商用環境では独自のVPC使おう

では作成しましょう。

クラスター作成完了

クラスターが出来上がりました。

作ったクラスターを選択して、早速タスクを動かしてみましょう。
クラスター名を選択し、タスクタブからタスクの開始ボタンを押すと、動作するタスクを選択する画面になります。

タスクの実行

では動作してみましょう。
しばらくすると、次のような状態になっていると思います。

動いているっぽい

どうやら動いているようです。
ECSインスタンスからコンテナのホストになっているインスタンスを参照して、public dnsを調べましょう。
それをブラウザにはっつけると、Laravelのページが表示されます。
Webアプリのデプロイ完了
うまくいきました!

サービスを使う

とりあえずデプロイできて、動作も確認できました。
とはいえ、これを運用するのはまだまだ厳しいところです。

  • タスクが死んだ場合の復旧をどうすればいいのか
  • コンテナを更新したときのデプロイ方法はどうなるのか
  • コンテナのスケーリングはどうするのか

この辺をサービスに解決してもらうとしましょう。

タスクを停止してみる

とりあえず、タスクを停止します。クラスターのタスクタブで、先ほど動かしたタスクを落とします。
当然ですが、落としたタスクは復活したりしないので、この時点で先に動かしたWEBサーバはダウン状態となります。

イメージを更新する

これからロードバランサーを使用するに当たり、ヘルスチェック用のルーティングをします。
今回はlaravel5.4を使う(使っちゃってる)ので次のようなroutingを用意します。

routes/web.php
Route::get('/healthcheck', function () {
    return ['health'=>'ok'];
});

この状態で、Dockerのイメージビルドを再実行します。
コンテナを再度動かすと次のような挙動を示します。

$ docker run -d --name php-fpm niisan/php-fpm
$ docker run -d --link php-fpm:php-fpm -p 80:80  niisan/nginx
curl 127.0.0.1/healthcheck
{"health":"ok"}

これをECRに再アップロードしておきます。

タスクを更新する

次に、タスクを更新していきます。
タスクはバージョン管理されていて、タスクはの更新は正確には新しいリビジョンを作るということになります。

例えば、今動いているリビジョンのタスクを新しいリビジョンのタスクに置き換えることで、サーバを更新したことと同じ状況にできますし、いざ新しいリビジョンが障害を起こすようなものであった場合は古いリビジョンに戻してロールバックすることもできます。

タスク定義->webtestでタスク定義のリビジョン一覧が現れます。今は一個しか無いと思うので、それを選択し、新しいリビジョンの作成ボタンを押しましょう。
今回の変更はnginxのポートの部分になります。

ダイナミックポート

なんとホストポートが空欄になっていますが、これがダイナミックポートという仕組みになります。
これはコンテナインスタンスで開いているポートを選んで、nginxコンテナの80ポートに繋げる仕組みで、ALB + target groupと組み合わせるときに使用します。

ALBを用意する

ひとまずコンテナの調整はこの辺にしておいて、ロードバランサーの設定を始めましょう。
まず、サービス -> EC2 -> サイドバーのロードバランサーを選択し、ロードバランサーを作成ボタンを押しましょう。
ALBの設定
Application load balancer を選択して、次へを押すとロードバランサーの設定に移ります。
今回はデフォルトのVPCを使うので、名前以外は全部デフォルトで問題なしです。
サブネットも二つあると思うので、両方共チェックしておきましょう。
一応、プロトコルはHTTPにしておきましょう。
セキュリティの警告は、今回は別に秘密通信でもないので、必要ないです。

セキュリティブループの設定

セキュリティグループはとにかく設定しておきましょう。
覚えやすい名前にしておくと、後で便利かもしれません。

空のターゲットグループ

ターゲットの登録画面になりますが、今はターゲットがないので、そのまま次へで、作成を完了させます。
これで、とりあえずロードバランサーの作成が完了しました。

最後に、ロードバランサーのセキュリティグループからコンテナインスタンスのセキュリティグループへの通信経路を確保しておきましょう。
コンテナインスタンスのセキュリティグループ( EC2ContainerService-*** )のinboundを編集しておきましょう。

セキュリティグループの設定

ロードバランサーからのinboundで全てのtcpを選択しておきましょう。
ダイナミックポートを使うと、開いているポートを使うのでどのポートが割り当てられるかわかりません。

サービスの作成

ここまで来てようやくサービスの作成が初められます。
再びEC2 Container Serviceから先程作成したクラスターを選択し、サービスを選択します。
作成ボタンがあるので、これを押しましょう。
サービス作成
まず、タスクはWebtestを選ぶわけですが、ここではリビジョンを含めて指定することになります。
サービス名は・・・とりあえずタスクのファミリー名と同じにしています。
画面下部に行くとELBを設定するボタンがあるので押してみましょう。
スクリーンショット 2017-03-18 22.39.45.png
するとこんな画面になるので、さっき作ったALBを選択し、負荷分散用のコンテナがnginxで、ポートが0:80になっていることを確認したら、ELBへの追加ボタンを押しましょう
スクリーンショット 2017-03-18 22.41.36.png
するとこんな画面になるのでターゲットグループを先程追加したものに変更して保存を押しましょう。

すると、サービスにALBの情報が登録されるので、この状態でサービスを作成しましょう。

スクリーンショット 2017-03-18 23.41.08.png

クラスターの状態がこのようになれば、成功です。
あとは、ロードバランサーのDNSにアクセスして、
Webアプリのデプロイ完了
これが出れば成功です。

まとめ

実はこれ書き始めたのって随分と前なのですが、途中でコンテナ運用の何がいいのかを説明するための資料作りしていたら、時間が立ってしまったのです。
まあ、ECSって使ってみるとすごく楽で、更にスケーリングしたり、他のサービスと相乗りさせたりマイクロサービス化させたりがすごく簡単にできるのですが、Webアプリを動かすに当たっては、わりとハマりどころが多いので、一貫したチュートリアル形式のものを作ってみました。
特にハマりどころなのは、ALB -> コンテナインスタンスにおけるセキュリティグループの設定だと思います。
考えてみれば当たり前なのですが、まあ、忘れることが多いです。
とはいえ、そんなところを超えてしまえば、後はコンテナで簡単に運用できる環境を量産できるので、皆さん是非とも使ってみてください。

今回はそんなところです。

参考

コンテナに挫折したあなたへ – 超わかりやすい発表資料です!師匠と呼びたい

続きを読む

[EC2] SSH 接続時のログインメッセージにインスタンスタイプとかリージョンとか表示する

対象は Amazon Linux で動いてる EC2。
SSH接続して作業するときに、このインスタンスってどのインスタンスタイプで動いてたっけ?って知りたいときとかに便利。

こんな感じのシェルスクリプトを /etc/update-motd.d/40-instance-meta とかって名前で保存して実行権限与えておいてください。

/etc/update-motd.d/40-instance-meta
#!/bin/sh
instance_type=$(curl -s http://169.254.169.254/latest/meta-data/instance-type/)
az=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
region=$(echo ${az} | sed -e 's/[a-z]$//g')

cat << EOF
 INSTANCE TYPE : ${instance_type}
 REGION : ${region} (${az})

EOF

そのあとで update-motd コマンドを root 権限で実行すると、次回 SSH ログイン時からログインメッセージ変わります。あら便利

Last login: Wed Mar 15 15:05:40 2017 from xxx.xxx.xxx.xxx
      ___         _            __
     / _ | __ _  (_)_ _  ___  / /____
    / __ |/  ' / /  ' / _ / __/ _ 
   /_/ |_/_/_/_/_/_/_/_/___/__/___/

https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/

 Nginx 1.11.10, PHP 7.1.2, Percona MySQL 5.6.35, WP-CLI 1.1.0

 amimoto     https://www.amimoto-ami.com/
 digitalcube https://en.digitalcube.jp/

 INSTANCE TYPE : t2.small
 REGION : ap-northeast-1 (ap-northeast-1c)

続きを読む

JAWS-UG情シス支部 第8回議論会からの学び

JAWS-UG情シス支部 第8回議論会に参加してきました。
そこで出た話題などを踏まえて、自分のまとめをしたいと思います。
※8回そのもののまとめではなく、踏まえた学びのお話し。

AWSアカウント

複数利用の是非

  • 開発と本番で分離するか、サービスごと、パートナー先、部門毎etcと話題に出たけど絶対解は無さそう
  • 全体的な傾向としては会社管理のアカウントは右肩上がりに増える傾向にはあった

アカウント権限の付与

  • rootユーザーは使用しない。これはAWSの推奨事項。
  • IAMユーザーの発行については、会社規模、AWSに関わる人数規模次第。
  • 多数のAWSアカウントと権限発行が必要な場合はIAMユーザーでは運用が回らないので、Active Directoryなどの既存認証基盤で管理する

権限付与とログ監査

  • 権限付与は最小限に絞らないと怖い。絞り切れないのなら、最低限Denyは設定する。CloudTrailは変更できないようにする
  • CloudTrailのログ監査については実運用としては厳しい印象。
  • 参考としては、先日のJAWS Daysの知らない間に使われていませんか? ~AWSの利用監査対策~が同様の話題。そこではSumoLogicを使用してWeeklyレポートの送付や、不審な操作はリアルタイムアラートをしているとの紹介。

ec2-user

  • ec2-user についても絶対解はない。
  • AWSとしては、「新しいユーザー用にユーザーアカウントを作成することは、ec2-user アカウントへのアクセス権を複数のユーザーに (経験のないユーザーも含めて) 与えるよりも、はるかに安全です。」との説明
  • ec2-userは削除しても実害はないようなので、削除かSSH禁止にするのもあり。実施方法は、ここがわかりやすい
  • EC2のOSにログインしなくても困らないような環境にしていくのが幸せかな。

続きを読む

RedmineをElasticBeanstalkのMulti-Container Dockerで起動してみた

ElasticBeanstalkをいろいろ試している最中。
今回はMulti−Container Dockerのお試し。

方針

  • Redmineのコンテナとリバースプロキシ用のNginxコンテナを使う。
  • AWSなのでデータベースはRDSを使う。
  • お試しなのでDocker RegistoryはDockerhubを使う。
  • RedmineのDockerイメージはお約束のsameersbn/redmine

EBアプリケーションのソースバンドル作成

この時点ではまだAWSを触る必要はない。
ディレクトリとファイルの構成は以下のような感じ。

.
├── Dockerrun.aws.json
├── nginx/
│   └── conf.d/
│       └── default.conf
└── redmine/
    └── data/
        └── .gitkeep

Dockerrun.aws.jsonにコンテナの構成を記載する。
どうやらECSのTask Definisionと同じような内容のようだ。

Dockerrun.aws.json
{
  "AWSEBDockerrunVersion": 2,
  "volumes": [
    {
      "name": "redmine-data",
      "host": {
        "sourcePath": "/var/app/current/redmine/data"
      }
    },
    {
      "name": "nginx-conf",
      "host": {
        "sourcePath": "/var/app/current/nginx/conf.d"
      }
    }
  ],
  "containerDefinitions": [
    {
      "name": "redmine",
      "image": "sameersbn/redmine",
      "essential": true,
      "memory": 512,
      "mountPoints": [
        {
          "sourceVolume": "redmine-data",
          "containerPath": "/home/redmine/data"
        }
      ],
      "environment": [
        {
          "name": "REDMINE_RELATIVE_URL_ROOT",
          "value": "/redmine"
        },
        {
          "name": "DB_ADAPTER",
          "value": "postgresql"
        }
      ]
    },
    {
      "name": "nginx-proxy",
      "image": "nginx",
      "essential": true,
      "memory": 128,
      "mountPoints": [
        {
          "sourceVolume": "nginx-conf",
          "containerPath": "/etc/nginx/conf.d",
          "readOnly": true
        }
      ],
      "portMappings": [
        {
          "hostPort": 80,
          "containerPort": 80
        }
      ],
      "links": [
        "redmine:redmine"
      ]
    }
  ]
}

ホストの環境変数を自動で引き継いでくれるみたいなのでDB_HOSTやDB_NAMEなどはEBの環境変数で渡せるためここでは書かない。逆にここに書いちゃうと環境ごとに作らないとなので絶対にやらない。
logConfigurationでCloudWatch LogsやFluentdが使えるみたいだけど、今回は割愛。

Redmineはサブディレクトリにしてみた。
複数アプリケーションをNginxでパスルーティングできることのフィジビリティ確保。(ALB使えや)
Route53でドメイン名を複数このEBに紐付けてホスト名での振り分けもできそう。
ホスト名でのルーティングはALBでは(今のところ)できない。

nginx/conf.d/default.conf
server {
    listen       80;
    server_name  localhost;
    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
    location /redmine {
      proxy_set_header X-Real-IP  $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_pass http://redmine;
    }
    error_page  404              /404.html;
    error_page  500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

で、ローカルのGitリポジトリにcommitしておく。

git init && git add ./* && git commit -m "initial commit."

必要なリソースを事前準備

RDSとセキュリティグループは事前に作成しておかないと最初のデプロイでコケるので事前に作成しておく。

  • VPC * 1, Internet Gateway * 1, RouteTable * 1, Subnet * 1
  • ElasticBeanstalk用のSecurity Group (80/tcp 0.0.0.0/0) * 1
  • PostgreSQLのRDS (EBで作成しない)
    • RDSのSecurityGroupで上で作ったSecurityGroupからのアクセスを許可しておく。

ElasticBeanstalkの環境を作成する

マネジメントコンソールでもできるけど、ElasticBeanstalkはeb-cliを使ったほうが便利。(というかcliじゃないとできない設定が多すぎる)

# アプリケーションの作成
eb init --region ap-northeast-1 -p "multi-container-docker-1.12.6-(generic)" test-app
eb create -r ap-northeast-1 -c CNAMEのプレフィクス -i t2.small -k EC2キーペア 
  -p "multi-container-docker-1.12.6-(generic)" --single 
  --envvars "DB_HOST=RDSエンドポイント,DB_NAME=RDSのDB名,DB_USER=RDSのマスタユーザ,DB_PASS=RDSパスワード" 
  --vpc --vpc.id VPCのID --vpc.ec2subnets サブネットのID --vpc.securitygroups セキュリティグループID 
  --vpc.publicip 
  test-app-env

http://CNAMEのプレフィクス.ap-northeast-1.elasticbeanstalk.com/redmine にアクセスしてRedmineが表示されればOK。
ElasticBeanstalkって作るまでは本当に簡単。カスタマイズは大変だけど。

続きを読む

2017/3/11 JAWS DAYS 2017 参加メモ

http://jawsdays2017.jaws-ug.jp/

赤ドクロ Presents 『AWSでアプリ開発するなら 知っておくべこと』

https://www.slideshare.net/keisuke69/aws-73040279

アーキテクチャのベストプラクティス

  • Design for failure

    • 単一障害点をなくす、すべてが失敗し得るという前提で考える

      • 最初に1ホストを複数に分割する⇒Webとデータベース(RDS)
      • 複数のWebインスタンスを異なるAZで
      • RDSはMulti-AZ
      • ELBを利用して負荷分散
  • Build Security Every Layer
    • 通信経路および保存されたデータの暗号化、IAM/セキュリティグループ
  • Leverage Many Storage Options
    • 万能なデータストアは存在しない、特性に応じて使い分ける
    • Storage
      • Object Storage: S3, Glacier
      • File/Block Storage: EFS(NFS、共有ディスク), EBS
    • Database
      • NoSQL: ElastiCache, DynamoDB
      • SQL: RDS(トランザクション処理), Redshift(DWH)
      • 静的コンテンツはS3に
      • セッションやステートはDynamoDB
      • DBのキャッシュはElastiCache
  • Implement Elasticity
    • IPアドレスで参照しない(名前ベースで)、分散させる
  • Think Prallel
    • EMRを用いて並列のMapReduceジョブを実行、ELB、1つのKinesis Streamと複数のKCLアプリケーション、バックエンドとしてのLambda
    • 1インスタンスでN時間 = N台を1時間 ⇒ コストは同じ
  • Loose Coupling
    • コンポーネント間の結合度が緩やかになるほど、スケーラビリティは高まる
    • すべてのコンポーネントはブラックボックスとしてデザイン(APIアクセス、DNS名でアクセスなど)
    • Queueを使って疎結合に(部分的なretryがしやすくなる、重たい処理だけをスケールする)
    • Service Discovery
      • 各サービスで増えたリソース、減ったリソースに対して透過的にアクセス
      • Auto Scalingを使ったELB自動登録、Consulなど
    • Asynchronous Integration
      • 同期処理である必要がなければ非同期にする(その処理、本当にレスポンス必要ですか?)
      • アプリケーションがブロックされない
      • スケーラビリティ&高可用性
      • Frontendを停止することになくBackendを容易にメンテナンス可能
      • リクエストの処理順序やリトライ等の制御が容易に(一方、数珠つなぎで全体の見通しは悪くなる)
  • Don’t Fear Constraints
    • より多くのメモリが必要?⇒負荷分散、キャッシュ
    • データベースのIOPSが必要?⇒リードレプリカ、シャーディング、データベースのキャッシング
    • 問題のあるインスタンスを破棄し、置き換える

The Twelve-Factor App

  • Dockerによるアプリケーション開発やLambdaのようなサーバレスコンピュートの普及に伴い、改めて重要性が増しつつある
  • Codebase
    • デプロイされているアプリとコードベースは常に1:1であるべき
  • Dependencies
    • 依存関係を明示的に宣言し分離する
    • 特定の環境に暗黙的にインストールされているパッケージやツールに依存せず、アプリに同梱する
    • 例:gemとbundler
  • Config
    • OSレベルの環境変数によって注入されるべき
    • 設定ファイルは言語/フレームワークの環境依存になる
  • Backing Service
    • ネットワーク越しに使うものはすべてリソースとして扱い(URLのように)、データベースはアタッチされたリソースとして扱う
    • リソースの切替はリソースハンドルの切替(URLの切替)とする
  • Build
    • build、リリース、実行の3つのステージを厳密に分離する
    • すべてのリリースは一意のIDを持つべき(どの環境にどのIDがdeployされているか)
  • Process
    • アプリケーションをStatelessなプロセスの組み合わせとして実行!
    • スケールアウトの単位としてプロセスモデルは分かりやすい(スレッドはメモリ共有するなどで管理が複雑)
    • 永続化する必要のあるデータ(次のリクエストでも利用するデータ)はDBなどstatefullな外部サービスを利用
    • ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとして扱う
  • Dsiposability
    • グレースフルシャットダウン
  • Dev/prod parity
    • 開発・ステージング・本番環境をできるだけ一致させ、CI/CDの効果を発揮する
  • Log
    • 出力ストリームの保存先やルーティングにアプリは関与しない(標準出力に吐き出すだけにする)
    • 収集、保存、インデックス化し分析する環境をアプリの外に用意する
  • Stateless
    • ステートフルにになる要素を水平スケールするリソースの外部に配置
    • Session情報(スケールアウトすると新しいインスタンスから見えない)⇒DynamoDBに見にいってローカルにキャッシュ

DevOps

  • 無駄やボトルネックを取り除くことで、ライフサイクル(フィードバックループ)を効率化し、高速化する
  • Cluture:End to EndでOne teamであること、主体的なオーナーシップ、行われた作業の結果に対する可視性を高める
  • Practice:Automate Everything、Test Everything, CI/CD/Infrastructure as a code, etc…
    • 自動化と構成管理:プロビジョニング、設定、オーケストレーション、レポーティング
    • ApplicationとInfrastructureをいずれも、バージョン管理し、build&testし、成果物を登録し、デプロイする
    • 繰り返し継続的に行う
  • Tool

DevOps tool on AWS

  • ほとんどのサービスにAPIが用意されている⇒プログラミングの文脈でインフラを制御する

    • 各言語のSDKが用意されている(IDE向けのプラグインも用意されている)
  • Cloud formation
  • Jenkinsを使ったデプロイ

ベストプラクティス

  • 自動ロールバック:まずはロールバックし、その後ログ/グラフなどを用いてデバッグする
  • ダッシュボードで通常時と異常時を把握する

AWS SECURITY DEATH m/ ~セキュ鮫様からのお告げ~ by Security-JAWS

ネットワーク

  • public subnet / private subnet

    • public subnet: インターネットに直接接続可能なサブネット(公開サーバを置く、EIPとの紐づけもできる)
    • private subnet: NATゲートウェイを経由して内⇒外のインターネット通信は可能
  • statefull / stateless
    • NAT配下のクライアントのSource Portはハイポート(1024-65535)からランダムに設定される
    • Statefull: 戻りの通信もよろしくしてくれる
    • Stateless:内⇒外も書かないといけない(1024-65535/tcp)
    • Security GroupはStatefull⇔Network ACL(subnet単位で通信を制御)はStateless
  • VPN
    • ユースケース

      • Webサーバ/DBサーバのメンテナンスはプライベートネットワーク経由で行いたい(平文でインターネットを通さない)
      • 社内システムで事業所とAWSの間(Direct Connectは品質を高めることもできる)
      • AWSを既存システムの拡張リソースとして使用するような場合(繁忙期など)
    • VPNの場合、AWS側には2つのVPNエンドポイントが用意される(Customer Gateway側で2つのトンネルを張る必要がある)
      • static routingもしくは、BGPによるダイナミックルーティング(対応機種のFAQ参照)
  • Direct Connect(専用線接続)
    • 宅内~接続ポイント⇒一般的には通信キャリア
    • 接続ポイント~AWS⇒AWSが提供
    • VLAN分けをできるキャリアと、できないサービスがある
    • TOKAIコミュニケーションズ、Colt(旧KVH)

WAF/DDoS

  • 全脳アーキテクチャ若手の会
    #### DDoS
  • DDoS対策(コストがかかる)、DDoSをあえて受ける(落ちてもいいサイトであれば、放置するのも一つ)
    • L3/L4:Infrastructure
    • L7: Application
  • AWS Shield
    • CloudFrontを使って、Shieldオプションを有効化
    • Shieldの後ろはAWSでも、オンプレでも対策可能
    • 防御対象:CloudFront, ELB, ALB, Route53
    • 監視:常にモニタリングしてベースラインの作成、異常検出
    • Basicは無料で利用可能、AdvancedはDRT付き
    • Billing Protection
    • DRT:WAFのチューニングやルール作成もやる
    • CloudFrontさえ入っているなら、導入しておかない手はない!

WAF

  • FWやIDS/IPSでは防ぐことができない不正な攻撃を遮断(アプリケーション脆弱性など)

    • PCI-DSS 6.6にもWAF導入について明記されている
  • AWS WAF
    • カスタムルール(IPアドレス制限/文字列制限)、SQLI/XSSといった基本的な対策が可能
    • 構成:CloudFront, ELB, ALBに仕込めるマネージドWAF
    • ルールを正規表現で書けない、WAF検知ログは100件まで
  • AWS WAF / WAF on AWS / SaaS WAF / Cloud WAFの比較
    • SaaS WAF / Cloud WAF: 正常な通信の確認、DNSの向き先変更程度で導入できる
    • WAF on AWSはオートスケールに対応している製品が多い
    • AWS WAFはセキュリティ面では物足りない
  • 「セキュリティ開発」はなぜ浸透しないのか

AWS Config

ごちゃごちゃしやすいAWSリソースを簡単に「見える化」できる

  • 構成管理、変更管理のためのサービス(よく使うサービスは対応済)

    • 構成情報のスナップショットの取得
    • 変更内容を追うことができる、SNSを使った通知も可能
    • AWSリソース間の関係性の確認(EC2とVPC/Security Group/ALBとの関係)
    • EC2 Systems Manager: エージェントを入れると、OSの中の情報を取れる、コンソールからコマンドを発行⇒OS上の変更管理が可能になった
    • IAMの構成管理
  • ユースケース
    • AWSリソースの一覧でAWSリソースを確認できる、削除されたリソースについても追跡可能
    • いつ、どのように変更されたかを記録するので証跡として利用可能
    • 関連するAWSリソースも辿れるのでトラブルシュートしやすい
  • AWS Confing Rules
    • AWS Configで記録した設定が正しいかを判定するルールを定義できる
      • セキュリティグループがフルオープン
      • MFA設定していない
      • ACMの証明書の有効期限があと少し
  • マネージドルール
    • Instanceにtagをつけているか?(billingのために、作った人/プロジェクト名をつける)
    • SecurityGroupがフルオープンになっているか?
  • カスタムルール
    • 判定機構はLambdaで実装⇒極論、修正することもできる
    • awslabsにカスタムルールが公開されている(現在34)
  • AWS Configを有効化して可視化
    • Auto Scalliingで、頻繁にインスタンスの起動/削除をしていなければ、課金額は大きくない

Chat bots with Amazon Lex

  • Amazon Lex:音声/テキスト処理

    • Alexaと同じ技術で提供されている
    • 音声認識+自然言語処理
  • コンポーネント
    • ユーザ入力⇒出力
    • Intents:意図(Utterance/Slots)
    • Fulfillment:処理
  • Utterance
    • Intent(例:RegisteruserForEvent)に対してユーザ入力を紐づける
    • Sample utteranceを複数事前に定義する
    • 反復して学習することによってユーザ入力の言い回しの揺れを吸収(徐々に改善していく)
  • Slot
    • SLOT NAME: eventDate, SLOT TYPE: AMAZON.DATE
    • 12 March 2017 / tomorrowみたいな揺れを吸収できる
  • Fulfilment
    • AWS Lambdaとの統合⇒クライアントにレスポンスを返す
  • 複数のintentをflowにすることで、より自然な対話が可能になる
    • もう少し知りたいですか? ⇒ yes ⇒ 次のintentに繋げる
    • 曖昧な答えの場合は、プロンプトを出す(「”yes”か”no”で答えてください」)
  • Lambdaとの統合
    • Lexがユーザ入力をparseし、intent/slotsを渡してlambdaを起動、lambdaからレスポンスを返す
    • dialogAction:会話の流れをつかさどる(例:ConfirmIntent)
    • facebookの場合、Response cardを返すこともできる(ユーザに選択肢リストを提示)
  • Lambda Functionの実装例
    • switchでintentごとの処理を定義して、1 functionで複数intentを処理
    • LexResponseBuilderでレスポンスをbuild
  • English Onlyでlaunchするが、複数言語をサポートするロードマップ
    • 開発者からAWS Japanへプレッシャーを!
  • 最初はよくテストして、エラーが多いようであればintentを細かく設定するなどの工夫が必要

サーバレスの今と未来

https://www.slideshare.net/YoshidaShingo/serverlessnowandthen

サーバレス

  • パラダイムシフト

    • サーバが要らないということではなく、開発者はサーバについて「考えなくてもよくなる」
    • 2014年末のre:InventにてLambdaの発表
    • 最大の特徴は、課金は使った分だけ(メモリ×時間×実行回数)
  • Function as a Service
    • アーキテクチャにおける責務

      • Stateful >> Stateless
      • 永続データ >> 揮発性
      • バッチ >> イベントドリブン
  • Lambda goes everywhere
    • コンテナベースの実行環境はportabilityが高いので、いろいろなところにデプロイできる
    • Athenaの基盤もLambda
    • Greengrass(AWS IoT)
    • CloudFrontのEdgeの上

代表的なサーバレスアーキテクチャ

  • UIドリブンアプリケーション

    • 認証ロジックをBaaS、DynamoDBにクライアントから直接アクセス、SPA+API Gateway
  • メッセージドリブンアプリケーション
    • オンライン広告システム
    • コンテンツのサムネイル作成(image magicを載せたlambda)
    • ログのストリームプロセッシング(kinesis/kafkaから取って、加工して、S3やDynamoに入れる)

エコシステム

  • プラットフォーム事業者、フレームワークやツール、アプリケーション開発者

    • アプリケーション開発者のノウハウ発信が足りない
    • cloud packの毎日放送事例
  • Serverless framework, Apex, Lamvery, Swagger, AWS Serverless Application Model(SAM), Postman…
  • SAM
    • CloudFormationテンプレートで管理できる
    • lambda, API Gateway, DynamoDBがサポートされている
    • app-spec.yaml -> CloudFormation(codeはS3経由でデプロイされる)

サーバレスだからこそできることをやる

  • 10X Product Development

    • TypeScriptしか書かず、あとは外部のサービスを使っている
    • firebase(auth), Netlify(static site hosting), Cloudinary(画像管理), Algolia(検索)
  • Serverless, NoOpes and the Tooth Fairy
    • 来るサーバーレスな未来では、アプリケーション開発者が運用に責任を持つ
    • プロバイダの技術情報や、内部技術が何に依存しているか理解する
    • 可視性が下がる、自分自身で問題をfixできないし新機能を実装することもできない
    • 売れていないサービスはシャットダウンされるかも
  • 日経新聞事例(紙面ビューアー)
    • 最大18,000回/1分間のinvocation
  • システムをリアクティブに設計する
    • イベントの発火やwebhookなどに対応している周辺のマネージドサービスとうまくつないでいる
    • シンプルなマイクロサービスとして
    • 一度トライアルしておき、いざ活用する前にはまりどころなど判断

SPAの開発の流れ

  • ビュー/アプリ(js)開発

    • ビューの作成
    • テスト駆動でアプリコードを追加(テストがないと、統合時に問題が起こったときの切り分けが困難)
    • 例:jQuery+Jasmine
    • ローカルで開発可能、チーム開発がはじまったらS3で
    • テスト時のブラウザキャッシュに注意(chromeの開発者ツールでdisable cacheするとか)
    • AWSに繋ぐ前に、1行書いたら1行テスト
  • Cognitoを使った認証+フェデレーション
    • 例:Google+
    • Googleで認証してIDが払い出される
    • ブラウザがCognitoにJSでアクセス、CognitoがGoogleに検証、OKであればDynamoDB書き込み権限を払い出す
  • DynamoDBを使ったデータの管理
  • Lambdaでシステム強化
    • DynamoDB直接読み書きでは仕組みとしてできてしまう、「不正なクエリからの保護」(lambdaでvalidationするなど)
    • 「ユーザ全員分の集計」などの情報提供のため
  • Serverless Single Page Apps
    • Ben Rady著、Step by Stepガイド(日本語版が間もなく出る予定)

参考(ところどころで言及されていた別発表)

[AWSワークショップ] Amazon Kinesis Analyticsを触ってみよう

kinesis

  • モチベーション

    • 処理した結果を複数システムに送る必要がある

      • kafka or Kinesis Streams
    • しかも機械学習を行なう
      • Spark Streaming or Storm
  • Kinesis
    • Streams

      • マネージドkafkaのイメージ:入出力に制限はある(入力:秒間1MBまたは1,000put)
    • Firehose:S3, Redshiftへ簡単に配信
    • Analytics:SQLクエリー
  • Stream Source/Destination(StreamかFirehose)
    • 入力側を決定する(Strems or firehouse)
    • 入力データの型定義をおこなう
    • SQL分を作成、デプロイ
    • 出力先を決定する(Strems or firehouse)
  • kinesis demo stremasは良く停止するので注意・・・
    • データ定義は大文字で定義(もしくはselect句をダブルクォーテーションで挟む)

Windowの概念

  • Tumbling Window(例:1分ごとに出力)

    • FLOOR((“SOURCE_SQL_STREAM_001”.ROWTIME – TIMESTAMP ‘1970-01-01 00:00:00’) SECOND / 10 TO SECOND)
    • 10 TO SECOND⇒10秒間隔
  • Sliding Window(データが流れてきたら出力を開始する)
    • Time(60sec:レコード受信をトリガーに直近60sec分を集計)
    • Row(2rows:自分+直近2レコード)
    • 1つのdestinationに対して、TimeとRowを両方設定できる

Reference Dataの追加

  • AWS CLIでのみ追加が可能
  • 例:S3のファイルを見る
  • 現状、Reference Dataを追加すると動作しない(サポート確認中)

まとめ

  • Firehose -> Elastic Search -> KibanaとすべてAWSコンソールで設定可能
  • 構築は非常に楽、標準SQL、Firehoseで接続が簡単
  • バグが多い、性能評価がしにくい
  • kinesis streamsはzookeeperの管理が不要、KPLと併用すれば非常に安い
  • Analyticsは簡単な集計処理ならよいが、複雑な処理はSpark Streaming等を利用したほうがよい

[Alexaハンズオン] Alexa Skills Kit で遊ぼう【基礎編】

続きを読む

AWSのEC2で必要なswap領域の追加とスワップを減らす設定

EC2のnanoやmicro、smallといった小さいインスタンスを使っていると、デフォルトではswap領域がないため、nginxをコンパイルする際やElasticsearchを起動する際など、メモリを多く必要とする処理が失敗してしまうことがよくあります。
また、スワップが頻繁に発生すると処理速度も心配になるので、なるべくメモリを使って頑張ってもらう設定も一緒にすると安心です。

スワップ領域の追加手順

512MBのswap領域を追加する手順です。作業はrootユーザ想定なので、適宜sudoは追加してください。

dd if=/dev/zero of=/swapfile1 bs=1M count=512
chmod 600 /swapfile1
mkswap /swapfile1
swapon /swapfile1
echo "/swapfile1  none        swap    sw              0   0" >> /etc/fstab

設定追加されていることを確認。

cat /etc/fstab
# #
# LABEL=/     /           ext4    defaults,noatime  1   1
# tmpfs       /dev/shm    tmpfs   defaults        0   0
# devpts      /dev/pts    devpts  gid=5,mode=620  0   0
# sysfs       /sys        sysfs   defaults        0   0
# proc        /proc       proc    defaults        0   0
# /swapfile1  none        swap    sw              0   0

freeコマンドでもSwap領域と使用されている領域を確認できます。

free -m
#              total       used       free     shared    buffers     cached
# Mem:          2003       1932         70          0          0         19
# -/+ buffers/cache:       1912         90
# Swap:          511        511          0

スワップ頻度の変更手順

swappinessでスワップの頻度を変更できます。
AmazonLinuxではデフォルトで60になっていました。

cat /proc/sys/vm/swappiness
# 60

rootユーザでの作業想定の手順。

echo 10 | tee /proc/sys/vm/swappiness
echo vm.swappiness = 10 | tee -a /etc/sysctl.conf

変更を確認します。

grep swappiness /etc/sysctl.conf
# vm.swappiness = 10 

AWS等でメモリ領域の小さいEC2インスタンスを使う際には設定しておくと安心です!

続きを読む

AWS EC2にApache2.4, PHP7環境を構築するメモ

yum更新
$ sudo yum -y update
Apache2.4インストール
$ sudo yum -y install httpd24
PHP7.0インストール
$ sudo yum -y install php70 php70-mbstring php70-pdo
PHP7.0利用可能パッケージ確認(必要に応じて)
$ sudo yum list available | grep php70
インストールモジュールの確認
$ sudo yum list installed | grep httpd24
$ sudo yum list installed | grep php70
php.ini編集
$ sudo vi /etc/php.ini
httpd起動設定
$ sudo chkconfig httpd on
$ sudo chkconfig --list httpd
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
httpd.conf編集
$ sudo vi /etc/httpd/conf/httpd.conf
httpd.conf シンタックスチェック&起動
$ sudo /etc/init.d/httpd configtest
Syntax OK
$ sudo /etc/init.d/httpd start
Starting httpd:                                            [  OK  ]
その他参考ページ

続きを読む