上面左邊是個人我的微信,如需進一步溝通,請加微信。 右邊是個人公衆號「Openstack私有云」,若有興趣,請關注。html
如今Openstack社區的安裝部署方式已經開始推薦使用kolla進行部署,kolla項目如今包括兩個子項目:kolla-ansible和kolla-kubernetes,其中kolla-ansible應用於生產環境案例多些而且使用普遍一些,本文檔kolla是指kolla-ansible。 node
kolla-ansible項目是基於ansible playbook的部署方式,原來openstack ansible的部署方式支持baremetel和lxc容器兩種方式進行部署,kolla的部署方式是徹底基於docker和ansible兩大工具實現。python
2018年3月1日注:爲了提升部署效率,能夠經過直接使用製做好的ISO鏡像鏡像安裝,詳見個人另外一編博客文章:mysql
Kolla是OpenStack下的一個項目,項目的目標是提供可用於生產的容器化部署工具,以便使用社區最佳實踐來運行可擴展、快速、可靠和可升級的OpenStack雲。git
Kolla使用Docker容器和Anisble playbooks來實現這個目標。Kolla是開箱即用的,即便你是個新手也能夠很快的使用kolla快速部署你的openstack集羣。Kolla也容許你根據實際的需求來定製化的部署。github
kolla目前已經能夠部署如下openstack項目:sql
v Aodhmongodb
v Barbicandocker
v Bifrost
v Ceilometer
v Cinder
v CloudKitty
v Congress
v Designate
v Glance
v Gnocchi
v Heat
v Horizon
v Ironic
v Keystone
v Kuryr
v Magnum
v Manila
v Mistral
v Murano
v Neutron
v Nova
v Rally
v Sahara
v Senlin
v Swift
v Tempest
v Trove
v Vmtp
v Watcher
v Zaqar
能夠部署的基礎組件包括:
v Ceph 作cinder/nova/glance存儲後端
v [collectd (https://collectd.org), [InfluxDB (https://influxdata.com/time-series-platform/influxdb/), and [Grafana (http://grafana.org) for performance monitoring.
v [Elasticsearch (https://www.elastic.co/de/products/elasticsearch) and [Kibana (https://www.elastic.co/de/products/kibana) 日誌分析
v [HAProxy (http://www.haproxy.org/) and [Keepalived (http://www.keepalived.org/) 高可用
v [Heka (http://hekad.readthedocs.org/) 分佈式可擴展的日誌系統
v [MariaDB and Galera Cluster (https://mariadb.com/kb/en/mariadb/galera-cluster/) 高可用數據庫
v [MongoDB (https://www.mongodb.org/) Ceilometer和Gnocchi的數據庫後端
v [Open vSwitch (http://openvswitch.org/)
v [RabbitMQ (https://www.rabbitmq.com/) 消息隊列
容器化的OpenStack實現,其實都差很少,就看各家誰更加完全,更加優雅,更加安全。所謂完全,就是徹底對操做系統是免疫的,把容器刪掉後,操做系統就好像沒操做過同樣。
通常來講都是build各類服務的docker 鏡像。利用工具進行編排,對鏡像分發,把鏡像啓動起來。有些廠商僅僅是把控制節點容器化。對於kolla項目來講,是把OpenStack和周邊項目所有容器化:
2 ceph
2 qemu
2 libvirt
這些都容器化,甚至在討論NTP服務,也須要進行容器化。
Kolla項目 https://github.com/openstack/kolla
這個其實你們均可以想到,容器最大的特色,就是升級。企業使用OpenStack,最大的一個顧慮,就是升級。尤爲在OpenStack一年兩個版本下,不斷的有新的功能的需求的狀況下,若是不能升級,實際上是很痛苦。尤爲在企業的迅速發展的過程當中。
容器化的OpenStack,升級有多麼簡單呢?其實就是刪掉容器,換上新的容器,用戶基本是無感知的狀態下完成。
升級子因此很困難,有一個很現實的緣由,線上環境,很難模擬,升級驗證測試很難進行。當採用容器化之後,咱們很容易模擬出一個線上環境,進行升級測試,升級失敗,回滾。其實這些都作的很漂亮。
之前廠商的解決方案,都是3個控制節點,若是我但願增長到5個控制節點,或者把控制節點某個服務單獨部署,那麼這個基本是很難完成的任務。
之前廠商都廠商把OpenStack的各個服務放到虛擬機裏,這樣部署靈活性提升很多。可是虛擬機仍是很重,面對客戶千百萬化的需求,就有點無能爲力。
舉一個例子:
企業基本節點,我規模很小,可能就只有幾臺機器,這時候,我可能不須要控制節點高可用,我就須要1個控制節點,管理機櫃計算節點。
隨着時間的發展,但願擴大規模,控制節點變成高可用。
規模進一步擴大,我就須要把消息隊列單獨出來部署,解決性能的問題。
這種需求,很實在,OpenStack廠商也在努力知足企業的這些需求,其實Mirantis的Fuel,已經在不少程度,知足了企業這種需求,不過代價很大。
對於容器化的OpenStack,就變得很簡單,無非就是調整各個節點的容器分佈,編排的問題。控制節點是3個,仍是五個,rabbitmq放在什麼位置,根本就不是問題。
OpenStack過去使用最廣的配置管理工具是Puppet,對於企業用戶來講,這個是很難掌控的。其實在國內,就算是互聯網公司,負責Puppet的運維人員離職,其實都是很難招聘回來相應的人員。
對於OpenStack廠商來講,要想徹底掌控Puppet,仍是很困難的。更別說,要知足各類靈活的需求。
配置管理工具,其實Salt和Ansible,是python開發,比較易用,不過在OpenStack的生態圈裏,不如puppet強大,很難超越Puppet。
容器化後的OpenStack,配置管理工具,或者編排的工具,就不少選擇,ansible,slat,K8S,都是能夠支持。你就不須要受ruby的折磨。
其實這也是大大下降企業掌控OpenStack難度。
廠商都在宣傳所謂沒有廠商綁定。其實你用了紅帽的OpenStack,要想換到Ubuntu下,不是不可能,其實確定很痛苦。若是要換成Suse,難度就更高。
各類配置管理工具,其實都是依賴發行版的包管理。國內的銀行其實都使用Suse。可是社區的Puppet工具不支持Suse。或者操做系統發行版沒有提供包,怎麼辦?容器化的OpenStack。其實理論上,能夠跑在任何支持容器的操做系統上。內核的版本高,無非就是性能更好一點。其實你只須要作點測試,就能夠實現這種跨操做系統的部署。
容器裏,可使用rpm包,Deb包,也是能夠跑源碼安裝,這樣其實對於操做系統廠商來講,基本就沒任何的依賴。不受制操做系統廠商。
OpenStack項目的增多,軟件互相依賴的問題,愈來愈嚴重。由於OpenStack不少項目是須要使用外部項目,例如Ceph,他的依賴極可能和OpenStack組件的依賴產生衝突。這種問題,能夠解決,可是解決,沒任何的意義和技術含量,很讓技術人員抓狂。其實發行版都在投入大量的精力去解決各個軟件包的互相依賴的問題。
容器化的OpenStack,很好的解決了這個問題。
在生產環境中,部署時間1個小時,和一天,其實區別不大,畢竟部署是一次性的工做。對於測試來講,就徹底不同。若是我10分鐘能夠完成一次部署,能夠測試驗證的東西,和幾個小時才能完成一次的部署,差別仍是很大的。
容器化OpenStack,大大加快了部署的時間,一般10分鐘,就能夠完成一次完整功能的部署,驗證OpenStack各類新功能的代價,就大大減小。
OpenStack在企業的實際使用中,都是抱怨太複雜,這其實也是由於OpenStack,鬆耦合,功能強大,同時也讓用戶感受很複雜。尤爲在出現錯誤的時候,很無奈。
容器化後,用戶感受OpenStack各個組件,就相似累積木同樣,搭建起來,能夠根據本身的需求,選擇哪一個模塊。感受本身是可控的。你能夠很方便的裝上某個模塊,不滿意,刪掉。背後的複雜的邏輯,社區已經幫你完善。
遇到問題,尋求幫助,也顯得簡單不少。由於你們容器裏的東西都是同樣的,無非就是外面的配置文件。
也只要讓企業感受本身能夠掌控OpenStack,這樣OpenStack纔會大量的進入企業的IT系統。這個時候,不管是採用外包仍是本身運維。
若是實現計算節點掛掉後,上面的虛擬機自動在別的節點啓動起來。這個問題解決的辦法,其實有不少,解決的難點,就在於我如何判斷這臺節點真的掛掉。由於虛擬機的遷移的東西,是很大的,必須很當心。也很容易形成誤判。
海雲捷迅提出一個使用consul的解決方案,就是一個容器裏作健康檢查的組件,放到openstack計算節點,相似peer to peer,互相檢查。
當容器化的OpenStack後,那麼就能夠利用容器強大社區,各類的實現方式,第一時間知道節點失效。確定你也是可使用consul來解決這個問題,更加直接。
OpenStack一直都在完善本身的監控日誌分析。不過進展並不太好。容器化的OpenStack,面臨的監控,日誌的問題,和之前的OpenStack有很大差別。
不過不得不認可,容器的世界裏,這方面很是完善,太多選擇,能夠幫助你解決監控和日誌分析的問題。
能夠利用強大的Docker社區,來完善OpenStack短板的地方。
容器化後的OpenStack,其實帶來不少意想不到的創新和變化。不少之前很炫的概念,慢慢走向現實。
OpenStack一個版本的發行週期大概是分爲B1,B2,B3,每一個階段大概45天,後續就發佈RC,正式版本。
以往OpenStack公司都是等到一個版本正式發佈後,進行打包,測試,驗證,通過3個月和半年,正式對外發布。那麼這種發佈週期,其實已經有點跟不上OpenStack的步伐。例如Mitaka版本發佈的時候,紅帽的Liberty版本才正式對外發布。
能不能作到,OpenStack一邊開發,發行版也在同步進行打包,測試呢?其實在OpenStack發展初期,有人提出這樣的建議,不過對操做系統廠商來講,代價太大,不肯意去作。
有了容器化之後,徹底不須要依賴操做系統的打包,我能夠根據本身的需求,進行build image,測試,這樣個人產品的發佈週期,就會大大縮短。
(以上內容參考:http://www.chenshake.com/openstack-benefits-of-container/)
這些工做都是在OpenStack服務(目標主機)節點進行。對於kolla來講,準備工做作完後,安裝OpenStack很是快,若是從網上下載鏡像須要看網絡狀況,若是先準備好了docker本地registry並提早build images,那麼安裝也就是1個小時之內的事情。
目標主機相關準備工做:
1. 關閉Selinux
2. 關閉Firewalld
3. 關閉NetworkManager
4. 設置hostname FQDN,讓機器能夠經過hostname進行互相訪問,統一 /etc/hosts文件
5. 同步時間,先確保時間是基本一致,和硬件也統一時間
6. 設置docker registry 服務器位置,設置不安全的訪問。
7. 檢查機器是否支持KVM
8. 設置docker源,安裝docker 1.12.5
9. 設置訪問私有的registry 源
10. 打開Docker 的 shared mount 功能
11. 設置網卡,網絡,符合部署需求。若是須要bonding,須要把bonding作好。
12. 對於要部署Ceph的節點的磁盤,進行打標籤
13. 檢查網絡,重點,確保裝好後,網絡功能正常。
在kolla部署節點(Master節點),咱們須要作的準備工做:
1. 關閉Selinux
2. 關閉NetworkManager
3. 設置hostname FQDN,讓機器能夠經過hostname進行互相訪問,統一 /etc/hosts文件
4. 同步時間,先確保時間是基本一致,和硬件也統一時間
5. 設置docker源
上面面5條,與目標節點的準備工做是相同的,不一樣的是:
1. 搭建私有的registry服務器,存放build好的OpenStack Docker鏡像
2. 安裝ansible
3. 部署kolla-ansible
最小化安裝操做系統。
1 關閉NetworkManager
2 關閉Selinux
3 關閉Firewalld
4 安裝Epel源
5 設置Hostname
6 同步時間
systemctl stop NetworkManager systemctl disable NetworkManager
編輯 /etc/selinux/config
SELINUX=disabled
重啓機器,查看selinux狀態
# sestatus SELinux status: disabled
systemctl status firewalld systemctl stop firewalld systemctl disable firewalld systemctl status firewalld firewall-cmd --state
yum install epel-release
查看repo狀況:
yum repolist
#cat /etc/hostname kolla # cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.0.7.10 kolla.dd.com kolla
檢查
#hostname -F /etc/hostname #hostname kolla #hostname -f kolla.dd.com
yum install ntp systemctl enable ntpd.service systemctl start ntpd.service
手工同步時間:
ntpdate 0.centos.pool.ntp.org
必定要啓用EPEL的repo源
yum install python-devel libffi-devel gcc openssl-devel git python-pip
安裝經常使用軟件包:
yum install vim wget -y
目前最新版本的Docker是1.13.X,Kolla目前支持的Docker是1.12.x,因此咱們要指定Docker的版原本安裝,而且必定要採用Docker官方的源,不能使用紅帽的源,紅帽的源的Docker有bug。
tee /etc/yum.repos.d/docker.repo << 'EOF' [dockerrepo] name=Docker Repository baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/ enabled=1 gpgcheck=1 gpgkey=https://yum.dockerproject.org/gpg EOF
yum install docker-engine-1.12.5 docker-engine-selinux-1.12.5 -y
mkdir /etc/systemd/system/docker.service.d tee /etc/systemd/system/docker.service.d/kolla.conf << 'EOF' [Service] MountFlags=shared EOF
重啓相關服務:
systemctl daemon-reload systemctl enable docker systemctl restart docker
編輯 /usr/lib/systemd/system/docker.service
#ExecStart=/usr/bin/dockerd ExecStart=/usr/bin/dockerd --insecure-registry 10.0.7.10:4000
注意,將10.0.7.10改成安裝時的kolla-master實際內網地址;
重啓服務
systemctl daemon-reload systemctl restart docker
Kolla項目的Mitaka版本要求ansible版本低於2.0,Newton版本之後的就只支持2.x以上的版本。咱們這裏安裝Ocata版本,所以要求ansible版本高於2.0 ,默認安裝便可 。
yum install ansible -y
編輯/etc/hosts文件,增長如下內容:
10.0.7.10 kolla.dd.com kolla 10.0.7.221 control01.dd.com control01 10.0.7.222 compute01.dd.com compute01 10.0.7.223 storage01.dd.com storage01
注意,以上IP地址和主機名,根據最終肯定的IP地址和主機名進行修改。剩下的主機解析記錄根據最終的主機肯定並添加。
創建ansible的ssh信任關係:
在kolla主機上執行: ssh-keygen
編輯ansible host文件:vi /tmp/all
[all] control01 compute01 storage01
分別在kolla上用ssh使用root帳戶登陸control01/compute01/storage01 ,使kolla記錄 know_hosts,而後執行下面的命令創建ssh信任關係,使kolla免密登錄三臺主機:
ansible control01 -i /tmp/all -m authorized_key -a "user=root key='{{lookup('file','/root/.ssh/id_rsa.pub')}}'" -k ansible compute01 -i /tmp/all -m authorized_key -a "user=root key='{{lookup('file','/root/.ssh/id_rsa.pub')}}'" -k ansible storage01 -i /tmp/all -m authorized_key -a "user=root key='{{lookup('file','/root/.ssh/id_rsa.pub')}}'" -k
Docker Registry服務器是一個本地託管的鏡像管理服務器,它取代了從Docker Hub獲取鏡像。Kolla能夠在有或沒有本地鏡像管理服務器的狀況下部署,2.3版以前的Docker註冊表性能很是差,由於全部容器數據都是針對每一個映像推送的,而不是利用Docker分層來優化推送操做。所以,Kolla社區建議使用註冊表2.3或更高版本。要使用版本2.3或更高版本部署Registry服務器,請執行如下操做:
mkdir /opt/registry docker run -d -v /opt/registry:/var/lib/registry -p 4000:5000 \ --restart=always --name registry registry:2
注:默認docker的registry是使用5000端口,對於OpenStack來講,有端口衝突,因此改爲4000
下載kolla官方提供的鏡像:
http://tarballs.openstack.org/kolla/images/
這是kolla官方提供的鏡像給CI使用,只保留最新版本和最新的stable版本。下載Ocata版本:
wget http://tarballs.openstack.org/kolla/images/centos-source-registry-ocata.tar.gz 注:官網上面已經移除了,我已上傳到百度雲盤,下載地址:https://pan.baidu.com/s/1A3KFi3kPj4b0PBDR9cOOlQ 密碼: p7ns tar zxvf centos-source-registry-ocata.tar.gz -C /opt/registry/
這樣就把kolla的docker鏡像文件放到Regisitry服務器上。
5. kolla-ansible(在kolla-master節點上執行)
下載kolla-ansible的代碼:
cd /home git clone https://github.com/openstack/kolla-ansible -b stable/ocata
安裝kolla-ansible
cd kolla-ansible pip install .
一個小技巧,若是pip速度很慢,後面能夠加上參數,指定國內的pip源
pip install . -i https://pypi.tuna.tsinghua.edu.cn/simple
(以上內容參考: http://www.cnblogs.com/microman/p/6107879.html)
複製相關文件
cp -r etc/kolla /etc/kolla/ cp ansible/inventory/* /home/
若是是在虛擬機裏裝kolla,但願能夠啓動再啓動虛擬機,那麼你須要把virt_type=qemu,默認是kvm :
mkdir -p /etc/kolla/config/nova cat << EOF > /etc/kolla/config/nova/nova-compute.conf [libvirt] virt_type=qemu cpu_mode = none EOF
生成密碼文件:
kolla-genpwd
編輯 /etc/kolla/passwords.yml
keystone_admin_password: admin #登陸Dashboard,admin使用的密碼 database_password: mysql #mysql數據庫密碼
相關的密碼能夠根據本身須要進行修改。
編輯 /etc/kolla/globals.yml 文件
kolla_internal_vip_address: "10.0.7.11"
注意,將10.0.7.11這個地址替換爲現場使用地址,這個地址用做內網全部openstack組件HA高可用地址
kolla_install_type: "source" openstack_release: "4.0.3" //注意和kolla_ansible的版本保持一致 docker_registry: "10.0.7.10:4000" docker_namespace: "lokolla" network_interface: "ens33" neutron_external_interface: "ens34"
10.0.7.11,這個ip是一個沒有使用的的ip地址,他是給haproxy使用。 網絡接口名稱 ens33是openstack內部網絡 、 ens34是外部網絡, 請根據實際狀況修改 。
部署前的bootstrap準備:
kolla-ansible -i /home/multinode bootstrap-servers
這個命令會作一些安裝前的準備工做,好比在每一個目標節點修改/etc/hosts文件,準備ansible playbook文件等等。
部署前的檢查:
kolla-ansible prechecks -i /home/multinode
整個部署過程只須要運行一個命令:
kolla-ansible deploy -i /home/multinode
/home/multinode是inventory文件,裏面具體定義了哪一臺主機安裝什麼openstack模塊。例如,默認咱們會把compute主機放到compute節點組,若是我想將control03主機也做爲comute節點使用,那麼我只須要到這樣修改:
[compute] compute01 compute02 compute03 compute04 compute05 control03
即,將control03 加入到[compute]組中。同理,其餘的功能模塊也能夠根據設計很是靈活的配置。建議通讀這個文件。
另外,在 /etc/kolla/globle.yml文件中能夠定義決定安裝或者不安裝相關的openstack組件,好比,默認狀況不安裝neutron的負載均衡和防火牆功能,若是但願啓用,那麼在globle.yml中將下面的行:
#enable_neutron_lbaas: "no" #enable_neutron_fwaas: "no"
改成:
enable_neutron_lbaas: "yes" enable_neutron_fwaas: "yes"
具體哪些組件是默認安裝,哪些組件是默認禁用,須要參考這個文件:kolla-ansible/ansible/group_vars/all.yml ,建議通讀這個文件。
全局配置文件/etc/kolla/globle.yml中能夠修改上面這個文件的默認參數值,默認的/etc/kolla/globle.yml文件,建議通讀這個文件。
kolla-ansible post-deploy
這個命令會建立 /etc/kolla/admin-openrc.sh 文件
安裝OpenStack client端:
pip install python-openstackclient
編輯 /usr/share/kolla-ansible/init-runonce,
網絡須要根據實際狀況修改:
EXT_NET_CIDR='192.168.12.0/24' EXT_NET_RANGE='start=192.168.12.30,end=192.168.12.40' EXT_NET_GATEWAY='192.168.12.1'
這裏解釋一下,192.168.12.0的網絡,就是上面ens34接的網絡,這個網絡是經過路由器訪問互聯網。這個地方須要好好理解。配置好這個,裝完虛擬機就能夠直接ping通。
運行
source /etc/kolla/admin-openrc.sh cd /usr/share/kolla-ansible ./init-runonce
最後能夠建立一個虛擬機,根據最後的命令提示:
openstack server create \ --image cirros \ --flavor m1.tiny \ --key-name mykey \ --nic net-id=a9f8b46b-41c1-4e0a-b015-457dffc89afe \
這個時候,你能夠登陸Dashboard,給虛擬機分配一個floating ip,若是順利,應該就能夠直接ping 通 floating ip的地址。
[root@kolla kolla-ansible]# openstack server create --image cirros --flavor m1.tiny --key-name mykey --nic net-id=a9f8b46b-41c1-4e0a-b015-457dffc89afe demo1 +-------------------------------------+-----------------------------------------------+ | Field | Value | +-------------------------------------+-----------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | hx9jW5tbru3U | | config_drive | | | created | 2017-11-06T13:35:12Z | | flavor | m1.tiny (1) | | hostId | | | id | 1d269c03-1ee4-44ab-8a12-9ecaa6cdcd86 | | image | cirros (48332374-1fd5-4f58-b8ce-b0e3f4b2015a) | | key_name | mykey | | name | demo1 | | progress | 0 | | project_id | 80db9a28c916458ab3d4f84b9eb315d0 | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2017-11-06T13:35:14Z | | user_id | 08fb93292c9341f78efb3d454a9f4cd8 | | volumes_attached | | +-------------------------------------+-----------------------------------------------+ [root@kolla kolla-ansible]# openstack server list +--------------------------------------+-------+--------+----------+--------+---------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------+--------+----------+--------+---------+ | 1d269c03-1ee4-44ab-8a12-9ecaa6cdcd86 | demo1 | BUILD | | cirros | m1.tiny | +--------------------------------------+-------+--------+----------+--------+---------+ [root@kolla kolla-ansible]# openstack server list +--------------------------------------+-------+--------+--------------------+--------+---------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------+--------+--------------------+--------+---------+ | 1d269c03-1ee4-44ab-8a12-9ecaa6cdcd86 | demo1 | ACTIVE | demo-net=10.0.0.10 | cirros | m1.tiny | +--------------------------------------+-------+--------+--------------------+--------+---------+
參考文檔
http://docs.openstack.org/developer/kolla-ansible/quickstart.html
http://www.cnblogs.com/lienhua34/p/4922130.html