5 ms·

I like how Ansible shows how sometimes technology can come full circle. Ansible started as a more organized way to manage infrastructure beyond hacks and handm

I like how Ansible shows how sometimes technology can come full circle. Ansible started as a more organized way to manage infrastructure beyond hacks and handmade scripts. As technology matured and infrastructure become more complex, the simplicity of Ansible fell short, and tools like Puppet and Chef came into scene. But technology kept pushing forward, and these tools evolved to become increasingly complex until they become behemoths with towering ecosystems around them. Enter containers and container orchestration. Suddenly many of the problems that configuration managers were trying to solve aren't there anymore. And suddenly Ansible simplicity, which became its weakness, has become its strength.

FooBarWidget 9y ago
> As technology matured and infrastructure become more complex, the simplicity of Ansible fell short, and tools like Puppet and Chef came into scene. Wait what? I'm pretty sure Ansible came after Puppet and Chef, not the other way around.
- deleted 9y ago
  [deleted]
- oblio 9y ago
  CFEngine 1993 (for completeness) Puppet 2005 Chef 2009 Salt 2011 (also for completeness) Ansible 2012 OP's timeline is a bit off :)
  - dullgiulio 9y ago
    Before CFEngine, people used the 'm4' macro processor to generate configuration files. It was very common for sendmail ones, but also for fast replication with minimal differences.
  - liveoneggs 9y ago
    rdist 1983
- angarg12 9y ago
  You are right and I'm an idiot. I got introduced to them the other way around and didn't fact check. Sorry about that.
sergiosgc 9y ago
> Enter containers and container orchestration. Suddenly many of the problems that configuration managers were trying to solve aren't there anymore. I profoundly disagree with this statement. I think containers are, potentially, a huge step backward in the configuration management task domain. They are very useful in dynamic scaling orchestration tasks, but awful as a configuration management tool. And they are mostly used as a configuration management tool. Ansible/puppet/chef describe how to install your complete server pool. It's hugely reassuring to know that this knowledge is written somewhere, in formal form, that it is version-controlled and that it is debuggable. Containers as configuration management are the modern day equivalent of the mythical server that no one touches and that no one knows how to reinstall. (a bit exaggerated, but correct nonetheless)
- deleted 9y ago
  [deleted]
- cookiecaper 9y ago
  Yes. This is one of the biggest myths about containerization. Docker containers are opaque because: * "Dockerfile" or whatever that language is called is horrible, terrible, and very bad, with extremely minimal support for anything useful and braindead implementation for the little it supports (every new RUN line cements a new layer in the image, meaning you need lots of commands on a single RUN-line continuation to keep size down). Essentially, this means that people do all their work before Dockerization, in some undefined mechanism that is probably not very reproducible. Most often this is copying over static configurations, making changes, etc., before running docker build. * The FROM semantics encourage passing the buck and using opaque binary bases that are not necessarily well-understood. Since Dockerfiles are very hard to do anything useful in, people will get something minimal working and then cement it in a FROM tag to iterate further, because they don't want to potentially break that base. We have short Dockerfiles where I work but they are still stacked 2-3 layers deep, and this is just slapping binaries on top of each other; unlike an Ansible playbook, it provides no information about how or why these things are being combined. Docker image distribution does not necessitate source Dockerfile distribution. The build is not necessarily reproducible, and this semantic results in a big, fragile dependency stack when someone somewhere in the FROM chain falls over. It also creates some attack surface for injecting into an early commonly-used FROM source. People just trust that FROM images are great and good and reliable and trustworthy. We all should know how that will end up. Making a Docker image is much closer to the old "zip up this folder and label it 'todays-good-code' and save it on your desktop Bob, we don't want to lose it." There is no information about what is in that copy. It is a raw binary blob. This is the antithesis of configuration management.

FooBarWidget 9y ago

> As technology matured and infrastructure become more complex, the simplicity of Ansible fell short, and tools like Puppet and Chef came into scene. Wait what? I'm pretty sure Ansible came after Puppet and Chef, not the other way around.

deleted 9y ago
[deleted]
oblio 9y ago
CFEngine 1993 (for completeness) Puppet 2005 Chef 2009 Salt 2011 (also for completeness) Ansible 2012 OP's timeline is a bit off :)
- dullgiulio 9y ago
  Before CFEngine, people used the 'm4' macro processor to generate configuration files. It was very common for sendmail ones, but also for fast replication with minimal differences.
- liveoneggs 9y ago
  rdist 1983
angarg12 9y ago
You are right and I'm an idiot. I got introduced to them the other way around and didn't fact check. Sorry about that.

sergiosgc 9y ago

> Enter containers and container orchestration. Suddenly many of the problems that configuration managers were trying to solve aren't there anymore. I profoundly disagree with this statement. I think containers are, potentially, a huge step backward in the configuration management task domain. They are very useful in dynamic scaling orchestration tasks, but awful as a configuration management tool. And they are mostly used as a configuration management tool. Ansible/puppet/chef describe how to install your complete server pool. It's hugely reassuring to know that this knowledge is written somewhere, in formal form, that it is version-controlled and that it is debuggable. Containers as configuration management are the modern day equivalent of the mythical server that no one touches and that no one knows how to reinstall. (a bit exaggerated, but correct nonetheless)

deleted 9y ago
[deleted]
cookiecaper 9y ago
Yes. This is one of the biggest myths about containerization. Docker containers are opaque because: * "Dockerfile" or whatever that language is called is horrible, terrible, and very bad, with extremely minimal support for anything useful and braindead implementation for the little it supports (every new RUN line cements a new layer in the image, meaning you need lots of commands on a single RUN-line continuation to keep size down). Essentially, this means that people do all their work before Dockerization, in some undefined mechanism that is probably not very reproducible. Most often this is copying over static configurations, making changes, etc., before running docker build. * The FROM semantics encourage passing the buck and using opaque binary bases that are not necessarily well-understood. Since Dockerfiles are very hard to do anything useful in, people will get something minimal working and then cement it in a FROM tag to iterate further, because they don't want to potentially break that base. We have short Dockerfiles where I work but they are still stacked 2-3 layers deep, and this is just slapping binaries on top of each other; unlike an Ansible playbook, it provides no information about how or why these things are being combined. Docker image distribution does not necessitate source Dockerfile distribution. The build is not necessarily reproducible, and this semantic results in a big, fragile dependency stack when someone somewhere in the FROM chain falls over. It also creates some attack surface for injecting into an early commonly-used FROM source. People just trust that FROM images are great and good and reliable and trustworthy. We all should know how that will end up. Making a Docker image is much closer to the old "zip up this folder and label it 'todays-good-code' and save it on your desktop Bob, we don't want to lose it." There is no information about what is in that copy. It is a raw binary blob. This is the antithesis of configuration management.