安全设计帮助(服务器,团队,角色,剧本等)

时间:2015-05-20 09:08:10

标签: ansible

我们正在努力为我们的船员设计一个Ansible系统。

我们有一些悬而未决的问题会导致我们停下来思考并听取其他想法。

细节:

  • 4个开发团队。
  • 我们为每个程序员提供CI服务器,数据库服务器和个人虚拟机。
  • 一个新的程序员收到一个干净的虚拟机,我们希望使用Ansible根据他即将加入的团队为他“准备”。
  • 我们还想在一些虚拟机上使用Ansible进行每周更新(如果需要) - 它可能适用于整个团队或所有虚拟机。
  • 团队A和团队B分享他们的一些需求(例如,他们都使用Django)但是团队A使用的自然应用程序和团队B没有。

我们做了什么:

  • 我们有旧的“维护”bash脚本,我们将其转换为YAML脚本。
  • 我们将它们分组为Ansible角色
  • 我们有一个库存文件,其中包含每个团队和我们服务器的组:

`

[ALL:children]
Team A
Team B
...

[Team A]
...

[Team B]
...

[CIservers]
...

[DBservers]
...
  • 我们有大型剧本,其中包含我们所有的角色(每个角色都有标签):

    - hosts: ALL roles: - { role x, tags: 'x' } - { role y, tags: 'y' } ...

  • 我们这样调用Ansible:

    ansible-playbook -i inventory -t TAG1,TAG2 -l TeamA play.yml

问题:

  • 我们感觉我们没有按照自己的意愿使用角色。我们最终得到像“mercurial”或“eclipse”这样的角色,用于安装和配置(添加别名,编辑PATH,创建符号链接等)和apt_packages的角色(使用apt模块来安装我们需要的包)和pip_packages的角色(使用pip模块安装我们需要的软件包。)
  • 我们的一些角色依赖于其他角色(我们使用meta文件夹来声明这些依赖项)。因为我们的playbook包含我们拥有的所有角色,所以当我们运行它时没有标签(例如,在新的程序员VM上),其他角色所依赖的角色运行两次(或更多),这是浪费时间。我们教会从我们的剧本中删除其他人所依赖的角色,但这不是一个好的解决方案,因为这样我们就失去了自己运行该角色的能力。

我们不确定如何从这一点继续。是否通过以正确的顺序指定角色来产生角色依赖关系并创建实现这些依赖关系的playbooks。 我们是否应该将我们的角色更改为TeamA或DBserver,这些角色将统一我们当前的许多角色(在这种情况下,我们如何处理TeamA和TeamB之间的常见任务以及我们如何处理仅与TeamA相关的任务?)< / p>

嗯,这就是一切。

提前致谢!

2 个答案:

答案 0 :(得分:0)

对于迟到的回答感到抱歉,我猜你的团队现在可能已经找到了解决方案。我怀疑你将拥有标准的ansible结构,其中包含group_vars,hosts_vars,一个角色文件夹和一个site.yml,如下面的大纲

site.yml
group_vars
host_vars
roles
    common
    dbserver
    ciserver

我怀疑您的团队正在尝试将所有内容链接到一个site.yml文件中。这适用于基于角色和标记操作的常见任务。我建议在这些边缘情况下,您在根级别创建第二个或第三个playbook,这可以特定于团队或每周部署。在这种情况下,您仍然可以将常见任务保留在标准结构中,但是您不会将所有元素的任务复杂化。

site.yml // the standard ansible way
teamb.yml // we need to do something slightly different  

同样,当您发现实现任务的更好方法时,可以重构剧本,并将任务从特定文件移动到标准角色

答案 1 :(得分:0)

当您有多个团队在同一工作并且不想影响其他任务时,您似乎仍在尝试使用ansible的最佳方法。看看这个boilerplate可能会有帮助。

如果您查看该仓库。您将看到有多个角色,您可以根据需要设计剧本。

示例:  - common.yml (这在所有团队中都是常见的)  -另外,您可以使用 teamname.yml project.yml

创建

如果您使用上述任何一种方法,则只需要在剧本中定义适当的角色即可,并且应与正确的主持人组变量相关联。