kakakakakku blog

Weekly Tech Blog: Keep on Learning!

Amazon Elasticsearch Service で「手動スナップショット」を取得する

自動スナップショットと手動スナップショット

Amazon Elasticsearch Service でクラスタのスナップショットを取得する場合,「自動スナップショット」と「手動スナップショット」の2種類がある.

AWS 側で自動的に日次取得してくれるものを「自動スナップショット」と呼ぶ.14世代保管される.ただし「自動スナップショット」のリストアは自分たちではできず,AWS サポートに依頼して実施してもらう必要がある.よって,リストアのタイミングが AWS サポート側に依存することになり,運用的には自由度が低いものとなる.

逆に「手動スナップショット」は,Elasticsearch 自体のスナップショット機能を使って,任意のタイミングでスナップショットの取得とリストアができるため,自由度が高いものとなる.また EC2 上で運用している Elasticsearch クラスタのスナップショットを取得して,Amazon Elasticsearch Service にリストアすることで,移行としても使える.

詳しくはドキュメントに記載されているが,日本語訳が変で「スナップショットを取る」と「スナップショットを取得する」と訳すべきところが「スナップショットを撮る」と「スナップショットを撮影する」になっていて,どうしても読みながら気になってしまった.フィードバックしたら修正してもらえるのかな?

docs.aws.amazon.com

www.elastic.co

手動スナップショットを試してみた

最近 Amazon Elasticsearch Service で運用しているクラスタが落ちたことがあって,AWS サポートに依頼して「自動スナップショット」からのリストアをお願いした.そのときに「手動スナップショットはしてますか?」や「手動スナップショットがあるとリストアも素早くできますよ」的なコミュニケーションがあって,AWS 的にも自由度が高い「手動スナップショット」を推奨しているのかなという雰囲気を感じて,一度試してみようと思った.

前提

  • Amazon Elasticsearch Service ドメイン(クラスタ)が構築済であること
  • エンドポイントは全て ${amazon_es_endpoint} で記載している

事前準備(ドキュメントを登録する)

事前にサンプルドキュメントを1件登録する.

$ curl -s -XPUT ${amazon_es_endpoint}/blog/articles/1 -d '
quote> {
quote>   "title": "xxx",
quote>   "body": "yyy",
quote>   "tags": ["z1", "z2"]
quote> }
quote> '
{"_index":"blog","_type":"articles","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}%

$ curl -s ${amazon_es_endpoint}/blog/articles/1 | jq .
{
  "_index": "blog",
  "_type": "articles",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "title": "xxx",
    "body": "yyy",
    "tags": [
      "z1",
      "z2"
    ]
  }
}

IAM 設定をする

スナップショットを S3 に保存するため,IAM で少し複雑な設定をする必要がある.詳しくは上に載せたドキュメントに書いてあるので,ここでは箇条書きに留めておく.

  • スナップショットを保存する S3 に対するアクセス許可をした IAM ポリシーを作成する
  • ロールタイプを EC2 にした IAM ロールを作成し,Amazon Elasticsearch Service に対する権限と作成した IAM ポリシーをアタッチする

リポジトリ登録をする

Amazon Elasticsearch Service で手動スナップショットを取得する場合,S3 に保存することになるが,事前に S3 をスナップショットのリポジトリとして登録する必要がある.さらに登録するときに AWS のリクエスト署名が必要になるため,curl から API を叩くことができず,SDK を経由する必要がある.今回はドキュメントに書いてある Python (boto) のサンプルコードを使った.これは面倒すぎる...!

実際に実行するときは以下の項目を書き換える必要がある.

  • region
  • host
  • aws_access_key_id
  • aws_secret_access_key
  • path
  • bucket
  • role_arn
from boto.connection import AWSAuthConnection

