Attention, ce billet se traine depuis plus de 3 mois. Les informations qu'il contient ne sont peut-être plus à jour.
Welcome to Nginx, puis Wordpress
Rédigé par / / 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...