Après avoir découvert la CLI, continuons dans l’univers d’ansible pour apprendre à l’utiliser et bien comprendre ses principes. Eh oui, apprendre ansible c’est bien mais il faut surtout bien assimiler les concepts et bien organiser. Le but de cet article est d’aider les débutants à trouver leur chemin et de partager les pratiques avec les personnes ayant un niveau un peu plus avancé.

Il existe pas mal de bonnes pratiques pour ne pas se louper et toujours garder le cap. Après quelques années d’expériences, je pense que dans le domaine de l’infra as code, il faut toujours avoir des règles, des principes, des nomenclatures pour garder l’objectif de toujours s’y retrouver et éviter les dérives. Et systématiquement, il y a des dérives et il faudra revenir vers vos règles pour ramener les choses dans l’ordre.

Mais bon, quand on ne connait pas ou même lorsque l’on connait juste un peu, ce n’est pas évident de trouver son cap. Et surtout il faut éviter d’inventer des choses qui existent déjà.

Rester dans les fondamentaux a aussi un gros avantage. Si vous intégrez de nouvelles personnes dans vos équipes et qu’elles connaissent déjà les bonnes pratiques, ce sera encore plus facile pour eux d’être intégré technologiquement parlant. Et cela est très important en matière d’IaC car celle-ci décrit votre infrastructure et l’installation d’élements importants.

Bref l’inventaire ou inventory est un élément essentiel dans ansible et dans votre infrastructure. Pour débuter avec ansible, il faut donc bien organiser celui-ci.

Inventory ou fichier d’inventaire, c’est votre infrastructure

L’inventory n’est pas juste ce fichier mais celui-ci est central. Nous verrons dans le point suivant que l’inventaire est aussi composé de ses variables que nous nommons… variables d’inventaire.

L’inventaire comprend la liste de vos machines, il peut être de 3 types de formats : json, yaml, ini. Personnellement, je préfère le format yaml. Pourquoi ? tout simplement car :

• tous les autres fichiers ansible sont en format yaml, donc par souci d’homogénéité
• également car grâce à son indentation il permet de bien visualiser la hiérarchie des groupes et hosts (même si nous ne sommes pas toujours fan du format yaml).

Une machine est appelée host assez logiquement. Un ou plusieurs hosts peuvent consituer un groupe (group). Les hosts peuvent être décrit par des éléments permettant de les joindre : ip, dns principalement.

Et si vous avez des nomenclatures de serveurs adaptées, vous pourrez même gagner du temps en utilisant des patterns, par exemple : srv-bdd-[1-5].

Mettons maintenant tout cela en musique :

all:
  children:
    parent1:
      hosts:
        srv4:
      children:
        enfant1:
          hosts:
            srv1:
            srv2:
        enfant2:
          hosts:
            srv3:
          children
            enfant3:
              hosts:
                srv5:

Cela pour le format yaml, on a :

• le groupe parent de tous qui se nomme toujours ALL (non modifiable)
• le sous-groupe de ALL qui se nomme parent1 (à vous de choisir le nom)
• parent1 est composé d’un host srv4 et de deux sous-groupes : enfant1 et enfant2
• enfant1 est composé de srv1 et srv2
• enfant2 est composé de srv3 et un autre sous-groupe enfant3
• etc

Et maintenant pour le format ini.

[parent1]
srv4
[enfant1]
srv1
srv2
[enfant2]
srv3
[enfant3]
srv5
[parent1:children]
groupe1
groupe2
[enfant2:children]
enfant3

Et voilà l’essentiel. On peut également passer des variables directement dans ce fichier pour les associer à des groupes ou encore à des hosts. Mais je ne recommande pas de faire cela ou surtout il faut le limiter au maximum pour éviter que votre fichier d’inventaire ansible ne soit imbuvable.

Les variables d’inventaires ansible

Pour apprendre ansible, nous le reverrons mais il est important d’avoir un peu en tête la hiérarchie des variables ou précédence des variables… 22 types de variables au final dont certaines sont plus prioritaires que d’autres. Rassurez-vous vous n’avez pas besoin de toutes les connaître et surtout il faut éviter autant que possible de toutes les utiliser pour faciliter la maintenance de votre code.