class ESConnection(AWSAuthConnection):

    def __init__(self, region, **kwargs):
        super(ESConnection, self).__init__(**kwargs)
        self._set_auth_region_name(region)
        self._set_auth_service_name("es")

    def _required_auth_capability(self):
        return ['hmac-v4']

if __name__ == "__main__":

    client = ESConnection(
            region='us-east-1',
            host='search-weblogs-etrt4mbbu254nsfupy6oiytuz4.us-east-1.es.a9.com',
            aws_access_key_id='my-access-key-id',
            aws_secret_access_key='my-access-key', is_secure=False)

    print 'Registering Snapshot Repository'
    resp = client.make_request(method='POST',
            path='/_snapshot/weblogs-index-backups',
            data='{"type": "s3","settings": { "bucket": "es-index-backups","region": "us-east-1","role_arn": "arn:aws:iam::123456789012:role/MyElasticsearchRole"}}')
    body = resp.read()
    print body

実行したところ,以下のような結果が返ってきた.

$ python snapshot.py
Registering Snapshot Repository
{"acknowledged":true}

手動スナップショットを取得する

これで,やっと準備が整ったので,手動スナップショットの取得ができる.取得自体は簡単で,以下の API をコールする.今回は2回スナップショットを取得してみた.

$ curl -XPUT ${amazon_es_endpoint}/_snapshot/backups/snapshot_1
{"accepted":true}%

$ curl -XPUT ${amazon_es_endpoint}/_snapshot/backups/snapshot_2
{"accepted":true}%

取得後にスナップショットの一覧を確認することもできる.

$ curl -s ${amazon_es_endpoint}/_snapshot/backups/_all | jq .
{
  "snapshots": [
    {
      "snapshot": "snapshot_1",
      "version_id": 2030299,
      "version": "2.3.2",
      "indices": [
        "blog"
      ],
      "state": "SUCCESS",
      "start_time": "2016-12-17T08:03:25.067Z",
      "start_time_in_millis": 1481961805067,
      "end_time": "2016-12-17T08:03:26.174Z",
      "end_time_in_millis": 1481961806174,
      "duration_in_millis": 1107,
      "failures": [],
      "shards": {
        "total": 1,
        "failed": 0,
        "successful": 1
      }
    },
    {
      "snapshot": "snapshot_2",
      "version_id": 2030299,
      "version": "2.3.2",
      "indices": [
        "blog"
      ],
      "state": "SUCCESS",
      "start_time": "2016-12-17T08:07:18.741Z",
      "start_time_in_millis": 1481962038741,
      "end_time": "2016-12-17T08:07:19.207Z",
      "end_time_in_millis": 1481962039207,
      "duration_in_millis": 466,
      "failures": [],
      "shards": {
        "total": 1,
        "failed": 0,
        "successful": 1
      }
    }
  ]
}

S3 でもスナップショットが取得されていることを確認できた(S3 は新 UI に変更済).

f:id:kakku22:20161217180035p:plain

手動スナップショットをリストアする

次にリストアを試す.1点注意点があって,Amazon Elasticsearch Service は _close API をサポートしていないため,リストアするインデックスを事前に削除した状態でないとリストアできないという制約がある.まず最初に,インデックスが存在する状態でリストアをしてみたところ,以下のように 500 が返ってきた.

$ curl -s -XPOST ${amazon_es_endpoint}/_snapshot/backups/snapshot_1/_restore | jq .
{
  "error": {
    "root_cause": [
      {
        "type": "snapshot_restore_exception",
        "reason": "[backups:snapshot_1] cannot restore index [blog] because it's open"
      }
    ],
    "type": "snapshot_restore_exception",
    "reason": "[backups:snapshot_1] cannot restore index [blog] because it's open"
  },
  "status": 500
}

よって,インデックスを削除して,ドキュメントがクエリできないことを確認した.

$ curl -XDELETE ${amazon_es_endpoint}/_all
{"acknowledged":true}%

