centos安装saltstack？centos7.6安装教程

大家好，感谢邀请，今天来为大家分享一下centos安装saltstack的问题，以及和centos7.6安装教程的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！

如何借助Salt Cloud配置AWS EC2实例

SaltStack项目于2011年启动。我们在2013年8月首次刊文介绍SaltStack；就在同一年，在拥有最多“关闭的问题”（issues closed）和“合并拉拽请求”（merged pull request）类别的所有公共软件库当中，GitHub的Octoverse在saltstack/salt软件库中名列第三。

2013年11月8日，Salt Cloud被并入到主Salt软件库，成为SaltStack 2014.1.0 Hydrogen版本的一部分。

Salt Cloud这款工具可以用来配置和管理得到支持的云服务提供商内部和之间的云服务器。比如说，系统管理员通过使用Salt Cloud配置的单个节点，就可以配置位于亚马逊网络服务（AWS）美国西海岸地区的五台新的Web服务器，配置位于Rackspace伦敦地区的三台新的应用服务器。

本文介绍了如何借助Salt Cloud配置亚马逊弹性计算云（EC2）实例；文章还介绍了如何使用Salt Cloud的地图（Map）功能，借助单单一个命令，配置几个并行的实例。

不过本文中所用的发行版是CentOS；除了安装方面的一些微小细节外，本文探讨的详细步骤适用于EC2上、可以运行最新版SaltStack的任何发行版。

除了AWS EC2外，SaltStack还支持其他的云服务提供商，比如Digital Ocean、GoGrid、谷歌计算引擎（Google Compute Engine）、OpenStack和Rackspace。功能矩阵列出了一张表，显示了针对每家云服务提供商的支持功能。

来自运行salt-cloud的实例、Salt Cloud命令行工具以及所配置实例的所有交互都通过SSH协议来实现。Salt Cloud不需要Salt Master守护进程。如果你想要使用Salt状态和模块来管理所配置实例，就需要设置Salt Master，这不在本文的探讨范围之内。

安装

salt-cloud命令行工具随作为EPEL一部分的salt-master 2014.1.0 RPM程序包一同发行。它应该可以安装在EC2里面的实例上。

$ yum install salt-master

“SaltStack”团队管理Ubuntu个人软件包存档（PPA），它含有所有最新版本的Ubuntu。Salt还出现在标准的openSUSE 13.1版本中。docs.saltstack.com提供了详尽具体的说明文档，含有说明步骤，介绍了如何针对其他发行版和平台安装Salt。

salt-cloud确实依赖Apache libcloud，这是一种可与30多家云服务提供商兼容的python库。可以使用pip命令，安装稳定版本的apache-libcloud。

$ pip install apache-libcloud

要是没有pip命令，你可能需要先安装python-pip程序包。如果你想把apache-libcloud安装在孤立的Python环境中，首先要检查virtualenv（虚拟环境）。

EC2安全组

salt-cloud配置的每个实例都需要属于至少一个AWS EC2安全组（Security Group），该安全组允许来自端口22/tcp、始发于运行salt-cloud的实例的入站流量。我在之前的一篇文章中已介绍了如何使用awscli工具创建安全组，

$ aws ec2 create-security-group\--group-name MySecurityGroupSaltCloudInstances\--description"The Security Group applied to all salt-cloud instances"$ aws ec2 authorize-security-group-ingress\--group-name MySecurityGroupSaltCloudInstances\--source-group MySecurityGroupSaltCloud\--protocol tcp--port 22

authorize-security-group-ingress命令允许MySecurityGroupSaltCloud安全组里面的任何EC2节点通过端口22/tcp，访问MySecurityGroupSaltCloudInstances里面的其他任何EC2节点。在我的安装环境中，运行salt-cloud的实例属于MySecurityGroupSaltCloud安全组。你需要创建一个安全组，运行salt-cloud的实例将属于该安全组。

EC2密钥对

salt-cloud依赖SSH协议上传和运用salt-bootstrap自动安装脚本。需要针对运行salt-cloud的实例生成SSH公钥和私钥。公钥同样需要上传到AWS EC2，成为密钥对。我在前一篇文章中也介绍了如何实现这一步。

想创建SSH私钥和SSH公钥：

$ ssh-keygen-f/etc/salt/my_salt_cloud_key-t rsa-b 4096$ aws ec2 import-key-pair--key-name my_salt_cloud_key\--public-key-material

