基础架构自动化是编写脚本环境的过程-从安装操作系统,到在实例上安装和配置服务器,再到配置实例和软件之间的通信方式,等等。 通过脚本环境,您可以将相同的配置应用于单个节点或数千个节点。
基础架构自动化也有其他名称:配置管理,IT管理,供应,脚本化基础架构,系统配置管理以及许多其他重叠术语。 关键是相同的:您将基础结构及其配置描述为一个脚本或一组脚本,以便可以以不那么容易出错的方式复制环境。 基础架构自动化为开发和运营带来了灵活性,因为任何授权的团队成员都可以在将良好的开发实践(例如自动化测试和版本控制)应用于基础架构的同时修改脚本。
在过去的十年中,出现了一些开源和商业工具来支持基础设施自动化。 开源工具包括Bcfg2,CFEngine,Chef和Puppet。 它们可以在云以及虚拟和物理环境中使用。 在本文中,我将重点介绍最受欢迎的开源基础结构自动化工具:Chef和Puppet。 尽管您不会学习这两种工具的复杂性,但您将了解它们之间的异同以及一些代表性示例。 有关设置和使用基础架构自动化工具的更详细的示例,本文提供了一个随附的视频 ,该视频显示了如何在云环境中运行Puppet。
Chef和Puppet都在脚本环境中使用Ruby域特定语言(DSL)。 Chef表示为内部 Ruby DSL,Puppet用户主要使用其外部 DSL(也用Ruby编写)。 这些工具倾向于在Linux®系统自动化中更经常使用,但它们也支持Windows。 Puppet具有比Chef更大的用户基础,并且为较旧的过时操作系统提供更多支持。 使用Puppet,您可以设置对其他任务的依赖性。 两种工具都是幂等的 ,这意味着无论您运行多少次,都可以通过相同的配置获得相同的结果。
厨师
自2009年以来,Chef就已经存在了。它受到Puppet和CFEngine的影响。 Chef支持多种平台,包括Ubuntu,Debian,RHEL / CentOS,Fedora,Mac OS X,Windows 7和Windows Server。 通常将它描述为更易于使用-特别是对于Ruby开发人员,因为Chef中的所有内容都定义为Ruby脚本,并且遵循开发人员习惯于使用的模型。Chef拥有热情的用户群,并且Chef社区正在Swift发展同时开发食谱供其他人使用。
这个怎么运作
在Chef中,三个核心组件相互交互-Chef服务器 , 节点和Chef工作站 。 Chef运行食谱 , 食谱由在节点上执行自动化步骤(称为操作)的食谱组成,例如安装和配置软件或添加文件。 Chef服务器包含用于管理多个节点的配置数据。 当请求时,节点将下拉存储在Chef服务器上的配置文件和资源。 资源的示例包括文件,包,cron和execute。
用户使用名为Knife的 Chef命令行界面与Chef服务器进行交互。 节点可以具有一个或多个角色 。 角色定义节点的属性 (特定于节点的设置)和配方,并可以在多个节点上应用它们。 食谱可以运行其他食谱。 节点中的配方(称为运行列表)按照列出的顺序执行。 Chef工作站是具有本地Chef存储库和Knife的实例。
表1描述了Chef的核心组件:
表1. Chef组件
零件 | 描述 |
---|---|
属性 | 描述节点数据,例如IP地址和主机名。 |
厨师客户 | 确实代表一个节点工作。 单个Chef客户端可以为多个节点运行配方。 |
主厨独奏 | 允许您在没有厨师服务器的情况下运行厨师食谱。 |
食谱 | 包含自动化基础架构所需的所有资源,并且可以与其他Chef用户共享。 食谱通常包含多个食谱。 |
资料袋 | 包含节点和角色使用的全局可用数据。 |
刀 | 由系统管理员用于将配置更改上载到Chef服务器。 刀用于通过SSH在节点之间进行通信。 |
管理控制台 | Chef服务器的Web界面,用于管理节点,角色,菜谱,数据包和API客户端。 |
节点 | 运行Chef客户端的主机。 从Chef的角度来看,节点的主要特征是其属性和运行列表。 节点是应用配方和角色的组件。 |
奥海 | 检测有关您的操作系统的数据。 它可以独立使用,但是其主要目的是向Chef提供节点数据。 |
食谱 | Chef中的基本配置。 配方封装了按定义的顺序执行以配置节点的资源集合。 |
存储库(Chef存储库) | 托管用于管理Chef的系统的菜谱,角色,配置文件和其他工件的地方。 |
资源资源 | 您正在节点上配置的东西的跨平台抽象。 例如,可以在不同的OS平台上对用户和软件包进行不同的配置。 Chef从用户那里抽象了执行此操作的复杂性。 |
角色 | 一种对相似节点的相似特征进行分组的机制。 |
服务器(Chef服务器) | 服务器配置的集中存储库。 |
例子
清单1演示了在Tomcat食谱一部分的配方中如何使用service
资源。 您会看到可以使用诸如Chef之类的工具来进行特定于平台的配置并管理服务器配置。
清单1.主厨食谱
service "tomcat" do
service_name "tomcat6"
case node["platform"]
when "centos","redhat","fedora"
supports :restart => true, :status => true
when "debian","ubuntu"
supports :restart => true, :reload => true, :status => true
end
action [:enable, :start]
end
清单2定义了Tomcat食谱的属性。 在此示例中,我为Tomcat服务器定义了一些外部端口以使其可用。 您可能会看到的其他类型的属性包括目录,选项,用户和其他配置的值。
清单2. Chef属性
default["tomcat"]["port"] = 8080
default["tomcat"]["ssl_port"] = 8443
default["tomcat"]["ajp_port"] = 8009
与外部DSL相比,Chef 扩展了Ruby语言,从而提供了一种可将配置一次应用于多个节点的模型。 Chef使用的命令式模型没有显式的依赖项管理,因此拥有更多开发背景的人员在编写脚本环境时倾向于使用Chef。
木偶
Puppet自2005年以来一直在使用。许多组织,包括Google,Twitter,Oracle和Rackspace,都使用它来管理其基础架构。 Puppet需要比Chef更为陡峭的学习曲线,它支持多种Windows和* nix环境。 Puppet具有庞大而活跃的用户社区。 它已被成千上万的组织使用,其安装运行了成千上万个实例。
这个怎么运作
Puppet使用主服务器的概念(称为Puppet主服务器),该服务器将节点之间的配置集中化,并根据类型将它们分组在一起。 例如,如果您有一组都使用Jenkins WAR运行Tomcat的Web服务器,则可以将它们组合到Puppet主服务器上。 Puppet代理在系统上作为守护程序运行。 这使您可以将基础结构更改同时部署到多个节点。 它的功能与部署管理器相同,但不部署应用程序,而是部署基础结构更改。
Puppet包含一个称为facter的工具。 Facter保留有关系统的元数据,可用于在服务器之间进行过滤。 例如,您可以使用facter来确定节点的主机名。 MCollective是与Puppet集成的部署工具。 您可以使用MCollective在节点之间部署基础结构更改。
表2列出了Puppet的关键组件:
表2.主要的人偶组件
零件 | 描述 |
---|---|
代理商 | 在节点上运行的守护进程,该守护进程收集有关该节点的信息并将其发送到Puppet主服务器。 |
目录 | 指定如何配置节点的事实汇编。 |
事实 | 关于节点的数据,由该节点发送到Puppet主节点。 |
表现 | 描述资源及其间的依赖关系。 |
模组 | 对相关清单进行分组(在目录中)。 例如,一个模块可以定义如何安装,配置和运行像MySQL这样的数据库。 |
节点 | 由Puppet主服务器管理的主机。 节点的定义类似于类,但包含主机名或完全限定的域名。 |
木偶大师 | 管理所有Puppet节点的服务器。 |
资源资源 | 例如,包,文件或服务。 |
例子
在清单3的示例中,Puppet清单描述了要在节点上安装的软件包。 木偶确定了安装这些软件包的最佳方法和执行顺序。
清单3.用于软件包安装的木偶清单
class system {
package { "rubygems": ensure => "installed" }
package { "make": ensure => "installed" }
package { "gcc": ensure => "installed" }
package { "gcc-c++": ensure => "installed" }
package { "ruby-devel": ensure => "installed" }
package { "libcurl-devel": ensure => "installed" }
package { "zlib-devel": ensure => "installed" }
package { "openssl-devel": ensure => "installed" }
package { "libxml2-devel": ensure => "installed" }
package { "libxslt-devel": ensure => "installed" }
}
清单4中的Puppet清单片段显示了可以在脚本化基础结构中使用的不同资源类型(包和服务)的示例:
清单4. httpd
P清单
class httpd {
package { 'httpd-devel':
ensure => installed,
}
service { 'httpd':
ensure => running,
enable => true,
subscribe => Package['httpd-devel'],
}
}
Puppet使用具有显式依赖项管理的声明性模型。 因此,它往往是具有更多系统管理背景并希望编写其环境脚本的工程师所考虑的第一个工具。
基础架构即代码
在本文中,您通过示例了解到,您的基础结构不再需要专门应用于各个节点的手动操作。 通过自动化您的基础架构,您可以进行上下扩展,而无需进行任何额外的工作。 因为您的基础结构是用脚本建模的,所以您可以像应用程序代码一样对它们进行版本控制和测试。
在下一篇文章中,您将学习创建临时 (或瞬态 )环境的模式和技术,这些环境是在24小时内创建和销毁的,并包含敏捷DevOps附带的丰富心态(即,缺乏稀缺性 )。
翻译自: https://www.ibm.com/developerworks/java/library/a-devops2/index.html