5 ms·

Opsworks is nice, and it's a good packaged solution. A large number of smaller apps would benefit from a switch. It's also more fairly priced. That being said,

Opsworks is nice, and it's a good packaged solution. A large number of smaller apps would benefit from a switch. It's also more fairly priced. That being said, opsworks is still based on chef, which is still cumbersome. For most people Ansible is far easier to deal with if they don't fit into the opsworks box. The overhead of starting from scratch with ansible can be made up for with the faster overall development time.

swrobel 13y ago
Good to know! I've been meaning to look into Ansible & SaltStack, and you gave me the kick in the butt I needed. EDIT: ohai Andrew! Thanks for the comment.
wc- 13y ago
Big thumbs up for ansible, I have had great results with it it in a number of different production environments, I think the docs are great, and the devs in the irc channel on freenode are very helpful. If you are about to embark on the journey of provisioning for the first time, or if you are looking for something a little more straightforward than chef/puppet (in my opinion at least...), I highly recommend checking out Ansible!
- phowat 13y ago
  Another thumbs up. I'm currently in the process of migrating away from CFEngine to Ansible and it's been a breeze.
sync 13y ago
Seems like Opsworks does a lot more than just the provisioning, no? "AWS OpsWorks can scale your application using automatic load-based or time-based scaling and maintain the health of your application by detecting failed instances and replacing them. You have full control of deployments and automation of each component." How would you suggest using Ansible to cover that side of things?
- wc- 13y ago
  Autoscaling groups with ansible-pull + cloud init to configure instances as they are spun up by AWS is what I've had the most success with. So your autoscaling group spins up a new instance using a prebaked AMI, and on first boot cloud-init will run ansible-pull locally to grab the latest configs and start up services as needed. Alternatively you can just use ansible to bake a new AMI as needed and skip the ansible-pull + cloud-init part altogether.
- imperialWicket 13y ago
  This just introduces additional tools/products to the stack, but you can use Ansible with the Netflix OSS stack, such that Ansible provisions your AMIs and Asgard manages auto-scaling and deployment (with very fine-grained control).
darklajid 13y ago
Ansible: I was in the "Don't go there" camp a while ago - they documentation was horrible, the whole website a mess and lots of things weren't discoverable at all (people using ansible told me that they used google site search to find stuff in the manual). I returned a couple of days ago to look at the current state of things and I have to admit that I was impressed. Technically I really liked ansible for quite some while. Now it even comes with decent documentation. I'd back the suggestion to check it out.
- ghayes 13y ago
  I was really excited by ansible, but I quickly found out that using `register: result` and `when: result|success` throughout so many playbooks meant I was back to the mess that is understanding the flow of a chef script that you didn't personally write. Maybe that's not a problem since I rarely found an open source ansible playbook for anything I needed and had to always write my own.
  - zenojevski 13y ago
    Hi, I've published some reusable roles for ansible. They are still quite basic, but I'd love for you to have a look at them. https://github.com/search?q=%40zenoamaro+ansible https://github.com/search?q=%40zenoamaro+ansible
    - ghayes 13y ago
      Always great to see people putting up open-source projects like this. I'll definitely give them a look, and at the least, get a grip on how other people found solutions with Ansible. Thanks man.
- mercurial 13y ago
  The doc is indeed pretty good, and available offline (ansible-doc). I quite like that it uses a very declarative syntax, and it's relatively easy to get idempotent operations. And the fact that you don't need to install anything on the machine you administer is definitely a strong point. One downside is that I can see how tracking down role dependencies would be tricky if you had many different roles. I also haven't tried at scale.
tgeek 13y ago
"That being said, opsworks is still based on chef, which is still cumbersome." re:chef I don't think this is necessarily a fair assessment and true for all. There are a ton of community cookbooks out there, and a very large community now online to help people with Chef. I've been using Chef for years and like anything else once you get over the learning period, it becomes second nature. Any tool that you use will have some learning curve to it, and so the trade offs that make it cumbersome for some, make it easy for others. Also, you could technically Chef in Ansible in OpsWorks(if OpsWorks met other needs for you), but thats just crazy talk haha

swrobel 13y ago

Good to know! I've been meaning to look into Ansible & SaltStack, and you gave me the kick in the butt I needed. EDIT: ohai Andrew! Thanks for the comment.

wc- 13y ago

Big thumbs up for ansible, I have had great results with it it in a number of different production environments, I think the docs are great, and the devs in the irc channel on freenode are very helpful. If you are about to embark on the journey of provisioning for the first time, or if you are looking for something a little more straightforward than chef/puppet (in my opinion at least...), I highly recommend checking out Ansible!

phowat 13y ago
Another thumbs up. I'm currently in the process of migrating away from CFEngine to Ansible and it's been a breeze.

sync 13y ago

Seems like Opsworks does a lot more than just the provisioning, no? "AWS OpsWorks can scale your application using automatic load-based or time-based scaling and maintain the health of your application by detecting failed instances and replacing them. You have full control of deployments and automation of each component." How would you suggest using Ansible to cover that side of things?

wc- 13y ago
Autoscaling groups with ansible-pull + cloud init to configure instances as they are spun up by AWS is what I've had the most success with. So your autoscaling group spins up a new instance using a prebaked AMI, and on first boot cloud-init will run ansible-pull locally to grab the latest configs and start up services as needed. Alternatively you can just use ansible to bake a new AMI as needed and skip the ansible-pull + cloud-init part altogether.
imperialWicket 13y ago
This just introduces additional tools/products to the stack, but you can use Ansible with the Netflix OSS stack, such that Ansible provisions your AMIs and Asgard manages auto-scaling and deployment (with very fine-grained control).

darklajid 13y ago

Ansible: I was in the "Don't go there" camp a while ago - they documentation was horrible, the whole website a mess and lots of things weren't discoverable at all (people using ansible told me that they used google site search to find stuff in the manual). I returned a couple of days ago to look at the current state of things and I have to admit that I was impressed. Technically I really liked ansible for quite some while. Now it even comes with decent documentation. I'd back the suggestion to check it out.

ghayes 13y ago
I was really excited by ansible, but I quickly found out that using `register: result` and `when: result|success` throughout so many playbooks meant I was back to the mess that is understanding the flow of a chef script that you didn't personally write. Maybe that's not a problem since I rarely found an open source ansible playbook for anything I needed and had to always write my own.
- zenojevski 13y ago
  Hi, I've published some reusable roles for ansible. They are still quite basic, but I'd love for you to have a look at them. https://github.com/search?q=%40zenoamaro+ansible https://github.com/search?q=%40zenoamaro+ansible
  - ghayes 13y ago
    Always great to see people putting up open-source projects like this. I'll definitely give them a look, and at the least, get a grip on how other people found solutions with Ansible. Thanks man.
mercurial 13y ago
The doc is indeed pretty good, and available offline (ansible-doc). I quite like that it uses a very declarative syntax, and it's relatively easy to get idempotent operations. And the fact that you don't need to install anything on the machine you administer is definitely a strong point. One downside is that I can see how tracking down role dependencies would be tricky if you had many different roles. I also haven't tried at scale.

tgeek 13y ago

"That being said, opsworks is still based on chef, which is still cumbersome." re:chef I don't think this is necessarily a fair assessment and true for all. There are a ton of community cookbooks out there, and a very large community now online to help people with Chef. I've been using Chef for years and like anything else once you get over the learning period, it becomes second nature. Any tool that you use will have some learning curve to it, and so the trade offs that make it cumbersome for some, make it easy for others. Also, you could technically Chef in Ansible in OpsWorks(if OpsWorks met other needs for you), but thats just crazy talk haha