Tungstenで、よく確認するソースコード
schema-transformer
tungsten の動作を確認する上で、よく確認するソースコードをあげていこうと思う。
個人的に一番よく眺める、と思っているファイルは、schema-transformer 内の以下のファイルになる。
https://github.com/Juniper/contrail-controller/blob/master/src/config/schema-transformer/config_db.py
schema-transformer は、controller のなかで動いているプロセスの一つで、webui 等で指定される値と、実際にcontrail-control, vrouter 等で使用される値の間の変換を行っている。
例えば、neutronの中で、2つの仮想ネットワーク(以下、VN) 間の間の通信を許可するとき、ポリシー、ルーターなどの要素を作成して、VN間の通信を許可することになる。
ポリシー、ルーターについては、tungsten の中にも同じような設定が存在しており、こちらはcontroller の中で動いているcassandra の中に、一旦情報が保管される。
ただ、実際にcontrail-control が上記をvrouter に伝えるときには、上記の指定は、route-target の指定を使ったものに変換されている。
※ 具体的には、ポリシーは、それぞれのVNが持っているルートターゲットをお互いにインポートしあい、ルーターは、ルーターが持つ共通のroute-target に対して、各VNがroute-target のexport/import を行う、という実装になっている
上記のような変換を行う仕組みが、schema-transformer となっている。
このため、schema-transformer の動作を追うことで、tungsten の uiから指定した値がどのように使われているか、等を確認することが出来る。
※ 例として、ルーターをVNに接続した際の処理はこちら
https://github.com/Juniper/contrail-controller/blob/master/src/config/schema-transformer/config_db.py#L4165
schema-transformer は、通常のポリシー、ルーター以外に、サービスチェインを設定したときの動作も扱っている。
例えば、transparent, in-network, in-network-nat で、どのような違いがあるか、等を確認してみると、おもしろいのではなかろうか。
device-manager
device-manager は、controller の中のプロセスの1つで、物理ルーター、物理スイッチ等に、netconf で設定を投入するプロセスになる。
ソースコードの場所はこちらになる。
https://github.com/Juniper/contrail-controller/blob/master/src/config/device-manager/device_manager/plugins/juniper/juniper_conf.py
https://github.com/Juniper/contrail-controller/blob/master/src/config/device-manager/device_manager/plugins/juniper/mx/mx_conf.py
以前紹介した例だと、vMXを外部ルーターとして設定する場合に、以下のようなコンフィグを投入したのだが、この辺りの処理は、こちらのロジックで動いている。
https://github.com/tnaganawa/contrail-k8s-tutorial/blob/master/vmx-config/vmx-config
例えば、仮想ネットワークに'Extend To Physical Router'を設定すると、VRFの作成と、import/exportポリシーの設定が行われるのだが、その辺りの処理はこちらになる。
https://github.com/Juniper/contrail-controller/blob/master/src/config/device-manager/device_manager/plugins/juniper/mx/mx_conf.py#L247
device-manager には、上記の機能以外にも、BGPの設定を行ったり、ToRスイッチの設定を行う、といった機能もある。
https://github.com/Juniper/contrail-controller/tree/master/src/config/device-manager/device_manager/plugins/juniper/qfx
いろいろと眺めてみるとおもしろいのではなかろうか。
svc-monitor
svc-monitorも controller の中のプロセスの1つで、contrail webui等から設定された値を元に、各種の処理を行う部分になる。
こう書くとschema-transformer とあまり変わらないのだが、実際には svc-monitor では、schema-transformer とは扱う対象が異なっている。
http://juniper.github.io/contrail-vnc/architecture.html
よく出てくる項目としては以下がある。
- load balancer の設定時 (openstack lbaas, k8s service/ingress 等から設定) にhaproxy の立ち上げ等を実施
- snat router の設定時に iptables MASQUERADE のルールを設定
ソースコードの場所でいうと、load balancer 設定時の動作は、以下の場所となる。
https://github.com/Juniper/contrail-controller/tree/master/src/config/svc-monitor/svc_monitor/services/loadbalancer/drivers
例えば、haproxy の設定ファイルは、以下のようなロジックで作成されている。
https://github.com/Juniper/contrail-controller/blob/master/src/config/svc-monitor/svc_monitor/services/loadbalancer/drivers/ha_proxy/haproxy_config.py
また、router にsnatを設定した際は、compute上に linux namespace が作成され、iptables の MASQUERADEが設定されることによって、snat が実施されるのだが、その辺りの制御も、svc-monitorが担当している。
https://github.com/Juniper/contrail-controller/blob/master/src/config/svc-monitor/svc_monitor/snat_agent.py#L138
実際にcompute上で作成されるnamespace は以下で指定されているらしい。
https://github.com/Juniper/contrail-controller/blob/master/src/vnsw/opencontrail-vrouter-netns/opencontrail_vrouter_netns/vrouter_netns.py#L106
