楽しみにしているテック系Podcastまとめ

未再生エピソードがもうありません。

半年以内に配信があった中で、配信を楽しみにしているPodcastをいくつかリストアップしてみます。

目的は「もっとエピソード配信が増える」「もっとテック系Podcastが増える」です。

Rebuild.fm

http://rebuild.fm/

最近のテック系Podcastブームの先駆け。

テック系を通り越して既に別次元のエンターテイメントになっている。

なんでこんなに面白いのかわかりません。でも面白いんです。

mozaic.fm

http://mozaic.fm/

Web技術。毎回濃くて勉強になります。

そのWeb技術をよく知らなかったらmozaic.fmその技術のエピソードを聞いてテンションを上げる方法をとったりします。

最近配信が止まっていますが、まだ凄いWeb技術がでてきたら配信されそうです。

engineer meeting podcast

http://engineer-meeting.tumblr.com/

エンジニアの人たちの話。ゆるい。リアルなエンジニアの人たちの話っぽい話の流れが好きです。

もう3年続いているらしいです。老舗なほうですかね。

「こんばんわ。エンジニアミーティングPodcastでーす。」の入りがクセになっています。

「プロジェクト開発カードゲームを作ろう」のコーナーは是非聞いてみて欲しいです。プレイしたくなります。

のぼりーさんのクラウドインフラPodcast

https://cloudinfra.audio/

クラウド系Podcast。自分の仕事の守備範囲と近い話なのでいつも興味深く聞いています。

Rebuild.fmと並んで、奥さんとドライブ中に聞くことがあるPodcastです。

Frontend Lunch

https://soundcloud.com/hatena-frontend

はてなのフロントエンドのエンジニアの人たちの技術ばかりのPostcast。レベルの高いエンジニアの人たちの話題ってこんな感じなのかなーと思っています。

最近、JSer.infoの話題からはじまるのですが、フロントエンドについていけていない自分としては「あーそういうところに興味を持つのか」と勉強になります。

PHPの現場

http://php-genba.shin1x1.com/

まさにPHPの現場。最も「あーあるある！」ってなるPodcast。あと耳が痛い。「もっと頑張らないと」と思ってしまいます。

boot.fm

https://bootfm.github.io/

話題の範囲や割合がすごく好みなPodcast。

最近更新がないのがちょっと寂しいです。

genba.fm

https://genba.fm/

最近はじまったJavaScriptの現場のPodcast。

らしいですが、フロントエンドに弱い自分にはレベルが高いのかまだ現場感が感じられない感じです。

mosaic.fmとは別の感じで濃くて「次のエピソードはなんだろう？」と楽しみです。

Vue.jsにも興味を持ちました。

以上です。

技術の話が多くて、アニメなど趣味の話題が少ない（もしくは知らない人のために都度噛み砕いている）Podcastが多い気がします。

技術の話は（当然）勉強になりますし、それ以外でも、聞いている間だけでも話題についていけているフリができるようなエピソードが好きみたいです。

オススメがありましたら教えて下さい。

最近のCertman活動またはCHANGELOG

AWS Ruby

日本だけでなく海外の方にも（どこで見つけたんだ？）使って頂いていて、ACMやDNSにおける知識を教えてもらいつつ修正を繰り返してとりあえず一段落した感じです。

前回 からのアップデートをCHANGELOG代わりに記録しておきます。

--remain-resources オプションを追加した

github.com

証明書の自動更新の条件に当てはまらないときのための対応です。

ACMを取得するために利用したRoute53/SES/S3の設定を残しておくというものです。

実はこの条件についてリクエストをもらうまで知りませんでした。ありがたいです。

これをきっかけにできるだけ将来にわたってリソースを残しても問題がなくなるように、 v0.7.0までにわたっていろいろ改修を加えました。

各リージョンでACMを発行しても問題がないようにした

当初はRoute53でも使える証明書が発行できる us-east-1 固定でした。

リクエストをもらって各リージョンでも使えるようにしました。

