Archiwa kategorii: puppet

puppet: hash i templates

Wykorzystanie hash-y jest bardzo wygodne, gdyż pozwala utrzymać strukturę danych z informacją o ich wykorzystaniu. Wyobraźmy sobie, że chcemy zarządzać plikiem /etc/exports zarządzającym wyeksportowanymi systemami plików. Niech nasz hash opisujący udostępniane pliki ma postać:

	$fs= 
	{		
		"/export/repos/"  =>
			{
				"10.40.0.20" => 
				{ 
					"server"  => "10.40.0.20",
					"options" => "ro",
				},				
			},
		"/export/ks" =>
			{

				"10.40.0.20" => 
					{ 
						"server"  => "10.40.0.20",
						"options" => "ro",
					},				
			

				"10.40.0.21" => 
					{
						"server" => "10.40.0.21",
						"options" => "rw",
					},
			},

	}	

Wtedy template może wyglądać następująco:

<% @fs.each do |fs_key, fs_machines| %>
<%= fs_key %> <% fs_machines.each do |machine, options| %> <%= machine %>(<%= options['options'] %>) <% end %> 
<% end %>

Puppet i hiera: debugowanie

Hiera czyli hierarchiczna baza danych bardzo często używana jest razem z puppetem. Jak sprawdzić jakie dane ona przekaże do puppeta? Spójrz na przykłady poniżej:

[root@master1 ~]# hiera -d classes environment=lab1
DEBUG: Sat Dec 20 18:59:05 -0500 2014: Hiera YAML backend starting
DEBUG: Sat Dec 20 18:59:05 -0500 2014: Looking up classes in YAML backend
DEBUG: Sat Dec 20 18:59:05 -0500 2014: Looking for data source lab1
DEBUG: Sat Dec 20 18:59:05 -0500 2014: Found classes in lab1
["u4y_base"]

albo przykład bardziej skomplikowany:

[root@master1 node]# hiera -d classes environment=lab1 ::fqdn=master1
DEBUG: Wed Feb 11 19:53:03 +0100 2015: Hiera YAML backend starting
DEBUG: Wed Feb 11 19:53:03 +0100 2015: Looking up classes in YAML backend
DEBUG: Wed Feb 11 19:53:03 +0100 2015: Looking for data source lab1/node/master1
DEBUG: Wed Feb 11 19:53:03 +0100 2015: Found classes in lab1/node/master1
["apache",
 "firewall_trojans_ignore",
 "u4y_dhcpd",
 "u4y_dhcpd::c_dhcp_client_firewall",
 "u4y_dns_server",
 "u4y_firewall",
 "u4y_nfs",
 "u4y_nfs::c_server_firewall",
 "u4y_host",
 "u4y_repo_sync",
 "u4y_host::c_install",
 "u4y_pxelinux",
 "u4y_pxelinux::c_centos",
 "u4y_firewall::c_service",
 "u4y_puppet_server",
 "u4y_kickstart_server",
 "u4y_kickstart_server::c_kickstart_file",
 "u4y_repo_sync::c_centos6",
 "u4y_repo_sync::c_centos7",
 "u4y_tftp_server",
 "u4y_users::c_users",
 "u4y_sshd",
 "u4y_packages::c_packages",
 "u4y_selinux"]

Puppet: dodawanie reguł z plików lokalnych

Nie zawsze musimy korzystać z architektury klient-server. Czasem możemy po prostu wprowadzić reguły zapisane w plikach lokalnych:

[root@vz13505 manifests]# ls -l test_firewall.pp
-rw-r--r-- 1 root root 158 Mar  2 13:18 test_firewall.pp

[root@vz13505 manifests]# puppet apply test_firewall.pp
Warning: Could not retrieve fact fqdn
Notice: /Firewall[000 allow ssh]/ensure: created
Notice: Finished catalog run in 0.46 seconds
[root@vz13505 manifests]# cat test_firewall.pp

## test of firewall module from puppet lab (modul: puppetlabs-firewall)
firewall { '000 allow ssh':
  dport  => 22,
  action => accept,
  proto  => 'tcp',
}

Disaster & Recovery: puppet

Niestety (albo stety, jako że jako admin powinienem mieć to w małym palcu) od czasu do czasu przeinstalowywuje swoje serwery. Jak szybko otworzyć konfiguracje? Plan dla puppet-a.

1. Konifguracja trzymana jest w SVN. Pozwala to kontrolować zmiany w plikach konfiguracyjnych jak również otworzyć konfiguracje z zdalnego serwera SVN.
2. Należy przekonfigurować puppet-a aby brał konfigurację z innych katalogów niż domyślnie. W pliku /etc/puppet/puppet.conf w sekcji main zmieniłem ustawienia:

manifestdir =/etc/puppet/ziutus_puppet@linuxexpert.pl/manifests
manifest=/etc/puppet/ziutus_puppet@linuxexpert.pl/manifests/site.pp
modulepath = /etc/puppet/modules:/usr/share/puppet/modules:/etc/puppet/ziutus_puppet@linuxexpert.pl/modules

3. Plik /etc/puppet/puppet.conf jest twardym linkiem do pliku z repozytorium (łatwiej się odtwarza konfigurację)

Ciekawym opisem jak trzymać konfigurację puppet-a w systemach kontroli wersji znajduje się na stronie:
http://projects.puppetlabs.com/projects/1/wiki/puppet_version_control
Moja uwaga: proponują tam trzymać CAŁĄ konfigurację w systemie kontroli wersji, ja zdecydowałem się na inne rozwiązanie (przeniesienie części konfiguracji do innych katalogów i wskazanie ich w głównym pliku puppet-a) gdyż korzystam także z zewnętrznych modułów, a ich na razie nie chce trzymać w repozytorium. Jak będzie trzeba, po prostu sobie znowu je zainstaluje…

