diaryこの広告は、90日以上更新していないブログに表示しています。nsx」などなど、さまざまなpluginが設定ファイルで設定できる。それをstevedoreというライブラリを用いて実現可能にしている。今回はそれの使い方について、keystoneclientのauth_pluginの読み込み部分を見ながら使い方を見ていく※注意:イマイチ良く分かっていないところがあるので、間違いや詳細が分かる方はコメントくださいkeystoneclientにauth_pluginについて(stevedoreの使用例)keystoneclientでは、認証の方法をplugin形式で実装している(Token,Password等)ので、さまざまな認証方法を選択することができる。WSGIアプリケーションのFilterでは、設定ファイルで、使用するkeystonclientで読み込むauth_pluginを設定ファイルで下記のように、指定している。**kwargs)~~~~~~~~~~~~ここでは、pluginクラスを生成して、生成したpluginクラスに設定をつっこんでます。mgr.driver~~~~~~~~~~~~~~やっとここで、stevedoreの登場です(42行目)。stevedore.DriverManagerが与えられたname(このときはpassword)に対応するクラスを探して、読み込みます。stevedoreについて先ほどまで、keytonemiddlewareとkeystoneclientを見て実際にプラグインが読み込まれる過程を見ました。ここから、stevedoreの使い方を見ていきます。)なぜそんなことができるかというと、インストール時にsetup.cfgでそのマッピングについて定義するからです。tokenがnameといいます。ここまでくれば分かるかと思いますが。namespaceとnameの組み合わせで、対応クラスがマッピングされます。passwordとすれば、読み込まれるクラスは、keystoneclient.auth.identity.generic:Passwordになります。中のentry_points.txtに同じような定義があります。例として、keystoneclientのentry_points.txtを下記に記します。keystoneclient.contrib.auth.v3.saml2:Saml2UnscopedToken表記は、違いますが雰囲気で分かると思います。囲まれている部分がnamespaceに対応し、の下に書かれている部分がnameに相当しますneutronのpluginの読まれ方ここで疑問に、思う方がいるかもしれませんが(僕は思いました)。password,tokenなどnameを使用して、entry_pointsでそのマッピング先を探すのに、設定ファイルでクラスパスを直接書いている部分があるのはなぜだろう。stevedoreは、nameにクラスパスが指定されていたらそのクラスパスのクラスを読み込むのか?例えばneutronでは、service_pluginsの指定に、フルクラスネームで書くこともnameで書くこともできます。neutron.services.l3_router.l3_router_plugin.L3RouterPluginneutronのpluginの読み込み方を調べてみたところ、こんな風になっていました。plugin_class()stevedoreは、nameにマッチするentry_pointが見つからない場合は、例外を吐くのでその例外をキャッチし、クラスパスが指定されていることを仮定し、importutilsでimportを試みてるんですね。設定ファイルのpluginに指定する値は、entry_pointのnameでも、クラスパスでもうまくいくんですね。python-oslo.db_1.0.2-1_all.debするとdebファイルが追加されています。第21回勉強会があるということで、参加しようとIronic環境をDevstackで構築しようとしたが、詰まりどころが満載だったのででデバッグの記録をメモとりあえず、Document通りに。./stack.shインストールは、うまく行った、Horizonの画面も確認できた。|+--------------------------------------+---------+--------+------------+-------------+------------------+うまく行き過ぎだとは思ってた、エラーですね。available」というエラーが。memory"」SSHPowerDriverが実行するvirshを実行した時のエラーのようだ。callback」のまま固まっている・・・・tftpサーバのアドレスが、ironic-conductorが動いているホストのIPであることに気づく、ironicノードがironic-conductorが動いているホストと通信できないといけないことに気づく。ホスト側のルーティングテーブルに、仮想L2NWの経路を、仮想ルータの外部アドレスIF経由で追加ここまできて、やっと動きました。そもそも、なぜこんなにデバッグに時間がかかったかというと、ironicのプロビジョニングプロセスをまったく調べずに実行したことが原因ですね。今回調べたところ、いろいろと制約があるなと感じました。nodeからtftpサーバにアクセスできる必要がある。現状ironic.confの設定ファイルで、tftpサーバのIPアドレスを指定するので、テナントごとにtftpサーバを分けることはできない。APIを叩ける必要があるつまり、Managementセグメントとユーザセグメントを完全に分けることはできないもし、やるならdeployフェーズのみ収容スイッチのポートのvlanを変更してアクセス可能にする等を行う必要がある。conductorから見て、nodeが所属するサブネットが被ってはいけない(routingできないから)ネットワーク周りが、結構難しいなぁという印象。Publicクラウドとして、仮想ネットワーク作り放題で、vmとベアを意識せずにポコポコプロビジョニングというのは、まだ難しいのかぁ。Ironicは少し面白そうなので、もう少し追いかけてみる。23:51IronicをDevstackでサク?っと試してみたTweet広告を非表示にするもっと読むコメントを書く2015-01-03Rack、WSGIサーバのThread処理の実装について(1)はじめに本記事では、あえてRack,WSGIサーバと言っているが、いわゆるWEBアプリケーションサーバ以外のサーバソフトウェアの実装でも共通の話題である「クライアントからの接続ー通信処理」の実装方式として、NativeThreadのパターンとGreenThreadのパターンの2つの違いを自分用に2回にわたってメモ事前知識ソケットプログラミング等で、チャットプログラム等を作ったりしたことがある人は、ご存知かもしれないが。サーバの通信処理がどのようなフローで行われるかを少しここでおさらいする。サーバソケット(通信要求を受け付けるためのソケット)を作成するサーバソケットを指定のIP(通常、0.0.0.0でどのIFのIPでも受けれるようにする)、指定のportで通信要求を待つクライアントからの通信要求をacceptするクライアントと通信路が確立される見て分かると思うが、1プロセス1スレッドでサーバを実装してしまうと、同時に1つのクライアントしかさばけないため、3と4の間で各クライアントごとにスレッド、プロセスを生成して4以降のクライアントごとの処理はスレッドやプロセスに任せるのが一般的である。0:00.00なんで最初から、ネイティブスレッドが1つ作られているんだ?と思ったけど、後述するnetstatの結果より、ipv4,v6で1つずつ接続待ちのスレッドを作っていると思われるcurlでwebappにアクセスしてみる。0:00.03Threadが2個増えた!1つが先ほどのcurlからのリクエストを担当し、もう1つは次のクライアントのためにあらかじめスレッドを作成しているものだと思われる。curlのリクエストが終了したら、1つ減った。う〜ん、もしかしたら、1つ多いスレッドは次のクライアントのためのものではないかもしれない。1の4種類のネイティブスレッドでWEBrickは実現しているようです。クライアントの処理がNativeThreadだと何がいいのかNativeThreadのスケジューリングは、OSのプロセススケージューラによってスケジューリングされるため各スレッドは、コアの分だけ同時に動くことができる。端的に言うと各ThreadがOSに認識される。そのため、先ほどのsampleプログラムであるTestAppのcallメソッドの中に、sleep(1000)などのブロック関数があっても別のクライアントに影響を与えないのだ。題材である、WEBアプリだとあまりないシチュエーションかもしれないが、各スレッドが独立して動くのでスレッド同士影響を与えないよう、スレッドセーフであることをきちんと確認する必要がある。16:37Rack、WSGIサーバのThread処理の実装について(1)Tweet広告を非表示にするもっと読むコメントを書く2015-01-01Backlogってなんぞやはじめにサーバソフトウェアの設定ファイル等でよく見かける項目であるBacklogってどういう意味なんだろうと、少し調べたのでメモを残します。Backlogapacheやnginx、memchachedなどのサーバ系ソフトウェアの設定ファイルの中で設定することが多い、このBacklogとは何なのかをここでは言及する。サーバアプリケーションがlistenしているソケットがacceptしていない、確立済TCPセッションを何個までOS側で保持するかを定義したもの。下記のようなサーバーアプリケーションがあるとする。print("ここは到達しないコード")上記のサーバアプリケーションに、5個の接続要求(telnetとかを使って)を出すと。3個目までTCPコネクションが確立され、4,5個目の接続要求は無視される。netstatで確認してみると、下記のようになる。LISTENコードを見てもらうと分かる通り、サーバ(server.py)では2回しかacceptされていないが、netstatでは下記の3つセッションが確立できていることが分かる(ESTABLISHED)127.0.0.1.52601と127.0.0.1.6001127.0.0.1.52600と127.0.0.1.6001127.0.0.1.52599と127.0.0.1.6001これは、server.pyからは2つのコネクションしか見えていないが、残りの1つのセッションはOS側で保持してくれていることが分かる、この何個のセッションをOS側で面倒見るかを定義したものがbacklogである。今回は、backlog=1でサーバソケットをlistenしているため3個目のリクエストはセッションが確立されたが4、5個目のリクエストはクライアントからSYNパケットを送っているが、サーバに無視されている。これらの挙動を図にまとめるとこんな感じになる。注目していただきたいのは下記の点ソケットキューの大きさがbacklog数ソケットキューは、サーバソケットごと(=port)ごとに作成されるaccept()システムコールが呼ばれると、確立済のTCPセッションはソケットキューから削除され、ファイルディスクリタに登録される(関連づけられる)maxconnソケットキューの長さの最大値を定義するカーネルパラメーター、128がデフォルトで定義されている。backlogでmaxconnより大きな数字を定義しても、maxconnの値が優先されます。00:11BacklogってなんぞやTweet広告を非表示にするもっと読むコメントを書く2014-12-15(付録)DevstackはどんなことをしているのかOpenStackこの記事は、Devstackはどんなことをしているのかの付録記事になっており、下記の2部構成になっております。付録1.devstackのソースを読むときに非常にお世話になったコマンドdevstackは、シェルスクリプトであり。他のファイルで定義されている関数をsourceコマンドで動的に読み込みます。そのため、簡単に関数の定義や変数の定義がある場所を調べることができないのですが、そのような場合はgrepコマンドを下記のように使うと便利です。AGENT_BINARY="$NEUTRON_DIR/neutron/plugins/ryu/agent/ryu_neutron_agent.py"付録2.ソースからインストールする際の、手順のメモ(殴り書きなので、適宜微修正をしないといけないかもしれません)注意していただきたいこと<****>は適宜自分の環境に置き換えて入力してください。確認する方が確実)dist指定があるものは、ディストリビューションのバージョンがdistに指定されているバージョンの場合だけインストール。<コンポーネントのソースディレクトリのパス>→2つのコンポーネントがtestというライブラリを使用するとするときに、1つ目のコンポーネントがバージョン0.8を使っていて、もう片方がバージョン1.2を使っている場合。1つ目のコンポーネントが最初にインストールされると、2つ目のコンポーネントでバージョン0.8のライブラリを使うことになるのでエラーが起きることがある。その解決策として作られた。stable/juno(10)openstack-dev/pbrコンポーネント→インストールオプションをsetup.cfgに書いて、setuptoolsでインストールするときにsetupメソッドをフックしてその、オプションを適用してくれるらしい。tgtadmsql_connection=mysql://<user名>:<password>@127.0.0.1/cinder?charset=utf8api_paste_config=/etc/cinder/api-paste.inirootwrap_config=/etc/cinder/rootwrap.confosapi_volume_extension=cinder.api.contrib.standard_extensionsstate_path=/opt/stack/data/cinderlock_path=/opt/stack/data/cinderperiodic_interval=60use_syslog=Truerpc_backend=cinder.openstack.common.rpc.impl_komburabbit_hosts=<rabbitmqのIP>rabbit_password=stack[BRCD_FABRIC_EXAMPLE][CISCO_FABRIC_EXAMPLE][database][fc-zone-manager][keymgr][keystone_authtoken]auth_host=<keystoneのIP>auth_port=35357auth_protocol=httpadmin_tenant_name=serviceadmin_user=cinderadmin_password=stacksigning_dir=/var/cache/cindercafile=auth_uri=http://<keystoneのIP>:35357/v2.0[matchmaker_redis][matchmaker_ring][profiler][ssl]※CINDER_DRIVER(local.conf[localrc]に指定する環境変数)に何も指定しないと、defaultという値が入るが、devstack/lib/cinder_plugins/配下にdefaultというファイルはないため、driverの設定は行われない。→servicetoken(設定ファイルで設定している)を用いて認証する。→各々のコンポーネントのユーザを作成したので、token認証をやめる。/etc/cinder/cinder.confおめでとうございます。ここまで無事たどりついたらOpenstackが動いているはずです。2014/12/15です。書慣れていないのですが、がんばります。この前、DevStackのソースを読んで、Devstackがやっていることを手作業で再現してみるということをやってみたので、Devstackが大体どんなことをやっているのか?を5つのポイントにしてまとめてみました。付録としてdevstackに沿って手作業でインストールしたときの手順書を掲載します。興味ある方はご覧くださいDevstackのソースを読むことのすすめdevstackを普段使っている方、使いたいと思ってる方はざっとでいいので、一度devstackのスクリプトを読むことをオススメします(特に初級〜中級技術者の人)理由としては、下記の点があげられます。配下に、各コンポーネントの名前(一部プロセス名)のファイルがあり、その中に、必要なパッケージファイルが羅列されています。pipのインストールと、特定のライブラリをあらかじめインストールpipは、pythonのパッケージ関連システムです。Openstackはソースコードを取得して、pipでローカルインストールします。ここからが、肝心のOpenstackコンポーネントのインストールkeystoneとかをインストールする前に共通コンポーネントをインストールする必要がある。その中でも、「requirements」「pbr」2つの共通コンポーネントは一番最初にインストールする。各コンポーネントのrequirements.txtをチェックしrequirementsコンポーネントのglobal-requirements.txtに定義されていないライブラリはないか?各コンポーネントのrequirements.txtで定義されているライブラリのバージョンはglobal-requirements.txtより古くないか?をチェックしてくれるもの。One構成を想定して各コンポーネントのライブラリ同士が悪さをしないようにするものらしい。openstack-dev/pbrコンポーネントのインストールpbrコンポーネントは、インストールオプションをsetup.cfgに書いて、setuptoolsでインストールするときにsetupメソッドをフックしてその、オプションを適用してくれるらしい。最後に、各コンポーネントに関する設定ファイルの編集。devstackのスクリプトを読むのが一番めんどくさいのがここ。neutronデモテナント用のプライベートネットワーク、サブネットの作成(dhcp有効)外部ネットワーク、サブネットの作成(dhcp無効)デモテナント用のルータの作成デモテナント用のルータのインターフェスの作成(プライベートネットワーク)デモテナント用のルータにgatewayの設定(外部ネットワーク)→外部ネットワークでは、dhcpが無効になっていることに注意。adminテナントでインスタンスを作って外部ネットワークに直接接続しても、ipが降ってこないのでssh等でアクセスすることができない。<デモテナントのgw側のIFのアドレス>)6.インストールは終了、あとは遊ぶだけ!まとめ今回、devstackがどんなことをしているのか5つのポイントにしてまとめてみましたが、ここでは、設定ファイルの編集については具体的には触れていません。いうのもopenstackの使う機能によって、作る設定ファイル、内容がまったく違うからです。devstackでは、それらに対応するためコードが複雑化しているように見えます。私はこれらの背景より、devstackでどのように設定ファイルを編集しているかを知ることはあまり意味がないと考えています。ここでは4ステップ目に「設定ファイルの編集、起動」とだけ記しています。この後に、Devstackが行っていることを手作業で再現したときの手順メモを付録(別日記)として載せますので、もう少しdevstackがどんなことをしているかを知りたい方、手作業でインストールしてみたい方は参考にしてみてください。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。