Posts made by matteo nunziati

@stacksofplates said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

@stacksofplates said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

it can leverage full Jinjia2 templating straight inside state files (playbooks) letting you avoiding to split playbooks or add all of those ‘when’ directives all around;

See, I don't see this as a plus. You can do full j2 templating with Ansible also, but why? Why are you splitting playbooks?

You can't do full j2 in templates. j2 is a plus to me because I've been exposed to j2 for at least 1,5 years and it is really handy to me.

That is trying to use Jinja2 syntax in a yaml file, obviously it's not going to work. You can do full j2 templating in the j2 templates, not the playbooks.

mmm... AFAIK roles are useful to discriminate between functions, like webserver, database server and so... but when you have to manage heterogeneous OSes like CentOS and Ubuntu I'd like to prefer the {%if %} {%else%} approach of Salt.

In my small trip around ansible I've had to put a lot of whens all around. The alternative was to write a playbook for the webserver role of CentOS and one for the webserver role of Ubuntu, and then include both into an "abstract" webserver playbook.
Unless I'm missing something, having an if/else turned more handy to me.

How do you cope with different OSes and how do you abstract away differences with Ansible in your daily job?

All of that functionality should be in the role. The role should be standalone so it can run on any machine, that "logic" shouldn't be in the playbooks. For example, a role that installs apache could be set up like this:

main.yml has your include and conditionals:

---
- include: rhel.yml
when: ansible_os_family == "RedHat"

- include: ubuntu.yml
when: ansible_os_family == "Debian"

Then the specific tasks for each would be included in those yml files.

There are other ways to do this, like using variables in conditionals for package names, but this is a simple setup. That way you need one conditional at the beginning.

Take a look at how people set things up on Ansible Galaxy. The playbooks should only tell what roles to run on what hosts. So a site.yml is your main playbook that has includes for everything, and then you can break out your playbooks into dev, test, and prod machines. Or however you want to separate them.

yes, that's what I was thinking of. in Salt you do this by writing a single file with an if/else statement, beacuse you can mix yaml and jinja. You just have a single webserver.sls. I simply feel more comfortable with this approach because all the logic is in one place.
I mean: if you have tasks which are common to RedHat and Ubuntu, you put them into the main.yaml I suppose, to not duplicate code. At that point if you have interleaved common/specific tasks you have to create a lot of fragmentation with all that includes and a number of "micro" files, or you end up duplicating code in files to have less fragmentation...

I can't imagine otherwise... I'll look at Galaxy.

@stacksofplates said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

@stacksofplates said in wetting my feet with CM software:

@scottalanmiller said in wetting my feet with CM software:

@stacksofplates said in wetting my feet with CM software:

@scottalanmiller said in wetting my feet with CM software:

@stacksofplates said in wetting my feet with CM software:

@scottalanmiller said in wetting my feet with CM software:

You left out instant commands. Salt can run commands or changes against the environment "instantly", faster than SSH. If something is wrong and you need to push a change or you need to be really tight on the timing of a change, Salt makes this incredibly easy.

This is completely wrong. If you run Ansiblr in parallel it will change every machine at the same time instantly.

No need to make a connection first? How is Ansible doing that? Do you move to an agent structure just like Salt? Salt's claim to speed fame is not needing to set up an SSH connection first.

That said, I was unaware that Ansible could do "instant" commands.

Salt still has to make a connection. The data has to get to the remote machine somehow. It's just as fast with SSH and running in parallel you can run over 1000 machines at the same time. The slow down is the default of 5 machines in parallel, but you can change that.

Salt already has a connection, that's the difference. It's an open channel. Does not need to establish a connection to run the commands.

My point is the data is on one machine, and needs to get to anther. So while the connection is there, the data isn't. The SSH sessions take no time to set up. For all intents and purposes, it's instant. If it's not, it's not Ansible's fault, it's something with your environment.

I think the plus of Salt is that minions do not need firewall openings. Unless you still use a pure ssh as fallback.

We need SSH for other programs and remote sessions into the machines, so I have to have it anyway.

yeah that's my point too, but SAM seems to manage things a bit differently.

@stacksofplates said in wetting my feet with CM software:

@scottalanmiller said in wetting my feet with CM software:

@stacksofplates said in wetting my feet with CM software:

@scottalanmiller said in wetting my feet with CM software:

@stacksofplates said in wetting my feet with CM software:

@scottalanmiller said in wetting my feet with CM software:

