Разгръщане и конфигуриране на PostgreSQL с Puppet

Puppet е софтуер с отворен код за управление и внедряване на конфигурацията. Основан през 2005 г., той е мултиплатформен и дори има собствен декларативен език за конфигуриране.

Задачите, свързани с администрирането и поддръжката на PostgreSQL (или друг софтуер наистина) се състои от ежедневни, повтарящи се процеси, които изискват наблюдение. Това важи дори за тези задачи, управлявани от скриптове или команди чрез инструмент за планиране. Сложността на тези задачи нараства експоненциално, когато се изпълняват в масивна инфраструктура, но използването на Puppet за този вид задачи често може да реши този тип широкомащабни проблеми, тъй като Puppet централизира и автоматизира изпълнението на тези операции по много пъргав начин.

Puppet работи в архитектурата на ниво клиент/сървър, където се извършва конфигурацията; тези операции след това се разпространяват и изпълняват на всички клиенти (известни също като възли).

Обикновено се изпълнява на всеки 30 минути, възелът на агентите ще събира набор от информация (тип процесор, архитектура, IP адрес и т.н.), наричана още факти, след което изпраща информацията до master, който чака отговор, за да види дали има нови конфигурации за прилагане.

Тези факти ще позволят на капитана да персонализира една и съща конфигурация за всеки възел.

По много опростен начин Puppet е един от най-важните инструменти за DevOps налични днес. В този блог ще разгледаме следното...

Случаят на употреба за Puppet &PostgreSQL
Инсталиране на Puppet
Конфигуриране и програмиране на кукла
Конфигуриране на Puppet за PostgreSQL

Инсталацията и настройката на Puppet (версия 5.3.10), описани по-долу, бяха извършени в набор от хостове, използващи CentOS 7.0 като операционна система.

Случаят на употреба за Puppet &PostgreSQL

Да предположим, че има проблем във вашата защитна стена на машините, които хостват всичките ви PostgreSQL сървъри, тогава ще е необходимо да откажете всички изходящи връзки към PostgreSQL и да го направите възможно най-скоро.

Куклата е идеалният инструмент за тази ситуация, особено защото скоростта и ефективността са съществено. Ще говорим за този пример, представен в раздела „Конфигуриране на Puppet за PostgreSQL“, като управляваме параметъра listen_addresses.

Инсталиране на Puppet

Има набор от често срещани стъпки, които да се изпълняват на главни или агентни хостове:

Първа стъпка

Актуализиране на /etc/hosts файл с имена на хостове и техния IP адрес

192.168.1.85 agent agent.severalnines.com

192.168.1.87 master master.severalnines.com puppet

Стъпка втора

Добавяне на хранилища Puppet в системата

$ sudo rpm –Uvh https://yum.puppetlabs.com/puppet5/el/7/x86_64/puppet5-release-5.0.0-1-el7.noarch.rpm

За други операционни системи или версии на CentOS, най-подходящото хранилище може да се намери в Puppet, Inc. Yum Repositories.

Трета стъпка

Конфигуриране на NTP (Network Time Protocol) сървър

$ sudo yum -y install chrony

Стъпка четвърта

Chrony се използва за синхронизиране на системния часовник от различни NTP сървъри и по този начин поддържа времето синхронизирано между главния и агент сървъра.

След като инсталирате chrony, той трябва да бъде активиран и рестартиран:

$ sudo systemctl enable chronyd.service

$ sudo systemctl restart chronyd.service

Стъпка пета

Деактивирайте параметъра SELinux

Във файла /etc/sysconfig/selinux параметърът SELINUX (Linux с подобрена сигурност) трябва да бъде деактивиран, за да не ограничава достъпа и на двата хоста.

SELINUX=disabled

Стъпка шеста

Преди инсталирането на Puppet (магистър или агент) защитната стена в тези хостове трябва да бъде съответно дефинирана:

$ sudo firewall-cmd -–add-service=ntp -–permanent 

$ sudo firewall-cmd –-reload

