Centraal server beheer via SaltStack

Ik ben met SaltStack aan het testen voor centraal beheer van Linux servers en is vrij makkelijk in gebruik. Veel voorkomende handelingen zijn bijv OS updates.

Ipv telkens met SSH inloggen op iedere server en yum update/apt-upgrade uit te voeren, kun je via commando salt '*' pkg.upgrade alle servers in 1x updaten. Wil je servers rebooten, dan voer je salt '*' system.reboot uit.

Gebruikt iemand van jullie ook SaltStack of andere tools (puppet, ansible etc)?

Wij gebruiken Ansible voor zo een beetje alles, installeren van services tot het beheren van DNS zones en meer. Je kan er tegenwoordig ook network devices mee beheren, uitstekende tool.

Voor updates gebruiken we Ansible met eigen Python modules. O.a. om te controleren of er problemen zijn vóór we updates doen -- en niet alle software staat in een package manager.

Ansible gebruiken we eigenlijk voor alle grootschalige acties die meerdere servers raakt en waar we direct feedback willen. Voor 'zorg dat service X draait en config Y moet altijd Z zijn' gebruiken we Puppet.

Oorspronkelijk geplaatst door xaban

Wij gebruiken Ansible voor zo een beetje alles, installeren van services tot het beheren van DNS zones en meer. Je kan er tegenwoordig ook network devices mee beheren, uitstekende tool.

Ik ga ook eens kijken naar Ansible. Deze werkt werkt ook zo'n beetje als omschreven hierboven, gewoon ansible agent deployen op een server, master toewijzen en gaan met die banaan zoals saltstack?

Als ik Ansible zo bekijk, zet de Ansible master een connectie op via SSH naar de slave. Op de slave moet poort 22 dus openstaan? Bij saltstack hoeft geen poort open te worden gezet omdat de agent (salt-minion) een outbound connectie opzet via eigen poort naar de master.

Oorspronkelijk geplaatst door mgielissen

Ik ga ook eens kijken naar Ansible. Deze werkt werkt ook zo'n beetje als omschreven hierboven, gewoon ansible agent deployen op een server, master toewijzen en gaan met die banaan zoals saltstack?

Ansible werkt agent-less. Enige wat je nodig hebt is SSH toegang tot de servers waar je acties op uit wilt voeren.

Oorspronkelijk geplaatst door xaban

Ansible werkt agent-less. Enige wat je nodig hebt is SSH toegang tot de servers waar je acties op uit wilt voeren.

Ik heb Ansible al aan het werken, op de slave moet je een SSH Ansible useraccount aanmaken. Van het client-server idee van saltstack ben ik meer gecharmeerd.

Wij gebruiken ook echt overal Ansible voor. De playbooks in Yaml zijn ideaal en voor iedereen te begrijpen. Als je Redhat gebruikt zitten er ook nog eens heel veel standaard functies in Ansible

ik volg even deze thread, zeer geinteresseerd

Ansible werkt goed icm playbooks. Heeft wel een aantal voordelen tov Salt.

Oorspronkelijk geplaatst door mgielissen

Ansible werkt goed icm playbooks. Heeft wel een aantal voordelen tov Salt.

Kijk ook eens naar puppet, dat doet wat jij wilt heeft een agent en haalt de configuratie binnen. Echter de combinatie van Ansible en Puppet is machtig.

Ansible is bedoelt om doormiddel van ssh taken uit te voeren of meerdere taken die in een playbook staan.
(update van de server yum update of snel een configuratie uitrollen op alle servers (host toevoegen aan de /etc/hosts op alle servers)

Puppet is bedoelt om vooringetelde waardes te check op de server of die nog zo ingesteld staan zoals bedoelt. (zoals of nginx draait, configuratie bestand zoals in ingesteld.)

Dit is natuurlijk even heel kort door de bocht wat je er mee kan doen, en als je het goed doet kunnen ze alle bij het zelfde maar de een is makkelijker in gebruik dan de andere in bepaalde taken uit te voeren. Belangrijkste is dus Puppet draait op de client en je hebt een Puppet server nodig en haalt de configuratie op, ansible draait op je eigen machine of controle server en pushed de configuratie naar de clients.

Links of rechtsom je moet in je firewall of poort 22 (ansible) openzetten of poort 8140 (puppet).

Voor beheer tools om Ansible en puppet te beheren check https://www.ansible.com/products/tower en https://www.theforeman.org/

Nog wat interessante Ansible tools:
- https://github.com/ansible/awx - in plaats van Ansible Tower.
- https://github.com/openstack/ara - voor reporting.

En voor Puppet heb je tegenwoordig ook Puppet Bolt, wat eigenlijk het antwoord op Ansible is:
- https://puppet.com/products/puppet-bolt

Links of rechtsom je moet in je firewall of poort 22 (ansible) openzetten of poort 8140 (puppet).

Niet helemaal. Want het is niet hetzelfde. De ene is inkomend en de andere uitgaand. Lijkt een klein detail maar het is een groot verschil.

Een database server heeft bijvoorbeeld meestal geen publiek adres. Dat betekent bij Ansible dat je `ssh_args` en een eigen ssh config file moet configureren om via een jump server verder te komen. Bij Puppet heb je alleen uitgaand 8140 nodig wat de configuratie iets simpeler maakt.

Oorspronkelijk geplaatst door ju5t

Een database server heeft bijvoorbeeld meestal geen publiek adres. Dat betekent bij Ansible dat je `ssh_args` en een eigen ssh config file moet configureren om via een jump server verder te komen. Bij Puppet heb je alleen uitgaand 8140 nodig wat de configuratie iets simpeler maakt.

Dat is waar, echter zou je op een manier de machine in moeten kunnen, dit kan doormiddel van een jumphost en als je via een jumphost er bij kan kan je er ook bij met ssh / ansible.

Doormiddel van je ssh config kan je automatisch via een jumphost connecten en is het alsof je direct connectie heb met de database server

Zeer interessant..ik volg dit ook even..