続 カッコの付け方

AWSを始めとしたクラウドコンピューティング全般と、唯一神emacsにおける()の付け方についてだらだら書きます

GCEでHTTPS負荷分散 SSL Termination

技術的に不可能だろうと思っていましたが、予告通りHTTPS負荷分散がGCEでも実現可能となりました。
これにより、SSL TerminationがGCEでも可能となりました!

HTTP負荷分散との変更点

GCEのロードバランサは2つあります
- ネットワーク負荷分散
- HTTP負荷分散
いずれもAWS - ELBに比べて暖気不要などアドバンテージがあるのは変わりませんが、本機能はHTTP負荷分散のみです。
Developers Consoleから変更可能です。

簡単ですが、一旦HTTP負荷分散として設定したものを、HTTPSへ変更する手順を記す。

HTTPSでリクエストを受ける

f:id:iga-ninja:20150712183827p:plain

SSL証明書をアップロード

f:id:iga-ninja:20150712183923p:plain

f:id:iga-ninja:20150712183932p:plain

アプリケーション側の考慮

AWSのELBと同じく、ロードバランサ側でSSLを剥がしてしまうので、バックエンドのWebサーバ側にとっては ブラウザからHTTPSかHTTPの判断がつきません。が、そもそも1つのIPアドレスで80 & 443を両方Listen出来ないので、この考慮は必要ないかもしれません。

HTTPヘッダ

ここから書くことはドキュメンテーションにも記載がない内容となります。今後変更される可能性は極めて高いと思います!

ダサくて嫌だけど、おなじみphpinfo()でのぞきます。#もっとイケてるカッコイイ方法を探そう

f:id:iga-ninja:20150712183943p:plain

これを見てわかることは
- HTTPSは何かのリソースでSSLを解いている
ということは、暖気不要とはならないはず
- AWS - ELBに比べて、SSLを解く専用のナニかが在る
それが X-FORWARDED-FORに出ている。だからカンマ区切りの2段転送。

まとめ

AWSのELBとはかなり違うので注意!
1. 1つのIPアドレスで 80 & 443を Listen 出来ない
2. X-Forwarded-Forはカンマ区切りになる(これは2段リバプロとかやるとこうなる、標準の動き)
3. この構成だと、暖気無しとは行かないのではないか?
ひとまず出来ましたが、まだ課題が沢山ありますね。。Betaが切れる頃までに仕様が様変わりするかもしれないので、そこまで待つ!

GoDaddyからRoute53によるDNS管理に変える方法

日本でDNSといえばお名前.comが有名ですが、GoDaddyは海外の老舗という感じで、かなり古くから存在し、今もドメインレジストラとして健在です。今回はGoDaddyからDNS管理をRoute53に変更します。レジストラとしてはGoDaddyのままで、Transferは行いません、Transferについては、下記で動画による丁寧な解説があります。

www.youtube.com

Route53側の準備

Hosted Zone を作って終わりです。NSレコードが4つ作成されるので、それをメモります。

GoDaddy側の設定

f:id:iga-ninja:20150628215546p:plain

f:id:iga-ninja:20150628215614p:plain

f:id:iga-ninja:20150628215647p:plain

f:id:iga-ninja:20150628215700p:plain

f:id:iga-ninja:20150628215714p:plain

引越し時の注意

引越とは、現在GoDaddyでDNSレコードを管理していて、かつサービスも稼働している場合を想定します。現在、AWS以外のホスティング・オンプレ環境などでサービスしており、これをAWS-EC2やELBに変更するパターンを指します。
この引越パターンの場合、GoDaddy側のNSレコードTTLを短くできるとよいのですが、残念ながら、NSレコードのTTLは調整出来ないようです。

f:id:iga-ninja:20150628215822p:plain

上記の通り、TTLは1日で固定なので、1発で引越とは行かず、必ず平行期間を経ることになります。
1. Route53のレコードをGoDaddyの既存レコードと全く同じにする
2. GoDaddy側のNSレコードを書き換える(上記でやったこと)
3. 1日待つ、この間は平行期間となる 4. GoDaddy側のレコードが参照されていないことを確認する
5. Route53側のレコードをAWSサービスに向ける

まとめ