Инсталиране на Puppet Master

След като хранилището на пакети puppet5-release-5.0.0-1-el7.noarch.rpm се добави към системата, инсталацията на puppetserver може да бъде извършена:

$ sudo yum install -y puppetserver

Параметърът за максимално разпределение на паметта е важна настройка за актуализиране на файла /etc/sysconfig/puppetserver до 2GB (или до 1GB, ако услугата не се стартира):

JAVA_ARGS="-Xms2g –Xmx2g "

В конфигурационния файл /etc/puppetlabs/puppet/puppet.conf е необходимо да добавите следната параметризация:

[master]

dns_alt_names=master.severalnines.com,puppet



[main]

certname = master.severalnines.com

server = master.severalnines.com

environment = production

runinterval = 1h

Услугата puppetserver използва порт 8140, за да слуша заявките за възел, поради което е необходимо да се гарантира, че този порт ще бъде активиран:

$ sudo firewall-cmd --add-port=8140/tcp --permanent

$ sudo firewall-cmd --reload

След като всички настройки са направени в puppet master, е време да стартирате тази услуга:

$ sudo systemctl start puppetserver

$ sudo systemctl enable puppetserver

Инсталиране на Puppet Agent

Агентът Puppet в хранилището на пакетите puppet5-release-5.0.0-1-el7.noarch.rpm също е добавен към системата, инсталирането на puppet-agent може да се извърши веднага:

$ sudo yum install -y puppet-agent

Конфигурационният файл на puppet-agent /etc/puppetlabs/puppet/puppet.conf също трябва да бъде актуализиран чрез добавяне на следния параметър:

[main]

certname = agent.severalnines.com

server = master.severalnines.com

environment = production

runinterval = 1h

Следващата стъпка се състои в регистриране на възела на агента на главния хост чрез изпълнение на следната команда:

$ sudo /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable=true

service { ‘puppet’:

ensure => ‘running’,

enable => ‘true’

  }

В този момент на главния хост има чакаща заявка от марионетния агент за подписване на сертификат:

Това трябва да бъде подписано чрез изпълнение на една от следните команди:

$ sudo /opt/puppetlabs/bin/puppet cert sign agent.severalnines.com

или

$ sudo /opt/puppetlabs/bin/puppet cert sign --all

Накрая (и след като капитана на puppet е подписал сертификата) е време да приложите конфигурациите към агента, като извлечете каталога от капитана на puppet:

$ sudo /opt/puppetlabs/bin/puppet agent --test

В тази команда параметърът --test не означава тест, настройките, извлечени от главния, ще бъдат приложени към локалния агент. За да тествате/проверите конфигурациите от master, трябва да се изпълни следната команда:

$ sudo /opt/puppetlabs/bin/puppet agent --noop

Конфигуриране и програмиране на кукла

Puppet използва декларативен подход за програмиране, при който целта е да посочи какво да прави и няма значение как да го постигне!

Най-елементарната част от кода на Puppet е ресурсът, който определя системно свойство като команда, услуга, файл, директория, потребител или пакет.

По-долу е представен синтаксисът на ресурс за създаване на потребител:

user { 'admin_postgresql':

  ensure     => present,

  uid        => '1000',

  gid        => '1000',

  home       => '/home/admin/postresql'

}

Различни ресурси могат да бъдат присъединени към предишния клас (известен също като манифест) на файл с разширение „pp“ (това означава Puppet Program), въпреки това няколко манифеста и данни (като факти, файлове и шаблони) ще състави модул. Всички логически йерархии и правила са представени на диаграмата по-долу:

Целта на всеки модул е да съдържа всички необходими манифести за изпълнение на единични задачи по модулен начин. От друга страна, концепцията за клас не е същата от обектно-ориентирани езици за програмиране, в Puppet тя работи като агрегатор на ресурси.

Организацията на тези файлове има специфична структура на директории, която да следва:

На която целта на всяка папка е следната:

