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枚目のカレンダーなので、ネタ感あふれる副音声モードでお届けしました。ではメリークリスマス。

September 14, 2014

OpenStackのツール環境をImmutableに整える

タイトルは釣りです すいません。でも、日本のどこかに、わたしを待ってる、理解し合える人がいらっしゃると思います。 なぜ必要か? いけてるOpenStackerは、相手にするOpenStack環境がオンプレであろうがパブリッククラウドであろうが、すぐにコマンド叩いて「なるほどこの環境は。。。ニヤリ」とできるものです。そういうものです。 やりたいこと OpenStack CLIなどのツールを詰め込んだ環境を、必要な時に、すぐ使いたい・作りたい Windows、Macどちらでも同様の環境にしたい 相手にするOpenStackがオンプレでも、パブリッククラウドでも、また、ツールがぶら下がっているネットワーク環境の違いも、設定やスクリプトで吸収 Windows、Mac環境を汚さない、また、汚されない コマンド2、3発程度で、気軽に作って消せる VMできたらすぐログイン、即OpenStack CLIが使える 方針 OpenStackの各種ツールを動かすOSはLinuxとし、VM上に作る VagrantでWindows/Macの違いを吸収する VMイメージをこねくり回さず、常にまっさらなベースOSに対し構成管理ツールでプロビジョニングを行う 構成管理ツールはAnsibleを使う(本を買ったので、使いたかっただけ) 前提条件 Windows 8.1 & VMware Worksation 10.0.3 OSX 10.9.4 & VirtualBox 4.3.16 Vagrant 1.6.5 (VMware用ライセンス買いました) ひとまずOpenStack CLIを使えるところまで作る ではVagrantfileを見てみましょう これがわたしが作ったVagrantfileです。見ての通りですが、以下に補足します。 VMwareとVirtualBoxでなるべく環境を合わせるため、opscodeのBentoで、事前にboxファイルを作ってます。ubuntu14.04としました。 実行ディレクトリにprovision.shを置きます。 provision.shでubuntuへansibleをインストールし、追って入れたてホヤホヤのansibleで環境を整えます。 実行ディレクトリ内のansibleディレクトリに、ansibleのplaybook(site.yml)と変数定義ファイル(vars/env.yml)を置きます。 hostsファイルには以下のようにlocalhostを定義します。 [localhost] 127.0.0.1 ansible_connection=local provision.sh解説 ansibleのインストールとplaybookの実行。playbookの実行が回りくどい感じなのは、Vagrantのフォルダ同期機能でパーミッションが正しく設定できなかったゆえのワークアラウンドです。 playbook(site.yml)解説 varsディレクトリ配下に、環境変数を定義したenv. Read more

September 6, 2014

Vagrant-hpからVagrant-openstack-pluginへ

ツールやSDKはボチボチ集約したほうが これまでHP Public CloudむけのVagrantは、vagrant-hp plug-inを使ってました。でも最近、より汎用的で開発が活発なvagrant-openstack-pluginへ鞍替えを画策しております。そろそろOpenStackのツールやSDKは、スタンダードになりそうなものを盛り上げた方がいいかな、と思っていたところだったので。 多様性はオープンソースの魅力ですが、選択肢が多すぎるとユーザーは迷子になります。OpenStackのアプリデベロッパーは増えつつあるので、そろそろコミュニティでツールやSDKの集約を考える時期かなあ、と。 さて、このPlug-in、あまり情報ないので、使用感をまとめておきます。 前提条件 Vagrant 1.6.3 vagrant-openstack-plugin 0.8.0 HP Public Cloud (2014/9/6) プラグインのインストールと前準備 Githubを見て、プラグインのインストールとboxファイルの作成を行ってください。boxファイルがない状態でvagrant upすると怒られます。 ではVagrantfileを見てみましょう これがわたしが作ったVagrantfileです。見ての通りですが、以下に補足します。 フレーバーとイメージ名は正規表現で指定できます。 OpenStack CLI群と同じ環境変数を使ってます。 Floating IPは":auto"指定にてVMへ自動割当できますが、IPは事前に確保しておいてください。 で、ふつーに動きます。乗り換え決定です。 スナップショット便利 vagrant-hpでは使えなかったはず。こいつは便利だ。 $ vagrant openstack snapshot -n lab01_snap ==> default: This server instance is snapshoting! ==> default: Snapshot is ok

May 6, 2014

いま最も楽にIcehouse環境を作る方法