You left out instant commands. Salt can run commands or changes against the environment "instantly", faster than SSH. If something is wrong and you need to push a change or you need to be really tight on the timing of a change, Salt makes this incredibly easy.

This is completely wrong. If you run Ansiblr in parallel it will change every machine at the same time instantly.

No need to make a connection first? How is Ansible doing that? Do you move to an agent structure just like Salt? Salt's claim to speed fame is not needing to set up an SSH connection first.

That said, I was unaware that Ansible could do "instant" commands.

Salt still has to make a connection. The data has to get to the remote machine somehow. It's just as fast with SSH and running in parallel you can run over 1000 machines at the same time. The slow down is the default of 5 machines in parallel, but you can change that.

Salt already has a connection, that's the difference. It's an open channel. Does not need to establish a connection to run the commands.

My point is the data is on one machine, and needs to get to anther. So while the connection is there, the data isn't. The SSH sessions take no time to set up. For all intents and purposes, it's instant. If it's not, it's not Ansible's fault, it's something with your environment.

I think the plus of Salt is that minions do not need firewall openings. Unless you still use a pure ssh as fallback.

@stacksofplates said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

it can leverage full Jinjia2 templating straight inside state files (playbooks) letting you avoiding to split playbooks or add all of those ‘when’ directives all around;

See, I don't see this as a plus. You can do full j2 templating with Ansible also, but why? Why are you splitting playbooks?

You can't do full j2 in templates. j2 is a plus to me because I've been exposed to j2 for at least 1,5 years and it is really handy to me.

The role should be taking care of that by either having a main.yml with include statements for conditionals under your tasks, or if there aren't enough differences only using a when directive for that specific task.

mmm... AFAIK roles are useful to discriminate between functions, like webserver, database server and so... but when you have to manage heterogeneous OSes like CentOS and Ubuntu I'd like to prefer the {%if %} {%else%} approach of Salt.

In my small trip around ansible I've had to put a lot of whens all around. The alternative was to write a playbook for the webserver role of CentOS and one for the webserver role of Ubuntu, and then include both into an "abstract" webserver playbook.
Unless I'm missing something, having an if/else turned more handy to me.

How do you cope with different OSes and how do you abstract away differences with Ansible in your daily job?

@scottalanmiller said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

mmm... I got it! I prefer to clone plain vanilla rather than rebuild my images (I mean VM images)

I figured that out... but why? Why leave out the standardization stuff that is where all the power is?

Because my approach is: what is upstream is default, what is mine it is not. As I do not provide services to others, I do not need to be an upstream for someone else, therefore I always restart from scratch. And having a CM to do this for me is a real added value.
I mean that as setting up a cronjob in a reproducibile manner is important for a certain class of service (say a backup) It is also important to me to setup everything from scratch in a reproducible manner.

ex.:

• I've changed my keys? just re-deploy them
• Salt/Ansible run with python3? just avoid to use the available image with python-minimal on it. just drop it from the playbook/state

@scottalanmiller said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

Still, from a more detailed POW: still do you think that having the agent into the image is better than use the ssh approach? I always end up considering that an ssh is always good as a fallback. I'm comparing here Salt master/minion vs Salt-ssh to make that clear.

Yes, not having SSH at all I consider the biggest "slam dunk" for Salt. I see needing to SSH into a machine ever as a bit of a failure now. I don't want SSH to even run, let alone be needed.

wowa that's would be a good article on best practices and "why you need access (and which) to your machine".
My mind set is always:
1- be sure to have local access. (in VM this is the virtual console provided by the hypervisor)
2- be sure to have remote access.
3- implement any other mechanism of communication with the machine (like Salt in this case)

but I never close any of the others later. Just keep them as fallback.

btw, remaining on the Ansible/Salt comparison I would like to have an opinion also from @stacksofplates , being he an avid ansible user.

@scottalanmiller said in wetting my feet with CM software:

Still not clear, which commands are you looking for?

@scottalanmiller said in wetting my feet with CM software:

You left out instant commands.

Those commands and the link to them in the docs.

@scottalanmiller link to direct commands in Salt.

@scottalanmiller said in wetting my feet with CM software:

Same with Ansible, there is no agent there by default, nor keys for accessing the OS. Neither "just works". Nothing does. And just doing installs from ISO is a lot of effort that isn't needed. That's way more time consuming and complex than doing one install, installing keys for Ansible or the agent for Salt, running updates for security then making an image. Making a new install is seconds after that, instead of a long time. It's worth it, even for a single additional install.

