HDE BLOG

コードもサーバも、雲の上

EIPプールをつくったお話

Service Engineering Division / DevOps Unitの出口です

先日,社内勉強会にて「EIPプールをつくったお話」をユニットの代表として発表させていただきました. 発表内容のダイジェストをこちらのHDEブログに書いて欲しいという依頼を頂きましたので 僭越ながらありがたく書かせていただきます.

DevOpsチームにとってのEIP

メールサービスをお客様へ提供するために リリース作業のなかで新しいEIPを取得し,お客様のテナントと紐付けを行っています

しかしながらただEIPを取得するだけではなく以下の作業(設定の申請)を行わなければなりません

  • メール送信制限の解除申請
  • IPの逆引き申請
  • RBLの解除申請

「なんだたったの3作業か,それぐらい仕事しろよ」と思われるかもしれませんが 実際に作業をしていると以下の問題点が浮上します

  • AWS作業遅れがリリース作業スケジュールに影響を与えている
    AWSの作業遅れによりリリース作業を行うときに時間に余裕を持たせなければいけなくなります

  • 確認作業を行う必要がある
    RBL解除されているかの確認作業を行う必要があります

  • 生身の人間がEIPを操作するのには無理がある
    現状EIPにはタグ等を付けられないので XXX.XXX.XXX.XXXのEIPの申請を間違えてYYY.YYY.YYY.YYYで出してしまった等のミスが考えられます

ということでEIPを貯めておくプールを作りました

これらの問題を一挙に解決するためにDevOpsユニットが頑張ってEIPを蓄えておけるプールを作りました. 簡単なフローは以下のとおりです

  1. 定期的にEIPを「申請解除待ち」状態としてためる
  2. 自動的に申請を出す
  3. 別タスクで定期的にRBL等から解除されているか確認をする
  4. 解除されたことが確認されたら「申請解除」状態にする

また上記フローとは別に以下の機能もつけました (詳しい説明は割愛)

  • ログを残す (基本中の基本)
  • Slack通知機能
  • RBL監視システム

EIP Poolが実装されたよ

そして先日,ついに本番環境へ実装されました

朝のMTG後にJenkinsさんがEIPプールの状態をお知らせする様子がこちらです

f:id:koppe_dd:20150611174115p:plain

現在DevOpsユニットでは最大30のEIPを確保するような設定になっているのですが, 上の図は自由に使える状態(つまり申請が処理されて設定済み)のEIP(緑りんご)が24あり, 申請が処理されるのを待っているEIP(赤りんごとなす)が4つあり, 空いている状態(ふたば)が2つとなっています(こちらの空きは自動的に補填されるようになっています)

ここで地味に注目していただきたいのが「なす」です
この「なす」のマークが付いているEIPは申請は出したけれどなぜか長期(7日以上)経過しても 設定されていないEIPに対してつけられるマークで以前までの環境だと リリース遅延の原因となりうるEIPだったことを意味します

一方でEIPプールを実装した後はすでに確保してある設定済みのEIPを使えば良いため, このようにリリース遅延の原因をなくすことが出来ました.

おわりに

今回ご紹介したEIPプールは自動化に関するほんの一例で DevOpsユニットではEIPプールにとどまらずさらなる自動化やリリース作業の効率化によって日々進化をしつづけています

機会があれば,皆様にDevOpsユニットがどのようにして効率化をしているかご紹介できればと思います. つたない文章でしたが最後まで見て下さりありがとうございます

YAPC::NA 2015 に参加してきました

YAPC::NA は16年の歴史を持つ今夏開催されるYAPC::Asia Tokyo 2015の元となったカンファレンスです。今年はSalt Lake Cityで開催されました。

自分は今年でYAPC::Asia Tokyoに一区切りが付くので、2000人規模のイベントを開催するにあたってどういうところに注意をしながら今まで準備をしてきたのか、などのノウハウをシェアするトークを発表するためと、Perl界隈の人達と旧交を温め、新しいつながりを求めて参加しました。

今年の会場はアメリカはユタ州のソルトレイクシティーです。アメリカには長いこと住んでいましたがユタ州には来たことがなく、初上陸です。ユタ州と言えばステレオタイプ的なイメージでは砂漠やモルモン教なのですが、どちらもその姿を見かける事なく若干拍子抜けでした。ソルトレイクシティーの印象は若干乾いた気候の普通のアメリカの地方都市でしたが、特筆すべき点としてはとにかくアメリカにありがちなただの平たい景色ではなく、町の後ろに雄大な山々が鎮座しているのがとても印象的で美しい景観でした。

Untitled

会場はLittle America Hotelというホテルの一階にあるレセプションルームを使って行われました。大きい500人程度収容可能な部屋がひとつあり、キーノートやLightning Talkの時はその部屋全体を使います。それ以外の時間帯ではその部屋を3分割し、100名前後の部屋を三つにしてセッションが行われていました。

Untitled

日本だと何日か続くイベントの場合はその都度帰宅するのでずっと会場にいる人は限られてきますがYAPC::NAの参加者は基本的に会場と同じホテルか、隣のホテルなどに泊まっているので三日間ずっと会場にいる人が多いです。私も会場と同じホテルに泊まったので移動はずいぶん楽でした。

DSC_0313

会場と皆さんの宿泊場所が同じせいかもしれませんが、カンファレンスはとてもリラックスした雰囲気でゆったりと進んでいきます。

YAPC::Asia Tokyoの主催者としてカンファレンス会場に来ている人達をみていつも感じてるのは「参加者の皆さんは本当に一生懸命トークを聞きにいくな」ということです。皆さん本当になるたけ多くを吸収しようと頑張っているのだとは思いますが、YAPC::NAでは参加者達は興味のあるトークの時間以外はその辺りで四方山話に花を咲かせていたり、施設内のバーでお酒を飲んでいたり、はたまた部屋で仕事をしていたりとかなりみんな自由に過ごしています。多分一日を通してずっとトークを聞いている参加者は一人としていないのではないでしょうか…?

