Pages

Rechercher dans ce blog

lundi 9 septembre 2013

Intégration GitLab | Chef 11 (OSC)





Si vous avez utilisé chef, vous vous rendez bien vite compte qu'il faut un répertoire "maître" de travail, à jour et bien rangé.

Afin que tout le monde dispose de ce même dossier à jour, il convient de le stocker sur un "gestionnaire de version". Opscode nous propose Github, mais celui-ci reste payant si l'on veut des "repository" privés. La solution ?  --> GitLab.

Nous allons donc installer intégrer GitLab 6 à Chef 11 (OSC). Nous allons utiliser le moteur de BDD de Chef (PostgreSQL) et son serveur web (Nginx), tous les deux compatibles (moyennant bidouilles..) avec GitLab !!

                                     
   


Je considère que chef-server est déjà installé et configuré sur la machine.

GitLab 6 sur scientific linux 6.3 (globalement EL6)



Gitlab est une application de gestion de dépôts git sous licence MIT. 
Elle permet d'héberger sur votre propre serveur des dépôts git avec l'interface web offrant tout le nécessaire pour vos projets : navigation dans le code source, suivi des demandes de bugs et d'évolutions (« issues »), wiki, gestion des droits d'accès par équipe, commentaires, notifications, etc.

On le décris souvent (à tort) comme un fork "open-source" de GitHub.

Je vais vous présenter 2 façons de l' installer, la première avec Bitnami (installation "1 clic" ) et la seconde sera un script d'installation.

jeudi 22 août 2013

Mise à jour Gitlab 5.4 -> 6.0

Si vous le saviez pas encore, Gitlab publie des mises à jour chaque 22 du mois.
Les mises à jour de la même branche sont mineures, mais ce mois-ci, une mise à jour majeure est mise en place.

L'un des grands changements est l'utilisation de Unicorn à la place de Puma.
D'autres améliorations également sur le management des équipes .

La procédure pour mettre à jour la version 5.4 vers la 6.0 se trouve sur le site internet :

https://github.com/gitlabhq/gitlabhq/blob/master/doc/update/5.4-to-6.0.md

Je mettrais prochainement en ligne, un nouveau script d'installation pour scientific linux 6.  -- Finalement fait !


Je vous invite à aller voir du coté de Bitnami qui permet d'installer "en 1 clic" dans un répertoire choisi une installation "compléte" (stack). Vous aurez tout les outils/programmes (apache, ruby..) dans un seul répertoire.

Ils m'ont l'air assez à jour : une version de Gitlab 6 est déjà disponible (dès le jour même).

mercredi 21 août 2013

Chef OSC Installation failover



Chef est un outil de management de configuration écris en Ruby et Erlang.

Il permet de maintenir/configurer des serveurs ou des postes de travail grâce à des "recettes" (recipes) stockées dans des « manuels de cuisine » (cookbooks) qui sont stockés par le composant bookshelf sur le serveur chef.

Les recettes sont écrites en ruby ou DSL(domain specific language).
Pour faciliter les modifications et restaurations, ces recettes sont "versionnées". Une première fois sur la machine workstation (git) , une seconde fois sur le serveur (bookshelf) et une troisième fois avec gitlab (git).

Chef est basé sur une idée maître : Vous pouvez modéliser votre infrastructure informatique ainsi que vos applications comme du code. L' infrastructure devient alors testable, versionnée et reproductible comme du code.

Voici l’architecture globale :








On distingue les principaux composants suivants :


  • bookshelf: composant qui versionne les recettes stockées sur le serveur 
  • chef-expander: formate les messages des queues RabbitMQ 
  • chef-server-webui: Application Ruby qui héberge l'interface web de chef-server chef-solr: Indexer 
  • erchef: API chef (chef en Erlang) 
  • nginx: Serveur web 
  • postgresql: base de données 

Installation des serveurs en mode failover :

chef-server.rpm est installé mais pas configuré
Configuration du fichier hosts: 
Vérifiez les noms de vos serveurs
hostname

Configurez également /etc/hosts
Mise à jour RabbitMQ : 
Nous allons maintenant mettre à jour la version de rabbitMQ utilisée par la version 3.1.4 (à partir de la branche 3, la gestion des clusters est largement améliorée)

