Archiwum kategorii: Zarządzanie farmami i klastrami

Chef – instalacja klienta i dodanie go przez użycie knife

Instalacja klienta jest prosta: wykonujemy jeden skrypt, który ściągnie i zainstaluje wszystko:

[root@server1 ~]# curl -L https://www.opscode.com/chef/install.sh | sudo bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 19602  100 19602    0     0  16096      0  0:00:01  0:00:01 --:--:-- 16106
el 6 i686
Getting information for chef stable  for el...
downloading https://omnitruck-direct.chef.io/stable/chef/metadata?v=&p=el&pv=6&m=i686
  to file /tmp/install.sh.1537/metadata.txt
trying wget...
sha1    d85315adde9ff0889358ea96341a1e38aabe4e36
sha256  db1dd569f3f99f56d2446b30f5f75b2bf6b7d786f93e6b3be60b14c297639acc
url     https://packages.chef.io/stable/el/6/chef-12.11.18-1.el6.i386.rpm
version 12.11.18
downloaded metadata file looks valid...
downloading https://packages.chef.io/stable/el/6/chef-12.11.18-1.el6.i386.rpm
  to file /tmp/install.sh.1537/chef-12.11.18-1.el6.i386.rpm
trying wget...
Comparing checksum with sha256sum...

WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING

You are installing an omnibus package without a version pin.  If you are installing
on production servers via an automated process this is DANGEROUS and you will
be upgraded without warning on new releases, even to new major releases.
Letting the version float is only appropriate in desktop, test, development or
CI/CD environments.

WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING

Installing chef
installing with rpm...
ostrzeżenie: /tmp/install.sh.1537/chef-12.11.18-1.el6.i386.rpm: Nagłówek V4 DSA/SHA1 Signature, identyfikator klucza 83ef826a: NOKEY
Przygotowywanie…                    ################################# [100%]
Aktualizowanie/instalowanie…
   1:chef-12.11.18-1.el6              ################################# [100%]
Thank you for installing Chef!

Gdy mamy skonfigurowany knife, dodanie kolejnego klienta nie stanowi problemu:

[root@server1 ~]# knife bootstrap server1.localnet -N sevrrver1
Creating new client for server1
Creating new node for server1
Connecting to server1.localnet
root@server1.localnet's password: 
server1.localnet -----> Existing Chef installation detected
server1.localnet Starting the first Chef Client run...
server1.localnet Starting Chef Client, version 12.11.18
server1.localnet resolving cookbooks for run list: []
server1.localnet Synchronizing Cookbooks:
server1.localnet Installing Cookbook Gems:
server1.localnet Compiling Cookbooks...
server1.localnet [2016-06-10T21:20:44+02:00] WARN: Node server1 has an empty run list.
server1.localnet Converging 0 resources
server1.localnet 
server1.localnet Running handlers:
server1.localnet Running handlers complete
server1.localnet Chef Client finished, 0/0 resources updated in 08 seconds

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