ansible是什么_为什么您可能需要Ansible甚至不知道

ansible是什么

使用Shell脚本配置机器非常麻烦 (Configuring machines with shell scripts is terribly messy)

Do you want to start using Ansible? Are you already using it, but coming up against challenges? Even if you don’t fall into either category, don’t stop reading. I’m going to show you why you might actually need Ansible and how to best take advantage of it.

您要开始使用Ansible吗？ 您已经在使用它，但是面临挑战吗？ 即使您不属于任何一个类别 ，也不要停止阅读。 我将向您展示为什么您可能真正需要 Ansible，以及如何最好地利用它。

Ansible’s catchphrase is “simple IT automation.” This is a pretty accurate description of what it does. In its most popular mode of operation (there are several), you describe the desired state of your machines, and Ansible manipulates them to achieve this state. At this point, you may be thinking “yeah, but we’ve already got shell scripts for that.” Ansible, though, offers several advantages over good old shell scripts.

Ansible的口号是“简单的IT自动化”。 这是一个相当准确的描述。 在其最流行的操作模式(有几种)下，您描述了机器的期望状态，而Ansible操纵它们以达到该状态。 在这一点上，您可能会想“是的，但是我们已经为此使用了shell脚本。” 但是，Ansible与良好的旧Shell脚本相比具有许多优点。

First of all, the playbook, which describes the desired state, is declarative and written in YAML. Using a playbook means you don’t need to handle the error control and condition checking yourself. It also means no actions will be taken if the state is already satisfied (e.g. apt-get won’t run if an nginx package is already installed).

首先，描述所需状态的剧本是声明性的，并用YAML编写。 使用剧本意味着您不需要自己进行错误控制和条件检查。 这也意味着如果状态已经满足，则不会采取任何措施(例如，如果已经安装了nginx软件包，则apt-get将不会运行)。

But this is only part of the story.

但这只是故事的一部分。

The other thing that makes Ansible so powerful is the use of modules. Instead of relying on many third-party applications (sed, grep, jq, useradd, parted, etc.) and parsing their output, you can focus solely on the state itself. This means that regardless of the underlying userspace programs (useradd, adduser, Busybox, BSD, or GNU variants), you can just specify a universal task as follows:

使Ansible如此强大的另一件事是模块的使用。 无需依赖许多第三方应用程序( sed ， grep ， jq ， useradd ， parted等)并解析其输出，您可以仅关注状态本身。 这意味着无论基础用户空间程序( useradd ， adduser ，Busybox，BSD或GNU变体)如何，您都可以按照以下方式指定通用任务：

– name: Create the operator user
  user:
    name: operator
    createhome: yes
    groups: wheel
    shell: /bin/sh

In the same way, you would encapsulate parts of your script into separate libraries, Ansible embraces the concept of roles. Roles describe particular states of a machine, together with possible variables, configuration files, or templates. They’re aptly named, and the machine can use roles like docker, nginx, and python, for example. Each of these may then be tested in isolation and reused among all of your projects. They also can encapsulate more abstract concepts like the ansible-hardening role from OpenStack, which makes a target a little bit harder to break.

同样，您可以将脚本的各个部分封装到单独的库中，Ansible包含角色的概念。 角色描述计算机的特定状态，以及可能的变量，配置文件或模板。 它们被恰当地命名，并且机器可以使用例如docker ， nginx和python类的角色。 然后可以单独测试所有这些项目，并在所有项目中重用它们。 他们还可以封装更抽象的概念，例如来自OpenStack的ansible-harding角色，这使目标更难打破。

And the other cool thing? To run Ansible, you only need Python 2.6+ on your target machines and an open SSH connection. There’s no need to install anything else! This means you’re probably ready to start using Ansible right away! Prepare your control machine by running brew install ansible or pip install -user ansible and follow me.

还有一件很酷的事情？ 要运行Ansible，您只需在目标计算机上使用Python 2.6+并打开SSH连接即可。 无需安装其他任何东西！ 这意味着您可能已经准备好立即开始使用Ansible！ 通过运行brew install ansible或pip install -user ansible来准备控制机，然后关注我。

以代码部署 (Deployment as Code)

Forget about the README located in the project’s root directory. It usually contains all the tedious details on how to deploy to staging or production. With Ansible, the documentation is in the code. It’s testable, it’s reusable, and it can be run by anybody, as long as the person has access to the target machines. It also forms the perfect basis for a Continuous Deployment (CD) pipeline.

忘记位于项目根目录中的自述文件。 它通常包含有关如何部署到暂存或生产的所有繁琐细节。 使用Ansible，文档位于代码中。 它是可测试的，可重用的，并且任何人都可以运行，只要该人可以访问目标计算机即可。 它还为持续部署(CD)管道提供了完美的基础。

Making sure your app is always deployable can also help avert disaster. Instead of figuring out what to do when your servers go down, you simply edit the inventory file and make a fresh deployment to a new set of machines.

确保您的应用始终可部署，还可以帮助您避免灾难。 您无需弄清楚服务器故障时的处理方法，只需编辑清单文件并重新部署到一组新计算机即可。

