16 ms·

Would you say that this can be compared to what leetrout commented with the difference that instead of scripts there is only a single command? Is the playbook

by hakre 6y ago

Would you say that this can be compared to what leetrout commented with the difference that instead of scripts there is only a single command? Is the playbook always called "play.yml"? And how do you handle multiple repositories (or is there only a sinlge one?)?

zufallsheld 6y ago
Yes, it's basically the same what leertout does. And no, it is not always called play.yml but according to its function, e.g. "install_foo.yml". We typically have all our code for one customer in one repository.
- hakre 6y ago
  Yes, that clarifies a lot. And yes, one repository per configuration (per customer code). Is it that you have one inventory per customer configuration? Or how do you manage multiple inventories in this setup?
  - zufallsheld 6y ago
    > Is it that you have one inventory per customer configuration? Or how do you manage multiple inventories in this setup? We have different customers with different servers and applications. Every customer has its own repository with one or more inventories.
    - hakre 6y ago
      Thanks for your quick feedback. And how do you share the context / documentation which yaml file is intended to be called by which ansible utility with which utility parameters and switches? I ask b/c this is normally the problem I run into when things grow and I found the suggestion in the OP interesting to this regard as it adds the context while implementing, not documenting afterwards (and such documentation often becomes stale). Also documentation is often declarative (like do this, then that etc.) and it does not show the original thoughts/ideas behind a certain utility invocation. I'd be interested to learn a bit more here, so if you could share a bit of context from your end would be nice.
      - zufallsheld 6y ago
        > And how do you share the context / documentation which yaml file is intended to be called by which ansible utility with which utility parameters and switches? Like I said: Ideally there are no switches and parameters - the playbook should work as-is. If there are switches, we document them in our internal confluence. And yes, our docs get stale, too. That is a problem that we did not fix yet. :) Many playbooks also get executed automatically, so there'S no need to remember parameters for them. You just start the CI-job that then runs the playbook.

by hakre 6y ago

zufallsheld 6y ago

Yes, it's basically the same what leertout does. And no, it is not always called play.yml but according to its function, e.g. "install_foo.yml". We typically have all our code for one customer in one repository.

hakre 6y ago
Yes, that clarifies a lot. And yes, one repository per configuration (per customer code). Is it that you have one inventory per customer configuration? Or how do you manage multiple inventories in this setup?
- zufallsheld 6y ago
  > Is it that you have one inventory per customer configuration? Or how do you manage multiple inventories in this setup? We have different customers with different servers and applications. Every customer has its own repository with one or more inventories.
  - hakre 6y ago
    Thanks for your quick feedback. And how do you share the context / documentation which yaml file is intended to be called by which ansible utility with which utility parameters and switches? I ask b/c this is normally the problem I run into when things grow and I found the suggestion in the OP interesting to this regard as it adds the context while implementing, not documenting afterwards (and such documentation often becomes stale). Also documentation is often declarative (like do this, then that etc.) and it does not show the original thoughts/ideas behind a certain utility invocation. I'd be interested to learn a bit more here, so if you could share a bit of context from your end would be nice.
    - zufallsheld 6y ago
      > And how do you share the context / documentation which yaml file is intended to be called by which ansible utility with which utility parameters and switches? Like I said: Ideally there are no switches and parameters - the playbook should work as-is. If there are switches, we document them in our internal confluence. And yes, our docs get stale, too. That is a problem that we did not fix yet. :) Many playbooks also get executed automatically, so there'S no need to remember parameters for them. You just start the CI-job that then runs the playbook.