Openstack容器部署工具—kolla-ansible源码解读

2023-05-16

kolla-ansible源码解读

  • kolla介绍
  • 目录结构
    • ansible目录结构
  • 对neutron部署代码解读
    • neutron目录结构
      • default
      • handlers
      • meta
      • tasks
      • templates
  • 命令参数解析

kolla介绍

Kolla-ansible是OpenStack下面的一个自动化部署的项目,基于docker和Ansible实现。
Docker负责镜像制作、容器管理。
Anisble负责环境部署管理。

目录结构

kolla-ansible
├── ansible # Ansible的playbook和roles在这个目录下面
├── doc # 一些文档说明书
├── etc_examples # Openstack部署需要的一些配置模板文件
├── init-runonce # 初始化配置脚本
├── init-vpn # 配置VPNaas的脚本
├── setup.cfg # 安装配置入口文件
└── tools # 和kolla交互的脚本工具

ansible目录结构

ansible
├── action_plugins # 自定义插件,用户yml和config的配置合并
├── filter_plugins # 自定义过滤器插件,用来处理变量数据
├── group_vars # 存放ansible的全局变量,比如:配置文件路径、网卡、IP、端口、服务的开启等。
├── inventory # 主机清单 分为单节点、多节点
├── library # 自定义的ansible模块
	bslurp.py:# 作用是从其他节点拷贝文件然后再复制给其他节点
	kolla_docker.py:# 作用是控制管理docker,通过连接docker API去对容器进行创建、删除等一些操作
	kolla_toolbox.py:# 负责容器的启动以及初始化的操作
	kolla_container_facts.py:# 用于检查容器是否正在运行
├── mariadb_backup.yml
├── mariadb_recovery.yml
├── nova.yml
├── post-deploy.yml
├── roles # 目录下有不同组件业务的playbook、定义的变量以及模板文件等
├── site.yml
└── vmha.yml

对neutron部署代码解读

neutron目录结构

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

default

defaults下的main.yml,作为当前role的变量文件,定义了关于neutron及neutron各服务的相关参数

# 部分代码
---
project_name: "neutron"

# 定义了neutron_server相关的参数,容器名、镜像、卷等
neutron_services:
  neutron-server:
    # 定义neutron_server的容器名
    container_name: "neutron_server"
    # 定义容器使用的镜像
    image: "{{ neutron_server_image_full }}"
    enabled: true
    group: "neutron-server"
    host_in_groups: "{{ inventory_hostname in groups['neutron-server'] }}"
    # 容器和宿主机映射的卷
    volumes:
      - "{{ node_config_directory }}/neutron-server/:{{ container_config_directory }}/:ro"
      - "/etc/localtime:/etc/localtime:ro"
      - "kolla_logs:/var/log/kolla/"
      
# 定义neutron数据库地址等
neutron_database_name: "neutron"
neutron_database_user: "neutron"
neutron_database_address: "{{ kolla_internal_fqdn }}:{{ database_port }}"

# 定义neutron_server镜像名
neutron_server_image_full: "{{ neutron_server_image }}:{{ neutron_server_tag }}"

handlers

handlers下的main.yml文件,实际是创建、启动neutron各服务容器的playbook。但handlers只能在被触发的情况下才会去执行相关被触发的Task。

