当前位置: 首页 > 科技观察

使用Ansible管理您的工作站:配置自动化

时间:2023-03-13 21:53:46 科技观察

了解如何让Ansible自动将配置应用于一系列台式机和笔记本电脑。Ansible是一个令人惊讶的自动化配置管理工具。它主要用于服务器和云部署,但很少有人关注它在工作站(无论是台式机还是笔记本电脑)上的使用,这也是本系列将重点关注的内容。在本系列的第***部分中,我向您展示了ansible-pull命令的基本用法,我们创建了一个安装了几个包的剧本。它本身用处不大,但为后续的自动化做准备。在这篇文章中,循环将被关闭,而在***部分,我们将有一个完整的工作站自动配置的工作解决方案。现在,我们将设置Ansible的配置,以便将来的更改将自动部署到我们的工作站。在此阶段,假设您已经完成了工作的第一部分。如果没有,请在完成后返回本文。您应该已经有一个GitHub存储库,其中包含第一篇文章中的代码。我们将直接在我们之前创建的部分之上继续。首先,由于我们要做的不仅仅是安装包文件,我们将进行一些重组。我们现在有一个名为local.yml的剧本,内容如下:-hosts:localhostbecome:truetasks:-name:Installpackagesapt:name={{item}}with_items:-htop-mc-tmuxif我们只是想实现一个任务所以上面的配置就足够了。随着我们继续向我们的配置添加内容,这个文件将变得非常大和混乱。***能够针对不同类型的配置将我们的动作游戏分成单独的文件。要实现这一点,请创建一个称为任务簿的东西,它类似于剧本但更精简。让我们在Git存储库中为我们的任务簿创建一个目录。mkdirtaskslocal.yml剧本中的代码很好地转换为用于安装包文件的任务手册。让我们将这个文件移动到我们刚刚创建的任务目录中并重命名它。mvlocal.ymltasks/packages.yml现在,我们编辑packages.yml文件以将其缩小很多,事实上,我们可以缩小除了单个任务本身之外的所有内容。让我们编辑packages.yml如下所示:-name:Installpackagesapt:name={{item}}with_items:-htop-mc-tmux如你所见,它使用相同的语法,但我们删除了Everythingthatis已删除此任务无用且不必要的内容。现在我们有一个专门用于安装包文件的任务簿。但是我们仍然需要一个名为local.yml的文件,因为ansible-pull仍然会寻找这个文件。因此,我们将在存储库的根目录(而不是任务目录)中创建一个全新的文件,其中包含以下内容:-hosts:localhostbecome:truepre_tasks:-name:updaterepositoriesapt:update_cache=yeschanged_when:Falsetasks:-include:tasks/packages.yml这个新的local.yml起到了导入任务簿索引的作用。我在这个文件中添加了一些您在本系列中没有看到的内容。首先,在文件的开头,我添加了pre_tasks,这是一个在所有其他任务之前运行一个任务的任务。在这种情况下,我们对Ansible的命令是让它更新我们发行版软件存储库的索引。以下配置将执行此任务要求:apt:update_cache=yes通常apt模块用于安装包文件,但我们也可以让它更新存储库索引。这样做的目的是为了让我们的每一个动作在Ansible运行的时候都能配合最好的索引。这将确保我们在安装具有旧索引的包时没有问题。因为apt模块只能在Debian、Ubuntu及其衍生版本下工作。如果您正在运行不同的发行版,您将希望使用特定于您的发行版的模块而不是apt。如果您需要使用不同的模块,请参阅Ansible的文档。以下行也需要进一步解释:changed_when:False任务中的这一行阻止Ansible报告操作更改的结果,即使它本身导致系统发生更改。在这里,我们不关心存储库索引是否包含新数据;它几乎总是如此,因为存储库总是在变化。我们不关心apt存储库的变化,因为索引变化是一个正常的过程。如果我们删除这一行,我们将在稍后的过程报告中看到所有更改,即使它只是一个库更新。***忽略此类更改。接下来是常规任务阶段,我们将导入创建好的任务书。每次我们添加另一个任务簿时,添加这一行:tasks:-include:tasks/packages.yml如果你现在运行ansible-pull命令,它应该基本上和上一篇文章一样。不同之处在于我们改进了我们的组织并能够更有效地扩展它。为了让大家省去上篇文章的搜索,ansible-pull命令的语法如下:sudoansible-pull-Uhttps://github.com//ansible.git如果你还记得,ansible-的pull命令拉取Git存储库并应用它包含的配置。现在我们的基础已经到位,我们可以扩展我们的Ansible并添加功能。更具体地说,我们将添加配置以自动将更改部署到工作站。为了支持这个要求,首先我们创建一个特殊帐户来应用我们的Ansible配置。这不是必需的,我们仍然可以在自己的用户下运行Ansible配置。但是使用隔离用户可以将其隔离到后台运行的一个不需要我们参与的系统进程。我们可以使用正常的方式来创建这个用户,但是由于我们使用的是Ansible,所以我们应该尽量避免使用手动更改。相反,我们将创建一个任务簿来处理用户创建任务。此任务簿目前只会创建一个用户,但您可以向此任务簿添加其他操作以创建更多用户。我将此用户命名为ansible,您可以随意命名(如果进行此更改,请务必更新所有出现的情况)。让我们创建一个名为user.yml的任务簿并将以下代码放入其中:-name:createansibleuseruser:name=ansibleuid=900接下来,我们需要编辑local.yml文件以添加此新任务添加手册,像这样:-hosts:localhostbecome:truepre_tasks:-name:updaterepositoriesapt:update_cache=yeschanged_when:Falsetasks:-include:tasks/users.yml-include:tasks/packages.ymlnow当我们运行ansible-pull命令,会在系统中创建一个名为ansible的用户。请注意,我通过uid参数专门为该用户声明了用户ID900。这不是必需的,但建议直接创建UID。由于低于1000的UID不会显示在登录屏幕上,这很好,因为我们根本不需要使用ansibe帐户登录我们的桌面。UID900是任意的;它应该是未使用的低于1000的任何值。您可以使用以下命令验证UID900是否已在您的系统上使用:cat/etc/passwd|grep900但是,您使用此UID应该没有问题,因为它没有在我使用过的任何发行版中使用过所以到目前为止,我还没有遇到它被默认使用。现在,我们有了一个名为ansible的账号,后面在自动化配置中会用到。接下来,我们可以创建实际的cron作业来实现自动化。我们不应该将它放在我们刚刚创建的users.yml文件中,而应该将它分离到自己的文件中。在作业目录中创建一个名为cron.yml的作业簿,并将以下代码放入其中:-name:installcronjob(ansible-pull)cron:user="ansible"name="ansibleprovision"minute="*/10"job="/usr/bin/ansible-pull-o-Uhttps://github.com//ansible.git>/dev/null"cron模块的语法不需要解释。通过此操作,我们创建了一个由用户ansible运行的cron作业。该作业将每10分钟执行一次,这是它将执行的命令:/usr/bin/ansible-pull-o-Uhttps://github.com//ansible.git>/dev/null也,我们可以向这个文件添加额外的cron作业,我们希望将其部署到我们所有的工作站。我们只需要为我们的新cron作业添加额外的操作。但是,仅仅添加定时任务簿是不够的,我们还需要将其添加到local.yml文件中,以便调用。在末尾添加以下行:-include:tasks/cron.yml现在当ansible-pull命令执行时,它会以ansible用户身份每十分钟设置一个新的cron作业。但是,每十分钟运行一次Ansible作业并不是一个好主意,因为它会消耗大量CPU资源。除非我们在Git存储库中更改了某些内容,否则Ansible每十分钟运行一次毫无意义。但是,我们已经解决了这个问题。请注意我在cron作业中添加到ansible-pill命令的-o参数,这是我们以前从未使用过的。此参数告诉Ansible仅在存储库自上次调用ansible-pull后发生更改时才运行。如果库中没有任何变化,它不会做任何事情。这样你就不会无缘无故浪费CPU资源了。当然,拉取存储库时会使用一些CPU资源,但不会像再次应用整个配置时那么多。ansible-pull执行的时候,会遍历playbook和taskbook中的所有task,但至少不会乱跑。即使我们已经添加了所有必要的配置元素来自动化ansible-pull,它仍然无法正常工作。ansible-pull命令需要sudo权限才能运行,这将允许它执行系统范围的命令。但是我们创建的用户ansible并没有设置sudo权限执行命令,所以当cron作业被触发时,会执行失败。通常我们可以使用命令visudo手动设置用户ansible拥有这个权限。然而,我们现在应该以Ansible的方式来做,这将是一个向您展示复制模块如何工作的机会。复制模块允许您将文件从存储库复制到文件系统上的任何位置。在这种情况下,我们将sudo的配置文件复制到/etc/sudoers.d/以便用户ansible可以以管理员权限执行任务。打开users.yml并将以下操作添加到文件末尾。-name:copysudoers_ansiblecopy:src=files/sudoers_ansibledest=/etc/sudoers.d/ansibleowner=rootgroup=rootmode=0440如我们所见,复制模块将文件从我们的存储库复制到任何其他位置。在此过程中,我们获取了一个名为sudoers_ansible的文件(我们稍后将创建该文件)并将其复制为root拥有的/etc/sudoers/ansible。接下来,我们需要创建要复制的文件。在存储库的根目录中,创建一个名为files的目录:mkdirfiles然后,在我们刚刚创建的文件目录中,创建一个名为sudoers_ansible的文件,其中包含以下内容:ansibleALL=(ALL)NOPASSWD:ALL正如我们所做的那样,在/etc/sudoer.d目录中创建一个文件允许我们为特定用户配置sudo权限。现在我们允许ansible用户通过sudo完全控制而无需密码提示。这将允许ansible-pull作为后台任务运行,而无需手动执行。现在,您可以通过再次运行ansible-pull来拉取最新的更改:sudoansible-pull-Uhttps://github.com//ansible.git从这里开始,ansible-pull的cron作业将在后台运行十分钟检查您的存储库是否有更改,如果发现更改,它将运行您的剧本并应用您的任务簿。所以现在我们有了一个完整的工作解决方案。当您第一次设置新的笔记本电脑或台式机时,您必须手动运行ansible-pull命令,但仅限于第一次。第一次后,用户ansible将接管后台后续运行任务。当您想要对您的机器进行更改时,您只需从Git存储库中拉取进行更改,然后将这些更改推回到存储库中。然后,下一次cron作业在每台机器上运行时,它将拉取更改并应用它们。您现在只需进行一项更改,您的所有工作站都会随之更改。尽管这种方法有点不寻常,但通常情况下,您会有一个清单文件,其中包含您的机器列表以及不同机器所属的规则。但是,如文章中所述,ansible-pull方法是管理工作站配置的一种非常有效的方法。我已经在我的Github存储库中更新了这篇文章中的代码,所以请随意浏览和比较您的语法。此外,我将上一篇文章中的代码移到了它自己的目录中。在第三部分中,我们将通过介绍使用Ansible配置GNOME桌面设置来结束本系列。我将向您展示如何设置壁纸和锁屏壁纸、应用桌面主题等等。与此同时,当需要做一些功课时,我们大多数人都有我们使用的各种应用程序的配置文件。它可以是Bash、Vim或您使用的任何其他工具的配置文件。现在你可以尝试通过我们正在使用的Ansible库将这些配置自动复制到你的机器上。在本文中,我向您展示了如何复制文件,因此请尝试一下,看看您是否可以应用这些知识。