Les formations ansible passent souvent assez rapidement sur les variables d’inventaires. C’est assez logique car sans mise en pratique c’est toujours délicat à aborder. Néanmoins il faut y passer quelques minutes pour bien débuter.

Notre fichier inventory est donc composé de hosts et de groupes. Nous allons donc pouvoir définir des variables de groupes et d’autres spécifiquement pour des hosts. Une fois que l’on a dit cela, il se dégage logiquement une hiérarchie ou précédence, les variables de hosts s’imposent aux variables de groupes. Ainsi, si vous avez un groupe de webserver avec une variable port = 80, si vous avez une exception dans ce groupe vous pourrez surcharger la variable de groupe par la variable du host en question port = 8080, par exemple.

Comment cela s’organise ?

Assez simplement au même niveau que notre inventory (le fichier), on va retrouver deux répertoires :

• group_vars
• host_vars

Une fois dans ces répertoires nous allons pouvoir créer soit :

• des répertoires par groupe avec le nom du groupe ou par nom de host, vous pourrez ainsi créer plusieurs fichiers car vous avez beaucoup de variables et donc un besoin d’organiser un maximum
• des fichiers yaml par nom de groupe ou nom de host car vous avez peu de variables.

├── 00_inventory.yml
├── group_vars
│   ├── all.yml
│   ├── dbserver.yml
│   └── webserver
│       ├── vault.yml
│       └── webserver.yml
└── host_vars
    ├── srv1
    │   └── srv1.yml
    └── srv2.yml

On retrouve bien :

• notre fichier d’inventaire 00_inventory.yml
• nos deux répertoires principaux toujours nommés group_vars et host_vars
• et des sous-répertoires ou fichiers

Et si vous avez différents environnements vous pouvez tendre vers cette organisation assez connue :

├── dev
│   ├── 00_inventory.yml
│   ├── group_vars
│   │   ├── all.yml
│   │   ├── dbserver.yml
│   │   └── webserver
│   │       ├── vault.yml
│   │       └── webserver.yml
│   └── host_vars
│       ├── srv1
│       │   └── srv1.yml
│       └── srv2.yml
├── prod
│   ├── 00_inventory.yml
│   ├── group_vars
│   │   ├── all.yml
│   │   ├── dbserver.yml
│   │   └── webserver
│   │       ├── vault.yml
│   │       └── webserver.yml
│   └── host_vars
│       ├── srv1
│       │   └── srv1.yml
│       └── srv2.yml
└── stage
    ├── 00_inventory.yml
    ├── group_vars
    │   ├── all.yml
    │   ├── dbserver.yml
    │   └── webserver
    │       ├── vault.yml
    │       └── webserver.yml
    └── host_vars
        ├── srv1
        │   └── srv1.yml
        └── srv2.yml

Prenez bien votre temps pour bien comprendre et retenir ce type d’organisation car vous la retrouverez souvent ou elle pourra repondre à votre besoin. Pour débuter avec l’inventaire ansible c’est déjà un très bon début.

Voici une petite démonstration qui va permettre de rendre parlant tout cela avec une variable que l’on va surcharger à différents endroits.

Mon dépôt de formation ansible ici.

Retrouvez également la documentation officielle concernant l’inventory ici.

English version : if you want to learn and start with ansible

Lors de notre précédent article, nous avons débuter avec ansible :

• principes de base
• installations possibles
• premières commandes

Nous n’allons pas encore nous jeter dans le grand bain des rôles et playbooks. Pour un débutant, il est important de comprendre le fonctionnement de base d’un outil. En guise de formation et pour faire un premier pas avec la ligne de commande, je vous propose de pratiquer quelques commandes.

Retrouvez mon dépôt ici.

Et la vidéo associée :

La plus basique : le ping ansible

Pour savoir si ansible fonctionne de votre serveur/laptop source vers votre machine cible, nous pouvons utiliser le module ping. Attention, il ne s’agit pas là de faire un ping réseau ou icmp mais un ping au sens de ansible. En gros, ansible peut-il faire une connexion ssh vers la machine cible d’où vous le lancer.

