[Gluster-infra] Switching from salt to ansible ?
mscherer at redhat.com
Tue Jan 5 13:59:27 UTC 2016
Le mardi 05 janvier 2016 à 10:22 +0100, Niels de Vos a écrit :
> On Mon, Jan 04, 2016 at 05:27:10PM +0100, Michael Scherer wrote:
> > Hi,
> > so over the holidays, I was pondering on moving to ansible from salt.
> > So the reasons are numerous:
> > - I am personally much more efficient with ansible than with salt
> > (despite using salt for 1 year). While the 2 tools do the same basic
> > stuff, there is always some difference (like user vs owner), and there
> > is a totally different philosophy when it come to multiple servers
> > orchestration (one example is how I do deploy freeipa on salt vs
> > ansible).
> Many of us are more familiar with Ansible than Salt. It'll be easier to
> get contributions from developers when Ansible is used.
Yeah, that's the point. But I also wanted to know how much people know
the tools, for how long, etc, etc.
> > - Fedora is using ansible, and while we can't reuse their code that
> > much, we can at least take it and adapt.
> And can ask the Fedora sysadmins for help/ideas, or discuss the general
> approach of a role/task. If something in our Ansible doesn't work well
> enough, they might be able to share their thoughts. Fedora Infra is
> interested in Gluster and they would surely assist with some bits in
> return for our help ;-)
yeah, that's a issue I have with salt, not much people to discuss with
( as I converted my friends to ansible...). And while I go to the local
salt meetup every time, I often ask to do stuff in a different way that
the salt philosophy, or where doing things properly would requires more
python code (like freeipa integration, for one)
> > Now, there is a few downsides:
> > - it mean rewriting most of the stuff we already have
> > - it mean that we depend on sshd to be running. IE, if we screwed ssh
> > config (happened in the past), we can't just use salt to fix it.
> Having ssh running, or the salt-minion, does not make much of a
> difference to me.
IIRC, salt-minion do not open a port, it connect to the salt-master. It
can also connect in a P2P fashion, or run locally. Both tools are
equally flexible on that point.
But the way we use salt is the standard way, one salt-master, where each
minion connect to receive order.
And the point is "I deploy a new config change on openssh", who do not
work on EL5, and poof, we lost the access on a server. When it did
happen on salt, I just reverted the change and that's it (happened last
In the mean time, I did add safeguard (like testing the config before a
restart...), so that's less risky, but still.
> > - it also mean that we will have a ssh key to connect as root on a
> > server, and i am not that confortable with the idea (provided that we
> > use the regular method of using ansible, ie push based)
> Or (a dedicated ansible user and) use sudo? Might make auditing a little
> easier. I think its even possible to use sshd/Match on a username and
> only allow certain logins from selected sources (like a management
yeah, making the key restricted by IP seems the best protection (it
might cause some bootstrapping issues, but I guess I can fix that).
About sudo, not sure what it does bring to us in term of auditing.
Ansible do send everything to syslog anyway, and sshd can tell you what
key was used (maybe not by default, and that's for sure less obvious to
grep in log).
And having ssh ansible at server + sudo without password seems the same ssh
root at server regarding access granted by the key.
Maybe I am missing a race condition regarding the log (ie, if someone do
ssh root at server killall -9 syslog, will the connexion be logged to the
remote syslog server ?)
Another solution is to use ansible over salt
( https://github.com/ansible/ansible/pull/12836 ), which mean we get the
benefit of both world. If we decide to switch, I would maybe start by
that until we can get a more secured network setup (ie, reuse the
existing salt setup, and migrate slowly).
Sysadmin, Community Infrastructure and Platform, OSAS
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Gluster-infra