BillMaier schrieb:
nbkr schrieb:
Puppet ist auch nicht distributionsunabhängig. Die Paket- und Servicenamen sowie Ort und Version von Dateien unterscheiden sich ja, das kann auch puppet nicht ändern. Da baust du dann bei Puppet halt ethliche Fallunterscheidungen. Bei ansible sinds halt unterschiedliche Rollen/Files.
Für mich sah es so aus, als müsse ich bei Ansible auch zwischen den verwendeten Tools unterscheiden. Also yum und apt und wie sie alle heißen.
Ja, muss man. Es gibt aber eine schöne Funktion names "group_by" das erzeugt eine dynamische Gruppe im Inventory das alle Hosts z.B. eines Betriebssystems umfasst. Damit wird dann wieder vergleichsweise einfach. Siehe: http://www.ansibleworks.com/docs/playbooks_best_practices.html#operating-system-and-distribution-variance
Ist auch eher standard, oder? Also Puppet in der Bewerbung sagt wahrscheinlich mehr aus als Ansible(?)
Vor Puppet gab es bzgl. Konfigurationsmanagement nur cfengine. Puppet war das erste Tool was das populär gemacht hat. Inzwischen gibts einen ganzen Zoo von Automatisierungstools. Was mehr als genial ist. Docker, Juju, Fabrik und sogar eine Pythonmodule mit denen man hübsche Sachen machen kann wie paramiko.
Puppet gehört im Vergleich dazu fast schon wieder zum alten Eisen. Es hat auch in meinen Augen einen entscheidenen Nachteil. Puppet nutzt eine deklarative Sprache, das findet man vergleichsweise selten. Alle Programmiersprachen die man als Admin üblicherweise im Einsatz hat (Perl, Python, Bash, PHP ...) sind imperative Sprachen. Das kneift einem dann regelmäßig. So kann man in Puppet z.B. ein Objekt immer nur einmal definieren - was in der Praxis mehr als lästig ist.
Ein Beispiel:
Angenommen du hast ein System auf dem MySQL Datenbank und PHPMyAdmin laufen soll. Du erstellst, neben dem DB Modul, also in Puppet ein PHPMyAdmin Modul. Da das den Apache brauchst fügst du ein
package { 'httpd':
ensure => present,
}
in das PHPMyAdmin Modul ein (die Objekte für den Dienst spare ich mir mal). Soweit so gut.
Kurze Zeit später soll auf die Kiste noch Piwik. Also schreibst du ein Piwik-Modul. Das benötigt auch den Apache. Der Apache ist schon dank phpmyadmin auf dem System. Was jetzt? Wenn du den Apache im Piwikmodul nicht ebenfalls aufnimmst hast, ist das Piwik Modul nicht alleine nutzbar - eine Maschine die nur Piwik installiert hat, müsste auf andere Art und Weise den Apache installiert bekommen. Den Apache kannst du auch nicht ins Piwik Modul aufnehmen, da es kann zu einem Konflikt mit dem PHPMyAdmin Modul kommt.
Die Lösung bei Puppet sieht so aus, dass du jetzt den Apache aus dem PHPMyAdmin Modul entfernst, ein eigenes Modul dafür schreibst und dieses Modul in die Nodedefiniton mit aufnimmst. Am Ende hast du dann für nahezu jedes Softwarepaket ein eigenes Modul, was mehr als lästig ist und die Modul-Idee irgendwie ad absurdum führt.
Im Vergleich dazu ansible:
Du erstellst eine Rolle "phpmyadmin" in den dortigen Tasks steht neben der Installation des von PHPMyAdmin
- name: "Install Apache"
action: yum pkg=httpd state=installed
Im Piwik Modul fügst du das selbe ein. Ansible erkennt bei der Installation von Piwik das der Apache schon drauf ist und installiert ihn nicht nicht nochmal. Problem gelöst.
Bzgl. Bewerbung, kommt halt immer drauf an. Ja, Puppet ist sowas wie der Industriestandard. Ich würde in eine Bewerbung den Punkt "Konfigurationsmanagementtools" aufnehmen und darunter dann ansible schreiben. Ein guter potentieller Chef, sojemand für den man arbeiten will, wird sich die Bewerbung nehmen das lesen und aus Neugierde den Ausdruck "ansible configuration" googlen. Dann stellt er/sie fest dass der Bewerber über den Tellerrand schaut und ihn einstellen.
Aber ich fürchte du hast da schon recht, die meisten Haken einfach nur Stichworte ab.