しがないインフラエンジニアLOG

インフラエンジニアとしての諸々

CentOS7.4でOpenRestyをインストールしてLuaでHelloWorldする方法

今回したこと

Vagrant環境にCentOS7.4を構築して、
OpenRestyインストールしてLuaでHallo Worldを出力してみました。

https://avatars2.githubusercontent.com/u/7390180?s=200&v=4

なぜやろうとおもったか

OpenRestyを過去にインストールしてLuaでいろいろやっていたのですが、
やりかたを忘れてしまったのでせっかくなので備忘録がてらに記載しました。

OpenRestyはnginxにngx_luaなどを全部入りにしたnginxでluaを実行する環境全部盛りなパッケージになってます。

nginxでLuaをやろうと思うと自分でビルドオプション書いて必要なパッケージ入れたり結構面倒くさい作業があるので、OpenRestyを入れて楽をしてしまいましょう。

OpenResty公式

前提 / 準備

1. OpenRestyのリポジトリ登録

■ 以下のコマンドでOpenRestyのリポジトリを登録します。

# yum install yum-utils
# yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo

2. OpenRestyインストール

■ 以下のコマンドでOpenRestyをインストールします。

# yum install openresty

■ 以下のパッケージがインストールされます。

(1/4): openresty
(2/4): openresty-pcre
(3/4): openresty-zlib
(4/4): openresty-openssl-1.1

3. OpenResty起動確認

■ OpenRestyは昔ながらのinitファイルで記載されていますので以下ファイルを作成してsystemdで操作しましょう。

# vi /etc/systemd/system/openresty.service
[Unit]
Description=The nginx HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/usr/local/openresty/nginx/logs/nginx.pid
ExecStartPre=/usr/local/openresty/nginx/sbin/nginx -t
ExecStart=/usr/local/openresty/nginx/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

参照

■ 以下のコマンドでOpenRestyの設定読み込み及び起動

# systemctl daemon-reload
# systemctl enable openresty.service
# systemctl restart openresty
# chkconfig openresty off

■ 以下のコマンドでOpenRestyのnginxが起動していることを確認

# ps aux | grep openresty

4. luaファイルの準備

■ とりあえずHello World用のLuaスクリプトを準備します。

# vi /usr/local/openresty/nginx/html/hello.lua
(以下を記載)
ngx.print("Hello, world!")

■ 以下を実行して「Hello, world!」と出力されればOK。

# lua /usr/local/openresty/nginx/html/hello.lua

5. OpenResty-Nginx設定

■ nginxの設定を実施。

# vi /usr/local/openresty/nginx/conf/nginx.conf
(serverセクションに追記)
location /hello {
    default_type text/html;
    content_by_lua_file /usr/local/openresty/nginx/html/hello.lua;
}

helloディレクトリに来たアクセスをすべてhello.luaで処理するかように設定しました。

*OpenRestyのディレクトリにnginxのファイル一式があります。迷子注意。

5. OpenResty-Nginx再起動

■ nginxの再起動

# systemctl restart openresty

6. 動作確認

■ 以下のコマンドで正常にluaの実行結果がレスポンスとして帰ってきていることを確認。

# cd ~
# wget http://localhost/hello/hello.html
# cat hello.html
Hello, world!

できた!!

最後に

nginxにluaモジュールを導入するときに色々やらないといけない作業をOpenRestyを入れることでサクッと環境を構築することができました。

ミドルウェア側で制御したいところを、luaで拡張できるのでインフラエンジニアにとっては強い味方ではないでしょうか。

引き続きLuaでごにょごにょしていきたいと思います。

AmazonLinux2でFluentdとKinesisFirehoseを使ってS3に保存する方法(Fluentd→Kinesis編)

今回したこと

AmazonLinux2で出力されるログを、
KinesisFirehoseを経由してS3に保存しました。

f:id:ishimotty:20181024170327j:plain

なぜやろうとおもったか

今まで別途ログ収集サーバーを立てていたのですが、
以下の問題点がありS3にログをためる方向に移行しました。

