Archives de l’auteur : xavki

Tutorials pour débuter avec Kubernetes

Suivre les technologies du moment, c’est souvent le but recherché par tous les sysadmin et devops. Et cela n’est pas facile avec la démultiplication des technologies de puis l’arrivée du cloud, des conteneurs et de l’infrastructure as code. Une évolution inévitable à l’heure de l’industrialisation de l’informatique, secteur encore jeune qui a besoin d’évoluer.

Kubernetes est pleinement dans cette mouvance. D’ailleurs, le nombre de technologies ou d’outils rattachés à celui est presque affolant. Tous les jours de nouveaux outils, régulièrement de nouveaux concepts émergent également. Bref on en a jamais fini avec kubernetes. D’ailleurs l’une des forces d’un bon devops, c’est de savoir aussi attendre et faire le bon choix parmi cette forêt d’outils qui demain n’existeront plus pour certains.

Apprendre par le bon bout…

K8S pour les intimes commence déjà par docker et les principes de conteneurisation. Je vous invite à découvrir docker via la chaine xavki si vous le souhaitez. Certes kubernetes tente de se détacher de ce « conteneur runtime » mais néanmoins pour apprendre se focaliser sur docker est plutôt une bonne approche.

Mais k8s se comprend avant de s’apprendre avec de nombreux concepts et définitions. Il faut imaginer déjà que k8s est un orchestrateur de conteneurs mais c’est aussi une grosse couche logique sur les conteneurs, leurs réseaux, le stockage et le dns qui va avec.

Dans cette introduction, si vous avez du mal à imaginer kubernetes, je vous propose de vous le présenter avec simplicité.

Kubernetes vient d’ailleurs du grec et signifie timonier. On peut le comprendre car il est à la tête de ce magistral porte conteneurs.

Avec kub vous allez pouvoir bénéficier de nombreuses fonctions avancées et rares, que ne fournissent pas forcément les autres orchestrateurs de conteneurs :

  • autoguérisson
  • autoscaling
  • versionning
  • rolling update
  • sécurisation des communication entre les conteneurs par différentes couches
  • gestion de la persistence de la donnée…

Mais attention ces grands pouvoirs nécessitent une grande responsabilité comme on dit. La responsabilité de celui qui manage le paquebot. Le moindre grain de sable dans cette horlogerie et c’est le trou noir compte tenu du rôle central de l’outil. Courage donc aux sysadmins et aux devops face à ce challenge.

C’est aussi pour cela que beaucoup de choix s’orientent vers des solutions plus ou moins managés :

  • les solutions cloud : GKE, EKS…
  • les managers : rancher…

Bref c’est une aventure et on peut même simplifier en indiquant que c’est un vrai outil de virtualisation avec les responsabilités qui vont avec (et les ressources et le temps).

On ne va pas vers kubernetes pour se faire plaisir, il faut y trouver un réel intérêt sur de nombreux facteurs. On ne le fait pas pour faire comme les autres ou parce que c’est la techno du moment.

De nouvelles notions et définitions dans kubernetes

Kubernetes fait partie des technologies embarquant le plus de concepts je trouve. Intellectuellement c’est très intéressant mais c’est aussi une charge.

En voici quelques unes :

Le Pod

Inévitable, il peut regrouper un ou plusieurs conteneurs. C’est la couche logique par excellence qui va permettre une total abstraction avec l’échelon inférieur le conteneur.

Le pod contient les applicatifs, il peut être plus ou moins éphémères suivant sont types. Vous pouvez associer avec lui un applicatif et une tâche ponctuelle nécessaire pour son installation. Il peut être scallé up ou down pour soutenir la charge etc…

Les services

On pourrait les rapprocher à l’exposition des pods mais en même temps il joue une sorte de fonction de dns. L’idée est de sécuriser et permettre l’accès aux pods ayant la même fonction.

Avec eux vous pourrez en quelque sorte exposer vos conteneurs ou à l’opposé les barricader. Si les pods d’un même applicatif sont distribués sur différents noeuds, il aura la charge de fournir comment accéder à ces pods (ip port…). Il permet également de faire du dns au sein du cluster kub.

Le replicaset

Résumons-le simplement à la gestion du nombre de pods.

Le deployment

Un autre échelon très important qui englobe les replicasets et les pods. Il permet notamment de gérer la santé des pods et leur scaling suivant certaines règles. Un deployment va permettre de créer des pods suivant un template de pods. Idéal pour l’instanciation.

Les statefulsets