# 部分内容
# 启动neutron-server容器
---
- name: Restart neutron-server container
  # vars:task下定义的变量
  vars:
    service_name: "neutron-server"
    service: "{{ neutron_services[service_name] }}"
    config_json: "{{ neutron_config_jsons.results|selectattr('item.key', 'equalto', service_name)|first }}"
    neutron_conf: "{{ neutron_confs.results|selectattr('item.key', 'equalto', service_name)|first }}"
    neutron_lbaas_conf: "{{ neutron_lbaas_confs.results|selectattr('item.key', 'equalto', service_name)|first }}"
    neutron_vpnaas_conf: "{{ neutron_vpnaas_confs.results|selectattr('item.key', 'equalto', service_name)|first }}"
    neutron_ml2_conf: "{{ neutron_ml2_confs.results|selectattr('item.key', 'equalto', service_name)|first }}"
    policy_json: "{{ policy_jsons.results|selectattr('item.key', 'equalto', service_name)|first }}"
    neutron_server_container: "{{ check_neutron_containers.results|selectattr('item.key', 'equalto', service_name)|first }}"
  # 调用kolla-docker模块,启动容器
  kolla_docker:
    action: "recreate_or_restart_container"
    # docker的一些共用变量,在group/all.yml内有所定义
    common_options: "{{ docker_common_options }}"
    # 指定容器名
    name: "{{ service.container_name }}"
    # 指定启动容器所需镜像
    image: "{{ service.image }}"
    # 容器内配置文件等和宿主机的映射关系
    volumes: "{{ service.volumes }}"
    # 指定是否开启特权
    privileged: "{{ service.privileged | default(False) }}"
  # when:只有当列表下的所有条件满足时,才执行该task
  when:
    - action != "config"
    - service.enabled | bool
    - service.host_in_groups | bool
    - config_json | changed
      or neutron_conf | changed
      or neutron_lbaas_conf | changed
      or neutron_vpnaas_conf | changed
      or neutron_ml2_conf | changed
      or nsx_ini | changed
      or policy_json | changed
      or neutron_server_container | changed

meta

meta下的main.yml指定了neutron这个role的依赖,从main.yml内容可以看出实际是依赖于common这个role,也就是在执行neutron的task前,会先去common这个role下执行相关task。

tasks

main.yml
在tasks目录下,有很多的yml文件,其中main.yml是入口执行文件。
当我们执行kolla-ansible deploy时,main.yml将调用deploy.yml

---
- include: "{{ action }}.yml"

ironic-check.yml
检查是否满足ironic开启时,neutron_plugin_agent配置为openvswitch,不满足则报错

- fail: msg="neutron_plugin_agent must use openvswitch with Ironic"
  when:
    - enable_ironic | bool
    - neutron_plugin_agent != "openvswitch"

register.yml
register.yml内进行了neutron的service和endpoint创建、project,user,和role创建。

在这里面调用了自定义的kolla_toolbox模块,该模块实际是去kolla_toolbox容器内调用自定义的kolla_keystone_service模块,并把module_args下的变量传递进去。

---
- name: Creating the Neutron service and endpoint
  调用kolla_toolbox模块
  kolla_toolbox:
    # kolla_keystone_service模块在kolla_toolbox容器内的/usr/share/ansible/目录下
    module_name: "kolla_keystone_service"
    # 定义创建service和endpoint所需的变量和值,供kolla_keystone_service模块执行
    module_args:
      service_name: "neutron"
      service_type: "network"
      description: "Openstack Networking"
      endpoint_region: "{{ openstack_region_name }}"
      url: "{{ item.url }}"
      interface: "{{ item.interface }}"
      region_name: "{{ openstack_region_name }}"
      auth: "{{ '{{ openstack_neutron_auth }}' }}"
      endpoint_type: "{{ openstack_interface }}"
    module_extra_vars:
      openstack_neutron_auth: "{{ openstack_neutron_auth }}"
  # run_once:任选单个节点执行一次,不会在所有节点执行
  run_once: True
  # with_items: 对列表进行循环操作
  with_items:
    - {'interface': 'admin', 'url': '{{ neutron_admin_endpoint }}'}
    - {'interface': 'internal', 'url': '{{ neutron_internal_endpoint }}'}
    - {'interface': 'public', 'url': '{{ neutron_public_endpoint }}'}

config.yml
config.yml是通过模板为neutron的各个服务生成配置文件

#确认配置文件的路径存在,不存在则创建
- name: Ensuring config directories exist
  file:
    path: "{{ node_config_directory }}/{{ item.key }}"
    state: "directory"
    recurse: yes
  when:
    - item.value.enabled | bool
    - item.value.host_in_groups | bool
  with_dict: "{{ neutron_services }}"