puppet: grupowanie elementów

Miałem mały problem z skracaniem zapisu, zwykłe grupowanie jak poniżej nie działało:

Package["nfs-common"] -> File["/etc/default/nfs-common"] -> Service["statd-mounting"], Service["statd"]

Ale poniższe działa:

Package["nfs-common"] -> File["/etc/default/nfs-common"] -> Service["statd-mounting","statd"]

Puppet: moje uwagi po krótkim zapoznaniu się

Puppet to dobre narzędzie pozwalające skrócić czas reinstalacji systemu a także prowadzania zmian w środowisku, umożliwia też wprowadzanie standaryzacji. Uczę się go od kilku tygodni i powoli dochodzę do pewnych wniosków.
Podstawowym problemem jest dokumentacja a raczej pomoc dla początkujących ;). Prawda jest taka iż podstawowy tutorial pozwala tylko nauczyć się podstaw a rzeczy których się tam uczymy w ogóle nie przydają się w zaawansowanych środowiskach. Powód? Aby zobaczyć jakie zmiany chce puppet wprowadzić do systemu należy zakodować wszystkie nasze elementy to w postaci typów. Proste moduły pozwalają przenosić zmiany ale nie pokazują co zmieniają, po prostu to zmieniają.
Po takiej długim okresie istnienia programu mógłbym spodziewać się większej ilości gotowych modułów dobrej jakości, jak na razie nie jest ich dużo :/

Z pewnością coś tu dopisze…

puppet: synchronizacja modułów

Nie zawsze, nie wszystkie informacje są dostępne w takiej formie jak powinny być. Czasem trzeba dodać nowe fakty, nowe rozwiązania. Jak je przesłać na klienta? Możemy skorzystać z opcji synchronizacji wtyczek (ang. plugin) w sekcji „main”:

pluginsync=true

Efekt:

Jun 25 16:03:52 ziutus puppet-agent[18319]: Starting Puppet client version 2.6.4
Jun 25 16:03:53 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/facter]/ensure) created
Jun 25 16:03:54 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/facter/iptables.rb]/ensure) defined content as '{md5}47bbd812e6fd7a7bdff3435c50b4687d'
Jun 25 16:03:56 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/provider]/ensure) created
Jun 25 16:03:57 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/provider/firewall]/ensure) created
Jun 25 16:03:58 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/provider/firewall.rb]/ensure) defined content as '{md5}f4c747685c2c8ef97fe78732c8153c75'
Jun 25 16:04:01 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/provider/firewall/ip6tables.rb]/ensure) defined content as '{md5}37ccb43da0c5950d33213a1082bde094'
Jun 25 16:04:03 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/provider/firewall/iptables.rb]/ensure) defined content as '{md5}09095f4df985ff6beea50e8db5c36fb7'
Jun 25 16:04:03 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/test]/ensure) removed
Jun 25 16:04:05 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/type/firewall.rb]/ensure) defined content as '{md5}babcbf3938183329b6b78795f8abaf2b'
Jun 25 16:04:05 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/type/iptables.rb]/ensure) removed
Jun 25 16:04:05 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/util]/ensure) created
Jun 25 16:04:07 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/util/firewall.rb]/ensure) defined content as '{md5}0adc814705c4f92a8191ff274801f708'
Jun 25 16:04:08 ziutus puppet-agent[18319]: (/File[/var/lib/puppet/lib/puppet/util/ipcidr.rb]/ensure) defined content as '{md5}225adf61f5de40fa04b4e936e388b801'

puppet: graficzne przedstawienie zależności

Czasem trudno dość, jakie zależności między obiektami / elementami stworzyliśmy dla naszego klienta (ang. node). Rozwiązanie jest proste, na kliencie dodajemy do pliku konfiguracyjnego dyrektywy:

[agent]
graph=true
graphdir=/tmp

Konwersja plików może być dokonana przy pomocy programu dot:

#! /bin/bash

DOT_DIR=/tmp
OUTPUT_DIR=/tmp

dot -Tpng $DOT_DIR/expanded_relationships.dot -o $DOT_DIR/expanded_relationships.png
dot -Tpng $DOT_DIR/relationships.dot -o $DOT_DIR/relationships.png
dot -Tpng $DOT_DIR/resources.dot  -o $DOT_DIR/resources.png

wskazówka: nie musisz tego robić na kliencie, możesz przegrać pliki na serwer centralny i tam skonwertować.

puppet: sprawdzanie co puppet chciałby zrobić

Większość administratorów, wolałaby wiedzieć co puppet chce zrobić zanim pozwoli mu mieszać na serwerach produkcyjnych. Można to w miarę łatwo zobaczyć korzystając z opcji –noop:

root@ziutus:~# puppetd  --test --noop
info: Caching catalog for gateway.linuxexpert.pl
info: Applying configuration version '1340171431'
notice: /Stage[main]//Node[gateway.linuxexpert.pl]/Phpldapadmin::Server[127.0.0.1]/Exec[/usr/local/bin/merge_config_files.sh /etc/phpldapadmin/config_main.php /etc/phpldapadmin/config.d/ /etc/phpldapadmin/config.php]/returns: is notrun, should be 0 (noop)
notice: /Stage[main]/Rsyslog/Service[rsyslog]/enable: is false, should be true (noop)
notice: /Stage[main]/Knockd/Service[knockd]/ensure: is stopped, should be running (noop)
notice: /Stage[main]//Node[gateway.linuxexpert.pl]/Ssh_authorized_key[root_ziutus]/ensure: is present, should be absent (noop)
notice: Finished catalog run in 6.35 seconds