Cela induit donc plusieurs paramètres : le serveur et le user. Il est important de ne pas oublier ce dernier car c’est avec lui que sera associé la clef ssh ou le password. L’utilisateur de départ qui initie la connexion est celui qui lance la commande ansible et l’utilisateur final peut être précisé par l’option -u.

Regardons la ligne ci-dessous :

ansible -i "node2," all -u vagrant -m ping

On a :

• -i : qui précise le serveur target/cible, cela peut être un nom dns ou une ip. Important,vous devez rajouter une virgule après ce n’est pas une erreur de frappe. Suivi de « all » qui définit le groupe qui par défaut est all, nous reverrons cela plus tard avec l’inventaire.
• -u : précise l’utilsiateur de la machine cible. Si vous utilisez une clef ssh c’est dans la conf ssh de ce user que vous devez avoir ajouté votre clef publique (dans le fichier authorized_keys).
• -k : si vous n’avez pas de clef publique ou que vous souhaitez utiliser une connexion ssh via un passowrd vous pouvez le faire avec cette option. Ansible proposera alors de le saisir après avoir lancé la commande.

Vous pouvez forcer l’utilisation du password ssh de cette manière :

ansible -i "node2," all -u vagrant -k --ssh-extra-args="-o 'PreferredAuthentications=password'" -m ping

Pour afficher le résultat sur une ligne :

ansible -i "node2," all -u vagrant -m ping --one-line

Pour utiliser à distance une commande sur le shell distant :

ansible -i "node2," all -u vagrant -m command -a uptime

Et voilà vous avez lancé un uptime à distance et récupéré son résultat.

Poussons plus loin dans l’utilisation de la CLI

Bien sûr on peut même aller plus loin avec la simple ligne de commande ansible. Je vous propose pour vous former quelques exemples qui vous permettront de vous aguerrir par la pratique et sans faire de code pour le moment.

Par exemple, par la ligne de commande nous pouvons définir une variable et afficher son résultat comme si nous étions sur le serveur distant.

ansible -i "node2," all -e "var1=xavki" -m debug -a 'msg={{ var1 }}'

Ainsi nous passons quelques nouvelles options :

• -e : pour définir une variable « var1 » avec sa valeur « xavki »
• -m : pour préciser le module à utiliser, en l’occurence « debug »
• -a : pour définir un paramètre de ce module, nous définissons « msg » avec la valeur de var1. Remarquez le double accolade qui est un format jinja, ansible reposant sur python.

Maintenant lançons un shell un peu plus élaboré avec quelques pipe dans ansible :

ansible -i "node2," all -u vagrant -m shell -a "ps aux | grep vagrant | wc -l" --one-line

On retrouve toujours nos options et nous avons simplement changé de module en utilisant « shell ». Et on profite du oneline pour l’output.

Comment installer à distance un serveur nginx :

ansible -i "node2," all -b -m apt -a 'name=nginx state=latest'

Là encore changement de module pour « apt » et définition de deux paramètres de ce module avec -a.

De même pour arrêter ou redémarer le service systemd :

ansible -i "node2," all -b -m service -a 'name=nginx state=stopped'

Et encore un peu plus…

Et on peut pousser encore plus loin avec d’autres onelines très facile à comprendre et utiliser.

Comment faire l’équivalent d’un scp avec ansible en une ligne ?

ansible -i "node2," all -m copy -a 'src=toto.txt dest=/tmp/titi.txt'

On y définit le fichier source et la destination. Mieux qu’un scp, ansible va faire jouer son idempotence et ne réalisera cette action que si nécessaire. C’est à dire si le fichier n’existe pas ou si il est différent du fichier source.

Pour faire l’inverse et récupérer un fichier d’une machine distante ?

ansible -i "node2," all -m fetch -a 'src=/tmp/titi.txt dest=xavki.txt flat=yes'

Cette fois-ci on utilisera le module « fetch », là encore en une ligne pour débuter tranquillement et apprendre à notre rythme.

Mais savez vous que à chaque run, ansible récupère ce que l’on appelle des facts, ce sont des variables génériques soit nécessaire pour son fonctionnement soit souvent utiles.

Eh bien regardons les facts disponibles pour une machine donnée :

ansible -i "node2," all -m setup -a "filter=ansible_distribution*"

