3月, 2020 | フィンガーイース

【CloudWatch】AutoScaling のメモリ/ディスク使用率のグループメトリクスを取得する【AWS】

AutoScaling のグループメトリクスとして、メモリとディスク使用率を取得する必要がございました。
調べると AWS がメトリクス取得用のスクリプトを提供しているようです。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/mon-scripts.html

# 必要なパッケージの導入
yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https perl-Digest-SHA.x86_64
# ディレクトリ移動
cd /usr/local/src/
# スクリプトのインストール
curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O
# スクリプトの解凍
unzip CloudWatchMonitoringScripts-1.2.2.zip && rm CloudWatchMonitoringScripts-1.2.2.zip && cd aws-scripts-mon
# テスト実行
./mon-put-instance-data.pl --mem-util --mem-used --mem-avail --disk-space-util --disk-path=/ --auto-scaling=only
# cronで5分毎に実行
crontab -e
=====================================================================================================================================================================
*/5 * * * * /usr/local/src/aws-scripts-mon/mon-put-instance-data.pl --mem-util --mem-used --mem-avail --disk-space-util --disk-path=/ --auto-scaling=only --from-cron

※ EC2 から CloudWatch を操作できる権限を持った IAM ロールを事前にアタッチしておく必要がございます。
※ インスタンス毎にキャッシュファイルが作成されるので、EC2 起動時にキャッシュファイルを削除するよう UserData を設定しておきます。