确保您的团队已准备好进行DevOps (Make Sure Your Team Is Ready for DevOps)

When the deployment is a part of the codebase, it has to evolve with the codebase. Make sure all of your team is DevOps-enabled and understands how to use Ansible. The best way to do this is to provide a Vagrant environment so each dev can test the deployment process locally.

当部署是代码库的一部分时，它必须随代码库一起发展。 确保您所有的团队都支持DevOps，并了解如何使用Ansible。 最好的方法是提供一个Vagrant环境，以便每个开发人员都可以在本地测试部署过程。

It’s essential that you test your deployment code in the same way you test your application. Each change to an application that may be relevant to deployment needs to be reflected in changes to Ansible files. For example, if you add new files that must be copied to the server, make sure there’s a corresponding task. If an application starts logging in a particular directory, make sure Ansible creates that directory and sets appropriate permissions.

必须以与测试应用程序相同的方式来测试部署代码。 与部署相关的应用程序每次更改都需要反映在Ansible文件的更改中。 例如，如果添加必须复制到服务器的新文件，请确保存在相应的任务。 如果应用程序开始登录特定目录，请确保Ansible创建该目录并设置适当的权限。

使其易于工作，难以维护 (It’s Easy to Make It Work, Harder to Make It Maintainable)

Ansible has its downsides, as well. These aren’t necessarily related to the tool itself, but they do crop up occasionally. Even though Ansible has well-documented best practices, those don’t always help you achieve a single goal. This can lead to the creation of complicated solutions when simple ones would suffice.

Ansible也有其缺点。 这些不一定与工具本身有关，但偶尔会出现。 即使Ansible拥有记录良好的最佳做法 ，但这些并非总是能帮助您实现一个目标。 当简单的解决方案就足够时，这可能导致创建复杂的解决方案。

首选一次性部署 (Prefer One-Time Deployments)

Even though one of the features Ansible advertises is idempotence, it’s still quite easy to write a playbook that won’t work correctly. For example, how do you update service in an idempotent way? You can’t, it’s self-contradictory, which means you have to sacrifice one thing to save another (an update, that is).

即使Ansible宣传的功能之一是幂等 ，但编写无法正常工作的剧本还是很容易的。 例如，如何以幂等方式更新服务？ 您不能，这是自相矛盾的，这意味着您必须牺牲一件事来保存另一件事(即更新)。

There are two concepts that can help with this problem: disposable infrastructure and immutable infrastructure. The two are pretty similar from a deployment point of view. The former assumes that a machine can be easily disposed of at any point in time after a successful deployment. It may be reconfigured in the future, but there’s nothing stopping you from taking it down at any time. The latter also requires that a machine never changes its configuration after it is provisioned.

有两个概念可以解决此问题： 一次性基础架构和不可变基础架构 。 从部署的角度来看，两者非常相似。 前者假设成功部署后的任何时间都可以轻松处置计算机。 将来可能会对其进行重新配置，但没有任何阻止您随时删除它的功能。 后者还要求一台机器在配置后永远不要更改其配置。

Both assume your application is located beyond a load balancer (or a reverse proxy). Such a load balancer could be hosted either externally or internally, independent of the rest of the infrastructure. Services that make up your application are registered in the load balancer. The backend configuration is updated dynamically as services come and go. If you want to host the load balancer yourself, confd or consul-template can help with dynamic reconfiguration.

两者都假定您的应用程序位于负载均衡器(或反向代理)之外。 这样的负载均衡器可以在外部或内部托管，而与其余基础结构无关。 组成您的应用程序的服务已在负载均衡器中注册。 后端配置会随着服务的出现而动态更新。 如果要自己托管负载平衡器，则confd或consul-template可以帮助动态重新配置。

使用和重用角色 (Use and Reuse Roles)

Questions like when and how to use roles or what aspects should be configurable don’t have single, straightforward answers. In my experience, it’s best to think of the various use cases for a particular machine and then to encapsulate those use cases in separate roles that can not only be tested in isolation but can also be reused for other projects. Such reuse also leads to better code quality thanks to a larger testing base.

诸如何时，如何使用角色或应配置哪些方面之类的问题没有一个简单直接的答案。 以我的经验，最好考虑一台特定机器的各种用例，然后将这些用例封装在单独的角色中，这些角色不仅可以单独进行测试，还可以重用于其他项目。 由于具有更大的测试基础，因此这种重用还可以提高代码质量。

可能性的银河 (A Galaxy of Possibilities)

Ansible Galaxy provides lots of modules we can use. This is similar to Docker Hub or NPM, where you can search for the relevant parts and use them in your project. They are all written adhering to one standard, meaning they should be easily reusable. Unfortunately, this isn’t always the case.

Ansible Galaxy提供了许多我们可以使用的模块。 这类似于Docker Hub或NPM，您可以在其中搜索相关部分并在项目中使用它们。 它们都是按照一个标准编写的，这意味着它们应该易于重用。 不幸的是，并非总是如此。

