kolla-ansible源码分析

时间:2022-12-23 14:13:09

一.kolla-ansible 源码的目录结构

kolla-ansible是从kolla项目分离出来的一个可交付的项目,kolla-ansible负责部署容器化的openstack各个服务和基础设施组件。kolla是用于构建docker镜像

[root@openstack01 ansible]# tree -L 2
.
├── action_plugins //actions_plugins目录下存放的是kolla-ansible自定义的ansible插件
│ ├── merge_configs.py //在playbook内通过使用merge_config来合并配置文件模板,生成openstack各服务的配置文件
│ ├── merge_configs.pyc
│ ├── merge_configs.pyo
│ ├── merge_yaml.py
│ ├── merge_yaml.pyc
│ └── merge_yaml.pyo
├── bifrost.yml
├── certificates.yml
├── destroy.yml
├── group_vars
│ └── all.yml //all.yml文件作为ansible的变量文件,定义了各类配置信息。比如:配置文件路径,网卡,IP,端口号,各服务的开启等。与global.yml文件的差别就是,部分的配置已经在global.yml文件内做了定义,global.yml具有更高优先级
├── inventory //inventory目录下存放的是主机清单
│ ├── all-in-one //all-in-one用于单节点的环境下,指定要部署的主机和该主机的角色
│ └── multinode //multinode用于多节点环境,指定要部署的主机和该主机的角色
├── kolla-host.yml
├── library //kolla-ansible自定义的ansible模块
│ ├── bslurp.py //从远程节点获取文件,并分发到更多节点
│ ├── bslurp.pyc
│ ├── bslurp.pyo
│ ├── kolla_container_facts.py //获取容器的facts信息
│ ├── kolla_container_facts.pyc
│ ├── kolla_container_facts.pyo
│ ├── kolla_docker.py //通过调用docker.py来驱动docker,进行启动容器,删除容器的操作
│ ├── kolla_docker.pyc
│ ├── kolla_docker.pyo
│ ├── kolla_toolbox.py //用于调用kolla_toolbox容器内定义的ansible模块
│ ├── kolla_toolbox.pyc
│ ├── kolla_toolbox.pyo
│ ├── merge_configs.py
│ ├── merge_configs.pyc
│ ├── merge_configs.pyo
│ ├── merge_yaml.py
│ ├── merge_yaml.pyc
│ └── merge_yaml.pyo
├── mariadb_recovery.yml
├── post-deploy.yml
├── roles //在实际的业务使用中,不同的业务需要不同的playbook文件,很难维护,这里ansible采用role的方式对playbook进行目录的结构化处理
│ ├── aodh
│ ├── barbican
│ ├── baremetal
│ ├── bifrost
│ ├── blazar
│ ├── ceilometer
│ ├── ceph
│ ├── ceph_pools.yml
│ ├── certificates
│ ├── chrony
│ ├── cinder
│ ├── cloudkitty
│ ├── collectd
│ ├── common
│ ├── congress
│ ├── designate
│ ├── destroy
│ ├── elasticsearch
│ ├── etcd
│ ├── freezer
│ ├── glance
│ ├── gnocchi
│ ├── grafana
│ ├── haproxy
│ ├── heat
│ ├── horizon
│ ├── influxdb
│ ├── ironic
│ ├── iscsi
│ ├── karbor
│ ├── keystone
│ ├── kibana
│ ├── kuryr
│ ├── magnum
│ ├── manila
│ ├── mariadb
│ ├── memcached
│ ├── mistral
│ ├── mongodb
│ ├── multipathd
│ ├── murano
│ ├── neutron
│ ├── nova
│ ├── nova-hyperv
│ ├── octavia
│ ├── opendaylight
│ ├── openvswitch
│ ├── ovs-dpdk
│ ├── panko
│ ├── prechecks
│ ├── qdrouterd
│ ├── rabbitmq
│ ├── rally
│ ├── redis
│ ├── sahara
│ ├── searchlight
│ ├── senlin
│ ├── skydive
│ ├── solum
│ ├── stop
│ ├── swift
│ ├── tacker
│ ├── telegraf
│ ├── tempest
│ ├── trove
│ ├── vitrage
│ ├── vmtp
│ ├── watcher
│ └── zun
├── site.retry
├── site.yml //roles引用的入口文件
└── stop.yml

二. kolla-ansible代码roles目录分析

这里以roles目录下的neutron目录为例进行说明:

[root@openstack01 roles]# tree neutron -L 1
neutron
├── defaults
├── handlers
├── meta
├── tasks
└── templates

