パラボラアンテナと星の日記

あることないこと

EC2自身が起動時にRoute53の設定を自分で更新するやつ

Docker ruby CoreOS Route53

github.com

EC2立ち上げるたびに手で名前設定するのが面倒なので、EC2自身がRoute53叩いて設定するやつをDockerfileで書いた。

流行りのAWS Lambdaとかは使ってません。

使い方

EC2インスタンス上で、以下のようにdocker runするだけで、 いい感じにCNAMEレコード更新(UPSERT)する。

$ docker run -h $(hostname) --rm hoshinotsuyoshi/r53-from-ec2:2.1.23 ゾーン名(例:example.com.)

事前に、以下の2点が必要。

  • "AmazonRoute53FullAccess" というIAM PolicyをインスタンスのIAM Roleにアタッチしておくこと
  • ゾーン(例:example.com.)の設定が、既にRoute53にあること

cloud-configでの動かし方

ユーザーデータに、こんな感じで書いておく。

hostname: ホスト名
coreos:
  units:
    - name: r53-from-ec2.service
      command: start
      content: |
        [Unit]
        Description=r53
        After=docker.service
        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStart=/usr/bin/docker run -h %H --rm hoshinotsuyoshi/r53-from-ec2:2.1.23 ゾーン名(例:example.com.)

これでインスタンス立ち上がった直後に、ホスト名.example.com でアクセスできる。

スクリプトの中身

  • 中途半端だけどOptionParserを使ってる
    • --help とか渡せる
    • --private とか渡すとPrivate DNSの設定更新になる
  • TTL(60秒) とレコードタイプ(CNAME)がベタ書き。
  • ruby使ってて、イメージサイズが大きい(90MB)点はイケてない
def pub_hostname
  open('http://169.254.169.254/2014-11-05/meta-data/public-hostname').read
end

def pri_hostname
  open('http://169.254.169.254/2014-11-05/meta-data/hostname').read
end

opt = OptionParser.new
opt.on('-h', '--help') do
  STDERR.puts "USAGE\n$ docker run -h $(hostname) --rm hoshinotsuyoshi/r53-from-ec2 example.com."
  exit 1
end

opt.on('--private') do
  @hostname = pri_hostname
end

opt.parse!(ARGV)

@hostname ||= pub_hostname

ZONE = ARGV.shift.dup
ZONE.end_with?('.') || ZONE << '.'
HOST = Socket.gethostname
REGION = @hostname.split('.')[1]

c = Aws::Route53::Client.new(region: REGION)
id = c.list_hosted_zones.hosted_zones.find{|z| z.name == ZONE }.tap do |zone|
  zone.nil? && !STDERR.puts("Cannot find zone #{ZONE}") && exit(1)
end.id
c.change_resource_record_sets(
  hosted_zone_id: id,
  change_batch: {
    changes: [
      {
        action: 'UPSERT',
        resource_record_set: {
          name: HOST + '.' + ZONE,
          type: 'CNAME',
          ttl: 60,
          resource_records: [
            { value: @hostname }
          ],
        },
      },
    ],
  },
)

ベタ書きのとこ直して ちゃんとオプションで渡せるようにすれば割りと使えるツールになるかも？

CoreOSだけでNFSサーバー in EC2

CoreOS NFS

CoreOSだけでNFS。dockerナシでできました。

CoreOSにはrpc-mountdやらnfsdやらが入ってて、いろいろやればできた。

以下、一応動作確認したサーバー側(EC2 1台)とクライアント側(EC2 1台)のyamlの中身です。

サーバー側

#cloud-config

hostname: nfs-server
write-files:
  - path: /etc/exports
    permissions: '0644'
    content: |
      /var/data    172.31.0.0/16(rw,async,no_subtree_check,no_root_squash,fsid=0)
coreos:
  units:
    - name: timezone.service
      command: start
      content: |
        [Unit]
        Description=timezone
        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStart=/usr/bin/ln -sf ../usr/share/zoneinfo/Japan /etc/localtime
    - name: volume.service
      command: start
      content: |
        [Unit]
        Description=mkdir -p /var/data
        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStart=/usr/bin/mkdir -p /var/data
    - name: rpc-mountd.service
      command: start
    - name: nfsd.service
      command: start

ポイント(?)

  • ExecStart=/usr/bin/mkdir -p /var/data
    • ディレクトリ作るやり方が分からず、こうなった。もっとスマートに書くやり方教えて欲しい…

クライアント側

サーバー側とは別のEC2インスタンス。

#cloud-config