More than once in my career, I’ve happened upon a module that declared compatibility with Debian but was only ever tested on Ubuntu. This may not be a problem if you can choose your base OS. It may mean some additional work in porting it if you want to make use of existing infrastructure.

在我的职业生涯中，我不止一次遇到了一个声明与Debian兼容但仅在Ubuntu上进行过测试的模块。 如果您可以选择基本操作系统，则这可能不是问题。 如果要使用现有的基础架构，则可能需要进行一些额外的移植工作。

Version pinning is another problem. We all know that software evolves and that backward compatibility is rarely observed. When modules use several dependencies, it’s crucial that every such dependency is described with an exact version tag. This way, we can avoid the problem of installing a package in the latest version that’s no longer compatible with another part of the system.

版本固定是另一个问题。 我们都知道软件在发展，很少向后兼容。 当模块使用多个依赖项时，至关重要的是，必须使用确切的版本标记来描述每个此类依赖项。 这样，我们可以避免在与系统的另一部分不再兼容的最新版本中安装软件包的问题。

When talking about pinned versions, there’s no avoiding the subject of bit rot. Unused software decays. Referenced hyperlinks can become obsolete, releases can be taken down, hosting services may cease operation. Even if a module uses a pinned version, it may become unusable if it’s not regularly tested and updated as needed, which leads us to our next topic.

在谈论固定版本时，不可避免地会发生位腐烂的问题。 未使用的软件会衰减。 引用的超链接可能会过时，发布可能被删除，托管服务可能会停止运行。 即使模块使用固定版本，如果未根据需要对其进行定期测试和更新，它也可能变得无法使用，这将导致我们进入下一个主题。

测试很艰辛，而且很费时间 (Testing Is Hard — and Time-Consuming)

Ansible usually operates on system services. While it’s possible to test some of its features in containers (e.g., with Docker), this approach will generally fail. Docker can’t test all the kernel operations or systemd calls, because they don’t exist in its scope. To properly test Ansible playbooks, you need VMs. Did you notice the plural? Good, because it’s not enough to test on just one VM.

Ansible通常在系统服务上运行。 尽管可以在容器中测试其某些功能(例如，使用Docker)，但是这种方法通常会失败。 Docker无法测试所有内核操作或systemd调用，因为它们不存在于其范围内。 要正确测试Ansible剧本，您需要VM。 您注意到复数了吗？ 很好，因为仅在一个VM上进行测试还不够。

The most basic test setup should use a clean VM, run the playbook, check the results, and then run the playbook again to check for idempotency issues. But this only gives you limited information. You still don’t know if the playbook will actually deploy in production. The target machine won’t necessarily be a clean VM (unless you’re already using disposable infrastructure).

最基本的测试设置应使用干净的VM，运行剧本，检查结果，然后再次运行剧本以检查幂等问题。 但这仅给您有限的信息。 您仍然不知道剧本是否会真正部署到生产环境中。 目标计算机不一定是干净的VM(除非您已经在使用一次性基础架构)。

To mitigate this risk, it may be a good idea to have a separate VM that could serve as “long-term memory.” This VM, in contrast, would not be cleaned after every test deployment but would allow changes to accumulate over time.

为了减轻这种风险，最好有一个单独的VM来充当“长期内存”。 相反，此VM不会在每次测试部署后清除，但会随着时间的推移而累积更改。

摘要 (Summary)

The best way to document code is in the code itself. Considering this simple statement leads us to a logical conclusion — the best deployment documentation is the deployment code. There are many tools to help achieve this, with Ansible being one of them. Personally, I prefer it to Chef or Puppet, but I’ve yet to try Salt or StackStorm.

记录代码的最佳方法是在代码本身中。 考虑到这个简单的陈述，我们可以得出一个合乎逻辑的结论-最好的部署文档是部署代码。 有许多工具可以帮助实现这一目标，其中Ansible是其中之一。 就个人而言，我更喜欢Chef或Puppet ，但我还没有尝试过Salt或StackStorm 。

As with every tool I’ve encountered in my professional life, it also has its downsides. Knowing them up front should help you avoid some of the problems I’ve stumbled upon. Hopefully, learning from my experience will save you time and frustration in your own work.

就像我在职业生涯中遇到的所有工具一样，它也有缺点。 预先了解它们应该可以帮助您避免我偶然发现的一些问题。 希望从我的经验中学到东西可以节省您的时间和工作上的挫败感。

If you like what I create consider subscribing to Bit Better. It’s a community newsletter with recommendations for books, articles, tools, and sometimes music.

如果您喜欢我创建的内容，请考虑订阅Bit Better。 这是一份社区通讯，其中包含有关书籍，文章，工具和音乐的建议。

Originally published at https://www.iamondemand.com on August 10, 2017.

最初于2017年8月10日发布在https://www.iamondemand.com 。

翻译自: https://www.freecodecamp.org/news/why-you-might-need-ansible-and-not-even-know-it-d33b6e4b2ebe/

ansible是什么