Category Archives: Foreman

Faites tourner vos foreman-proxy avec passenger

Posté par le 07/03/2013 No comments

J’ai récemment décidé de remplacer le démon Webrick utilisé habituellement par Foreman-Proxy
par Apache 2.4 et Passenger pour des question principalement d’industrialisation.
Comme nous allons le voir le setup est assez simple.
Je pars du principe que vous avez déjà installé apache et passenger (pour Foreman, Puppetmasterd, etc ..).

Mon installation de smart-proxy étant par Git, celui-ci est localisé dans /opt, je vous laisse adapter vos chemins !
La configuration d’apache est la suivante :

Listen 8444
<VirtualHost *:8444>
  ServerName foreman-proxy.example.com
  ServerAlias proxy1.example.com

  DocumentRoot /opt/smart-proxy/public

  RailsAutoDetect On
  PassengerTempDir /opt/smart-proxy/tmp
  AddDefaultCharset UTF-8
  HostnameLookups On

  SSLEngine on
  SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/proxy1.example.com.pem
  SSLCertificateFile /var/lib/puppet/ssl/certs/proxy1.example.com.pem
  SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem

  <Directory /opt/smart-proxy/public>
     Require local
     Require ip 192.168.0.0/16 10.0.0.0/8
  </Directory>

  CustomLog ${APACHE_LOG_DIR}/foreman-proxy.example.com/access.log combined
  ErrorLog ${APACHE_LOG_DIR}/foreman-proxy.example.com/error.log
</VirtualHost>

J’ai choisi de ne pas faire écouter passenger sur le même port que le démon webrick, mais vous pouvez très bien utiliser le 8443.
On remarque que la configuration SSL ne se fait plus au niveau de la configuration du proxy mais directement dans apache.

Au niveau du proxy, il est important de savoir que pour le moment, la directive « :trusted_hosts » provoque une erreur 500.
Le bug à été remonté ici : http://projects.theforeman.org/issues/2259

Voila, il vous reste à arrêter votre daemon smart-proxy et relancer apache et c’est tout bon !
Attention, si vous avez changé de port d’écoute, penser à mettre à jour votre configuration au niveau de Foreman.

Share

Générer avec Puppet des certificat SSL avec des « Alternative Name »

Posté par le 06/03/2013 No comments

J’avais besoins de cette fonctionnalité pour mettre en place la communication SSL entre mes deux serveurs Foreman et ses proxies.
Mon problème étant que mes serveurs Foreman sont utilisé en faillover (avec une VIP) avec un DNS généric et non pas en utilisant leur FQDN.
Ceci provoquait un problème avec le certificat puppet utilisé car l’adresse ne correspondait pas au CN exposé.
J’ai donc mis en place un certificat puppet dont le CN est le FQDN (ex:foreman1.example.com) de la machine et qui comprend en plus comme
‘Subject Alternative Name’ le nom du faillover utilisé (ex:foreman.example.com).

C’est très simple à réaliser mais l’info est pas très documentée sur le net.
Il faut commencer par révoquer et supprimer tous les certificats existants pour cette machine :
Sur le client (sur Debian) :

# rm -rf /var/lib/puppet/ssl

Sur le puppet master : 

# puppet cert clean foreman1.example.com

Modifier le puppet.conf du client et lui ajouter la directive :

dns_alt_names = foreman.example.com

Puis lancer puppet sur le client pour forcer la création du nouveau certificat et envoyer la demande de signature au master :

# puppet agent -t --report --pluginsync

Sur le master vous pouvez voir une nouvelle demande de certificat et vous pouvez le signer :

# puppet cert list
  "foreman1.example.com" (SHA256) 2C:76:5B:85:67:28:1C:92:48:AA:10:22:44:C7:9B:A7:0D:9B:E2:A5:5F:10:71:87:B9:3F:46:E4:70:4B:43:6C (alt names: "DNS:foreman.example.com", "DNS:foreman1.example.com")
# puppet cert sign devshinken4.yzserv.com --allow-dns-alt-names

Vous avez donc maintenant un certificat signé par votre Puppet CA qui comprend un DNS Alt Name.

Share

Migrez vos Foreman et dormez sur vos deux oreilles.

Posté par le 16/01/2013 No comments

