December 19, 2015

OpenStackとAzureにDocker Swarmをかぶせてみた

どこいってもいじられる OpenStack Advent Calendar 2015 参加作品、19夜目のエントリです。 OpenStackの最前線から離れて3か月がたちました。OpenStackつながりな方にお会いするたび、マイルドなかわいがりをうけます。ほんとうにありがとうございます。仕事としては専門でなくなりましたが、ユーザ会副会長の任期はまだ残っているので、積極的にいじられに行く所存です。でも笑いながら蹴ったりするのはやめてください。 さて、毎年参加しているOpenStack Advent Calendarですが、せっかくだからいまの専門とOpenStackを組み合わせたいと思います。ここはひとつ、OpenStackとAzureを組み合わせて何かやってみましょう。 乗るしかないこのDockerウェーブに どうせなら注目されている技術でフュージョンしたいですね。2015年を振り返って、ビッグウェーブ感が高かったのはなんでしょう。はい、Dockerです。Dockerを使ってOpenStackとAzureを組み合わせてみます。あまり難しいことをせず、シンプルにサクッとできることを。年末ですし、「正月休みにやってみっか」というニーズにこたえます。 ところでOpenStack環境はどうやって調達しましょう。ちょっと前までは身の回りに売るほどあったのですが。探さないといけないですね。せっかくなので日本のサービスを探してみましょう。 条件はAPIを公開していること。じゃないと、Dockerの便利なツール群が使えません。Linuxが動くサービスであれば、Docker環境をしみじみ手作業で夜なべして作れなくもないですが、嫌ですよね。正月休みは修行じゃなくて餅食って酒飲みたい。安心してください、わかってます。人力主義では、せっかくサクサク使えるDockerが台無しです。 あと、当然ですが個人で気軽にオンラインで契約できることも条件です。 そうすると、ほぼ一択。Conohaです。かわいらしい座敷童の“このは”がイメージキャラのサービスです。作っているのは手練れなOSSANたちですが。 では、AzureとConohaにDocker環境をサクッと作り、どちらにもサクッと同じコンテナを作る。もちろん同じCLIから。ということをしてみようと思います。 今回大活躍するDoker Machine、Swarmの説明はしませんが、関心のある方は前佛さんの資料を参考にしてください。 ローカル環境 Mac OS X (El Capitan) Docker Toolbox 1.9.1 ローカル、Azure、ConohaすべてのDocker環境はDocker Machineでサクッと作ります。 また、Swarmのマスタはローカルに配置します。 いざ実行 まず、Docker Machineにクラウドの諸設定を食わせます。 Azure向けにサブスクリプションIDとCertファイルの場所を指定します。詳細はここを。 $ export AZURE_SUBSCRIPTION_ID=hoge-fuga-hoge-fuga-hoge $ export AZURE_SUBSCRIPTION_CERT=~/.ssh/yourcert.pem Conoha向けにOpenStack関連の環境変数をセットします。 $ export OS_USERNAME=yourname $ export OS_TENANT_NAME=yourtenantname $ export OS_PASSWORD=yourpass $ export OS_AUTH_URL=https://identity.tyo1.conoha.io/v2.0 次はローカルコンテナ環境を整えます。 Swarmコンテナを起動し、ディスカバリトークンを生成します。このトークンがSwarmクラスタの識別子です。 $ docker-machine create -d virtualbox local $ eval "$(docker-machine env local)" $ docker run swarm create Status: Downloaded newer image for swarm:latest tokentokentokentoken このトークンは控えておきましょう。 Read more

April 4, 2015

いきなり Terraform OpenStack Provider

Terraform 0.4でOpenStack Providerリリース 以前からOpenStack対応は表明されていたのですが、いよいよv0.4でリリースされました。 小さくはじめましょう この手のツールを試すときは、はじめから欲張ると苦労します。最小限の設定でひとまず動かすとクイックに幸せが訪れます。目標は10分。 テストした環境 Terraform 0.4 Mac OS 10.10.2 HP Helion Public Cloud OpenStackerのみだしなみ、環境変数 下記、環境変数はセットされてますよね。要確認。 OS_AUTH_URL OS_USERNAME OS_PASSWORD OS_REGION_NAME OS_TENANT_NAME 最小限の構成ファイル これだけ。Providerの設定は書かなくていいです。Terraformは環境変数を見に行きます。Resource部は、最小限ということで、まずはインスタンスを起動し、Floating IPをつけるとこまで持っていきましょう。 さあ実行 まずはterraform planコマンドで、実行計画を確認します。 $ terraform plan Refreshing Terraform state prior to plan... The Terraform execution plan has been generated and is shown below. Resources are shown in alphabetical order for quick scanning. Green resources will be created (or destroyed and then created if an existing resource exists), yellow resources are being changed in-place, and red resources will be destroyed. Read more