roles/neutron目录下有5个文件夹:

  • default: 定义了部署neutron各服务的各类参数
  • handlers:定义了启动neutron各服务容器的操作
  • meta:定义了部署neutron的依赖
  • tasks:部署neutron的各playbook
  • templates:neutron各服务配置文件的模板

三. neutron目录下的文件分析

[root@openstack01 roles]# tree neutron/
neutron/
├── defaults
│   └── main.yml //作为当前role的变量文件,定义了关于neutron以及neutron各服务的相关参数
├── handlers
│   └── main.yml //创建,启动neutron各服务容器的playbook,但handlers只能在被触发的情况下才会去执行相关被触发的task
├── meta
│   └── main.yml //指定neutron这个role的依赖,从main.yml内容看出实际是依赖于common这个role,也就是在执行neutron的task前,会先去common这个role下执行相关task
├── tasks
│   ├── bootstrap_service.yml //将会启动bootstrap引导容器,用于解决neutron服务所需的依赖配置,在完成后,这些引导容器将被自动删除
│   ├── bootstrap.yml //为neutron创建数据库及数据库用户等
│   ├── check.yml
│   ├── config-neutron-fake.yml
│   ├── config.yml //通过模板为neutron的各个服务生成配置文件
│   ├── deploy.yml
│   ├── ironic-check.yml
│   ├── main.yml //入口执行文件
│   ├── precheck.yml
│   ├── pull.yml
│   ├── reconfigure.yml
│   ├── register.yml
│   └── upgrade.yml
└── templates //templates目录下存放着很多j2格式的文件,他们都是neutron各服务的配置文件模板,这些模板将被config.yml根据需要生成为各服务的配置文件
├── bgp_dragent.ini.j2
├── dhcp_agent.ini.j2
├── dnsmasq.conf.j2
├── fwaas_driver.ini.j2
├── l3_agent.ini.j2
├── lbaas_agent.ini.j2
├── metadata_agent.ini.j2
├── ml2_conf.ini.j2
├── ml2_conf_xenapi.ini.j2
├── neutron-bgp-dragent.json.j2
├── neutron.conf.j2
├── neutron-dhcp-agent.json.j2
├── neutron-l3-agent.json.j2
├── neutron-l3-agent-wrapper.sh.j2
├── neutron-lbaas-agent.json.j2
├── neutron_lbaas.conf.j2
├── neutron-linuxbridge-agent.json.j2
├── neutron-metadata-agent.json.j2
├── neutron-openvswitch-agent.json.j2
├── neutron-openvswitch-agent-xenapi.json.j2
├── neutron-server.json.j2
├── neutron-sriov-agent.json.j2
├── neutron-vpnaas-agent.json.j2
├── neutron-vpnaas-agent-wrapper.sh.j2
├── neutron_vpnaas.conf.j2
├── nsx.ini.j2
├── sriov_agent.ini.j2
└── vpnaas_agent.ini.j2

四. kolla-ansible部署过程代码调用

执行kolla-anisble -i multinode deploy 时调用如下:
kolla-ansible源码分析

执行的命令如下:
kolla-ansible源码分析

这里我们解析下CMD命令:
ansible-playbook -i multinode -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e action=deploy /usr/share/kolla-ansible/ansible/site.yml

其中INVENTORY参数表示multinode文件,主要是指定主机角色 CONFIG_OPTS指定globals.yml,passwords.yml,配置文件目录,主要是指定一些配置相关。EXTRA_OPTS主要是指定执行的动作,PLAYBOOK为roles的入口文件site.yml

因此调用的过程也就是:
kolla-ansible -i multinode deploy ---->调用/usr/share/kolla-ansible/ansible/site.yml ---->根据site.yml文件的task调用执行各role