Je viens de migrer Foreman pour mettre la version 1.1 en production (je reviendrais sur les nouvelles fonctionnalités de la version 1.1).

Un des points les plus important que je teste quand je mets Foreman à jour, c’est la non regression de l’output de l’ENC. C’est à dire, je vérifie que la nouvelle version de Foreman envoie le même YAML au Puppet Master pendant ENC lookup. Pour me faciliter la vie, j’ai écris un petit script ruby (en partant du script d’external node controler de Foreman) qui va comparer les réponses en YAML entre deux instances de Foreman (ex: une instance de production et une instance de QA).

Afin de supporter les classes paramétrées, Foreman à changé un peu la structure du YAML mais le script supporte ce changement.
Vous pouvez le retrouver sur mon Github. Vous avez juste à modifier les deux URLs de vos Foreman de Production et de DEV ainsi que vos identifiants et mot de passe.

Le script s’arrête automatiquement si il trouve une définition de node différente entre le Foreman de dev et celui de production. Cet outils me permet donc d’être plus tranquile quand je fais une mise à jour majeure de mes Foreman !

Share

Déploiement automatisé et sans effort d’un webserver avec Foreman

Posté par le 19/06/2012 No comments

L’objectif de ce post est de montrer le niveau d’industrialisation pour le déploiement d’application sur des machines virtuelles que nous apporte Foreman à Yakaz.

Cette vidéo montre comment très facilement nous pouvons créer une nouvelle machine virtuelle et comment puppet configure de manière automatisé le serveur pour faire tourner notre application. Nous utilisons la notion de Compute Resource qui arrive avec Foreman 1.0.

Comparés à l’ancien support de la virtualisation (les hypervisors cf précédent article), les Computes Resources permettent de :

  • Déployer des VM avec plusieurs disque et interfaces réseaux
  • Avoir une console VNC directement depuis l’interface de Foreman 
  • De contrôler qui peut utiliser quelle compute resource : ceci permet d’avoir un cluster de virtualisation pour l’environnement de dévelopement où n’importe qui peut déployer des VM et un cluster de production isolé.
  • Support de la gestion de l’alimentation de la VM directement dans Foreman 
  • Suppression de l’host dans Foreman supprime maintenant aussi la VM sur l’hyperviseur
Les computes resources supportées pour l’instant par Foreman sont : 
  • oVirt / RHEV-M
  • libvirt
  • Amazon EC2
  • support partiel de VMware
Pour rappel, lors d’un déploiement en ‘Unattended Installation’, Foreman s’occupe de :
  • Créer les enregistrements A et PTR pour le domaine
  • Créer la lease DHCP pour la machine
  • Configurer puppet pour la machine via les ENC
  • Signer le certificat client puppet de votre nouvelle VM dans la PuppetCA de votre puppetmaster
Voir ces billets part1 part2 part3 pour le déploiement de Foreman.
Une fois la VM créée et buildée puppet va configurer la machine afin qu’elle soit conforme à l’environnement d’exécution de l’application sélectioné (en l’occurence nos serveurs Web avec notre site)

Cette vidéo vous montre que notre temps humain nécessaire au déploiement d’un nouveau serveur à été drastiquement réduit en misant sur l’intégration de Foreman dans notre architecture. Cette approche nous apporte une forte fléxibilité et élasticité dans la gestion de notre production.

 

Share

Vérifiez le run de vos Puppet avec Foreman et Nagios

Posté par le 21/03/2012 No comments

J’avais besoin de m’assurer de la fiabilité des runs de Puppet sur l’ensemble de ma production. Pour cela il faut m’assurer de 2 choses :

- Premièrement que puppet s’exécute correctement toute les demi-heure (j’utilise un cron et non pas le daemon puppet) . Pour cela, c’est assez simple, j’utilise un check nagios de base « check_file_age » et je vérifie l’âge du fichier « state.yaml ». Voici donc à quoi ressemble ma commande sur un serveur Debian:

/usr/lib/nagios/plugins/check_file_age -w 3780 -c 43200 -f /var/lib/puppet/state/state.yaml

- La première commande me permet de savoir que Puppet tourne bien régulièrement. Cependant je suis incapable de dire si les runs s’effectuent correctement ou non. C’est pourquoi  j’ai décidé d’utiliser la fonction de Reports de Foreman (voir ces 3 billets 1 2 3 pour l’installation de Foreman).