$ curl -s ${amazon_es_endpoint}/blog/articles/1 | jq .
{
  "error": {
    "root_cause": [
      {
        "type": "index_not_found_exception",
        "reason": "no such index",
        "resource.type": "index_expression",
        "resource.id": "blog",
        "index": "blog"
      }
    ],
    "type": "index_not_found_exception",
    "reason": "no such index",
    "resource.type": "index_expression",
    "resource.id": "blog",
    "index": "blog"
  },
  "status": 404
}

改めてリストアすると,成功して,ドキュメントもクエリできた.

$ curl -s -XPOST ${amazon_es_endpoint}/_snapshot/backups/snapshot_1/_restore | jq .
{"accepted": true}

$ curl -s ${amazon_es_endpoint}/blog/articles/1 | jq .
{
  "_index": "blog",
  "_type": "articles",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "title": "xxx",
    "body": "yyy",
    "tags": [
      "z1",
      "z2"
    ]
  }
}

まとめ

クラスタの運用を考えると Amazon Elasticsearch Service の「手動スナップショット」は重要で,今回一通りの手順を試してみた.

感想としては「面倒な部分が多いな...」という印象で,管理コンソールと API 経由でもっと簡単にスナップショットを管理したいし,S3 のリポジトリ登録も管理コンソールと API 経由で行いたいし,もっと言うと「自動スナップショット」を AWS サポートに依頼せずともリストアできたら便利なんだけどなーとも思う.今後のアップデートに期待する!

こんなにも格差が広がっているとは知らなかった /「シリコンバレーで起きている本当のこと」を読んだ

書店に並んでて,タイトルに惹かれて買った「シリコンバレーで起きている本当のこと」を読んだ.

内容としては軽く数時間あれば読み切れる量になっている.

目次

  • 第1章 「世界を変える」情報発信地
  • 第2章 富を生み出す町の知られざる顔
  • 第3章 新しい技術と既存社会との衝突
  • 第4章 IT企業vs.国家、新たなる対立
  • 第5章 それでも、フロンティアを求めて

感想

Google / Facebook などシリコンバレーを本拠地にする会社をテーマにした本を今まで数冊読んできたこともあって,知っていたこともあったけど,普段光が当たらないような話題として,シリコンバレーの問題点などは知らないことばかりだった.特にシリコンバレーの格差が広がりすぎた結果,市内の路線バスで毎日夜を明かすホームレスが多くいることだったり,財政難によって道路が整備されずにガタガタのままになっていることなど,現地に行ったことがなく,シリコンバレーに特別な憧れを抱いている僕からすると凄く驚きだった.

Uber / Airbnb が既存社会のルールと衝突しながらも成長している話の中で,路駐している場所を売買する MonkeyParking がサービス開始直後に消えた(現在は事業をピボットしている)話は面白かった.「短期間で多くのユーザーを味方につけることができていれば革新的なサービスとして成り立っていたはず」と CEO が話しているのも社会との衝突の難しさだなと感じた.

www.monkeyparking.co

最近は日本でも伸びている EdTech 系の話もあって General Assembly と Hack Reactor が紹介されていた.高額な受講料が必要になるし,審査も厳しいけど,シリコンバレー企業への就職率は99%で,さらに1年目の年収で1000万円を余裕で超えるのは,良い人材に対する需要を意味している.また刑務所にいる受刑者にプログラミングを指導して出所後にエンジニア職に就くという話もアメリカ風だなと感じた.

generalassemb.ly

www.hackreactor.com

まとめると

「シリコンバレー」に憧れていて,もっと詳しく知りたいという人にオススメ!

ルポ シリコンバレーで起きている本当のこと

ルポ シリコンバレーで起きている本当のこと

関連記事

シリコンバレーと第二次世界大戦の話,シリコンバレーの家賃が高騰している話などは,上杉さんの記事が素晴らしくまとまっている.

chibicode.com

chibicode.com

Codenize Meetup に参加して Infrastructure as Code ツールとオペレーションの実践的な話が聞けた