会場に置いてあったピアノを弾いて待ち時間を過ごす人もいました。ちなみにこの方はジャズピアノを弾いていましたね。

Untitled

とは言え、ホテル内の会場という環境の違いや、このイベントの参加者の人達はそもそも交流をしに来ているという共通認識があるので知らない人に声をかけることも簡単にできるという事もあるので同じような雰囲気を期待するのは無理でしょう。それでも今年のYAPC::Asia Tokyoでもなるたけ交流が生まれるといいなと願っております。

Untitled

関係者に聞いたところこのようなホテルの施設を借りてイベントを執り行うと会期中の飲み物や軽食を合わせた状態で施設利用契約をするそうで、そのおかげで会期中はお菓子、フルーツ、コーヒー、ソフトドリンクは飲み放題、食べ放題でした。さすがアメリカ、という感じですが、イベント主催者としては「う、ここで無理矢理コストを追加されるのか… 辛そう…」と心を痛めずにはいられませんでした…

でもアメリカのレストランで食事をしているとフルーツはなかなか手に入らないので今回フルーツがあったのは個人的にはすごく助かりました!

トークの内容としては今年は比較的Perl6の話題が多かった印象があります。やはり「今年の冬に本リリースをする…かも!」という発表があったからでしょう。ちなみにあまり技術に関係ない禅の心構えみたいなトークも入っていたりして主催者達の試行錯誤がうかがえました。Docker等のコンテナ技術のトークなどもありましたが、その手の「流行り物」トークは比較的おとなしめな印象でした。イベントの性質もあるのでしょうが、ここでもやはり日本人との国民性の差が若干ですが出ている気はしました。

Untitled

また、Perlというと「ああ、あの古いヤツね」というイメージを持たれてしまうのは大変残念なのですが、古いと言うことは今では皆さんが使っている様々なツール類のルーツがPerlにあったりするのです。例えば今ではよく知られているYAMLは以下の写真のIngy氏を含む数名がスペック策定をしています。そういう人達に出会えるのも今回のように自ら海外のカンファレンスに出向いていく醍醐味のうちの一つです。

Untitled

1日目の夜はまず「ミキサー」という名称で、参加者全員が参加できるいわゆる懇親会がありました。ミキサーでは何人かの懐かしい顔を見つけたり、見つけられたり。自分の名前を聞いて「ああ、CPANにあるあのモジュール使ってるよ!」と言われたり、「おい、あの日本でPerlの新しい実装を書いてた二人は今何してるんだ」と詰問されたり(笑)色々と話ができました。

Untitled

Untitled

ミキサーの後は知り合いのツテもあったのでYAPC::NAのスポンサー向けディナーに招待されて混じってきました。ちゃんとした着席ディナー形式でちょっと面くらいましたが、普段だとあまり話さないであろう人達と話せてとても有意義でした。ちなみにこの写真の真ん中に映っている方、僕と同い年くらいかと思ったらまだ4年前に大学を出たばかりだというので多分30前です。向こうも同じ事を思っているとは思いますが「ガイジンの年わからんわー」と思いました。

Untitled

メインディッシュ!アメリカンですねー!うーん、(小声)でもこの肉はあまりおいしくなかった… (見た目もイマイチだったのでフォーカスを敢えて野菜に絞りました)

その晩は最後に近所のバーに行き、行ったところでハッカー達の集まりにありがちな色々な議論がはじまっちゃって、最終的にはプレゼンテーション(もしくな実際のコード)を見せて説明するというおきまり?な流れになってました。写真はMoose等の最初の作者であるStevan Little氏が突然「技術とアート」について語り始めた時のものです。

Untitled

二日目も粛々とカンファレンスは進みます。この日のハイライトは現在のPerl5開発の総指揮をとっているRicardo Signes氏がPerlの作者であるLarry Wall氏に一般公募した様々な質問をぶつけるQ&Aセッションでした。Larryはとにかく不思議なテンポとギャグのセンスがあり、このセッションは彼の人間的な魅力を引き出しつつ様々な彼しかしらないであろう「pack関数はNASAの宇宙計画の中で送られてくるデータの検証を行うために作られた」などのエピソードも含め過去の出来事についての説明等もしてもらえるというかなり興味深いセッションでした。

Untitled

Larryのトークに興味がある方は是非youtubeの動画をどうぞ!ちなみに最初の10分程度はLarryの声が録音できていないようです…

二日目の最後も参加者向けのディナーがありました。ブラジル出身の参加者を見つけて話していたらPerlコミュニティに長らく貢献しているWendyさんと、Perlで開発をしていたら絶対に彼のモジュールのお世話になっているDavid Goldenさんが我々のテーブルに来て一緒にディナーを楽しむ事ができました。

Untitled

ちなみにこのディナーについても主催の端くれとしては心が痛む「300人分用意したのに170人しか来なかった」という辛い話を後で聞きました… カンファレンスの主催って大変なんですよ!<宣伝>「カンファレンス運営の本当の裏側」っていう座談会をやっちゃうくらい大変です!</宣伝>

最終日の三日目、まず自分はその前日にチャリティとして購入を約束していた特製Tシャツを受け取りにいきました。これは主催の一人であるJohn Anderson(genehack)氏が腎臓癌の手術のために参加ができなくなった上手術日がちょうどこの最終日に重なるために応援の一環として有志が作成したものです。最終的にはgenehack氏が彼の選択した慈善団体にお金は寄付するようですが、とにかく応援のためのジェスチャをみんなでしたわけです。

というわけで自分も及ばずながら購入をしたのですが、それはなんと、Larry Wall氏、Perl6の主開発陣の一人であるPatrick Michaud氏、そしてPerl5のRicardo Signes氏三人のサイン入りのシャツでした。帰ったらどこかに保管しておきたいと思います

