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

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

インフラエンジニアがブログを書くことについて

雑記

はじめに

はい。一年ぶりぐらいのポストですね。

誰やねん的なのはtwitterなりFacebookなりWantedlyなり見てもらえればいいと思います。

（今度ブログにも自己紹介ページ設けます。いつか。多分）

 

タイトルからいきなり「インフラエンジニアがブログを書くことについて（ドヤァ）」と大層なタイトルをつけてしまいました。

こうやって人はブログを書くハードルを上げてしまい書かなくなるのです。

かれこれ数回ポストしては書かなくなり、数回ポストしては書かなくなりを８年間続けて来ました。

学生の時のダイエットブログとかも含めると１２年ぐらいブログを書くことに飽き続けててます。

 

でも飽きても飽きても書こうって思うってことは重要だと自分が思うから書くんだと思うんですよね。

なのでこれからは続けることを第一の目的としてチラシの裏的なブログを書いていこうと思います。 

そもそもなぜブログを書くのか

では本題に入ります。

そもそもなんでブログを書くことが重要だと思うかというと、以下がパッと思いついただけで上げられると思います。

  • アフィリエイトで儲かる（めちゃくちゃ読んでもらえれば）
  • 知名度が上がる（めちゃくちゃ読んでもらえれば）
  • 本が出版できる（めちゃくちゃ読んでもらえれば）
  • 転職の時に役立つ（まぁまぁ読んでもらえれば）
  • お金持ちになれる（結構良い企業に転職できたらor本がめちゃくちゃ売れれば）

結局金ですね。

ブログを書いている人はみんなお金が目当てで書いているのです。

なのでこれからブログを書いている人を軽蔑するようにしましょう٩( 'ω' )و

お金以外のブログを書く理由

これだけだと炎上一直線なのでお金以外でブログを書く理由を書いてみました。

  • 自分の考えが整理できる。
  • 文章力が上がる。
  • 技術の情報の取りまとめができるので自分の知識が上がる。
  • 社会貢献できる。
  • 会社の宣伝になる。

以上がお金目的以外で当てはまるかなと思います。

まぁ知名度が上がるも技術の情報が集まってくるようになるので、こっちにカテゴライズされるかもしれません。

自分の考えが整理できる。

個人的にはこれが一番大事だと思います。

文章を書くことで自分の中でバラバラになっていた考え方がまとまっていく。

それはインフラエンジニアにとってというか人間にとって大事なことだと思います。

そのためのツールとしてブログは最適だと思います。

文章力が上がる

普段からドキュメントを書いてればいいんですが、最近IaCとかでインフラエンジニアもコードで表せばよくね？みたいな風潮ありますよね。

あと「Slackばっかりでちゃんとした文章がかけない」・・・あると思います。

普段から一定の量の文章を書くことで文章能力が上がりますよね。

特にSIやってるインフラの人だと設計書書く機会も多いと思います。バリバリ書いて文章力を上げておきましょう。

技術の情報の取りまとめができるので自分の知識が上がる

これが一番大きいと思います。

なんか技術ブログ書いてる人って「技術情報を世間に広めてエンジニア界隈を発展させる」っていってるような人も結構いると思うんですけど、正直「それ一次情報見ればよくない？」って思うことも多いんですよね。

それか「すでにQiitaにあるでしょ」みたいな。

 

いや素晴らしいブログも沢山あるんですよ。

一次情報が英語だったりするので理解が早くなったりもしますし。

 

ただ僕たち凡人エンジニアは技術情報を広める効果よりも「技術の情報の取りまとめができる」ことのメリットの方をかなり大きく享受してると思います。

（オープンソースのコミッターの皆さま。RFCとかそういう仕様作ってる方々。あなた達はもっとドキュメント書いてください。凡人エンジニアのお願いです。日本語がいいですね。）

 

やっぱり人に教えるのってかなりの理解力が必要なんですよね。

教える人がいないけどブログという形なら人に伝えるレベルの文章を書かないといけない。

結果として自分の知識が向上する。

これが一番ブログを書くメリットだと思います。

社会貢献できる/会社の宣伝になる。

「社会貢献ができる」と「会社の宣伝になる」はこれを目的で書くと自分がブログを書くことに飽きるのが目に見えているので僕の目的ではないですが、多分これを目的にしている人も多いと思います。

テックブログで有名な会社さんでクラスメソッドさんとかいますけど典型ですよね。

ブログの会社というだけであれだけ訴求力があるんですからテックブログの効力は結構なものがあると思います。（知らんけど）

 あれ？結構メリット多くない？

書いてて思いましたけど結構メリット多いですよね。

描き続けないと損だと思いました。（僕が）

なのでこれからも書き続けたいと思います。（僕が）

書いてない皆さんは書かない方がいいと思います。なぜなら皆さんのレベルが上がってエンジニア全体のレベルが上がってもっと頑張らないとお賃金のレートが上がらなくなって困るからです。（僕が）

だってメリットしかないじゃないですか。

というわけでこれから

というわけでこれからチラシの裏みたいなブログを書き続けたいと思います。

真面目に書くとすぐ飽きてしまうので。僕による僕のためのブログを心がけたいです。

 

頭の整理を目的としているので読むに値しないこともあるかと思いますが、自分に対してのブログという位置付で書き続けたいと思います。

フィーリングとかガッツとか気持ちとかパッションがこのブログとめちゃくちゃ合ったり、暇だったりして死にそうな方は読んでください。

 

でもたまに技術的なこと書くと思います。

だって普通に仕事中にメモしてることをポストするだけでいいんだし。

その時は「あ、まともなこと書いてるな」と思ってやってください٩( 'ω' )و

 

おまけ

ここまで読んだ暇人の方は思ったでしょう。

「インフラエンジニア関係ないやん..」と。

そんなあなたのために僕のオススメするブログ３選をおまけでのっけちゃいましょう。

 

hb.matsumoto-r.jp

はい。インフラエンジニアならご存知まつもとりーさんのブログです。

僕はこのブログに出会って人生変わったと言っても過言ではないです。

 

特に昔のポストの「Linux系インフラエンジニア3年目のスキルを見抜く50の質問」 ってポストを読んで見てください。心折れますから。

人間とウェブの未来 - Linux系インフラエンジニア3年目のスキルを見抜く50の質問（ホスティングの場合）

僕はエンジニアを始めて3年目で転職しましたが、その時にこのポストを読んで心が折れました。

「無理や・・自分のレベルが低すぎる・・・」と。

 

ただその時から世の中のインフラエンジニアは3年目でこんなことが出来るのだというハードルが上がった状態で生きてきたのである意味高地トレーニング状態でした。

まつもとりーさんありがとうございます。いつかお会いしてお礼が言いたい。

 

nippondanji.blogspot.com

お次は漢のコンピューター道。

DBについて勉強する時はこちらをチェックしましょう。

 

blog.father.gedow.net

最後にドリコムの外道父さんのブログ。

こちらのインフラエンジニアを一から育てた以下のポストは初心者インフラエンジニアの方は必見です。

（新卒でこんな教育受けてたら多分後々の人生イージーモードでしょう。羨ましい。）

新卒インフラエンジニアを育成した話 | 外道父の匠

 

 

 

 

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：AmazonLinux２
  • 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を使用してセキュリティの担保を確保しましょう。