木曜日に Codenize Meetup に参加してきた.Codenize.tools には様々なツールがあって,有名なものだと Roadworker(Route 53 の設定をコード化) / Piculet(セキュリティグループの設定をコード化) / Miam(IAM の設定をコード化)など.タイミング良く Roadworker と Piculet を検証していたので, 実際に運用で Codenize.tools を活用している現場の話を聞いてみたく,抽選も当たって参加できて良かった.

codenize.connpass.com

cloudinfra-audio に Codenize.tools 開発者の @sgwr_dts さんが出てて,Roadworker を作ることになった背景とか,裏話っぽいことが聞けるので良い!オススメ!

cloudinfra.audio

Infrastructure as Code とは何かそして何であるべきか

Recruit Technologies Open Lab 勉強会で知って,読もう読もうと思いながら積読したままになっている “ Infrastructure as Code 本” の紹介だった.来年3月頃には日本語訳で出版される予定があるらしく,頑張って読むか,日本語訳の出版を待つか,悩ましいところ.オライリーで関連する本だと “Effective DevOps 本” もあるし,"Site Reliability Engineering 本“ もあるし,読みたい本が多すぎる.

kakakakakku.hatenablog.com

  • ダイナミックインフラストラクチャにより顕在化した問題
    • サーバスプロール
    • 構成ドリフト
    • スノーフレークサーバ
    • 脆弱なインフラ
    • オートメーション恐怖症
    • システム疲労

「スノーフレークサーバ」と「オートメーション恐怖症」の話は凄く考えさせられた.「スノーフレークサーバ」とは他のサーバと構成/設定が異なるサーバのことで,一時的な障害対応や検証などにより,手動で適用されたまま戻し忘れた設定が残ってしまったり,適用後に Chef などのプロビジョニングツール側のメンテナンスを忘れてしまうなどの状況のことを言う.そうなってしまうと,いざ自動化するときに一部のサーバでエラーになったりして,さらにそのエラーが致命的だと障害になってしまうため,自動化することに不安を感じてしまう「オートメーション恐怖症」に繋がる.今の現場でも最近まで「スノーフレークサーバ」が大量にあって,同じロールなのに全然構成が違ったりもした.Chef 管理を徹底して,ロールを分割して,Serverspec でテストをして,フローを抜本的に見直したことで今はほぼ解消していて,安定的な運用ができている.

  • Infrastructure as Code の原則
    • 簡単に再現できるシステム
    • 使い捨てにできるシステム
    • 統一的なシステム
    • 反復可能なシステム
    • 変更しやすいデザイン

再現可能なことは本当に重要だと思う.Chef を書くときは常に冪等性を意識して,どんな状態でも同じ結果が得られるようにしているし,ビジネス要求の変化によって迅速にインフラ構成も変更する必要があるため,より重要な要素となる.他にも自動化だけではなく,システムを深く理解して継続的に変更を加えられるように「人間中心設計」を意識することも重要という話があった.

speakerdeck.com

Hashをめぐる冒険

  • Codenize.tools のポリシー
    • ステートを持たない
    • エクスポートできること
      • 管理コンソールで設定したいこともある
  • コード化の意義
    • テキストで状態を管理する
    • 冪等性
    • 設定を動的に行う
      • データ記述言語 DSL (JSON / YAML / TOML)
      • 汎用言語 DSL (Ruby)
  • CI ツライ

既に運用中のシステムに導入することを考えると,Codenize.tools にエクスポート機能(+ 冪等性)があるのは重要だと思う.ただ Roadworker の template 機能などは一度使ってしまうと,エクスポートできなくなるため,そこは運用フローもセットで考えて,適材適所に使うという感じになるなと思った.コード化に関しては,やはり表現力の高さと記述量の省略を考えて Ruby などの汎用言語が良いのではないかなと思っているし,だからこそ Codenize.tools が流行ってるんだと思う.