On peut les résumer à des deployments avec les mêmes fonctions auxquels on ajouter des facilités pour gérer la persistence de la data qui est attachée aux pods. Idéal pour les bases de données essentiellement.

Bon courage à tous mais le plaisir est au rendez-vous si vous ne brûlez pas les étapes.

Débuter avec Prometheus et se former

Le monitoring est un domaine qui existe depuis de nombreuses années pour gérer les infrastructures. Il existait avant le web mais son intérêt c’est accru d’année en année. La tolérance aux pannes étant devenue de plus en plus faible, les outils de monitoring ont évolué également avec le temps.

L’arrivée des infrastructure à base de microservices et la nécessaité de baser le monitoring sur de plus en plus d’éléments « métiers » a aussi joué ces dernières années. Si le monitoring système était bien présent auparavant, la partie applicative est devenu un enjeu important pour toute société ayant le moindre site web ou même fournissant des services en interne.

Parfois, le monitoring système est même réduit au minimum au bénéfice du service rendu final.

Vous pouvez retrouver mes prises de notes sur Prometheus en plus des vidéos de la chaine sur ce dépôt gitlab.

Prometheus et Grafana, la stack du moment

La collecte et la mise en valeur de métriques passent souvent par la combinaison de plusieurs outils. Je vous propose de découvrir aujourd’hui une partie de la stack prometheus/grafana qui est l’une des plus à la mode en ce moment.

Pourquoi ? en grande partie par sa simplicité de mise en place et son déploiement. Prometheus constitue la base de données (timeseries). Il stocke les données sur de courtes périodes (son point faible reste la rétention sur des volumes importants). Attention, il reste très performant sur de longues périodes si vous ne collectez pas trop de métriques.

Sa force ? être capable d’aller chercher lui-même l’information sur les serveurs. Alors que de nombreux autres outils fonctionnent avec des agents qui envoient l’information vers la base centralisée, Prometheus va chercher l’information.

Attention, néanmoins, vous devez mettre en place ce que l’on appelle des exporters. Il s’agit de petits binaires, souvent développés en GO (mais vous pouvez aussi développer el votre en bash ou en python). Ces derniers affichent les informations sur une route à savoir un port et un path de la machine (par défaut on utilise couramment la route /mettrics). On parle là des données où les outils ne mettent pas déjà à disposition une route pour prometheus.

Car de nombreux outils mettent à dispositions des options pour mettre en place cette route. Les données, dans tous les cas, sont affichées au format openmetrics. Un standard, facile à scraper et à utiliser.

Prometheus est aussi souvent utiliser pour ses capacités d’autodiscovery notamment dans kubernetes ou docker mais pas seulement (consul, aws, dns…).

Comment installer Prometheus ?

Bien sûr vous pouvez retrouver la documentation de prometheus ici. Cette timeseries database est tellement courante que de nombreuses distributions vous la fournissent dans les dépôts standards. Par exemple sur les OS à base de Debian :

sudo apt-get install prometheus

Sinon, bien sûr, vous pouvez l’installer facilement avec l’aide de docker pour la lancer sous forme de conteneur :

docker run -d --name prometheus \
-v $PWD/etc/:/etc/prometheus/ \
 -v $PWD/data/:/prometheus/ \
-p 9090:9090 quay.io/prometheus/prometheus:v2.0.0

Attention néanmoins à ne pas oublier qu’il s’agit d’une application stateful et que du coup vous devrez stocker des éléments en dehors du conteneur en montant un volume. Ainsi comme dans l’exemple précédent, je vous invite à monter un volume pour la configuration et un autre pour les datas. Stocker sa configuration en dehors du conteneur vous permettra de facilement relancer un conteneur similaire avec les mêmes options.

Quelques défintions pour cette TSDB particulière

Comme tout outil, Prometheus dispose de son propre langage et ses propres notions et définitions.

Sa configuration est stockée dans un fichier (par défaut prometheus.yml) au format yaml.

./prometheus --config.file=prometheus.yml

Dans ce fichier de configuration on retrouver :

  • Une partie « global » qui définit des settings par défaut par exemple :
    • scrape_interval : fréquence de collecte des métriques
    • evaluation_interval : fréquence de check des alertes
    • scrape_timeout : durée d’attente des métriques (temps de réponse de la route)
  • rule files :volet relatif à la configuration des alertes
  • scrape config : éléments relatifs aux routes mise à disposition de prometheus :
    • dynamiques ou non
    • ip/url et port
    • nom du job de scrape

Et toutes les données sont donc exportées au format openmetrics :

up{instance="192.168.62.3:9100",job="node_exporter",service="myapp"} 1