December 12, 2014

君はOpenStack Monascaを知っているか

このエントリーは、OpenStack (2枚目) Advent Calendar 2014の12夜目担当作品です。 Monitoring as a Service 監視をサービスとして提供するって、どういうことでしょうか。 [Monitoring] 従来の監視。担当者が事前に監視項目を定義する。静的。 [Monitoring as a Service] 監視機能をサービスとして提供する。不特定多数のユーザーが、自分の監視したい測定項目を定義し、自分の好きなタイミングでチェックする。GUIはもちろん、APIでデータ取得できる。動的。 まあ、AWSのCloudWatchみたいなものです。先に言うべきでしたね、すいません。 このMonitoring as a Service、技術的なハードルは結構高いんです。刻々と上がってくるイベントをさばき、蓄積し、APIをバシバシ叩くユーザーリクエストに応えなきゃいけない。監視というと裏方のイメージがありますが、これは、対価をいただくに値する、立派なサービスです。 そこでOpenStackのMonitoring as a Service事情はどうでしょうか。一見、それを実現できそうなCeilometerがあります。ただ、もともとCeilomerは課金のための利用情報収集をする、という生まれなので、マルチテナントで、ユーザーが自らメトリックを定義し、チェックするという使い方に向いていません。ユーザー向けというより、管理者向けなんです。 そこでMonascaの登場です。まだ正式機能ではありませんが、いずれ昇格するのでは、と個人的に期待しています。 では、アーキテクチャーを見てみましょう。 ひゃー、ワクワクしますがちょっと重いですね。特にイベントを処理するメッセージキュー、イベントを貯めるDBは工夫が要りそうです。現時点で、キューにはApache Kafka、DBにはカラムナーDBのVerticaや、時系列DBのInflux DBがサポートされています。正直、無理目のスタックです。 と思っていたら。 なんと、Monasca-Vagrantなんてものができているじゃありませんか。VagrantとAnsibleでサクっと環境を作れるとな。まじか。本当か。本当だった。1時間くらいでできた。 気をつけること 動作実績のあるわたしの環境は、MacBook Pro Late 2013 / 2.3 GHz Intel Core i7、メモリ16GB、Yosemite。 Vagrantfileを見る限り、メモリ7GBと6GBのVMを作る。ここいじって動くかは要検証。 git cloneしたディレクトリ直下にansibleのrequirementファイルが置かれるので、そこで作業 vagrant upで2つのVM、devstackとmini-monが作られる、ここは時間と帯域がいるので、スタバな人は要注意 気をつけるのはこれくらいです。レッツトライ。 年末年始休暇のお楽しみが増えましたね。 これでわたしの2014年Advent Calendarシリーズは完了です。メリークリスマス & 良いお年を。

December 9, 2014

OpenStackと長期バージョン固定

