Archives de catégorie : Non classé

Kubespray : installation d’un cluster K8S se rapprochant de la production

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

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.

Manipuler une API via une interface graphique avec Postman

Que vous soyez développeur frontend ou backend, une étape incontournable du développement d’une application web est l’appel vers le serveur. Plus votre application croit, plus ces appels sont nombreux. Si dans certains cas vous pouvez faire ces appels via votre navigateur, le plus souvent il faudra un autre outil pour pouvoir lancer ces appels et vérifier que votre développement a bien fonctionné.

L’outil Postman est l’incontournable pour pouvoir manipuler efficacement des appels API via une interface graphique.

Pourquoi utiliser Postman ?

Dès lors que vos appels API impliquent des appels autres que des requêtes GET, vous aurez besoin d’avoir un outil. Saisir ses requêtes curL à la main n’étant pas une option pour être productif, il faut utiliser un client graphique pour accélérer ses tests manuels.

Postman propose une interface graphique très simple d’utilisation pour effectuer ses appels HTTP en paramétrant la méthode, l’url, les query params, le header et, le cas échéant, body.

Postman est très pratique lors du développement d’une API ou lorsqu’on cherche à découvrir une API tierce en vue de l’intégrer dans son application.

Accélérer son développement

Postman va bien au delà de pouvoir effectuer ses requêtes http via une interface graphique. Son véritable atout vient de sa capacité à stocker certaines données en variables et de pouvoir lancer de manière séquentielle plusieurs appels API d’affilé.

Ainsi, tester un flux de comportement comme si un utilisateur allait manipuler votre API est possible en créant une collection d’appels API. Vous pourrez définir en variable certaines données qui sont renvoyés en tant que réponse d’une requête précédente et définir un comportement à suivre en fonction des résultats.

Vous pouvez également utiliser de la donnée externe, via un fichier CSV ou JSON afin de faire tourner vos requêtes. Ce cas est utilisé pour initialiser un échantillon de base de donnée en vue de faire quelques tests manuels.

Alternatives à Postman

Des alternatives gratuites et payantes à Postman existent. L’application Insomnia, compatible Mac, Windows et Linux, est une alternative gratuite et plus simple que Postman. Elle offre moins de fonctionnalités au bénéfice d’avoir une interface plus épurée.

Paw est un client Mac, vendu à 49€, offrant des fonctionnalités au moins aussi poussé que Postman. Son interface graphique est très travaillée et rend son utilisation très agréable. Cependant, son prix décourage beaucoup d’utilisateurs qui trouvent leurs compte avec postman gratuitement

Et le bon vieux Jmeter

Enfin, vous pouvez aussi vous tourner vers un outil plus ancien : Jmeter. Ce dernier est plus réputé pour être capable de faire des tests de charge mais sa polyvalence lui permet sans souci de faire les tests de vos routes d’API. Gratuit et appartenant à la fondation apache, il nécessite une certaine pratique mais vous permettra de réaliser des tests complets allant jusque vérifier la bonne insertion des données dans la base de données de votre API.

Et l’aventure continue…

Après plusieurs semaines, il est temps pour moi de refaire un petit sur cette aventure xavki. Et une fois de plus, j’en tire beaucoup de points positifs.

Les nouvelles playlists sont attendues

Dernièrement, j’ai ouvert de nouvelles playlists : terraform, ELK, cassandra, packer ou encore mindset.

Et à chaque fois le public a répondu présent. Bien sûr l’idée pour moi n’est pas de m’étaler sans rentrer un peu dans chaque technologie mais d’offrir un échantillon du potentiel de chaque outil.

Et c’est bien là l’objectif de la chaine, vous faire et au passage me faire découvrir le périmètre de chaque outil. Pour moi un devops doit surtout avoir une vision générale pour savoir piocher dans sa caisse à outils pour trouver la clef qui correspond le mieux. Et cela en prenant en compte, l’environnement, les objectifs et également son niveau de connaissances et compétences.

Votre carrière et vos qualités à mettre en valeur

Xavki vise à nous faire progresser sur le côté technologique mais aussi sur les aspects liés à notre métier en général.

Ainsi, j’ai souhaité ouvrir un volet RH avec une orientation carrière. L’idée est de se donner les outils, les réflections pour faire les bons choix aux bons moments. Comment aussi se rassurer face à des questions dont on est peu habitées de traiter.

Un autre volet, Mindset, me permet de proposer un angle plus comportemental. Non pas que l’on soit tous mauvais moi. Mais plutôt que l’on peut parfois ne pas se donner toutes les chances pour progresser, s’étendre encore plus vite et prendre vraiment son envol. C’est dans ce sens que j’ai abordé la question de la patience (qui peut me manquer cruellement parfois).

