wetting my feet with CM software

scottalanmiller

Does Ansible handle Local Group Policy well? I looked quickly but didn't find anything really useful. Salt has this...

https://docs.saltstack.com/en/latest/ref/states/all/salt.states.win_lgpo.html

matteo nunziati

@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?

matteo nunziati

@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.

scottalanmiller

@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.

Yeah, that's my top thing that I like there.

stacksofplates

@scottalanmiller said in wetting my feet with CM software:

Does Ansible handle Local Group Policy well? I looked quickly but didn't find anything really useful. Salt has this...

https://docs.saltstack.com/en/latest/ref/states/all/salt.states.win_lgpo.html

Not sure. I don't do anything with Windows so I have no experience to speak from.

stacksofplates

@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.

stacksofplates

@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.

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:

@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.

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

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

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...

How is that any different than if/else statements?

if == ubuntu
package=apache2
else
package=httpd

when: ansible_os_family == "Debian"
pkg = apache2
when: ansible_os_family == "RedHat"
pkg = httpd

You don't need mico files at all. Just call variables in your j2 templates depending on the OS or OS release. Say for instance you use port 22 on RHEL and 2222 on Ubuntu (stupid but just an example), use the same j2 file with a {{ ssh_port }} variable and have the task insert the port number. No need for anything else other than a single template file.