このエントリーは、OpenStack (2枚目) Advent Calendar 2014の9夜目担当作品です。 ソフトウェア、バージョン、サポート たいていのソフトウェアには、バージョンがあります。そしてそれぞれのソフトウェアには「直近2バージョンをサポートする。ユーザーがそれよりも古いバージョンを使いたい場合、ベストエフォートで対応する。サポート対象外のバージョンで不具合対応ができるかどうかは、場合による。」なんていうポリシーがあったりします。 進化著しいソフト、OpenStackでは OpenStackは現在、半年ごとにアップデートします。進化が早いです。そして公式サイトを見て分かるとおり、直近2バージョンがサポート対象です。ちょっと短いですね。長期サポートよりも新規開発を優先しているわけですが、「もうちょっと長くサポートしてくれんか」というのが人情でしょう。 でも、長期バージョン固定するとどうなるか では仮に「そのバージョンがリリースされてから3年間、同じバージョンで運用する」というポリシーでクラウドを作ったとしましょう。その間に、5〜6バージョン、進化してしまうわけですが。以下、ちょっと未来の想像です。 [とあるクラウド その1] - (Dev) 今度のシステムでAっちゅうライブラリ使いたいんだけど、OpenStackだと、サポートがLからなんだよね。 - (Ops) あー、うちの環境Jよ。 - (Dev) そうすか。じゃあ他のにするわ。 使われないクラウド。悲しい。これからOpenStackに対応したアプリやライブラリ、たくさん出てきそうなのに。 [とあるクラウド その2] - (Ops) うちはJで3年間バージョン固定、長期サポートです!! アップデート作業のために環境を止めたりしません!! - (Dev) おーいいね。決定。3年のんびりするわ。 〜3年後〜 - (Ops) 約束の3年です。長年放置したのでバージョンアップは大手術です。システム止めます!! - (Dev) いやいやいやいや、アプリも運用も、そんな準備できてないし。 リスクの先送りと大噴火。「小さな変更をこまめに行い、リスクを最小化する。人もプロセスも、アプリの作りも、変化に強くなる。」という、最近のDevOpsなりCI/CDといったトレンドとは逆のやり口です。 アップデートの仕組みに投資したほうが建設的と思う もちろん、OpenStackの開発が落ち着いてきたら、長期のバージョン固定サポートは価値が高いと思います。ただし、イノベーションを求めて活発に開発しているソフトでは、結局それはユーザーにとって不利益になるのではないでしょうか。 それよりは、アップデーターの開発、複数コントロールプレーンの平行運用の確立、アプリや運用でも対応するなど、「変化を受け入れる」ほうが建設的なのではと考える次第です。 最後に、最新のOpenStack User Surveyを紹介します。注目はBusiness Driverです。OpenStackを使う、動機です。 OpenStackのBusiness Driverとして、最もユーザーが重視しているのは、”Ability to innovate”なんですよね。 あまり変化なく、3年とか5年とか、言葉は悪いですが、塩漬けで使うような従来型システムとは、優先すべきところが違うのではなかろうかと。 メインフレームから、クライアント/サーバー、そしてWebと、テクノロジーリフレッシュの機会が、これまではありました。そろそろ、リフレッシュしてみませんか。

December 6, 2014

ハンサムOpenStack

このエントリーは、OpenStack (2枚目) Advent Calendar 2014の6夜目担当作品です。 出オチ OpenStackも人気が出て、Advent Calendarが1枚ではおさまさなくなりました。2枚目です。ハンサムです。だからハンサムOpenStackです。 こんなテーマで何か書けるんでしょうか? 何をおっしゃる、芸術とは制約から生まれるのです。 そもそも2枚目とは 「二枚目」という用語は、歌舞伎用語をもとに、江戸時代に生まれた。歌舞伎の看板は、通常は8枚から成っていた。一枚目の看板は「書き出し」と言われ、主役の名が書かれ、二枚目の看板には若い色男の役者の名が書かれることになっていた。また、三枚目の看板には道化役の名が書かれることになっていた。 「二枚目」(2013年5月28日 (火) 02:17 UTCの版)『ウィキペディア日本語版』 8枚あるらしいぞ いじってみよう 一枚目:主役:そのまま主役。「一枚看板」という用法もある。 Novaですね。主役です。 二枚目:色男:優男で色事担当 これはあとにとっておきましょう。 三枚目:道化:お笑い担当 Glanceですね。何も変なことしてないのにネタにされる。 四枚目:中軸:中堅役者 まとめ役 Cinderでしょうか。主役のNovaを活かす名脇役。 五枚目:敵役:一般的な敵役 Heatかな。はじめのCloudFormation形式ってのが気に入らなかった。HOTが出てきたので許す。 六枚目:実敵:憎めない善要素のある敵役 Ceilometerです。重いです。絶賛チューニング中です。 七枚目:実悪:巨悪 ラスボス 全ての悪事の黒幕 Neutron。でもまあ、Neutronに罪はないか。取り巻きが良くなかったのよきっと。これから良くなるよ。 八枚目:座長:元締め Swiftで決まり。ほとばしる安定感。というかAWSに依存したS3互換製品とかやめてみんなオープンなSwift互換にするといいよ。 じゃあ二枚目は? *Trove*です。若さと期待の大きさを込めてキャスティングしました。というかこれを見ても分かるとおり、当面PaaSと言えばDBaaSです。DBの構築とか運用面倒ですものね。Troveはレプリケーション機能が追加されたり、いよいよこれから本格化と思います。 2枚目のカレンダーなので、ネタ感あふれる副音声モードでお届けしました。ではメリークリスマス。

© Copyright 2019 Toru Makabe

Powered by Hugo & Kiss.