Untitled

またその後このチャリティTシャツを購入した人達で記念写真を撮りました。

Untitled

この日は自分のトークがあったのであまり聴講はせず、イメージトレーニングをしみたり、スライドの手直しをしたりしていました(16:9で作っていたのに蓋をあけてみたら4:3のモニターだったので慌てて手直しをしました…)。それでも先日知り合った縁でランチに誘ってもらったのでついていきこれまた色々な話をきかせてもらえました。一番右側の人は「シュワルツ変換」で有名なRandal Schwartz氏です

Untitled

その後自分のトークでした。技術的な内容はゼロです。どういうことを重要視しながらいままでYAPC::Asia Tokyoの準備をしてきたか、という話で、基本的にはこれからカンファレンスをやっていきたいと思っている人達向けに自分の経験をシェアしたものです。怖くて自分で録画は見ていませんが、まぁ一応言うことは言えた… と思います。

youtu.be

Twitter上では結構評判がよかったようなので、とりあえず安心という感じです。

その後Lightning Talkや最後のキーノートがあったのですが、この辺りで時差ぼけにより力尽きてしまいまともな記録がなくなってしまいました…

ともあれ、三日間たっぷりと技術に関する交流ができました。またいつか参加できればと思います。実はこの原稿はホテルの部屋で書いているので、これから帰国です。さー、また13時間かけて日本にもどるぞー!

あ、YAPC::Asia Tokyo 2015も是非よろしくお願いいたします

Shibuya English Werewolf Party vol.2

 
こんにちは!Kishi@HDEボドゲ部にぎやかし担当です。

去る2015年5月12日夜に、
第2回目のShibuya English Werewolf Partyが開催されました!

 

f:id:yuki_ks:20150515103548j:plain


台風直撃寸前の悪天候にもかかわらず、
17名の方にご参加いただきました!
ありがとうございました!

普段のボドゲ部は弊社HDEのスタッフ中心のところ、
今回は殆どが外部からのお客様のため、
どうなるのか不安もありましたが、
みなさまのお陰でとても楽しい時間になりました。
  
今回、参加者のCandyさんから
英語の振り返りと人狼以外でも使えるストックフレーズを
勉強できる時間を取ることが出来ました!
これはとても良かったです。
※Candyさんお手伝いありがとうございました:)
 

f:id:yuki_ks:20150515103619j:plain

*1*2*3*4

 
次回もできれば似たようなことができればいいなと思っています。
例えば、議論中言いたくても言えなかった言葉をメモして
ゲーム終了後に英語化する時間をとる、
あわせて、1テーブル7-8名程度にし、
議論時間をゆっくり取り英語で話す機会を増やすなどです。

SEWPは英語を学習することだけが目的ではないのですが、
参加している方のお話を聞いていると、
もう少し各々の英語を見直す時間があってもいいのかな思ってます。

もちろん、ゲームも楽しみたい!

今回も人狼ゲームが初めての方が何人かいらっしゃったので、
人狼ゲームの作戦に対する日本語レクチャーがあったら
もっと英語で人狼ゲームについて話せるし、
聞き取れるしいいかなと思いました。
これはもう少しもんでみます:)

f:id:yuki_ks:20150515111604j:plain


 
テーブルに置かせて頂いているサマリーシートも
バージョンアップ+増刷したいですね!
何かご意見やアイディアがあれば是非お願い致します:)

というわけで、次回は7月開催予定です。
弊社のグローバルインターンシップメンバーが居るタイミングで
開催したいと思います。お楽しみに!!

***以下ゲームレポート***

*1:※下記注訳の英語は、絶賛英語勉強中の筆者コメントです。

必ずしも文法的に正しくない場合があります。

また、品詞・訳の確認はWeblio英和辞典・和英辞典から引用いたしました。

*2:"I vote you"とつい言ってしまう方が多かったので、

誰かに投票するときは"vote for you"が正しいということでした。

vote:【自動詞】投票する【他動詞】票決する

*3:"I'm unbalance."「分からない!」

unbalance:【他動詞】<心の>均衡を破る【名詞】不均衡

いろいろな意見がありすぎて混乱する(=気持ちが不均衡になる)状態を表しています。

人狼意外の場面でも使えそうです。

*4:"One be (un)comfortable in what one's doing. "

uncomfortable:【形容詞】不快な←→comfortable:【形容詞】快適な

これも相手の提案について「いい」「悪い」をストレートにではなくニュアンスで返せる良いフレーズ。

続きを読む

「cloudn (クラウド・エヌ)」を使ってみました

ソリューション推進部 開発&ASPチームの大久保です。

2015/04/17 に開催された社内勉強会にて、NTTコミュニケーションズが提供するパブリッククラウドサービス「cloudn(クラウド・エヌ)」について概要を紹介したところ、AWSが大好きなはず(と勝手に私が思っている)な社内メンバーから、意外やブログで詳しく紹介してほしいというご要望を頂き、ありがたくブログを書かせて頂くことになりました。

cloudn とは?

お決まりの書き出しですみません。URLだけ紹介させてください。

www.ntt.com

使ってみる

cloudn が提供する 仮想サーバ(Compute)を使ってみました。仮想サーバには、FLATタイプ、VPCタイプ OpenNW, VPCタイプ ClosedNW の3タイプが提供されています。AWSと機能比較すると、FLATタイプ = EC2-Classic, VPCタイプ = EC2-VPC となります。今回は、FLATタイプの仮想サーバを管理コンソールとAPIを使って作成してみます。

仮想サーバを作成する

管理コンソールの操作方法についてはマニュアルに大変わかりやすく書いてありますのでこちらをご覧ください。ここでのポイントはブラウザに Firefox を使用することです。IEやChromeだと管理コンソールが正常に動作しないことがあります。ウィザードでの設定が終了してから、仮想サーバが起動するまでは 30秒~1分程度です。

