Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

Technologie

Prismo, le Reddit du fediverse

Rédigé par dada / 13 novembre 2018 / 6 commentaires


Je suis accroc à tout ce qui tourne autour de la fédération. Vraiment. Mon compte Mastodon tourne à plein régime et mon compte Pixelfed aussi, même s'il est en attente de réelle fédération, qui arrive.
Bref.
Dans la famille, nous pouvons maintenant ajouter un nouveau : Prismo !

C'est quoi ?

Prismo, c'est une sorte de Reddit, mais un Reddit fédéré, ou encore un Journal du Hacker. Il permet de partager des liens, d'en avoir un aperçu, de commenter ou encore de laisser la communauté en évaluer la pertinence avec des +1 ou des -1 et d'ainsi les faire apparaître sur la page d'accueil, bien en avant.

En images :


Vous avez ci-dessus la page d'accueil avec l'accès aux Stories, aux Comments et la liste des tags du moment. La page "Hot" permet d'accéder aux liens qui viennent d'être balancés, triés uniquement par date d'ajout.


Ci-dessus, un lien balancé par Valere. Même si l'article est super intéressant, ce sont des commentaires dont nous allons parler. Mon commentaire vient de mon compte Mastodon tout comme la réponse de Valere :


On se retrouve bien dans un cas typique de fédération ! Quand un lien est donné à manger à Prismo, celui-ci est directement envoyé dans notre univers fédéré, Mastodon en l’occurrence. Les interactions sont transmises dans les deux sens et tout le monde peut participer. C'est beau. Et vous avez des notifications pour vous alerter.

Prismo étant encore en développement, tout est encore possible. Dans les tuyaux, on peut déjà espérer voir rapidement arriver la fédération entre instances pour mettre en commun leurs communautés.
J'attends aussi l'arrivée d'un flux RSS, histoire de voir passer les nouvelles sur Mastodon mais aussi dans mon FreshRSS.
Une application Android/iOS ? Si des développeurs se motivent pour nous pondre ça, il y en aura. En attendant, la version mobile fonctionne bien.

L'utilité

Dans mon cas, je ne sais pas encore ce que je vais faire de ce nouvel outil. Je sais que je balance une quantité non négligeable de liens vers des articles autour de la politique internationale, du droit ou des nouvelles technologies. C'est un peu le cœur de métier de mon compte Mastodon. Est-ce que je vais déplacer tout ça dans une instance Prismo ? Je ne sais pas mais je vais y penser.

Par contre, si vous êtes un adepte de la veille technologiques et que vous n'avez pas vraiment d'intérêt à maintenir un compte Mastodon, vous êtes la cible privilégiée du petit nouveau. Il pourrait remplacer votre Shaarli ou vos billets de blog regroupant vos lectures de la semaine.

Où tester ?

Si vous êtes tentés par l'expérience, foncez faire un compte chez Hostux.news ! L'instance est gérée par Valere, ou Valere, ou Valere ou encore Valere.



On vous y attend pour découvrir ce que vous avez à nous faire lire !

Et si on mettait PluXml dans un cluster k8s ?

Rédigé par dada / 11 novembre 2018 / Aucun commentaire



L'idée est saugrenue mais c'est exactement ce que j'ai fait ces derniers temps. Non sans souffrir, j'ai réussi à m'en sortir. Au programme : créer un conteneur qui va bien pour PluXml, mettre en place un déploiement pour le faire tourner dans k8s et l'utilisation de PersistentVolume.

Notez que je découvre toujours cet univers et que ce qui est présenté dans ce billet ne reflète que mes avancées.

La création du conteneur

Introduction

J'ai déjà pondu quelques conteneurs, principalement des exporters Prometheus en Python qui vont récupérer les statistiques de Mastodon et Pixelfed pour les afficher dans des dashboards Grafana (combo mots clés pour des recruteurs).

Pour PluXml, c'est différent. Il nous faut un conteneur avec :
- Les sources du CMS
- Du php7 et ses dépendances
- Un serveur web

Voyons comment y arriver en s'inspirant de ce qui a été fait pour Wordpress.

Le Dockerfile

C'est quoi ? C'est le fichier de configuration qui va nous permettre de créer le conteneur. En gros, les sources du conteneur.
FROM php:7.0-apache

WORKDIR /var/www/html

