Question

我使用Vagrant来自Puppet背景，并且在理解Ansible及其差异方面遇到了一些麻烦。

我的Puppet结构看起来像这样：

puppet
----servers
--------Backend
------------Vagrantfile
----src
--------manifests
------------nodes
----------------development
--------------------backend.pp
--------modules
----------------mysql

安装很简单，cd到Vagrantfile并使用Vagrant启动VM。

现在这是我的Ansible文件夹结构的第一个草稿：

ansible
----servers
--------Backend
------------Vagrantfile
------------ansible.cfg
----sources
--------backend.yml
--------site.yml
--------inventories
------------development
----------------group_vars
--------------------all
--------------------backend
----------------hosts
--------playbooks
--------roles
------------mysql

现在提出问题：

这是Ansible的最佳做法还是离Puppet太近了？
将backend.yml视为Puppet节点清单是否正确？
我应该在哪里放置site.yml和backend.yml？ This example将here放在主目录中，http://leucos.github.io/ansible-files-layout/将其放置在＆＃39;播放＆＃39;目录。有什么区别？
我认为group_vars/backend中的我的group_vars没有被正确使用，我该如何访问它们？

来源：

https://github.com/ansible/ansible-examples

https://github.com/enginyoyen/ansible-best-practises

Answer 1

您找到了几个推荐布局的示例，但未找到the official one。这应该有希望回答你的许多问题，但我也会尝试在这里解决它们。

这是Ansible的最佳做法还是离Puppet太近了？

这绝对不是Ansible推荐的布局。在最佳实践布局中，没有servers或sources - 这些内部的所有内容都位于顶层（“服务器”的含义是什么，反正？）。

将backend.yml视为Puppet节点清单是否正确？

我对Puppet并不熟悉，所以无法回答这个问题。

我应该在哪里放置site.yml和backend.yml？这个例子将它们放在主目录中，而它位于'plays'目录中。有什么区别？

官方建议将所有剧本分散在根目录中。但是，这有点乱，因此有些人将它们放在子目录中（在您的示例中，plays）。这种方法运行得相当不错，但您需要相应地调整播放手册中的路径。

我认为group_vars / backend中的group_vars没有正确使用，我该如何访问它们？

您不应将它们放在库存文件夹的子目录中，因为它们不是库存的一部分。有许多地方可以定义变量，您应该阅读the documentation以了解它们是什么以及何时应该使用它们，但是group_vars应该位于目录的根目录中。 / p>

Answer 2

就我而言，我根据环境复杂性使用以下结构（请检查directory-layout）：

简单的环境

在一种环境下或以预配模式使用剧本时，我会使用这种结构

ansible
├── inventory
│   ├── hosts
│   └── group_vars
│       └── my_group.yml
├── roles
│   └── mysql
├── ansible.cfg
├── README.md
├── playbook1.yml
└── playbook2.yml

在ansible.cfg中，我在inventory = ./inventory中使用变量[default]，以避免通过命令ansible-*设置清单路径。

中等/复杂环境

当有多个环境时，我会使用这种结构

ansible
├── inventories
│   ├── production
│   │   ├── hosts
│   │   └── group_vars
│   │       └── my_group.yml
│   └── development
│       ├── hosts
│       └── group_vars
│           └── my_group.yml
├── playbooks
│   ├── playbook1
│   │   ├── group_vars
│   │   │   └── my_group.yml
│   │   ├── roles
│   │   │   └── mysql
│   │   ├── README.md
│   │   └── site.yml
│   ...
├── README.md
└── ansible.cfg

在这种情况下，./inventories中每个环境都有一个文件夹。

我也更喜欢为每个剧本使用一个特定的文件夹，以便能够轻松使用variable precedence section中定义的剧本级别的文件夹group_vars。随着环境变得越来越复杂，存在更多的变量。剧本中的group_vars（和host_vars）可以为所有环境定义通用变量，从而减少库存变量。

最终级别的环境

我已经使用Ansible来处理具有5000台服务器的系统，这里有一些技巧可以解决更复杂的环境：

拆分库存文件

使用多个文件而不是单个hosts文件来定义清单服务器。在这种情况下，hosts文件仅包含服务器名称，其他文件包含具有不同视角的组：

└── production
    ├── hosts
    ├── middleware
    └── trigram

middleware：具有映射到二手中间件或其他stuf的组。我使用此文件将服务器映射到tomcat，java，postgresql等。例如，我将其用于部署监视代理的剧本：如何检索指标，来自tomcat，java，postgresql的日志等。
trigram：在我的项目中，我通常使用固定长度（3或4）的代码来标识我的业务组件（例如：用于库存管理的“ STK”），然后创建要映射的组文件服务器上的业务组件（哪些服务器用于部署“ STK”）

创建新的剧本时，请选择您的视角来应对不同的环境。

警告：我认为Ansible加载文件的字母顺序为字母顺序，您不能定义一个引用尚未加载的组的组。

将文件夹用于`group_vars`

在group_vars中，可以使用带有子文件的文件夹来代替使用文件：

└── production
    └── group_vars
        └── my_group
            ├── vars1.yml
            └── vars2.yml

这对于拆分大文件很有用，或者如果您具有生成变量的工具，在这种情况下，您在git下有vars1.yml，并且生成了vars2.yml

拆分git repo

当您在大型系统上使用ansible时，会有很多提交，并且经常出现一个问题：如何拆分我的git repo？

我的情况是，对于具有不同访问规则的./inventories中的每个文件夹，我使用一个git repo。还有./playbooks中每个文件夹的git repo，也具有不同的访问规则。

Ansible文件夹结构

2 个答案: