On the matter of philosophy, as someone who has taken care of
infrastructure for a while but who is new to Ansible, here is my general
take. What do you think? How does it compare with your vision?
* A deployment script is primarily a declaration of intended state. (E.g.
logical volume X should exist and should have size at least 10GB.)
* If you tell a physicist the above, he or she is likely to counter that
abstract truths don't exist in the real world. The only truths are
empirical. When we say that a drive has size 10G what we really mean is
that we can write 10G of data to it and read it back. Actually doing that
every time we want to check a partition size is a bit slow and tedious so
we may use lvdispaly instead (knowing full well that lvdisplay can give a
different answer) but this is still an actual verifiable test, not an
abstraction.
* Corollary: A deploy script's declaration of state is a sequence of tests
of the form "is the world in state X?".
* If a test of the form "is the world in state X?" returns negative, a
deploy script should have an action of the form "make it so".
* Lesson from life, just because an installation script returns true
doesn't mean that it succeeded. The world is full of broken code and it is
pointless trying to rail against it. Any deploy script that does: `check
else install` is vulnerable to broken installers. Site reliability
engineers cannot afford to write installers like that. Their installers
must always be of the form `check or ( install and check again )`.
* Corollary: Every aspect of an install script needs two functions: check
and install, and they should be run as `check or ( install and check again
)`.
feature X:
check: `function that checks whether X is so`
install: `make X so`
feature Y:
check: `function that checks whether Y is so`
install: `make Y so`
...
One nice thing about this philosophy is that it is not infrequent to be
faced with a situation where you think: `Great, I have installed a program
called foowidgeebar. Now, how do I know whether it works?` If the
installer is well written it will have a definition of 'it works' that is
empirical. If foowidgeebar is a web server, the ultimate test is `curl
http://localhost:80`. If the program is a postgres database and the
definition of installation is that user moog can run sql queries then a
test is `sudo -u moog psql -c "select 99;"`. It becomes really easy to
check whether a machine, system, server or cluster is in a good state. If
an installer doesn't have a read-only "check that the installation is good"
mode than that is a big red flag.
* Now, why use a structured format such as YAML to encode the desired
state? A: Because that lets you reason abut your desired state. It makes
it easy to say: `My desired state has 8 hosted servers so my projected
monthly bill is 16 gold ingots.` or `My desired state has 100 users but
actually there are 110. Who are these additional users with access to my
systems?`
How closely does this match Ansible's vision?
Best wishes, Max
--
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/2d9dcf9d-cff7-432f-bcbb-06d3764e25cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