hostname: nfs-client01
write-files:
  - path: /etc/conf.d/nfs
    permissions: '0644'
    content: |
      OPTS_RPC_MOUNTD=""
coreos:
  units:
    - name: timezone.service
      command: start
      content: |
        [Unit]
        Description=timezone
        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStart=/usr/bin/ln -sf ../usr/share/zoneinfo/Japan /etc/localtime
    - name: rpc-statd.service
      command: start
      enable: true
    - name: mnt-data.mount
      command: start
      content: |
        [Mount]
        What=server.nfs.inner:/var/data
        Where=/mnt/data
        Type=nfs
    - name: chown-core-mnt-data.service
      command: start
      content: |
        [Unit]
        Description=chown core /mnt/data
        After=mnt-data.mount
        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStart=/usr/bin/chown core /mnt/data

ポイント(?)

  • What=server.nfs.inner:/var/data
    • サーバー名の部分、IPアドレスでも良い。
    • 今回はnfsサーバー側にRoute53でserver.nfs.innerって名前つけてる。
  • ExecStart=/usr/bin/chown core /mnt/data
    • chownしないと実用的じゃない。けどたったこれだけのために10行程度書かないといけないのがイケてない気がする

その他EC2周り設定

セキュリティグループ(サーバーもクライアントも)

こんなノリ

f:id:hoppie:20150923001751p:plain

ほんとは2049番だけでもいいかも。試してない。

サーバーの名前設定

こんなノリ

f:id:hoppie:20150923001804p:plain

所感

  • もちろんnfsdじゃなくて、docker + volumeでもなんか出来そう

参考にしたページ

How to deploy NFS Server in CoreOS_ - Google グループ

Enabling and Mounting NFS on CoreOS · Scott's Weblog · The weblog of an IT pro specializing in virtualization, networking, open source, and cloud computing

dockerで遊ぶときにEC2で動かす 俺の2015年秋

CoreOS docker

この記事は、最後まで読んでも特に新しいことは書いてありません。

TL;DR

dockerで遊ぶとき、EC2も良いっすよ

dockerで遊ぶとき

docker-machineやcoreos-vagrantも良いツールなのですが、個人的にはEC2に落ちついてきました。

1つのホストの中にコンテナをぽこぽこ立てたり、マルチホスト環境とか作ったりして遊んでいます。

サンデープログラミングが捗るという感じです。

最近のことをメモがてらまとめておきます。

戦略

遊ぶ時の戦略(?)は、こんな感じです。

  • 準備1: CoreOSで起動設定(LaunchConfigurations)を作っておく
    • (作業時間2分以下)
    • AMIはこのへんから、適当に。
  • 準備2: AutoScalingGroupを作っておく
    • (作業時間2分以下)
    • このとき適当にロール当てておくと後でS3とかECS周りで便利(無くてもOK)
  • 遊び始め
    • AutoScalingで 手動で 希望インスタンス数を 0 -> N(N>=1) する
    • (待つこと1〜3分)
  • 遊ぶ:
    • 自由に遊ぶ!!!
  • 遊び終了

遊んだ後にかたづけしないと課金がずっと続く パターンのやつです。

とくに気取った自動化はやっておらず、 「忘れずに0に戻す」 を実践して参ります。

CoreOS、Immutable度高い

CoreOSの場合、どうしても最初に設定されているべきことはuser-dataにcloud-configを書く必要出てきます。

ちゃんとcloud-config書いておけば、こころ置きなく遊んだ後にシャットダウンできるという感じです。

「遊んだ後にシャットダウンする」と「cloud-config」は相性良い(気がする)。

開発環境としてのVagrant(+VirtualBox)やdocker-machineとの対比

docker-machine(boot2docker)との対比。

  • メリット
    • 自分の回線都合でdocker pullが遅いとかいうことがなくなる
    • 自分のメモリ都合でVMが作れないということがなくなる
    • production環境に近い
    • ECSが試せる
    • VirtualBox固有のハマりどころにハマらない
  • デメリット
    • 金がかかる(t2.microを1ヶ月動かすと2000円ぐらいかかる)
    • セキュリティグループだるい
    • 起動が遅い

「金がかかる」に関しては、無料利用枠があるうちは無料ですね、私はまだ適用期間内なのでなんとか頑張っています。

「セキュリティグループがだるい」に関しては、まぁproductionで使う時もだるいので…

自分の場合、メリットの1番目が大きくて、わりとdocker pullが遅いのがイライラさせるとこだったんです。

ファミレスとかでテザリングを使う人間にとってこれはデカい。

あと、PCにどれくらい空いているメモリがあるか、ということでも話が違ってくると思う。