Salt Cloud配置文件

Salt Cloud配置文件（Profile）为一组将由salt-cloud配置和管理的salt minion定义了一些基本的配置项。

在下面的/etc/salt/cloud.profiles文件里面，我已创建了一个配置文件，名为base_ec2_private；该配置文件使用我将在接下来定义的my_ec2_ap_southeast_2_private_ips提供商。我需要指定的另外唯一一个选项是minion将运行的那个映像的亚马逊机器映像（AMI） ID。ami-e7138ddd是CentOS.org发行、在AWS ap-southeast-2区域里面可用的CentOS 6.5映像的AMI ID。

base_ec2_private: provider: my_ec2_ap_southeast_2_private_ips image: ami-e7138ddd

Salt Cloud提供商

salt-cloud提供商定义了AWS EC2实例使用的一系列属性。

下面是我用来定义my_ec2_ap_southeast_2_private_ips提供商的/etc/salt/cloud.providers文件。该提供商被我的my base_ec2_private配置文件所使用。

my_ec2_ap_southeast_2_private_ips:

# salt-cloud应连接到的IP地址 ssh_interface: private_ips# AWS登录信息 id:@AWS_ACCESS_KEY_ID@ key:'@AWS_SECRET_ACCESS_KEY@'# SSH密钥 keyname: my_salt_cloud_key private_key:/etc/salt/my_salt_cloud_key# AWS位置 location: ap-southeast-2 availability_zone: ap-southeast-2a# AWS安全组 securitygroup: MySecurityGroupSaltCloudInstances# AWS AMI size: Micro Instance# minion被销毁后，删除AWS根卷 del_root_vol_on_destroy: True#本地用户 ssh_username: root#一旦销毁，就更名 rename_on_destroy: True provider: ec2

我定义了用@符号封装的几个属性，它们需要上传，以适合你的环境。

@AWS_ACCESS_KEY_ID@：AWS Access Key ID属于拥有足够EC2权限以配置新实例的IAM帐户。虽然salt-cloud确实支持AWS身份与访问管理（IAM）角色，但它们只适用于所配置的EC2 minion。静态的AWS访问密钥和秘密密钥仍被salt-cloud用来部署minion。

@AWS_SECRET_ACCESS_KEY@：属于AWS Access Key ID的AWS秘密密钥。

创建第一个salt-cloud minion

首先，你可能需要在SSH代理里面设置SSH密钥。

$ eval `ssh-agent`$ ssh-add/etc/salt/my_salt_cloud_key

下一步，调用传递配置文件名称的salt-cloud，其名称与你在/etc/salt/cloud.profiles里面配置的相一致，最后一个参数是新minion的名称。

$ salt-cloud--profile=base_ec2_private my_first_minion

salt-cloud使用SSH代理获取salt-bootstrap自动安装脚本，该脚本会安全地检测minion发行版，安装salt-minion程序包，如果你已设置好salt-master，还可以预先为salt-master提供minion的密钥。

如果成功，我们可以使用salt-cloud查询实例：

$ salt-cloud--action=show_instance my_first_minion

salt-cloud还支持其他操作，比如查询和设定AWS EC2标记：

$ salt-cloud--action=get_tags my_first_minion$ salt-cloud--action=set_tags my_first_minion environment=devel\ role=webserver

我们可以启用和禁用EC2终止保护（Termination Protection）：

$ salt-cloud--action=show_term_protect my_first_minion$ salt-cloud--action=enable_term_protect my_first_minion$ salt-cloud--action=disable_term_protect my_first_minion

我们还可以重启minion：

$ salt-cloud--action=reboot my_first_minion

如果你已设置好了salt-master，应该能够通过salt命令行，运行标准的salt模块：

$ salt my_first_minion cmd.run'/sbin/ip address show'

当然了，如果salt-master状态已设置好，你可以运用state.highstate。

$ salt my_first_minion state.highstate

最后，我们可以使用--destroy选项销毁实例：

$ salt-cloud--destroy my_first_minion

Salt Cloud地图

我们前面已探讨了借助salt-cloud配置单个的EC2实例。现在，我们可以延伸开来，使用Slat Cloud地图（Maps），借助单单一个salt-cloud命令，创建多个实例。