3.1. 仮想サーバーを作成する — Cloudn Compute FLATタイプ 操作マニュアル v2.20.2

仮想サーバを設定する

今回、オフィシャルテンプレートの CentOS 6.5 64bit から仮想サーバを作成しました。開発やサービスで複数台の仮想サーバを作成する場合、OSの基本設定などはあらかじめ済ませた状態のテンプレートがあると便利なので、まずはテンプレートの元になる仮想サーバの設定を行います。

タイムゾーン・言語

cloudn の仮想サーバはデフォルトでは、タイムゾーンが UTC になっています。/root/tzconfigurator.sh というシェルスクリプトが用意されており、対話形式でタイムゾーンの設定が行えます。が、私はいつものやり方でささっと設定します。

タイムゾーンの設定

# cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
# cat /etc/sysconfig/clock
ZONE="Asia/Tokyo"

言語の設定

# cat /etc/sysconfig/i18n
LANG="en_US.UTF-8" -> 日本語にしたい場合、ja_JP.utf8 に変更
SYSFONT="latarcyrheb-sun16"


ネットワーク

ホスト名、iptables などささっと設定します。セキュリティグループの設定が必須なので不正アクセスされるリスクは低いですが、デフォルトだと iptables は全開放、かつ、chkconfig off という状態で起動します。かなり豪快です。

ホスト名

# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no (IPv6無効)
HOSTNAME=template.localhost.localdomain (ホストFQDNを設定)

iptables

# cat setting-iptables.sh
iptables -F
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 接続元IP/32 -p tcp -m tcp --dport 22 -j ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# sh setting-iptables.sh

# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

# chkconfig iptables on
# chkconfig --list | grep iptables
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off


時刻同期(NTP)

仮想サーバはOS停止していると時間が止まりますので、NTPを使用してサーバの時刻をあわせます。cloudn FLATタイプは 直接インターネットに接続されているので、CentOS 標準の /etc/ntp.conf でタイムサーバと通信できます。国内のタイムサーバですと、 MFEEDなどが利用できます。ntpd もデフォルトで起動しているので、タイムサーバがデフォルト設定でよければ、NTPを動作させるための設定は特にありません。

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-secure.opticner 223.255.185.2    2 u   15   64  377   13.196    9.558   6.019
*v157-7-235-92.z 10.84.87.146     2 u   24   64  377   15.089  -14.547   3.478
+c-kint.tv       133.243.238.243  2 u   17   64  377   13.842   -9.597   4.046
+x.ns.gin.ntt.ne 103.1.106.69     2 u   11   64  377   12.129  -13.728   3.157


DNS

DNSサーバは cloudn から提供されており、/etc/resolv.conf に設定されています。そのまま利用できます。


ユーザ・グループ

サーバへのアクセスポリシーは様々あるかと思いますが、私は root への昇格が可能なシステム管理ユーザを作成し、SSH では、root ログイン禁止にしています。ユーザを作成したら SSHキーも登録しておきましょう。以下、/etc/ssh/sshd_config の設定例です。

# diff sshd_config sshd_config.org
42c42
< PermitRootLogin no (rootユーザのログイン禁止)
---
> #PermitRootLogin yes
47,49c47,49
< RSAAuthentication yes (RSA公開鍵認証を有効化)
< PubkeyAuthentication yes
< AuthorizedKeysFile    .ssh/authorized_keys
---
> #RSAAuthentication yes
> #PubkeyAuthentication yes
> #AuthorizedKeysFile   .ssh/authorized_keys
66c66
< PasswordAuthentication no (パスワードログインを無効化)
---
> PasswordAuthentication yes
139,140d138
<
< AllowUsers hoge fuga (SSHログイン可能なユーザを限定)


ディスク

cloudn はルートディスクに 15GB の容量を割り当ててくれます。AWSではスワップ領域が確保されておらず、必要であればEBSにスワップファイルを作成する必要がありますが、cloudn はデフォルトで 2GB のスワップ領域が確保されています。以下、vQプランのディスクとメモリの割り当て状況です。

# df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root   13G  755M   11G   7% /
tmpfs                         246M     0  246M   0% /dev/shm
/dev/vda1                     485M   33M  427M   8% /boot

# free -m
             total       used       free     shared    buffers     cached
Mem:           490        122        367          0          6         38
-/+ buffers/cache:         77        413
Swap:         2047          0       2047

テンプレートを作成する

その他監視エージェントやら必要なパッケージやらインストールしてOS設定が完了したらテンプレートを作成します。またしてもマニュアル参照ですみません。マニュアル通りにテンプレートを作成します。

3.15. テンプレートを作成する — Cloudn Compute FLATタイプ 操作マニュアル v2.20.2

テンプレートをコピーする

cloudn をサービスで使用する場合、冗長化のために異なるゾーンにAP, DBサーバを配置します。一方で、テンプレートはゾーンごとに有効です。(ゾーン jp-e1a で作成したテンプレートを使用して、ゾーン jp-e1b に仮想サーバを作成することはできません)ですので、作成したテンプレートは各ゾーンにコピーする必要があります。

8.3. テンプレートをコピーする — Cloudn Compute FLATタイプ 操作マニュアル v2.20.2

APIを使う準備をする

cloudn は オープンソースのクラウド基盤 Apache CloudStack をベースとしたサービスであるため、APIの操作に cloudmonkey CLIを使用することができます。マニュアルにも書いてあります。マニュアルに従って cloudmonkey をインストールし、URL, apikey, secretkey を設定します。apikey, secretkey は、管理コンソールにログインした直後のページの下の方に「portal contents」>「APIアクセスキー秘密鍵管理」というメニューがあります。これをクリックすると取得できます。

1.3. APIクライアントの利用 — Cloudn Compute FLATタイプ APIリファレンス v2.20.2

