如何使用 Ansible 管理您的工作站配置

在本系列的第一篇文章中,了解为您的笔记本电脑和台式机设置配置管理的基础知识。
426 位读者喜欢这篇文章。
Jump-start your career with open source skills

Opensource.com

配置管理是服务器管理和 DevOps 非常重要的一个方面。“基础设施即代码”方法使得在各种配置中部署服务器以及动态扩展组织的资源以满足用户需求变得容易。但是,对于希望自动化设置自己的笔记本电脑和台式机(工作站)的个人管理员,关注较少。

在本系列中,我将向您展示如何通过 Ansible 自动化您的工作站设置,这将使您在想要或需要重新加载机器时轻松恢复您的完整配置。此外,如果您有多个工作站,您可以使用相同的方法使每个工作站上的配置相同。在第一篇文章中,我们将为我们的个人或工作计算机设置基本的配置管理,并为本系列的其余部分奠定基础。到本文结束时,您将拥有一个可立即受益的工作设置。每篇文章都将自动化更多内容,复杂性也会增加。

[阅读本系列的第二部分。]

为什么选择 Ansible?

有许多配置管理解决方案可用,包括 Salt Stack、Chef 和 Puppet。我更喜欢 Ansible,因为它在资源利用方面更轻量级,其语法更易于阅读,并且如果正确利用,它可以彻底改变您的配置管理。Ansible 的轻量级特性与手头的主题尤其相关,因为我们可能不想仅仅为了自动化笔记本电脑和台式机的设置而运行整个服务器。理想情况下,我们需要一些快速的东西;一些我们可以用来快速启动和运行的东西,如果我们需要恢复我们的工作站或在多台机器之间同步我们的配置。我针对 Ansible 的特定方法(我将在本文中演示)非常适合这一点——无需维护服务器。您只需下载您的配置并运行它。

我的方法

通常,Ansible 从中央服务器运行。它利用清单文件,这是一个文本文件,其中包含我们希望 Ansible 管理的所有主机及其 IP 地址或域名的列表。这对于静态环境非常有用,但对于工作站来说并不理想。原因是我们真的不知道我们的工作站在任何时刻的状态。也许我关闭了我的台式机,或者我的笔记本电脑可能处于挂起状态并放在我的包里。在任何一种情况下,Ansible 服务器都会抱怨,因为它无法访问我的离线机器。我们需要一种更按需的方法,我们将通过使用 ansible-pull 来实现这一点。ansible-pull 命令是 Ansible 的一部分,它允许您从 Git 仓库下载您的配置并立即应用它。您无需维护服务器或清单列表;您只需运行 ansible-pull 命令,向其提供 Git 仓库 URL,它就会为您完成剩下的工作。

开始入门

首先,在您想要管理的计算机上安装 Ansible。一个问题是许多发行版都附带旧版本。根据我的经验,我可以告诉您,您肯定需要最新的可用版本。新功能会非常频繁地引入 Ansible,如果您运行的是旧版本,您在网上找到的示例语法可能无法正常工作,因为它使用的是您安装的版本中未实现的功能。即使是点发布也有很多新功能。其中一个例子是 dconf 模块,它是 Ansible 2.4 的新功能。如果您尝试使用利用此模块的语法,除非您拥有 2.4 或更高版本,否则它将失败。在 Ubuntu 及其衍生版本中,我们可以使用官方个人软件包存档 (PPA) 轻松安装最新版本的 Ansible。以下命令将完成这项工作

sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

如果您没有使用 Ubuntu,请查阅 Ansible 的文档,了解如何为您的平台获取它。

接下来,我们需要一个 Git 仓库来保存我们的配置。满足此要求的最简单方法是创建一个空仓库,或者如果您有您自己的 Git 服务器,则可以使用它。为了简单起见,我假设您正在使用 GitHub,因此如果您使用其他服务,请调整命令。在 GitHub 中创建一个仓库;您将获得一个类似于这样的仓库 URL

git@github.com:<your_user_name>/ansible.git