CI ツライのはよくわかる.最近 Roadworker にプルリクを送る前にローカルで RSpec を流したら,個人用ドメイン設定が全て消えて,焦った話も今となっては昔の話.モックも再現性の問題はあるだろうけど,AWS 側で何かしら用意してもらえると CI の幅も広がりそう.

speakerdeck.com

Sustainable Operation

  • 個人に依存するノウハウは基本的に受け継がれない
  • コード化することによって,知識量の差があったとしても,似たように書けば適用できる
  • 知識のグラデーションを許容する
  • インフラエンジニアの仕事はオペレーションからフローの構築に移っていく
  • 継続できる環境を作ることが重要

凄く良い話だった.インフラエンジニアの仕事を権威的に守るのではなく,コード化することによってインフラエンジニア以外にも理解できる形で共有して,継続的に変更ができることに価値があるという内容だった.そして今後のインフラエンジニアの強みは継続的なオペレーションを実現するフローの構築,そして自動化ツールなどに対する深い理解で,オペレーションを行うことではないんだなと感じた.

speakerdeck.com

クラメソ流 Codenize Tools 活用術

  • Piculet でエクスポートした後に Ruby スクリプトで IP アドレスを独自の名前(オフィスの拠点名など)に変換する運用をしている
  • オペレーションチーム専用の社内試験がある
    • フェーズ 3 で Piculet を使ったテストなどがある

どんな社内試験なんだろう!受けてみたいなーと思った.

あと Piculet でグループ名が ["111111111111", "sg-11111111"] のような形式になってしまうという話は僕も同じく経験した.そのときに調べた限りだと,IAM ポリシーで iam:GetUser を許可する場合と許可しない場合で形式が違ったので,許可するようにして回避した.

www.slideshare.net

kumogata-template の紹介

  • Kumogata フルサポート
  • DSL をさらに簡略化して書くことができる Gem
  • 今後 Kumogata2 に切り替える

www.slideshare.net

Roadworkerではじめる大量DNS移行

  • 事故を防ぐ Tips
    • direnv を使ってクレデンシャルを管理する
    • ドメインごとにディレクトリを分けることで -f オプションなど副作用のあるコマンドも安心感が得られる

speakerdeck.com

terraform の運用で消耗してる話(そして codenize で助けて欲しい話)

  • Terraform を運用していると予想外の変更が発生する場合がある
    • リソースが再作成されてしまう
    • 管理コンソールで一時的な変更をしたままにしてしまうと次の実行でその変更が消えてしまう
  • terraform plan の結果を見極めることが重要

まぁ Terraform だけじゃなく CloudFormation も同様にそういう場面はあると思うし,例えば Piculet も管理コンソールから修正不可能な「グループ名」などを修正すると再生成になったりはする(インスタンスとの依存はチェックしてくれるけど).ツールの挙動を深くまで理解してないと,使うの怖いよなぁ…という印象がある.発表者の恩田さんが書いた記事を読んだときに良い事例だなと思ったのと同時に,もし Terraform 使うなら既に Terraform の運用経験のある人がいてくれると安心感があるなーと思ったりしていた.

developers.eure.jp

(資料はまだ公開されてなさそう)

まとめ

Codenize.tools だけではなく,実践的な Infrastructure as Code の話が聞けて良かった.積極的に導入していきたい.

関連記事

dev.classmethod.jp

最近 Codenize.tools を検証した記事(Piculet と Roadworker)

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Slack で "積極的に通知を受け取る" ための簡単な設定

「Slack 2 Advent Calendar 2016」7日目の記事を書くぞー!

たまには Slack ネタでも書こうかなと思って Slack Advent Calendar を見たら全枠埋まってたけど,Slack 2 Advent Calendar は全然埋まって無くて,7日目を担当することにした.まだまだ枠空いてるし,参加者募集!

qiita.com

積極的に通知を受け取る