Vous voyez que dans cette exemple, nous filtrons ceux-ci pour ne récupérer que les facts relatifs à la distribution.

Forez vous avec des tutorials ansible sur la chaine Xavki

Vous le savez, la chaine xavki que je tiens, est axée autour du devops. Comment devenir devops ou en acquérir les réflexe ou même la philosophie ? Dans ce domaine, certains outils sont marquants et sortent du lot. L’infrastructure as code est bien sûr un peu essentielle. De nombreux softs existent dans ce domaine et certains ont gagné des parts ces dernières années. Ansible fait partie de ces outils du parfait devops.

Ansible en quelques principes ?

Les principes d’ansible en font de lui un des plus faciles à adopter du marché. Totalement gratuit, il se base sur le langage python qui a fortement progressé ces dernières années agrandissant sensiblement son périmètre au fur et à mesure des années (IA, big data, statistiques, développement, CMS, framework…).

En outre, pour faciliter les choses, il se base sur une méthode de type push. A savoir que ansible ne nécessite pas d’agent. Mieux, une simple connexion ssh et python vous permettront de faire l’essentiel des tâches que vous aurez à réaliser. Un bon point pour les sysadmins qui restent fidèles à leurs scripts bash avec des boucles pour lancer un peu de ssh. Ou encore aux développeurs python qui utilisent paramiko avec une gestion délicate de l’idempotence… Ansible peut satisfaire vraiment beaucoup de monde.

Certains apprécieront moins son langage descriptif à base de yaml. Néanmoins, il permet de glisser sur la tendance et permet d’organiser clairement le code sous réserve de respecter les bonnes indentations. Un bon IDE vous y aidera d’autant plus.

Quelques éléments centraux :

• le fichier d’inventaire (inventory file) : facile à deviner, il permet de regrouper la liste des machines, des groupes de machines ou même des patterns de serveurs
• les variables d’inventaire : il s’agit des variables spécifiques à des hosts/serveurs ou à des groupes de machines. Elles sont stockées soit dans le fichier d’inventaire mais plutôt dans des répertoires host_vars et group_vars, respectivement pour les serveurs et les groupes de serveurs.
• le rôle : regroupe un ensemble de tâches ou d’actions cohérentes pour installer, configurer etc (par exemple installer un serveur web). Un rôle est constitué notamment d’actions que l’on appelle tasks.
• les tasks : ce sont des tâches individuelles qui utilise un module suivant des paramètres adaptés à la finalité de l’action
• le playbook : fichier permettant de faire la jointure entre l’inventaire et les rôles. Il a une fonction centrale qui permet de dire quel groupe ou quel serveur va avoir tels et tels rôles de joués.

Respecter ces principes est PRIMORDIAL pour la faciliter de l’organisation du code dans son ensemble. S’agissant de bonnes pratiques, n’importe quelle personne ayant suivie une formation ansible pourra s’y retrouver relativement facilement et pouvoir découvrir votre infra en lisant comme dans un livre (on l’oubli trop souvent).

Installer le binaire

Potentiellement il y a 3 choix pour installer ansible :

• via le gestionnaire de module python comme pip (pip3)
• via le téléchargement de la source
• via le gestionnaire de paquets de votre distribution préférée

Personnellement je préfère de loin cette dernière solution. Mais le contexte peut vous en faire décider autrement.

Sur debian on va simplement faire

sudo apt update

sudo apt install ansible

Et voilà le tour est joué. Vous pourrez très bien le faire sur redhat/centos/fedora car le projet ansible est porté par Redhat.

Pour configurer ansible, il est nécessaire de retenir un nom de fichier : ansible.cfg.

Vous pourrez le retrouver dans /etc/ansible/ ou encore dans votre home ou enfin à la racine de votre code (localisation du playbook).

Je vous invite à en découvrir plus sur la playlist de tutos ansible.

Premières commandes en CLI

Si vous avez installé ansible, vous êtes prêts à faire feu !!! Sauf si vous n’avez pas créé votre clef ssh. Dans ce cas, je vous propose une petite piqure de rappel ici.

Bref comment débuter et faire vos premières commandes ?

Pour pinguer les machines cibles.