Dans cet exemple, « up » est une métrique (notamment par défaut la route prometheus), 1 sa valeur.

On découvre également ce que l’on appelle des labels comme par exemple : instance, job, service. Mais bien sûr vous pouvez aussi créer vos propres labels.

L’outil n’est pas une simple database car il récupère lui-même ses informations et met également à votre disposition une interface graphique. Par défaut, affichée sur le port 9090, elle affiche :

  • la configuration pris en compte sur le moment
  • les routes collectées
  • la possibilié de requêter les données en utilisant le langage PromQL (prometheus query language)
  • la possibilité de réaliser des graphiques (un peu rudimentaires que l’on remplacera souvent par grafana).

Node Exporter : le plus courant

On l’a dit, notre TSDB va chercher elle même ses métriques. Soit sur des outils intégrés aux applicatifs soit par le biais d’exporter. Ces outils tournent au niveau local, collecte la données et l’expose sur un port et une route (souvent /metrics par défaut).

Node exporter est l’un des plus commun. en effet, il permet de collecter des informations de bases sur le système : les disques, leurs volumes, le réseau, les process…

Pour l’installer vous devez faire votre choix :

  • par un paquet de votre distribution
  • par un conteneur docker spécifique
  • par le binaire.

Ainsi sous debian vous pouvez l’installer avec :

sudo apt-get install prometheus-node-exporter

Avec docker :

docker run -d \
  --net="host" \
  --pid="host" \
  -v "/:/host:ro,rslave" \
  -p 9100:9100 \
  --name node_exporter \
  quay.io/prometheus/node-exporter \
  --path.rootfs=/host

Et pour le faire avec le binairere source :

  • récupérez le binaire et préparez les répertoires et user
sudo useradd -rs /bin/false node_exporter
https://prometheus.io/download/#node_exporter
wget https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
tar -xvzf node_exporter-0.18.1.linux-amd64.tar.gz
mv node_exporter-0.18.1.linux-amd64/node_exporter /usr/local/bin/
chown node_exporter:node_exporter /usr/local/bin/node_exporter
  • créez le service systemd pour lancer le processus et le gérer