mmm... I got it! I prefer to clone plain vanilla rather than rebuild my images (I mean VM images) so that's where my considerations comes from. In this specific case it would mean to add a standard user locked down without password. Therefore it could be rather straight forward to have the user in place and "clone" it as you have not to add different users/passwords.

Still, from a more detailed POW: still do you think that having the agent into the image is better than use the ssh approach? I always end up considering that an ssh is always good as a fallback. I'm comparing here Salt master/minion vs Salt-ssh to make that clear.

@scottalanmiller said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

• The relevant thing here is: how can massively create this user from a plain VM not customized at installation time and deployed on N VMs (with N possibly really big)? Maybe a datacenter can customize an iso, but a small company like mine is best server by Ansible like solutions, especially in disaster recovery scenarios, where you have to think fast at a lot of things.

Why would you not have your VM customized? Size doesn't make any difference. Even if you are a one man shop with one server, you would customize your installation distro. We do this just for our lab alone, for example. And we do it on Vultr or Linode. Makes everything much easier and standardized, even if you are not using a tool like Ansible or Salt. In fact, the smaller you are, the more important that efficient processes be used. Big companies can afford to be more lax, and often are.

mmm... link please
(OK, after luch I will search for it anyway)

@scottalanmiller said in wetting my feet with CM software:

It "just works" when we've used it. No need for dependencies to be met, no user creation, no SSH in from the outside... nothing like tha

if you install the minions everything is resolved by the installer either the boostrap script or the repository you have choosen. What is nice about Ansible if that you just need to apt-get/yum install it on a control machine, then "minions" are there, just add the dependancy installation as very first step in your palybook and ansible "autoinstalls" requirements.

You can do this even with Salt, but you need salt-ssh -r on the command line and then you can execute any state deployment with Salt (either salt-ssh or salt master/minion).

Everything boils down to the fact you have or not an image ready to go with your CM tools. With Ansible you do not need it, you can do on the fly. with Salt you have an intermediate step. To me it is better to run salt-ssh to instrument your target machines, rahter than preseed an image. This is massive do not requires you to poke with isos ad so...

It is just an additional step to remember even when you are in a hurry. just this.

Or, of course, I've missed something. Do not forget I've just started this as a learning project, so exchange here is really appreciated.

@scottalanmiller said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

• Considering this, instrumentation is a bit more of a trouble in Salt: while Ansible can check with pure shell commands for its platform requirements (and install them), you have to force salt to install those items from a salt-ssh cmd line. It can’t create a state file for instrumentation in the likes of ansible “instrumentation” playbooks.
• This implies that rebuilding an infrastructure is not a one line away with Salt as it is with Ansible, first you need to instrument with salt-ssh, then run environments (cascade of playbooks in Ansible terms). As a side note ansible requires libselinux-python as additional dependency in CentOS 7, while Salt doesn’t.

What do you mean? You'd have Salt built into your base image. So none of this would apply in normal circumstances. Salt would already be installed along with all dependencies before you even start.

that's the point: if you run a standard ISO from canonical or redhat/centos, you have not it installed by any default install: you have to add it and/or preseed the installer (never done this, so I'd have to experiment with this).

@scottalanmiller said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

• Salt doesn’t work well with sudo. It requires that the user has NOPASSWD rights for sudo. This basically kills usage on any Ubuntu like distro. The solution is to manually add a special locked user with NOPASSWD rights in sudoers. In fact, giving the standard user NOPASSWD is close to security suicide.

This isn't a standard user, though, so that this is considered bad for standard users isn't applicable here. So that's not a negative.

It is negative in that I've to make adjustements to "plain" installed distros by hand, or at least other configuration tools. Then having a dedicated locked down user is perfectly OK.

@scottalanmiller said in wetting my feet with CM software:

@matteo-nunziati said in wetting my feet with CM software:

• The first thing to consider as now is that Salt is less available than Ansible in distros’ packages. Moreover, being Ansible backed by Red Hat is possible that they will purge Salt as they done with Xen.

What do you mean purge? Xen is still supported by Red Hat and XenServer is still built on it.

I mean that new Rad Hat products have KVM per default and Xen, to my humble opinion, is a second class citizen - at least since Red Hat 7. Of course they support their previous releases, and of course XenServer is built on it, but it is based on the CentOS distro and is supported by the XenServer project (Linux Foundation?) not by direct Red Hat support.

Once up and running, Salt is really the winner to me, for a number of reasons:

