internet/community.general
3
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2026-05-07 13:52:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add info about sudo.

Browse Source
This commit is contained in:
Michael DeHaan
2012-04-14 08:45:27 -04:00
parent 2850b8d921
commit adbf3590c5
15 changed files with 49 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
index.html
View File

@@ -182,13 +182,17 @@ version of software if required.</p>
<p>Other deployment oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts. Ansible playbooks &#8211; having been designed with this problem in mind &#8211; are good at both deployment &amp; idempotent configuration, meaning you don&#8217;t have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc), and performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required &#8211; while avoiding the problem of fragile scripting that assumes certain starting
or ending states.</p>
<p>Ansible is also unique in other ways. Extending ansible does not require programming in any particular language &#8211; you can write <a class="reference internal" href="modules.html"><em>Ansible Modules</em></a> as idempotent scripts or programs that return simple JSON. Ansible is also pragmatic, so when you need to, it&#8217;s also trivially easy to just execute useful shell commands.</p>
<p>Why use Ansible versus something else? (Puppet, Chef, Capistrano, etc?) Ansible will have far
<p>Why use Ansible versus other configuration management tools? (Puppet, Chef, etc?) Ansible will have far
less code, it will be (by extension) more correct, and it will be the
easiest thing to hack on and use you&#8217;ll ever see &#8211; regardless of your
favorite language of choice.</p>
<p>Systems management doesn&#8217;t have to be complicated. Ansible&#8217;s docs
will remain short &amp; simple, and the source will be blindingly obvious.</p>
<p>We&#8217;ve learned well from &#8220;Infrastructure is Code&#8221;. Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project &#8211; bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit.</p>
favorite language of choice. Versus other deployment tools? (Capistrano, Fabric?). Ansible playbooks are easier
to use (not being code) and also allows intermixing of idempotent configuration management rules for a higher level
of control. Further, it was designed for deploying multi-node applications from the beginning.</p>
<p>Compared with most configuration managememnt tools, Ansible is also more secure. While most configuration management tools use a daemon, running as root with full access to the system, with it&#8217;s own in-house developed PKI infrastructure, Ansible just uses SSH (and supports sudo as neccesssary). There is no additional attack surface and OpenSSH is one of the most peer reviewed security components out there.
If a central server containing your playbooks are comprimised, your nodes are not &#8211; which is NOT the case
of these other tools, which can, more or less, turn into a botnet. Our security approach is to avoid writing custom
crypto code altogether, and rely on the most secure part of the Linux/Unix subsystem that your machines are already using.</p>
<p>Systems management doesn&#8217;t have to be complicated. Ansible&#8217;s docs will remain short &amp; simple, and the source will be blindingly obvious. We&#8217;ve learned well from &#8220;Infrastructure is Code&#8221;. Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project &#8211; bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit.</p>
<div class="section" id="architecture">
<h2>Architecture<a class="headerlink" href="#architecture" title="Permalink to this headline"></a></h2>
<div align="center" class="align-center"><img alt="&quot;Architecture Diagram&quot;" class="align-center" src="http://ansible.github.com/ansible_arch2.jpg" style="width: 800px;" /></div>
@@ -345,6 +349,7 @@ Email: <input type=text name=email>&nbsp;&nbsp;<input type=submit name="sub" val
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="faq.html#other-questions">Other Questions</a><ul>
<li class="toctree-l3"><a class="reference internal" href="faq.html#what-is-ansible-s-approach-to-security">What is Ansible&#8217;s approach to security?</a></li>
<li class="toctree-l3"><a class="reference internal" href="faq.html#how-does-ansible-scale">How does Ansible scale?</a></li>
<li class="toctree-l3"><a class="reference internal" href="faq.html#are-transports-other-than-ssh-supported">Are transports other than SSH supported?</a></li>
<li class="toctree-l3"><a class="reference internal" href="faq.html#what-are-some-ideal-uses-for-ansible">What are some ideal uses for Ansible?</a></li>
@@ -376,7 +381,7 @@ Puppet Labs, and rPath. Reach Michael by email <a class="reference external" hr
<p class="pull-right"><a href="#">Back to top</a></p>
<p>
&copy; Copyright 2012 Michael DeHaan.<br/>
Last updated on Apr 12, 2012.<br/>
Last updated on Apr 14, 2012.<br/>
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.0.8.<br/>
</p>
</div>