今回は仮想サーバの作成/起動/停止/削除、アプリケーションのプロビジョニング、SSHログインなど何かと便利な Vagrant と cloudmonkey を組み合わせて使用します。Vagrant はこのあたりを読んでインストールしてください。

cloudmonkey と vagrant がインストールできたら、vagrant-cloudstack プラグインをインストールします(これで合体します)。

$ vagrant plugin install vagrant-cloudstack
Installing the 'vagrant-cloudstack' plugin. This can take a few minutes...
Installed the plugin 'vagrant-cloudstack (1.0.0)'!

いよいよ仮想サーバの量産体制が整いました。APIを使って仮想サーバを作成するためには以下のパラメータが必要です。

セキュリティグループID

管理コンソールの「ネットワーク」>ビューの選択「セキュリティグループ」>一覧から仮想サーバに適用するセキュリティグループをクリック>「詳細タブ」にIDが記載されています。これをメモ。

テンプレートID

管理コンソールの「テンプレート」>テンプレート名をクリック>「詳細タブ」にID(テンプレートID)が記載されています。これをメモ。

ゾーンID

cloudmonkey CLI を使って取得できます。

$ cloudmonkey list zones
count = 2
zone:
name = jp-e1a
id = 1b02e74c-6c21-4aa3-b96c-51042de8fccd
:

インスタンスタイプID

同じく cloudmonkey CLI を使って取得します。

$ cloudmonkey list serviceofferings
count = 7
serviceoffering:
name = t1.micro
id = 200c6378-8ae9-4718-9b25-b8c4f6c1dfc8
:

これで、「どのテンプレートを使って」、「どのセキュリティグループを適用して」、「どこ(ゾーン)に」、「何の(インスタンスタイプ)」仮想サーバを作るかを指定できます。

APIを使って仮想サーバを作成する

上記のパラメータがあれば、Vagrant を使ってさくっと仮想サーバが作成できます。今回ご紹介している Vagrantfile は、仮想サーバを作成し、Vagrantを実行したサーバと作成した仮想サーバ間でディスクを共有することでアプリケーションに必要なファイルを転送し、vagrant/init/setup.sh をプロビジョニング時にキックすることにより、アプリケーションのインストール・設定まで実行しているテンプレートです。小中規模のシステムであれば、ChefやPuppetなどのプロビジョニングツールを使わなくても自動化できるかと思います。Vagrantは環境変数を読んでくれるのでパラメータは環境変数に定義しています。

作業ディレクトリを作成
$ mkdir vagrant
$ cd vagrant

Vagrantを初期化
$ vagrant init

Vagrantfile を以下の通り作成する。
$ cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "dummy"
  config.ssh.private_key_path = "~/.ssh/id_rsa"
  config.ssh.username = "cmcadmin"
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.vm.synced_folder "provision/", "/home/***/vagrant"
  config.vm.synced_folder "conf/", "/home/***/vagrant/conf"

  config.vm.provider :cloudstack do |cloudstack, override|
    cloudstack.host = "comp-api.jp-e1.cloudn-service.com"
    cloudstack.path = "/client/api"
    cloudstack.port = "443"
    cloudstack.scheme = "https"
    cloudstack.api_key = "${APIKEY}" -> cloudn のアクセスキー
    cloudstack.secret_key = "${SECRET}" -> clooudn の秘密鍵
    cloudstack.instance_ready_timeout = 1800

    cloudstack.display_name = "${VM_HOSTNAME}" -> 仮想サーバの表示名(管理コンソール上に表示される)
    cloudstack.name = "${VM_NAME}" -> 仮想サーバの名前(管理コンソール上に表示される)
    cloudstack.group = "${VM_GROUP}" -> 仮想サーバのグループ(管理コンソール上に表示される)

    cloudstack.template_id = "${CLOUDN_JPE1A_TEMPLATE_ID}" -> テンプレート
    cloudstack.service_offering_id = "${CLOUDN_SERVICE_OFFERING_ID}" -> インスタンスタイプ
    cloudstack.zone_id = "${CLOUDN_JPE1A_ZONE_ID}" -> ゾーン
    cloudstack.security_group_ids = ["${CLOUDN_SECURITY_GROUP_ID}"] -> セキュリティグループ
    cloudstack.network_type = "Basic"
  end
  config.vm.provision :shell do |shell|
        shell.privileged = false
    shell.inline = "vagrant/init/setup.sh"
  end

end

仮想サーバを作成・起動する
$ vagrant up

vagrant up してからサーバが起動するまでは調子がいいと5分程度でです。アプリケーションの インストールなどを除くと、1~2分程度で仮想サーバの作成と起動が出来ているように思います。

終わりに

今回は仮想サーバの作成方法を中心にレポートしましたが、データディスクのアタッチや、DNSへの正引き・逆引きレコード登録などもAPIでできますし、VPCタイプでは、セキュアな3層モデルのウェブアプリケーションを構築することも可能です。コスト競争力もありますし、「cloudn(クラウド・エヌ)」 なかなか良いサービスではないかなと思います。

Pythonでvirtualenvの構築を自動化する

おはこんばちは!! 尾藤 a.k.a. BTOです。

pythonで開発環境を構築する時は、virtualenvを使うことが多いかと思います。 弊社のプロダクトでもvirtualenvを使って、各開発者の環境を統一しています。

そこで問題になるのがvirtualenvの構築です。 virtualenvの構築を主導でやっていると、手作業によるミスが起きやすいですし、何より最初からすることが決まっている処理は自動化したいものです。

そこで、virtualenvの環境を自動で構築するために、virtualenvのbootstrapを使用しています。

virtualenv bootstrap script を作っておけば、

% python create.py ~/.venv/your-project

みたいにして、コマンド一発でvirtualenvの構築と必要なライブラリのインストールが一発でできるようになり、各開発者の環境統一が簡単にできるようになります。

virtualenv bootstrap