• it can leverage full Jinjia2 templating straight inside state files (playbooks) letting you avoiding to split playbooks or add all of those ‘when’ directives all around;
• its file.managed state is a proper diff-patch automatic routine able to check for file state without you to be required to create patches or so like you have to with Ansible: it is just auto-magic;
• while distro specificities are always there Salt tends to abstract away as most as possible the underlying OS you are configuring, leading to certain reductions in number of lines/verbosity. It is just a bit more “dense”. While not incredibly more dense, it is still more compact;
• I’ve not dig this in depth, but Salt allows you to keep your config files in a git repo in the cloud (say github or bitbucket) and deploy them from here. I’m talking about config templates or so, like a crontab file etc... Again I’ve not tested this so I can not comment on it, but it is a really nice idea. Ansible can leverage git in a way or another, but has not builtin modules for file redistribution straight from git.

ok, I've pushed the configuration scripts for Salt on github. In the while here is my conclusion, after I've experimented a bit with both systems. Again: this is the newbie approach so keep it with a grain of... Salt(stack)

My conclusion here is that Ansible is more radicated and mature, but Salt is more powerful/easier to deal with when up and running. The issue is how to make it up and running:

• The first thing to consider as now is that Salt is less available than Ansible in distros’ packages. Moreover, being Ansible backed by Red Hat is possible that they will purge Salt as they done with Xen. This implies a bit of troubles as the recommended install ways of Salt either require you to stick with a vulnerable version or expose you to the fast pace of updates which - for security reasons - already have broken backward compatibility twice. Considering this, I’ve ended up with the salt-ssh approach, which resembles the Ansible one and involves just the control machine, avoiding risky version upgrades.
• Both systems don’t run on python3, with Ansible having an experimental mode enabled. This implies that even today you have to instrument Ubuntu distros (as in a near future Debian too) with a python-minimal package which is able to deal with Salt/Ansible.
• Salt doesn’t work well with sudo. It requires that the user has NOPASSWD rights for sudo. This basically kills usage on any Ubuntu like distro. The solution is to manually add a special locked user with NOPASSWD rights in sudoers. In fact, giving the standard user NOPASSWD is close to security suicide.
• Considering this, instrumentation is a bit more of a trouble in Salt: while Ansible can check with pure shell commands for its platform requirements (and install them), you have to force salt to install those items from a salt-ssh cmd line. It can’t create a state file for instrumentation in the likes of ansible “instrumentation” playbooks.
• This implies that rebuilding an infrastructure is not a one line away with Salt as it is with Ansible, first you need to instrument with salt-ssh, then run environments (cascade of playbooks in Ansible terms). As a side note ansible requires libselinux-python as additional dependency in CentOS 7, while Salt doesn’t.
• Basically this means that Salt instrumentation is more cumbersome: while ansible requires you to export your keys and set up the hosts file (Roster in Salt), here you also have to create the user and then manually issue a salt-ssh command system wide, without any target filtering, as you cannot know if you send an apt-get command for instrumentation even to CentOS machines. Really a bad hack, maybe due to my noobness.
• The relevant thing here is: how can massively create this user from a plain VM not customized at installation time and deployed on N VMs (with N possibly really big)? Maybe a datacenter can customize an iso, but a small company like mine is best server by Ansible like solutions, especially in disaster recovery scenarios, where you have to think fast at a lot of things.
• Another thing to mind of is that issuing raw shell commands is neither well suited for error catching nor for input security, but, in the end of the day it can save your day, as it fits well the role of fallback. While this is not possible before instrumentation with Salt, both systems can do this once up and running, allowing you to fill possible features holes in the functions (somethin glike systemd modules not already in place).

we have a company in my town: second quadrant. the provide professional postgresql support worldwide and they pronunce it "postgres". omitting the final "ql"

@scottalanmiller said in Normal Forms of Systems Administration:

Fifth Normal Form: "Fully Described State". No logins and no commands are used but rather all administration is done via a state machine.

an example in real world? I stick to the forth form, and I'm not aware of anything after that!

just for the curious, I'm trying to configure a couple of VM with ansible and salt just to compare them.
here is my diary with the gists.

notes:

• this is a work in progress
• this is really n00b stuff: I'm a coder not a sys admin
• I'm not the kind of man than reads the full doc and then start code with order <- I rather create a lot of chaos and then I reorder and formalize after docs
• the document is a sort of diary updated live in these days whenever I've time.

bye bye

@JaredBusch that's exactly the opposite for me: I prefer a billion of mails to check altogether rather that fuzziness.