ansible -i "node2," all -u vagrant -m ping

Attention, on parle d’un ping au sens ansible à savoir réussir une connexion ssh globalement.

-i : permet de préciser le fichier d’inventaire mais comme nous ne l’avons pas encore vu et que notre cible est une seule et unique machine on va simplement préciser cette machine entre double quote MAIS n’oubliez pas la virgule et le all (pour indiquer que cette machine fait partie du groupe all.

-u : permet de préciser l’utilisateur distant pour notre ssh ( <user>@<server>)

-m : permet de préciser l’utilisation d’un module, en l’occurence le module ping.

Dans notre cas nous avons une clef ssh mais on peut également faire la même chose par un password ssh :

ansible -i "node2," all -u vagrant -k -m ping

et si vous voulez forcer le fonctionnement par password pour une raison précise :

ansible -i "node2," all -u vagrant -k --ssh-extra-args="-o 'PreferredAuthentications=password'" -m ping

Installer kubernetes on premise est un petit défi même si certaines solutions sont plus simples que d’autres. J’ai pu tester différentes options comme kubadm, rancher ou en core kubespray mais jamais « the hard way ». Cette dernière méthode est certainement la meilleure pour mieux appréhender la constitution d’un cluster. Certes, cette méthode est formatrice mais peut effrayer notamment faire peur si on veut installer un cluster kubernetes pour de la production. Si vous souhaitez vous former à kubernetes rendez-vous sur cette playlist.

Je vous propose de découvrir une méthode intermédiaire mais d’y ajouter le nécessaire pour rendre votre cluster hautement disponible. Et vous allez voir que contrairement à ce que l’on pense ce n’est pas si compliqué. Je vous invite après cette installation de prendre du recul et d’identifier les points critiques pour être bien à l’aise avec ces éléments. Car le jour où votre cluster kube dysfonctionne en production et on premise, vous pouvez transpirer pas mal pour débuguer car généralement vous n’avez pas mis qu’une seule application dessus.

Tout le code ci-dessous est présent dans mon dépôt officiel.

Mais je vous invite à découvrir les vidéos dans cette playlist youtube :

De quoi avons nous besoin côté machines virtuelles ?

Eh oui on veut tester un environnement de production mais rien ne vous empêches de vous faire la main sur votre laptop ou de simples machines virtuelles. Personnellement, j’utilise souvent virtualbox et je fais le provisioning de manière automatisé avec vagrant. Le Vagrantfile est donc ce qui va le mieux décrire notre infrastructure. J’ai volontairement évité de factoriser les boucles de manière à rendre cela plus lisisble.

Notre infrastructure sera composée :

• 1 machine de déploiement pour jouer kubespray (ansible) on va pas salir notre laptop non plus et en prod on ne déploie pas de son laptop.
• 2 haproxy : ils serviront pour loadbalaner l’api kubernetes pour les commandes kubectl vers nos master (port 6443) et également pour loadblancer sur les noeuds worker les flux http/https (80/443)
• 2 masters : il vaudrait mieux 3 mais notre but est de faire de simples tests tout de même (en ajoute run n’est juste que rajouter une ligne dans le ansible)
• 1 node : notre objectif n’est pas d’héberger mais de tester un cluster kube et son environnement haute disponibilité.

Ce qui donne :

Vagrant.configure(2) do |config|
  common = <<-SHELL
  if ! grep -q deploykub /etc/hosts; then  sudo echo "192.168.7.120     kdeploykub" >> /etc/hosts ;fi
  if ! grep -q node01 /etc/hosts; then  sudo echo "192.168.7.121     kmaster01" >> /etc/hosts ;fi
  if ! grep -q node02 /etc/hosts; then  sudo echo "192.168.7.122     kmaster02" >> /etc/hosts ;fi
  if ! grep -q node03 /etc/hosts; then  sudo echo "192.168.7.123     knode01" >> /etc/hosts ;fi
  if ! grep -q node04 /etc/hosts; then  sudo echo "192.168.7.124     haproxy01" >> /etc/hosts ;fi
  if ! grep -q node05 /etc/hosts; then  sudo echo "192.168.7.125     haproxy02" >> /etc/hosts ;fi
  sudo yum -y install vim tree net-tools telnet git python3-pip sshpass
  sudo setsebool -P haproxy_connect_any=1
  sudo echo "autocmd filetype yaml setlocal ai ts=2 sw=2 et" > /home/vagrant/.vimrc
  sed -i 's/ChallengeResponseAuthentication no/ChallengeResponseAuthentication yes/g' /etc/ssh/sshd_config
  sudo systemctl restart sshd
  SHELL
  

	config.vm.box = "centos/7"
	config.vm.box_url = "centos/7"

	config.vm.define "kdeploykub" do |kdeploykub|
		kdeploykub.vm.hostname = "kdeploykub"
		kdeploykub.vm.network "private_network", ip: "192.168.7.120"
		kdeploykub.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "1" ]
			v.customize [ "modifyvm", :id, "--memory", "512" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "kdeploykub"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "kmaster01" do |kmaster01|
		kmaster01.vm.hostname = "kmaster01"
		kmaster01.vm.network "private_network", ip: "192.168.7.121"
		kmaster01.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "2" ]
			v.customize [ "modifyvm", :id, "--memory", "2048" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "kmaster01"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "kmaster02" do |kmaster02|
		kmaster02.vm.hostname = "kmaster02"
		kmaster02.vm.network "private_network", ip: "192.168.7.122"
		kmaster02.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "2" ]
			v.customize [ "modifyvm", :id, "--memory", "2048" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "kmaster02"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "knode01" do |knode01|
		knode01.vm.hostname = "knode01"
		knode01.vm.network "private_network", ip: "192.168.7.123"
		knode01.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "2" ]
			v.customize [ "modifyvm", :id, "--memory", "2048" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "knode01"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "haproxy01" do |haproxy01|
		haproxy01.vm.hostname = "haproxy01"
		haproxy01.vm.network "private_network", ip: "192.168.7.124"
		haproxy01.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "1" ]
			v.customize [ "modifyvm", :id, "--memory", "512" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "haproxy01"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "haproxy02" do |haproxy02|
		haproxy02.vm.hostname = "haproxy02"
		haproxy02.vm.network "private_network", ip: "192.168.7.125"
		haproxy02.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "1" ]
			v.customize [ "modifyvm", :id, "--memory", "512" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "haproxy02"]
		end
		config.vm.provision :shell, :inline => common
	end

