On Fri, Jun 18, 2021 at 4:41 PM Wei-Yen Tan <[email protected]> wrote:
>
> Ansible is a tool for configuration management which has been aptly been
> explained but I will explain further to give some detail . The second use
> case is orchestration.
>
> If you program say with a script you tell it what to do. You have to control
> from the start to finish the logic what to do. It is in order.
>
> When you use ansible you don't have to program. You just say I want this
> thing to look like this and it will do it. But ansible can put things in
> order too in other words orchestration. This becomes powerful because it
> allows people to write what could be otherwise complex code into something
> that is concise.
>
Wei-Yen,
yes, this is exactly what I am struggling with.
Defining a state is not simple.
At the base level Ansible provides serviced module that recognizes
started, stopped, restarted, reloaded states.
When a service is deployed as part of a larger system, the state space
is different:
- started at version X
- started at version Y
- stopped
- restarted at version X
- restarted at version Y
- etc
The versions are managed by other tasks in the playbook that are
performed in specified sequence.
Depending on at what point in the playbook execution and whether this
task is run, the service may end up in either version X or version Y.
serviced:
state:
- restarted
Driving X to Y change is powerful, but seems far from concise.
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAGB%3D%3DuL3WoZQv%3DfCuA0s%2BWCqg5%2BOk7HEvF2cHjg%3DjqVEpzO2YQ%40mail.gmail.com.