github.com

その際に不可解な現象に悩まされ（あるリージョンではうまくいくけどあるリージョンではうまくいかない）、 muranushi さんにかなり付き合ってもらいながら改善できました。

ちなみに不可解な現象というのはS3のバケット名のバリデーションがリージョンごとに違ったというものでした。

ワイルドカード指定のドメインや www. なドメインに対応した

やっぱり要望がありました。Pull Requestまでいただきました。

まあ、そうですよねー。

認証用メール用のドメイン（MXレコードの配置）についていろいろなパターンに対応した

認証メールを受け取る方法がいろいろあるので（これもあまり知らなかったです）、いろいろとアドバイスをもらいながら修正をしました。

S3/SESのリージョンをCertman側で指定するようにした

SESは全てのリージョンにはないので、SESがないリージョンでACMの証明書を作成する場合SESは別のリージョンになります。

最初は「別のリージョンにする必要があれば」us-east-1にするような実装だったのですが、これを「ドメイン名をハッシュ関数に渡して、Certman側でSES/S3のリージョンを指定する」ようにしました。

これはCertmenを作成する際に、Certman側でSES/S3のリージョンを知る方法が必要だったのと、リージョンが分散されているほうが有効だと判断したためです。

SESのReceipt Ruleを作成する際に、既存のActive Receipt Rule Setに追加するようにした

SESのActive Receipt Rule Setは各リージョンで1つしか設定できません。当初は新しいReceipt Rule Setを作成してそれに切り替えてACMの認証メールを受け取っていました（終わったら既存のReceipt Rule Setに戻す）。

しかし、これだと認証メールを受け取っている間、既存のReceipt Rule SetにあったRecipt Ruleが動かないという問題あります。

さらに、 --remain-resources を指定してリソースを残してしまうと既存のReceipt Rule Setが適用されないままになります。

なので、v0.7.0からCertman用Receipt Ruleは既存のActive Receipt Rule Setに追加するように修正しました。

認証メールの再送に対応した

github.com

CertmanではACMの認証に必要なリソースを一気に作るので、ときどき認証メールを受け取れないタイミングがあります。 なので、ACMの認証メールを一定間隔で再送するようにしました。

今後対応したいこと

  • 最初のpromtをスキップできようにする（-y オプション)
  • 既存のACM証明書の認証メール取得用AWSリソースを後から作成できるようにする ( コマンド名決まっていない )
  • 証明書のインポートに対応する ( import コマンド )
  • 証明書のステータスを取得する ( status コマンド )

Certmen (ACMの証明書全てを管理する何か) が必要かどうかはいろんな人からフィードバック貰いたいところですね。

ACMの証明書取得方法を忘れたい人は是非利用してみてください。

Infrastructure as Code 第I部読了。Infrastructure as Codeとそれを構成する要素を俯瞰できる第I部でした

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

やっと、Infrastructure as Codeの第I部を読み終わることができました。 （なかなかまとまった時間がとれなくて、何度も読み戻ってしまいました）

Infrastructure as Codeといえば、

ちょうどnobolycloudでもmizzyさんがゲストで、Infrastructure as Codeの見どころを紹介していましたね。

cloudinfra.audio

自分が言いたいことはタイトルで書いてしまったのですが、以下長々と感想です。

第I部

Infrastruture as Codeはクラウド時代に仕事を終わらせなければならないエンジニアのためのもの

「仕事を終わらせなければならない」が個人的パワーワードでした。

確かになーと。

ここ数年で自分の中でAnsibleやCapistrano、TerraformやServerspecがあたり前になっていて、それらを当然として開発をしています。

先日もRoute53で管理されている複数のドメインの設定変更を行いました。

その時もRoadworkerやPiculet、そして少しのRubyスクリプトを駆使することで事前の検証や一括設定変更ができて、心理的負担少なく対応ができました（今度どこかで書きます）。

もし、Infrastructure as Codeがなかったとしたら

