OpenShift Container Platform 4.13: Any Platform インストールした際の失敗メモ
自宅ラボに、OpenShift4.13をインストールした際に詰まった箇所のメモを残しておく。 若干構成等を変更したが基本以下の参照資料と同じ。
参照資料
https://docs.openshift.com/container-platform/4.13/installing/installing_platform_agnostic/installing-platform-agnostic.html
https://github.com/team-ohc-jp-place/OpenShift-ADP/tree/4.11/AnyPlatform
https://qiita.com/loftkun/items/03ca887ace88ef10496f
https://rheb.hatenablog.com/entry/openshift41-baremetal-upi
大別して4点。
一点目: iPXEスクリプトに不備があった
参照資料にあるように、iPXEスクリプトを作成してインストールを開始すると iPXEのブートメニューは表示されるが、master又はworkerを選択すると"Could not boot image: No such file or directory No more network devices" と出力され、ファイルの取得が開始しなかった。
bootstrapノードは正常にインストールが出来たのに、何故かmasterとworkerのみ失敗するという状況。 bootstrapは正常にインストールが出来ること、nginxのログにGETが来ていないことから、被疑箇所はiPXEスクリプトだと思い間違いがないか調べたが、一見問題ないように見えた。 しかし、根気強く確認していくと、:master や :worker の後ろに全角スペースが含まれていることに気がついた。
:master <--- ★ここに全角スペースがあった kernel http://bastion01.ocplab.test:8008/rhcos-4.12.17-x86_64-live-kernel-x86_64 ip=dhcp rd.neednet=1 console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=sda initrd=rhcos-4.12.17-x86_64-live-initramfs.x86_64.img coreos.live.rootfs_url=http://bastion01.ocplab.test:8008/rhcos-4.12.17-x86_64-live-rootfs.x86_64.img coreos.inst.ignition_url=http://bastion01.ocplab.test:8008/master.ign initrd http://bastion01.ocplab.test:8008/rhcos-4.12.17-x86_64-live-initramfs.x86_64.img boot :worker <--- ★ここに全角スペースがあった kernel http://bastion01.ocplab.test:8008/rhcos-4.12.17-x86_64-live-kernel-x86_64 ip=dhcp rd.neednet=1 console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=sda initrd=rhcos-4.12.17-x86_64-live-initramfs.x86_64.img coreos.live.rootfs_url=http://bastion01.ocplab.test:8008/rhcos-4.12.17-x86_64-live-rootfs.x86_64.img coreos.inst.ignition_url=http://bastion01.ocplab.test:8008/worker.ign initrd http://bastion01.ocplab.test:8008/rhcos-4.12.17-x86_64-live-initramfs.x86_64.img boot
全角スペースを削除すると、masterもworkerもインストールが進行するようになった。 基本的なことだが、適当にコピペしてるとこうなるので注意。 エディタの拡張機能等で全角スペースの可視化やファイル保存時に自動でスペース削除するようにすると同じミスはしないと思う。
二点目: firewalldで必要なportを開放していなかった
masterとworkerのインストールが進行すると、以下の画像にあるようにエラーが延々と出力されて詰まった。
ログやパケットキャプチャを確認して気づいたが、firewalld にてポート(22623)が開いてなかった。
初歩的だけど、ありがちなミス。まあこれは大したことない。
三点目: アドレス重複
以下のように、PXEブートが失敗した。
何度か試行錯誤している内に発生した事象。
少し前まではここで詰まることはなかったので、不思議に思いつつ調べてみるとdhcpdによりノード指定したIPアドレスが別のノードに割り当てられていたのが原因だった。
アドレスのリース状況は、/var/lib/dhcpd/dhcpd.leases で確認できる。
四点目: オペレータがFalse
インストールも大詰めの所で、以下を実施したら失敗した。 調べてみると、authentiation と console が False になっていることが原因らしい。
[root@bastion01 openshift]# ./openshift-install --dir=installdir wait-for install-complete
INFO Waiting up to 40m0s (until 3:37PM) for the cluster at https://api.ocp4130.ocplab.test:6443 to initialize...
ERROR Cluster operator authentication Degraded is True with OAuthServerRouteEndpointAccessibleController_SyncError: OAuthServerRouteEndpointAccessibleControllerDegraded: Get "https://oauth-openshift.apps.ocp4130.ocplab.test/healthz": EOF
ERROR Cluster operator authentication Available is False with OAuthServerRouteEndpointAccessibleController_EndpointUnavailable: OAuthServerRouteEndpointAccessibleControllerAvailable: Get "https://oauth-openshift.apps.ocp4130.ocplab.test/healthz": EOF
INFO Cluster operator baremetal Disabled is False with :
INFO Cluster operator cloud-controller-manager TrustedCABundleControllerControllerAvailable is True with AsExpected: Trusted CA Bundle Controller works as expected
INFO Cluster operator cloud-controller-manager TrustedCABundleControllerControllerDegraded is False with AsExpected: Trusted CA Bundle Controller works as expected
INFO Cluster operator cloud-controller-manager CloudConfigControllerAvailable is True with AsExpected: Cloud Config Controller works as expected
INFO Cluster operator cloud-controller-manager CloudConfigControllerDegraded is False with AsExpected: Cloud Config Controller works as expected
INFO Cluster operator console Progressing is True with SyncLoopRefresh_InProgress: SyncLoopRefreshProgressing: Working toward version 4.13.4, 0 replicas available
ERROR Cluster operator console Available is False with Deployment_InsufficientReplicas::RouteHealth_FailedGet: DeploymentAvailable: 0 replicas available for console deployment
ERROR RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.ocp4130.ocplab.test): Get "https://console-openshift-console.apps.ocp4130.ocplab.test": EOF
INFO Cluster operator etcd RecentBackup is Unknown with ControllerStarted: The etcd backup controller is starting, and will decide if recent backups are available or if a backup is required
ERROR Cluster operator ingress Degraded is True with IngressDegraded: The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
INFO Cluster operator ingress EvaluationConditionsDetected is False with AsExpected:
INFO Cluster operator insights ClusterTransferAvailable is False with NoClusterTransfer: no available cluster transfer
INFO Cluster operator insights Disabled is False with AsExpected:
INFO Cluster operator insights SCAAvailable is False with NotFound: Failed to pull SCA certs from https://api.openshift.com/api/accounts_mgmt/v1/certificates: OCM API https://api.openshift.com/api/accounts_mgmt/v1/certificates returned HTTP 404: {"code":"ACCT-MGMT-7","href":"/api/accounts_mgmt/v1/errors/7","id":"7","kind":"Error","operation_id":"c29b5877-fad8-4773-83bc-e91712b4dba8","reason":"The organization (id= 1eMTNJtEsI58UIvnjQyhhHz1gCQ) does not have any certificate of type sca. Enable SCA at https://access.redhat.com/management."}
INFO Cluster operator network ManagementStateDegraded is False with :
ERROR Cluster initialization failed because one or more operators are not functioning properly.
ERROR The cluster should be accessible for troubleshooting as detailed in the documentation linked below,
ERROR https://docs.openshift.com/container-platform/latest/support/troubleshooting/troubleshooting-installations.html
ERROR The 'wait-for install-complete' subcommand can then be used to continue the installation
ERROR failed to initialize the cluster: Cluster operators authentication, console are not available
[root@bastion01 openshift]# oc get clusteroperator
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.13.4 False False True 5h16m OAuthServerRouteEndpointAccessibleControllerAvailable: Get "https://oauth-openshift.apps.ocp4130.ocplab.test/healthz": EOF
baremetal 4.13.4 True False False 5h14m
cloud-controller-manager 4.13.4 True False False 5h19m
cloud-credential 4.13.4 True False False 5h20m
cluster-autoscaler 4.13.4 True False False 5h15m
config-operator 4.13.4 True False False 5h15m
console 4.13.4 False True False 5h5m DeploymentAvailable: 0 replicas available for console deployment...
control-plane-machine-set 4.13.4 True False False 5h14m
csi-snapshot-controller 4.13.4 True False False 5h15m
dns 4.13.4 True False False 5h15m
etcd 4.13.4 True False False 5h13m
image-registry 4.13.4 True False False 5h5m
ingress 4.13.4 True False True 5h7m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
insights 4.13.4 True False False 5h2m
kube-apiserver 4.13.4 True False False 5h5m
kube-controller-manager 4.13.4 True False False 5h12m
kube-scheduler 4.13.4 True False False 5h12m
kube-storage-version-migrator 4.13.4 True False False 5h15m
machine-api 4.13.4 True False False 5h14m
machine-approver 4.13.4 True False False 5h15m
machine-config 4.13.4 True False False 5h
marketplace 4.13.4 True False False 5h15m
monitoring 4.13.4 True False False 5h4m
network 4.13.4 True False False 5h15m
node-tuning 4.13.4 True False False 5h14m
openshift-apiserver 4.13.4 True False False 5h5m
openshift-controller-manager 4.13.4 True False False 5h11m
openshift-samples 4.13.4 True False False 5h7m
operator-lifecycle-manager 4.13.4 True False False 5h15m
operator-lifecycle-manager-catalog 4.13.4 True False False 5h15m
operator-lifecycle-manager-packageserver 4.13.4 True False False 5h7m
service-ca 4.13.4 True False False 5h15m
storage 4.13.4 True False False 5h15m
[root@bastion01 openshift]#
[root@bastion01 openshift]# oc -n openshift-console get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
console-7f5b95d995-dsgfz 0/1 CrashLoopBackOff 53 (4m32s ago) 5h1m 10.128.0.37 master03.ocp4130.ocplab.test <none> <none>
console-7f5b95d995-xng76 0/1 CrashLoopBackOff 53 (4m29s ago) 5h1m 10.129.0.60 master01.ocp4130.ocplab.test <none> <none>
console-867db595c-nvvg8 0/1 CrashLoopBackOff 54 (101s ago) 5h4m 10.130.0.15 master02.ocp4130.ocplab.test <none> <none>
downloads-f6b75d65c-j9445 1/1 Running 0 5h4m 10.129.0.39 master01.ocp4130.ocplab.test <none> <none>
downloads-f6b75d65c-q8fsp 1/1 Running 0 5h4m 10.130.0.14 master02.ocp4130.ocplab.test <none> <none>
[root@bastion01 openshift]#
[root@bastion01 openshift]# oc logs console-867db595c-nvvg8 -n openshift-console | tail -n 3
E0720 11:02:54.033112 1 auth.go:239] error contacting auth provider (retrying in 10s): request to OAuth issuer endpoint https://oauth-openshift.apps.ocp4130.ocplab.test/oauth/token failed: Head "https://oauth-openshift.apps.ocp4130.ocplab.test": EOF
E0720 11:03:04.038234 1 auth.go:239] error contacting auth provider (retrying in 10s): request to OAuth issuer endpoint https://oauth-openshift.apps.ocp4130.ocplab.test/oauth/token failed: Head "https://oauth-openshift.apps.ocp4130.ocplab.test": EOF
E0720 11:03:14.043150 1 auth.go:239] error contacting auth provider (retrying in 10s): request to OAuth issuer endpoint https://oauth-openshift.apps.ocp4130.ocplab.test/oauth/token failed: Head "https://oauth-openshift.apps.ocp4130.ocplab.test": EOF
よくわかんねーなと思いつつ、ログを基に調べてみると以下のナレッジを発見。
結論として、これを実施したら、正常になった。
https://access.redhat.com/solutions/5691661
[root@bastion01 openshift]# oc get pods -n openshift-ingress NAME READY STATUS RESTARTS AGE router-default-5768f5c985-ct5ds 1/1 Running 1 (5h24m ago) 5h26m router-default-5768f5c985-tvrt7 1/1 Running 2 (5h21m ago) 5h26m [root@bastion01 openshift]# oc delete pod router-default-5768f5c985-ct5ds router-default-5768f5c985-tvrt7 -n openshift-ingress pod "router-default-5768f5c985-ct5ds" deleted pod "router-default-5768f5c985-tvrt7" deleted [root@bastion01 openshift]# <<< 少し時間がかかるので、のんびり待つ [root@bastion01 openshift]# oc get clusteroperators NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.13.4 True False False 38s baremetal 4.13.4 True False False 5h28m cloud-controller-manager 4.13.4 True False False 5h33m cloud-credential 4.13.4 True False False 5h33m cluster-autoscaler 4.13.4 True False False 5h29m config-operator 4.13.4 True False False 5h29m console 4.13.4 True False False 18s control-plane-machine-set 4.13.4 True False False 5h28m csi-snapshot-controller 4.13.4 True False False 5h28m dns 4.13.4 True False False 5h28m etcd 4.13.4 True False False 5h27m image-registry 4.13.4 True False False 5h18m ingress 4.13.4 True False False 7s insights 4.13.4 True False False 5h16m kube-apiserver 4.13.4 True False False 5h19m kube-controller-manager 4.13.4 True False False 5h26m kube-scheduler 4.13.4 True False False 5h26m kube-storage-version-migrator 4.13.4 True False False 5h29m machine-api 4.13.4 True False False 5h28m machine-approver 4.13.4 True False False 5h28m machine-config 4.13.4 True False False 5h14m marketplace 4.13.4 True False False 5h29m monitoring 4.13.4 True False False 5h18m network 4.13.4 True False False 5h29m node-tuning 4.13.4 True False False 5h28m openshift-apiserver 4.13.4 True False False 5h19m openshift-controller-manager 4.13.4 True False False 5h25m openshift-samples 4.13.4 True False False 5h21m operator-lifecycle-manager 4.13.4 True False False 5h28m operator-lifecycle-manager-catalog 4.13.4 True False False 5h28m operator-lifecycle-manager-packageserver 4.13.4 True False False 5h21m service-ca 4.13.4 True False False 5h29m storage 4.13.4 True False False 5h29m [root@bastion01 openshift]# [root@bastion01 openshift]# oc -n openshift-console get pods NAME READY STATUS RESTARTS AGE console-7f5b95d995-dsgfz 1/1 Running 56 (11m ago) 5h20m console-7f5b95d995-xng76 1/1 Running 56 (10m ago) 5h20m downloads-f6b75d65c-j9445 1/1 Running 0 5h22m downloads-f6b75d65c-q8fsp 1/1 Running 0 5h22m
オペレータが全て True になってから、consoleにアクセスを試してみると正常にログインできた。
NetworkManagerからOpen vSwitchを作成する
Open vSwitchを作成する時は、ovsコマンドを使用することが一般的だと思いますが、NetworkManagerが稼働している環境だとNetworkManagerから全部設定したいなあと思うことがあります。
というのも、ovsコマンドから作成したinterfaceにIPを設定するためには、NetworkManagerからでなく別途ifcfgファイルを手動で作成して適用する必要があるからです。(私の知見不足で他に方法があるかもしれませんが)
よって、nmcliからovsの作成・設定をする方法を調べたのでメモとして残しておきます。
インストール
nmcliからovsを作成するには、openvswitchの他に、NetworkManager-ovsをインストールする必要があります。
※openvswitchは既にinstall済み
dnf install NetworkManager-ovs
インストール後、NetworkManagerを再起動します。再起動しないと私の環境では正常に動作しませんでした。
systemctl restart NetworkManager
設定
NetworkManagerからovsを作成する場合、bridge, port, interfaceをそれぞれ作成しなければなりません。
ovs-vsctlコマンドとは異なり、自動的には作成してもらえないようです。
最初に、bridge作成します。
nmcli con add type ovs-bridge ifname br-data
次に、port, interfaceを作成します。
masterは、portの場合はbridge名、interfaceの場合は、port名を入力します。
全部同じ名前でもいいですが、紛らわしかったので今回はport名だけ変更しました。
また、interfaceを作成する際に、IPの無効化の設定をしています。
この設定をしないと、接続プロファイルがactiveにならないので、しばらくすると自動的にovsがdownします。
nmcli con add type ovs-port ifname br-data-p01 master br-data nmcli con add type ovs-interface slave-type ovs-port ifname br-data master br-data-p01 \ ipv4.method disabled \ ipv6.method disabled
IPを設定する場合は下記のように設定します。
tag設定する場合は、ovs-port.tag
nmcli con add type ovs-port ifname ovs-vlan10 master br-data ovs-port.tag 10 nmcli con add type ovs-interface slave-type ovs-port ifname vlan10 master ovs-vlan10 \ ipv4.method manual ipv4.address 192.168.10.1/24 \ ipv4.gateway 192.168.10.254 \ ipv4.dns 8.8.8.8 \ ipv4.never-default no \ ipv6.method disabled nmcli con add type ovs-port ifname ovs-vlan20 master br-data ovs-port.tag 20 nmcli con add type ovs-interface slave-type ovs-port ifname vlan20 master ovs-vlan20 \ ipv4.method manual ipv4.address 192.168.20.1/24 \ ipv4.gateway 192.168.20.254 \ ipv4.never-default yes \ ipv6.method disabled
最後に、物理IFをovs-interfaceとしてbridgeに組み込みます。
この際にportも作成する必要があります。
下記例では、ovs-port.vlan-mode <vlan-mode名> でportに設定するvlan-modeをnative-untaggedに変更しています。
併せてtag 20を設定しているので、tag無pktを受信すると、vlan20のpktとして扱うという動きになります。 (送信時もtagを付けない)
nmcli con add type ovs-port ifname ovs-ens19 master br-data \ ovs-port.vlan-mode native-untagged \ ovs-port.tag 20 nmcli con add type ethernet ifname ens19 master ovs-ens19
これで 設定ができたので、確認してみます。
まずは、openvswitchから見てみます。
[root@test ~]# ovs-vsctl show
02cadfc2-10dd-441b-8fa7-ed1861a84a4d
Bridge br-data
Port ovs-vlan10
tag: 10
Interface vlan10
type: internal
Port ovs-vlan20
tag: 20
Interface vlan20
type: internal
Port br-data-p01
Interface br-data
type: internal
Port ovs-ens19
tag: 20
Interface ens19
type: system
ovs_version: "2.15.3"
[root@test ~]# ovs-vsctl list port ovs-ens19
_uuid : adc42cb6-aa53-4efd-ab6e-e2de791fa075
bond_active_slave : []
bond_downdelay : 0
bond_fake_iface : false
bond_mode : []
bond_updelay : 0
cvlans : []
external_ids : {NM.connection.uuid="5a3bc8ff-b87b-451d-a4c8-05b8c8736570"}
fake_bridge : false
interfaces : [de7bfab3-b883-4b76-89fe-2014179f8eff]
lacp : []
mac : []
name : ovs-ens19
other_config : {}
protected : false
qos : []
rstp_statistics : {}
rstp_status : {}
statistics : {}
status : {}
tag : 20
trunks : []
vlan_mode : native-untagged
正常に作成されているようです。
次にnmcliの接続プロファイル とデバイスを見てみます。
作成時にcon-name でプロファイル名を指定していないので、少し分かり難いですね。
[root@test ~]# nmcli con show --active NAME UUID TYPE DEVICE ovs-slave-vlan10 2b96a544-042e-4b08-b83d-a967c8ff8a85 ovs-interface vlan10 ovs-slave-vlan20 08bf6c74-931f-4a49-b292-eaf3e92c4043 ovs-interface vlan20 ovs-bridge-br-data 02cfc6ed-7642-4355-9d11-92505aa84fa0 ovs-bridge br-data ovs-slave-br-data 95a93f76-4bca-4062-812a-d1d357b72a97 ovs-interface br-data ovs-slave-br-data-p01 15d1690e-6df4-4a1f-b0b4-391ba9fd4ca9 ovs-port br-data-p01 ovs-slave-ens19 80e4dcaa-a75b-4108-8063-52699eeccc44 ethernet ens19 ovs-slave-ovs-ens19 5a3bc8ff-b87b-451d-a4c8-05b8c8736570 ovs-port ovs-ens19 ovs-slave-ovs-vlan10 3c9f7b44-9272-4520-b7bc-f51e1428daa7 ovs-port ovs-vlan10 ovs-slave-ovs-vlan20 101c0c92-577a-466a-8777-a2eb16ffe714 ovs-port ovs-vlan20 [root@test ~]# nmcli dev DEVICE TYPE STATE CONNECTION vlan10 ovs-interface connected ovs-slave-vlan10 vlan20 ovs-interface connected ovs-slave-vlan20 ens19 ethernet connected ovs-slave-ens19 br-data ovs-bridge connected ovs-bridge-br-data br-data ovs-interface connected ovs-slave-br-data br-data-p01 ovs-port connected ovs-slave-br-data-p01 ovs-ens19 ovs-port connected ovs-slave-ovs-ens19 ovs-vlan10 ovs-port connected ovs-slave-ovs-vlan10 ovs-vlan20 ovs-port connected ovs-slave-ovs-vlan20 lo loopback unmanaged --
最後にデバイスの状態とルート情報を確認します。
[root@test ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000
link/ether 5e:51:07:e8:5e:77 brd ff:ff:ff:ff:ff:ff
17: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ce:ec:57:ab:6c:ec brd ff:ff:ff:ff:ff:ff
18: br-data: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 12:4b:c8:a3:f0:4a brd ff:ff:ff:ff:ff:ff
19: vlan10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 72:e9:5a:79:65:55 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute vlan10
valid_lft forever preferred_lft forever
20: vlan20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 4e:e4:59:08:94:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.20.1/24 brd 192.168.20.255 scope global noprefixroute vlan20
valid_lft forever preferred_lft forever
[root@test ~]# ip r
default via 192.168.10.254 dev vlan10 proto static metric 801
192.168.10.0/24 dev vlan10 proto kernel scope link src 192.168.10.1 metric 801
192.168.20.0/24 dev vlan20 proto kernel scope link src 192.168.20.1 metric 802
問題ないようですね。
疎通確認は面倒臭いので省略します。
今回は上手くできましたが、下記参考文献にある通りovsの機能を全てサポートしているわけではないようなので、使用する機能が対応しているか事前に確認する必要がありそうです。
参考文献
https://manpages.debian.org/testing/network-manager/nm-settings.5.en.html#ovs-port_setting
https://manpages.debian.org/testing/openvswitch-common/ovs-vsctl.8.en.html
https://man.archlinux.org/man/extra/networkmanager/nm-openvswitch.7.en
http://www.openvswitch.org//ovs-vswitchd.conf.db.5.pdf
TungstenFabric (Contrail) controllerにopenstack clientをインストールする
前回、TungstenFabric + Openstack をdeployしたので、設定をしていきたいところですが、GUIでポチポチするのも手間なのでCLIでの設定を試したいと思います。
CLIで設定するには、tungstenfabricやopenstackのapiを叩けばいいのですが、ものによってはkeystoneでの認証が必要のため、予めTokenを取得してcmdのヘッダに付与する必要があります。
Tokenを取得する方法としては、openstack コマンドがありますが、前回のdeploy方法だとopenstackコマンドが使えません。※
その為、openstack client をインストールすることで、openstack コマンドを使用可能にし、cmdからAPIを叩けるようにします。
※openstack controllerで稼働している"kolla_toolbox"というコンテナにログインし、admin-openrc.shを読み込むことで使えますが、毎度コンテナからというのも手間なので
docker exec -it kolla_toolbox bash source /var/lib/kolla/config_files/admin-openrc.sh
設定
TungstenFabric Controllerに、virtualenvをインストールし作成した仮想環境の中にpipでopenstack clientをインストールします。
yum install -y gcc python-devel python2.7 -m pip install virtualenv python2.7 -m virtualenv venv-osp-client source venv-osp-client/bin/activate pip install python-openstackclient python-ironicclient
openstack client では、複数のファイルでqueue モジュールを使用していますが、queueモジュールはpython2とpython3で名称が変化しています。
Python2系: Queue
Python3系: queue
今回の環境では、Python2.7を使用している為、下記のファイルを置換する必要があります。
sed -i -e "s/import queue/import Queue/g" /root/venv-osp-client/lib/python2.7/site-packages/openstack/utils.py sed -i -e "s/import queue/import Queue/g" /root/venv-osp-client/lib/python2.7/site-packages/openstack/cloud/openstackcloud.py
次に、OpenStack クライアント環境スクリプトを作成します。
cat << 'EOF' > admin-openrc.sh
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=contrail123
export OS_AUTH_URL=http://192.168.0.10:35357/v3
export OS_INTERFACE=internal
export OS_IDENTITY_API_VERSION=3
export OS_REGION_NAME=RegionOne
export OS_AUTH_PLUGIN=password
export OS_BAREMETAL_API_VERSION=1.29
export PS1="${PS1-}(o $OS_USERNAME $OS_PROJECT_NAME)]\$ "
EOF
作成後に、source コマンドで読み込みます。
source admin-openrc.sh
これで、openstackコマンドが使用可能になったので、Tokenが取得可能になりました。
TOKEN=$(openstack token issue | awk '/ id/{print $4}')
echo $TOKEN
Kolla AnsibleでOpenStack + TungstenFabric (Contrail) deploy
Kolla Ansibleを使用してTungstenFabric (Contrail) + OpenStackをdeployする手順はGitHub やJuniperが公開している手順に記載されていますが、所々情報が古く少し苦戦したので、設定例をメモ。
構成
下記図の通り。
MultiNode & Multi interfaceで試したかったので各Controllerは3台構成で2nic持たせている。
各インスタンスのcpu/memory/disk設定は下記。
推奨スペックよりも低いが自宅環境のマシンだと下記が限界だった。
スペックに余裕がある場合は多めに割り当てたほうが無難。
deployer: 1CPU/2GB/10GB OpenStack Controller: 4CPU/12GB/100GB TungstenFabric Controller: 4CPU/16GB/100GB ComputeNode: 4CPU/8GB/100GB
設定
インスタンスの初期設定を実施した後deployerにて下記編集。
provider_config:
bms:
ssh_user: admin
ssh_private_key: /root/.ssh/id_rsa
ssh_public_key: /root/.ssh/id_rsa.pub
domainsuffix: local
instances:
ctr01:
provider: bms
ip: 192.168.0.11
roles:
openstack:
ctr02:
provider: bms
ip: 192.168.0.12
roles:
openstack:
ctr03:
provider: bms
ip: 192.168.0.13
roles:
openstack:
tf01:
provider: bms
ip: 192.168.0.14
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
tf02:
provider: bms
ip: 192.168.0.15
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
tf03:
provider: bms
ip: 192.168.0.16
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
cmp01:
provider: bms
ip: 192.168.0.17
roles:
vrouter:
openstack_compute:
cmp02:
provider: bms
ip: 192.168.0.18
roles:
vrouter:
openstack_compute:
global_configuration:
CONTAINER_REGISTRY: tungstenfabric
contrail_configuration:
UPGRADE_KERNEL: False
CONTRAIL_VERSION: "2020-08-21-stable"
CONTRAIL_CONTAINER_TAG: "2020-08-21-stable"
CONTROLLER_NODES: 192.168.0.14,192.168.0.15,192.168.0.16
CONTROL_NODES: 172.16.0.14,172.16.0.15,172.16.0.16
CLOUD_ORCHESTRATOR: openstack
VROUTER_GATEWAY: 172.16.0.254
KEYSTONE_AUTH_HOST: 192.168.0.10
KEYSTONE_AUTH_URL_VERSION: /v3
KEYSTONE_AUTH_URL: http://192.168.0.10:35357/v3
OPENSTACK_VERSION: queens
AUTH_MODE: keystone
RABBITMQ_NODE_PORT: 5673
CONFIG_DATABASE_NODEMGR__DEFAULTS__minimum_diskGB: 20
DATABASE_NODEMGR__DEFAULTS__minimum_diskGB: 20
PHYSICAL_INTERFACE: vlan10
JVM_EXTRA_OPTS: "-Xms1g -Xmx2g"
BGP_ASN: 64512
kolla_config:
customize:
nova.conf: |
[libvirt]
virt_type=qemu
cpu_mode=none
kolla_globals:
enable_haproxy: yes
enable_ironic: no
enable_swift: no
contrail_api_interface_address: 192.168.0.14,192.168.0.15,192.168.0.16
kolla_internal_vip_address: 192.168.0.10
kolla_external_vip_address: 172.16.0.10
kolla_passwords:
keystone_admin_password: contrail123
deploy
上記設定後、deployerにて下記実行。
ansible-playbook -i inventory/ -e orchestrator=openstack playbooks/configure_instances.yml -vv ansible-playbook -i inventory/ -e orchestrator=openstack playbooks/install_openstack.yml -vv ansible-playbook -i inventory/ -e orchestrator=openstack playbooks/install_contrail.yml -vv
正常に完了すれば、下記のようにOpenstackのUI (Horizon)とTungstenFabric (Contrail) のUIにアクセスできる。
