opencontrail4.0のdocker版を試してみた

Contrail

概要

opencontrail から最新のdockerが公開されたため、そちらを試してみた際のまとめとなる。
http://www.opencontrail.org/opencontrail-containers-now-on-dockerhub/

opencontrail はオープンソースとして開発がすすめられているものの、バイナリファイルが定期的に公開されているわけではない、という制限があったため、手軽に試すのが難しかった。

今回久しぶりに新規のバイナリが公開されたため、そちらを試す、というのがこのブログの趣旨になる。

※ 公開されたバイナリは4.x 系なのだが、こちらは kubernetes 連携の機能が加わっている版なので、この機能を試している。

 

インストール方法

主な手順はこちらを参照。
https://github.com/Juniper/contrail-docker/wiki/Provision-Contrail-CNI-for-Kubernetes

まず、ubuntu16.04.2 の仮想マシンを3台用意する。
※ スレーブノードでは メモリ1GB程度でも大丈夫だが、マスターは8GB程度はほしい (検証時はawsでマスター: t2.large, スレーブ: t2.micro で実施)
※※ ローカルでインストールする場合、マスターノードでは、ホスト名が名前解決できるよう、/etc/hosts を設定する必要があった


その後、以下のコマンドを順に実施していく。

(1. 共通)
# sudo service ufw stop
# sudo iptables -F
# sudo apt-get install apt-transport-https ca-certificates curl -y

# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
# sudo bash -c 'cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF'
# sudo apt-get update -y
# sudo apt-get install -y kubectl=1.7.4-00 kubelet=1.7.4-00 kubeadm=1.7.4-00 docker-engine

(2-1. マスターのみ)
# sudo kubeadm init

# mkdir -p $HOME/.kube
# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# sudo chown $(id -u):$(id -g) $HOME/.kube/config

(2-2. スレーブのみ)
# sudo kubeadm join --token (kubeadm init実行時に表示されたtoken) (マスターのIP):6443

(3. マスターのみ)
# git clone https://github.com/Juniper/contrail-docker.git -b R4.0
# cd contrail-docker/kubernetes/manifests/
# sed -i 's/10.84.13.7/(マスターのIP)/' contrail-host-ubuntu.yaml
# kubectl apply -f contrail-host-ubuntu.yaml

この後、しばらく待つと、以下のURLでContrailの画面が表示されるはずである。
https://(マスターノードのIP):8143
※ aws の場合 $ssh -L 8143:127.0.0.1:8143 -i (aws用のpemファイル) ubuntu@(マスターのIP) などで確認する
※ ID/パスワードは admin:contrail123 となる

 

f:id:aaabbb_200904:20171015032251p:plainf:id:aaabbb_200904:20171015032304p:plainf:id:aaabbb_200904:20171015032309p:plain

 

 



動作確認

以下のyaml ファイルを使用して、podを2つ作成し、お互いにping が通れば、基本的な動作は okとなる
# kubectl create -f cirros1.yaml
# kubectl create -f cirros2.yaml
# kubectl exec -it cirros1 sh
# ping (cirros2のIP) # (kubectl get pod -o wide で確認)
※ cirrosがあがってこない場合、事前にスレーブノードを再起動する必要があるかもしれない

///
(cirros1.yaml)
apiVersion: v1
kind: Pod
metadata:
  name: cirros1
  labels:
  name: cirros1
spec:
  containers:
  - name: cirros1
    image: cirros
    ports:
      - containerPort: 22
///

うまくいかない場合

以下のコマンドを使って、contrail の各コンポーネントが起動しているかどうか、を順に見ていくことになる。

# kubectl get pod --all-namespaces
# kubectl exec -it <contrail-pod-name> -n kube-system -- contrail-status

※ 上手くいった場合、以下のように、各コンポーネントが active の状態になる。
root@ip-172-31-3-97:~/contrail-docker/kubernetes/manifests# kubectl exec -it contrail-controller-8hshr -n kube
-system -- contrail-status
== Contrail Control ==
contrail-control: active
contrail-named: active
contrail-dns: active
contrail-control-nodemgr: active
== Contrail Config ==
contrail-api: active
contrail-schema: active
contrail-svc-monitor: active
contrail-device-manager: active
contrail-config-nodemgr: active
== Contrail Config Database==
contrail-database: active

