8:30 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2020-07-28 00:27, Maciej Delmanowski wrote:
On lip 27, Robin Schneider wrote:
I think that DebOps is slowly approaching a point where more complex
deployments might require more than one non-idempotent Ansible playbook
runs to finish configuration. The individual services of course run
idempotently as standalone, but various roles rely on Ansible local facts
defined by other roles more and more, which means that 2-3 full runs might
be required to "stabilize" the final infrastructure. It's a hard problem
to
solve with a linear deployment strategy we use with Ansible. Something more
dynamic and parallel[1] could make the deployments with eventual
consistency, when various services "come online" during execution and
affect other services.
I am ok with potentially needing multiple runs as well for the reasons you
pointed out.
A completely different configuration management system comes to mind,
namely mgmt[2]. I wonder how far along the project is from a stable
release, and if the developers would consider a configuration scheme as
flexible as Ansible so that DebOps could be ported to it. I guess we will
see eventually; in the meantime multiple playbook runs that finish in a
consistent and idempotent state will have to be the norm.
[1]:
https://purpleidea.com/blog/2016/01/18/next-generation-configuration-mgmt/
[2]: https://github.com/purpleidea/mgmt
Always interesting to keep an eye out for improved designs. Good thing is we
don’t have to be early adopters because we have something that works
reasonably well.
> Some input for how to design the wrapper role. Consider if common
> documentation can be shared as in only document it once in the wrapper
> role. This way it defines the "interface" (as in Java) of the wrapper
> role that would actually be implemented by the actual roles. That means
> of course that all alternative roles try to implement the same
> "interface" (needed/recommended anyway).
No, that's not what I envisioned with the "wrapper roles". They are only
something akin to "switches" of sorts that run a specified service role
with the dependent variables that role listens to passed on. In a 'nginx'
vs 'apache' case, you still will have to define say,
'nginx__dependent_servers' and 'apache__dependent_servers' variables in
a
role like 'owncloud', with the syntax required by the respective roles.
There might be issues with some variables being unacessible between the
complimentary roles, so the public interface of a given service role will
have to be considered very carefully to work around that. But since DebOps
has strict separation of variables between roles and no direct access, I
think that we are ready for this.
Just an idea and I guess my thinking was too locked on how it was back then.
You are right, now with the mono repo, we have more options for the docs and
with the 'import_role' task.
Also, this common "interface" would probably only work for some roles. For the
databases MariaDB and PostgreSQL, it would not as they have different concepts.
> And my take on what others are doing. You are right, I am not aware of
> others doing this dependency variable passing. But that is one of the
> things that make DebOps great for me. This really helps to deploy
> services. I don’t have to care about the host firewall or the webserver
> config for the application. The role contains sane defaults. Awesome.
>
> Also the official SaltStack formulas that I know of don’t handle
> webserver nor Firewall, so you have to do that yourself.
I envision that the "infrastructure as code" solution such as DebOps
should encode as much automation as possible between different low level
operating system services. I don't really want to think about low-level
details each time I set up a new service anymore. In the container-based
world, it seems that Kubernetes Operators[4] seem to be a solution for this
problem.
We made pretty good progress with Ansible on the standalone host so far
via Ansible local facts, but there's still some way to go in a cluster
environment. In this case, something like SaltStack's Event System[5]
really starts to look seductive... I wonder if we can find a lightweight
alternative without all the other configuration-related baggage that could
be co-opted for use with Ansible. Probably some kind of universal RPC
service that could be used to execute authenticated and authorized
commands. Pub/Sub support would bring more flexibility as well.> [4]:
https://kubernetes.io/docs/concepts/extend-kubernetes/operator/ [5]:
https://docs.saltstack.com/en/master/topics/event/events.html
Don’t be afraid of SaltStack itself :) SaltStack can make use of Ansible at
various levels (module level, playbook level). The other way around seems to
also have some integrations.
> For my taste we don’t have to keep supporting stuff we don’t use.
About
> ntp roles: I don’t really see the need for ntpd (ntp.org) anymore.
> chrony supersedes it. I propose you drop ntpd support and see who screams
> and if they have good reasons for it :) Kind of similar with Apache
> except that there are still valid use cases for it, but not in DebOps
> main application stacks. I would not spend too much time on it.
This probably calls for a survey among DebOps users to see who uses what.
LimeSurvey[4] role could probably come in handy, and it seems to be a
popular application for this kind of thing. I'll add it to the todo list.
[4]: https://www.limesurvey.org/en/
I have done a somewhat extensive research on this kind of software ~1 year ago
and limesurvey scored strong.
But I would rather ask if there are any technical reasons against things like
chrony. Otherwise you have the issue that people doing the survey might not be
up-to-date/universally informed and just vote for what they currently use. We
should still push for good solutions rather than legacy once.
- --
Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7eE3HRuH0o2l6AUVhv2YC78aQPgFAl8gbqwACgkQhv2YC78a
QPjw5A/+I5pr/4mwhddMztoWeoObd9BUWyI2iNTgJq9HogkT784fpa4+Sutbbuch
+KVFrKD0SmZAm3dgfnPOBCVGJMQv9w+5PbDZf8nfGo4eqvWsG4BMdh2vciv6ioX0
Z8sKzsmCPuWdJeI3SWWg950eUy4+oXywL6I3SJL3o6CeEQx/QTQHp44TJm6bvOeZ
rIBZLsKtGk4X6QWztToyHTy2pItyr315gvq2cDMn4O5PUluBmMkMOzhOsRxLWzJV
/oeaL9CDuibIGkjQVXr+pn3Txiazay1MbFe9n2crZ89Zl6wsJmaDirlQO87pWqL8
dlMUVFMNLmIvBQIulQdlEzUn98tJnGqFPDT/vghDjLHW4nS9x6YxbakWDKbm5LyV
BCZhu0uNs/6ZApEWO36ooW3XUKafy6UDN2dXa3w+d39u6KMvfnq/GcjYaZxEHTkb
rHSnUyOd5Fpl4HkbHfLrS5KiWZcIdnmgm8nw+haSbryb7pdZB10VyZ5Vv46H+ejJ
YwdQcy4RH/2tgQAros/WAtcvEF7opz/j/ArwJfqAdFjhMEQftDPf7zUzTX3YH76D
tyb6qxEJtaq4NwMch20mmzkZkomxU4Pqz9hE3MXNWk5BlGdDlys7vYwuAZQX880u
FvoX9jtzsyFCqBstNaKcbcHSJDUr/pFdyHGvg3thu3VQOOhmhvg=
=fH6h
-----END PGP SIGNATURE-----