Meetup du 31/03/2017, Paris Julien Abbé

1. Validation de code
Code défensif
Paris Puppet DevOps Meetup
30/03/2017

2. Sommaire
• Les Hooks Git
– Emplacement
– Timeline
• Validation de code
– Commande
• Qualité de code
– Linter
• Code défensif
• Aller plus loin…

3. Hooks Git ?
• Description git-scm.com
Git dispose d'un moyen de lancer des scripts personnalisés
quand certaines actions importantes ont lieu.
Il y a deux groupes de crochets : ceux côté client et ceux
côté serveur.
Les crochets côté client concernent les opérations de
client telles que la validation et la fusion.
Les crochets côté serveur concernent les opérations de
serveur Git telles que la réception de commits

4. Différents systèmes,
une même implémentation

5. Timeline des hooks
Client
• prepare-commit-
msg
• commit-msg
• post-commit
GIT PUSH
Serveur
• pre-receive
• update
• post-
receive
Deux groupes de hooks:
côté client
Généralement des opérations de validation
côté serveur
Généralement des triggers

6. Validation de code
Quand valider ?
git
add
git
commit
git
push

7. Que valider en pre-commit ?
.pp -> syntaxe manifest Puppet
.epp -> syntaxe template Puppet epp
.erb -> syntaxe template Puppet erb
.rb -> syntaxe extention Puppet
Fact : présence de confine
.yaml -> structure yaml hieradata
.json -> structure json metadonnées
repo -> arborescences et fichiers cachés
facts.d -> présence du shebang
Puppetfile -> syntaxe Puppetfile

8. Commandes unitaires
Extension Commande
.pp puppet parser validate class.pp
.epp puppet epp validate <fichier>.epp
.erb erb -x -T '-' <fichier>.erb | ruby -c
.rb ruby -c <fichier>.rb
(facts) grep -e
'^s*confines*:kernel.*=>'
<fichier>.rb
.yaml ruby -e "require 'yaml';
YAML.load_file('<fichier>.yaml')"
.json python -mjson.tool <fichier>.json

9. Mais aussi…
Check Commande
repo folders='manifests files lib templates
examples facts.d spec functions types
tests'
for i in $(ls -d */); do
if ! [[ ${folders[*]} =~ ${i%%/} ]]
then
echo "${i%%/} > Folder name error"
error=1
fi
done
facts.d head -n1 <file>| grep -e '^#!/‘

10. Qualité de code
Le code poussé doit être conforme à des
standards de qualité, aux différents style guide.
Exemple de checks en utilisant puppet-lint:
https://github.com/rodjek/puppet-lint
gem install puppet-lint
% puppet-lint init.pp
WARNING: top-scope variable being used without explicit namespace on line 81
ERROR : define defined inside a class on line 59
ERROR: single quoted string containing a variable on line 124
WARNING: string containing only a variable on line 81
WARNING: => on line isn't properly aligned for resource on line 71
ERROR: two-space soft tabs not used on line 50
WARNING: line has more than 80 characters on line 83
ERROR: trailing whitespace found on line 163
ERROR: mode should be represented as a 4 digit value on line 55
ERROR: no default in case statement

11. Linter
Différents linter existent pour valider les fichiers
d’un module.
Généralement sous forme de package Ruby
Cible Install
.pp gem install puppet-lint
metadata.json gem install metadata-json-lint
.json gem install jsonlint
.yaml gem install yaml-lint

12. Code défensif
Ce type de check interdit l’utilisation de certains
type ou resource type Puppet.
Cela permet de forcer l’utilisation d’un wrapper,
défini par une autre équipe en charge de cette
ressource.

13. Code défensif
Exemples:
En situation :
grep -e '^s*users*{.*[:|,]'
<file.pp>
Action Regex
Interdire la ressource user ^s*users*{.*[:|,]
Interdire la ressource group ^s*groups*{.*[:|,]
Interdire la ressource yumrepo ^s*yumrepos*{.*[:|,]

14. Et les control repos ?
Les control repos sont des repos Git permettant de
mapper une branche Git à un environnement
Puppet et son contenu.
Validation de la syntaxe des Puppetfile :
r10k puppetfile check

15. Aller plus loin …
Trigger
Scripts / API
git
add
git
commit
git
push

16. Aller plus loin …
• Fichiers cachés hors standard
• Repo comportant des RPM
• git tag = metadata.json tag
• …
What else ?

17. Questions ?