RUN apt update
RUN apt install -y wget unzip
RUN wget https://git.dadall.info/dada/pluxml/raw/master/pluxml-latest.zip
RUN mv pluxml-latest.zip /usr/src/

#VOLUME
VOLUME /var/www/html

RUN a2enmod rewrite
RUN service apache2 restart
RUN apt-get update && apt-get install -y \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libpng-dev \
    && docker-php-ext-install -j$(nproc) iconv \
    && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
    && docker-php-ext-install -j$(nproc) gd

# Expose
EXPOSE 80

COPY entrypoint.sh /usr/local/bin/

ENTRYPOINT ["entrypoint.sh"]
CMD ["apache2-foreground"]

Comprendre le Dockerfile

FROM : C'est ici qu'on indique clairement la solution de facilité. Pour ne pas se battre avec l'installation d'Apache et de PHP7, j'indique au Dockerfile de prendre comme base un conteneur ayant déjà PHP7, Apache et Debian configurés.

WORKDIR : Ici, on indique où vont s’exécuter les commandes qui vont suivre. Ce n'est pas pertinent dans mon cas, mais bon.

VOLUME : C'est une sorte de point de montage entre le conteneur et son hôte.

RUN : Simple : les commandes que nous allons exécuter à la création du conteneur. Ici, on va récupérer les sources de PluXml qui sont hébergées dans mon Gitlab perso, les extraire et les préparer. On va aussi activer le module Apache nécessaire au bon fonctionnement du CMS et installer le module PHP-GD, lui aussi obligatoire.

EXPOSE : C'est le port qui sera ouvert vers l'extérieur. On va taper sur le port 80 pour accéder au contenu du conteneur.

COPY : Commande permettant de copier des fichiers de votre ordinateur à l'intérieur du conteneur. ici, le script entrypoint.

CMD : La commande à exécuter une fois que tout est terminé.

Note : Oui, je sais, il y a des choses inutiles. C'est un exemple.

Entrypoint ?

Le script :
#!/bin/bash