在/etc/salt/cloud.map文件里面，我定义了三台都继承base_ec2_private配置文件的Web服务器。

base_ec2_private:- web1_prod- web2_prod- web3_prod

想配置所有三个实例，我只需要传递--map选项连同地图文件的位置。另外包括--parallel，地图里面的所有实例将同时被配置。

$ salt-cloud--map=/etc/salt/cloud.map--parallel

一旦配置完毕，我们就可以借助salt-cloud，查询地图里面的所有实例。

$ salt-cloud--map=/etc/salt/cloud.map--query

想终止地图里面的所有服务器，我们只要传递--destroy选项。

$ salt-cloud--map=/etc/salt/cloud.map–destroy

OpenStack部署都有哪些方式

对于每一个刚接触到OpenStack的新人而言，安装无疑是最困难的，同时这也客观上提高了大家学习OpenStack云计算的技术门槛。想一想，自己3年前网上偶然接触到OpenStack时，一头茫然，手动搭建一个多节点环境时居然用了3个星期。

时至今日，真是感触颇多，从某种角度而言，也很庆幸当时自己并未因困难而放弃OpenStack，否则，应该是去做其他领域了吧！

言归正传，咱们就来数落数落部署OpenStack都有哪些方式吧。这里，我们根据使用者群体的不同类型来进行分类和归纳：

个人使用方面

DevStack

无疑，在可预见的未来时间内，DevStack仍将是众多开发者们的首选安装方式或工具。该方式主要是通过配置参数，执行shell脚本来安装一个OpenStack的开发环境。

Github:

Wiki:

Rdo

Rdo是由Red Hat开源的一款部署OpenStack的工具，同DevStack一样，支持单节点和多节点部署。但Rdo只支持CentOS系列的操作系统。需要注意的是，该项目并不属于OpenStack官方社区项目。

Docs：

手动部署

手动部署all-in-one、multi-node、multi-HA-node环境。

其他

企业、团体方面

Puppet

Puppet由Ruby语言编写。应当说，Puppet是进入OpenStack自动化部署中的早期一批项目，历史还算悠久。目前，它的活跃开发群体们是Red hat、 Mirantis、UnitedStack等。

Red

hat自从收购Ansible之后，如今仍然保持强势劲头在Puppet

OpenStack项目中的Commit数量和质量，其技术实力不容小觑；Mirantis出品的Fuel部署工具中，大量的模块代码便使用的是

Puppet。就国内而言，UnitedStack是Puppet社区贡献和使用的最大用户。

Github：

Governance：

Wiki：

Ansible

Ansible

是新近出现的自动化运维工具，已被Red

Hat收购。基于Python开发，集合了众多运维工具（puppet、cfengine、chef、saltstack等）的优点，实现了批量系统配

置、批量程序部署、批量运行命令等功能，它一方面总结了Puppet的设计上的得失，另一方面也改进了很多设计。比如是基于SSH方式工作，故而不需要在

被控端安装客户端。使得在和OpenStack结合上没有历史包袱，更加能够轻装上阵，未来发展潜力不容小觑号称是“你一直寻找的下一代Iaas”的

Zstack，使用到的部署工具也是基于Ansible。

Openstack-ansible项目，最早是由老牌Rackspace公司在Launchpad官网上注册。

在最新的Ansible OpenStack项目社区Commit贡献中，Rackspace也可谓是遥遥领先，而紧随其后的是Red Hat、国内九州云等公司。

Github：

SaltStack

SaltStack

也是一款开源的自动化部署工具，基于Python开发，实现了批量系统配置、批量程序部署、批量运行命令等功能，和Ansible也是挺相近的。不同之一

是，由于SaltStack的master和minion认证机制和工作方式，需要在被控端安装minion客户端，在加之其他原因，自然和

Ansible相比，其优缺点便很明显了。

需要注意的是，使用Saltstack部署OpenStack，并不属于OpenStack社区项目。目前，主要还是处于用户自研自用的阶段。据笔者所知，目前国内的携程应该是使用Saltstack部署OpenStack规模最大的用户。

Saltstack部署OpenStack示例：

Saltstack部署OpenStack模块：

TripleO

Tripleo

项目最早由HP于2013.4在launchpad上注册BP。用于完成OpenStack的安装与部署。TripleO全称“OpenStack On