「もし、Infrastructure as CodeやCodenizeの考え方がなかったとしたら、、、？」というのは、今となっては考えられません。

自分は、社内では少なくなった「CDでOSをインストールしたことがある」「データセンターにラックサーバを設置したことがある」世代です。

しかし、当時のインフラ運用の仕方を今もしていたら到底仕事は回らないと思います。

むしろ、「さらにInfrastructure as Code / Codenizeを進めていかないと会社として競争力を失い遅れていくのでは？」という不安も強く感じます。

例えば1章では、そういった不安の原因を「課題」として名前を付けてわかりやすく説明してくれています。

「スノーフレーク」や「オートメーション恐怖症」など、あるある過ぎます（何を意味するのかは是非本書を読んでみて欲しいです）。

それらの課題についてどのようなアプローチで解決するべきなのかを俯瞰的に紹介してくれます。そしてそれらを原則と呼んでいます。

IaCに興味があるエンジニアだけでなく、IaCの導入が進まないエンジニアにも是非読んで欲しいです。

「へー、Infrastructure as Codeってこういう課題から生まれているのか。うちに必要かな」

「Infrastructure as Codeの原則に沿っているかな？」

と読むのに良い章だと思います。

この章だけ読むのも十分価値があります。

インフラがプログラマブルになったからInfrastructure as Codeが定着したという側面

Infrastructure as Codeは全てのインフラに十分な形で適用できるわけではありません。

Infrastructure as Codeの発展の裏にはインフラの進化があって、その進化したインフラにInfrastructure as Codeがマッチするというのです。

2章や5章はそういった「Infrastructure as Codeと相性の良いインフラの条件」について紹介しています。

自分はAWSを良く使うのですが、AWSはまさに本章で紹介する「ダイナミックインフラストラクチャプラットフォーム」です。

操作のほとんどがAPI経由で実現できますし、サービスのリリースのタイミングでAPIやSDKがリリースされることもあります。

そんなAWSが「Infrastructure as Codeと相性が良い」というのは感覚ではわかっていました。

本書では「Infrastructure as Codeと相性の良いインフラの条件」をしっかりと説明しています。

読むと逆にそれらの条件を満たしているAWSやその他のクラウドサービスの凄さを改めて感じます。

良い時代。

受け身かオートメーションか

「サーバを追加したら、サーバ管理システムに登録してください」

正直、これが本当に面倒です。

「脆弱性が報告されたので、各自管理しているサーバを確認してください」

必要なのはわかっていますが、これも面倒です。

この課題をいつか解決をしたいと思っています。（実は受託開発会社ならではの悩ましいところもあるのですが、解決はしたいのです。）

今ならVulsがありますし、komaも作ったりしました。なんかできそうな気がしています。

そういった意味で3章のCMDBについての話はうなずきっぱなしでした。

（CMDBの話も是非本書を読んでみてください。）

サーバ構成ツールからコンテナの世界

4章は「Infrastructure as Code」と聞いて個人的に真っ先に想像するサーバ構成ツールの話です。

やはりコンテナに章の大部分を割いており、コンテナの利点やセキュリティの考え方などがわかりやすく説明されています。

イミュータブルな世界には憧れます。

第II部が楽しみ

第I部は、Infrastructure as Codeの基礎でした。

それを踏まえて第II部はさまざまなパターンについて書かれているそうです。

nobolycloudでも好印象な箇所なので非常に楽しみです。

最後に

mizzyさん、ご恵投いただきありがとうございました！

まだ時間はかかりそうですが、じっくり読んでいきます！

AWS Certificate Manager (ACM) のSSL証明書をAWSマネージドサービスを駆使して自動取得するクライアント Certman を作った #fukuokarb

AWS Ruby

ACMのSSL証明書取得が本当に毎回面倒だしすぐ忘れるので、いつもの自分の取得方法をCLIツールにしました。

github.com

前提

SSL証明書が必要なドメインを同一アカウント内のRoute53で管理している必要があります。