Vous pouvez trouver mon script içi sur Github. Pour l’utiliser sur un serveur Debian, il faut installer les dépendances (dont une qui n’est pas packagée en deb) :

# apt-get install libhttp-server-simple-perl libjson-perl
# wget http://search.cpan.org/CPAN/authors/id/M/MC/MCRAWFOR/REST-Client-243.tar.gz
# tar xvf REST-Client-243.tar.gz
# cd REST-Client-243
# make
# make install

Ensuite pour l’utiliser c’est très simple :

$ /usr/lib/nagios/plugins/check_foreman_puppet_failure.pl -H webserver.example.com -F http://foreman.example.com -w 3 -c 5 -u username -p password

Cette commande va vérifier les derniers rapports d’exécution de Puppet. Si le nombre de run en erreur est supérieur à warning ou critical alors le check retournera une erreur.

Voila, vous pouvez superviser correctement vos runs de Puppet grâce à Foreman et Nagios

Share

Foreman sort en version 0.3

Posté par le 07/06/2011 No comments

Un tout petit post aujourd’hui pour signaler la sortie de Foreman en version 0.3.
Cette version apporte pas mal de nouveauté notamment au niveau de l’interface Web.
Je vous invite à lire la release note situé ici.
Les paquets officiels Debian devrait pas tarder à arriver, sinon vous pouvez toujours les construire vous même en suivant la procédure décrite ici.

Bravo à l’équipe de développement qui fait vraiment un super travail. Vous pouvez toujours venir les saluer en allant sur le salon IRC de Freenode #theforeman.

Amusez-vous bien !

Share

Intégration de PuppetDoc avec Foreman

Posté par le 24/05/2011 No comments

Nous allons voir dans cet article comment intégrer la documentation de puppet à Foreman. L’objectif est de donner accès aux utilisateurs à cette documentation pour qu’ils sachent quelles règles sont appliquées dans les classes.

Patcher Puppetdoc de Debian 6

Pour les utilisateurs de Debian 6, la première chose à faire est de patcher puppetdoc (voir bug). Pour cela, vous pouvez utiliser le backport du patch que je met à disposition : 

# curl http://www.fitzdsl.net/wp-content/uploads/2011/05/puppet_generator.rb_.patch | patch /usr/lib/ruby/1.8/puppet/util/rdoc/generators/puppet_generator.rb

Générer la documentation

Vous pouvez en premier lieu définir le « document root » de votre documentation. J’ai décidé pour ma part de laisser la doc dans le dossier par défaut : RAILS_ROOT/public. Pour générer la documentation, nous allons utiliser une commande rake prévue pour cela. Dans /usr/share/foreman : 

# rake puppet:rdoc:generate

Pensez à mettre cette commande en Cron pour mettre à jour votre documentation au fur et à mesure.La documentation est maintenant accessible en allant dans Additional Settings, Puppet Classes, et en cliquant dans la colonne Environements de la classe.

Share

Mise à jour de la libvirt-ruby de Debian pour Foreman

Posté par le 24/05/2011 No comments

Cet article très court fait suite à mon précédent billet sur l’intégration de la libvirt avec Foreman. Nous avons vu qu’il était possible de gérer la création de VM et faire des actions simples sur ces VM. Cependant l’installation décrite dans l’article précédent ne permet pas d’exploiter tout ce que Foreman peut faire. En effet, Foreman peut lister les bridges présents sur les Hyperviseurs quand l’intégration de la libvirt le permet (c’est à dire sur Fedora et RHEL mais pas sur Debian / Ubuntu : voir ce bug).

Nous allons donc voir comment corriger très simplement ce problème quand Foreman est installé sur une machine Debian. Nous allons désinstaller le paquet ruby-libvirt de Debian et installer la gem correspondant mais à une version bien supérieure. 

# apt-get remove --purge libvirt-ruby1.8
# apt-get install libvirt-dev libxen-dev rubygems
# gem install ruby-libvirt
# service apache2 restart

C’est bon, si vous essayez de créer un nouvel Host sur un Hyperviseur basé sur Fedora ou RHEL, Foreman devrait vous proposer les bridges disponibles.

Share

Foreman et la libvirt : un pas vers les nuages !

Posté par le 23/05/2011 1 comment