# 为需要neutron.conf配置文件的服务生成neutron.conf配置文件  
- name: Copying over neutron.conf
  vars:
    service_name: "{{ item.key }}"
    # 定义需要neutron.conf配置文件的服务
    services_need_neutron_conf:
      - "neutron-dhcp-agent"
      - "neutron-l3-agent"
      - "neutron-linuxbridge-agent"
      - "neutron-metadata-agent"
      - "neutron-openvswitch-agent"
      - "neutron-server"
      - "neutron-lbaas-agent"
      - "neutron-vpnaas-agent"
      - "neutron-bgp-dragent"
  # 调用自定义的merge_configs模块
  # merge_configs模块将合并sources下列表的所有模板和文件,生成neutron.conf
  merge_configs:
    sources:
      # sources下列表的文件内,配置项重复时,下方的将覆盖上方的
      - "{{ role_path }}/templates/neutron.conf.j2"
      - "{{ node_custom_config }}/global.conf"
      - "{{ node_custom_config }}/database.conf"
      - "{{ node_custom_config }}/messaging.conf"
      - "{{ node_custom_config }}/neutron.conf"
      - "{{ node_custom_config }}/neutron/{{ item.key }}.conf"
      - "{{ node_custom_config }}/neutron/{{ inventory_hostname }}/neutron.conf"
    dest: "{{ node_config_directory }}/{{ item.key }}/neutron.conf"
  register: neutron_confs
  when:
    - item.value.enabled | bool
    - item.value.host_in_groups | bool
    - item.key in services_need_neutron_conf
  # 对neutron_services下的各服务进行循环
  with_dict: "{{ neutron_services }}"
  # 触发执行handlers下的Restart {{ item.key }} container的task
  # 被触发的task将在所有task执行完成后执行
  notify:
    - "Restart {{ item.key }} container"

bootstrap.yml
bootstrap.yml是为neutron创建数据库及数据库用户等

# 创建neutron的数据库
- name: Creating Neutron database
  # 调用kolla_toolbox模块
  kolla_toolbox:
    module_name: mysql_db
    module_args:
      login_host: "{{ database_address }}"
      login_port: "{{ database_port }}"
      login_user: "{{ database_user }}"
      login_password: "{{ database_password }}"
      name: "{{ neutron_database_name }}"
  # 将执行结果暂存到database
  register: database
  run_once: True
  # 指定在neutron-server主机组的第一个主机上执行该task
  delegate_to: "{{ groups['neutron-server'][0] }}"

# 当上方暂存的database有改变值时,将会去执行bootstrap_service.yml
- include: bootstrap_service.yml
  when: database.changed

bootstrap_service.yml
bootstrap_service.yml将会启动bootstrap引导容器,用于解决neutron服务所需的依赖配置,在完成后,这些引导容器将被自动删除

# 启动bootstrap_neutron容器
- name: Running Neutron bootstrap container
  vars:
    neutron_server: "{{ neutron_services['neutron-server'] }}"
  kolla_docker:
    action: "start_container"
    common_options: "{{ docker_common_options }}"
    detach: False
    environment:
      KOLLA_BOOTSTRAP:
      KOLLA_CONFIG_STRATEGY: "{{ config_strategy }}"
    image: "{{ neutron_server.image }}"
    labels:
      BOOTSTRAP:
    name: "bootstrap_neutron"
    restart_policy: "never"
    volumes: "{{ neutron_server.volumes }}"
  run_once: True
  delegate_to: "{{ groups[neutron_server.group][0] }}"

templates

templates目录下存放着很多j2格式的文件,他们都是neutron各服务的配置文件模板,这些模板将被config.yml根据需要生成为各服务的配置文件。
这里举neutron.conf.j2和neutron-server.json.j2为例进行分析

neutron.conf.j2

[DEFAULT]
# 直接生成配置项
log_dir = /var/log/kolla/neutron

