wetting my feet with CM software
-
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller link to direct commands in Salt.
Still not clear, which commands are you looking for?
-
@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 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:
@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
-
@matteo-nunziati said in wetting my feet with CM software:
@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.
OH!
First example here, the cmd.run option...
https://mangolassi.it/topic/11821/executing-basic-commands-with-salt
-
@matteo-nunziati said in wetting my feet with CM software:
@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.
Salt retains remote access, it just gives you a more secure one than SSH. You don't give up remote access, you simply improve it.
-
@matteo-nunziati said in wetting my feet with CM software:
Becaouse my approach is: what is upstream is default, what is mine it is not.
Yes, I understand this, but why? This is universally considered bad from all experience that I have. Your default exists for one purpose - for you. If you are using the upstream default, you are prepping a system that isn't for you. Why? Make it for you! There's no benefit to prepping it for generic use as your goal is to make it for your use, not someone else's.
-
@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.
No, there is no Xen support any longer from Red Hat. XenServer being built on CentOS has nothing to do with weather Red Hat will support it or not.
-
@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.
-
@stacksofplates said in wetting my feet with CM software:
@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.
No, there is no Xen support any longer from Red Hat. XenServer being built on CentOS has nothing to do with weather Red Hat will support it or not.
Ah right, they dropped server side support. They still include the client extensions though.
-
@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.
-
Looks pretty easy to do...
http://docs.ansible.com/ansible/intro_adhoc.html -
@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.
-
@scottalanmiller said in wetting my feet with CM software:
Looks pretty easy to do...
http://docs.ansible.com/ansible/intro_adhoc.htmlRight. For example if you need to do a quick update, ad-hoc is the best way. I use ad-hoc commands multiple times daily for a multitude of reasons.
-
@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.
-
@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.
-
@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? 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.
-
@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:
@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.
No, there is no Xen support any longer from Red Hat. XenServer being built on CentOS has nothing to do with weather Red Hat will support it or not.
Ah right, they dropped server side support. They still include the client extensions though.
Ya they still offer guest drivers. I don't think they're dumb enough to try to stop you from running RHEL on whatever you want.
-
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
-
@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?
