無理をすると必ず返ってくる。チームの負債になってしまう。RoadworkerRoadworkerを使うことで、Route53のDNSレコードをDSLとして管理する事が出来る。詳しい使い方はREADME.mdを見てもらうのが吉だ。AWSの1アカウントで1サービスを運用している事を想定すると、Route53で複数のドメインを関している事が多いと思う。--with-soa-nsを指定した。zone毎にファイル出力を行う。--with-soa-nsはSOAレコードとNSレコードも出力するもので、デフォルトではSOAレコードとNSレコードは出力されない為、SOAレコードとNSレコードが必要な場合は意識が必要だ。checkのregion指定は出力されなかった。checkのregion指定を行った。GitHubGitHubにPrivateリポジトリでソース管理を行った。各種権限はチームに合わせた設定が必要だと思う。Requestのmergeで本番にapplyする。それが我々のチームの戦略とした為だ。AWSRoute53へアクセスするAWSユーザーが必要で、DNSレコードの追加だけでなくレコードの削除も行うためRoute53へのフルアクセス権限を付与したユーザを用意した。CircleCIのVersionは1.0を使っている。その為、roadworkerを使うために一工夫が必要となった。libpq-devとして必要な環境を用意するのだ。'roadworker'としてroadworkerを使う。circle.ymlは記述方法が柔軟だが、シンプルな記述となる点も気に入っている。以下にサンプルを載せておく。zoneに適用される。zoneに適用しても良い。いった戦略を選択するのか考える事が重要だ。それが最適化なのだから。見えてきた、次にやるべきこと実際の運用は良くある話になる。修正をmasterに加えpushする。Requestを作成出来る。zoneが切り替わる。成功の結果をSlackへ流す。これで、Route53の変更履歴も残すことが出来るし、複数人によるreviewが行える。反映自体もmergeするだけなので手間が掛からない。これで、見える化と属人化の排除が行えた。この運用を始めて分かった事は、当たり前過ぎてこの構想を考えている最中には思いつかなかった事だ。それはRoute53のお作法を理解する必要があるという事だ。通常のDNSサーバに+αで便利な機能が使えるRoute53だが、果たしてその機能や使い方を全て理解出来ているだろうか?テストをpassしなかった際に出力される例外をすぐに理解出来るだろうか?AWSのGUI上に表示されるヘルプがない状態で、それくらいroadworkerを使いこなせるだろうか?きっとこの例外をクリアする為に、AWSの知見があるエンジニアに頼る事になるだろう。我々は誰かに頼るのではなく、チームで解決しなくてはいけない。当たり前になってしまった事は、常に忘れてしまう。人間がエンジニアリングをしている以上、つきまとう問題かもしれない。それでも次の課題がある事は素晴らしい。次の進歩に向けて学ぶことが出来る。して我々は機械化の波に飲まれていくのである。我々のチームに必要なのは「脱機械化」なのかもしれない。