CloudWatchLogsを使うことも考えたのですが、
ただ現状fluentdからElasticSeachにもデータを突っ込んでいるので断念しました。
*現時点ではCloudWatchLogsからElasticSearchはAWSのElasticSearchServiceへの転送しか対応していないので。

ちなみに直接FluentdからS3に上げる方法もあるのですが、 APIのコール回数が多くなるのでKinesisFilehoseで一旦集約しています。

現状の問題点

  • ログの管理が必要。
  • ログの消失リスク
  • ログ管理サーバーのスペック/ボトルネック

前提 / 準備

  • OS:AmazonLinux2
  • AWS:(Kinesis→S3編)の設定が完了していること(作成予定)

引用:(Kinesis→S3編)

0. 送信元IAM Role

送信元のEC2に付与しているIAM Roleに以下のポリシーが権限を付与します。

AmazonKinesisFirehoseFullAccess

1. fluentdインストール

以下のコマンドを実行してfluentdをインストールします。

# curl -L https://toolbelt.treasuredata.com/sh/install-amazon2-td-agent3.sh | sh

引用:fluentd公式

2. fluentd起動設定

■ 起動ユーザーの変更
# vi /lib/systemd/system/td-agent.service
(変更前)
User=td-agent
Group=td-agent
(変更後)
User=root
Group=root

■ 設定の読み込み
# systemctl daemon-reload
# systemctl restart td-agent

■ fluentdの自動起設定
# systemctl enable td-agent.service
# systemctl list-unit-files -t service | grep td-agent

3. Kinesisプラグインのインストール

以下のコマンドを実行して、Kinesisプラグインをインストールします。

# td-agent-gem install fluent-plugin-kinesis

4. Kinesis用fluentd設定

以下の設定をfluentdに記載します。
*今回は試しに/tmp/test.logを使用します。
インターバルなどは各システムごとに最適化する必要あありますが、
とりあえず今回はAWSチームが参考に書いている値を記載。

■ テスト用のログファイル作成
# touch /tmp/test.log

■ kinesis用設定
# vi /etc/td-agent/td-agent.conf
<source>
  @type tail
  path /tmp/test.log
  pos_file /tmp/test_log.pos
  format none
  tag log.kinesis
</source>

<match log.kinesis>
  @type kinesis_firehose
  region ap-northeast-1
  delivery_stream_name test
  
  flush_interval 1  
  chunk_limit_size 1m
  flush_thread_interval 0.1
  flush_thread_burst_interval 0.01
  flush_thread_count 15
</match>

■ fluentd再起動
# td-agent --dry-run -c /etc/td-agent/td-agent.conf
# systemctl restart td-agent

引用:AWS GitHub

5. 動作確認

以下のコマンドを実行して、対象のログに追記します。
満足したら CTRL + C で中断しましょう。

# while true ;do echo `date` >> /tmp/test.log ;sleep 5;done

対象のS3にログが保存されているはずです。

最後に

とりあえずやりたかったfluentdからKinesisFirehoseを使用して、
S3にログを保存することができました。

Fluentdのログ送信間隔やFirehoseのBuffer conditionsなどのバッファーによるラグがあるので動作確認などが結構手間取るかと思います。

本当のリアルタイムログ収集は難しいですが、そこまでのリアルタイム性を求めないのであればS3の堅牢性を重視して十分な選択肢になるはずです。

AWSコマンド(S3)編メモ

今回したこと

S3をAWSコマンドで捜査した際の基本メモ

なぜやろうとおもったか

毎回AWSの公式リファレンスを見ているのだが備忘録がてらに記載する。

前提

・EC2での捜査。 ・S3へのアクセス権があること。

1. ファイルチェック

aws s3 ls s3://[バケット名]/

2.アップロード

aws s3 cp [ファイル名] s3://[バケット名]/

3. 同期

aws s3 sync --region ap-northeast-1 s3://[同期元バケット名] s3://[同期先バケット名]

4. 切り戻し

aws s3 sync --region ap-northeast-1 s3://[同期先バケット名] s3://[同期元バケット名]

5. ダウンロード

aws s3 cp s3://[バケット名]/[ファイル名] [ファイル名]

最後に