# 将会读取变量文件中api_interface_address和neutron_server_port的值,生成配置项
bind_host = {{ api_interface_address }}
bind_port = {{ neutron_server_port }}

# 将根据if条件判断表达式,符合的表达式将生成对应的配置项
{% if neutron_plugin_agent == 'vmware_nsxv' %}
core_plugin = vmware_nsx.plugin.NsxVPlugin
{% elif neutron_plugin_agent == 'vmware_dvs' %}
core_plugin = vmware_nsx.plugin.NsxDvsPlugin
{% else %}
core_plugin = ml2
service_plugins = {{ neutron_service_plugins|map(attribute='name')|join(',') }}
{% endif %}

neutron-server.json.j2
config.yml将把neutron-server.json.j2生成为config.json,存放在/etc/kolla/neutron-server/目录下,同时该目录下还有neutron.conf等其他neutron-server的配置文件。

在启动容器时/etc/kolla/neutron-server/会被映射到neutron_server容器的/var/lib/kolla/config_files/目录下。

此时生成的config.json的作用就是提供/var/lib/kolla/config_files/目录下neutron-server服务各配置文件与真正配置文件目录:/etc/neutron/ 的链接关系

{
    "command": "neutron-server --config-file /etc/neutron/neutron.conf {% if neutron_plugin_agent in ['openvswitch', 'linuxbridge', 'opendaylight'] %} --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_lbaas.conf --config-file /etc/neutron/neutron_vpnaas.conf {% elif neutron_plugin_agent in ['vmware_nsxv', 'vmware_dvs'] %} --config-file /etc/neutron/plugins/vmware/nsx.ini {% endif %} --config-file /etc/neutron/fwaas_driver.ini",
    "config_files": [
        {
            # 提供/var/lib/kolla/config_files/neutron.conf和/etc/neutron/neutron.conf的链接
            "source": "{{ container_config_directory }}/neutron.conf",
            "dest": "/etc/neutron/neutron.conf",
            "owner": "neutron",
            "perm": "0600"
        }
    ]
}

命令参数解析

ansible-playbook -i $INVENTORY $CONFIG_OPTS $EXTRA_OPTS $PLAYBOOK $VERBOSITY
# -------------------------------------------------
INVENTORY:inventory文件,用于ansible配置主机信息,文件路径在/etc/ansible/hosts/
CONFIG_OPTS:指定globals.yml,password.yml文件
EXTRA_OPTS:指定执行的动作,如’-e kolla_action=deploy’
PLAYBOOK: 为role的入口文件site.yml

例如执行deploy动作的调用过程为kolla-ansible -i all-in-one deploy —> 调用/usr/local/share/kolla-ansible/ansible/site.yml —>根据site.yml文件的task调用执行roles

下面以reconfigure流程分析为例

命令执行参数 kolla-ansible -i /etc/ansible/hosts/ reconfigure -t keystone(组件名称)
具体调用ansible-playbook -i /etc/hosts -e @/etc/ict/globals.yml -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e enable_horizon=false  --tags keystone -e kolla_action=reconfigure -e kolla_serial=0 /usr/share/kolla-ansible/ansible/site.yml

reconfigure操作对应的kolla_action参数为reconfigure,首先去调用site.yml中name为apply role haproxy的tasks

在haproxy role task中,有很多task子任务,此处以keystone为例
在tasks中使用include_role动态导入keystone
- include_role:
    role: keystone
    tasks_from: loadbalancer
  tags: keystone
  when: enable_keystone | bool
  
此处的tasks_from和include_role配合使用,用于指定要从tasks目录中加载的文件,即roles/keystone/tasks/loadbalancer(若tasks_from不指定,默认为main.yml)

- name: "Configure haproxy for {{ project_name }}"
  import_role:
    role: haproxy-config
  vars:
    project_services: "{{ keystone_services }}"
  tags: always
 
使用import_role静态导入haproxy-config

首先,读取keystone_services变量值,赋值给project_services,然后加载roles/haproxy-cofig/tasks/main.yml文件:主要完成的操作就是把本地的haproxy_single_service_listen.cfg.j2模块注入变量后,复制到远程节点目录/etc/kolla/haproxy/services.d/nova-api.cfg