#!/bin/bash
rm -rf /var/tmp/aws-mon/*

※ cloudwatch-agent もありますが、こちらではグループメトリクスは取得できないようです。

【Lambda】アラート通知を判別して別々の絵文字を付与し Slack に通知してみる【slack】

【Lambda】CloudWatch の通知を Lambda で Slack に飛ばしてみる【Slack】

↑ 前回の記事の続きです。

アラーム、リカバリ時の通知が判別し辛いので、それぞれの通知に対して別々の絵文字を付与してみます。
※ ランタイムは python3.7 です。

import boto3
import json
import logging
import os

from base64 import b64decode
from urllib.request import Request, urlopen
from urllib.error import URLError, HTTPError


# 通知するチャンネル定義
SLACK_CHANNEL = "#xxxxxx"

# WEB_HOOKURL 定義
HOOK_URL = "https://hooks.slack.com/services/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

logger = logging.getLogger()
logger.setLevel(logging.INFO)


def lambda_handler(event, context):
    logger.info("Event: " + str(event))
    message = json.loads(event['Records'][0]['Sns']['Message'])
    logger.info("Message: " + str(message))

    alarm_name = message['AlarmName']
    new_state = message['NewStateValue']
    reason = message['NewStateReason']

    stamp = ":warning:"
    if new_state == "ALARM":
        stamp = ":warning:"
    else:
        stamp = ":ok_woman:"
        
    slack_message = {
        'channel': SLACK_CHANNEL,
        'text': "%s %s state is now %s: %s" % (stamp, alarm_name, new_state, reason)
    }

    req = Request(HOOK_URL, json.dumps(slack_message).encode('utf-8'))
    try:
        response = urlopen(req)
        response.read()
        logger.info("Message posted to %s", slack_message['channel'])
    except HTTPError as e:
        logger.error("Request failed: %d %s", e.code, e.reason)
    except URLError as e:
        logger.error("Server connection failed: %s", e.reason)

CloudWatch からの通知が ALARM であれば :warning: を付与、それ以外であれば :ok_woman: を付与します。

【Lambda】CloudWatch の通知を Lambda で Slack に飛ばしてみる【Slack】

担当している案件で CloudWatch からの通知を Slackに飛ばす必要があったので、Lambda で実装してみます。

1.事前準備

■ 通知を飛ばす Slack に Incoming WebHooks を追加しておく
https://slack.com/services/new/incoming-webhook

■ 必要なポリシーを付与した IAM ロールを作成しておく
・CloudWatchReadOnlyAccess
・AWSLambdaBasicExecutionRole

■ CloudWatch + SNS の通知設定

2.Lambda設定

Lambda > 関数 > 関数の作成 > 一から作成

関数名：<>
ランタイム：python 3.7
実行ロールの選択：事前準備で作成したIAMロール

> トリガーを追加

トリガーの設定：SNS
SNS トピック：「事前準備で作成したSNSトピック」
トリガーの有効化：有効

関数コード

import boto3
import json
import logging
import os

from base64 import b64decode
from urllib.request import Request, urlopen
from urllib.error import URLError, HTTPError


# 通知を飛ばすチャンネルを定義
SLACK_CHANNEL = "#xxxxxx"

# WEB_HOOKURLを定義
HOOK_URL = "https://hooks.slack.com/services/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

logger = logging.getLogger()
logger.setLevel(logging.INFO)


def lambda_handler(event, context):
    logger.info("Event: " + str(event))
    message = json.loads(event['Records'][0]['Sns']['Message'])
    logger.info("Message: " + str(message))

    alarm_name = message['AlarmName']
    #old_state = message['OldStateValue']
    new_state = message['NewStateValue']
    reason = message['NewStateReason']

    slack_message = {
        'channel': SLACK_CHANNEL,
        'text': "%s state is now %s: %s" % (alarm_name, new_state, reason)
    }

    req = Request(HOOK_URL, json.dumps(slack_message).encode('utf-8'))
    try:
        response = urlopen(req)
        response.read()
        logger.info("Message posted to %s", slack_message['channel'])
    except HTTPError as e:
        logger.error("Request failed: %d %s", e.code, e.reason)
    except URLError as e:
        logger.error("Server connection failed: %s", e.reason)

⇒「SLACK_CHANNEL」「HOOK_URL」に通知を飛ばすチャンネル名とWebHookURLを定義してください。

【スパム対策】opendkim の設定【dkim】

opendkim を導入する機会があったので備忘録を残しておきます。
※ メール送信の際に利用するドメインを test.work とします。

# 必要なパッケージの導入
yum install epel-release
yum install opendkim
yum install mailx

# キーペア作成
mkdir -p /etc/opendkim/keys/test.work
opendkim-genkey -D /etc/opendkim/keys/test.work/ -d testdom.work -s test_work_20200315
chown opendkim:opendkim /etc/opendkim/keys/test.work -R

# KeyTable 追記
vi /etc/opendkim/KeyTable
===============================================================================================================================
test_work_20200315._domainkey.test.work test.work:test_work_20200315:/etc/opendkim/keys/test.work/test_work_20200315.private

# SigningTable 追記
vi /etc/opendkim/SigningTable
====================================================
*@test.work test_work_20200315._domainkey.test.work


# opendkim 設定ファイル調整
vi /etc/opendkim.conf
===========================================================
Mode    sv
KeyTable        /etc/opendkim/KeyTable
SigningTable    refile:/etc/opendkim/SigningTable
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts   refile:/etc/opendkim/TrustedHosts

# opendkim 起動
systemctl start opendkim
systemctl enable opendkim

# opendkim 連携設定
vi /etc/postfix/main.cf
========================================
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
milter_default_action = accept

# postfix 設定反映
postfix check
systemctl reload postfix

# テストメール送信
echo "TEST MAIL" | mail -s "TEST" -r test@test.work xxx@xxx.com


# メールヘッダーに電子署名が追記されているか確認
less /var/log/maillog
========================================================================================================================
Mar 14 16:31:36 test-server1 opendkim[3193]: 0DD5D5B6A2: DKIM-Signature field added (s=test_work_20200315, d=test.work)

DNS サーバに登録するレコードと値はキーペアを作成した際の txt ファイルに情報が書いてます。

[root@test-server1 test.work]# cat /etc/opendkim/keys/test.work/test_work_20200315.txt
test_work_20200315._domainkey   IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpgATXCFihKVnzn9BFZWqyGiFpzmkR5UMhdBz7Uqu+OnKN3+DYh47TSeKlj/4HIz/umGWJ/nAdDMLhkiaTtCfiEml/xxkzzsgwlOL9Iub/gigTaXcYbipAutSjtEoz8MTe+zeHGveLhcxwsEYxm9HQBXiTl6l1yzxqCdFAZes6uQIDAQAB" )  ; ----- DKIM key test_work_20200315 for testdom.work

「test_work_20200315._domainkey.test.work」の txt レコードとして下記を登録すれば OK です。

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpgATXCFihKVnzn9BFZWqyGiFpzmkR5UMhdBz7Uqu+OnKN3+DYh47TSeKlj/4HIz/umGWJ/nAdDMLhkiaTtCfiEml/xxkzzsgwlOL9Iub/gigTaXcYbipAutSjtEoz8MTe+zeHGveLhcxwsEYxm9HQBXiTl6l1yzxqCdFAZes6uQIDAQAB"

【proxy】踏み台経由でデータを同期する【rsync】

こんにちは。
踏み台を経由して rsync でデータ同期する方法を、自分用の備忘録として残しておきます。

↓ 前提として同期先、及び、踏み台に root ユーザで接続できる必要があります。

【AWS】EC2 に root ユーザで接続する【サーバ移設】

# SSH 接続設定
vi ~/.ssh/config
============================================================
# 踏み台サーバ
Host mng-bastion01
    # IP アドレス ( 踏み台サーバ )
    HostName      111.111.111.111
    # 接続ユーザ ( 踏み台サーバ )
    User          root
    # 秘密鍵 ( 踏み台サーバ )
    IdentityFile  ~/.ssh/root_secretkey

# ステージングサーバ
Host stg-web01
    ProxyCommand  ssh -W %h:%p mng-bastion01
    # IP アドレス ( ステージングサーバ )
    HostName      222.222.222.222
    # 接続ユーザ ( ステージングサーバ )
    User          root
    # 秘密鍵 ( ステージングサーバ )
    IdentityFile  ~/.ssh/root_secretkey

# 本番サーバ
Host prod-web01
    ProxyCommand  ssh -W %h:%p mng-bastion01
    # IP アドレス ( 本番サーバ )
    HostName      333.333.333.333
    # 接続ユーザ ( 本番サーバ )
    User          root
    # 秘密鍵 ( 本番サーバ )
    IdentityFile  ~/.ssh/root_secretkey
============================================================
    
# パーミッションを調整
chmod 600 ~/.ssh/config

# 接続確認
ssh mng-bastion01
ssh stg-web01
ssh prod-web01

# /path/to/sync_dir を同期先の /path/to/ 配下に同期 ( ドライラン )
rsync -avzn --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' /path/to/sync_dir stg-web01:/path/to/
rsync -avzn --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' /path/to/sync_dir prod-web01:/path/to/

# /path/to/sync_dir を同期先の /path/to/ 配下に同期
rsync -avz --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' /path/to/sync_dir stg-web01:/path/to/
rsync -avz --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' /path/to/sync_dir prod-web01:/path/to/


# 同期元の /path/to/sync_dir を /path/to/ 配下に同期 ( ドライラン )
rsync -avzn --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' stg-web01:/path/to/sync_dir /path/to/
rsync -avzn --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' prod-web01:/path/to/sync_dir /path/to/

# 同期元の /path/to/sync_dir を/path/to/ 配下に同期
rsync -avz --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' stg-web01:/path/to/sync_dir /path/to/
rsync -avz --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' prod-web01:/path/to/sync_dir /path/to/

【AWS】EC2 に root ユーザで接続する【サーバ移設】

こんにちは。
rsync でデータ同期を行う際、一般ユーザを用いてしまうと owner と group が適切に設定されないケースがあるようです。
AWS EC2 ( AmazonLinux ) のデフォルト設定では root ユーザでの接続ができないので、後述のように設定を調整します。

# 設定ファイルをバックアップ
cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.org
diff /etc/ssh/sshd_config /etc/ssh/sshd_config.org

# sshd 設定ファイルの調整
vi /etc/ssh/sshd_config
======================================
#PermitRootLogin forced-commands-only
PermitRootLogin without-password
======================================
# sshd 設定ファイルの syntax チェック
sshd -t

# sshd 再読み込み
/etc/init.d/sshd reload

# sshd の起動を確認
netstat -lntp | grep sshd

# root ユーザの公開鍵追記
vi /root/.ssh/authorized_keys
=======================================
ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
=======================================

※ 秘密鍵、公開鍵のキーペアは下記コマンドで作成できます。

ssh-keygen -b 2048 -t rsa -f ./key_name

【サーバ移設】Linux の OS ユーザ移設【Tips】

こんにちは。
Linux サーバを移設する際に OS ユーザを移設先サーバにも作成する必要があるんですが、大量に OS ユーザが存在すると面倒くさいですよね。
そんなときは /etc/passwd 関連ファイルをコピーするといいらしいです。
※ 普通に実施すると権限がないので下記の手順が必要です。

# /etc/passwdを編集
vipw
=======================================
user1:x:515:515::/home/user1:/bin/bash
user2:x:504:504::/home/user2:/bin/bash
=======================================
:wq!

# /etc/shadowを編集
vipw -s
=======================================================================================================================
user1:$6$43wzBE4t$XVEOEQpipC9FRocISuPMZ47qPIPwG70sjm2S7ADy4scuwtuBBSlA70q/w0nduW1A2dHUkpVqEW8KW8Ro0:17387:0:99999:7:::
user2:$6$G8m9jYDT$X53N71JCVXbbJnDLrvBED67ZrrwtL.hfJa.9sosksjwnaUtlLF/K0F2l9KvmsgrULgFQ/KahH6C.:17220:0:99999:7:::
=======================================================================================================================
# 保存できないので無理やり保存する
:w !sudo tee %
:q!

# /etc/groupを編集
vigr
=============
user1:x:515:
user2:x:504:
=============

# /etc/gshadowの編集
vigr -s
===========
user1:!::
user2:!::
===========
# 保存できないので無理やり保存する
:w !sudo tee %
:q!

【redash】dumpファイルからの復旧/データ移行【Docker】

【redash】Dockerコンテナ内部からdumpデータを取得【シェルスクリプト】

↑dumpデータの取得はこちらで。

dumpデータから redash のレストア/データ移行手順になります。

# コンテナ停止
docker-compose -f docker-compose-redash.yml down --remove-orphans

# PostgreSQLのコンテナのみ起動
docker container run -d -v /path/to/postgres-data:/var/lib/postgresql/data -p 5432:5432 postgres:9.5.6-alpine

# PostgreSQLのコンテナIDを確認
docker ps | grep postgres | awk '{print $1}'

# dumpファイルをコンテナに転送
docker container cp /path/to/redash-backup_$(date +"%Y%m%d").gz [コンテナID]:/usr/local/redash-backup_$(date +"%Y%m%d").gz

# DBの削除
docker container exec [コンテナID] /bin/bash -c 'psql -c "drop database if exists postgres" -U postgres template1'

# DBの作成
docker container exec [コンテナID] /bin/bash -c 'psql -c "create database postgres" -U postgres template1'

# dumpデータのインポート
docker container exec [コンテナID] /bin/bash -c 'zcat /usr/local/redash-backup_$(date +"%Y%m%d").gz | psql -U postgres -d postgres'

# PostgreSQLのコンテナ停止
docker container stop [コンテナID]

# PostgreSQLのコンテナ削除
docker container rm [コンテナID]

# コンテナ起動
docker-compose -f docker-compose-redash.yml up -d

↓redash の構築方法はこちら

【Docker】redashの構築【CentOS7】

【redash】Dockerコンテナ内部からdumpデータを取得【シェルスクリプト】

そういえば redash のバックアップを取得していなかったなと気づきまして。
どうやらコンテナ内部の PostgreSQL の dumpデータを取得するればいいようです。

↓こんな感じのシェルスクリプトをcronで定期実行すればいいですね!

#!/bin/sh

# バックアップディレクトリを定義
BACKUP_DIR=/var/backup
# バックアップファイルを保持する期間を定義
TIME=3

# DBのコンテナIDを取得
CID=$(docker container ls | grep postgres | awk '{print $1}')

# dumpを取得
docker container exec ${CID} /bin/bash -c 'pg_dump -U postgres postgres | gzip > /usr/local/redash-backup.gz'

# ホストにdumpを転送
docker container cp ${CID}:/usr/local/redash-backup.gz ${BACKUP_DIR}/redash-backup_$(date +"%Y%m%d").gz

# dumpのローテート設定
find ${BACKUP_DIR}/ -daystart -name '*.gz' -mtime +${TIME} -delete

↓redashの構築方法はこちら

【Docker】redashの構築【CentOS7】