virtualenvにはbootstrapという機能がついています。 bootstrapを使うと、virtualenvの構築任意の事後処理を1発で実行するbootstrap scriptを生成してくれます。 プロジェクトでbootstrap scriptを作っておけば、コマンドを1発実行するだけで、同じライブラリ、バージョンを持ったvirtualenvを構築できます。

bootstrap scriptの生成

では、どのようにしてbootstrap scriptを生成すればいいのでしょうか。 virtualenvにはbootstrap scriptを生成する機能がついています。

virtualenv.create_bootstrap_script() を呼び出すと、bootstrap script用の文字列を返してくれますので、あとはそれをbootstrap script fileに書き出すだけです。 virtualenv.create_bootstrap_script() には事後処理を実装するスクリプトの文字列を渡すことができます。

#!/usr/bin/env python

import os
import virtualenv

extra_script = open('extra.py').read()
script = virtualenv.create_bootstrap_script(extra_script)
f = open('create.py', 'w')
f.write(script)
f.close()

freeze.py

これはvirtualenv bootstrap scriptを生成するfreeze.pyです。 ここではextra.pyから事後処理のスクリプトを読み込み、create.pyというvirtualenv bootstrap scriptを生成しています。

import os

def after_install(options, home_dir):
    pip = os.path.join(home_dir, 'bin', 'pip')
    os.system(pip + ' install Fabric')
    os.system(pip + ' install boto')
    os.system(pip + ' install pep8')
    os.system(pip + ' install tornado')

extra.py

extra.pyはこんな感じでafter_installにvirtualenvインストール後の処理を書きます。 ここで必要なライブラリをインストールするようにすれば、virtualenvの構築とライブラリのインストールが一発でできるようになります。

これで準備が整ったので、freeze.pyを実行すると、create.pyを生成してくれます。

% python freeze.py

できたcreate.pyをリポジトリにコミットすれば、他の開発者にも同様な環境を簡単に構築できます。

requirements.txtを使う

pythonのプロジェクトではrequirements.txtというファイルがよく使われます。 これはただのpip freezeの出力結果なのですが、そのプロジェウトで必要なライブラリやバージョンを簡潔に表現することができます。

requirements.txtの生成は簡単です。 pip freeze の結果をファイルに書き出しましょう。

% pip freeze > requirements.txt

それでは先ほどのvirtualenv bootstrap scriptでrequirements.txtを使うようにしてみましょう。 それにはextra.pyでpip installしている部分をrequirements.txt経由でインストールするように変更するだけでできます。

import os

def after_install(options, home_dir):
    pip = os.path.join(home_dir, 'bin', 'pip')
    os.system(pip + ' install -r requirements.txt')

extra.py

これで、今後はrequirements.txtを更新するだけでよくなりました。

wheelを使う

ここまでで、環境構築の自動化がかなり進みました。 しかし、現状ではpipでライブラリのインストールを最初から行うため時間がかかってしまいます。 毎回pipサーバに取りに行くのも無駄です。 コンパイル済みのパッケージがローカルにあれば問題は一気に解決します。 そのためにwheelというものを使います。

wheelはpythonのパッケージを配布するためのフォーマットです。 wheelのパッケージはコンパイル済みのため、インストールが高速にできます。 事前にwheelパッケージを作ってローカルに持っておけば、pipサーバにアクセスせずに高速にインストールすることができるようになります。

wheelパッケージを作るのは簡単で、次のようにコマンドを実行するだけです。

% pip wheel -r requirements.txt

コマンドを実行すると、wheelhouseというディレクトリにwheelパッケージが作られます。 拡張子は.whlです。

では今度はwheelパッケージを使ってインストールするようにしてみましょう。 after_installのところで、wheelパッケージを使ってインストールするように変更するだけです。

import os

def after_install(options, home_dir):
    pip = os.path.join(home_dir, 'bin', 'pip')
    os.system(pip + ' install --use-wheel --no-index --find-links=wheelhouse')

extra.py

これでpipサーバにアクセスする必要もなくなり、インストールも高速にできるようになりました。

結論

HDEでは英語で人狼を開催します。 ご興味のある方はご連絡ください。

Shibuya English Werewolf Party vol.2 | Facebook

Terraformでクラウドを耕そう

クラウドプロダクト開発部のたなべです。

去る4月17日(金)に開催された社内勉強会 (HDE Monthly Technical Session; MTS) で Terraformについてライブデモを交えて話しました。今回はそのブログレポートです。

Terraformについての一般的な話はGoogle検索等で探してください(すみません。。)。

スライド

勉強会は基本英語なのでスライドも英語です。

スライド中に使用したデモはGithub上で公開しています。

github.com

ブランチを1から7まで用意しています。VPCに始まり、サブネット、セキュリティグループ、ルーティング、インターネットゲートウェイ、ELB、そして最後にWebサーバを起動するところまでを7ステップで試せるようになっています。

順に進めていき、ブランチ 7terraform destroy したとしても、再度 terraform apply すると一発で同じ環境が再度作成されます。再現性があるのもterraformのよいところです。

なぜTerraformなのか

Terraformをはじめて見たとき、すぐに「単なるプロバイダー非依存のCloudFormationみたいなものか」と解釈しました。

この解釈自体は間違いではありませんが、実際に使ってみるとそれ以上に「楽しい」ツールだということを実感しました。特にCloudFormationのJSONに嫌気がさしていたのもあり、もう戻りたくありません。

私がTerraformを使い出したのは現在開発中のサービスのステージング環境をAWS上に用意するためでした。 今日ではVPC以外の選択肢はないため、まずVPCを設計するところから始めました。

  • まずはネットワーク(サブネット)設計
  • 次にセキュリティグループを設計
  • おっと、ELBには専用のサブネットとセキュリティグループを割り当てたほうがよさそうだ
  • えー、インターネットゲートウェイを作成して、VPCに割り当てて…
  • あー、ルーティングテーブルのデフォルトゲートウェイをigwにして…
  • うー、RDSにはプライベートサブネットをだな…

