Scalaは昔少し勉強して挫折した経験があります。月並みにいえば、その時こういう本があったらなぁという感想です。
そもそも会社でのポジションはSREなので、Scalaを実務で書くことはほとんどありません。Pythonは書くシチュエーションがありますが、関数型を多用することもありませんでした。
本書の読了が見えてきた頃からこの本を片手にScalaでCodility の問題を解く会社内の集まりに参加させてもらっています。Atcoder にも参加するようになりScalaプログラミングを楽しんでいます。
Terraformのリファクタリング楽しいですね。ついついいろんなハードコードを変数化するのに熱中してしまいます。
AWSをTerraformで構築・運用するときAWSのアカウントIDが必要になることがあります。 特にVPC Peering、Private Link, SNS, S3のBucket Policyなど、クロスアカウントで利用できるリソースなどは別アカウントのIDが欲しくなる事があります。 一つならまだしも2つ以上アカウントIDと連携したりすると混乱するので、ここにハードコードしたIDではなくわかりやすい変数名、しかもリモートステートで別アカウントのIDが参照できれば良いなと思いました。
自アカウントであれば、aws_caller_identityを利用すれば簡単に取得することができます。
data "aws_caller_identity" "self" { } どこかに上記のような記述をすると、下記のような形でアカウントIDを参照できます。
"${data.aws_caller_identity.self.account_id}" これにリモートステートの仕組みをプラスすることで、別アカウントのIDを変数化できました。 参照される側のアカウントをA, 参照する側のアカウントをBとしています。
最近はDockerの環境を運用することが多いので、すっかりEC2に対してAnsibleで環境を構築したりメンテナンスしたりすることが減りました。 それでもAWS上のECSをEC2ベースで運用していて、EC2に監視用のエージェントなどをインストールしているケースなどもあると思います。 例えば自分の場合だとPrometheusの監視モジュール、node exporterを各EC2にインストールしています。
今後もECS OptimizedなEC2はどんどん更新されていくので、これを機にPackerを導入してベースイメージの作成をすることにしました。 ちなみにPackerを導入しようと思ったのは先日発表されたDockerの脆弱性対応のためEC2をアップデートしないといけなかったことがきっかけです。
というわけでPackerは初めて触ったわけですが、ほとんどはまることもなくAnsibleをプロビジョナーとする構成を作ることができました。 それでも何点かつまずいた点があったので、残しておきます。
環境は下記の通りです。
バックアップは取っていてもリストアできないと宝の持ち腐れですね。
ibdataのコールドバックアップは取っていて、サクッと一部のテーブルのデータのみリストアする方法です。 稼働中のMySQLを止める必要がないので、一部のテーブルだけ復旧したい場合や、とりあえず昔のテーブルの状況を見たい場合などに利用可能です。 データベース全体のリストアではないので、リストアの時間を短縮したいときに使えるかと思います。
やり方としては公式のドキュメントに書いてある通りなのですが、もうちょっと細かくやり方を見ていきます。 innodb_file_per_tableがONになっていて、テーブル毎にibdataが作成されていることが前提になります。
大まかな手順は下記のようになります。
下記のバージョンで検証しました。
OreillyのDocker本に続いて読んだのが、現時点では比較的最近出版された本書でした。 出来るだけ新しいDocker本で最近の情報で知識をアップデートしたかったのと、Kubernetesの説明が充実してそうというのが本書を手に取った動機です。 Dockerに正式採用されたKubernetesと、Swarmの違いなんかも体験できればなと思いました。
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。 プライベートで使っているサーバーも、構成管理することにしました。 まずは初期構築の部分をまとめてみました。