zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

【AWS】Cloudwatchのcron式では日フィールドと曜日フィールドを同時に指定できない

【問題と解決】

Cloudwatchルールのイベントソースで以下のcron式を指定しようとすると書式エラー（Parameter ScheduleExpression is not valid.）

30 2 * * FRI *

以下のようにすると解決

30 2 ? * FRI *

【メモ】

下記リンクより
>cron 式の日フィールドと曜日フィールドを同時に指定することはできません。一方のフィールドに値 (または *) を指定する場合、もう一方のフィールドで ? (疑問符) を使用する必要があります。
なんと。。

【参考】

docs.aws.amazon.com

【AWS】AutoScalingでElasticIPを自動割り当て201909

【参考】

Auto Scalingで起動したインスタンスにEIPを自動で設定する方法 | Ryuzee.com
※上記ほぼそのまま。エラーが出てたのでgrepを追記しました

AutoScalingでElasticIPを自動割り当てするには - Qiita
※こっちのスクリプトはgrepが足りなくて（今では）正常に動作しない。
　先にこちらを見てハマったのでメモを残しておきます。

EC2 Linux ユーザーデータをログに記録し、コンソールログに送る

【結論】

事前準備
1)割り当て対象となるEIPを確保
省略

2)IAM Roleを作成
→下記内容のポリシーを作成、EC2インスタンスに適用されるロールにアタッチしておく

ポリシー名：AssociateAddress（例)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeAddresses",
        "ec2:AssociateAddress"
        ],
      "Effect": "Allow",
      "Resource": "*"
    }
   ]
}


3)以下の内容のshをAMIのもとになるインスタンスに作成

例）
/usr/local/bin/associate_eip.sh

#!/bin/bash -ex

exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1

echo BEGIN

INSTANCE_ID=`curl http://169.254.169.254/latest/meta-data/instance-id`
REGION=`curl http://169.254.169.254/latest/dynamic/instance-identity/document | grep region | awk -F\" '{print $4}'`

for ALLOC_ID in `aws ec2 describe-addresses --region=$REGION --filter "Name=domain,Values=vpc"  --output text | grep -v eipassoc- | grep -v Name | awk '{print $2}'`
do
  CMD="aws ec2 associate-address --instance-id $INSTANCE_ID --allocation-id $ALLOC_ID --no-allow-reassociation --region=$REGION"
  $CMD
  STATUS=$?
  if [ 0 = $STATUS ] ; then
    exit 0
  fi
done

→実行権限を付与（chmod +x associate_eip.sh）

4)ユーザーデータ経由で実行する
オートスケーリングのユーザーデータで

#!/bin/bash
export HOME=/root
/usr/local/bin/associate_eip.sh

とかやるとうまくいった。

【AWS Backup】2時間おきにEBSのスナップショットを取る

【前置】

先日のAWS障害でスナップショットから復旧(http://zuntan02.hateblo.jp/entry/2019/08/26/092722)
したのだけど、自前で配置してたセルフスナップショットshの頻度がデイリーだったので、ちょっとログが抜けてしまった。
クリティカルなサービスではないし、cronの頻度を上げればいいだけの話なんだけど、せっかく[AWS Backup]というサービスが使えるようになったので試しに使ってみた

【目標】

  • 2時間おき(※)にスナップショットをとる
  • スナップショットは10日保持したのち削除する

※startWindowMinutesが最短でも60分であるため、毎時実行させると1時間のうちに2回スナップショットがとられたりしていまいち。最短でも2時間に1回が妥当と思われた。

【作業】

1)事前にバックアップしたいEBSのIDをメモる。

EBS ID vol-hogehogefugafuga

2)バックアッププランとルールを作成する

[AWSマネージメントコンソール]-[AWS Backup]-[バックアッププラン]-[バックアッププランを作成]-[新しいプランを立てる]

バックアッププラン名：10days-Backup

バックアップルールの設定
ルール名：Every2hours-10days-Backup

スケジュール：
→プルダウンでは最短でも12時間ごとしか選べないので、ここでは[カスタムcron式]を選択

Cron式は以下のとおりとする

cron(0 0/2 * * ? *)

バックアップウィンドウ
バックアップウィンドウをカスタマイズ：数時間以内にバックアップを開始：1

ライフサイクル

  • コールドストレージへの移行：しない
  • 有効期限切れ：作成後の日数:10

バックアップボールト:Default

復旧ポイントに追加されたタグ：任意
バックアッププランに追加されたタグ：任意

上記で[プランを作成]

3)プランにリソースを割り当てる

リソース割り当て名：サーバ名など
IAM ロール：デフォルトのロール
リソースを割り当てる：割り当て単位(ここではリソースID)、リソースタイプ（ここではEBS）、ボリュームIDなどを選択

以上で、（およそ）2時間おきにスナップショットが作成され、10日保持された後自動削除されていくことになります。