DNSに関しては、半端な理解に対して警鐘をならすエントリがたくさんあります。 http://wp.kaz.bz/tech/2013/04/15/1606.html
浸透いうな!

このエントリでは表層的な部分についてしか触れていませんが、しっかり理解して意のままに制御できるようにしたいものです。

mac の chromeに「このウェブサイトからいつもとは異なる誤った認証情報が返されました」といわれたら

エライところではまってしまった。
chrome @ macpaypal やら twitter やら、はては App Store もダメだ!どういうこと?

ググると出てくるルート証明書の期限ぎれ問題だけど、どうも切れている証明書は無い、、
調べてみると ルート認証局はすべて Verisign Class 3 Primary Certification Authority - G5

とりあえず復旧手段は

  1. キーチェーンアクセス -> ログイン & 証明書で、該当中間証明書があれば削除する
    画像はもう消えちゃってるけど f:id:iga-ninja:20150628183927p:plain
  2. Chromeの履歴を全削除 設定 -> 詳細設定を表示... -> プライバシーの閲覧履歴データの消去 f:id:iga-ninja:20150628183939p:plain

  3. Chrome再起動

  4. App Store アプリとかも、再起動が多分必要

やべえなこれ、なんで起こったのだろうか? この証明書がイカれてしまうと、App Storeが死ぬので、Updateもできない。

ELBを使うときの注意、/28のサブネットは狭すぎる!

AWSVPC & Subnetのビットマスクは /16 - /28 です。この数字を聞いて 「狭い方はもう少し出来てもいいんじゃないか?」と私も思っていましたが、/28でも狭すぎます!特にELBを使う場合は、すぐにIPが尽きてしまいます。

なぜ狭いビットマスクを指定するのか?

  1. VPNを張りたいので、CIDRの衝突を回避するため
  2. VPC Peering でのCIDRの衝突を回避するため
  3. 貧乏性

概ね別ネットワークとの接続が目的だと思います。私は、VPN接続が予定されているが、対向のCIDRが分からない、だから極力狭いサブネットを指定して衝突する可能性を下げる目的でつかいました。ただし、この用途では、ISP Shared Address(100.64.0.0/10)を使ってしまうのも手です。

狭いビットマスクとELB

早くも結論を書くと
/28で使えるIPアドレスは、AWS側ルータ等に取られるIPアドレスを差し引いて11個。そのサブネットにELBを建てると、ELB暖気申請していなくても、8IPが予約されてしまう。よって、2台ELBを/28のサブネットに建てることはできない

こんなことになります。

AWSのドキュメント

2012年に偉大な方より言及されております。

blog.cloudpack.jp

これによると、20IPのリザーブと記載がありますが、現在のドキュメントでは8 IPと改められているようです。ただしドキュメント日付は同じでも日本語ドキュメントには一切記載がありません。(2015/06/28の時点)

docs.aws.amazon.com

再現方法

この現象に遭遇してから、再現しようと思ったけど、意外に苦戦しました。/28のサブネットを作成し、ELBだけを複数台作成すると、2台以上作れたりします。

まず、11個のローカルIPアドレスの内、4IPを食いつぶし、残り7IP以下とします。
ケチるなら、ENIを無駄作成 & Attachが手っ取り早いです。どんな方法でもいいので、VPC->Subnetの表示で、残りIPが7以下の状態を作ります。

f:id:iga-ninja:20150628151211p:plain

その上で、普通にELBをつくろうとしたら、下記の表示が出ます。

f:id:iga-ninja:20150628151218p:plain

まとめ

  1. /28でサブネットを切るなら、ELBは1台だけと覚悟する
  2. 2015年6月現在のELBのためのIPリザーブ数は 8 IP、しかも各々のサブネットに対して
  3. 可能な限り、ドキュメントは英語を読む

AWSの新しいVM Import ImportImage で複数ディスクを一気にAMIへ!

仮想環境(VMWareとか)からAWS EC2へコンバート&インポートする機能は、以前から存在しましたが、新しく Import Imageという方法がサポートされました。 今までと何処が違うのかと、実際にやってみたので紹介します。 http://aws.typepad.com/aws_japan/2015/04/vm-import-update-faster-and-more-flexible-with-multi-volume-support.html

