TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ansible 1.4 released

192 点作者 matthiasv超过 11 年前

20 条评论

mattjaynes超过 11 年前
For a higher-level overview of this release, see the blog post: <a href="http://blog.ansibleworks.com/2013/11/21/ansible-1-4-released/" rel="nofollow">http:&#x2F;&#x2F;blog.ansibleworks.com&#x2F;2013&#x2F;11&#x2F;21&#x2F;ansible-1-4-released...</a><p>A lot of great new features in this release - very excited to see the tool become more and more powerful.<p>I only came across Ansible this summer, but it really blew my mind. I&#x27;ve been doing systems contracting for a few years now and Ansible is the most valuable tool I&#x27;ve come across for systems management so far. Now, rather than have to use (and train my clients on) multiple tools, I can have them just learn one solid tool that can handle orchestration, deployment, configuration management, server inventory, etc. I can now do a systems project in days when before the same project would take weeks. Expect to hear a lot more about Ansible in the future.<p>Ansible isn&#x27;t awesome because of a feature-list. It&#x27;s awesome because it saves me time and gives me a lot of power for very little investment. Whether you&#x27;re setting up a single server or 10,000 nodes, you can use this tool to give you a ton of leverage without having to spend weeks learning complex tools.<p>That&#x27;s why I&#x27;ve been focusing on it so much in the last few months.<p>Shameless (but highly relevant!) plugs:<p>For weekly community updates and cowsay jokes, sign up for Ansible Weekly: <a href="http://devopsu.com/newsletters/ansible-weekly-newsletter.html" rel="nofollow">http:&#x2F;&#x2F;devopsu.com&#x2F;newsletters&#x2F;ansible-weekly-newsletter.htm...</a><p>For a comparison of Ansible with other configuration management tools (implementing an identical project in each tool), see my book on the subject: <a href="http://devopsu.com/books/taste-test-puppet-chef-salt-stack-ansible.html" rel="nofollow">http:&#x2F;&#x2F;devopsu.com&#x2F;books&#x2F;taste-test-puppet-chef-salt-stack-a...</a><p>For a brief introduction to Ansible in comparison to Shell Scripts, see: <a href="http://devopsu.com/blog/ansible-vs-shell-scripts/" rel="nofollow">http:&#x2F;&#x2F;devopsu.com&#x2F;blog&#x2F;ansible-vs-shell-scripts&#x2F;</a>
评论 #6778544 未加载
评论 #6783209 未加载
gtaylor超过 11 年前
Ansible has worked really well for us at Pathwright. We initially played a lot with Chef and Puppet, as they&#x27;re two really safe bets. This is kind of petty, but we&#x27;re a Python shop, so the Rubyisms were a bit jarring. Both were also a bit harder to pick up while short on time. This new thing (at the time) called Ansible caught our eye, and it only took a few days to see that it was a great fit for us.<p>While Ansible is developed in Python, it doesn&#x27;t leak through to the UI and the playbooks. It&#x27;s all just YAML. Learn a little Jinja2, grok the directory structure, and you&#x27;re set.<p>The playbook format is simple, and even people without any Ansible experience can pick through and get a basic idea of what&#x27;s going on. Pythonistas, Rubyists, whatever. It&#x27;s just YAML.<p>My only criticism is that the documentation isn&#x27;t organized very well just yet. This is common with projects that are rapidly growing&#x2F;improving, and I expect it to get better. In particular, I think the doc index needs to be trimmed a LOT, with more content being delegated to sub-sections: <a href="http://www.ansibleworks.com/docs/" rel="nofollow">http:&#x2F;&#x2F;www.ansibleworks.com&#x2F;docs&#x2F;</a><p>Overall, great utility, very helpful community, loads of potential.
评论 #6778819 未加载
评论 #6779009 未加载
评论 #6780087 未加载
sandGorgon超过 11 年前
Ansible has way too few examples and documentation going around it. The supplied examples are way too simplistic and do not mirror any real life application at all.<p>I really hope that the authors create a non trivial project (like hadoop on EC2) which exercises a lot of parts of Ansible, document it throughly and structure it to match real life workflows. It&#x27;s really, really hard to go around hunting for documentation. For example, I did not even know after reading the Ansible-EC2 documentation for a few hours that you need to periodically run &quot;python ec2.py&quot; to keep refreshing your inventory in a cache on your disk. I somehow thought (or intuitively expected) all that happened in the background on running the playbook, and just take a few minutes longer - it&#x27;s not as if any time is saved, since you have to run the inventory script anyway.<p>Single playbooks that launch an EC2 instance, print hello and shut it down are not the typical use case.
评论 #6779179 未加载
pilif超过 11 年前
Last year, I have deployed ~20 machines with puppet (some virtual, some physical) which also was my first attempt into automatic configuration (better late than never I guess).<p>I&#x27;m reasonably happy with the outcome and it has certainly paid off the learning effort.<p>But when I learned about Ansible a few months ago and after reading the documentation, I was blown away when I&#x27;ve seen Ansible practically fixing all my gripes I have with puppet.<p>Audible really feels like the perfect piece of Software for my use case:<p>For one, I don&#x27;t have that many machines and the amount of them changes very rarely, so I don&#x27;t really get much benefit from the central puppet server. It is however one additional piece if software to maintain.<p>Then, by being able to push a config from everywhere with Ansible, I could get rid of a few scripts that now update the puppet master from git checkouts and then tell the other machines to fetch the config (the clients are not running the agent in daemon mode because I like to have full control over when the deployment of configs happens)<p>Next, Ansible has a very cool facility to do one-off things across multiple machines. Yes, that&#x27;s probably a dangerous shoot-yourself-in-the-foot feature, but sometimes, my feet need shooting at and I&#x27;m happy if the tool provides the gun instead of myself having to build the gun myself if you pardon the metaphor.<p>Next, I love the feature that managed clients practically need nothing installed on them to be able to manage them. And: Ansible brings everything it needs to bootstrap a new client. That&#x27; say other script I would not have needed to write.<p>Finally, I like the much bigger library of included modules as that would keep the repository I have to keep smaller and constrained to just the actual configuration of my machines rather than infrastructure to just be able to express the configuration.<p>Now if only I had time to convert our puppet setup.
ermintrude超过 11 年前
I&#x27;m working on a large project running on AWS. We&#x27;re building an n-tier architecture with many roles in auto-scaling groups.<p>We wasted the first couple of months writing wrappers around SSH to let us provision servers with salt, which if we&#x27;d been using ansible would have been completely unnecessary. We did evaluate ansible at the start of the year, but at that time it didn&#x27;t look quite as mature so we went with salt.<p>I&#x27;ve used ansible myself and it&#x27;s far simpler than salt, and quicker to get started with. Admittedly I haven&#x27;t used it to deploy the same complex software as we are doing with salt, where orchestration is fiddly. Overall, the thing that lets salt down is its appalling documentation, poor support (the IRC channel has been practically useless) and complex terminology (what&#x27;s the difference between a module and a state? Who knows...).<p>Salt does have one thing in its favour though - the ability to run things in parallel. For example a new node can request itself to be configured which is very useful when running in auto-scaling groups. I think this is coming in ansible, but it wasn&#x27;t at the same level as in salt last I checked.<p>With salt, when a new node comes up (in an auto-scaling group for example), it can request itself to be configured. Once finished it can fire an event to the saltmaster which can trigger it to reconfigure other nodes. This, for example, means when a new web server comes up, the app can be deployed to it and the node can then instruct the saltmaster to update the load balancer configs to send traffic to it. This event system is powerful because it lets multiple tasks take place in parallel, but it is complicated.<p>If ansible had an intuitive way of running tasks in parallel (with locks through critical sections, the ability to target a subset of matched nodes (to back up a single server in a pool for example), etc.), then I think it&#x27;d beat salt hands down.<p>For the majority of cases I&#x27;d definitely recommend ansible over salt. And as for chef&#x2F;puppet after using them both on earlier projects, we started looking for something else that could do orchestrations as well as provisioning and that had saner authentication when running in the cloud.<p>Good work ansible team!
评论 #6781081 未加载
analytically超过 11 年前
Check out my Ansible Playbook that installs a Hadoop cluster (running on Java 7), with Ganglia, Fluentd, ElasticSearch and Kibana 3 for monitoring and centralized log indexing. <a href="https://github.com/analytically/hadoop-ansible" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;analytically&#x2F;hadoop-ansible</a>
qznc超过 11 年前
In all this talk about Ansible, Puppet, Chef, I wonder why nobody mentions cfengine. When I explored configuration systems my conclusions were Ansible for small systems (&lt;100 nodes) and cfengine3 for larger systems. cfengine has very little dependencies (no Python&#x2F;Ruby&#x2F;etc) and a solid theoretic foundation (Promise theory etc).
评论 #6783011 未加载
pas256超过 11 年前
Ansible is so good, than even Ansible playbooks win awards:<p><a href="https://github.com/Answers4AWS/netflixoss-ansible" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Answers4AWS&#x2F;netflixoss-ansible</a><p>:-)
ddispaltro超过 11 年前
I feel like for years we&#x27;ve bastardized chef to execute like fabric, using littlechef, custom attribute smashers, and git. Now with ansible this a first class experience, very cool guys!
shiven超过 11 年前
Ansible has so far been the best software I have ever used for system administration. Love it!<p>After the nightmare (for me) that was chef&#x2F;puppet, Ansible is heaven!!
habitue超过 11 年前
I see that it&#x27;s licensed GPL, but then the &quot;pricing&quot; page says the open source version can be used on up to 10 boxes. Is this a code restriction (which could be circumvented) or is it an additional license restriction (which the GPL expressly disallows) ?
评论 #6778854 未加载
nphase超过 11 年前
These Van Halen song release names are hilarious!
jeffnappi超过 11 年前
Ansible is fantastic - congrats to Michael Dehaan and the rest of the team! We love ansible at iAcquire :)
misterparker超过 11 年前
Will this allow me to talk with the buggers?
xfax超过 11 年前
I&#x27;m looking for a configuration management system since our VPSs are getting a bit crazy to manage manually.<p>Been looking at Chef and Ansible primarily. Anyone have a good comparison between the two?
评论 #6785949 未加载
评论 #6778955 未加载
pekk超过 11 年前
Too bad Ansible will not support Python 3
评论 #6779564 未加载
CraigJPerry超过 11 年前
How do others test their playbooks?<p>I&#x27;ve been wrapping up playbooks in python unittests[1] but i&#x27;d like to find something a bit more expressive and less wordy. I could shoogle my wee testing framework a bit more into shape but keen to see how others tackle.<p>Maybe i can steal some inspiration!<p>[1] <a href="https://github.com/CraigJPerry/home-network/blob/master/tests/test_install_pull_mode.py" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;CraigJPerry&#x2F;home-network&#x2F;blob&#x2F;master&#x2F;test...</a>
评论 #6778742 未加载
评论 #6779720 未加载
mackwic超过 11 年前
I am not convinced by the advantages of the web gui for deployment against our good old fabric&#x2F;buildbot&#x2F;deploy, does someone has a feedback with that tool ?<p>Anyway, I am always very happy to see OSS projects like that making a living of paid services (or the opposite, whatever ;) ).
评论 #6778151 未加载
评论 #6778133 未加载
评论 #6778225 未加载
tszming超过 11 年前
More and more people are moving from projects like chef to ansible because people need a way to manage servers without the need of too much server dependencies, it is so obvious and I really can&#x27;t understand why chef developers can&#x27;t see the needs here.
HeyImAlex超过 11 年前
Woo for roles search path configurability! I&#x27;d been symlinking a devops folder into all of my projects and doing relative imports from it.