La configuration en pratique

Comment configurer ...

... 1 serveur ?

... 100 serveurs ?

... 10000 serveurs ?

;-)

Solutions

Plusieurs stratégies peuvent être adoptées :

À la mimine

• Documentations, wiki, tableurs -> SSH
• Temps de déploiement, de maintien et de mise à jour exponentiel avec le nombre d'instances

Via des scripts

• Connexion en SSH, récupération du script et exécution
• Scripts versionnés et bichonnés

Le gestionnaire de configuration

Aujourd'hui Photobox se situe entre la solution 1 et 2 grâce a son système PXE à base de scripts et à ses documentations disponibles

Convergences et divergences

Concepts de convergence et de divergence dans les configurations d'un parc

La convergence en pratique

• Chaque action unitaire réalisée sur un serveur doit systématiquement être reportée sur ses voisins pour maintenir la cohérence et l'homogénéité du parc
• L'inventaire et les différents contextes des serveurs et des applications doivent être disponibles et accessibles simplement par les opérateurs
• La génération d'une configuration doit être au maximum procédurale et deterministe selon un schéma précis
• Sans l'application de contraintes régulières sur les configurations, l'architecture ne peut que diverger

Ne pas accumuler de dette technique

• Les serveurs suivent les mêmes règles de configuration, mais évoluent dans des contextes propres : selon le dimentionnement, le rôle, la localisation ...
• La mise à jour d'une option, d'une règle, ou d'un nouveau composant sur l'ensemble de son parc n'est plus un risque ou une opération lourde
• On ne modifie plus directement les instances, mais uniquement les règles qui les régissent
• Simplification des tests et des déploiements, réduction du temps de validation : fonctionnel pour 1, donc pour 1000 !

Objectif

On ne touche plus aux serveurs :on en fait la description et ils s'autogèrent !

Un nouveau paradigme

• Passer de la réalisation d'une action à sa simple description
• Le fix "quick & dirty" devient l'exception et doit faire l'objet d'une mise à jour upstream
• L'architecture est "drivée" par le code, validée, sauvegardée, consolidée, versionnée, publique et partagée (modèle IaC)
• Un modèle peut être testé instantanément et mis en production suivant des cycles courts
• Tout le monde peut collaborer et proposer ses innovations
• Plus besoin de réinventer la roue dans la majorité des cas

Des changements à prévoir !

Une conduite de changement sur les méthodes et les pratiques est donc à mener sur le long terme, car cette transition majeure ne peut être imposée aux équipes

Des outils facilitant l'utilisation et promouvant la gestion de configuration devront être mis à disposition et illustrés. La migration ne peut être au final que progressive et plébicitée

Et concrètement ?

Prenons l'exemple sur l'une des dernières modification réalisée sur les scripts d'installation actuels :

########################
#---- Setup SWAP   ----#
########################
if [ `free -tm | grep "Mem:" | awk {'print $2'}` -lt 16000 ]
then
        dd if=/dev/zero of=/data/irenderer.swap bs=1024M count=8
        sync
        mkswap /data/irenderer.swap
        chmod -v 600 /data/irenderer.swap
        if [ `grep -i irenderer.swap /etc/fstab -c` -eq 0 ]
        then
                echo "# Swap File Irenderer" >> /etc/fstab
                echo "/data/irenderer.swap swap swap defaults 0 0" >> /etc/fstab
        fi
fi

Et concrètement ?

La mise en place via un gestionnaire de configuration permet d'abstraire le côté système et ne s'interesser qu'à la description :

#------metadata-------#
depends          'swap'


#------attributes------#
default['iprod']['core']['memlimit'] = 16777216  #kB



#------description-----#
swap_file '/data/irenderer.swap' do
  size      8192    # MBs
  persist
  only_if { node['memory']['total'].to_i < node['iprod']['core']['memlimit'] }
end

Plus d'écriture dans fstab, plus besoin de dd/fallocate, plus de swapon ... C'est le script "swap_file" qui manage l'ensemble, gère tous les cas de figures et maintient à jour le fichier swap !

Simple comme un bloc !

La majeure partie des besoins peuvent se décrire au sein de blocs descriptifs courts et compréhensibles :

directory "/data/" do
  not_if { Dir.exists?("/data") }
  owner "root"
  group "root"
  mode 0755
  action :create
end

user_account 'root' do
  manage_home false
  ssh_keys node['ssh']['root']['authorized_keys'] + node['ssh']['root']['local_keys']
  action :modify
end

template "/etc/perl/CPAN/Config.pm" do
  source "Config.pm.erb"
  mode 0644
  owner "root"
  group "root"
end

node['iprod']['core']['packages'].each do |iprod|
  package iprod
end

Et pour les power-users ?

Si les primitives natives ou les jeux de scripts de la communauté ne sont pas suffisants pour écrire la description attendue, il faudra développer (ou améliorer) le comportement souhaité au travers d'un language de scripting spécifique.

Ces développements pourront, s'ils concernent des briques standard, être libérés pour profiter de l'expertise et de l'experience de la communauté.

Cas d'école : déployer un NRPE Nagios ...

# diff photobox.cfg nrpe-deployer-sart.cfg 
20d19
< command[check_disk3]=/usr/lib/nagios/plugins/check_disk $ARG1$

But de l'opération : déployer une nouvelle règle sur les serveurs

• SSH sur chacune des instances ? (quelles instances ?)
• Rundeck qui lance une commande patch ? (mais peut être certains serveurs utilisent nrpe.d/ et d'autre pas ?)
• SCP de masse ?
• On met tout dans /data et on fait des symlinks dans le système pour ne plus se préoccuper de la localisation du fichier ?
• On corrige les différents deployer de machines (AU, SART ...) ?
• Ou bien ... on met en place un gestionnaire de configuration ?

Cas d'école ... bis

include_recipe 'nagios::client'

template '/etc/nagios/nrpe.d/photobox.cfg' do
  source 'photobox.cfg.erb'
  mode 0644
  owner 'root'
  group 'root'
end