Import Imageとは?

上記ブログを読んでいただけるのが早いのですが、要は
- Import Instance = VMイメージがいきなりEC2インスタンスになる.
- Import Image = VMイメージがAMIになる。

新しくサポートされた Import Image ですが、何が美味しいの?に対して

  • 複数ディスクの構成のVMインポートに対応!
  • 同時インポート数が 5 -> 20へ!
  • OVA形式に対応! (一枚岩のイメージファイル)

ってところです。便利ですね。技術的にもこちらの方が筋がいいと思う。

実践

道具の準備

Import Instanceは、EC2 API Tool を使いましたが、Import Imageは AWS CLIでOKです。楽ですね!

手順の概要

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/UsingImportImage.html によると、
1. AWS CLI をインストールします。
2. Amazon EC2 にインポートする VM を準備します。
3. VM を仮想化環境からエクスポートします。
4. VMAmazon EC2 にインポートします。
5. Amazon EC2インスタンスを起動します。

となっていますが、この通り進めても確実に止まります!

Import Imageの方法

まず、Import Instanceと違って、コマンドはVMイメージファイルをS3のアップロードからを面倒見てくれません
自分でS3へアップロードする必要があります。(AWS的にはお好きなS3クライアントでアップロードできる!となってます)
VMイメージはでかいファイルなので、aws s3 コマンドが最適でしょう。マルチパートアップロードもできる。 そののち、AWS CLIを打つのですが、そこには罠が。。。

まずは、VMのExport

複数ディスクを一発インポートするので、OVAを指定して一枚岩にしました。
OVFテンプレートのエクスポートで、単一のファイル(OVA)を選択しましょう

S3へアップロード

なんでもいいですが、aws s3 コマンドがお勧めです。マルチパートアップロードがいい感じ!

vmimportロールの設定

出ました。ここがです。マニュアルどおりにやると、後は aws ec2 importimageで万事OKのはずですが、エラーが出るはずです。

A client error (InvalidParameter) occurred when calling the ImportImage operation: The service role <vmimport> does not exist or does not have sufficient permissions for the service to continue

AWSに慣れていない人だとビビりますが、roleと書いてありますね。aws cliコマンド発行から、AWS内部のシステム連携するにあたって、roleを使って権限を担保します。 では、roleを足しましょう。ドキュメントはこちらにあります。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/VMImportPrerequisites.html
前提条件の中段当たりに VM Import サービスロールとありますので、こいつを指示どおりに設定します。手順は上記ドキュメントどおりで割愛します。

いよいよVM Importを実行

コマンドは至って単純 aws ec2 import-image --cli-input-json file://import.json
でもって、import.json

{
    "Description": "importDualDisk", 
    "DiskContainers": [
        {
            "Description": "dualDisk", 
            "UserBucket": {
                "S3Bucket": "<your-bucket>", 
                "S3Key": "<s3上のovaファイルのパス>"
            }
        }
    ]
}

さて、上手く行ったかな?

$ aws ec2 describe-import-image-tasks
{
    "Status": "active",
    "Description": "importDualDisk",
    "Progress": "2",
    "SnapshotDetails": [
        {
            "UserBucket": {
                "S3Bucket": "<your-bucket>",
                "S3Key": "<s3上のovaファイルのパス>"
            },
            "DiskImageSize": 0.0
        }
    ],
    "StatusMessage": "pending",
    "ImportTaskId": "import-ami-hogehoge"
}

まだかな、まだかな〜

$ aws ec2 describe-import-image-tasks
{
    "ImportImageTasks": [
        {
            "Status": "active",
            "Description": "importDualDisk",
            "Progress": "28",
            "SnapshotDetails": [
                {
                    "UserBucket": {
                        "S3Bucket": "<your-bucket>",
                        "S3Key": "<s3上のovaファイルのパス>"
                    },
                    "DiskImageSize": 325137408.0,
                    "Format": "VMDK"
                },
                {
                    "UserBucket": {
                        "S3Bucket": "<your-bucket>",
                        "S3Key": "<s3上のovaファイルのパス>"
                    },
                    "DiskImageSize": 68096.0,
                    "Format": "VMDK"
                }
            ],
            "StatusMessage": "converting",
            "ImportTaskId": "import-ami-hogehoge"
        }
    ]
}