在haproxy中配置好keystone之后,往下会执行到名为Apply role keystone的task
- name: Apply role keystone
  gather_facts: false
  hosts:
    - keystone
    - '&enable_keystone_True'
  serial: '{{ kolla_serial|default("0") }}'
  roles:
    - { role: keystone,
        tags: keystone,
        when: enable_keystone | bool }
       
然后会去执行roles/keystone/tasks/main.yml --> reconfigure.yml --> 主要任务实现都在deploy.yml文件

主要实现:
config.yml:实现keystone相关的检查配置文件
clone.yml:git下载keystone文件
bootstarp.yml: 创建keystone数据库用户权限等配置
meta: flush_handlers:meta任务可影响ansible内部运行方式,这里表示立即执行之前tasks所对应的handler

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

Openstack容器部署工具—kolla-ansible源码解读 的相关文章

  • ubuntu22 安装 qt6

    sudo qt unified linux x64 4 5 2 online run mirror https mirrors aliyun com qt qt6支持 mirror https mirrors aliyun com qt
  • Serdes高速收发器和CDR技术

    目录 一 Serdes高速收发器 二 CDR技术 三 Comma码 K码 今天学习一下 高速收发器 serdes 以及用到的CDR 技术 一 Serdes高速收发器 在传统的源同步传输中 xff0c 数据和时钟分离 xff0c 在速率较低
  • Linux学习--安装软件时提示有未能满足的依赖关系

    这种现象出现的原因是 xff1a xff08 1 xff09 软件需要依赖旧的版本的其他软件 xff0c 但是目前这些都是新的 xff08 2 xff09 要装A xff0c 但是依赖新版本的B xff0c 同时C也依赖了B xff0c 但
  • 解决centos9安装mongodb数据库错误:mongod: error while loading shared libraries: libcrypto.so.1.1: cannot open

    今天进行mongodb数据库在linux进行环境搭建搭建到了一半就开始出现错误 mongod error while loading shared libraries libcrypto so 1 1 cannot open shared
  • [模板] 线性筛素数 (欧拉筛)

    模板 素数筛 P3383 模板 线性筛素数 洛谷 计算机科学教育新生态 题目背景 本题已更新 xff0c 从判断素数改为了查询第 k 小的素数 提示 xff1a 如果你使用 cin 来读入 xff0c 建议使用 std ios sync w
  • WSL+Systemd+Gnome+VcXsrv+CUDAToolkit 安装

    我的版本信息 wsl xff1a PS C Users kirk gt wsl update 正在检查更新 无更新使用 内核版本 xff1a 5 10 102 1 Ubuntu xff1a kirk 64 KirkComputer lsb
  • java上位机

    可以做 xff0c 我有做好的底层通讯程序 xff0c 无需了解通讯协议 xff0c 只要正确配置就可以读出相应的寄存器的值 xff0c 数据类型支持short xff0c int xff0c float等 xff0c 我也有做好的界面 x
  • java上位机的界面

  • Lanelet2高精地图3——LineString(线串)介绍

    LineString线串是两个或者多个点生成的有序数组 xff0c 用来描述地图元素的形状 线串可以通过高度离散化实现 xff0c 来描述任何一维形式 xff0c 并应用于地图上的任何可物理观察到的部分 与样条曲线相比 xff0c 线串可以
  • 香橙派的使用入门无屏幕安装系统

    首先我购买的是香橙派pipc这款开发板价格在105块 xff0c 需要购买散热片以及风扇 电源需要一个5v3安的电源 xff0c 系统有时候会运行不正常 一开始没有屏幕就需要一根usb转ttl的串口线 xff0c 注意不是usb转232 软
  • 香橙派进入系统后设置ip

    Debian 可以配置静态IP 动态IP使Debian连上互联网 用户使用nano编辑器编辑interface网卡配置文件 xff0c 为Debian系统指定本网络中的唯一IP地址 xff0c 使其能上网 方法 步骤 将用户当前目录切换到网
  • 香橙派更改中文界面以及安装输入法

    第一步更新语言包 sudo apt get install locales 第二部选择 sudo dpkg reconfigure locales 找到语言包空格键选中变 最后安装 scim 输入法相关 xff1a apt get inst
  • 香橙派添加启动脚本

    sudo nano etc rc local 后台启动 nohup root frp frpc c root frp frpc ini amp 查询日志 cat nohup out java jar root aaa jar
  • app远程访问plc实现方法

    工业上越来越多的人需要将局域网内的plc数据或者单片机的数据上传到手机app上 xff0c 实现远程的操作监控 实现的方法是借助plc支持modbus协议 xff0c 通过dtu模块实现串口透传到云服务器 xff0c 之后开发手机app实现
  • java访问西门子300plc以及仿真的测试方法

    安装step7软件 支持win7 64位系统 安装仿真软件plc sim 之后以管理员身份运行Nettoplcsim 下bin下的NetToPLCsim
  • Shell 批量拉取docker镜像(当前目录和指定目录)

    批量拉取docker容器镜像 拉取当前文件夹内的容器镜像 xff1a span class token shebang important bin sh span span class token comment 当前路径 span spa
  • docker-compose部署Jenkins+Gitlab CICD

    docker compose 搭建CICD jenkins 43 gitlab 1 修改yum源 xff08 1 xff09 备份原来的yum源 mv etc yum repos d CentOS Base repo etc yum rep
  • kubernetes Pod高级用法-探针

    POD 2高级用法 容器探测详解 所谓容器探测就是我们在里面设置了一些探针 xff0c 或者传感器来获取相应的数据用来判断容器存活与否或者就绪与否的标准 xff1b 目前k8s支持的存活性探测方式和就绪性探测方式都是一样的 xff0c 探针
  • 云原生工程师-1.容器相关

    个人博客地址 一 docker容器相关 1 服务器虚拟机容器的区别基础知识 k8s1 24之前 xff1a docker 1 24之后containerd docker主要制作镜像 xff1a docker build xff0c dock
  • nginx配置后转发没有生效的一个坑个人总结

    一 概述 nginx配置规则还是有点复杂的 xff0c 在此只总结下本人遇到的一个坑与解决方法 xff0c 具体原因还不清楚 二 配置后没有生效的坑 1 首先 xff0c 要访问的url样例是 xff1a http 10 123 123 1