Slack でよく話題になるのは「通知を抑制する」話だと思う.

  • Mute(ミュート)
  • Snooze(スヌーズ)
  • Do Not Disturb

など Slack で提供されている機能を使って,開発業務に支障が出ないように適度に抑制している人も多いだろう.

今回は逆に「積極的に通知を受け取る」話を書いてみようと思う.誰しも「新規ポストがあったらすぐに通知を受け取りたいチャンネル(気付かないと問題になる系)」があるのではないかと思う.例えば,監視アラート用のチャンネルだったり,アプリケーションエラー用のチャンネルだったり,ビジネス的に緊急度の高いチャンネルだったり.

知ってる人も多いと思うけど,意外にも僕のまわりだと知らない人が多くて,1度書いておこうと思った.とは言っても,設定自体は一瞬で終わるんだけども!

Channel Specific Settings

設定は簡単にできる.Account ページ(https://xxx.slack.com/account/notifications)にアクセスして,Notifications タブにある "Channel Specific Settings" で,特定のチャンネルを選択する.そして

  • Desktop - Everything
  • Mobile - Everything

にする.完了!

f:id:kakku22:20161206224526p:plain

ちなみに Slack クライアントから設定することもできる.チャンネルで "Channel Settings → Notification Preferences" を選択する.そして

  • Desktop notifications - Activity of any kind
  • Mobile push notifications - Activity of any kind

にする.完了!

f:id:kakku22:20161206232711p:plain

Mobile Push Timing

合わせて "Mobile Push Timing" の設定も変更しておくと良いと思う.デフォルトで "2 Minutes" になっている通知までの待機時間をすぐ受け取るようにする.

"Channel Specific Settings" と同じ Account ページにあって,"Mobile Push Timing" の選択肢を "Send push notifications as quickly as possible when I'm not active on the desktop" に変更する.完了!

f:id:kakku22:20161206230009p:plain

まとめ

Slack の通知とうまく付き合うためには「抑制」も必要だけど,同様に「積極的に受け取ること」も必要だと思う.僕の場合だと,監視アラートが発生するとすぐに Android に通知が飛んで,さらに Pebble に通知が飛ぶため,腕でサッと監視アラートの内容を確認することができる.凄く便利だからオススメ!

簡単な記事だけど,誰かの参考になれば良いな!

関連記事

チャンネルごとに設定する手順はドキュメントにも書いてあった.

get.slack.help

Route 53 の管理を自動化できる Roadworker を試して GeoLocation のエクスポートを直した

最近試していた Piculet に続き,Codenize.tools の中でも特によく使われてそうな Roadworker を試した.セキュリティグループほどの複雑さはないけど,ドメイン設定も管理コンソールで運用するのではなく,宣言的にコード化を進めて,レビュープロセスを通してから反映するべきだなと考えていて,既に稼働しているシステムに導入するのに適切なツールだなと感じている.

github.com

今年7月に開催された Infrastructure as Code 勉強会でも DNS 設定を Reproducible(再現可能) に管理する事例として Roadworker が紹介されていた.

kakakakakku.hatenablog.com

エクスポート

既に Route 53 に適用されている設定を簡単にエクスポートすることができる.Roadworker では冪等性が保証されているため,エクスポートした直後に反映しても,変更点がないため,副作用が起きないという点に良さがある.

$ roadwork --export --output Routefile
Export Route53 to `Routefile`

エクスポートされる Routefile は以下のような DSL となる.宣言的になっているため,読んで理解できるのは素晴らしい.

# -*- mode: ruby -*-
# vi: set ft=ruby :
hosted_zone "kakakakakku.com." do
  rrset "blog.kakakakakku.com.", "A" do
    ttl 300
    resource_records(
      "127.0.0.1",
      "127.0.0.2"
    )
  end
end

反映

Routefile を修正して簡単に反映することができる.以下は最初に --dry-run で確認した後に反映した.

$ roadwork --apply --dry-run
Apply `Routefile` to Route53 (dry-run)
Update ResourceRecordSet: blog.kakakakakku.com. A (dry-run)
  resource_records:
    -[{:value=>"127.0.0.1"}, {:value=>"127.0.0.2"}]
    +[{:value=>"127.0.0.1"}, {:value=>"127.0.0.2"}, {:value=>"127.0.0.3"}] (dry-run)
No change

$ roadwork --apply
Apply `Routefile` to Route53
Update ResourceRecordSet: blog.kakakakakku.com. A
  resource_records:
    -[{:value=>"127.0.0.1"}, {:value=>"127.0.0.2"}]
    +[{:value=>"127.0.0.1"}, {:value=>"127.0.0.2"}, {:value=>"127.0.0.3"}]

冪等性も保証されている.

$ roadwork --apply
Apply `Routefile` to Route53
No change

GeoLocation レコードのエクスポートに問題があった

GeoLocation レコードをエクスポートしたときに,以下のように geo_location の部分に Ruby の struct がそのまま出力されてしまっていることに気付いた.

# -*- mode: ruby -*-
# vi: set ft=ruby :
hosted_zone "kakakakakku.com." do
  rrset "geo.kakakakakku.com.", "A" do
    set_identifier "1234"
    ttl 300
    geo_location #<struct Aws::Route53::Types::GeoLocation continent_code="AS", country_code=nil, subdivision_code=nil>
    resource_records(
      "127.0.0.1"
    )
  end
end

デバッグしながら修正して,プルリクを送って,無事にマージしてもらうことができた(クローズになるかもなーと予想していたけど).簡単に言うと,GeoLocation の場合は value のクラスが Hash ではなく Aws::Route53::Types::GeoLocation になるため,その部分をハンドリングできるようにした.ハッシュ化された文字列から {} を除去するロジックはそのまま残している.

現在 v0.5.8.beta2 に暫定的に取り込まれていて,以下のように出力できるようになっている.

# -*- mode: ruby -*-
# vi: set ft=ruby :
hosted_zone "kakakakakku.com." do
  rrset "geo.kakakakakku.com.", "A" do
    set_identifier "1234"
    ttl 300
    geo_location :continent_code=>"AS"
    resource_records(
      "127.0.0.1"
    )
  end
end

github.com

なぜ GeoLocation に気付いたかというと,前に AWS 認定を勉強していたとき に Route 53 の機能をいろいろと試していて,そのときに作った GeoLocation レコードがたまたま残っていたという感じ.

RSpec を流す前に気を付けること

プルリクを送る前に一度テストを通してみようと思って RSpec を流したら,個人の AWS アカウントの Route 53 設定が全て吹っ飛んで焦った!!!検証用のドメインだから問題なかったし,エクスポートした Routefile をすぐ反映して戻せたから良かったけど,気を付けないと事故に繋がりそう.

ちなみに spec_helper.rb を見ればわかる通り,テスト用の環境変数を設定しないと流せないため,デフォルトの状態で RSpec を流しても副作用は起きなかった.プルリクを送ったときに TravisCI で流れたテストも落ちていたけど,マージされていたし,テスト用の AWS アカウントを用意して安全に運用するのも結構大変だなぁ…という印象だった.

まとめ

Piculet と同様に AWS リソースを部分的にコード化していく中で,Route 53 を管理する Roadworker は凄く便利だと思った.CircleCI 経由で自動的に反映する運用も含めて整理して,チームに提案してみようと思う.

関連記事

roadwork --test で実際にレコードのテストができるのは凄く良いな!参考になる記事だった.

tech.feedforce.jp

前に Piculet を試したときにまとめた記事も合わせて見てもらえると良さそう.

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Codenize Meetup

絶対に参加したかった Codenize Meetup の抽選に当たって参加できることになった!来週楽しみ!

codenize.connpass.com