== Contrail Web UI ==
contrail-webui: active
contrail-webui-middleware: active
== Contrail Support Services ==
zookeeper: active
rabbitmq-server: active (disabled on boot)

root@ip-172-31-3-97:~/contrail-docker/kubernetes/manifests# kubectl exec -it -n kube-system contrail-agent-n4x
p5 contrail-status
== Contrail vRouter ==
contrail-vrouter-agent: active
contrail-vrouter-nodemgr: active


※ ログ確認が必要な場合、(主に) 以下で確認
# kubectl exec -it <contrail-pod-name> -n kube-system bash
# tail -n 100 -f /var/log/contrail/*

 


まとめ

Contrail は、MPLSベースのVPN をオープンソースのみで動かせるようにした仕組みとなる。
※ 類似の仕組みについては以下、等を参照
https://forums.juniper.net/t5/Routing/Dymanic-GRE-Tunnel-VPN/td-p/92212
https://tools.ietf.org/html/draft-marques-l3vpn-end-system-07

上記の性質から、BGP(inet-vpn, evpn含む)にも対応しているので、ルーターと直接経路をやりとりし、GRE接続を張ることも出来る。

慣れるまで少々分かり辛いが、強力な割に使い方そのものはさほど難しくないので、この機会にトライしてみてもよいのではなかろうか

Jupyterベースでのアラート対応

Jupyter

execjson/applconn の実装を進めていくと、どうしても、間で人間の判断が必要な部分が出てくる。
こちらを上手く扱う方法を探していたのだが、最近Jupyter を使うのがよいのではないか、と思うようになった。
※ Jupyter についてはこちらなどを参照。
http://enakai00.hatenablog.com/entry/2016/04/22/204125
https://github.com/tnaganawa/jupyter-it-automation-notebook


この場合、フローとしては以下となる。
1. アラート発生
2. オペレーターがJupyter notebookを開く
3. 必要な作業をセルごとに実行
※ 現実的には、どうしても置き換えられない作業は、、ステークホルダー(サービスマネージャーなど)の判断をあおぐような場合だろうか。

また、アラートとnotebookのurlを紐付けておけば、アラート発生時に、自動でnotebookのurlにリダイレクトすることも出来る。
https://github.com/tnaganawa/open-alert-url

上記を踏まえると、アラート発生時の対応で間に人の判断が入るような場合には、Jupyterのセルの単位で区切って実装を進めていく、というのが一つの方法になるのではないかと思われる。

Docker上にOpenShotを導入して動画編集をしてみた

Linux