インストール

$ gem install certman

使い方

例えば、blog.example.com のSSL証明書を取得したいときは certman request blog.example.com を実行します。

最初にいくつかの注意事項に答えるとCertmanがAWSマネージドサービスを駆使してSSL証明書を取得します。

$ certman request blog.example.com
NOTICE! Certman support *us-east-1* only, now. OK? Yes
NOTICE! When requesting, Certman replace Active Receipt Rule Set. OK? Yes
[✔] [ACM] Check Certificate (successfull)
[✔] [Route53] Check Hosted Zone (successfull)
[✔] [Route53] Check TXT Record (successfull)
[✔] [Route53] Check MX Record (successfull)
[✔] [S3] Create Bucket for SES inbound (successfull)
[✔] [SES] Create Domain Identity (successfull)
[✔] [Route53] Add TXT Record Set to verify Domain Identity (successfull)
[✔] [SES] Check Domain Identity Status *verified* (successfull)
[✔] [Route53] Add MX Record Set (successfull)
[✔] [SES] Create Receipt Rule (successfull)
[✔] [ACM] Request Certificate (successfull)
[✔] [S3] Check approval mail (will take about 30 min) (successfull)
[✔] [SES] Remove Receipt rule (successfull)
[✔] [Route53] Remove Record Set (successfull)
[✔] [SES] Remove Verified Domain Identiry (successfull)
[✔] [S3] Delete Bucket (successfull)
Done.

certificate_arn: arn:aws:acm:us-east-1:0123456789:certificate/123abcd4-5e67-8f90-123a-4567bc89d01

完了までに約30分かかりますが、マネジメントコンソールでポチポチやるよりずっとマシです。

証明書を削除したいときは certman delete コマンドを実行します

$ certman delete blog.example.com
[✔] [ACM] Delete Certificate (successfull)
Done.

途中で失敗したときのRollbackをもう少しサポートしたいと思いますが、普通に使えるのではないかと思います。

ワイルドカードドメインはまだテストしていません。

というわけで

ACMの取得方法を忘れようと思います。

Ansible徹底入門は"今"のAnsibleの使い方を教えてくれる再入門書籍

Ansible

Ansible徹底入門 クラウド時代の新しい構成管理の実現

Ansible徹底入門 クラウド時代の新しい構成管理の実現

「Ansible徹底入門 クラウド時代の新しい構成管理の実現」を読了しました。

わたしのAnsibleスペック

とりあえず自分のスペックを。

  • 1.5か1.6から使い始めています。
  • 現在は1.9をメインに使っています。
  • ChefやPuppetはほとんど利用していません。
  • 受託開発をやっているせいか、結構な数のPlaybookを書いてきました。

“今"のAnsibleを教えてくれる

Ansible自体は知っていますし、実際に業務で使っていますが、本書を読んで感じたのは「自分の使い方は古い」ということでした。

古い書き方

私はLAMP環境がメインなのですが、次のプロジェクトに移るとき、過去のRoleを参考にします（「Roleの共有はコードが複雑になるので無理」派です）。

そのせいで書き方が古いままで、また、使い方にクセがあるのだと思います。

今の書き方

例えば、パラメータを = でつなげるのは今は推奨されない書き方だというのも本書のコラムで知りました。block~rescue 構文も使ったことがありませんでした。

もう十分に枯れたと勝手に思っていました。

しかしそんなことはありませんでした。

まさに今のAnsibleを教えてくれます。

チュートリアルとして最適

“徹底入門"というだけあって、Ansibleという構成管理ツールの必要性からしっかり教えてくれます。

1章から4章まで通読すれば、まず実践レベルで使えるようになるのではないでしょうか。5章をチュートリアル的に実施したらもう十分です。

正しくAnsibleの使い方を教えてくれるチュートリアルとして、今の時点でベストだと思います。

会社でも来年度の新人のために1冊購入しました。

次の使い方を模索できる