将该仓库克隆到您的本地工作目录(忽略任何抱怨仓库为空的消息)

git clone git@github.com:<your_user_name>/ansible.git

现在我们有了一个可以使用的空仓库。将您的工作目录更改为仓库内部(例如 cd ./ansible),并在您喜欢的文本编辑器中创建一个名为 local.yml 的文件。将以下配置放在该文件中

- hosts: localhost
  become: true
  tasks:
  - name: Install htop
    apt: name=htop

您刚刚创建的文件称为剧本 (playbook),安装 htop(我随意选择的一个包作为示例)的指令称为 play。剧本本身是一个 YAML 格式的文件,YAML 是一种简单易读的标记语言。YAML 的完整演练超出了本文的范围,但您不需要对其有专业的理解即可熟练使用 Ansible。配置易于阅读;只需查看此文件,您就可以轻松地了解到我们正在安装 htop 包。特别注意最后一行的 apt 模块,它仅适用于基于 Debian 的系统。如果您使用的是 Red Hat 平台,您可以将它更改为 yum 而不是 apt,如果您使用的是 Fedora,则将其更改为 dnfname 行只是提供有关我们任务的信息,并将显示在输出中。因此,您需要确保名称具有描述性,以便在需要排除多个 play 的故障时易于查找。

接下来,让我们将新文件提交到我们的仓库

git add local.yml
git commit -m "initial commit"
git push origin master

现在我们的新剧本应该出现在我们在 GitHub 上的仓库中。我们可以使用以下命令应用我们创建的剧本

sudo ansible-pull -U https://github.com/<your_user_name>/ansible.git

如果执行正确,htop 包应该安装在您的系统上。您可能在开头附近看到一些警告,抱怨缺少清单文件。这没关系,因为我们没有使用清单文件(对于这种用途,我们也不需要)。在输出的末尾,它将为您概述它所做的事情。如果 htop 安装正确,您应该在输出的最后一行看到 changed=1

这是如何工作的?ansible-pull 命令使用 -U 选项,该选项需要仓库 URL。出于安全目的,我给它提供了仓库 URL 的 https 版本,因为我不希望任何主机对仓库具有写访问权限(默认情况下 https 是只读的)。local.yml 剧本名称是假定的,因此我们不需要为剧本提供文件名——如果它在仓库的根目录中找到名为 local.yml 的剧本,它将自动运行该剧本。接下来,我们在命令前面使用了 sudo,因为我们正在修改系统。

让我们继续向我们的剧本添加其他包。我将添加两个额外的包,使其看起来像这样

- hosts: localhost
  become: true
  tasks:
  - name: Install htop
    apt: name=htop

  - name: Install mc
    apt: name=mc
    
  - name: Install tmux
    apt: name=tmux

我添加了额外的 play(任务)来安装另外两个包,mctmux。您选择让此剧本安装哪些包并不重要;我只是随意选择了这些。您应该安装您希望所有系统都拥有的任何包。唯一的注意事项是您必须预先知道这些包存在于您发行版的仓库中。

在我们提交并应用这个更新后的剧本之前,我们应该清理一下它。它目前也能正常工作,但(说实话)它看起来有点乱。让我们尝试在一个 play 中安装所有三个包。将您的 local.yml 的内容替换为以下内容

- hosts: localhost
  become: true
  tasks:
  - name: Install packages
    apt: name={{item}}
    with_items:
      - htop
      - mc
      - tmux

现在这样看起来更简洁高效了。我们使用 with_items 将我们的包列表整合到一个 play 中。如果我们想添加其他包,我们只需添加另一行,其中包含一个连字符和一个包名称。可以将 with_items 视为类似于 for 循环。我们列出的每个包都将被安装。

将我们的新更改提交回仓库

git add local.yml
git commit -m "added additional packages, cleaned up formatting"
git push origin master

现在我们可以运行我们的剧本,以从新配置中受益

sudo ansible-pull -U https://github.com/<your_user_name>/ansible.git