OpenStack”，意思即为“云上云”，可以简单理解为利用OpenStack来部署OpenStack，即首先基于V2P(和P2V相反，也就是指

把虚拟机的镜像迁移到物理机上)的理念事先准备好一些OpenStack节点（计算、存储、控制节点）的镜像，然后利用已有openstack环境的裸机

服务Ironic项目去部署裸机，软件安装部分的diskimage-builder，最后通过Heat项目和镜像内的DevOps工具(Puppet

Or Chef)再在裸机上配置运行openstack。

和其他部署工具不同的是，TripleO利用OpenStack本来的基础设施来部署OpenStack，基于Nova、 Neutron、Ironic和Heat，来自动化部署和伸缩OpenStack集群。

应

当确切的说，TripleO项目属于当前OpenStack社区主推的“Big Tent”开发模式下的big tent

project（OpenStack下的项目分为三种，core project: nova/neutron等核心项目，big tent

project:非核心项目，但也被OpenStack基金会接受；第三种就是其它项目，只是放在OpenStack下，但是社区还没有接受）。

在该项目的社区Commit贡献上，Red hat可谓是遥遥领先，而紧随其后的是IBM等公司。

Wiki：

Kolla

在

国内一些互联网资料上，常看到关于kolla是TripleO项目的一部分这样的描述，其实是不准确的。真实的是，Kolla项目起源于Tripleo项

目，时至今日，与它没有任何关系（虽然它们的目标都是做自动化部署，但走的道路却不同）。比之于Tripleo和其他部署工具，Kolla走的是

docker容器部署路线。

kolla项目起源于TripleO项目，聚焦于使用docker容器部署OpenStack服务。该项目由

Cisco于2014年9月提出，是OpenStack的孵化项目。当前Kolla项目在Kollaglue

repo提供了以下服务的docker镜像。# docker search kollaglue

Kolla的优势和使用场景，体现在如下几个方面：

原子性的升级或者回退OpenStack部署；

基于组件升级OpenStack；

基于组件回退OpenStack；

这里，我们予以拆分来理解：

Kolla

的最终目标是为OpenStack的每一个服务都创建一个对应的Docker Image，通过Docker

Image将升级的粒度减小到Service级别，从而使升级时，对OpenStack影响能达到最小，并且一旦升级失败，也很容易回滚。升级只需要三

步：Pull新版本的容器镜像，停止老版本的容器服务，然后启动新版本容器。回滚也不需要重新安装包了，直接启动老版本容器服务就行，非常方便。

Kolla是通过Docker Compose来部署OpenStack集群的，现在主要是针对裸机部署的，所以在部署Docker Container时，默认的网络配置都是Host模式。

首

先，只需要通过一个命令就可以把管理节点部署完成，这个命令是调用Docker

Compose来部署OpenStack的所有服务，然后我们可以在每一个计算节点上通过Docker

Compose安装计算节点需要的服务，就能部署一个OpenStack集群。因为Kolla的Docker

Image粒度很小，它针对每个OpenStack服务都有特定的Image，所以我们也可以通过Docker

Run来操作某个具体的OpenStack服务。

目前，我所在的公司九州云的一位同事近日获得提名成为Kolla项目Core。为OpenStack社区中增添了一份来自于中国的力量。

Fuel

Fuel

是针对OpenStack生产环境目标

（非开源）设计的一个端到端”一键部署“的工具，大量采用了Python、Ruby和JavaScript等语言。其功能含盖自动的PXE方式的操作系统

安装，DHCP服务，Orchestration服务和puppet配置管理相关服务等，此外还有OpenStack关键业务健康检查和log

实时查看等非常好用的服务。

Fuel，这款让很多人即爱且痛的工具，在国内外都很盛名。爱的原因是，它确实很棒；痛的原因是，要想彻底掌握

它，可不是一件容易事（各个模块集成度高、使用技术复杂）。既然提到Fuel，自然不能不提它的父母——Mirantis。Mirantis是一家技术实

力非常雄厚的OpenStack服务集成商，他是社区贡献排名前5名中唯一一个靠OpenStack软件和服务盈利的公司。同时，Fuel的版本节奏也很

快，平均每半年就能提供一个相对稳定的社区版。

从和笔者接触到的一些情况来看，国内研究、使用Fuel的个人、群体还是为数不少的。不少国内OpenStack初创公司的安装包就是基于Fuel去修改的。