随机推荐

  • 云原生工程师-6.k8s四层负载均衡-Service

    五 k8s四层负载均衡 Service 个人博客 5 1 什么是Service 5 1 1 Service作用 在 kubernetes 中 xff0c Pod 是有生命周期的 xff0c 如果 Pod 重启它的 IP 很有可能会发生变化
  • 云原生工程师-8.statefulset和daemonset

    七 Statefulset 有状态服务 个人博客 7 1 Statefulset相关概念 7 1 1 什么是Statefulset StatefulSet 是有状态的集合 xff0c 管理有状态的服务 xff0c 它所管理的 Pod 的名称
  • 云原生工程师-9.configmap和secret

    九 configmap 配置管理 个人博客 9 1 配置管理中心基本概念 9 1 1 什么是configmap Configmap 是 k8s 中的资源对象 xff0c 用于保存非机密性的配置的 xff0c 数据可以用 key value
  • 云原生工程师-10.K8s安全管理RBAC

    十一 K8s安全管理 xff1a 认证 xff0c 授权 xff0c 准入控制 个人博客 11 1RBAC概述 11 1 1安全管理概述 k8s 对我们整个系统的认证 xff0c 授权 xff0c 访问控制做了精密的设置 xff1b 对于
  • windows 10/11 wsl 安装 ubuntu

    微软官方连接 xff1a WSL 的手动安装步骤 Microsoft Learn 步骤 1 启用适用于 Linux 的 Windows 子系统 需要先启用 适用于 Linux 的 Windows 子系统 可选功能 xff0c 然后才能在 W
  • wsl2 与windows网络互通

    ubuntu wsl2 访问windows 方式一 xff1a ubuntu中查看 ubuntu终端中输入 cat etc resolv conf 显示结果 显示结果 This file was automatically generate
  • requires Python ‘>=3.7‘ but the running Python is 3.6.9 问题

    过程 ubuntu18 04 使用如下命令安装protobuf pip3 install protobuf 安装完毕后报错 protobuf requires Python 39 gt 61 3 7 39 but the running P
  • 拯救者Y9000P突然很卡

    描述 不知道什么原因 xff0c 拯救者Y9000P突然很卡 xff0c 打开windows 任务管理器 查看CPU性能显示速度不到1GHz 解决办法 关机 拔掉所有外设 xff0c 如鼠标 外接键盘 扩展屏幕 和其他设备 xff08 电源
  • windows电脑本通过网线分享无线网络

    条件 设备1 xff1a windows 10系统笔记本 xff08 wifi和网口 xff09 设备2 xff1a 具有网口的计算机 xff08 假设IP为 172 13 100 200 xff09 网线 期望 设备1通过wifi连接无线
  • shell中while内改变外部变量和 < << <<<

    代码 问题代码 使用管道会创建子shell lines 61 34 first line nsecond line nthird line 34 foo 61 0 echo e lines while read line do echo l
  • python 画几何图形

    多边形的画法 def ployon num distance bob color 39 blue 39 39 red 39 bob color 34 red 34 34 yellow 34 for i in range num bob fd
  • 希腊字母及读音

    希腊字母 24个希腊字母分别是 xff1a 拼写 xff1a 阿尔法 Alpha xff1a 贝塔 Beta xff1a 伽玛 Gamma xff1a 德尔塔 Delte xff1a 艾普西龙 Epsilon xff1a 捷塔 Zeta x
  • HexView工具使用

    HexView简介 HexView是Vector开发的一款查看和编辑16进制文件的PC端工具 它可以显示不同文件格式的内容 xff0c 主要是Intel HEX xff0c 摩托罗拉S记录二进制文件或其他汽车制造商特定的文件格式 此外 xf
  • c++ enum class转int

    示例 enum class 定义 span class token keyword enum span span class token keyword class span span class token class name Colo
  • cmake使用CMAKE_INSTALL_PREFIX指定目录的assimp

    编译assimp v5 2 5 CMakeLists txt片段 span class token comment 依赖库 span span class token function sudo span span class token
  • ubuntu14.04下eclipse4.5添加ADT插件构建android开发环境问题:libstdc++.so.6错误

    1 问题描述 xff1a ubuntu14 04 64位下 xff0c eclipse安装adt等android开发工具会提示 xff1a erro where loading shared libraries libstdc 43 43
  • 解决Win10下Linux子系统WSL输入who命令没有响应的内核问题

    系统和工具说明 Ubuntu 16 05 LTSWindows Terminalps xff1a powershellwsl xff1a windows子系统Linux 问题 在做操作系统的Linux的用户监测实验时 xff0c 我发现在W
  • vscode配置opencv环境【完整版】

    1 安装MinGW 并配置环境变量path 在终端输入gcc v验证 2 安装cmake 3 官方下载opencv源码source 在cmake中编译 xff0c 新建D opencv目录 先执行configure再执行generate o
  • 实验六:EIGRP协议配置

    EIGRP协议属于路由协议的一种 xff0c Cisco私有 xff0c 前身是IGRP xff0c 增加的 E 意为 增强型 xff0c 增强型内部网关路由协议 下面通过一个简单的小实验来学习一下EIGRP的相关命令 xff1a 拓扑图
  • Openstack容器部署工具—kolla-ansible源码解读

    kolla ansible源码解读 kolla介绍目录结构ansible目录结构 对neutron部署代码解读neutron目录结构defaulthandlersmetataskstemplates 命令参数解析 kolla介绍 Kolla