基本の基本だけど自動化に組み込んでしまえばあまり使うことはないのですが、 影響範囲が大きい(間違えてバケットを削除する可能性など)使用する際は改めて確認が必要です。

chkrootkitの導入と実行のメモ

今回したこと

chkrootkitのインストールと実行

なぜやろうとおもったか

rootkitの検出によるセキュリティの担保。

前提

・AmazonLinux ・Epel登録済み

1. chkrootkitのインストール

# yum install chkrootkit

2. chkrootkitの実行

# chkrootkit -l
# chkrootkit 
# chkrootkit | grep INFECTED

最後に

chkrootkitとによって、侵入者が仕込んだrootkitが検出できる可能性が高くなります。 よく使用されるrootkit検出ツールとしてrootkithunterとならんで使用されるchkrootkitを使用してセキュリティの担保を確保しましょう。

AWS AuroraのSlowクエリー出力のパラメーターメモ

今回したこと

AWS AuroraのSlowクエリー出力のパラメーターメモ

なぜやろうとおもったか

SQLの実行時間が遅いクエリおよびindexされていないカラムへのSQLアクセス調査。

前提

AWS Aurora ・デフォルトパラメーターグループ以外を設定済みであること。 *デフォルトパラメーターグループは設定変更不可であるため。

1. indexされていないSQLのログ出力

・log_queries_not_using_indexes 0 ⇒ 1 にする。

2. SlowクエリーのSQLのログ出力

・slow_query_log 0 ⇒1 にする。

3. SlowクエリーのSQLのログ出力を0.5秒以上かかっているクエリーに設定

・long_query_time 空 ⇒ 0.5

最後に

Auroraはデフォルトでテーブル()にSlowクエリーが登録されてテーブルにSlowログがたまっていきます。 標準でログローテーション用のストアドがあるのでこちらを使用してテーブルの肥大化を避けましょう。 標準のストアド:CALL mysql.rds_rotate_slow_log

RootKit Hunterの導入と実行

今回したこと

RootKit Hunterのインストールと実行のメモ

なぜやろうとおもったか

rootkitの検出によるセキュリティの担保。

前提

・AmazonLinux ・Epel登録済み

1. RootkitHunberのインストール

# yum install rkhunter

2.rootkithunterのセキュリティデータベースアップデート

# rkhunter --update 

3.rootkithunterの実行

# diff /etc/rkhunter.conf.rpmsave /etc/rkhunter.conf.org 
< #SCRIPTWHITELIST=/usr/bin/GET
> SCRIPTWHITELIST=/usr/bin/GET
# rkhunter --check --no-mail-on-warning
# rkhunter --check --skip-keypress --report-warnings-only --no-mail-on-warning

最後に

rkhunterによって、侵入者が仕込んだrootkitが検出できる可能性が高くなります。 よく使用されるrootkit検出ツールとしてrootkithunterを使用してセキュリティの担保を確保しましょう。

Serposcopeインストールメモ

今回したこと

Serposcopeインストールメモ

なぜやろうとおもったか

仕事の関係でSerpoScopeをインストールする機会があったのでメモ。

前提

AWS/EC2

1. Java8インストール/切り替え

# yum install java-1.8.0-openjdk-devel 
# alternatives --config java
# java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

2.serposcopeインストール手順

# mkdir /var/project/serposcope
# cd /var/project/serposcope
# wget https://serposcope.serphacker.com/download/2.6.0/serposcope-2.6.0.jar
# /usr/bin/java -jar /var/project/serposcope/serposcope-2.6.0.jar

3. デーモン化対応

# yum install supervisor
# chkconfig --list | grep supervisord
# chkconfig supervisord on
# vi /etc/supervisord.conf
* 末尾に追加。
    [program:serposcope]
    directory=/root/serposcope/
    command=/usr/bin/java -jar /var/project/serposcope/serposcope-2.6.0.jar
    numprocs=1
    autostart=true
    autorestart=true
    user=root
    redirect_stderr=true
    stdout_logfile=/var/log/supervisor/serposcope.log
# service  supervisord restart
# supervisorctl status *こちらにて確認可能

最後に

検索順位チェックツール「Serposcope」のインストールメモでした。