Dockerのチュートリアルを軽く触った事しかなかったのですが、本番でDockerを運用しているシステムを触ることになったので手に取りました。 しかしDockerは進化のスピードが早くてどの本を買おうか非常に迷いましたね。 この本は2016年の出版ですが、パッと見た所そこまで難しすぎず、手を動かしながらDockerを体験できそうだったのと、 迷ったらオライリーでしょっていう安易な考え方で選びました。 2年の月日はこの分野では大きな差がありそうですが、 特に進化が激しそうなオーケストレーション周りはこの本とは別に直近に出版されたものも読んで、 Dockerの進化を疑似体験しつつ知識をアップデートしていこうという目論見です。
AWS 認定 DevOps エンジニア – プロフェッショナル に合格しました！ これでAWS認定5冠達成です！
「データベース実践入門」 を読んでいて、これは論理学を学んでおかないと歯が立たないなと感じ、急遽読むことにしました。 論理学はプログラマが勉強すべき内容として、こちら でも紹介されていますね。 難しさに挫折するのは悔しい所ですが、ここは自分の知識のなさを素直に認めて急がば回れで行くことにしました。
実際に仕事でも使ってるAnsibleだけど、使い始めた頃から本書にはお世話になってます。 改めて読み返してみると、最初のハードルから様々なプロダクトとの連携や高速化など、 痒いところに手がとどく内容だなと思います。 初めてAnsibleを触る人にも良いと思います。 あまり馴染みのないPython製のCRMをベースに話が進んでいく箇所は若干難儀しましたが。
これまで、Googleの成長をリアルタイムで体験しながらネットを利用してきたわけですが、 Googleが企業し、小さな企業から大企業へとなっていく華やかな成長の裏で、 中の人は何を考え、苦悩してきたのかがわかる本です。
以前試したServerspecですが、Ansibleと連携するプロダクトがあるということで試してみました。 その名もansible_specです。 Ansibleで構成したサーバーの接続情報を共有したいというモチベーションはTestinfraと同様です。 やはり同じ接続設定をいろんなところに設定するのは避けたいところですよね。
Infrastructure as Code(IaC)もずいぶん使い古された感のあるワードですね。 出始めの頃は自分もChefとかPuppetを使いさえすればいいもんだと勘違いしていました。 実際はもっと大きな考え方であり、この本は網羅的にIaCの考え方を抑えていってくれるので、 視野狭窄にならないようにするためにも、読んでおいて損はない本だと思いました。
前回、ServerSpecを使ってインフラのテストを書いてみましたが、 同じ思想でpythonベースのプロダクトを教えてもらったので試してみました。
Testinfra aims to be a Serverspec equivalent in python 
DevOpsは最近ではバズワードでもなんでもなくて、 普通に考えなきゃいけない概念になってきました。 と言っても自分の周辺ではまだまだという感があるので、 とりあえず軽い気持ちで読んでみたのが本書です。 あまり考えずに買ったので、物語調で始まった時には少し面食らいました。
S3をEC2からマウントするgoofysを試してみた。 昔s3fsを試したことがあるんだけど、パフォーマンスが問題になったりしたことがありました。 巷では爆速と噂のgoofysですが、とりあえずパフォーマンスは置いておいて、できないことが何かを見ておきました。
昔はWebAPIを作る事が多かったんだけど、ここ数年はすっかりインフラ寄りになって、機能寄りの設計をやらなくなってました。 そんな中に読んだのが、Web API The Good Parts。 技術書の中にはかつての自分の成果物に赤面してしまう本が多々ありますが、この本は赤面度上位に位置しますね。
AnsibleでGentooの環境を作れるのかなあと思ったら、モジュールが提供されていました。 Apacheをインストールしてデフォルトランレベルに登録するところまでやってみました。
S3のバージョニングの機能は知っていたのですが、 古いバージョンをリストアする方法をちゃんと調べていませんでした。
バックアップとっててリストアできないなんて、最低ですね。
GentooをAWS上で動かすために、イメージを作ってみました。 クラウドに使えるstage4ファイルを利用すれば、簡単にできてしまいます。
追加ボリュームにgentooをインストール後、snapshot作成、AMI作成という手順でいきました。
独自のAMIを作ってたら、どうもうまく行かず。Try and Errorの様相を呈してきた。 何度もSnapshot作ってAMIを作ってLaunchってやり始めたので、Terraformでこの辺をやるようにした。
ただ、EBSボリュームからSnapshotを作る部分は見つけられなかったので、Snapshotを作るところは手動です。
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について記載しています。 サイズとマウントポイントを記載するだけ。 簡単なんだけどやはりインスタンス作りなおしなのは惜しいですね。
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"
}
} インスタンスにログインしてディスクの状況を確認します。
[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では鍵のインポートのみサポートしています。 確かに秘密鍵をダウンロードするより、公開鍵をアップロードするほうが健全ですね。
仕事では利用しているAnsible。 プライベートで使っているサーバーも、構成管理することにしました。 まずは初期構築の部分をまとめてみました。
MD5でファイルが同じかどうかを判定することがあります。 S3ではETAGにMD5値が格納されているという事になっていますが、 結論から言うと、Multipart Updateされた場合と、そうでない場合で異なります。
先日入門したTerraform、Route53のURL監視も入れてみました。 ポイントとしては、Route53のCloudWatchアラームはN.Virginiaのリージョンで作る必要がある点です。 それ以外のリージョンは現在はサポートされていません。
AWSソリューションアーキテクト プロフェッショナルに合格しました！ これで今あるAWS試験で残すはDevOps プロフェッショナルのみとなりました。
まずはこのBlogをホストしている環境をTerrraorrm化してみました。 いまだにClassic EC2を使ってたので、そろそろ再構築したかったんですよね。
USBカードリーダーにSDカードを刺すたびに、mountコマンドを打つのが億劫なので、 udevでAuto Mountするように設定してみました。
他のディストリビューションなら、そういうところまで整備されてるんでしょうけど、 未整備が故に色々調べれるのもGentooのいいところですね。
udevは "userspace device management" の略で、kernelが検出したデバイスに対してデバイスファイルを割り当てる仕組みです。 /sys/classを検索してdevファイルを探し、/devに対応するデバイスファイルを生成します。
私の環境では下記のudev関連のdaemonが動いていました。
root 2120 1 0 15:33 ? 00:00:00 /usr/lib/systemd/systemd-udevd --daemon このdaemonはデバイスが追加されたり取り除かれたりした際のイベント、ueventをkernelから直接受け取ります。 この様子はudevadmコマンドで見ることができます。
# kernelとudevイベントをモニター
$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[152621.041326] change /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2.4/3-2.4:1.0/host7/target7:0:0/7:0:0:0/block/sdc (block)
KERNEL[152621.055301] change /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2.4/3-2.4:1.0/host7/target7:0:0/7:0:0:0/block/sdc (block)
KERNEL[152621.065291] change /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2.4/3-2.4:1.0/host7/target7:0:0/7:0:0:0/block/sdc (block)
UDEV [152621.900706] change /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2.4/3-2.4:1.0/host7/target7:0:0/7:0:0:0/block/sdc (block)
UDEV [152621.913050] change /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2.4/3-2.4:1.0/host7/target7:0:0/7:0:0:0/block/sdc (block)
UDEV [152621.924742] change /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2.4/3-2.4:1.0/host7/target7:0:0/7:0:0:0/block/sdc (block)
KERNEL[152626.399018] change /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2.4/3-2.4:1.0/host7/target7:0:0/7:0:0:0/block/sdc (block)
UDEV [152626.429341] change /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2.4/3-2.4:1.0/host7/target7:0:0/7:0:0:0/block/sdc (block) さて、SDカードを挿すと /dev/sdc1 にデバイスファイルが作成されました。 /dev/sdc1の情報を udevadmで調査します。
# USBをさして/dev/sdc1にマッピングされた時、/dev/sdc1の情報を取得する
sudo udevadm info --query=all --name=/dev/sdc1
.
.
.
E: ID_PATH=pci-0000:00:12.0-usb-0:2.4:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_12_0-usb-0_2_4_1_0-scsi-0_0_0_0
E: ID_REVISION=1.00
E: ID_SERIAL=Multiple_Card_Reader_058F63666438-0:0
E: ID_SERIAL_SHORT=058F63666438
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Multiple
E: ID_VENDOR_ENC=Multiple
E: ID_VENDOR_ID=058f
E: MAJOR=8
E: MINOR=33
E: SUBSYSTEM=block
E: USEC_INITIALIZED=218061 ルールファイルを作成します。/etc/udev/rules.d/99-local.rulesです。
# start at sdb to ignore the system hard drive
KERNEL!="sd[c-z][1-9]", GOTO="exit"
# flash card
ENV{ID_VENDOR_ID}=="058f", GOTO="mount"
# USB Storage
ENV{ID_VENDOR_ID}=="13fe", GOTO="mount"
LABEL="mount"
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
ENV{ID_FS_LABEL}=="", ENV{dir_name}="flash_drive_%k"
ACTION=="add", RUN+="/bin/mkdir -p '/media/%E{dir_name}'"
# filesystem-specific mount options (777/666 dir/file perms for vfat)
ACTION=="add",ENV{mount_options_vfat}="gid=100,dmask=000,fmask=111,utf8,flush,rw,noatime,users"
# mount device
ACTION=="add", ENV{ID_FS_TYPE}=="vfat", RUN+="/bin/mount -t auto -o %E{mount_options_vfat} /dev/%k '/media/%E{dir_name}'"
# exit
LABEL="exit 作ったルールをテストしてみます。
# ルールをテストする
udevadm test $(udevadm info -q path -n /dev/sdc1)
.
.
.
ID_VENDOR=Multiple
ID_VENDOR_ENC=Multiple
ID_VENDOR_ID=058f
MAJOR=8
MINOR=33
SUBSYSTEM=block
USEC_INITIALIZED=218061
dir_name=Eye-Fi
mount_options_vfat=gid=100,dmask=000,fmask=111,utf8,flush,rw,noatime,users
run: '/bin/mkdir -p '/media/Eye-Fi''
run: '/bin/mount -t auto -o gid=100,dmask=000,fmask=111,utf8,flush,rw,noatime,users /dev/sdc1 '/media/Eye-Fi''
unload module index
Unloaded link configuration context. /media/Eye-Fi にmountされました。