cat /etc/systemd/system/node-exporter.service
[Unit]
Description=Node Exporter
After=network-online.target
[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter
[Install]
WantedBy=multi-user.target
  • puis activez le service systemd
systemctl daemon-reload
systemctl enable node_exporter
systemctl start node_exporter

Maintenant vous disposez de la route <ip>:9100/metrics sur la machine sur laquelle vous avez installé node exporter.

Il ne vous reste plus qu’à dire à prometheus de venir récupérer cette source d’informations. Bien sûr la machine prometheus doit pouvoir accéder à la route de node exporter. Ajoutez alors à votre configuration prometheus les lignes suivantes :

  - job_name: node-exporter
    static_configs:
      - targets: ['l<ip>:9100']

Labels et Filtres

Les labels et les filtres sont le quotidien de la personne qui utilise prometheus à travers les requêtes PromQL.

Les labels sont assimilables à des tags. C’est à dire une information que l’on va ajouter au fur et à mesure des scrape pour nous aider à isoler certaines données et les travailler plus facilement.

Ainsi, pour un scrape donnée (appelé aussi job), vous allez pouvoir ajouter un label nommé « environnement » :

  - job_name: node_exporter
      static_configs:
      - targets: [ '192.168.1.1:9100' ]
        labels:
          environnement: developpement

Dans le cas, d’utilisation d’autodiscovery, Prometheus autodécouvre des instances à monitorer et leurs informations (aws ec2 on retrouve les tags etc, les noms de services de consul etc). Et vous allez pouvoir ajouter ces informations complémentaires du discovery à votre liste de labels en utilisant le relabel.

scrape_configs:
  - job_name: Consul
    consul_sd_configs:
      - server: '192.168.57.10:8500'
        datacenter: 'mydc'
    relabel_configs:
      - source_labels: [__meta_consul_service]
        target_label: job

Dans cet exemple, l’information nom de service de consul vient compléter le label nommé « job ».

Les filtres permettent d’affiner les requêtes promql et limiter les résultats. Par exemple pour ne prendre en compte que le device eth0 :

node_network_receive_bytes_total{device="eth0"}

Le filtering se fait donc dans les labels mentionnés entre les accolades et la valeur mentionnées.

On peut également utiliser les regex pour plus de fléxibilités :

node_network_receive_bytes_total{device=~"eth.+"}
node_network_receive_bytes_total{device=~"eth0|lo"}

Voici donc la fin de ces premiers pas avec prometheus. Totu devops doit avoir quelques notions dans ce domaine. Je vous propose de retrouver les tutorials prometheus ici.

Top5 des vidéos devops en août 2020 !!!

La chaine youtube xavki marche bien et c’est surtout grâce à vous. Je n’ai pas trop chomé cet été finalement moi qui pensais faire une pause. Et comme je suis un addict dès que j’ai quelque chose qui me branche en finalement je n’aurais pas fait de pause.

Mon plaisir c’est de vous voir venir et revenir sur cette chaine. Et pour cela vous proposer du contenu intéressant. J’évite de faire le buzz si ce n’est de prendre des technologies à la mode dans le monde du devops.

Les dernières technologies auront été : kvm, traefik, ELK, terraform, prometheus et grafana… et j’en ai pas fini avec elles.

Alors ce top 10 de la chaine xavki ? car je suis bien incapable de dresser un top 10 à l’échelle du web il y a tellement de choix et de bons contenus.

Voici donc les vidéos les plus consultées pour le mois d’août et je vous en dis mon ressenti.

1. Docker : Premier Pas

C’est la vidéo la plus vu mais pour autant j’en suis d’autant plus déçu. Paradoxal non ? en effet, elle fait partie des premières vidéos et son son est très mauvais. Mon approche pédagogique n’est pas encore là non plus . Alors pourquoi elle marche ? docker est recherché et les tutorials en français introduisant cette technologie n’était pas si courante à l’époque. Du coup elle s’est faite sa place avec ses likes.

2. Traefik, l’introduction

Autant l’introduction à docker m’a pas forcément apporté un énorme plaisir, autant que ce genre de vidéo marche me fait plaisir. Pourquoi ? une technologie française qui marche fort en ce moment, un besoin d’en parler et le réelle sentiment que vous recherchez ce genre d’informations.

Traefik est une technologie que j’adore en ce moment pour son dynamisme et ce qu’il l’entoure. D’ailleurs je crois que je suis traefik ambassador même si je n’en ai pas réellement le niveau.

3. Kubernetes, présentation des tutorials de la chaine

Cette playlist fait partie de mes tops formations. Je peux réellement avoir le sentiment de vous faire converger vers des niveaux un peu plus pointus à chauqe fois et c’est quelque chose que j’apprécie. Bien sûr Kubernetes est à la mode et ça aide mais présenter la simple liste des vidéos à venir n’est pas forcément quelque chose de recherché. Mais c’est déjà un pas vers la formation. Comprendre et découvrir un plan de formation c’ets déjà se former à mon sens.

4. Gitlab, oui c’est recherché

Dans cette vidéo j’ai tenté de survoler et présenter les opportunités apportées par Gitlab. Un formidable outil qui a tendance à créer une forte dépendance. Petite société qui a su se faire une place parmi les très grand parmi les sociétés côtées boursières américaines. La petite société a bien évoluée autour de l’automatisation du déploiement de votre code applicatif mais pas forcément. Ils ont su intégré des technos tendances et inévitables comme : grafana, terraform, kubernetes???

5. Jenkins peut être ce qui me représente le plus…

Une vidéo simple, un peu sans prétention qui vous présente jenkins. Jenkins est un acteur historique dans le domaine du scheduling. Malgré son ancienneté, il est encore présent parmis les leaders. Et surtout sa communauté abondante rend cet outil ultra-polyvalent dans des domaines variés : déploiement, datas, infrastructure…

J’aime vraiment beaucoup ce côté polyvalent et discret mais toujours présent ce qui en démontre sa robustesse et son efficacité.

A vous de me dire à travers les commentaires dans les vidéos, les pouces bleus ou rouges, ce que vous pensez de tout cela.

Même si j’ai des regrets sur les vidéos réalisées au début de la chaine xavki, il faut l’accepter. On vient d’où l’on vient et l’on évolue. D’ailleurs il me semble plus intéressant d’évoluer et de comprendre ce process d’évolution que de déjà tout connaître sans évoluer.

Allé je vous laisse apprécier ou pas tout cela. Vous abonner ou non… voir même devenir membre VIP. A vous de voir appréciez, votre liberté de choix.

Ne pas s’éparpiller sur les sujets et les technos, mais bon…

La fin de la période des vacances d’été arrive, parfois tristement pour certains mais c’est ainsi il faut retourner au boulot. Je n’ai pas pris de vacances et cela s’en est peut être ressenti sur la chaine Xavki.

Du coup, j’ai été pas mal centré sur la chaine durant cete période. Parfois trop certainement avec les débordements que cela donne mais qu’il faut maitriser.

Au début j’ai tenté de maîtriser mon programme de tutorials pour éviter de me disperser. Mais finalement je pense que je me suis un peu étallé. En effet, je me suis dit que pour un devops toucher un peu à tout ce qui m’intéresse, reste nécessaire.

Les tutorials ELK où comment éplucher une documentation ? lol

Bon j’ai tout de même fait un bon focus sur ELK avec déjà plus de 90 vidéos. Non pas que j’ai réalisé des trucs compliqués mais j’ai tenté d’être un peu exhaustifs sur les possibilités d’utilisations de la stack ELK.

Dans le cadre de la réalisation de ces tutos, j’ai pu me rendre compte à quel point, j’avais une méconnaissance de cet outil et des opportunités qu’il propose. En effet, entre les beats, elasticsearch, logstash, kibana… il est possible de réaliser de très nombreuses choses.

On limite souvent cette stack à simplement lui injecter des logs mais elle va bien au-delà.

On s’en sert parfois comme stockage de documents et là encore, elle permet bien plus. Logstash à lui seul est un réel ETL (Extract Transfert and Load). Il permet de gérer de nombreux traitements de données, voir même d’extraire d’une base sql vers du nosql, faire intervenir du kafka etc.

Bref j’ai bien apprécié. J’ai pu aussi découvrir opendistro la version opensource d’une partie de stack et mis à disposition par AWS. Très kool.

Terraform et KVM en support

Terraform est un sujet qui me tient à coeur. En effet j’estime que cet outil signé hashicorp est nécessaire dans la caisse à outils de tout bon devops. Mieux il est souhaitable de maitriser la stack d’automatisation et d’orchestration : packer, ansible, terraform.

Et pour découvrir terrafomr je me suis dit que tout le monde ne souhaitait pas forcément mettre la main dans le cloud directement. Du coup j’ai regardé les providers pour tenter de trouver de meilleurs points d’entrées permettant de faire la passerelle avec des travaux déjà proposés sur la chaine.

Ainsi, j’ai fait plusieurs tutos sur les providers docker et kubernetes avec de la mise en application autour de wordpress. Et maintenant, je creuse autour de KVM, avec l’occasion aussi de faire des vidéos autour de KVM. Un bon moyen de se passer de virtualbox et vagrant pour pratiquer encore plus du terraform.

Et d’autres sujets pour se mettre en ordre

D’autres sujets sont venus dans le même temps.

Traefik, depuis la version 2, le reverse proxy français montre des choses très intéressantes avec des configurations plus dynamiques. Et donc après avoir examiné un peu haproxy, je me suis dit il va falloir initier cette playlist pour y revenir plus tard sur les sujets plus profonds comme l’ingress dans kubernetes etc.

Loki me tentait bien à force d’avoir épluché ELK, je me demandais en quoi ce projet de grafana labs était différent. Donc j’ai fait quelques tutorials loki pour découvrir l’outils. J’en retiens sa simplicité et son intégration à grafana pour centraliser la supervision globale : monitoring, logging et tracing.

Et un peu de cassandra. Découvrir cassandra c’est ouvrir une boite remplie de concepts très intéressants, mettant en évidence la disctinction entre sql et nosql.

Et le diverstissement autour de vagrant

Pour gagner du temps et réaliser des tests, des tutos, des démos, j’utilise la plupart du temps vagrant. ET à force de celà je me suis dit l’efficacité de notre apprentissage repose dans une mise en situation rapide via une VM ou une infrastructure rapidement à disposition.

Pour mettre cela en évidence, je me suis dit et si je proposais à tout le monde de découvrir vagrant tout en lançant un cluster kubernetes avec un peu d’automatisation via kubespray. Un moyen rapide et fiable pour avoir un lcuster kubernetes sous la main notamment pour faire des tests d’outils liés à k8s.

Et j’y ai ajouté un wordpress avec du nfs pour compléter ce cluster et faire en sorte d’avoir un applicatif dans ce cluster fonctionnel.

Les chiffres dans tout ça ?

La chaîne marche toujours très bien. Nous sommes déjà à plus de 13000 abonnés, 200 membres youtube, plus de 800 vidéos.

Dans quelques jours, le nombre de vues franchira les 800k, un grand pas avant le million que j’ai vraiment hâte de franchir.

Et tout les retours sont de très forts encouragements à poursuivre ces efforts.

Bref un grand merci pour m’aider dans cette aventure!!!