converting キタ━━━━(゚∀゚)━━━━!! ディスク2つも来てるぅ−!!
そののち preparing ami ステータスを経て

$ aws ec2 describe-import-image-tasks
{
    "ImportImageTasks": [
        {
            "Status": "completed",
            "LicenseType": "BYOL",
            "Description": "importDualDisk",
            "ImageId": "ami-xxxxxxx",
            "Platform": "Linux",
            "Architecture": "x86_64",
            ...
}

AMI-IDデキタ− オレ歓喜!

後はAMIからEC2起動!

問題なくできましたよ。 f:id:iga-ninja:20150607202017p:plain

まとめ

  • 複数ディスクOK
  • AMIだから、後からディスクの種類変更もOK
  • 手順的には role作成をわすれずに!!
  • vCentor + Connector でもできたらなぁ (AWSサポート回答によると、2015/06/07 まだ出来ないみたい)

楽になってうれしいな!

俺のオワコンコマンド整理

2015年 オワコンコマンドを整理します。
去年の自分なら、「オワコンコマンドも yumで入れればいいじゃないか!」と思っていましたが、どうやら時代がそれを許してくれないようです。Dockerをやるつもりがあるなら、代替可能な古いコマンドを使うのは捨てたほうがいいです。イメージ次第ですが、netstatなどはもう入っていないことが多いです。

grep -> ag

なんとあのgrepはもうオワコン入りです。ag (Ther Silver Search)というコマンドがgrepよりもは早く、かつ賢く、find & (xargs) & grep も葬り去ることになりました。すぐに消えることはなさそうですが、捨てる準備をしておきましょう。マカーも brew install ag で一発です。
github.com

telnet -> nc

NEでも無い限り、本当のtelnetが必要なことはほとんど無いでしょう。telnetは、TCP:Portの疎通確認に使っていると思いますが、この用途ではもうオワコンです。Dockerイメージは特にですが、ncすら入っていないこともあります。使い方はほぼ一緒ですので、すぐに捨てられます。

netstat -> ss

これもDockerです。もう netstatは主流じゃない という認識で良いです。コマンドもほとんど同じ、打鍵も減って楽。

ifconfig -> ip a

これもDocker。打鍵も減るし、netmask表示がビットででるので。

route -> ip r

同上

cpan -> cpanm

perl自体の元気がなくなり、情報が少しずつ古いままで止まっていましたが、まだまだperlは現役で、重要な言語であることに変わりありません。だけど、cpanでげんなりすることが多々あるので、どうにかしたいと思っていたら、cpan shell自体、とうの昔にオワコンらしいです。cpanmを使いましょう。チョット試してみましたが、いい感じでイライラを軽減できます。 http://www.omakase.org/perl/cpanm.html

screen -> tmux

正直screenを使い始めた頃に一旦この業界から離れているので、screenはあんまり使いこなせていませんでした。screenの詳しいことはわかりませんが、シリアルが使える点を除いて、今からやる人はtmux一択でいいでしょう。macから使える、いいシリアルの接続方法を知らないので、screenもtmuxも両方いれてます。めったに使わないけど。

rubyでマルチドキュメントyamlを捌く

マルチドキュメントyamlってなんだ?
1ファイルの中に---が複数入っているyamlです。こんな感じ

---
kind: dns#resourceRecordSet
rrdatas:
- x.x.x.x
ttl: 3600
type: A
---
kind: dns#resourceRecordSet
rrdatas:
- hogehoge
ttl: 3600
type: CNAME

コード

#!/usr/bin/env ruby
# -*- coding: utf-8 -*-
require 'yaml'

org = File.open("/path/to/yaml")
yam = YAML.load_documents(org)
org.close

ed_yam = yam.select{...}

File.open("/path/to/yanl", "w") do |e|
  e.write(YAML.dump_stream(*ed_yam))
end

読み込むとき load_documentsで吸わないと、最初のドキュメントで止まってしまう。 また吐き出すときも dump_streamでばらさなければいけないが、Arrayのままばらしてしまうと、これもひとつのドキュメント扱いになるので、 * 配列バラシをしている。