一.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 时调用如下:

执行的命令如下:

这里我们解析下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. CSS注意点

    案例: 实际开发中,这样写:

  2. Analysis of FCN

    全卷积网络 FCN 详解   背景 CNN能够对图片进行分类,可是怎么样才能识别图片中特定部分的物体,在2015年之前还是一个世界难题.神经网络大神Jonathan Long发表了<Fully ...

  3. [转载]SMTP的几个端口的比较

    出处:https://blog.csdn.net/zhangyuan12805/article/details/78781330 1. SMTP Port 25: 25口是四个端口中最老的.这是在33 ...

  4. jmeter插件使用说明

    jmeter作为一个开源的接口性能测试工具,其本身的小巧和灵活性给了测试人员很大的帮助,但其本身作为一个开源工具,相比于一些商业工具(比如LoadRunner),在功能的全面性上就稍显不足. 这篇博客 ...

  5. java的四大特性

    java的四大特性是:封装.继承.多态,抽象.

  6. MySQL5.7 多源复制监控脚本

    #!/bin/bash :<<BLOCK Version : v1.0 2018-12-21 MySQL多源复制检测脚本 监控配置放在 $CONFIG_FILE 中,内容如下 #mysql ...

  7. Docker Kubernetes YAML文件常用指令

    YAML文件常用指令 配置文件说明: 定义配置时,指定最新稳定版API(当前为v1). 配置文件应该存储在集群之外的版本控制仓库中.如果需要,可以快速回滚配置.重新创建和恢复. 应该使用YAML格式编 ...

  8. Windows server 2016安装Docker EE

    Windows server 2016安装Docker EE 下载 windows server 2016 180天评估版本. 地址:https://www.microsoft.com/en-us/e ...

  9. Injection的简单辨析

    依赖注入(injection)是一种对任何编程语言都有效的概念.依赖注入背后的一般概念称为控制反转.根据这个概念,类不应该静态配置其依赖项,而应该从外部配置. 如果Java类使用此类的实例,则Java ...

  10. 论文笔记:A Structured Self-Attentive Sentence Embedding

    A Structured Self-Attentive Sentence Embedding ICLR 2017 2018-08-19 14:07:29 Paper:https://arxiv.org ...