【AppleWatch】AppleWatchの画面交換プログラム発表前に修理してた場合、支払い済みの料金が戻ったメモ

【概要】
7月頃、朝充電器の上のApple Watch Series 3（2017年末購入）のガラス面がパカパカするなーと思ったら一周リング状に割れていた。特に落としたわけでもなく、充電器にセットしたときは特に問題なかった（と思う）。タッチも受け付けず、どうにもならない。仕方なくwatch 修理 - Apple サポート 公式サイトから修理に出して、28,000円くらいで交換修理となった。

ひと月ほどたったところで以下の交換プログラムが。運が悪い……！
support.apple.com

で、ダメ元でサポートに聞いてみたところ、なんとこれが返金対応可能とのこと。
サポートは大変柔軟かつ丁寧で、いろいろしっかり話を聞いてくれた（チャット→電話）。
画面割れのときの写真がある、と伝えたところ、その写真を送ってくれ、と言われ、送ったところ本来必要な確認ステップを色々スキップできた模様。

修理プログラム対象だったのにもう修理しちゃった……って人は（多少面倒ですが）Appleサポートに聞いてみると返金あるかもしれませんよ！

【AWSゾーン障害】ボリュームが復旧しないのでスナップショットからボリュームを立て直してアタッチしなおしたメモ

2019/08/23午後のap-northeast-1aのゾーン障害（https://aws.amazon.com/jp/message/56489/）で、大体のサービスはMultiAZで問題なかったし、しばらくしたら自動復旧したんだけど、一台だけボリュームが破損したらしくて復旧してこなかった。
パーソナルヘルダッシュボード（マネージメントコンソールの上にあるベルアイコンからいける）で確認すると

On August 22 we experienced a cooling failure in a single Availability Zone in the Tokyo (AP-NORTHEAST-1) Region, which has caused one or more of your volumes listed in the 'Affected Resources' tab, to be inaccessible. The cooling failure resulted in hardware failure on one or more storage servers that store your volume(s). We are working to resolve the hardware failures; however, if you have the ability to restore your volume(s) from a recent snapshot, we recommend that you do so. Given the nature of the hardware failures, we anticipate that recovery will be prolonged as we work to replace the failed components in the affected servers.

（Google翻訳）

8月22日、東京（AP-NORTHEAST-1）リージョンの単一のアベイラビリティーゾーンで冷却障害が発生し、「影響を受けるリソース」タブにリストされている1つ以上のボリュームにアクセスできなくなりました。冷却障害により、ボリュームを保存する1つ以上のストレージサーバーでハードウェア障害が発生しました。ハードウェア障害の解決に取り組んでいます。ただし、最新のスナップショットからボリュームを復元できる場合は、復元することをお勧めします。ハードウェア障害の性質を考えると、影響を受けるサーバーの障害のあるコンポーネントを交換するために作業するため、復旧が長くなることが予想されます。

ってなってたので、デイリーでとってるスナップショットからの Amazon EBS ボリュームの復元を実施した。

【参照】

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-restoring-volume.html
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-detaching-volume.html

■スナップショットからボリュームを作成

[スナップショット]で対象のスナップショットを選択
[アクション]-[ボリュームの作成]
（設定は旧のものと合わせた）

■ボリュームのデタッチとアタッチ

# デタッチ
https://console.aws.amazon.com/ec2/) にある Amazon EC2 コンソールを開きます。
ナビゲーションペインの [Volumes (ボリューム)] を選択します。
ボリュームを選択し、[Actions]、[Detach Volume] の順に選択します。
確認ダイアログボックスで、[Yes, Detach] を選択します。

やったこと
  • 上記手順に従い問題のサーバににアタッチされていた旧ディスクをデタッチ
  • 新ディスクをアタッチして起動

→エラー発生
Invalid value 'xxxxxxxxx' for instanceId. Instance does not have a volume attached at root (/dev/xvda)
→デフォルトで付与されるデバイスの設定が間違っていた
デバイス：/dev/xvdaでアタッチしなおしたら起動した


以上

bashのコマンドプロンプトに環境ごとに色を付ける

【参考】
qiita.com


例)

DEV（水色）

echo '[ "$PS1" = "" ] || PS1="[\u@\[\e[1;46m\]\h\[\e[0m\] \W] \$ "' >> /etc/profile.d/prompt.sh

STG（緑色）

echo '[ "$PS1" = "" ] || PS1="[\u@\[\e[1;42m\]\h\[\e[0m\] \W] \$ "' >> /etc/profile.d/prompt.sh

PROD

echo '[ "$PS1" = "" ] || PS1="[\u@\[\e[1;41m\]\h\[\e[0m\] \W] \$ "' >> /etc/profile.d/prompt.sh

※
chmod +x /etc/profile.d/prompt.sh
しておくこと