Dans une prochaine vidéo, j’y aborderai « apprendre, comprendre et montrer ». En essayant de faire le tour de la question de l’apprentissage en entreprise avec des personnes de profils différents et que ce soit sous l’angle apprenant que enseignant. C’est pour moi aussi l’occasion de comprendre pourquoi les gens aime apprendre via la chaine xavki… pourquoi ça marche ??

Recentrer des liveki

Depuis 3 mois, je cherche la bonne formule pour les lives et les choses progressent. Il me semble que les interventions sont une bonnes formules. Maintenant il reste à trouver le bon équilibre pour ne pas en avoir trop et être dans la ligne de la chaine. C’est à dire restons fortement en lien avec le monde professionnel.

Je pense que les prochains liveki dureront autour de 2h avec pas plus de 2 intervenants. Par ailleurs, j’essairai d’avoir un peu plus de lien avec le monde pro c’est à dire plutôt des personnes qui présentent des choses sur les technos devops. J’ai pris contact avec plusieurs sociétés que je connais via mon réseau (rancher, haproxy, traefik…). Le but étant pour elles de nous montrer des choses simples faites à partir de leurs outils et pour les spectateurs de pouvoir poser des questions sur des cas d’usages.

Je trouve cet équilibre assez sympathique et plus en lien avec l’esprit des tutos.

En outre, je pense continuer à faire un concours pour chaque liveki qui permettra aux gagnants d’avoir des goodies de formes diverses (peut être même des goodies xavki).

Structurer la vision globale

Depuis plusieurs mois, je trouve que Youtube ne permet pas de voir efficacement l’intégralité de la chaine. C’est pourquoi, je me suis mis à faire unpetit script python pour collecter la liste des vidéos et la remettre en forme au format markdown. Le résultat est présent sur deux dépôt au choix :

Je commence aussi à faire un peu de selenium pour permettre d’avoir un autre regard sur la chaine avec des stats sympas comme le top de commentateurs etc.

La mise en place des membres permet aussi de trouver un équilibre entre une publication qui ne spam pas et permettre de contribuer à la chaine. Ainsi, les membres peuvent avoir accès aux vidéos sans délai contrairement aux abonnés qui doivent attendre leur publication. Cela va permettre de rester sur un rythme de 3 vidéos par semaine ce qui est déjà assez dense.

Les sujets à venir ?

Une petite liste des choses que j’ai en tête pour la suite :

  • terraform plus que tout
  • packer
  • imbrication packer > terraform > ansible
  • refaire la playlist ansible
  • des tutoriels sur selenium
  • mise en place d’une infra complète de microservices de démonstration avec des tutoriels pour apprendre à faire le tout (code et infra)
  • kafka pour les débutant
  • nginx l’inévitable
  • traefik 2
  • kong peut être…

Voilà j’espère que vous prenez tous du plaisir à regarder la chaine. A très bientôt !!!

Trop de technos pour être partout…

Aujourd’hui, c’est très compliqué de suivre les technologies. D’une part, certaines d’entre elles sont en pleine explosion (cloud, kubernetes). D’autre part, il y en a de tous les côtés. Difficile de savoir parfois d’ailleurs laquelle sera celle qui sera adoptée par tous demain.

Et ce blog est difficile à maintenir pour moi. Je ne parviens jamais à y mettre des tutos et autres notes que j’aimerais voir dedans.

Ainsi, je me suis demandé si je ne devais pas le réorienté. Et finalement c’est peut être la solution. En effet, la chaine youtube Xavki marche bien et finalement je m’y retrouve suffisament pour avoir besoin d’en rajouter à côté.

Du coup, je vais réorienter le blog vers… le blog de la chaine Xavki. A savoir les sujets qui me trottent dans la tête, les évolutions, mes interrogations etc… Bref plus les dessous de la chaine. Cela me semble sympa aussi de partager dessus.

Et c’est un bon début pour commencer d’expliquer pourquoi je propose à des personnes autres que moi d’intervenir sur la chaine. A cela plusieurs raisons :

  • je ne peux pas couvrir tous les sujets : c’est un fait et je dois l’intégrer dans ma petit tête lol
  • certains sujets ont besoin d’experts
  • plus d’auteurs = plus de diversité = élargir ses points de vues
  • plus d’auteurs = plus de contenus
  • faire connaître d’autres personnes par l’influence de la chaine

Ouverture des festivités donc avec l’interviex de Kevin Chevreuil le concepteur/créateur de Kaisen Linux, un OS basé sur debian.

Dans cette vidéo, vous pourrez découvrir comment Kevin a eu l’idée de créer son OS et vous le verrez c’est un vrai passionné, c’est le moins que l’on puisse dire.

Bien sûr nous reverrons Kevin pour de nombreuses vidéos.