というのを考えながらVPC全体を設計したのですが、さてこれをCloudFomationでやるのかAPIを自分で叩くのか、はたまた手順書を書くのか…そしてTerraformを思い出しました(0.3.2のころ)。

Terraform (0.4.2現在)を使うと上で設計したものをそのままコードへ落とし込めます。

  • VPCは "aws_vpc" リソースで定義
  • サブネットは "aws_subnet" リソースで ELB、バックエンド、RDSの3つでそれを各AZ向けに定義
  • セキュリティグループは"aws_security_group" リソースで定義
    • ELB向けにはサービスポートをフルオープン
    • バックエンド向けにはELB用サブネットからのみアクセスを許可
    • RDS向けにはバックエンドからのみアクセスを許可
  • インターネットゲートウェイは"aws_internet_gateway" リソースで定義。
  • ルートテーブルは"aws_route_table" リソースで定義
    • メインのルートテーブルにはigwをつけずにそのままプライベートサブネットとしておく
    • パブリックサブネット用のルートテーブルを作成し、デフォルトゲートウェイをigwに向ける
  • ルートテーブルとサブネットの紐付けは"aws_route_table_association" リソースで定義。
    • ELB、バックエンド用サブネットを上で作成したルートテーブルに紐付け
  • ELBは"aws_elb" リソースで定義。専用のサブネットとセキュリティグループをアタッチ

Terraformの使いどころと注意点

私が思うTerraformの使いどころは

  • VPCにまつわる細々としたリソース
  • ELB
  • KeyPair
  • Route53のレコード

などです。Terraformとの相性は抜群です。

一方で向いていない(あるいはより注意が必要)な部分としては、

  • RDSの管理

    terraform planでは些細な変更と思ってapplyしたらdestroyを共なう再作成が実施されてそれがプロダクションだった、みたいな話がGithubのissuesに書き込まれていました。

    github.com

    の修正で意図せずdestroyされないようにするフラグが導入されたので、0.5では回避できると思われます。

  • EC2インスタンスの管理

    プロジェクトによると思いますが、台数を動的に増減させつつ、それをELB配下に入れたりする場合、インスタンスはterraformに入れることは難しいと思います。ただ、TerraformではAutoScallingを管理できる(らしい)のでそちらで代用できるかもしれません。

    我々のプロジェクトではTerraformでVPC等を管理し、その上で動くインスタンスはすべてOpsWorksで管理しているため、EC2インスタンスはTerraformで管理していません。

  • Route53のHosted Zoneそのものの管理

    最初、Route53のHosted Zoneも"aws_route53_zone"リソースで管理していました。ステージングなのもあり、また当時はリソース単位でtaintできなかったため、EC2インスタンスを再作成するのに terraform destroy をしたところ、Hosted Zoneも消えてしまいました。消えたこと自体は問題ないのですが、ゾーンを再作成するとNSレコードが変更されるため、別部署の人に再度NSレコードを設定してもらうハメになりました。

    この件も今後 prevent_destroy フラグを設定することで防げそうです。ただし、 terraform destroy を必要とする場合はやはりHosted Zoneはidだけ変数として与えるほうがよさそうです。

Terraformの今後

TerraformはVagrant、Packer、Serf、Consul等を開発しているHashiCorp社の最新プロダクトで、個人的にはこれまでの集大成に位置付けられるプロダクトだと認識しています。

そのためか、開発は非常に活発で、次のリリースは 0.5.0 が予定されています。 ChangeLogをみると、 1つのプロバイダーに対して複数のインスタンスを設定できるようになります。これはつまり、リージョン違いのAWSリソースを持てることを意味します。まだドキュメントがありませんが、テストケースによると、以下のように書けるようになります。

provider "aws" {
    alias = "west"
    region = "us-west-2"
}
provider "aws" {
    alias = "east"
    region = "us-east-1"
}
resource "aws_instance" "foo" {
    # us-west-2
    provider = "aws.west"
    ami = "ami-4fccb37f"
    instance_type = "m1.small"
}
resource "aws_instance" "bar" {
    # us-east-1
    provider = "aws.east"
    ami = "ami-8c6ea9e4"
    instance_type = "m1.small"
}

すでにVPC設定がterraform化されていれば、別リージョンへの展開も非常に簡単になりそうです。

さいごに

Infrastructure as a Codeで進むべき道はCloudFormationにはなく、Terraformなどのツールにあると思います。 まだ細かなオプションがリソースになかったり(例えばELBでProxy Protocol有効にしたい!!でもまだない)しますが、Goで書かれているので開発に参加しやすいと思います。

これを読んでTerraformを使ってみたくなったと思います(そう願います)。しかし、残念なことに今現在は既存リソースをTerraform管理下に置くことはできません。 そのため、新規構築のタイミングがあればがんばってTerraformをねじ込みましょう!!!!

セブ島で学んだopen mindの精神

初めまして、HDE2015年度新卒入社、”日本人”の土居です。

多国籍新入社員

僕にとってのいわゆる新卒の同期*1は、今のところ11月入社で台湾人のSunnyさん、12月入社でベトナム人のAnさん、同じ4月入社でマレーシア人のShi hanさんの3人なので、新入社員*2の中では僕が唯一の日本人になります。これは去年あたりから国籍を問わない採用を進めているHDEならではの状況です。現在も以前から行っているHDE Global Internship Programに加えて、「海外出張カバン持ちインターンシップ」というユニークでグローバルなインターンシップが動き始めている最中です。

セブ送り

グローバル化に伴って、社内での英語によるコミュニケーションは今後必須ということもあり、HDEには通称「セブ送り*3」と呼ばれる語学研修制度があります。今回、僕がその対象となり、入社前の2/15から3/14までの4週間、フィリピンのセブにあるQQ Englishという学校で英語会話のトレーニングを受けてきました。先月のMTSで、セブ島で学んできたことを発表させていただいたのですが、そこで発表した内容をブログにも書くことになりました。

