W poprzednim blogu pokazaliśmy, jak skonfigurować naszą maszynę za pomocą Puppet, a następnie zainstalować i skonfigurować MongoDB. Ponieważ mamy zamiar skonfigurować wiele węzłów, a raczej maszyn, potrzebujemy mistrza marionetek. Jednak w naszym przypadku utworzymy repozytorium git, w którym przekażemy nasze manifesty i zastosujemy je na naszych komputerach.
Aby utworzyć lokalne repozytorium git, najpierw wybierz ścieżkę, której chcesz użyć, tj. /opt/. Następnie utwórz repozytorium git, uruchamiając repozytorium $sudo mkdir. Uzyskaj uprawnienia użytkownika root do zmiany zawartości tego katalogu, wydając polecenie $sudo chown vagrant:vagrant repozytorium. Aby zainicjować ten katalog jako repozytorium git po wydaniu polecenia $ cd repozytorium, uruchom $ git init --bare --shared jeśli przejdziesz do tego katalogu, powinieneś teraz zobaczyć coś takiego jak
[email protected]:/vagrant/repository$ ls -l
total 12
-rw-rw-r-- 1 vagrant vagrant 23 Jul 15 07:46 HEAD
drwxr-xr-x 1 vagrant vagrant 64 Jul 15 07:46 branches
-rw-rw-r-- 1 vagrant vagrant 145 Jul 15 07:46 config
-rw-rw-r-- 1 vagrant vagrant 73 Jul 15 07:46 description
drwxr-xr-x 1 vagrant vagrant 352 Jul 15 07:46 hooks
drwxr-xr-x 1 vagrant vagrant 96 Jul 15 07:46 info
drwxr-xr-x 1 vagrant vagrant 128 Jul 15 07:46 objects
drwxr-xr-x 1 vagrant vagrant 128 Jul 15 07:46 refs
-rw-r--r-- 1 vagrant vagrant 0 Jul 1 15:58 test.ppTo jest podstawowa struktura repozytorium git, a opcje --bare i --share umożliwią nam wypychanie i ściąganie plików z katalogu.
Musimy skonfigurować system, który umożliwi komunikację między zaangażowanymi maszynami a tym zdalnym serwerem głównym. System w tym przypadku będzie określany jako demon. Demon będzie akceptował żądania od zdalnych hostów dotyczące ściągania lub wypychania plików do tego repozytorium. Aby to zrobić, wydaj polecenie $git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack
Dobrą praktyką będzie jednak utworzenie pliku, z którego będziemy mogli uruchomić to w tle. Dlatego musimy ustawić usługę, wydając polecenie sudo vim /etc/systemd/system/gitd. usługa. W nowym pliku wypełnij go tą zawartością
[Unit]
Description=Git Repo Server Daemon
[Service]
ExecStart=/usr/bin/git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack
[Install]
WantedBy=getty.target
DefaultInstance=ttylZapisz plik i wyjdź, naciskając
[email protected]:/opt/repository$ systemctl start gitd
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'gitd.service'.
Authenticating as: vagrant,,, (vagrant)
Password:
==== AUTHENTICATION COMPLETE ===
To check if the service is running $ ps -ef | grep git and you will get:
[email protected]:/opt/repository$ ps -ef | grep git
root 1726 1 0 07:48 ? 00:00:00 /usr/bin/git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack
root 1728 1726 0 07:48 ? 00:00:00 git-daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack
vagrant 1731 1700 0 07:48 pts/0 00:00:00 grep --color=auto gitTeraz, jeśli uruchomimy $ git clone git://198.168.1.100/repository (pamiętaj, aby zmienić adres IP na adres IP sieci twojego komputera) w katalogu głównym, otrzymasz nowo utworzony folder repozytorium . Pamiętaj, aby skonfigurować swoje dane uwierzytelniające poprzez odkomentowanie adresu e-mail i hasła w pliku konfiguracyjnym. Uruchom $ git config --global --edit, aby uzyskać dostęp do tego pliku.
To repozytorium będzie działać jako nasz centralny serwer dla wszystkich manifestów i zmiennych.
Konfigurowanie środowiska
Teraz musimy skonfigurować środowisko, z którego będziemy konfigurować węzły. Najpierw przejdź do katalogu włóczęgi i sklonuj repozytorium, które właśnie utworzyliśmy za pomocą tego samego polecenia, co powyżej.
Usuń katalog manifestu z folderu włóczęgi, uruchamiając $rm -r manifest/.
Utwórz nowy folder produkcyjny za pomocą $ mkdir production i sklonuj to samo repozytorium, które utworzyliśmy powyżej, za pomocą $ git clone git://198.168.1.100/repository . (nie zapomnij o kropki na końcu)
Skopiuj i wklej zawartość środowiska produkcyjnego puppetlabs do tego folderu produkcyjnego, wydając polecenie cp -pr /etc/puppetlabs/code/environments/production/* . Twój katalog produkcyjny powinien teraz wyglądać tak
[email protected]:/vagrant/production$ ls -l
total 8
drwxr-xr-x 1 vagrant vagrant 64 Apr 26 18:50 data
-rw-r--r-- 1 vagrant vagrant 865 Apr 26 18:50 environment.conf
-rw-r--r-- 1 vagrant vagrant 518 Apr 26 18:50 hiera.yaml
drwxr-xr-x 1 vagrant vagrant 96 Jul 2 10:45 manifests
drwxr-xr-x 1 vagrant vagrant 64 Apr 26 18:50 modules
-rw-r--r-- 1 vagrant vagrant 0 Jul 1 16:13 test.ppMusimy przekazać te zmiany do głównego repozytorium, więc uruchamiamy
$ git add * && git commit -m "adding production default files" && git pushAby sprawdzić, czy konfiguracja git działa, możemy usunąć zawartość katalogu /etc/puppetlabs/code/environments/production/, uruchamiając $ sudo rm -r * w tym katalogu, a następnie pull pliki z repozytorium głównego jako użytkownik root, tj. $ git clone git://198.168.1.100/repository . (nie zapomnij o kropki na końcu). W tym przypadku ściągane są tylko katalogi z zawartością, więc możesz pominąć foldery manifestów i modułów. Operacje te można wykonywać na wszystkich zaangażowanych maszynach, zarówno na maszynie głównej marionetkowej, jak i maszynie klienckiej. Naszym zadaniem będzie więc ściąganie zmian z głównego serwera i stosowanie zmian za pomocą manifestów.
Manifest wykonania
To jest skrypt, który napiszemy, aby pomóc nam pobrać zmiany i automatycznie zastosować je do naszych innych węzłów. Nie tylko musisz korzystać ze środowiska produkcyjnego, ale możesz dodać jak najwięcej środowisk, a następnie dyktować marionetkę, z której chcesz wyszukiwać. W katalogu głównym production/manifests utworzymy manifest wykonania jako puppet_exec.pp i wypełnimy go następującą zawartością
file { "This script will be pulling and applying the puppet manifests":
path => '/usr/local/bin/exec-puppet',
content => 'cd /etc/puppetlabs/code/environments/production/ && git pull; /opt/puppetlabs/bin/puppet apply manifests/'
mode => "0755"
}
cron {'exec-puppet':
command => '/usr/local/bin/exec-puppet',
hour => '*',
minute => '*/15'
}Plik to zasób, który został opisany do wykonywania manifestów marionetkowych. Dodaj odpowiednią ścieżkę do tworzonego przez nas pliku i wypełnij ją poleceniami, które mają zostać wydane, gdy zostanie wykonany.
Polecenia wykonywane są systematycznie, tzn. najpierw przechodzimy do środowiska produkcyjnego, ściągamy zmiany z repozytorium, a następnie stosujemy je na maszynie.
Dostarczamy katalog manifestów do każdego węzła, z którego może wybrać skierowany do niego manifest do zastosowania.
Ustawiany jest również czas, przez który plik wykonawczy ma być uruchamiany. W takim przypadku co godzinę uruchom plik 4 razy.
Aby zastosować to na naszej obecnej maszynie, $ cd /vagrant/production. Dodaj wszystko do git, uruchamiając $ git add *, a następnie $ git commit -m „add the cron configurations” i na końcu $ git push. Teraz przejdź do $ cd /etc/puppetlabs/code/environments/production/ i $ sudo git pull
Teraz, jeśli sprawdzimy folder manifestów w tym katalogu, powinieneś zobaczyć plik puppet_exec.pp utworzony tak, jak właśnie zdefiniowaliśmy.
Teraz jeśli uruchomimy $ sudo puppet zastosuj manifesty/ i sprawdź, czy pliki exec-puppet zostały utworzone $ cat /usr/local/bin/exec-puppet
Zawartość tego pliku powinna być
cd /etc/puppetlabs/code/environments/production/ && git pull; /opt/puppetlabs/bin/puppet apply manifests/W tym momencie widzieliśmy, jak możemy pobierać i wpychać zmiany do naszego głównego komputera, które powinny być zastosowane do wszystkich innych węzłów. Jeśli uruchomimy $ sudo crontab -l, niektóre ważne ostrzeżenia zostaną podświetlone w utworzonym pliku exec-puppet.
# HEADER: This file was autogenerated at 2019-07-02 11:50:56 +0000 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: exec-puppet
*/15 * * * * /usr/local/bin/exec-puppetKonfiguracja maszyn
Powiedzmy, że nasz włóczęga wygląda tak
Vagrant.configure("2") do |config|
config.vm.define "puppet" do |puppet|
puppet.vm.box = "bento/ubuntu-16.04"
#puppet.vm.hostname = "puppet"
#puppet.vm.network "private_network", ip: "192.168.1.10"
end
config.vm.define "db" do |db|
db.vm.box = "bento/ubuntu-16.04"
end
endW tym przypadku mamy maszynę marionetkową, na której robiliśmy nasze konfiguracje, a następnie maszynę db. Teraz musimy zautomatyzować maszynę tak, aby za każdym razem, gdy maszyna db jest uruchamiana, ma już zainstalowaną marionetkę i już dostępny plik cron, aby pobrać manifesty i odpowiednio je zastosować. Będziesz musiał zmienić strukturę zawartości maszyny db w następujący sposób
config.vm.define "db" do |db|
db.vm.box = "bento/ubuntu-16.04"
vm.provision "shell", inline: <<-SHELL
cd /temp
wget https://apt.puppetlabs.com/puppet5-release-xenial.deb
dpkg -i puppet5-release-xenial.deb
apt-get update
apt-get install -y puppet-agent
apt-get install -y git
rm -rf /etc/puppetlabs/code/environments/production/*
cd /etc/puppetlabs/code/environments/production/
git clone git://198.168.1.100/repository .
/opt/puppetlabs/bin/puppet apply /etc/puppetlabs/code/environments/production/manifests/puppet_exec.pp
SHELL
EndDo tego momentu struktura katalogu marionetek powinna wyglądać mniej więcej tak
Jeżeli teraz uruchomisz maszynę db poleceniem $ vagrant up db, część zasobów zostanie zainstalowana i skrypt, który właśnie zdefiniowaliśmy, można znaleźć w katalogu production/manifests. Jednak zaleca się używanie mistrza marionetek, który jest ograniczony tylko do 10 węzłów w wersji darmowej, w przeciwnym razie będziesz musiał subskrybować plan. Mistrz marionetek oferuje więcej funkcji i dystrybucję manifestów do wielu węzłów, raportowanie dzienników i większą kontrolę nad węzłami.
Moduł lalek Mongodb
Ten moduł jest używany do instalacji MongoDB, zarządzania instalacją serwera mongod, konfiguracji demona mongod i zarządzania konfiguracją Ops Managera oprócz demona MongoDB-mms.
Wniosek
W następnym blogu pokażemy, jak wdrożyć zestaw replik MongoDB i fragmenty za pomocą Puppet.