Téléchargement :

cd /tmp/
wget http://www.rabbitmq.com/releases/rabbitmq-server/v3.1.4/rabbitmq-server-generic-unix-3.1.4.tar.gz
tar xvfz rabbitmq-server-generic-unix-3.1.4.tar.gz
 
Puis on supprime l'ancienne version :

rm -rf /opt/chef-server/embedded/service/rabbitmq/

on recréé le dossier :

mkdir -p /opt/chef-server/embedded/service/rabbitmq/

on copie la nouvelle version :

cp -rf /tmp/rabbitmq_server-3.1.4/* /opt/chef-server/embedded/service/rabbitmq/

Puis on va copier notre fichier de configuration de rabbitMQ.
On n'utilisera plus la recette fournie par Opscode pour "gérer" rabbitMQ .
copier ceci dans : /opt/chef-server/embedded/service/rabbitmq/etc/rabbitmq/rabbitmq-env.conf

#!/bin/sh
##   The contents of this file are subject to the Mozilla Public License
##   Version 1.1 (the "License"); you may not use this file except in
##   compliance with the License. You may obtain a copy of the License at
##   http://www.mozilla.org/MPL/
##
##   Software distributed under the License is distributed on an "AS IS"
##   basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
##   License for the specific language governing rights and limitations
##   under the License.
##
##   The Original Code is RabbitMQ.
##
##   The Initial Developers of the Original Code are LShift Ltd,
##   Cohesive Financial Technologies LLC, and Rabbit Technologies Ltd.
##
##   Portions created before 22-Nov-2008 00:00:00 GMT by LShift Ltd,
##   Cohesive Financial Technologies LLC, or Rabbit Technologies Ltd
##   are Copyright (C) 2007-2008 LShift Ltd, Cohesive Financial
##   Technologies LLC, and Rabbit Technologies Ltd.
##
##   Portions created by LShift Ltd are Copyright (C) 2007-2010 LShift
##   Ltd. Portions created by Cohesive Financial Technologies LLC are
##   Copyright (C) 2007-2010 Cohesive Financial Technologies
##   LLC. Portions created by Rabbit Technologies Ltd are Copyright
##   (C) 2007-2010 Rabbit Technologies Ltd.
##
##   All Rights Reserved.
##
##   Contributor(s): __.
##

HOME="/var/opt/chef-server/rabbitmq"
RABBITMQ_MNESIA_BASE="/var/opt/chef-server/rabbitmq/db"
RABBITMQ_LOG_BASE="/var/log/chef-server/rabbitmq"
RABBITMQ_NODE_IP_ADDRESS="X.X.X.1"
RABBITMQ_NODE_PORT="5672"
RABBITMQ_NODENAME="rabbit@chef1-a"

Créer ensuite le fichier de configuration de rabbitmq :

nano  /opt/chef-server/embedded/service/rabbitmq/etc/rabbitmq/rabbitmq.config

et rajouter l'option qui limite la mémoire utilisée :

[{rabbit, [{disk_free_limit, 1000000000}]}].

On modifie ensuite, les paramètres par défaut de rabbitmq :

nano /opt/chef-server/embedded/service/rabbitmq/sbin/rabbitmq-defaults

on change :

SYS_PREFIX=/opt/chef-server/embedded/service/rabbitmq/

on commente :
#LOG_BASE=${SYS_PREFIX}/var/log/rabbitmq
#MNESIA_BASE=${SYS_PREFIX}/var/lib/rabbitmq/mnesia
Puis on peut le lancer (une première fois en mode "normal"..):

export PATH=$PATH:/opt/chef-server/embedded/bin/:/opt/chef-server/embedded/service/rabbitmq/sbin/
rabbitmq-server
et si tout se passe bien :
(Starting broker... completed with 0 plugins.)

on le coupe (Ctrl+c).

Nous allons maintenant ajouter quelques plugins qui vont nous permettre de surveiller les queues rabbitMQ par une interface web:

rabbitmq-plugins list
va nous lister les plugins disponibles. Nous allons activer rabbitmq_management et mochiweb.

rabbitmq-plugins enable mochiweb
rabbitmq-plugins enable rabbitmq_management
Puis relancer le service :

rabbitmq-server
Cette fois-ci le message suivant apparaît :

Starting broker... completed with 6 plugins.

On l'éteint et on le lance en mode "daemon" :

rabbitmq-server -detached
Aller sur http://chef1-a:15672/ pour vérifier son fonctionnement.
Par défaut un compte guest//guest est créé.
Changement des recettes :
On va éditer les recettes afin qu'un des serveurs soit "maître" : on se place dans la recette :

cd /opt/chef-server/embedded/cookbooks/chef-server/
nano attributes/default.rb
###
# High level options
###
default['chef_server']['api_version'] = "11.0.2"
default['chef_server']['flavor'] = "osc" # Open Source Chef

default['chef_server']['notification_email'] = "test@company.com"
default['chef_server']['bootstrap']['enable'] = true


# RabbitMQ\\

default['chef_server']['rabbitmq']['node_ip_address'] = 'X.X.X.1'
default['chef_server']['rabbitmq']['node_port'] = '5672'
default['chef_server']['rabbitmq']['nodename'] = 'rabbit@chef1-a'
default['chef_server']['rabbitmq']['vip'] = 'X.X.X.1'


# Chef Solr
\\default['chef_server']['chef-solr']['ip_address'] = 'X.X.X.1'
default['chef_server']['chef-solr']['vip'] = 'X.X.X.1'


# Bookshelf
\\default['chef_server']['bookshelf']['vip'] = node['fqdn']
default['chef_server']['bookshelf']['url'] = "https://#{node['fqdn']}"
default['chef_server']['bookshelf']['listen'] = "X.X.X.1"


# Erlang Chef Server API
\\default['chef_server']['erchef']['vip'] = 'X.X.X.1'
default['chef_server']['erchef']['listen'] = 'X.X.X.1'


# Chef Server WebUI
\\default['chef_server']['chef-server-webui']['listen'] = 'X.X.X.1'
default['chef_server']['chef-server-webui']['vip'] = 'X.X.X.1'

###
# Estatsd
###
default['chef_server']['estatsd']['vip'] = "X.X.X.1"

###
# Load Balancer
###
default['chef_server']['lb']['vip'] = "X.X.X.1"
default['chef_server']['lb']['upstream']['erchef'] = [ "X.X.X.1" ]
default['chef_server']['lb']['upstream']['chef-server-webui'] = [ "X.X.X.1" ]
default['chef_server']['lb']['upstream']['bookshelf'] = [ "X.X.X.1" ]

###
# PostgreSQL
###
default['chef_server']['postgresql']['vip'] = "X.X.X.1"
default['chef_server']['postgresql']['listen_address'] = '*'
nano recipes/default.rb

commenter la partie rabbitMQ :

# Configure Services
[
#"rabbitmq",
&"postgresql",

Rajouter les droits "opscode" à sa configuration :

nano templates/default/pg_hba.conf.erb
host replication opscode-pgsql X.X.X.2/24 trust
host all opscode_chef X.X.X.2/24 trust

Créer le fichier de restauration pour Postgre :
nano templates/default/recovery.conf.erb

et copier ce contenu :
# ---
# PostgreSQL recovery config file
# ---
#
# Edit this file to provide the parameters that PostgreSQL needs to
# perform an archive recovery of a database, or to act as a replication
# standby.
#
# If "recovery.conf" is present in the PostgreSQL data directory, it is
# read on postmaster startup.  After successful recovery, it is renamed
# to "recovery.done" to ensure that we do not accidentally re-enter
# archive recovery or standby mode.
#
# This file consists of lines of the form:
#
#   name = value
#
# Comments are introduced with '#'.
#
# The complete list of option names and allowed values can be found
# in the PostgreSQL documentation.
#
#---
# ARCHIVE RECOVERY PARAMETERS
#---
#
# restore_command
#
# specifies the shell command that is executed to copy log files
# back from archival storage.  The command string may contain %f,
# which is replaced by the name of the desired log file, and %p,
# which is replaced by the absolute path to copy the log file to.
#
# This parameter is *required* for an archive recovery, but optional
# for streaming replication.
#
# It is important that the command return nonzero exit status on failure.
# The command *will* be asked for log files that are not present in the
# archive; it must return nonzero when so asked.
#
# NOTE that the basename of %p will be different from %f; do not
# expect them to be interchangeable.
#
restore_command = 'cp /var/pg_xlog/%f "%p"'           # e.g. 'cp /mnt/server/archivedir/%f %p'
#
#
# archive_cleanup_command
#
# specifies an optional shell command to execute at every restartpoint.
# This can be useful for cleaning up the archive of a standby server.
#
#archive_cleanup_command = ''
#
# recovery_end_command
#
# specifies an optional shell command to execute at completion of recovery.
# This can be useful for cleaning up after the restore_command.
#
#recovery_end_command = ''
#
#---
# RECOVERY TARGET PARAMETERS
#---
#
# By default, recovery will rollforward to the end of the WAL log.
# If you want to stop rollforward at a specific point, you
# must set a recovery target.
#
# You may set a recovery target either by transactionId, by name,
# or by timestamp. Recovery may either include or exclude the
# transaction(s) with the recovery target value (ie, stop either
# just after or just before the given target, respectively).
#
#
#recovery_target_name = ''      # e.g. 'daily backup 2011-01-26'
#
#recovery_target_time = ''      # e.g. '2004-07-14 22:39:00 EST'
#
#recovery_target_xid = ''
#
#recovery_target_inclusive = true
#
#
# If you want to recover into a timeline other than the "main line" shown in
# pg_control, specify the timeline number here, or write 'latest' to get
# the latest branch for which there's a history file.
#
recovery_target_timeline = 'latest'
#
#
# If pause_at_recovery_target is enabled, recovery will pause when
# the recovery target is reached. The pause state will continue until
# pg_xlog_replay_resume() is called. This setting has no effect if
# hot standby is not enabled, or if no recovery target is set.
#
#pause_at_recovery_target = true
#
#---
# STANDBY SERVER PARAMETERS
#---
#
# standby_mode
#
# When standby_mode is enabled, the PostgreSQL server will work as a
# standby. It will continuously wait for the additional XLOG records, using
# restore_command and/or primary_conninfo.
#
standby_mode = on
#
# primary_conninfo
#
# If set, the PostgreSQL server will try to connect to the primary using this
# connection string and receive XLOG records continuously.
#
primary_conninfo = 'host=X.X.X.1 port=5432'          # e.g. 'host=localhost port=5432'
#
#
# By default, a standby server keeps restoring XLOG records from the
# primary indefinitely. If you want to stop the standby mode, finish recovery
# and open the system in read/write mode, specify path to a trigger file.
# The server will poll the trigger file path periodically and start as a
# primary server when it's found.
#
trigger_file = '/var/pg_failover'
#
#---
# HOT STANDBY PARAMETERS
#---
#
# Hot Standby related parameters are listed in postgresql.conf
#
#---

Editer :
nano recipes/postgresql.rb

et rajouter ceci :
#recovery = File.join(postgresql_data_dir, "recovery.conf")
#template recovery do
#  source "recovery.conf.erb"
#  owner node['chef_server']['postgresql']['username']
#  mode "0644"
#  notifies :restart, 'service[postgresql]' if OmnibusHelper.should_notify?("postgresql")
#end

 Editer :

nano templates/default/postgresql.conf.erb

et modifier suivant :

#--
# WRITE AHEAD LOG
#--

# - Settings -

wal_level = hot_standby    # minimal, archive, or hot_standby
          # (change requires restart)
fsync = on      # turns forced synchronization on or off
synchronous_commit = on    # synchronization level; on, off, or local
wal_sync_method = fsync    # the default is the first option
          # supported by the operating system:
          #   open_datasync
          #   fdatasync (default on Linux)
          #   fsync
          #   fsync_writethrough
          #   open_sync
#full_page_writes = on      # recover from partial page writes
#wal_buffers = -1     # min 32kB, -1 sets based on shared_buffers
          # (change requires restart)
#wal_writer_delay = 200ms   # 1-10000 milliseconds

#commit_delay = 0     # range 0-100000, in microseconds
#commit_siblings = 5      # range 1-1000

# - Archiving -

archive_mode = on   # allows archiving to be done
        # (change requires restart)
archive_command = 'cp %p /var/pg_xlog/%f'   # command to use to archive a logfile segment
#archive_timeout = 0    # force a logfile segment switch after this
        # number of seconds; 0 disables
#--
# REPLICATION
#--

# - Master Server -

# These settings are ignored on a standby server

max_wal_senders = 1   # max number of walsender processes
        # (change requires restart)
#wal_sender_delay = 1s    # walsender cycle time, 1-10000 milliseconds
wal_keep_segments = 50    # in logfile segments, 16MB each; 0 disables
#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
#replication_timeout = 60s  # in milliseconds; 0 disables
#synchronous_standby_names = '' # standby servers that provide sync rep
        # comma-separated list of application_name
        # from standby(s); '*' = all

# - Standby Servers -

# These settings are ignored on a master server

hot_standby = on    # "on" allows queries during recovery
          # (change requires restart)
#max_standby_archive_delay = 30s  # max delay before canceling queries
          # when reading WAL from archive;
          # -1 allows indefinite delay
#max_standby_streaming_delay = 30s  # max delay before canceling queries
          # when reading streaming WAL;
          # -1 allows indefinite delay
#wal_receiver_status_interval = 10s # send replies at least this often
          # 0 disables
#hot_standby_feedback = off   # send info from standby to prevent
          # query conflicts

Synchronisation SOLR:
nano templates/default/solrconfig.xml.erb

Modifier :

 
    true
    startup
    commit
    optimize
    schema.xml,stopwords.txt


   false
   http://X.X.X.1:8983/solr/replication
   00:00:10



Configuration du maître :
chef-server-ctl reconfigure

Il va s’arrêter à ce moment :

execute[boostrap-chef-server] action run

Mais c'est normal, afin d'obtenir le hash du mot de passe de rabbitMQ qu'on avait pas encore configuré. On copie donc ce hash :

nano /etc/chef-server/chef-server-secrets.json

dans la section :

"rabbitmq": {

     "password": XXXXXXXXXXXXXX

On va créer l'utilisateur chef, lui mettre ses droits..

rabbitmqctl add_vhost /chef
rabbitmqctl add_user chef COPIER ICI LE HASH
rabbitmqctl set_permissions -p /chef chef ".*" ".*" ".*"

et on relance la configuration de chef :

chef-server-ctl reconfigure
Pour s'assurer du bon fonctionnement on lance un test :

chef-server-ctl test 
on compresse tout ça pour l' envoyer sur l'esclave (ça nous évite de devoir se retaper toutes les pass-phrases, les certificats..)

tar cvfP /tmp/master.tar /opt/chef-server/embedded/ /etc/chef-server/admin.pem /etc/chef-server/chef-server-secrets.json /etc/chef-server/chef-webui.pem /etc/chef-server/chef-validator.pem

backup bdd :
su - opscode-pgsql
psql -d opscode_chef -c "SELECT pg_start_backup('replbackup');"
tar cfP /tmp/db_file_backup.tar /var/opt/chef-server/postgresql/data
psql -d opscode_chef -c "SELECT pg_stop_backup();"
exit

on copie tout ca sur l'esclave :

cd /tmp/
scp master.tar db_file_backup.tar chef1-b:/tmp/

Configuration esclave :
on installe le rpm, on supprime le dossier rabbitMQ et on écrase avec nos tar
rpm -Uvh chef-server-11.0.8.rpm
rm -rf /opt/chef-server/embedded/service/rabbitmq/
cd /tmp/
tar xvfP master.tar
tar xvfP db_file_backup.tar

on supprime le pid de postgresql du maître
rm -rf /var/opt/chef-server/postgresql/data/postmaster.pid

puis on modifie nos recettes :
cd /opt/chef-server/embedded/cookbooks/chef-server/

on décommente la partie "recovery" {{code}}nano recipes/postgresql.rb
nano attributes/default.rb

On change les addresses IP et le nom du serveur rabbitMQ
Ne pas changer la partie :

default['chef_server']['postgresql']['vip'] = "X.X.X.1"

Editer :
nano templates/default/solrconfig.xml.erb

Inverser les valeurs "true / false"

 
    true
    startup
    commit
    optimize
    schema.xml,stopwords.txt


   false
   http://X.X.X.1:8983/solr/replication
   00:00:10



Puis on lance la configuration de chef :
chef-server-ctl reconfigure

Il va s'arreter à
execute[boostrap-chef-server] action run

Continuons :

Mise en place du cluster rabbitMQ : 

Editer le fichier:
tail /var/opt/chef-server/rabbitmq/.erlang.cookie

puis
chown root:root /var/opt/chef-server/rabbitmq/.erlang.cookie && chmod 600 /var/opt/chef-server/rabbitmq/.erlang.cookie

on modifie la configuration (ip et nom) :
nano /opt/chef-server/embedded/service/rabbitmq/etc/rabbitmq/rabbitmq-env.conf
HOME="/var/opt/chef-server/rabbitmq"
RABBITMQ_MNESIA_BASE="/var/opt/chef-server/rabbitmq/db"
RABBITMQ_LOG_BASE="/var/log/chef-server/rabbitmq"
RABBITMQ_NODE_IP_ADDRESS="X.X.X.2"
RABBITMQ_NODE_PORT="5672"
RABBITMQ_NODENAME="rabbit@chef1-b"

on mets à jour notre environnement :
export PATH=$PATH:/opt/chef-server/embedded/bin/:/opt/chef-server/embedded/service/rabbitmq/sbin/

On vérifie que les plugins sont activés: Désactiver :
rabbitmq-plugins list

sinon :
rabbitmq-plugins enable mochiweb rabbitmq_management

On le lance une première fois :
rabbitmq-server

Si tout fonctionne :
rabbitmq-server -detached

On peut vérifier l'interface web : http://chef1-b:15672/

Puis on "clusterise" depuis l'esclave :
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@chef1-a
rabbitmqctl start_app

pour verifier :
rabbitmqctl cluster_status

On peut relancer la configuration de chef :
chef-server-ctl reconfigure

Synchronisation du bookshelf : 
On télécharge lsyncd
wget https://lsyncd.googlecode.com/files/lsyncd-2.1.5.tar.gz

On l'installe (besoin de lua, lua-devel , gcc, gcc++)
./configure
make
make install

On créé un fichier de configuration :
cd /etc/
nano lsyncd.conf

 on y mets :
settings{
logfile = "/tmp/lsyncd.log",
statusFile = "/tmp/lsyncd.status",
nodaemon = false,
maxDelays = 30,
maxProcesses = 6,
}

sync{
default.rsyncssh,
source="/var/opt/chef-server/bookshelf/data/",
host="chef1-b",
targetdir="/var/opt/chef-server/bookshelf/data/"}
sync{
default.rsyncssh,
source="/var/pg_xlog/",
host="chef1-b",
targetdir="/var/pg_xlog/"}
et on le lance avec :
lsyncd /etc/lsyncd.conf

* On peut vérifier dans les logs que tout fonctionne :
tail /tmp/lsyncd.log

* la vérification de la synchronisation de l'index Solr se fait par chef-server-ctl (par défaut toutes les 10 secs )

* les logs de verification de la réplication de postgre (sur esclave) :
tail /var/log/chef-server/postgresql/current

* Page d'informations sur les cluster rabbitMQ:
http://chef1-a:15672/#/

* Page d'information sur PostgreSQL :

http://chef1-a:8080/phpPgAdmin/

* Page de status de chef-server :

https://chef1-a/_status/

Afin de valider les tests d'opscode, l'ordre de démarrage des serveurs est important , démarrer dans un premier temps le serveur A, puis le serveur B. (Ainsi les consumers de rabbit seront sur le serveur A)

Lancer les tests :
chef-server-ctl test
  • sur le maitre : 
Finished in 47.71 seconds 70 examples, 0 failures
  • sur l'esclave : 
Finished in 45.68 seconds 70 examples, 10 failures

Des tests plus complets peuvent être lancés avec la commande :

chef-server-ctl test all
FAILOVER

Je ne vais pas expliquer le basculement IP, seulement le basculement esclave -> maitre / maitre -> esclave .
 Sur chef1-a (maître):
 -couper l'instance de chef
chef-server-ctl stop

-couper lsyncd (synchronisation bookshelf et Wal postgres)

-basculement IP
 Le reste des commandes se fait sur l'esclave.

Configuration : 
BDD :  
On précise à chef1-b de se servir de sa base de donnée.
nano /var/opt/chef-server/erchef/etc/app.config
 %% The only database supported is Postgres
 {db_type, pgsql},
 %% Database connection parameters
 {db_host, "X.X.X.2"},
 {db_port, 5432},
 {db_user, "opscode_chef"},
SOLR :
On inverse les valeurs maître/esclave et l'adresse du maître

 
    true
    startup
    commit
    optimize
    schema.xml,stopwords.txt


   false
   http://X.X.X.1:8983/solr/replication
   00:00:10



nano /var/opt/chef-server/chef-solr/home/conf/solrconfig.xml

PostgreSQL : 
Il y a 2 méthodes :

* le trigger file

Créer le trigger file "pg_failover" dans /var/

cd /var
touch pg_failover
Le fichier /var/opt/chef-server/postgresql/data/recovery.conf devient recovery.done.

* commande promote

Passer sur l'utilisateur opscode-pgsql et lancer la commande

su - opscode-pgsql
pg_ctl promote -D /var/opt/chef-server/postgresql/data/ promote
exit
RabbitMQ :

Le cluster doit rester présent , il suffit de vérifier avec

rabbitmqctl cluster_status
sinon :

rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@chef1-b
rabbitmqctl start_app
Redemarrage :
chef-server-ctl restart
Reprise en mode "normal" : 
Afin de rebasculer les serveurs dans leur rôle d'origine, le plus simple est de faire une backup totale de la base de donnée et de remettre les configurations d'origine.

On éteint l'instance de chef sur l'esclave (pas sur le maître)
chef-server-ctl stop

backup bdd :
su - opscode-pgsql
psql -d opscode_chef -c "SELECT pg_start_backup('replbackup');"
tar cfP /tmp/db_file_backup.tar /var/opt/chef-server/postgresql/data
psql -d opscode_chef -c "SELECT pg_stop_backup();"
exit 
on copie tout ca sur le maître :

cd /tmp/
scp db_file_backup.tar chef1-a:/tmp/
Puis on peut éteindre l'instance de chef sur le maître.

Configuration :
 Sur le maître (chef1-b):
  • recovery.done -> recovery.conf (et suppression du trigger file):

cd /var/opt/chef-server/postgresql/data/
mv recovery.done recovery.conf
rm /var/pg_failover
  • Solr On inverse les valeurs maître/esclave et l'adresse du maître

nano /var/opt/chef-server/chef-solr/home/conf/solrconfig.xml


  • Configuration erchef

nano /var/opt/chef-server/erchef/etc/app.config
 %% The only database supported is Postgres
 {db_type, pgsql},
 %% Database connection parameters
 {db_host, "X.X.X.1"},
 {db_port, 5432},
 {db_user, "opscode_chef"}, 
  • Lsyncd 
On coupe l'instance lsyncd :

ps aux | grep lsyncd 
et retenir le numéro du PID

 kill - 9 "numéro PID"
Sur l'esclave (chef1-a) :

  • On supprime la base de donnée en cours :
 rm -rf /var/opt/chef-server/postgresql/data/ 
On extrait la base de donnée récupérée précédemment : 

 tar xvfP /tmp/db_failover.tar 
On supprime le fichier recovery.done et postmaster.pid 

rm /var/opt/chef-server/postgresql/data/recovery.done /var/opt/chef-server/postgresql/data/postmaster.pid

  • Solr
On inverse les valeurs maître/esclave et l'adresse du maître
nano /var/opt/chef-server/chef-solr/home/conf/solrconfig.xml 
  •   Configuration erchef
nano /var/opt/chef-server/erchef/etc/app.config
 %% The only database supported is Postgres
 {db_type, pgsql},
 %% Database connection parameters
 {db_host, "X.X.X.1"},
 {db_port, 5432},
 {db_user, "opscode_chef"}, 
Sur les 2 serveurs :

  • supprimer les fichiers wal dans le dossier /var/pg_xlog
rm -f  /var/pg_xlog/* 
Relance lsyncd (chef1-a):
 lsyncd /etc/lsyncd.conf 
Relance Chef : Lancer l'instance en premier sur chef1-a, puis sur chef1-b.

Fork me on GitHub