end

Ou encore ce Vagrantfile

Commençons par le loadbalancer externe haproxy et sa vip gérée par keepalived

Attention avant de lancer le ansible kubespray, il est nécessaire que votre haproxy et votre VIP soient mis en place.

Donc première chose on installe les deux haproxy et keepalived :

sudo apt install - y haproxy keepalived

et ensuite on édite la configuration de haproxy

global
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

listen stats
    bind *:9000
    stats enable
    stats uri /stats
    stats refresh 2s
    stats auth xavki:password

listen kubernetes-apiserver-https
  bind *:6443
  mode tcp
  option log-health-checks
  timeout client 3h
  timeout server 3h
  server master1 192.168.7.121:6443 check check-ssl verify none inter 10000
  server master2 192.168.7.122:6443 check check-ssl verify none inter 10000
  balance roundrobin

Bien sûr derrière je vous laisse reload le service systemd de haproxy.

Ensuite ajoutons la configuration de keepalived :

vrrp_script reload_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 1
}

vrrp_instance VI_1 {
   virtual_router_id 100
   state MASTER
   priority 100

   # interval de check
   advert_int 1

   # interface de synchro entre les LB
   lvs_sync_daemon_interface eth1
   interface eth1

   # authentification entre les 2 machines LB
   authentication {
    auth_type PASS
    auth_pass secret
   }

   # vip
   virtual_ipaddress {
    192.168.7.130/32 brd 192.168.7.255 scope global
   }

   track_script {
     reload_haproxy
   }

}

Dans cette configuration on utilise une VIP qui switchera en fonction du service haproxy et du fait qu’il soit fonctionnel au vue de systemd ou non. Cette VIP est la :

192.168.7.130

Par défaut cette VIP sera portée par la machine haproxy1. Si celui-ci tombe cette adresse va être installée sur haproxy2 grâce à keepalived.