openshot (http://www.openshot.org/) はLinux上でも動く動画編集ソフトで、作ったogvファイルの連結、等が出来る。

openshot のような動画編集ソフトは、エンコードのライセンスの関係、等により、通常のcentosレポジトリには含まれていないものが多い。
このため、インストールしようとすると個別のyumレポジトリを定義する必要があるのだが、それをやると依存解決が煩雑になるため、可能であれば、vmやcontainer等に導入したかった。

今回は、上記ソフトウェアをdocker container上にいれて、動画編集を試してみた。
※ 2つのogv動画の連結、までは試したのだが、3D等の機能は試していないので、全ての機能がcontainer上で動くか、は未検証

インストール手番は以下となる。
※ Dockerfile形式で記述しているが、個別にコマンドを実行していっても作成は可能
///
FROM centos
RUN yum -y install openssh* epel-release xauth && sshd-keygen && rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm && yum -y install openshot ladspa ipa*fonts && yum install -y mlt-ffmpeg
CMD ["/bin/bash", "-c", "/usr/sbin/sshd; bash"]
///

この後、
$ sudo docker run -it (image-id)
で、該当containerを起動した後、
$ ssh -X ip
でログインし、(事前に適当なユーザーを作成し、パスワードを設定しておく)
$ export LC_ALL=C
$ openshot
で、openshotが起動した。

運用ツール図を完成させるには

execjson applconn

execjson / applconn 作成の経緯となった図について、まとめておこうと思う。

現状、ITILに準拠した ITオペレーションは、様々なソフトウェアによって、補助されながら実施されているが、環境によっては、導入されているツールの数が不足したりしていて、十分な自動化が進められないケースがある。

この場合、まずどのようなツールを導入するか、を確認し、それらの構築を進めていく必要があるのだが、それをまとめた図が以下になる。

f:id:aaabbb_200904:20170503072310j:plain


逆に、これらをオープンソースのみで達成できるようにしておけば、どんな環境であっても、ひとまずツールの問題は、解決できるものと考えられる。

上記について、オープンソースで対応するソフトウェアを追記した図は、以下となる。

f:id:aaabbb_200904:20170503072355j:plain
当時は、
 - ユーザー入力を、APIからアクセス可能にする仕組み
 - APIからの情報取得、更新が可能な構成管理DB(出来れば、検索、接続関係の可視化、も)
の2点が不足していたため、それぞれに対応するものとして、 execjson / applconn の作成に至った、という経緯になる。

現在の状況についてだが、上記2点については、あまり変化がない、、というより、上記2点については、他の部分と比べて環境依存が強い (それぞれサービスカタログ、CMDBの定義に対応) ので、個別に作り込む必要がある、部分になっていると思っている。

その意味では、'ソフトウェア開発のスキルがある、インフラエンジニア' の重要な仕事は、上記2点の実装、ということになるのではなかろうか。

Contrail: Linux as an SDN enabler

Contrail

前回、前々回の続きとなる。

前々回の記述の通り、Contrailを使うと、IPファブリックの下にセグメントを定義することが出来るが、
これを使うと、まず、VLANが不要となる。(セグメントは仮想ネットワークとして、Contrail内で定義)

これ以外に、ファイアウォール、ロードバランサー、の機能は、Openstackのセキュリティポリシー, ロードバランサー、でそれぞれ提供できるようになり、
DNS/DHCPについても、Openstack内で提供されているものについては、Contrailの一機能として提供できるようになる。
※ PC用、等については、別途AD等を構成する必要はあるかも知れない
セキュリティポリシー:
http://www.juniper.net/documentation/en_US/contrail3.1/topics/task/configuration/creating-policies-juniper-vnc.html
ロードバランサー:
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/task/configuration/lbaas-contrail3-F5.html
DNS:
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/task/configuration/configure-dns-vnc.html
このため、現在ハードウェアで提供しているネットワーク機能の大半を、ソフトウェアで提供できるようになる可能性がある。

このことにより、企業内のネットワークはContrailを適用することで、
複数のハードウェアが点在する複雑なものから、
スイッチとサーバー(及び、WAN接続用のルーター)のみで構成される、単純なものに変化するのではなかろうか。

また、Contrail内の操作はOpenstack API、及びVNC APIの組み合わせで、基本的に、実施出来るように作られている。
http://www.juniper.net/techpubs/en_US/release-independent/contrail/information-products/pathway-pages/api-server/
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/task/configuration/neutron-perform-improve-vnc.html
このため、Contrail上で実施されているオペレーションは、上記のAPIを使用することで、直接、プログラムへの移行が可能となる、はずである。

SDNというワードがあるが、
https://en.wikipedia.org/wiki/Software-defined_networking
上記から、
 ネットワークの構成要素をソフトウェア化し、Contrail Controllerにこれらの設定を集中させ、更にController操作にAPIを持たせた
ことで、Contrailは、元のワードの定義のかなりの部分を満たしている、と思っている

 

Contrail: Linux as an NFV orchestrator

Contrail

前回の続きとなる。

前述の通り、Contrail はNeutronプラグイン/kubernetes network として使用可能だが、
これ以外にサービスチェイニングについても強力な機能を持っている。
http://www.opencontrail.org/why-mplsbgp-vpn/

通常、複数のネットワークサービス(DPI, Firewall, NATなど)を使用する場合、
それぞれのNFに、IPでのルーティングを設定し、順番にパケットを通していく。
※ VNFが複数のサーバーに分散する場合、対向のスイッチと vlan trunk接続等を構成する必要もある
サービスチェイニングの場合、これとは違い、IPルーティング以外の方法を使って、次の行き先を指定する。
https://docs.openstack.org/draft/ja/networking-guide/config-sfc.html
このため、NFの順番の入れ替え、サービスの抜き差し、等が比較的簡単に実施できる。
※ 普通のIPルーティングの場合、IP、およびルーティングの変更が必要、、

Contrail の場合、元々MPLSを使って行き先を指定しているので、
管理コンソールから適切なポリシーを割り当ててやれば、そのままサービスチェイニングが実施できる。
また、MPLSをGRE上で飛ばすので、vlan等を工夫する必要もない。

サービスチェインの設定方法については、以下を参照。
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/task/configuration/service-chaining-example-ui.html


また、複数のNFを使ったサービスチェインにも対応しており、以下の2つが実施可能である。
 1. 複数のNFを順番に挟む場合
 2. 同じ種類のNFを負荷分散(ECMP)しながら挟む場合
こちらも、Contrail の管理コンソールから指定可能である。
実施方法については以下を参照。
1. youtube video (2分30秒から)
https://www.youtube.com/watch?v=wDRQq0pmln4
2. Service Chain with Equal-Cost Multipath in Active-Active Mode(1つのServiceInstanceで、複数のport-tupleを指定)
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/concept/service-chain-port-tuple.html

上記の仕組みから、ContrailはNFV orchestrator として、非常に強力なものとなっている。
単独のKVMと、linux bridge、及びvlanを駆使して上記と似た動作を再現することも出来なくはないが、
ある程度VNFの数が多い場合には、上記の構成を取った方が安定するのではなかろうか、、

Contrail: Linux as an MPLS router

Contrail

Contrail (http://www.opencontrail.org/) の日本語情報が少ない気がするので、ブログにまとめておく。

Contrail を一言でいうと、
 LinuxをMPLSルーター化するもの(GRE経由フルメッシュ)
で、主な用途としては、
 IPファブリックの下の何か(現実的にはOpenstackかKubernetes)、にセグメントの概念を提供する
だと思っている。

もう少し詳しく言うと、
元々サーバー数が増えてきて、IPファブリック (例としてはこちらを参考: https://www.janog.gr.jp/meeting/janog38/program/clos.html) を導入した際、ラック間で同じセグメントを共有することが出来ない、という制限が発生するようになった。
これは、アプリケーションによっては問題にならないものの、現実的には、'セグメントごとのアクセスポリシーを定めたい'、などの理由から、やはり同じ種類のサーバーは同じセグメントにまとめたい、という際に問題になる。

対応としては、VLANのような、セグメントを限定する情報を、IP上でencapsulateする方法が必要となる。

一つの方法としては、VXLANを使う方法がある。(VTEPは、スイッチ/サーバー、どちらもあり得る。)
スイッチの場合:
http://www.networkers.fi/blog/juniper-qfx-ip-fabric-and-vxlan-part-2/
サーバーの場合:
http://docs.openvswitch.org/en/latest/faq/vxlan/

もうひとつの方法として、MPLSを使った方法がある。こちらは、元々MPLSが使われていることが多い、SPネットワークでよく使われる。
https://techblog.yahoo.co.jp/infrastructure/evpn/

Contrailは後者の方法を採用したもので、kernelモジュール 'vrouter' を使い、出ていくトラフィックにMPLS情報を付与して、行き先のハイパーバイザに送る、という仕組みである。(行き先のハイパーバイザの情報は、コントローラー経由で各ノードに共有しておく)
構成図はこちら。
http://www.opencontrail.org/wp-content/uploads/2014/10/Figure01.png
http://www.opencontrail.org/opencontrail-architecture-documentation/

メリットとしては、デフォルトのopenstack ml2プラグインや、kubernetes と比べた場合はかなり明確で、
 l3で行き先を決めるので、ネットワークノード(スケールアウト不可)を持つ必要がない(ml2プラグインと比べて)
 マルチテナントが使用可能(kubernetesデフォルトと比べて)
となる。

kubernetes integrationの例はこちら。
https://www.mirantis.com/blog/kubernetes-openstack-multi-cloud-networking/

vlan+vxlan の構成に比べたメリットは、、vlan数の限界(4096)の影響を受けない、等はあげてもよいだろうか(環境によっては、アクセスポリシーの一括管理、等も挙げられるかもしれないが、execjson+applconnでも何とか出来ないことはない)

とはいえ、総じて、大規模なIPファブリックを組む環境であれば、一度検討してみてもよいのではなかろうか。

更に詳しく知りたい場合は、こちら
https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=9687
https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=9897