Cet article va vous expliquer comment utiliser Foreman et la libvirt pour aller encore plus loins dans l’automatisation de votre gestion de serveurs. Nous allons donc utiliser les couples Foreman, libvirt et KVM pour industrialiser le déploiement de machines virtuelles. Les mécanismes décrits dans cet articles ne sont pas sécurisés et ne doivent pas être utilisés dans un environnement de production. Il est possible de sécuriser l’utilisation de la libvirt par l’utilisation de certificats SSL mais cela fera l’objet d’un autre article. Cet article sera basé sur l’utilisation de postes clients sous Ubuntu 11.04 et Fedora 15 comme hyperviseurs.

Installation des pré-requis sur l’hyperviseur

Pour Ubuntu :

Il faut commencer par installer l’ensemble des prérequis sur l’hyperviseur.

# apt-get install kvm kvm-pxe qemu-kvm libvirt-bin bridge-utils

Il faut maintenant configurer les interfaces pour créer un bridge. Pour plus d’informations voir cette page. 

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
        bridge_ports eth0

Redémarrer le service réseaux :

# service networking restart

Pour Fedora :

Installation des pré-requis : 

# yum install libvirt bridge-utils qemu-kvm

Création du bridge : 

# cat /etc/sysconfig/network-scripts/ifcfg-em1 
   DEVICE=em1
   HWADDR=MAC:ADDRESS
   BRIDGE=breth0
# cat /etc/sysconfig/network-scripts/ifcfg-breth0 
   DEVICE=breth0
   TYPE=Bridge
   PEERDNS=no
   BOOTPROTO=dhcp
   ONBOOT=yes
   NM_CONTROLLED=no
   DNS1=8.8.8.8
   DNS2=8.8.4.4

Redémarrer le service réseaux :

# service network restart

Ouverture de la libvirt pour faire écouter le daemon en TCP

La première étape est de faire écouter la libvirt en TCP. Dans le fichier /etc/libvirt/libvirtd.conf, assurez-vous que les directives soient configurées comme suit :

listen_tcp = 1
auth_tcp = "none"
listen_tls=0

Sur Ubuntu, il faut modifier le fichier /etc/init.d/libvirt-bin.conf et ajouter ‘ -l ‘ à la directive libvirtd_opts :

env libvirtd_opts="-l -d"

Sous Fedora, il faut modifier le fichier « /etc/sysconfig/libvirtd » et décommenter la ligne LIBVIRTD_ARGS= »–listen ».

Dans les deux cas, il vous faut redémarrer le service libvirt :

service libvirt-bin | libvirtd restart

Vous devriez constater que la libvirt écoute sur vos interface réseaux avec un netstat :

#  netstat --inet -alepn | grep libvirt
tcp        0      0 0.0.0.0:16509           0.0.0.0:*               LISTEN      0          12809       1403/libvirtd