Папка	Описание
манифести	Код на кукла
файлове	Статични файлове за копиране на възли
шаблони	Шаблонни файлове за копиране в управлявани възли (може да се персонализира с променливи)
примери	Манифест, който показва как да използвате модула

Класовете (манифестите) могат да се използват от други класове, както е показано в примера по-долу:манифестът init.pp на dev_accounts използва групите на манифест от модула акаунти.

class dev_accounts {

  $rootgroup = $osfamily ? {

    'Debian'  => 'sudo',

    'RedHat'  => 'wheel',

    default   => warning('This distribution is not supported by the Accounts module'),

  }



  include accounts::groups



  user { 'username':

    ensure      => present,

    home        => '/home/admin/postresql',

    shell       => '/bin/bash',

    managehome  => true,

    gid         => 'admin_db',

    groups      => "$rootgroup",

    password    => '$1$7URTNNqb$65ca6wPFDvixURc/MMg7O1'

  }

}

В следващия раздел ще ви покажем как да генерирате съдържанието на папката с примери, както и командите за тестване и публикуване на всеки модул.

Конфигуриране на Puppet за PostgreSQL

Преди да представим няколко примера за конфигурация за разгръщане и поддържане на PostgreSQL база данни, е необходимо да инсталирате PostgreSQL puppet модула (на хоста на сървъра), за да използвате всичките им функционалности:

$ sudo /opt/puppetlabs/bin/puppet module install puppetlabs-postgresql

В момента хиляди модули, готови за използване в Puppet, са налични в публичното хранилище на модули Puppet Forge.

Първа стъпка

Конфигуриране и внедряване на нов екземпляр на PostgreSQL. Ето цялото необходимо програмиране и конфигурация за инсталиране на нов екземпляр на PostgreSQL във всички възли.

Първата стъпка е да създадете нова директория със структура на модула, както е споделено по-рано:

$ cd /etc/puppetlabs/code/environments/production/modules

$ mkdir db_postgresql_admin

$ cd db_postgresql_admin; mkdir{examples,files,manifests,templates}

След това във файла manifests/init.pp трябва да включите класа postgresql::server, предоставен от инсталирания модул:

class db_postgresql_admin{

  include postgresql::server

}

За да проверите синтаксиса на манифеста, добра практика е да изпълните следната команда:

$ sudo /opt/puppetlabs/bin/puppet parser validate init.pp

Ако нищо не се върне, това означава, че синтаксисът е правилен

За да ви покажем как да използвате този модул в папката с примери, е необходимо да създадете нов файл на манифест init.pp със следното съдържание:

include db_postgresql_admin

Примерното местоположение в модула трябва да бъде тествано и приложено към главния каталог:

$ sudo /opt/puppetlabs/bin/puppet apply --modulepath=/etc/puppetlabs/code/environments/production/modules --noop init.pp

Накрая е необходимо да дефинирате до кой модул всеки възел има достъп във файла “/etc/puppetlabs/code/environments/production/manifests/site.pp” :

node ’agent.severalnines.com’,’agent2.severalnines.com’{

 include db_postgresql_admin

}

Или конфигурация по подразбиране за всички възли:

node default {

 include db_postgresql_admin

}

Обикновено на всеки 30 минути възлите проверяват главния каталог, въпреки това тази заявка може да бъде принудена от страната на възела чрез следната команда:

$ /opt/puppetlabs/bin/puppet agent -t

Или ако целта е да се симулират разликите между основната конфигурация и текущите настройки на възел, може да се използва параметърът nopp (без операция):

$ /opt/puppetlabs/bin/puppet agent -t --noop

Втора стъпка

Актуализирайте екземпляра на PostgreSQL, за да слушате всички интерфейси. Предишната инсталация дефинира настройка на екземпляра в много ограничителен режим:позволява връзки само на локален хост, както може да бъде потвърдено от хостовете, асоциирани за порт 5432 (дефиниран за PostgreSQL):

$ sudo netstat -ntlp|grep 5432

tcp        0 0 127.0.0.1:5432          0.0.0.0:* LISTEN   3237/postgres       

