Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This was before Infrastructure-as-Code, Immutable Infrastructure, etc were popularized. 99% of the time, on greenfield systems, you shouldn't have to use Puppet or Chef or Ansible.

Runbooks-as-Code is also a great practice, similar to the notebook shown here. But they should be limited to one-time actions, like triage, recovery, etc.



> 99% of the time, on greenfield systems, you shouldn't have to use Puppet or Chef or Ansible.

I'm not entirely sure about this. One one hand, being able to set everything up once manually and just documenting the process usually will be easier, so people will opt for this, if given the choice.

Then again, I'm pretty sure that certain people aren't all that good at documentation and will write as little of it as possible, leading to this greenfield project that will inevitably turn into a brownfield project 5 years down the line now being at a disadvantage.

By then, nobody will really have any idea how to set up a new environment, or what exactly it needs. Worse yet, if you have some sloppily written documentation, that actually is no longer accurate and lies to you.


I'm pretty sure what he meant was that Puppet/Chef is for wrangling VMs, and for a greenfield project, there are better tools available than VMs.

If not, I agree with you, if you need them, you should use Chef/Puppet every time.


> I'm pretty sure what he meant was that Puppet/Chef is for wrangling VMs, and for a greenfield project, there are better tools available than VMs.

That's also fair, as long as you don't have requirements to run on-prem, where a lot of the cloud offerings won't usually be available.


Can you point to a repo that shows how this is done, are you saying docker-compose or nix or something? source: not a devop, just a vintage dev.


note that docker-compose is lately "docker compose" -- i.e. a plugin to mainstream docker-ce




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: