ぼぶろぐ -19ページ目

ぼぶろぐ

以前は、あいらぶLinux♪というタイトルでしたが、
最近はLinux以外のことも書いているので、タイトルを変更しました。
ぼぶちゃんのぶろぐでぼぶろぐです。

以前、AWS基盤の障害でAmazon DNSサーバーと通信できず、名前解決ができなくなるということが起きました。
解決方法としては、VPCのDHCPオプションセットで、セカンダリのDNSサーバーを指定することで解決できるとのことでしたので、以下に設定方法を記載します。

 

DHCPオプションセット
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html

 

1. マネジメントコンソールにログインして、"VPC"をクリックする
2. 左のメニューから"DHCPオプションセット"をクリックする
3. 上部の"DHCPオプションセットの作成"をクリックする
4. 設定する

 

ネームタグ:DHCPオプションセットの名前(つけなくても設定できる)

ドメイン名:既存の設定に合わせる(東京リージョンなら"ap-northeast-1.compute.internal")

ドメインネームサーバー:設定するDNSサーバーを指定(AmazonProvidedDNSは Amazon DNS サーバーで、セカンダリを指定するときはカンマで区切ります)
5. 左メニューの"VPC"をクリックする
6. DHCPオプションセットを変更するVPCを選択する
7. 上部の"アクション"の"DHCP オプションセットの編集"をクリック
8. 先ほど作成したDHCPオプションセットに変更して保存をクリック
9. 即時反映する場合はネットワークの再起動をしますが、そのまま放っておいても反映します(だいたい30分以内に反映します)。

 

■即時反映したとき

[ec2-user@ip-10-0-0-187 etc]$ cat resolv.conf
; generated by /sbin/dhclient-script
search ap-northeast-1.compute.internal
nameserver 10.0.0.2

[ec2-user@ip-10-0-0-187 etc]$ sudo service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:
Determining IP information for eth0... done.
                                                          [  OK  ]
                                                          
[ec2-user@ip-10-0-0-187 etc]$ cat resolv.conf
; generated by /sbin/dhclient-script
search ap-northeast-1.compute.internal
nameserver 10.0.0.2
nameserver 8.8.8.8

 

■放っておいたとき

[ec2-user@ip-10-0-0-187 ~]$ cat /var/log/messages
~省略~
Nov 11 13:17:08 ip-10-0-0-187 dhclient[17798]: DHCPREQUEST on eth0 to 10.0.0.1 port 67 (xid=0x476f5916)
Nov 11 13:17:08 ip-10-0-0-187 dhclient[17798]: DHCPACK from 10.0.0.1 (xid=0x476f5916)
Nov 11 13:17:11 ip-10-0-0-187 NET[22365]: /sbin/dhclient-script : updated /etc/resolv.conf
Nov 11 13:17:11 ip-10-0-0-187 dhclient[17798]: bound to 10.0.0.187 -- renewal in 1591 seconds.
Nov 11 13:17:11 ip-10-0-0-187 ec2net: [get_meta] Trying to get http://169.254.169.254/latest/meta-data/network/interfaces/macs/06:94:95:b5:63:d7/local-ipv4s
Nov 11 13:17:11 ip-10-0-0-187 ec2net: [rewrite_aliases] Rewriting aliases of eth0

ふと、いらないS3バケットを削除しようと思い、削除しようと思ったら削除できなかったS3バケットがあったので、削除方法を記載します。

 

AWS Elastic Beanstalkが作成したS3バケットを削除しようとしたところ以下のようにエラーが発生し、削除することができませんでした。

 

エラーの内容のスクリーンショットをとるのを忘れてしまったのですが、内容は「Access Denied」と出力されておりました。

 

エラー内容が「Access Denied」なので、権限を確認していたら、S3バケットポリシーでS3バケットの削除が許可されていませんでした。

 

S3バケットポリシーの内容抜粋

            "Sid": "xxxxxxxxxxxxxxxxxxx",
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:DeleteBucket",
            "Resource": "arn:aws:s3:::elasticbeanstalk-ap-northeast-1-034872295764"

 

このままだと削除できないので、S3バケットポリシーの"Effect": "Deny"の部分を、"Effect": "Allow"に変更して、保存しました。

 

その後、再度S3バケットの削除を試したところ、エラーは出力されましたが、削除することができました。

 

同じようなことが起きたときは、まず権限の確認をしましょう。

AWS CloudTrail はアカウントに対する AWS API 呼び出しを記録するウェブサービスで、ログファイルはS3に保存されます。このログより、AWS上のリソースの変更履歴を確認することができます。

 

AWS CloudTrail

https://aws.amazon.com/jp/cloudtrail/

 

設定自体はとても簡単で、費用はCloudTrail自体は無料で、ログファイルを保管するS3の使用料のみかかります。

 

設定の仕方は以下です。

 

AWSマネジメントコンソールにログインして、CloudTrailをクリックします。

もし、以下の画面が表示されないときは、左上のオレンジの立方体をクリックしてください。

 

左メニューの"Trail"をクリックし、"Add new trail"をクリックします。

 

"Trail name" と "S3 bucket" を入力して、"Create"をクリックします。

もし、既存のS3バケットを利用するときは、 ""をNoにして、"S3 bucket"に既存のS3バケット名を入力します。

 

これだけで、設定は完了です。

 

ログの確認方法は、左メニューのAPI activity historyをクリックします。

ログの一覧が表示されますので、確認したいログの左の黒い三角形をクリックします。

 

この例は、新しいCroudTrailの作成時のログです。

 

一人で使うのならあまり必要ないかもしれないですが、複数人でAWSリソースを管理するときは、いつだれがなにをしたかを記録しておくことは、とても重要です。

例えば、障害対応時になにか設定を変更したかどうかを確認するときにCloudTrailのログを確認することがあります。

 

便利な機能なので、ぜひ使ってみてください。