诚然,这个例子目前并没有做太多事情;它所做的只是安装几个包。您可以使用您的包管理器更快地安装这些包。然而,随着本系列的继续,这些示例将变得更加复杂,我们将自动化更多的事情。到最后,您将创建的 Ansible 配置将自动化越来越多的任务。例如,我使用的配置自动化了数百个包的安装,设置了 cron作业、处理桌面配置等等。

从我们目前完成的工作来看,您可能已经看到了全局。我们所要做的就是创建一个仓库,将一个剧本放在该仓库中,然后利用 ansible-pull 命令拉取该仓库并将其应用到我们的机器上。我们不需要设置服务器。将来,如果我们想更改我们的配置,我们可以拉取仓库,更新它,然后将其推送回我们的仓库并应用它。如果我们正在设置一台新机器,我们只需要安装 Ansible 并应用配置。

在下一篇文章中,我们将通过 cron 和一些其他项目进一步自动化此过程。与此同时,我已经将本文的代码复制到我的 GitLab 仓库中,以便您可以将您的语法与我的语法进行比较。我将在我们进行的过程中更新代码。


想要了解更多关于 Ansible 的信息?在这份免费白皮书中了解如何使用 Ansible 自动化您的 CI/CD 管道。

标签
User profile image.
Jay LaCroix 是一位来自密歇根州的技术专家,专注于 Linux 和开源软件。自 2002 年开始使用 Linux 以来,Jay 一直是 Linux 的忠实粉丝。他目前是一位高级解决方案架构师和自由顾问,喜欢培训和帮助他人使用 Linux 并充分利用这款出色的软件。

4 条评论

引用 如果正确利用,它可以彻底改变您的配置管理。 引用结束

其他解决方案不能做到吗?如果他们也能做到这一点,那么这并不是一个有效的理由来论证 Ansible 更好。由于大多数人没有对工作站使用配置管理程序,他们不存在的程序无法被彻底改变。您未能解释 Ansible 如何“彻底改变”配置管理,因此这听起来只像是从营销部门借用来的毫无意义的技术术语。

引用 无需维护服务器。 引用结束

引用 在 GitHub 上创建一个空仓库,或者如果您有自己的 Git 服务器,则可以使用它。 引用结束

您通过自相矛盾误导了您的读者。

您不需要 ANSIBLE 服务器,但您需要 GIT 服务器:您自己的服务器或由其他人提供的服务器,例如 Github(还有其他免费服务可用)。

很抱歉显得如此负面,但这些差异应该在发布文章之前解决,否则文章提供了有用的 HOWTO 信息。

Ansible 确实可能是工作站管理的最佳选择,但您并没有提出一个好的理由,除了它比其他替代方案更轻量级之外。

Ansible 的革命性本质来自于它是无代理的、不需要服务器、轻量级以及其他优点。如果您想了解 Ansible 提供的所有好处,我建议您查阅有关该主题的其他文章和书籍,以进一步扩展您的知识。

关于不需要服务器,拥有 Github 仓库并不构成维护服务器。Github 的服务器不是由最终用户维护的。我只提到如果您有自己的 Git 服务器可以使用它,因为有些人不希望公开他们的桌面配置,特别是当代码包含任何特权信息时。但服务器不是必需的。事实上,如果您想走那么远,您可以将所有这些代码存储在闪存驱动器上并绕过拥有 Git 仓库。

回复 ,评论者:Mr Awkward (未验证)

Jay,非常感谢这篇文章!我是“那些人”之一,他们 1) 总是运行发行版的最新版本,并且 2) 经常擦除磁盘并进行全新安装。因此,我通常在安装后的几天里突然想起我需要安装包 XYZ。有时这种情况会持续几个月(我似乎每年使用“units”命令大约两次)。我一直希望有一种很好的方法来自动化我的安装后配置,而这看起来可能是一个赢家。

我已经开始考虑如何从当前系统获取包列表,以开始构建我的第一个剧本...

期待您的下一篇文章!

感谢您的这篇文章,因为它真的很有信息量,我喜欢阅读您的文章,我希望我能阅读更多关于这方面的内容。

https://supportwala.net/linux-server

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.