tcp6       0 0 ::1:5432                :::* LISTEN   3237/postgres

За да позволите слушане на целия интерфейс, е необходимо да имате следното съдържание във файла /etc/puppetlabs/code/environments/production/modules/db_postgresql_admin/manifests/init.pp

class db_postgresql_admin{

  class{‘postgresql:server’:

        listen_addresses=>’*’ #listening all interfaces

       }

}

В примера по-горе има деклариран клас postgresql::server и настройка на параметъра listen_addresses на „*“, което означава всички интерфейси.

Сега портът 5432 е свързан с всички интерфейси, той може да бъде потвърден със следния IP адрес/порт:“0.0.0.0:5432”

$ sudo netstat -ntlp|grep 5432

tcp        0 0 0.0.0.0:5432            0.0.0.0:* LISTEN   1232/postgres       

tcp6       0 0 :::5432                 :::* LISTEN   1232/postgres

За да върнете първоначалната настройка:позволете връзки към база данни само от localhost, параметърът listen_addresses трябва да бъде зададен на „localhost“ или да посочи списък с хостове, ако желаете:

listen_addresses = 'agent2.severalnines.com,agent3.severalnines.com,localhost'

За да извлечете новата конфигурация от главния хост, е необходимо само да я заявите на възела:

$ /opt/puppetlabs/bin/puppet agent -t

Трета стъпка

Създайте PostgreSQL база данни. Инстанцията на PostgreSQL може да бъде създадена с нова база данни, както и с нов потребител (с парола), за да използва тази база данни и правило за файла pg_hab.conf, за да позволи връзката към базата данни за този нов потребител:

class db_postgresql_admin{

  class{‘postgresql:server’:

        listen_addresses=>’*’ #listening all interfaces

  }



   postgresql::server::db{‘nines_blog_db’:

     user => ‘severalnines’,          password=> postgresql_password(‘severalnines’,’passwd12’)

   }



   postgresql::server::pg_hba_rule{‘Authentication for severalnines’:

     Description =>’Open access to severalnines’,

     type => ‘local’,

database => ‘nines_blog_db’,

     user => ‘severalnines’,

address => ‘127.0.0.1/32’

         auth_method => ‘md5’

   }

}

Този последен ресурс има името „Удостоверяване за няколко деветки“ и файлът pg_hba.conf ще има още едно допълнително правило:

# Rule Name: Authentication for severalnines

# Description: Open access for severalnines

# Order: 150

local   nines_blog_db   severalnines 127.0.0.1/32    md5

За да извлечете новата конфигурация от главния хост, всичко, което е необходимо, е да я заявите на възела:

$ /opt/puppetlabs/bin/puppet agent -t

Четвърта стъпка

Създайте потребител само за четене. За да създадете нов потребител с привилегии само за четене, към предишния манифест трябва да се добавят следните ресурси:

postgresql::server::role{‘Creation of a new role nines_reader’:

createdb   => false,

createrole => false,

superuser => false,     password_hash=> postgresql_password(‘nines_reader’,’passwd13’)

}

postgresql::server::pg_hba_rule{‘Authentication for nines_reader’:

     description =>’Open access to nines_reader’,

     type => ‘host’,

database => ‘nines_blog_db’,

     user => ‘nines_reader’,

address => ‘192.168.1.10/32’,

         auth_method => ‘md5’

   }

За да извлечете новата конфигурация от главния хост, всичко, което е необходимо, е да я заявите на възела:

$ /opt/puppetlabs/bin/puppet agent -t

Заключение

В тази публикация в блога ви показахме основните стъпки за внедряване и започване на конфигуриране на вашата PostgreSQL база данни чрез автоматичен и персонализиран начин на няколко възли (които дори могат да бъдат виртуални машини).

Тези видове автоматизация могат да ви помогнат да станете по-ефективни, отколкото да го правите ръчно, а конфигурацията на PostgreSQL може лесно да се извърши с помощта на няколко от класовете, налични в хранилището на puppetforge