Attention si vous utilisez un firewall sur la machine, pensez à ouvrir le port 16509 en TCP. Vous devriez pouvoir tester la connexion en TCP avec virt-manager. Pour ajouter l’hyperviseur (si il est différent de votre poste client, allez dans Fichier, Ajouter un connexion. Cochez « Connexion à un hôte distant », Méthode TCP, Nom d’utilisateur : vide et nom d’hôte l’adresse IP ou le nom DNS de votre hyperviseur. Virt-manager devrait réussir à se connecter à la libvirt de votre hyperviseur.

Ajout d’un hyperviseur dans Foreman

Dans la nomenclature de Foreman, un hyperviseur est une machine qui va faire tourner la libvirt et les vm. Il faut tout d’abord commencer par installer les dépendances ruby et redémarrer apache2 (si vous utilisez passenger évidemment (voir article sur l’installation de Foreman avec Passenger)

# apt-get install libvirt-ruby
# service apache2 restart

Nous allons maintenant ajouter un hyperviseur dans Foreman. Allez dans Settings / Hypervisors / New Hypervisor. Donnez lui un nom. L’URI de connexion doit être de la forme :

qemu+tcp://IP_HYPERVISOR/system

Création d’une machine virtuelle avec Foreman

Il ne nous reste plus qu’à créer une nouvelle machine virtuelle directement sous Foreman. Pour cela allez dans Host, New Host. Dans la section « Virtual Host Settings », laissez « Bare Metal » si vous souhaitez une installation « classique » sinon sélectionnez l’hyperviseur sur lequel vous souhaitez créer la nouvelle VM. Vous pouvez alors dimensionner la VM comme vous le souhaitez. Dans le champs « Interfaces » il vous faut mettre manuellement le nom de votre bridge (généralement br0 sous Ubuntu et breth0 sous Fedora). Remplissez les autres champs de manière classique. Vous pouvez noter que vous n’avez plus la MAC adresse à remplir : Foreman s’occupe de la récupérer automatiquement.

Vous pouvez suivre le process d’installation de votre machine en utilisant virt-manager et son affichage VNC.

Manager ses VMs depuis l’interface de Foreman

Il est maintenant possible de manager ses VM directement depuis l’interface de Foreman. Pour cela allez dans Settings, Hypervisors. Vous avez la liste des hyperviseurs disponibles. En cliquant à gauche sur le nom de l’hyperviseur vous pouvez afficher les caractéristiques matérielles de la machine.

En cliquant sur Guest vous pouvez manager directement depuis Foreman : Allumer ou Éteindre vos VM ou les détruire. Attention, en cliquant sur Destroy vous perdrez vos données !

Share

Installation d’une infrastructure de management de serveurs : Puppet / Foreman – part 3

Posté par le 18/05/2011 4 comments

Cet article va principalement s’intéresser aux quatres principales briques que Foreman va manager à votre place : DNS, DHCP, TFTP et bien sûr Puppet / PuppetCA.

Ajout d’un smart-proxy dans Foreman

Lancez votre service foreman-proxy :

# service foreman-proxy start

Pour vérifier que votre service s’est bien lancé, faite pointer votre navigateur HTTP sur l’url de votre foreman-proxy sur le port 8443. (ex: http://foreman:8443/features) Vous devriez voir apparaitre une page listant les fonctionnalités activées sur votre Smart Proxy Foreman. Si cette page n’est pas accessible pensez à vérifier vos règles de firewalling.

Avant de pouvoir ajouter un smart-proxy dans Foreman il faut au moins activer une fonctionalité. Comme nous allons le voir par la suite vous pouver activer :

:tftp: true
:dns: true
:dhcp: true
:puppetca: true
:puppet: true

Pensez à redémarrer le proxy pour appliquer la nouvelle configuration. On peut maintenant ajouter un Smart Proxy dans Foreman. Pour cela allez sur l’interface de Foreman, dans le menu déroulant à droite sélectionnez « Smart Proxies », New Proxy, nommez le et indiquez son URL sans oublier le port d’écoute du serveur Webrick (8443) par défaut.
Lorsque vous sauvegardez, si tout vas bien vous devriez voir toutes les Features supportées par votre smart-proxy.

Configuration du serveur TFTP

Pour configurer votre serveur TFTP, il vous faut aller dans /tftpboot (ou votre racine TFTP si vous en avez choisi une différente) .
Il vous faut un pxelinux.0 et des fichiers permettant une netboot de debian. Vous pouvez trouver ceux-ci dans cette archive proposée par Debian (http://ftp.fr.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/netboot/netboot.tar.gz).

Extrayez l’archive dans /tftpboot (ou la racine de votre serveur TFTP), supprimez le lien symbolique de pxelinux.cfg et créez les répertoires boot et pxelinux.cfg (oui, c’est un répertoire !). Donnez les droits 700 et user foreman-proxy:root à ces deux dossiers.

# tar xvf netboot.tar.gz
# rm -rf pxelinux.cfg
# mkdir boot pxelinux.cfg && chmod 700 boot pxelinux.cfg && chown foreman-proxy:root boot pxelinux.cfg
# rm netboot.tar.gz

Dans le fichier /etc/foreman-proxy/settings.yml :

  1. Décommenter la ligne :tftp: true
  2. Décommenter la ligne :tftproot et mettez /tftpboot (ou votre autre dossier)

Redémarrez votre service foreman-proxy, retournez dans la configuration des smart-proxy sur Foreman, éditez votre proxy renseigné et sauvegardez tout de suite : la feature TFTP devrait s’afficher.
On va créer un fichier de boot par défaut. Si vous ne demandez pas explicitement à Foreman de reconstruire votre machine alors ce fichier de boot par défaut demandera à votre machine de continuer son boot sur son disque local en cas de redémarrage. Pour cela on va utiliser la fonction de templating de Foreman. Allez sur l’interface Web, un template nommé « PXE Default File » devrait être présent. Vous avez juste à clicker sur « Build PXE Default button », et c’est bon, vous devriez avoir un serveur PXE fonctionnel.

Configuration du serveur DHCP

Dans le fichier de configuration du serveur DHCPd, il vous faut ajouter les lignes suivantes par rapport à une configuration « classique » :

> omapi-port 7911;
> allow booting;
> allow bootp;

subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.10 192.168.1.200;
   option domain-name-servers 192.168.1.1 8.8.8.8 8.8.4.4;
   option domain-name "mycomapny.com";
   option routers 192.168.1.1;
   filename "/pxelinux.0";
   next-server 192.168.1.1;
}

Dans le fichier /etc/foreman-proxy/settings.yml :

  1. Décommenter la ligne :dhcp: true
  2. Décommenter la ligne :dhcp_vendor: isc
  3. Ajouter les lignes
     :dhcp_config: /etc/dhcp/dhcpd.conf
     :dhcp_leases: /var/lib/dhcp/dhcpd.leases

On redémarre le service de smart-proxy : 

# service foreman-proxy restart

Configuration de Bind

On va maintenant passer à la configuration du serveur DNS. Nous allons utiliser le serveur Bind9. Pour que foreman puisse modifier dynamiquement des zones via l’outils nsupdate, il va falloir lui générer une paire de clé permettant de l’authentifier.

Ces clés vont être générées via les commandes : 

# dnssec-keygen -a HMAC-MD5 -b 512 -n USER foreman.mycompany.com

Je stocke personnellement ces clés dans le répertoire /etc/bind en les renomant foreman.key et foreman.private. Il faut leur donner les droits 400 et les users foreman-proxy:foreman-proxy.
Il faut ensuite indiquer à Bind que le user à qui appartient cette clé à le droit de modifier sa zone. Il faut donc dans votre déclaration de zone ajouter une directive allow-update. Vous devriez obtenir quelquechose comme ca : 

zone "mycompany.com" {
        type master;
        file "/etc/bind/mycompany/db.mycompany.com";
        allow-update {key "foreman"; };
};

Pensez à faire de même pour votre zone reverse !

Création d’un domaine dans Foreman

Il vous faut maintenant indiquer à Foreman qu’il peut gérer un nouveau domaine. Dans le menu déroulant sélectionnez Domain, New Domain.

Entrez un nom qui vous servira uniquement de référence dans Foreman, le nom complet de votre domaine puis associez votre smart-proxy. Enfin sauvez !

Configuration de Puppet / PuppetCA

Il faut dans un premier temps installer le package sudo.

#apt-get install sudo

Puis il faut ajouter dans le fichier /etc/sudoers les lignes suivantes :

# visudo
> foreman ALL=(ALL) NOPASSWD:/usr/sbin/puppetca
> foreman-proxy ALL=(ALL) NOPASSWD:/usr/sbin/puppetca --clean *

Comme d’habitude on va activer ces services en dé-commentant les lignes correspondantes aux services dans /etc/foreman-proxy/settings.yml puis redémarrer le service foreman-proxy. Pour faire prendre en compte ces nouveaux services par foreman, éditez votre smart-proxy et sauvez ! Les services devraient apparaitre dans la liste des services disponibles pour ce smart-proxy !

Dans /etc/puppet, créer un fichier autosign.conf et changer son owner en foreman-proxy:puppet

# cd /etc/puppet
# touch autosign.conf
# chown foreman-proxy:puppet autosign.conf

Ajouter un sous-réseau dans Foreman

Pour ajouter un sous-réseau dans Foreman, sélectionnez Subnet dans le menu déroulant, puis New Subnet.
Remplissez son nom, son domaine associé, les informations relatives au réseau et le serveur smart-proxy que vous souhaitez associer à ce sous-réseau.

Conclusion

Voila, vous avez fini de paramétrer globalement la gestion des 4 briques principales que Foreman va pouvoir piloter pour vous. Nous verrons dans une dernière partie comment utiliser Foreman pour automatiser complètement l’installation d’une machine Debian.

Share