あえて言おう、これは甘えであると 現時点でもっとも楽にIcehouse環境を構築できる方法だと思う。所要時間、約30分。 では始めましょう。OpenStack Cloud Computing Cookbookの著者が提供しているツールを使います。使うのはVagrant、VirtualBox、Git。 ほんと、これだけ Vagrant、VirtualBox、Gitが入ってること、バージョンと大まかな手順をこのページで確認 $ vagrant plugin install vagrant-cachier $ git clone https://github.com/OpenStackCookbook/OpenStackCookbook.git $ cd OpenStackCookbook $ git checkout icehouse $ vagrant up 何度か管理者パスワードを入力 $ vagrant ssh controller $ . /vagrant/openrc $/vagrant/demo.sh 以上。Horizonコンソールは http://172.16.0.200/ から。 この環境だと30分でできた Vagrant 1.5.4 VirtualBox 4.3.10 Macbook Pro 2.3GHz クアッドコアIntel Core i7/メモリ16GB/SSD512GB デモや新機能の試用くらいであればこれで十分ですね。 著者に感謝。わたしは買いました。 – OpenStack Cloud Computing Cookbook Second Edition(Amazon.co.jp)

May 1, 2014

OpenStack超入門シリーズ 初期3部作完結

よく聞かれることをまとめました ひとまず、初期3部作完結。また書くかもしれません。 OpenStack超入門シリーズ いまさら聞けない Novaのディスク周り OpenStack超入門シリーズ いまさら聞けない Swiftの使い方 OpenStack超入門シリーズ いまさら聞けない Neutronの使い方

March 27, 2014

OpenStack超入門シリーズ

基本的な質問が増えてきた OpenStackerというと、これまではOpenStack環境を「作る」人が多かったわけですが、最近「使う」人が増えてきた気がします。なぜかというとユーザー・デベロッパー目線での基本的な質問が増えてきたからです。これはいい傾向。 よく聞かれることはまとめておこう もちろん気軽に質問していただきたいのですが、ググってすぐ見つかったほうがいいので、今後、よく聞かれることは資料にまとめておこうかと思います。 第一弾 OpenStack超入門シリーズ いまさら聞けない Novaのディスク周り

March 23, 2014

OpenStack Swiftへのファイル分割アップロード

Swiftへ、ファイルを分割してアップロードできる 今週偶然にも、何度か質問されたり、TwitterのTLにこの話題が流れてたり。もしかしたら世の関心が高い話題かもしれないので、まとめておきます。 アップロード形式は大きく3つ – そのまま、DLO、SLO そのまま、ファイルに手を加えずにアップロードします。この場合、ファイルサイズの上限は5GBです。5GBを超えるファイルをアップロードする場合、後述のDLO、SLOどちらかの形式でファイルを分割する必要があります。 DLO(Dynamic Large Object)形式。ファイルを任意のサイズに分割し、Swift上で1つのファイルに見せかけます。「指定のコンテナ/疑似フォルダ下にあるファイルを結合する」というルールなのでアップロード手順がシンプルです。また、後からのセグメント追加/削除が容易です。 SLO(Static Large Object)形式。ファイルを任意のサイズに分割し、Swift上で1つのファイルに見せかけます。分割セグメントファイルのハッシュ値をリストした、マニフェストファイルの作成が必要です。Swift上でハッシュのチェックが行われるため、データの完全性がDLOより高いです。また、セグメントを任意のコンテナに分散できるため、負荷分散の手段が増えます。 動きを見てみよう 環境は以下の通り。 HP Public Cloud US-West Region Swift Clientを動かすCompute Node – standard.large / ubuntu 12.04 Swift CLI – 2.0.3 約900MBあるubuntu desktopのisoファイルをアップロード そのままアップロード $time swift -v upload mak-cont ./ubuntu-13.10-desktop-amd64.iso --object-name non-seg.iso No handlers could be found for logger "keystoneclient.httpclient" non-seg.iso real 0m24.557s user 0m12.617s sys 0m11.197s ハンドラーが無いとか怒られましたが、別事案なので気にせずにいきましょう。そのまま送ると、25秒くらい。 $curl -H "X-Auth-Token: hoge" -I https://region-a.geo-1.objects.hpcloudsvc.com/v1/fuga/mak-cont/non-seg.iso HTTP/1.1 200 OK Content-Length: 925892608 Content-Type: application/x-iso9660-image Accept-Ranges: bytes Last-Modified: Sun, 23 Mar 2014 01:16:53 GMT Etag: 21ec41563ff34da27d4a0b56f2680c4f X-Timestamp: 1395537413. Read more

February 2, 2014

Transparency is Noisy

雑音が多いのは透明性の裏返し 秘密裏に開発し、ある日突然リリースする。いわゆる不言実行。 いっぽうで、みなで仕様を議論し、期限を定めて開発する。その過程を公開。こっちは有言実行。 有言実行は、叩かれやすいんです。雑音も多く生まれます。でもそれは、オープンである裏返し。 答えを出すのは、ユーザーとデベロッパーです。安全地帯にいる、外野ではありません。 元記事は、ここ。

© Copyright 2019 Toru Makabe

Powered by Hugo & Kiss.