if [ ! -e index.php ]; then
    unzip /usr/src/pluxml-latest.zip -d /var/www/html/
    mv /var/www/html/PluXml/* /var/www/html
    rm -rf /var/www/html/PluXml
    chown -R www-data: /var/www/html
fi

exec "$@"

Comprendre le entrypoint

On est face à un script bash tout simple mais il demande un peu d'explication quand même.
Nous voulons un conteneur mettant à disposition les sources de notre CMS adoré ET qui stockera les articles, commentaires, images, etc, loin de ce-dit conteneur. Sans ça, une fois le conteneur mort, les données mourront avec lui. Ces données, pour faire simple, seront dans le fameux VOLUME cité un peu plus haut.

Au sujet des sources, si notre Dockerfile s'amusait à les mettre directement dans /var/www/html, comme la norme le voudrait, elles disparaîtraient dans k8s.
Pourquoi ? Parce que ce VOLUME sera géré par k8s lui-même et sera vide :
- Dockerfile dépose les sources dans le conteneur
- k8s charge le conteneur
- k8s monte son persistentVolume dans /var/www/html
- Les sources du conteneur disparaissent. Échec.

Si vous regardez bien le Dockerfile et ses incroyablement nombreuses lignes de code : il déplace les sources dans /usr/src, bien au chaud, à l’abri du problème. À la création du conteneur, dans k8s, le script regardera s'il existe un fichier index.php (issu des sources du PluXml) et, le cas échéant, copiera les fichiers manquants dans /var/www/html qui sera un PersistentVolume dans k8s ! Et c'est bien ce que nous voulons !

La création de l'image

Pour construire une image Docker, placez-vous dans les répertoires où vous avez déposé les 2 fichiers détaillés précédemment et : 
docker build -t pluxml-5.6 .
Vous allez voir des lignes s'afficher dans tous les sens : pas de panique, c'est normal. Une fois votre terminal calmé :
Successfully built d554d0753425
Successfully tagged pluxml-5.6:latest
Gagné !

Téléverser l'image dans un dépôt

On ne va pas s'attarder là-dessus. Sachez juste que pour que k8s se serve de l'image, il faut qu'elle soit téléchargeable. J'ai poussé mon image dans le Docker Hub, dans un dépôt public. Vous allez pouvoir jouer avec sans vous prendre la tête.

Préparer Kubernetes

Postulats de base :
- Vous avez configuré Rook.
- Vous avez dégagé ce qui concerne les pods Wordpress/Mysql.

Le deployment & co

On va reprendre le travail vu ces derniers jours et créer des YAML pour notre conteneur !
dada@k8smaster:~/pluxml$ cat pluxml.yaml 
apiVersion: v1
kind: Service
metadata:
  name: pluxml
  labels:
    app: pluxml
spec:
  ports:
  - port: 80
  selector:
    app: pluxml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: plx-pv-claim
  labels:
    app: pluxml
spec:
  storageClassName: rook-ceph-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: pluxml
  labels:
    app: pluxml
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: pluxml
    spec:
      containers:
      - image: dadall/pluxml-5.6:latest
        imagePullPolicy: "Always"
        name: pluxml
        ports:
        - containerPort: 80
          name: pluxml
        volumeMounts:
        - name: pluxml-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: pluxml-persistent-storage
        persistentVolumeClaim:
          claimName: plx-pv-claim
Vous remarquez que je ne me suis pas foulé : c'est le YAML de Wordpress légèrement retravaillé. On y trouve le nom de mon image dans le Deployment et un Service pluxml.

L'ingress 

dada@k8smaster:~/pluxml$ cat pluxml-ingress.yaml 
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  name: pluxml-ingress
spec:
 backend:
   serviceName: pluxml
   servicePort: 80
Là aussi, simple : l'ingress qui s'attache à l'application pluxml.

Vous créez tout ça :
dada@k8smaster:~/pluxml$ kubectl create -f pluxml.yaml
dada@k8smaster:~/pluxml$ kubectl create -f pluxml-ingress.yaml
Si tout va bien, vous avez un pod PluXml qui vient d'apparaitre et qui est joignable !

Le pod :
dada@k8smaster:~/pluxml$ kubectl get pods --all-namespaces -o wide | grep plux
default            pluxml-686f7d486-7p5sq                                    1/1     Running     0          82m     10.244.2.164   k8snode2    <none>
Le service :
dada@k8smaster:~/pluxml$ kubectl describe svc pluxml
Name:              pluxml
Namespace:         default
Labels:            app=pluxml
Annotations:       <none>
Selector:          app=pluxml
Type:              ClusterIP
IP:                10.100.177.201
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.1.31:80
Session Affinity:  None
Events:            <none>
L'Ingress :
dada@k8smaster:~/pluxml$ kubectl describe ingress pluxml
Name:             pluxml-ingress
Namespace:        default
Address:          
Default backend:  pluxml:80 (10.244.1.31:80,10.244.2.164:80)
Rules:
  Host  Path  Backends
  ----  ----  --------
  *     *     pluxml:80 (10.244.1.31:80,10.244.2.164:80)
Annotations:
  kubernetes.io/ingress.class:  nginx
Events:                         <none>

Coucou PluXml !

Welcome to Nginx, puis Wordpress

Rédigé par dada / 09 novembre 2018 / Aucun commentaire

Perdu ?

On y arrive. Après des heures d'attente, de commandes bizarres, de pods dans tous les sens, je vais enfin vous montrer comment mettre en place un Wordpress, sa base de données et y accéder depuis le navigateur !

Wordpress

Il existe une configuration simple pour avoir un Wordpress fonctionnel : ne nous privons pas !

La partie MySQL

Son fichier de configuration :
apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim2
  labels:
    app: wordpress
spec:
  storageClassName: rook-ceph-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: changeme
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim2
Vous y trouverez les volumes persistant pour Rook, le point de montage, la configuration du port MySQL, le mot de passe, etc. Vous avez le temps de lire tout ça.

On lance la création du conteneur :
dada@k8smaster:~$ kubectl create -f mysql.yaml
Et le résultat :
default            wordpress-mysql-75477bf794-89mzw                          1/1     Running     1          5h38m   10.244.2.50    k8snode2    <none>

On peut enchaîner avec la suite. C'est vrai qu'une BDD de Wordpress sans le CMS pour l'utiliser, c'est moyen.

La partie PHP

Notez que je parle de la partie "PHP", mais il n'y a pas que PHP. Il me fallait un titre, alors voilà.

Cette partie, je l'ai modifié par rapport à ce que vous trouverez dans les documentations officielles.
apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
  - port: 80
  selector:
    app: wordpress
    tier: frontend
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pv-claim
  labels:
    app: wordpress
spec:
  storageClassName: rook-ceph-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
      - image: wordpress:4.6.1-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          value: changeme
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
Vous pouvez lancer tout ça :
 kubectl create -f wordpress.yaml
Le pod wordpress devrait apparaître: 
default            wordpress-796698694f-sxbhb                                1/1     Running     1          3h35m   10.244.2.51    k8snode2    <none>

Ce qu'il faut saisir

La présence des services de Wordpress :
dada@k8smaster:~/$ kubectl get services 
NAME                                     TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
kubernetes                               ClusterIP      10.96.0.1        <none>         443/TCP                      4d8h
my-nginx-nginx-ingress-controller        LoadBalancer   10.100.45.147    192.168.0.50   80:32462/TCP,443:30337/TCP   3d5h
my-nginx-nginx-ingress-default-backend   ClusterIP      10.109.228.138   <none>         80/TCP                       3d5h
wordpress                                ClusterIP      10.102.55.203    <none>         80/TCP                       6m3s
wordpress-mysql                          ClusterIP      None             <none>         3306/TCP                     6h33m
La configuration du service wordpress-mysql, on ne va pas s'y attarder. Ça marche tout seul.
Le truc chouette, c'est la configuration du service wordpress.
dada@k8smaster:~/$ kubectl describe service wordpress
Name:              wordpress
Namespace:         default
Labels:            app=wordpress
Annotations:       <none>
Selector:          app=wordpress,tier=frontend
Type:              ClusterIP
IP:                10.102.55.203
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.2.61:80
Session Affinity:  None
Events:            <none>
On y retrouve les informations qu'il nous faut et surtout, surtout, le Endpoint ! C'est là qu'on peut savoir où vont se retrouver les requêtes ! Ici, on lit 10.244.2.61:80 : il s'agit de l'IP du pod qui fait tourner Wordpress et le port sur lequel l'attaquer.

On va pouvoir s'attaquer à la dernière configuration : le service Ingress

Le service Ingress

Ici, on va expliquer au videur du cluster qu'il peut laisser passer les requêtes vers Wordpress.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  name: nginx-ingress
spec:
 backend:
   serviceName: wordpress
   servicePort: 80
Créez tout ça :
kubectl create -f ingress.yaml
Une fois créé, vérifiez qu'il est bien là :
dada@k8smaster:~/$ kubectl get ingresses
NAME            HOSTS   ADDRESS   PORTS   AGE
nginx-ingress   *                 80      6s
Et vérifiez sa configuration :
dada@k8smaster:~/$ kubectl describe ingress nginx-ingress
Name:             nginx-ingress
Namespace:        default
Address:          
Default backend:  wordpress:80 (10.244.2.61:80)
Rules:
  Host  Path  Backends
  ----  ----  --------
  *     *     wordpress:80 (10.244.2.61:80)
Annotations:
  kubernetes.io/ingress.class:  nginx
Events:
  Type    Reason  Age   From                      Message
  ----    ------  ----  ----                      -------
  Normal  CREATE  65s   nginx-ingress-controller  Ingress default/nginx-ingress
  Normal  UPDATE  30s   nginx-ingress-controller  Ingress default/nginx-ingress

Dans les Rules, remarquez que le backend est bien présent. Ici, le backend est le service wordpress que nous avons mis en place un peu plus tôt. Tout va bien !

Maintenant ? Souvenez-vous de l'IP externe que vous avez réussi à récupérer dans mon précédent billet et allez voir !



Il existe des moyens bien plus simples pour arriver à ce résultat. Passer par un Ingress Controller n'est pas la plus rapide mais elle permet de mettre le nez dans cet outil qui, plus tard, vous permettra de rediriger le flux en fonction du host. Bref. C'est un choix qui invite à aller plus loin !

La suite ?

À voir...

Accéder au cluster k8s depuis l'extérieur

Rédigé par dada / 09 novembre 2018 / Aucun commentaire



Perdu ?

On vient de se battre pour mettre en place un cluster Ceph opérationnel, histoire de stocker ses données dans le cluster k8s et de les répliquer un peu. Maintenant que c'est bon, si on s'attaquait à des choses un peu plus visible, hors dashboard ?
Au programme de ce billet : Ingress, Service, Wordpress, des nouveaux pods.

Ingress Nginx

Cette chose-là va être le point d'entrée de notre cluster. Il va permettre à l'extérieur d'aller regarder à l'intérieur. Son rôle va être de comprendre la requête d'entrée et de l'orienter vers le pod qui y répondra. Dans le cas qui va suivre, aller sur l'IP du cluster pour y retrouver un Wordpress.

Installation via Helm

Comme on s'en sert déjà, on va continuer :
helm install stable/nginx-ingress --name my-nginx
Cette installation va faire apparaître les pods suivants :
dada@k8smaster:~$ kubectget pods -n default
NAME                                                      READY   STATUS    RESTARTS   AGE
my-nginx-nginx-ingress-controller-565bc9555b-pcqjz        1/1     Running   2          8h
my-nginx-nginx-ingress-default-backend-5bcb65f5f4-728tx   1/1     Running   2          8h
Et un service. On n'a pas encore parlé de services : je vous redirige vers la documentation officielle si vous voulez en savoir bien plus.
dada@k8smaster:~$ kubectl --namespace default get services -o wide -w my-nginx-nginx-ingress-controller
NAME                                TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE   SELECTOR
my-nginx-nginx-ingress-controller   LoadBalancer   10.100.45.147   <pending>     80:32462/TCP,443:30337/TCP   8s    app=nginx-ingress,component=controller,release=my-nginx
Ça veut dire que l'Ingress Controller est bien installé. Notez le <pending> : ça veut dire que notre controller n'a pas d'IP externe. En gros : il ne sert à rien. Il lui faut une IP pour que nous puissions l'attaquer.
Dans une installation chez des gros fournisseurs d'informatique dans les nuages, nous aurions une sorte de plugin nous fournissant déjà l'IP tant désirée. Avec notre infrastructure sous Virtualbox, il va falloir faire autrement. Et autrement, ça veut dire avec MetalLB.

MetalLB

MetalLB, ce sont des pods que nous allons installer dans notre cluster et qui nous serviront à palier le problème cité juste au dessus. Il ira interroger notre DHCP, la Freebox dans mon cas, pour récupérer une IP publique.

Installer MetalLB

Toujours avec Helm :
helm install --name metallb stable/metallb
Un peu d'attente et vous devriez voir de nouveaux pods :
dada@k8smaster:~$ kubectl get pods -n metallb-system
NAME                         READY   STATUS    RESTARTS   AGE
controller-765899887-ck6bv   1/1     Running   2          8h
speaker-jdqg9                1/1     Running   2          8h
speaker-t4vtk                1/1     Running   2          8h
Il lui manque un fichier de configuration pour nous offrir une adresse IP externe :
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: default
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.0.50-192.168.0.60
Les adresses IP en bas de ce fichier de conf vont permettre à MetalLB d'aller titiller notre DHCP (Freebox pour moi) pour obtenir une adresse. Quelque chose entre 192.168.0.50 et 192.168.0.60 dans mon cas. Vérifiez bien la configuration de votre Freebox avant de choisir une plage d'IP.

On l'applique :
kubectl create -f config.yaml

Retour à l'Ingress Nginx

Une fois après avoir configuré MetalLB, vous allez vérifier l'état du service :
dada@k8smaster:~/$ kubectl --namespace default get services -o wide -w my-nginx-nginx-ingress-controller
NAME                                TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE    SELECTOR
my-nginx-nginx-ingress-controller   LoadBalancer   10.100.45.147   192.168.0.50   80:32462/TCP,443:30337/TCP   3d3h   app=nginx-ingress,component=controller,release=my-nginx
Vous avez vu ? Une EXTERNAL-IP ! On va pouvoir taper dessus !

La suite ?


Rook pour gérer le système de fichiers

Rédigé par dada / 08 novembre 2018 / 4 commentaires


Un cluster k8s, c'est presque "out-of-the-box" quand on veut s'en servir pour lancer des conteneurs qui n'amènent avec eux qu'un traitement. En gros, votre conteneur contient un script python qui va afficher 42 fois le message "toto" et mourir. C'est un exemple idiot, mais ce n'est pas un détail.
Dans le cadre de ce tuto qui me sert à préparer la migration de ce blog dans un cluster k8s, j'ai besoin de pouvoir stocker le contenu de mes billets quelque part. Le mettre dans un conteneur est une aberration et sera synonyme de perte de données quand celui-ci mourra.

Pour m'en sortir, on m'a parlé de Rook.io, un système de cluster Ceph intégré à Kubernetes. On va voir comment s'en servir maintenant.

Installer Rook

Installer les dépendances

Il va falloir installer des paquets sur vos membres du cluster. À l'exception du Master.
apt-get install ceph-fs-common ceph-common

Récupérer le binaire RBD

cd /bin  
sudo curl -O https://raw.githubusercontent.com/ceph/ceph-docker/master/examples/kubernetes-coreos/rbd  
sudo chmod +x /bin/rbd  
rbd #Command to download ceph images
On va partir sur la version beta de l'outil. C'est la plus stable.

Ajouter le dépôt Rook dans Helm

dada@k8smaster:~$ helm repo add rook-beta https://charts.rook.io/beta
"rook-beta" has been added to your repositories

Récupérer Rook

À la manière de APT :
dada@k8smaster:~$ helm install --namespace rook-ceph-system rook-beta/rook-ceph
NAME:   torrid-dragonfly
LAST DEPLOYED: Sun Nov  4 11:22:24 2018
NAMESPACE: rook-ceph-system
STATUS: DEPLOYED
Le message est bien plus long. Je vous invite à prendre le temps de le décortiquer pour y repérer les infos intéressantes.

On peut y récupérer la commande pour valider la présence du pod Operator :
dada@k8smaster:~$ kubectl --namespace rook-ceph-system get pods -l "app=rook-ceph-operator"
NAME                                 READY   STATUS    RESTARTS   AGE
rook-ceph-operator-f4cd7f8d5-zt7f4   1/1     Running   0          2m25
On y trouve aussi les pods nécessaires au cluster dans nos différents nodes :
dada@k8smaster:~$ kubectl get pods --all-namespaces -o wide | grep rook
rook-ceph-system   rook-ceph-agent-pb62s                   1/1     Running   0          4m10s   192.168.0.30   k8snode1    <none
rook-ceph-system   rook-ceph-agent-vccpt                   1/1     Running   0          4m10s   192.168.0.18   k8snode2    <none>
rook-ceph-system   rook-ceph-operator-f4cd7f8d5-zt7f4      1/1     Running   0          4m24s   10.244.2.62    k8snode2    <none>
rook-ceph-system   rook-discover-589mf                     1/1     Running   0          4m10s   10.244.2.63    k8snode2    <none>
rook-ceph-system   rook-discover-qhv9q                     1/1     Running   0          4m10s   10.244.1.232   k8snode1    <none>
On a la base ! Vous devriez avoir un agent et un discover par node. L'operator, lui, reste tout seul.

Création du cluster

Maintenant que Rook tourne, il lui faut lui faire comprendre que nous voulons un cluster qui va bien pour nos volumes.

Je reprends ci-dessous l'exemple de la documentation : ça marche bien comme ça.
#################################################################################
# This example first defines some necessary namespace and RBAC security objects.
# The actual Ceph Cluster CRD example can be found at the bottom of this example.
#################################################################################
apiVersion: v1
kind: Namespace
metadata:
  name: rook-ceph
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: rook-ceph-cluster
  namespace: rook-ceph
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: rook-ceph-cluster
  namespace: rook-ceph
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: [ "get", "list", "watch", "create", "update", "delete" ]
---
# Allow the operator to create resources in this cluster's namespace
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: rook-ceph-cluster-mgmt
  namespace: rook-ceph
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: rook-ceph-cluster-mgmt
subjects:
- kind: ServiceAccount
  name: rook-ceph-system
  namespace: rook-ceph-system
---
# Allow the pods in this namespace to work with configmaps
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: rook-ceph-cluster
  namespace: rook-ceph
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: rook-ceph-cluster
subjects:
- kind: ServiceAccount
  name: rook-ceph-cluster
  namespace: rook-ceph
---
#################################################################################
# The Ceph Cluster CRD example
#################################################################################
apiVersion: ceph.rook.io/v1beta1
kind: Cluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    # For the latest ceph images, see https://hub.docker.com/r/ceph/ceph/tags
    image: ceph/ceph:v13.2.2-20181023
  dataDirHostPath: /var/lib/rook
  dashboard:
    enabled: true
  storage:
    useAllNodes: true
    useAllDevices: false
    config:
      databaseSizeMB: "1024"
      journalSizeMB: "1024"
On apply tout ça :
kubectl create -f cluster.yaml
Si tout s'est bien passé et que vous avez patienté quelques minutes, voici ce que vous devriez avoir maintenant :
dada@k8smaster:~/rook$ kubectl get pods -n rook-ceph -o wide 
NAME                                   READY   STATUS      RESTARTS   AGE     IP             NODE       NOMINATED NODE
rook-ceph-mgr-a-5f6dd98574-tm9md       1/1     Running     0          3m3s    10.244.2.126   k8snode2   <none>
rook-ceph-mon0-sk798                   1/1     Running     0          4m36s   10.244.1.42    k8snode1   <none>
rook-ceph-mon1-bxgjt                   1/1     Running     0          4m16s   10.244.2.125   k8snode2   <none>
rook-ceph-mon2-snznb                   1/1     Running     0          3m48s   10.244.1.43    k8snode1   <none>
rook-ceph-osd-id-0-54c856d49d-77hfr    1/1     Running     0          2m27s   10.244.1.45    k8snode1   <none>
rook-ceph-osd-id-1-7d98bf85b5-rt4jw    1/1     Running     0          2m26s   10.244.2.128   k8snode2   <none>
rook-ceph-osd-prepare-k8snode1-dzd5v   0/1     Completed   0          2m41s   10.244.1.44    k8snode1   <none>
rook-ceph-osd-prepare-k8snode2-2jgvg   0/1     Completed   0          2m41s   10.244.2.127   k8snode2   <none>

Créer le système de fichiers

Le cluster est en place, mais rien ne nous permet de l'utiliser. On va remédier à ça en lui assignant un système de fichiers. Pour l'exemple, j'ai choisi la méthode dite Block Storage. Elle permet de mettre en place des Persistent Volumes (PV) qui pourront être utilisés par un seul pod à la fois. S'il vous faut plusieurs pods accédant à un PV, dirigez-vous vers le Shared File System.

Pour que ça marche, créez la configuration de la StorageClass :
apiVersion: ceph.rook.io/v1beta1
kind: Pool
metadata:
  name: replicapool
  namespace: rook-ceph
spec:
  replicated:
    size: 3
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: rook-ceph-block
provisioner: ceph.rook.io/bloc
parameters:
  pool: replicapool
  clusterNamespace: rook-ceph
On l'applique : 
kubectl create -f storageclass.yaml
On est bon pour le système de fichiers !
On ne va pas créer de pod s'en servant pour le moment. Si vous y allez, vous ne pourrez rien en tirer puisque vous ne pouvez pas encore accéder à votre cluster depuis l'extérieur. C'est la prochaine étape.

Le Dashboard Ceph

Si vous avez pris le temps de lire la configuration du cluster proposée un peu plus haut, vous devriez avoir vu que le Dashboard est activé dans le yaml. Comme pour Kubernetes, Rook intègre un dashboard pour y voir un peu plus clair.

Il est "enable", mais pas activé. Corrigeons ça à l'aide en créant le fichier dashboard-external.yaml :
dada@k8smaster:~/rook$ cat dashboard-external.yaml 
apiVersion: v1
kind: Service
metadata:
  name: rook-ceph-mgr-dashboard-external
  namespace: rook-ceph
  labels:
    app: rook-ceph-mgr
    rook_cluster: rook-ceph
spec:
  ports:
  - name: dashboard
    port: 7000
    protocol: TCP
    targetPort: 7000
  selector:
    app: rook-ceph-mgr
    rook_cluster: rook-ceph
  sessionAffinity: None
  type: NodePort
Récupérez le port exposé : 
dada@k8smaster:~/rook$ kubectl -n rook-ceph get service | grep Node
rook-ceph-mgr-dashboard-external   NodePort    10.99.88.135     <none>        7000:31165/TCP   3m41s
Et vous devriez pouvoir joindre le dashboard en utilisant l'IP du master et le port qui va bien : 31165 dans mon cas.

Si tout va bien, vous devriez pouvoir vous promener dans une page web qui ressemble à ça :

Considérations

La gestion du système de fichiers que je vous propose n'est pas sans risque. Les volumes que vous allez créer doivent être configurés sérieusement. Les exemples que vous aller trouver par-ci par-là vous permettront d'avoir un stockage dans votre cluster k8s, certes, mais rendront sans doute vos volumes dépendants de vos pods. Si vous décidez de supprimer le pod pour lequel vous avec un PVC, le PV disparaîtra, et vos données avec.

Prenez le temps de bien réfléchir et de bien plus étudier la question que ce que je vous propose dans mes billets avant de vous lancer dans une installation en production.

La suite ?


Fil RSS des articles de cette catégorie