もともとはAnsibleは「サーバ」に対しての構成管理ツールでしたが、本書を読んでみるとどんどんその幅を広げていることがわかります。

Infrastructure as Codeの時代に、適材適所でツールを利用するのも1つですが、Ansibleに統一することを検討するというのも良いのかもしれません。

6〜8章でOpenStack、AWS、Azureのモジュールの解説やチュートリアルもあるので、本書でまず検討することができます。

特に7章のCFnとの連携、ローリングデプロイのチュートリアルは実践的といえるのではないでしょうか。

Dockerとの連携

Dockerをやっと開発環境の一部として使い始めました。

9章でAnsible Containerの使い方が紹介されています。

Ansibleを開発環境でも本番環境でも使っている自分としては、まずはDockerを開発環境でWith Ansibleで活用して、本番環境でAnsibleだけを利用するという現実的なアプローチが取れそうで期待が高まります。

個人的にはDockerfileを書かなくて生きていけそうなので嬉しいです。

テスト

10章でAnsibleのPlaybookのテスト手法が紹介されています。

個人的にはAnsibleで管理されているサーバにさらにテストを書くのは、（主にコスト面で）懐疑的です。

しかし、本書で紹介されていたのはそれではなくてPlaybook自体のテストでした。

そういえば、チマチマ育てていった結果、いざ順番に実行したらコケるようになったPlaybookがあったなあ、と思い出しました。。。

というわけで

1系のAnsibleに慣れ親しんだ人も、今からAnsibleを使ってみようという人にもオススメです。

最後に

kaz29さん、ご恵投いただきありがとうございました！

Ansibleへの再入門ができた気がします！

久しぶりにansible.elに手を入れてみるかな。。。

awspecのAPIで悩んでいる その2

AWS Ruby

現在、awspecの各リソースタイプは、リソースの特定にIDか、タグの Name を利用しているます。

しかし、「サーバはペットから家畜へ」と言われるようにAWS上のリソースに名前がつくことのほうが少なくなっているようです。

awspecでもIssueが上がっています。

github.com

awspecとしてはリソースを一意に特定してテストするコンセプトは重要だ思っているので、（そのコンセプトは変えずに）例えば “IDを特定するためのヘルパー” を提供しようと考えています。

ヘルパー名は仮ですが、ec2リソースタイプに対して ec2_filter というヘルパーを用意した場合、以下のような使い方ができるようにしたいのです。

describe ec2(ec2_filter(tags: {'TagKey' => 'TagValue'})) do
   it { sholud be_running }
end

describe ec2(tags: {'TagKey' => 'TagValue'}) do # work ec2_filter() inside
   it { sholud be_running }
end

ec2_filter(tags: {'TagKey' => 'TagValue'}).each |id|
  describe ec2(id) do
     it { sholud be_running }
  end
end

ec2_filter(asg: 'my-asg').each |id|
  describe ec2(id) do
     it { sholud be_running }
  end
end

何に悩んでいるのか

ヘルパーの命名規則（名前）です。

  • おそらく各リソースに対して専用のリソースが必要
  • finder という名前は既に利用
  • 1つのリソースを特定するために使ったり、複数のリソースのIDを取得するために使ったりしたい

どうしたものか。。。

holiday-jp/holiday_jpに内閣府の「国民の祝日」のCSVファイルによるテストを追加しました

日本の祝日のデータセット holiday-jp/holiday_jp に内閣府の「国民の祝日」のCSVファイルによるテストを追加しました。

Tachikoma.ioによる定期テスト も回っていますので、今後安心して内閣府が定めた国民の祝日が反映されたデータセットが活用できます。

ちなみに

機械的なアクセスについて、内閣府のホームページの利用規約に記載がなかったので、（なんとなく）念の為内閣府に確認をしたところ、（「定期的に週1回、それ以外にもテスト実行する度にアクセス」ということを伝えた上で）

「常識的な範囲であれば機械的なアクセスをしても問題ない」

と回答いただきましたので、このまま利用させていただこうと思います。