AWS 認定 DevOps エンジニア – プロフェッショナル に合格しました！
これでAWS認定5冠達成です！
AWSの経験値
ここ3年間くらいはAWSでインフラ運用・構築したり、アプリケーション基盤作ったり。
TerraformとAnsibleで環境作ることが多いけど、試験範囲であるElastic BeanstalkやOpsWorksはほとんど使ったことがなく。
CloudFrontは少々使ったことがある程ででした。
勉強方法
これまでAWSの試験対策はもっぱら Linux Academy っていうオンラインの対策コースをやってきたのですが、
今回はA CLOUD GURUに浮気しました。
A CLOUD GURUは動画による講義とクイズにより構成されています。Linux Academyと違ってハンズオンがなかったのが残念な点です。
動画のクオリティはいいんですけどね。
Linux Academy 同様、英語なんで辛い部分もありますが、スライドと見ながら聞けば、何とかついていけるレベルです。
また、上司がこの試験の推奨セミナー「DevOps Engineering on AWS」を受講させてくれたのですが、
これは試験対策という意味合いは薄かったです。
試験では出ないCode CommitやCode CompleteなどのCode 5兄弟の話にだいぶ時間が割かれていたのが要因の一つですが、
AWSでのDevOpsを学ぶ上ではCode 5兄弟の話は欠かすことのできないものであると感じれたので、トータルでは無駄ではありません。
デプロイ戦略などの話も、良い復習になりました。
勉強期間
期間としては4ヶ月ほど。すごくダラダラと勉強してました。
勉強時間はちゃんと測ってないけど、60時間くらいかな。
内訳は
- A CLOUD GURU 15H
- 各サービスを触ってみる 10H
- AWSのドキュメントを読む 10H
- セミナー受講+復習 25H
試験を終わって振り返ると、業務でIAMのクロスアカウントを設定したり、
Terraformで環境を構築してきた経験が非常に効いたなと感じました。
勉強ではAWS固有のテクノロジーや用語を抑えて行きました。
例えばCloudFormationのWaitHandlerとかは勉強しとかないとですね。
模擬試験
1ヶ月前にうけた模試は、40%で不合格。
トピックレベルスコアリングの"Security, Governance, and Validation"なんて0%。
が、この模擬試験をしっかり復習したのは、合格のポイントだったと今では思います。
サンプル問題も解いておいて損はないです。
復習の甲斐あってか、本試験では"Security, Governance, and Validation"のスコア100%まで行きました。
最後に
実は一度は不合格をくらい、半額のバウチャーチケットがあったとはいえ16000円がパー。
非常に痛かった。。。。
2度目の受験では結局71%で合格しました。
セミナーでも話があったのですが、はDevOpsは文化なので、ツールだけでは実践できない面が多々あります。
先日読んだ、「The DevOps 逆転だ！究極の継続的デリバリー」の話なんてまさにそうでした。
どういう文化を作っていくかということを考えるときに、どういうツールがあるかを知っていると実現性に現実味が増します。
とはいえ、文化を作っていくのは試験に合格するなんかより相当難しいですね。
S3をEC2からマウントするgoofysを試してみた。
昔s3fsを試したことがあるんだけど、パフォーマンスが問題になったりしたことがありました。
巷では爆速と噂のgoofysですが、とりあえずパフォーマンスは置いておいて、できないことが何かを見ておきました。
何ができないのか
公式にもPOSIXは二の次ということで、できないことを書いてくれています。
group,modeとかは固定,simlinkは動かないそうです。
後、atime,mtime,ctimeが全部同じになります。
インストール
とはいえ使い心地を見ときたかったので、インストールして見ました。
ansibleで環境を作って見ました。
fuseとgoが必要です。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| ---
- hosts: tag_Name_gside_goofys
remote_user: gentoo
become: true
tasks:
- name: install sys-fs/fuse
portage: >
package=sys-fs/fuse
state=present
- name: install dev-lang/go
portage: >
package=dev-lang/go
state=present
- name: goofys Download
get_url: url="https://github.com/kahing/goofys/releases/download/v0.0.10/goofys" sha256sum="78baba6f9c3d8cb06a55a872f0380bc8b37af649a0a7d6961d0789a3bdcd62d4" dest="/usr/local/bin" mode="744"
|
実はmountの設定も書いていたのですが、IAM RoleでEC2に権限を与えて動作させようとした場合、fstabの設定ではマウントしてくれませんでした。
Credentialを置きたくない・置けないポリシーの場合はネックになりそうですね。
検証
IAM Role + fstabは動作しなかったので、コマンドでマウントします。
1
2
3
4
5
6
7
8
9
10
| $ goofys gside-goofys /mnt/s3/
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
udev 10M 0 10M 0% /dev
/dev/xvda2 8.6G 2.3G 5.9G 28% /
tmpfs 49M 240K 49M 1% /run
shm 242M 0 242M 0% /dev/shm
cgroup_root 10M 0 10M 0% /sys/fs/cgroup
gside-goofys 1.0P 0 1.0P 0% /mnt/s3
|
ファイルを作ってみました。
1
2
3
| $ touch /mnt/s3/hoge
$ ls -la /mnt/s3/hoge
-rw-r--r-- 1 root root 0 2月 19 21:09 /mnt/s3/hoge
|
ヘルプにもありますが、fileのモードは644,uid,gidは0がデフォルトで固定です。
これらの固定値はオプションで違う値に変更は可能ですが、固定値であることは変わりません。
1
2
| $ ln -sf hige /mnt/s3/foo
ln: シンボリックリンク '/mnt/s3/foo' の作成に失敗しました: 関数は実装されていません
|
シンボリックリンクは作れません。
まとめ
この割り切りが受け入れれるかというところでしょうね。
それでも爆速という点を重視して、制限を受け入れた上での使い道はいくらでもあると思います。
が、IAM Role+fstabの部分は対応を切望したいところです。
S3のバージョニングの機能は知っていたのですが、
古いバージョンをリストアする方法をちゃんと調べていませんでした。
バックアップとっててリストアできないなんて、最低ですね。
バージョニングが有効なバケットを作成する
まずはバージョニングが有効なS3バケットを作成しましょう。
今回もTerraformでお手軽に作っていきます。
1
2
3
4
5
6
7
| resource "aws_s3_bucket" "version-test" {
bucket = "gside-version-test"
acl = "private"
versioning {
enabled = true
}
}
|
ファイルをアップロードする。
適当なファイルを作ってS3にアップします。
1
2
| $ echo "hoge" > ~/hoge.txt
$ aws s3 cp ~/hoge.txt s3://gside-version-test/
|
aws s3api コマンドでバージョン情報を見てみます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| $ aws s3api list-object-versions --bucket gside-version-test
{
"Versions": [
{
"VersionId": "i4ngO7osXqV4GrFoXpHzblnWD7y3jIRa",
"Owner": {
"DisplayName": "foobar",
"ID": "2614e1fe5abbd1f85bc3c9b930b22f8f4f6eced59986b995b5e38cf655d7a7e0"
},
"LastModified": "2016-12-11T13:16:50.000Z",
"StorageClass": "STANDARD",
"ETag": "\"c59548c3c576228486a1f0037eb16a1b\"",
"Key": "hoge.txt",
"IsLatest": true,
"Size": 5
}
]
}
|
ファイルを更新して、バージョン情報を見てみます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| $ echo "fuga" > ~/hoge.txt
$ aws s3 cp ~/hoge.txt s3://gside-version-test/
$ aws s3api list-object-versions --bucket gside-version-test
{
"Versions": [
{
"LastModified": "2016-12-11T13:18:01.000Z",
"VersionId": "URhALfhfq69Zdqoh_z.b6j4ac5XR43oK",
"ETag": "\"11c9c5d7c37e614b4d99eea11672227e\"",
"StorageClass": "STANDARD",
"Key": "hoge.txt",
"Owner": {
"DisplayName": "foobar",
"ID": "2614e1fe5abbd1f85bc3c9b930b22f8f4f6eced59986b995b5e38cf655d7a7e0"
},
"IsLatest": true,
"Size": 5
},
{
"LastModified": "2016-12-11T13:16:50.000Z",
"VersionId": "i4ngO7osXqV4GrFoXpHzblnWD7y3jIRa",
"ETag": "\"c59548c3c576228486a1f0037eb16a1b\"",
"StorageClass": "STANDARD",
"Key": "hoge.txt",
"Owner": {
"DisplayName": "foobar",
"ID": "2614e1fe5abbd1f85bc3c9b930b22f8f4f6eced59986b995b5e38cf655d7a7e0"
},
"IsLatest": false,
"Size": 5
}
]
}
|
ファイルをリストアする。
ファイルをアップロードするにはaws s3api get-objectコマンドを利用して、上記のversion-idを指定してファイルを取得します。
1
2
3
4
5
6
7
8
9
10
11
12
| $ aws s3api get-object --bucket gside-version-test --key hoge.txt --version-id i4ngO7osXqV4GrFoXpHzblnWD7y3jIRa /tmp/hoge.txt
{
"AcceptRanges": "bytes",
"ContentType": "text/plain",
"LastModified": "Sun, 11 Dec 2016 13:16:50 GMT",
"ContentLength": 5,
"VersionId": "i4ngO7osXqV4GrFoXpHzblnWD7y3jIRa",
"ETag": "\"c59548c3c576228486a1f0037eb16a1b\"",
"Metadata": {}
}
$ cat /tmp/hoge.txt
hoge
|
まとめ
復旧するファイルが少ない場合は、コマンドラインで淡々とリストアする方法で行けそうです。
ファイルが多くなると、もうちょっと工夫が必要そうですね。
ちなみにファイルが消した場合でも aws s3api list-object-versions の情報は消えないので、復旧することができます。
GentooをAWS上で動かすために、イメージを作ってみました。
クラウドに使えるstage4ファイルを利用すれば、簡単にできてしまいます。
追加ボリュームにgentooをインストール後、snapshot作成、AMI作成という手順でいきました。
追加ディスクにGentooをインストールする。
何でもいいんで、LinuxベースのAMIを立ち上げ、
EBSボリュームを追加であタッチするところから始めます。
まずはディスクの用意から。/dev/xvdb が追加ディスクです。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| parted -a optimal /dev/xvdb
(parted) mklabel gpt
(parted) unit mib
(parted) mkpart primary 1 3
(parted) name 1 grub
(parted) set 1 bios_grub on
(parted) mkpart primary 3 9000
(parted) name 2 cloudimg-rootfs
(parted) mkpart primary 9000 -1
(parted) name 3 swap
(parted) print
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdb: 10240MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1.00MiB 3.00MiB 2.00MiB ext4 grub bios_grub
2 3.00MiB 9000MiB 8997MiB cloudimg-rootfs
3 9000MiB 10239MiB 1239MiB linux-swap(v1) swap
(parted) quit
|
ファイルシステムを構築します。
1
2
3
4
5
6
| $ mkfs.ext4 /dev/xvdb2
$ e2label /dev/xvdb2 cloudimg-rootfs
$ mkswap --label swap /dev/xvdb3
$ mkdir -p /mnt/gentoo
$ mount /dev/xvdb2 /mnt/gentoo
$ swapon /dev/xvdb3
|
stageファイルを展開します。
1
2
3
| $ cd /mnt/gentoo
$ wget http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64/stage4-amd64-cloud-20161201.tar.bz2
$ tar xjf stage4-amd64-cloud-20161201.tar.bz2
|
もろもろmountして、
1
2
3
4
5
| $ mount -t proc proc /mnt/gentoo/proc
$ mount --rbind /sys /mnt/gentoo/sys
$ mount --rbind /dev /mnt/gentoo/dev
$ chroot /mnt/gentoo/ /bin/bash
$ source /etc/profile
|
portageツリーを最新化。
1
2
| $ emerge --sync
$ emerge --ask --update --deep --newuse @world
|
ローケールを設定します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| $ echo "Asia/Tokyo" > /etc/timezone
$ emerge --config sys-libs/timezone-data
Configuring pkg...
* Updating /etc/localtime with /usr/share/zoneinfo/Asia/Tokyo
$ vi /etc/locale.gen
ja_JP.UTF-8 UTF-8
$ locale-gen
* Generating 3 locales (this might take a while) with 1 jobs
* (1/3) Generating en_US.ISO-8859-1 ... [ ok ]
* (2/3) Generating en_US.UTF-8 ... [ ok ]
* (3/3) Generating ja_JP.UTF-8 ... [ ok ]
* Generation complete
$ eselect locale list
[1] C
[2] en_US
[3] en_US.iso88591
[4] en_US.utf8 *
[5] ja_JP.utf8
[6] POSIX
[ ] (free form)
$ eselect locale set 5
Setting LANG to ja_JP.utf8 ...
Run ". /etc/profile" to update the variable in your shell.
$ env-update && source /etc/profile
>>> Regenerating /etc/ld.so.cache...
|
/etc/fstabを編集します。
1
2
| LABEL=cloudimg-rootfs / ext4 defaults 0 0
LABEL=swap none swap sw 0 0
|
/etc/conf.d/netを編集します。
ネットワークを設定します。
1
2
3
| $ cd /etc/init.d/
$ ln -s net.lo net.eth0
$ rc-update add net.eth0 default
|
Grubを設定します。
1
2
3
4
5
6
7
8
9
| $ grub-install /dev/xvdb
Installing for i386-pc platform.
Installation finished. No error reported.
$ grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/kernel-genkernel-x86_64-4.4.26-gentoo-openstack
Found initrd image: /boot/initramfs-genkernel-x86_64-4.4.26-gentoo-openstack
done
|
/mnt/gentoo/etc/cloud/cloud.cfgに下記を追記
1
| datasource_list: [ Ec2, None ]
|
SnapshotからGentooインスタンスを立ち上げる
ここまで来たら、作るためにsnapshotを取ります。
作ったSnapshotからAMIを作ってインスタンスを起動するTerraformの設定は下記になります。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| resource "aws_ami" "gentoo-base" {
name = "gentoo-base-20161124"
virtualization_type = "hvm"
root_device_name = "/dev/sda1"
ebs_block_device {
device_name = "/dev/sda1"
snapshot_id = "snap-1c6e4993"
volume_size = 10
}
}
resource "aws_instance" "gside-gentoo" {
ami = "${aws_ami.gentoo-base.id}"
availability_zone = "${aws_subnet.main.availability_zone}"
ebs_optimized = false
associate_public_ip_address = false
instance_type = "t2.nano"
monitoring = false
key_name = "${aws_key_pair.gside-key.key_name}"
vpc_security_group_ids = ["${aws_security_group.basic.id}"]
associate_public_ip_address = true
disable_api_termination = "true"
source_dest_check = "false"
subnet_id = "${aws_subnet.main.id}"
root_block_device {
volume_type = "gp2"
volume_size = 10
delete_on_termination = true
}
tags {
"Name" = "gside-gentoo"
}
}
|
起動後はgentooユーザーでsshログインできます。
まとめ
CloudフレンドリーなStage4ファイルが有るおかげで、色々楽ちんでした。
中身は下記が詳しいです。
https://mthode.org/posts/2016/Jan/stage4-tarballs-minimal-and-cloud/
stage4の中身についてもここからたどれます。
独自のAMIを作ってたら、どうもうまく行かず。Try and Errorの様相を呈してきた。
何度もSnapshot作ってAMIを作ってLaunchってやり始めたので、Terraformでこの辺をやるようにした。
ただ、EBSボリュームからSnapshotを作る部分は見つけられなかったので、Snapshotを作るところは手動です。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| resource "aws_ami" "origin-base" {
name = "origin-base-20161124"
virtualization_type = "hvm"
root_device_name = "/dev/sda1"
ebs_block_device {
device_name = "/dev/sda1"
snapshot_id = "snap-60559eee"
volume_size = 10
}
}
resource "aws_instance" "gside-origin" {
ami = "${aws_ami.origin-base.id}"
availability_zone = "${aws_subnet.main.availability_zone}"
ebs_optimized = false
associate_public_ip_address = false
instance_type = "t2.nano"
monitoring = false
key_name = "${aws_key_pair.gside-key.key_name}"
vpc_security_group_ids = ["${aws_security_group.basic.id}"]
associate_public_ip_address = true
disable_api_termination = "true"
source_dest_check = "false"
subnet_id = "${aws_subnet.main.id}"
root_block_device {
volume_type = "gp2"
volume_size = 10
delete_on_termination = true
}
tags {
"Name" = "gside-origin"
}
}
|
とあるインスタンスに追加でEBS VolumeをAttacheしたかったのですが、
現在のTerraform(Ver 0.7.9)では新規にインスタンスを作成し直さないとできないようです。
残念。
ebs_block_deviceの箇所で追加のEBSについて記載しています。
サイズとマウントポイントを記載するだけ。
簡単なんだけどやはりインスタンス作りなおしなのは惜しいですね。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| resource "aws_instance" "gside" {
ami = "ami-0c11b26d"
availability_zone = "${aws_subnet.main.availability_zone}"
ebs_optimized = false
associate_public_ip_address = false
instance_type = "t2.nano"
monitoring = false
key_name = "${aws_key_pair.gside-key.key_name}"
vpc_security_group_ids = ["${aws_security_group.basic.id}"]
associate_public_ip_address = true
private_ip = "10.0.1.10"
disable_api_termination = "true"
source_dest_check = "false"
subnet_id = "${aws_subnet.main.id}"
root_block_device {
volume_type = "gp2"
volume_size = 10
delete_on_termination = true
}
ebs_block_device {
device_name = "/dev/xvdb"
volume_size = 10
}
tags {
"Name" = "gside"
}
}
|
インスタンスにログインしてディスクの状況を確認します。
1
2
3
4
5
| [ec2-user@ip-10-0-1-10 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 10G 0 disk
└─xvda1 202:1 0 10G 0 part /
xvdb 202:16 0 10G 0 disk
|
AMIを作る時に必要なSSHのキーですが、
Terraformでは鍵のインポートのみサポートしています。
確かに秘密鍵をダウンロードするより、公開鍵をアップロードするほうが健全ですね。
鍵の作成
手元のPCで秘密鍵と公開鍵のペアを作成します。
1
2
3
4
5
6
7
8
| $ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
Your public key has been saved in
The key fingerprint is:
|
リソースにaws_key_pairを使って、公開鍵をアップロードします。
key_nameの参照には${aws_key_pair.gside-key.key_name}を使います。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| resource "aws_key_pair" "gside-key" {
key_name = "gside-key"
public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCvGSftV0pe4Pu4AA6CIwZ5QwUnVmO1YZ6LnkUuY1oti0OBuwNhvKE2gJ7eELwUmXLixq5OsccItAeUyIstp8u86AJqaO4DeZBE6gHwaBlrKKG+0b0jFsNCtfFu/jFsmnTuED5I/MpggUk0NKV4BFveqX9Wi7fxaOt5XEsx4XR9mJD+RrtrVAuzSoSK3y3jJgLKpBku1TqcaPZutE6fHIE6OalPRY0JCrN9WzQmFWXL+whTe9KaPMKs6PdHeFG+KBpnY9VjQxxc+lPmMfcID1t/xAuYpi5TZQbtB+YH5Qrn4uz+v1FyL9N/GYmcX8dVz9d9HMgXDUgzgEZU3JpWd6uf gside"
}
resource "aws_instance" "gside" {
ami = "ami-0c11b26d"
availability_zone = "${aws_subnet.main.availability_zone}"
ebs_optimized = false
associate_public_ip_address = false
instance_type = "t2.nano"
monitoring = false
key_name = "${aws_key_pair.gside-key.key_name}"
vpc_security_group_ids = ["${aws_security_group.basic.id}"]
associate_public_ip_address = true
private_ip = "10.0.1.10"
disable_api_termination = "true"
source_dest_check = "false"
subnet_id = "${aws_subnet.main.id}"
root_block_device {
volume_type = "gp2"
volume_size = 10
delete_on_termination = true
}
tags {
"Name" = "gside"
}
}
|
まとめ
これで秘密鍵をダウンロードする気持ち悪さからもおさらばです。
MD5でファイルが同じかどうかを判定することがあります。
S3ではETAGにMD5値が格納されているという事になっていますが、
結論から言うと、Multipart Updateされた場合と、そうでない場合で異なります。
s3 cpコマンドで試してみる(9M)
9Mのテストファイルを作ります。
1
2
3
4
| $ dd if=/dev/zero of=~/test9M bs=1M count=9
9+0 レコード入力
9+0 レコード出力
9437184 バイト (9.4 MB) コピーされました、 0.0269213 秒、 351 MB/秒
|
Bucketにコピーします。
1
2
| $ aws s3 cp ~/test9M s3://gside-test/test9M
upload: ../test9M to s3://gside-test/test9M
|
このコマンドでアップロードされた9Mのファイルは、ETAGがこんな感じ
1
2
3
4
5
6
7
8
9
| $ aws s3api head-object --bucket gside-test --key test9M
{
"Metadata": {},
"ETag": "\"d126ef08817d0490e207e456cb0ae080-2\"",
"ContentLength": 9437184,
"LastModified": "Sat, 22 Oct 2016 14:20:04 GMT",
"ContentType": "binary/octet-stream",
"AcceptRanges": "bytes"
}
|
ETagの値は “d126ef08817d0490e207e456cb0ae080-2” とハイフン付きの値です。
一方MD5はというと
1
2
| $ md5sum ~/test9M
b82b4ab87e44976024abc14a1670dac
|
ETAGの値とは違ってますね。Multipartアップロードされたのが原因です。
s3 cpコマンドで試してみる(8M)
8Mのテストファイルで同様のことをやってみます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| $ dd if=/dev/zero of=~/test8M bs=1M count=8
8+0 レコード入力
8+0 レコード出力
8388608 バイト (8.4 MB) コピーされました、 0.0204059 秒、 411 MB/秒
$ aws s3 cp ~/test8M s3://gside-test/test8M
upload: ../test8M to s3://gside-test/test8M
$ aws s3api head-object --bucket gside-test --key test8M
{
"LastModified": "Sat, 22 Oct 2016 14:19:07 GMT",
"AcceptRanges": "bytes",
"Metadata": {},
"ContentType": "binary/octet-stream",
"ETag": "\"96995b58d4cbf6aaa9041b4f00c7f6ae\"",
"ContentLength": 8388608
}
$ md5sum ~/test8M
96995b58d4cbf6aaa9041b4f00c7f6ae
|
今度はEtagとMD5が一致しています。Multipartでアップロードされなかったからですね。
解決策
s3api put-objectコマンドを使います。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| $ aws s3api put-object --bucket gside-test --key test9M --body ~/test9M
{
"ETag": "\"b82b4ab87e44976024abc14a1670dac0\""
}
$ aws s3api head-object --bucket gside-test --key test9M
{
"AcceptRanges": "bytes",
"ContentLength": 9437184,
"Metadata": {},
"ContentType": "binary/octet-stream",
"ETag": "\"b82b4ab87e44976024abc14a1670dac0\"",
"LastModified": "Sat, 22 Oct 2016 14:36:02 GMT"
}
|
今度はEtagとMD5が一致しています。
最後に
MD5とETAGを比較して、同一性を検証しているようなスクリプトを書いててハマりました。
AWSコンソールからアップロードした場合は64Mを超える辺りから、Multipart Uploadになるようです。
気をつけましょう。
先日入門したTerraform、Route53のURL監視も入れてみました。
ポイントとしては、Route53のCloudWatchアラームはN.Virginiaのリージョンで作る必要がある点です。
それ以外のリージョンは現在はサポートされていません。
Route53のヘルスチェックを作成する
Route53のヘルスチェックを作成します。
1
2
3
4
5
6
7
8
9
10
11
12
| resource "aws_route53_health_check" "gside" {
fqdn = "gside.org"
port = 80
type = "HTTP"
resource_path = "/blowg/b"
failure_threshold = "3"
request_interval = "30"
tags = {
Name = "gside"
}
}
|
Cloudwatchアラームを作成する
前述したように、N.VirginiaのリージョンにClouwdWatchアラームを作成します。
dimensionsには先程作成したRoute53のヘルスチェックのIDを指定します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| provider "aws" {
region = "us-east-1"
alias = "virginia"
}
resource "aws_cloudwatch_metric_alarm" "gside-healthcheck" {
provider = "aws.virginia"
alarm_name = "gside-healthcheck"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = "1"
metric_name = "HealthCheckStatus"
namespace = "AWS/Route53"
period = "60"
statistic = "Minimum"
threshold = "1"
alarm_description = "This metric monitor gside url healthcheck"
dimensions {
HealthCheckId="${aws_route53_health_check.gside.id}"
}
alarm_actions = ["arn:aws:sns:xxxxxxx"]
}
|
まとめ
ClouwdWatchアラームをN.Virgnia以外で作成して、なかなかRoute53ヘルスチェックと関連づかずハマりましたが、
それ以外は問題なく作成できる内容でした。
ちなみにアラート時のEmail送信用SNSを作るところもTerraform化しようとしましたが、
Emailは送信者認証が入るところがTerraformのモデルに合わず未サポートだそうです。
AWSソリューションアーキテクト プロフェッショナルに合格しました！
これで今あるAWS試験で残すはDevOps プロフェッショナルのみとなりました。
AWSの経験値
ここ1年間くらいはAWSでインフラ運用・構築したり、アプリケーション基盤作ったり。
オンプレのインフラの構築・運用経験もあるけど、AWSとのハイブリット環境とかではないです。
勉強方法
Linux Academy っていうオンラインの対策コースを淡々とやりました。
動画とハンズオンで勉強をしていくサイトです。
英語なんで辛い部分もありますが、そこまで難しい英語じゃないと感じました。
動画で使ったスライドはダウンロードできるので、聞き取れなかったところも後でじっくり読めます。
あとは練習問題があるので、それをAnkiにほりこんで通勤時間に見てました。
練習問題は、不正解の選択肢の何がおかしいか、もしくは正解の選択肢と比較してどの点が劣っているかをを突っ込めるようになるまで勉強しました。
実際の試験で似たような問題もでましたが、問題丸暗記で通るほどゆるい試験ではないです。
また、会社がこの試験の推奨セミナー「Architecting on AWS – Advanced Concepts」を受講させてくれたのもでかかったです。
使ったことのなかったKinesisとかDirectConnectあたりのサービスの理解が進んだのがよかったです。
あれはいいセミナーでした。
勉強期間
2016年8月にシステムオペレーション（SysOps）アドミニストレーター – アソシエイト試験に合格してからすぐに勉強を始めたので、
期間としては2ヶ月ほど。
勉強時間はちゃんと測ってないけど、60時間くらいかな。
模擬試験
1週間前にうけた模試は、それなりに自信があったのに 33%で不合格。
点数が悪かった言い訳としては日本語が微妙でしたっていう所なんですが、
実際理解が甘いところもあったので、模擬試験の問題をじっくり、淡々と復習しました。
最後に
本番は結局75%で合格。
大体の問題は自分の中でロジックを組み立てて選択していけました。
あまり資格試験自体好きじゃないんですが、AWS試験はこれまで受験してきて実務にそれなりに役に立ってます。
少し休んでDevOpsプロフェッショナルにも挑戦していこうと思います。