Offline QQ English

Skypeを使ったOnline QQ Englishに対して、現地に行って先生とマンツーマンの授業を受けられるのが、今回のセブ送り先であるOffline QQ Englishです。現地は、ちょうど乾季だったので、1ヶ月の間ほとんど雨が降らず、大変過ごしやすい天候でした。

学校は、セブのITパークという綺麗なオフィス街にあります。

f:id:doi-t:20150311130747j:plain

そこで8つのレギュラークラス*4と2つのナイトクラスの計10クラスの授業を毎日受講しました。

ナイトクラスの内容

夜のナイトクラスは自由参加のグループクラスになっていて、そこではプレゼンテーションやディベート、動画に対する感想や意見を述べるなどといったことを行います。このグループクラスでは、マンツーマンのクラスとは違って、リスニング能力に長けた先生ではなく、英語を勉強中の同じ生徒に対して詳しい説明をしたり、生徒同士でコミュニケーションを取る必要がありました。また、ディスカッションのテーマとして、各国の食、文化、習慣の紹介などの他に、人生、死、結婚、幸せ、ジレンマなど、日本語でも上手く言語化できないような話題も用いられました。

f:id:doi-t:20150313193420j:plain

Why? Why? Why?

このナイトクラスでは基本的に、先生の進行の元で、生徒が順番に自分の考えを発表していきます。上述の通り、時にいまいち説明しにくい話題を扱うため、英語を話すことに不慣れな人ほど詳しい説明を最初から諦めてしまいます。しかし、そんな時ほど先生はここぞとばかりに”Why?”を投げかけてきます。これが個人的に凄く良い訓練になりました。

例えば、「もし、5感のいずれか1つを失うならばどれを選ぶ?」という質問に対して、「味覚だ」と答えると、必ずその理由を問われます。曖昧な理由を答えると、もっと詳しく!例えば?という感じでとにかく自分の意見をはっきり説明するように促されます。

グループディスカッションの中で学んだopen mind

このWhy? -> because...の繰り返しは、非常に良い英会話の訓練になると共に、上記のような答えのない問い対する考えを、先生と生徒同士で共有する機会にもなります。人の哲学や人生観を聞くということは、相互理解の中でもとても深いコミュニケーションです。一方で、非常に繊細な部分であり、往往にして相反する意見がぶつかり合う部分でもあります。これを国籍も文化も違うグループで行うのに必要だったものがopen mindの精神でした。

自分の意見と相手の意見の両方を大切にする

open mind、すなわち相手の意見を受け入れることができる精神性をクラス内に醸成していたのが、クラスを担当している先生方でした。生徒同士の活発な意見交換ができていたのは、クラスを仕切る先生がopen mindの精神を発揮していたためでした。どの先生も、よく笑い、元気が良く、非常にポジティブであり、年齢に関わらず自分の考え、人生観をしっかりと持っていました。

その上で、自分とは全く異なる考えを受け入れ、理解するだけの精神性を持っていました。単に同意したり、異なる意見に迎合するのとは違います。常に「そのことについて、私はこう思うけれど、あなたは異なる考えを持っているのですね。」といった感じで、自分の考えも相手の考えも大事にしていたことで、相互理解に繋がる深いコミュニケーションが成立していたように思います。

f:id:doi-t:20150313205020j:plain

一週間で親友になる

生徒の中には一週間だけナイトクラスに参加して去って行く人もいます。そんな人とも、あっと言う間に相互理解が深まったのは、1日1時間程度のコミュニケーションの中で、自分の考え方を言葉を尽くして表明し合ったからでした。相手がどんな風に考えながら生き、自分の考えが相手に伝わっていると分かれば、それ以降は多少言葉足らずでも、より良いコミュニケーションを取ることができるようになりました。未熟な英語同士での会話では、特に注意して相手の言葉に耳を傾け、理解する必要がありました。そのことがむしろ相手の言葉を一旦自分の中で咀嚼する良い機会になっていたのかもしれません。

そもそも英語を使って何をするんだっけ?

日本ではあまり感じたことがなかった「はっきりと意見を述べる態度」には本当に驚かされっぱなしでした。自分と同じ年か、ずっと年下の人が、言語化可能な人生観に従って自分の意見を堂々と表明し、かつ相手の意見を受け入れるだけの精神性を兼ね備えていました。もちろん、世界中の誰もがそうであるとは限らないと思いますし、はっきりと言わない美徳は確かにあると思います。ただ、異なるものを受け入れることができるopen mindの精神性と共に、言葉を尽くして互いを表明し合うことができれば、少なくとも異なる文化、意見、哲学をより良く理解する機会が得られると感じています。セブ島には英語を学びに行きましたが、そもそも英語を使って何をするんだっけ?というところを学んで帰ってくることができたことは、自分にとって大きな収穫であったように思います。

f:id:doi-t:20150223155126j:plain

完璧な英語じゃなくて良い!

そもそも英語が得意なわけでもないのに難しい質問に英語で答えるのは、凄くハードルが高いように感じてしまいますが、ナイトクラスのもう一つのポイントは完璧な英語じゃなくて良いということでした。先生は間違えても良いからトライしてみようと促してくれますし、めちゃくちゃな英語でも一所懸命聞いてくれる人にはどうにかこうにか伝わります。何より、完璧な英語じゃなくても良いという実感が得られてからは、自分の中で英会話の敷居が一つ下がったように思います。「場数を踏めば上達する」が真であるならば、相互理解を目的にまずはトライしてみる、というのはどうでしょうか。;-)

*1:HDEのFY(Fiscal Year)は10月からということをベースに考えた場合

*2:と言っても、そもそも海外では日本のような新卒や同期という概念がないそうです

*3:「セブ島流し」とも

*4:6つのマンツーマンのクラスと、2つのグループクラス