Vérifiez que les deux services (haproxy et keepalived) soient bien démarrés sur les 2 machines haproxy. Activez le redémarrage au reboot avec le systemctl enable.

Maintenant configurons kubespray

Kubespray c’est du ansible. donc première chose vous devez l’installer sur la machine de déploiement et installer également pip :

sudo apt install ansible python3-pip

Ensuite clonez le dépôt de kubespray :

git clone https://github.com/kubernetes-sigs/kubespray

rendez-vous dans le nouveau répertoire puis :

sudo pip3 install -r requirements.txt

Ensuite on prépare le ansible on va recopier le modéèle d’inventaire :

cp -rfp inventory/sample inventory/mycluster

Puis on modifie cet inventory :

# ## Configure 'ip' variable to bind kubernetes services on a
# ## different ip than the default iface
# ## We should set etcd_member_name for etcd cluster. The node that is not a etcd member do not need to set the value, or can set the empty string value.
[all]
kmaster01 ansible_host=192.168.7.121  ip=192.168.7.121 etcd_member_name=etcd1
kmaster02 ansible_host=192.168.7.122  ip=192.168.7.122 etcd_member_name=etcd2
knode01 ansible_host=192.168.7.123  ip=192.168.7.123 etcd_member_name=etcd3

# ## configure a bastion host if your nodes are not directly reachable
# bastion ansible_host=x.x.x.x ansible_user=some_user

[kube-master]
kmaster01
kmaster02
[etcd]
kmaster01
kmaster02
knode01

[kube-node]
knode01

[calico-rr]

[k8s-cluster:children]
kube-master
kube-node
calico-rr

On y a donc déclaré nos nodes master et notre worker.

Particularité ETCD

Particularité pour notre test, nous allons faire ce qu’il ne faut pas faire c’est à dire héberger les services etcd sur les master et surtout sur 1 worker. Pourquoi cela ? Etcd nécessite un nombre impair de noeuds pour son bon fonctionnement. Donc on pourrait en avoir 1 ou 3. Mais si on veut faire des tests de coupures de noeuds il est préférable d’en avoir 3. J’ai donc salement choisi d’en ajouter un sur le worker.

En production il serait recommandé d’externaliser les etcd et ne pas les avoir au sein des machines kubernetes (plus y ajouter des backups etc).

Dernière configuration ansible

Maintenant il nous faut éditer le fichier du group all :

vim inventory/mykub/group_vars/all/all.yml

comme en modifiant ces lignes

## External LB example config
apiserver_loadbalancer_domain_name: "elb.kub"
loadbalancer_apiserver:
  address: 192.168.7.130
  port: 6443

On vient donc de préciser que la VIP est notre point d’entrée du loadbalancer et également que votre cluster répondra sur le nom de domaine elb.kub (vous pourrez modifier votre /etc/hosts).

Maintenant c’est partie on peut jouer notre ansible en tant que user vagrant et on utilisera le password « vagrant »… un standard sur vagrant.

ansible-playbook -i inventory/my-cluster/inventory.ini -u vagrant -k -b cluster.yml

Attendez plusieurs dizaines de minutes suivant votre connexion et le nombre de machines et votre cluster sera up à la fin.

Première connexion avec kubectl

Dernière tâche pour accéder à notre cluster, il nous faut récupérer le certificat du compte d’administrateur de notre cluster kubernetes.

Copiez sur un des master le fichier

cat /etc/kubernetes/admin.conf

Puis créez et collez le contenu sur la machine devant accéder au cluster :

mkdir -p ~/.kube
vim ~/.kube/config

Enfin installons kubectl sur cette même machine :

sudo apt-get update && sudo apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl

Maintenant testons notre cluster :

kubectl cluster-info
kubectl get nodes

Test de la haute disponibilité

Si tout est bien fonctionnel…

Coupez un haproxy soit en coupant le service avec un systemctl stop soit en arrêtant plus ou moins brutalement la machine.

Testez à nouveau vos commandes kubectl.

Ensuite coupez un master et procédez au même test.

Alors ça marche ?

Je vous invite à découvrir la playlist complète pour découvrir kubernetes et d’autres outils liés ici.