kolla-ansible源码分析的更多相关文章

  1. ABP源码分析一:整体项目结构及目录

    ABP是一套非常优秀的web应用程序架构,适合用来搭建集中式架构的web应用程序. 整个Abp的Infrastructure是以Abp这个package为核心模块(core)+15个模块(module ...

  2. HashMap与TreeMap源码分析

    1. 引言     在红黑树--算法导论(15)中学习了红黑树的原理.本来打算自己来试着实现一下,然而在看了JDK(1.8.0)TreeMap的源码后恍然发现原来它就是利用红黑树实现的(很惭愧学了Ja ...

  3. nginx源码分析之网络初始化

    nginx作为一个高性能的HTTP服务器,网络的处理是其核心,了解网络的初始化有助于加深对nginx网络处理的了解,本文主要通过nginx的源代码来分析其网络初始化. 从配置文件中读取初始化信息 与网 ...

  4. zookeeper源码分析之五服务端(集群leader)处理请求流程

    leader的实现类为LeaderZooKeeperServer,它间接继承自标准ZookeeperServer.它规定了请求到达leader时需要经历的路径: PrepRequestProcesso ...

  5. zookeeper源码分析之四服务端(单机)处理请求流程

    上文: zookeeper源码分析之一服务端启动过程 中,我们介绍了zookeeper服务器的启动过程,其中单机是ZookeeperServer启动,集群使用QuorumPeer启动,那么这次我们分析 ...

  6. zookeeper源码分析之三客户端发送请求流程

    znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端,这个功能是zookeeper对于应用最重要的特性,通过这个特性可以实现的功能包括配置的 ...

  7. java使用websocket,并且获取HttpSession,源码分析

    转载请在页首注明作者与出处 http://www.cnblogs.com/zhuxiaojie/p/6238826.html 一:本文使用范围 此文不仅仅局限于spring boot,普通的sprin ...

  8. ABP源码分析二:ABP中配置的注册和初始化

    一般来说,ASP.NET Web应用程序的第一个执行的方法是Global.asax下定义的Start方法.执行这个方法前HttpApplication 实例必须存在,也就是说其构造函数的执行必然是完成 ...

  9. ABP源码分析三:ABP Module

    Abp是一种基于模块化设计的思想构建的.开发人员可以将自定义的功能以模块(module)的形式集成到ABP中.具体的功能都可以设计成一个单独的Module.Abp底层框架提供便捷的方法集成每个Modu ...

  10. ABP源码分析四:Configuration

    核心模块的配置 Configuration是ABP中设计比较巧妙的地方.其通过AbpStartupConfiguration,Castle的依赖注入,Dictionary对象和扩展方法很巧妙的实现了配 ...

随机推荐

  1. SqlServer游标简介

    游标实例:             Declare MyCusror Cursor Scroll For Select * From Master_Goods Order By GoodsID Ope ...

  2. [译] EXTENDING JQUERY – 2.2 A simple plugin

    2.2 一个简单的插件示例 jQuery 插件能做任何事情,这个已经由浩如烟海的各类第三方插件如证明.小到只影响一个元素,大到改变多个元素的外观和行为,jQuery 的各种功能等你来扩展. 2.2.1 ...

  3. 日常工作生活中的做人做事道理[持续更新ing]

    1.凡是预则立,不预则废 2.不能用特殊案例说明事情本身的发展规律 3.任务不能拖,需主动出击,想方设法完成 4.工作要有细致化的沟通和安排 5.解决问题和安排任务可以逆向思维的去想 6.问题要举一反 ...

  4. MVC5 + EF6 + Bootstrap3 (9) HtmlHelper用法大全(下)

    文章来源:Slark.NET-博客园 http://www.cnblogs.com/slark/p/mvc5-ef6-bs3-get-started-httphelper-part2.html 上一节 ...

  5. 十二、BOOL冒泡

    int main(){        int a[5] = {5,2,3,4,1};      //需要一个可以告诉我们没有交换的东西      //YES:交换      //NO:未交换     ...

  6. JavaScript 继承的几种模式

    /** * Created by 2016 on 2016/6/5. */ //1.原型链继承 //把子类的原型,定义为超类的实例 通过原型来访问超类的方法和属性 function Person(){ ...

  7. WebLogic部署集群和代理服务器

    应公司要求,最近在学习weblogic集群这块的知识,下面我把我这几天学到的,以及过程中遇到的问题及如何解决的,分享给大家.首先,weblogic是Orcale公司的一款产品,至于其作用,我想就不用我 ...

  8. 在Ubuntu14.04下安装 ffmpeg-2.4.13(处理视频用,将视频保存为图片序列)

    首先在 http://www.ffmpeg.org/olddownload.html 下载 ffmpeg-2.4.13.tar.bz2 : 然后安装 yasm 和 libx264: apt-get i ...

  9. Jmeter4.0----安装教程(2)

    1.检查安装环境 1.1 JDK要求 JDK版本:1.6 + 1.2 检查是否安装JDK win + R 快捷键打开运行,输入 cmd 打开面板,在面板中输入 java -version,出现如下信息 ...

  10. springMVC源码分析--HandlerInterceptor拦截器调用过程(二)

    在上一篇博客springMVC源码分析--HandlerInterceptor拦截器(一)中我们介绍了HandlerInterceptor拦截器相关的内容,了解到了HandlerInterceptor ...