Différences

Ci-dessous, les différences entre deux révisions de la page.

--- guide:installation_kapsule_2020 [2020/06/01 11:06] – alban
+++ guide:installation_kapsule_2020 [2021/04/18 22:24] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
-====== [BROUILLON] Installation infra kapsule 2020 ======
+====== Installation infra Kapsule 2020 ======
 ===== Avant de commencer =====
@@ Ligne 10: / Ligne 10: @@
   * La dernière LTS ubuntu en ce mois de mai 2020 https://wiki.ubuntu.com/Releases et à ce jour c'est la version 20.04
-===== Installation kapsule =====
+===== Installation Kapsule =====
 Dans **l'interface web scaleway** https://console.scaleway.com, aller dans la partie **kapsule** et créer son cluster kubernetes.
@@ Ligne 41: / Ligne 41: @@
 <note info>
-*[INFO]* On suppose ici que la partie génération de clé publique / privée pour l'accès SSH a déjà été fait et ajouté dans l'admin scaleway pour être associé au serveur déployé.
+**[INFO]** On suppose ici que la partie génération de clé publique / privée pour l'accès SSH a déjà été fait et ajouté dans l'admin scaleway pour être associé au serveur déployé.
 </note>
@@ Ligne 55: / Ligne 55: @@
 </code>
-==== Install kubectl ====
+==== Installation kubectl ====
 A ce stade, il s'agit d'installer sur le serveur l'outil ''kubectl'', qui nous permettra de piloter le cluster Kubernetes en ligne de commande.
@@ Ligne 69: / Ligne 69: @@
 </code>
-==== Install du fichier kubeconfig ====
+==== Installation du fichier kubeconfig ====
 Pour pouvoir piloter le cluster kubernetes, il faut le fichier ''kubeconfig'' qu'on va ensuite installer sur le serveur d'admin.
@@ Ligne 86: / Ligne 86: @@
 </code>
-==== Install helm ====
+==== Installation helm ====
 Après avoir regardé un peu, il m'a semblé que le plus simple d'installation et de mise à jour dans le temps consiste à utiliser ''snap''.
@@ Ligne 100: / Ligne 100: @@
 </code>
-===== Configuration du cluster kubernetes =====
+===== Configuration Kapsule =====
 <note important>
@@ Ligne 226: / Ligne 226: @@
 <note info>
 **[INFO]** ''51.159.75.81'' correspond à l'ip du loadbalancer. Si elle n'est pas connue à l'avance, commencer par ''0.0.0.0/32'' puis la mettre à jour ensuite. C'est assez important car c'est ce paramètre qui va dire a nginx quel serveur continent la valeur ip client source a retenir dans les headers proxy.
+</note>
+<note info>
+**[INFO]** A noter que les paramètres ''timeout'' et ''body-size'' du proxy / ingress sont importants si vous avez des applications qui ont besoin d'uploader de gros fichiers //(utile par exemple pour l'import / export de wordpress)// d'une part et / ou faire de gros traitements d'autre part.
 </note>
@@ Ligne 244: / Ligne 248: @@
 ==== Changer la configuration de l'ingress ====
+Un peu de documentation utile //(intégrée aussi pour la définition du helm values)// :
+  * https://stackoverflow.com/questions/54884735/how-to-use-configmap-configuration-with-helm-nginx-ingress-controller-kubernet
+  * https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#custom-max-body-size
+  * https://github.com/kubernetes/ingress-nginx/issues/2007
+  * https://github.com/kubernetes/ingress-nginx/issues/3529
+  * https://github.com/kubernetes/ingress-nginx/issues/1067
 <note important>
@@ Ligne 283: / Ligne 294: @@
 ===== Installation rancher =====
-A ce stade, on doit avoir un cluster kubernetes de base configuré et bien sur le serveur d'admin qui nous a permis d'y arriver. Passons maintenant a l'installation de **Ranchger** qui permettra de gérer les déploiements d'application sur kubernetes. Cela permet aussi d'avoir un outil d'admin potable.
+A ce stade, on doit avoir un cluster kubernetes de base configuré et bien sur le serveur d'admin qui nous a permis d'y arriver. Passons maintenant a l'installation de **Rancher** qui permettra de gérer les déploiements d'application sur kubernetes. Cela permet aussi d'avoir un outil d'admin potable.
 **Les documentations de référence :**
@@ Ligne 312: / Ligne 323: @@
 </code>
-**On utilise plutot la méthode d'installation proposée par ''cert-manager''** //(la version peut être à mettre à jour) :
+**On utilise plutot la méthode d'installation proposée par ''cert-manager''** //(la version peut être à mettre à jour)// :
 <code bash>
 helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v0.15.0 --set installCRDs=true
@@ Ligne 348: / Ligne 359: @@
 </code>
-===== L'installation de wordpress =====
+===== Installation de wordpress =====
 ==== Installation du backend applicatif ====
 La documentation / le contenu de référence :
-https://docs.bitnami.com/tutorials/deploy-custom-wordpress-production-helm/#step-1-define-configuration-values-for-the-bitnami-wordpress-helm-chart
+  * https://docs.bitnami.com/tutorials/deploy-custom-wordpress-production-helm/#step-1-define-configuration-values-for-the-bitnami-wordpress-helm-chart
+  * https://github.com/bitnami/charts/tree/master/bitnami/wordpress
+  * https://bitnami.com/stack/wordpress/helm
+  * https://github.com/bitnami/charts/tree/master/bitnami/wordpress/#installing-the-chart
 J'ai retenu le **chart bitnami** plutôt que celui proposé par rancher car il est plus récent. Et de toutes façons rancher s'inspire du chart bitnami.
 Donc a ce stade go dans la gestion des catalogues de rancher, ajouter la référence vers les charts bitnami et utiliser à la fin la fonction de launch app en choisissant ''wordpress''.
+Ma configuration ''helm'' wordpress se base sur https://github.com/bitnami/charts/blob/master/bitnami/wordpress/values.yaml
+Ajout catalogue chart bitnami dans rancher :
+  * Add catalog
+  * Global catalog
+  * Utiliser cette adresse https://charts.bitnami.com/bitnami
 A noter qu'il faudra passer les bonnes valeurs de help dans le web //(soit en updloadant le fichier yaml, soit en le copian collant)//. D'ailleurs pourquoi via le web rancher plutôt qu'une simple commande helm ? Pour ma part parceque les applications déployées via rancher on des choses faites automatiquement //(un namespace, des éléments regroupement dans le web, des options d'upgrade, etc)//. Maintenant à chacun ses goûts :)
+**Ma configuration :**
+<file yaml wordpress_helm_values.yaml>
+## Global Docker image parameters
+## Please, note that this will override the image parameters, including dependencies, configured to use the global value
+## Current available global Docker image parameters: imageRegistry and imagePullSecrets
+##
+## User of the application
+## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
+##
+wordpressUsername: MON_USER
+## Application password
+## Defaults to a random 10-character alphanumeric string if not set
+## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
+##
+wordpressPassword: MON_PASSWORD
+## Admin email
+## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
+##
+wordpressEmail: MON_EMAIL
+## First name
+## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
+##
+wordpressFirstName: Alban
+## Last name
+## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
+##
+wordpressLastName: Montaigu
+## Blog name
+## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
+##
+wordpressBlogName: Alban's Home
+## Set up update strategy for wordpress installation. Set to Recreate if you use persistent volume that cannot be mounted by more than one pods to makesure the pods is destroyed first.
+## ref: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy
+## Example:
+## updateStrategy:
+##  type: RollingUpdate
+##  rollingUpdate:
+##    maxSurge: 25%
+##    maxUnavailable: 25%
+updateStrategy:
+  type: Recreate
+## Kubernetes configuration
+## For minikube, set this to NodePort, elsewhere use LoadBalancer or ClusterIP
+##
+service:
+  type: ClusterIP
+  ## HTTP Port
+  ##
+  ## Enable client source IP preservation
+  ## ref http://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip
+  ##
+  externalTrafficPolicy: Local
+## Configure the ingress resource that allows you to access the
+## WordPress installation. Set up the URL
+## ref: http://kubernetes.io/docs/user-guide/ingress/
+##
+ingress:
+  ## Set to true to enable ingress record generation
+  ##
+  enabled: false
+  ## Set this to true in order to add the corresponding annotations for cert-manager
+  ##
+  certManager: false
+## Enable persistence using Persistent Volume Claims
+## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
+##
+persistence:
+  enabled: true
+  ## wordpress data Persistent Volume Storage Class
+  ## If defined, storageClassName: <storageClass>
+  ## If set to "-", storageClassName: "", which disables dynamic provisioning
+  ## If undefined (the default) or set to null, no storageClassName spec is
+  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
+  ##   GKE, AWS & OpenStack)
+  ##
+  storageClass: "scw-bssd-retain"
+  ##
+  ## If you want to reuse an existing claim, you can pass the name of the PVC using
+  ## the existingClaim variable
+  # existingClaim: your-claim
+  accessMode: ReadWriteOnce
+  size: 10Gi
+##
+## MariaDB chart configuration
+##
+## https://github.com/bitnami/charts/blob/master/bitnami/mariadb/values.yaml
+##
+mariadb:
+  ## Whether to deploy a mariadb server to satisfy the applications database requirements. To use an external database set this to false and configure the externalDatabase parameters
+  enabled: true
+  ## Enable persistence using Persistent Volume Claims
+  ## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
+  ##
+  master:
+    persistence:
+      enabled: true
+      ## mariadb data Persistent Volume Storage Class
+      ## If defined, storageClassName: <storageClass>
+      ## If set to "-", storageClassName: "", which disables dynamic provisioning
+      ## If undefined (the default) or set to null, no storageClassName spec is
+      ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
+      ##   GKE, AWS & OpenStack)
+      ##
+      storageClass: "scw-bssd-retain"
+      accessModes:
+        - ReadWriteOnce
+      size: 8Gi
+</file>
+<note important>
+**[IMPORTANT]** ''clusterIP'' est important ici. Cela permet de déployer le backend accessible via ip interne dans le cluster kubernetes. C'est à cet endroit qu'on précise qu'on ne veut pas d'autre ''ingress'' ou de ''loadbalancer'' ou de ''nodeport'' car on gère cela d'un autre côté.
+</note>
 ==== Configurer le (seul et unique) ingress pour causer avec le backend wordpress ====
@@ Ligne 367: / Ligne 515: @@
 Et pour ceux qui se posent la question **oui il est possible d'avoir un seul ingress qui envoie vers plusieurs backend dans plusieurs namespaces** : https://itnext.io/save-on-your-aws-bill-with-kubernetes-ingress-148214a79dcb
+On commence déjà par préparer la configuration nécessaire pour la partie ''letsEncrypt'' //(les issuers de certificats, 1 pour le test et 1 pour la prod)//.
+On crée le fichier de configuration :
 <code bash>
 nano staging_issuer.yaml
 </code>
+Avec son contenu :
+<file yaml staging_issuer.yaml>
+apiVersion: cert-manager.io/v1alpha2
+kind: ClusterIssuer
+metadata:
+ name: letsencrypt-staging
+ namespace: cert-manager
+spec:
+ acme:
+   # The ACME server URL
+   server: https://acme-staging-v02.api.letsencrypt.org/directory
+   # Email address used for ACME registration
+   email: MON_MAIL
+   # Name of a secret used to store the ACME account private key
+   privateKeySecretRef:
+     name: letsencrypt-staging
+   # Enable the HTTP-01 challenge provider
+   solvers:
+   - http01:
+       ingress:
+         class:  nginx
+</file>
+On déploie l'issuer pour les tests :
+<code bash>
 kubectl create -f staging_issuer.yaml
+</code>
+On crée ensuite la configuration pour la production :
+<code bash>
 nano prod_issuer.yaml
+</code>
+Le contenu du fichier :
+<file yaml prod_issuer.yaml>
+apiVersion: cert-manager.io/v1alpha2
+kind: ClusterIssuer
+metadata:
+  name: letsencrypt-prod
+  namespace: cert-manager
+spec:
+  acme:
+    # The ACME server URL
+    server: https://acme-v02.api.letsencrypt.org/directory
+    # Email address used for ACME registration
+    email: MON_MAIL
+    # Name of a secret used to store the ACME account private key
+    privateKeySecretRef:
+      name: letsencrypt-prod
+    # Enable the HTTP-01 challenge provider
+    solvers:
+    - http01:
+        ingress:
+          class: nginx
+</file>
+**Et enfin, une fois la configuration de base let'sencrypt faite, on passe à la configuration ingress pour notre wordpress :**
+<code bash>
 nano wordpress_ingress.yaml
+</code>
+Le contenu du fichier :
 <file yaml wordpress_ingress.yaml>
 apiVersion: networking.k8s.io/v1beta1
@@ Ligne 400: / Ligne 607: @@
 </file>
-Commandes
+Maintenant que tous les fichiers de configuration sont prets, on passe au **deploiement**.
+Le letsEncrypt de test //(même si on ne l'utilise pas précisément là, il peut être bon pour tester si besoin)// :
+<code bash>
+kubectl create -f staging_issuer.yaml
+</code>
+**Le déploiement du ''letsEncrypt'' de prod et de la configuration ingress de wordpress** //(avec certificat letsEncrypt)// :
 <code bash>
 kubectl create -f prod_issuer.yaml
 kubectl apply -f  wordpress_ingress.yaml
+</code>
+Pour vérifier que la génération de certificat fonctionne :
+<code bash>
 kubectl describe certificate wordpress-tls
 </code>
-Debug ingress
+<note info>
+Les commandes ci-dessous peuvent être utiles pour des fins de début. Elles ne sont pas nécessaires à l'installation.
+</note>
+Avoir des infos sur le ingress wordpress :
 <code bash>
 kubectl get ing -n wordpress
-kubectl describe ing wordpress-ingress -n wordpress
 </code>
-Adapt nginx Ingress configuration
+Des infos de manière plus détaillée :
-No more needed, since all is included in helm ingress definition.
-  * https://stackoverflow.com/questions/54884735/how-to-use-configmap-configuration-with-helm-nginx-ingress-controller-kubernet
-  * https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#custom-max-body-size
-  * https://github.com/kubernetes/ingress-nginx/issues/2007
-Correction configuration pour x forwarded for
-https://github.com/kubernetes/ingress-nginx/issues/3529
-<code>
-compute-full-forwarded-for: "true"
-use-forwarded-headers: "true"
-</code>
-nano nginx_ingress_config.yaml
-<file yaml nginx_ingress_config.yaml>
-kind: ConfigMap
-apiVersion: v1
-metadata:
-  name: nginx-ingress-ingress-nginx-controller
-  namespace: default
-data:
-  proxy-connect-timeout: "30"
-  proxy-read-timeout: "1800"
-  proxy-send-timeout: "1800"
-  proxy-body-size: "500m"
-  use-proxy-protocol: "true"
-  proxy-real-ip-cidr: "51.159.26.229/32"
-  compute-full-forwarded-for: "true"
-  use-forwarded-headers: "true"
-  ssl-redirect: "false"
-  ssl-protocols: "TLSv1.2 TLSv1.3"
-  ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;"
-</file>
 <code bash>
-kubectl apply -f nginx_ingress_config.yaml
+kubectl describe ing wordpress-ingress -n wordpress
 </code>
-Il faut utiliser l'ip du load balancer pour proxy-real-ip-cidr, on ne peut pas rester générique avec du  ''0.0.0.0/32'' sinon real ip n'est pas pris au bon endroit.
+==== Configuration wordpress ====
-Voir https://github.com/kubernetes/ingress-nginx/issues/1067.
+<note important>
+**[IMPORTANT]** Je me suis rendu compte que les fonctions *import / export* de wordpress ne sont pas vraiment dédiées au backup. En effet, pour les médias //(images and co)// les données sont conservées sur le site d'origine, et au mieux c'est lors de l'import que les images d'origine sont téléchargées.
-Namespace default to change probably
+Si vous avez eu le malheur de démonter un peu vite votre ancien site, l'import sera en erreur sans aucun message aidant à comprendre. Oui j'ai compris après moultes tests et échecs...
+</note>
-Ajout catalogue chart bitnami dans rancher
+<note important>
+**[IMPORTANT]** Dernier point important concernant l'import sur les médias, images par exemple. Il est possible que lors de l'import wordpress les range dans des sous dossiers organisés par date //(alors que ce n'était pas le cas dans la configuration d'origine)//. Autrement dit toutes les inclusions d'images dans vos articles seront cassées.
-  * Add catalog
+Dans mon cas je m'en suis sorti en re téléchargeant les images d'origine dans ''wp-content/uploads'' quitte à dupliquer les images //(ces dernières n'apparaissent pas dans le gestionnaire de média)//. Il y a sans doute quelque chose de mieux à faire mais dans mon cas c'est suffisant.
-  * Global catalog
+</note>
-  * Utiliser cette adresse  https://charts.bitnami.com/bitnami
-Utiliser plutôt cette configuration que celle de rancher !
-===== Installation wordpress =====
-Ne pas utiliser le wordpress rancher, utiliser le bitnami mais via catalog bitnami dans rancher pour avoir l'app
-Documentation
-  * https://github.com/bitnami/charts/tree/master/bitnami/wordpress
-  * https://bitnami.com/stack/wordpress/helm
-  * https://github.com/bitnami/charts/tree/master/bitnami/wordpress/#installing-the-chart
-Configuration maison sur base
-Use https://github.com/bitnami/charts/blob/master/bitnami/wordpress/values.yaml
-Installation via rancher catalog app lunch avec ces values
-Note : helm install wordpress bitnami/wordpress -f wordpress_helm_values.yaml
-==== Configuration wordpress ====
-Divers
+**Sinon, en vrac, les quelques choses que j'ai du faire //(à remettre en forme un jour)// :**
-  * Import / export wordpress media , puis pages, puis articles séparés (après configuration ingress) et penser a associer ancien auteur to new one
+  * ''Export'' dans le site d'origine wordpress (via les fonction admin) des articles & média
-  * Rechercher remplacer les url ancien site nouveau site dans les articles (https://fr.wordpress.org/plugins/better-search-replace/
+  * ''Import'' dans le nouveau site des media puis articles séparés en associant l'ancien auteur au nouveau
-  * Trouble: Souci avec certaines images (a la racine de uploads dans la source et classée parfois avec un suffixe dans la dest) https://fr.wordpress.org/plugins/regenerate-thumbnails/ + reupload images manuellement ancien new site
+  * Rechercher remplacer les url ancien site nouveau site dans les articles et le contenu avec ce plugin https://fr.wordpress.org/plugins/better-search-replace/
-  * Changer langue to fr
+  * Changer la langue en Français
-  * Change blog slogan
+  * Changer le slogan du blog
-  * Configuration ecriture URL a renregistrer
+  * Configuration ecriture URL à renregistrer
-  * Compte alban montaigu à remplir (nom prénom, bio si nécessaire)
+  * Configuration du profil alban montaigu //(nom prénom, bio si nécessaire)//
   * Changer les widgets : nuage de tag
   * Widgets sites que j'aime bien et mes sites
-  * Piracy policy
+  * Page Piracy policy à configurer
-  * Reupload des images racine upload
+  * Régler les commentaires //(autoriser ou non selon l'envie du moment)//
-  * Rechercher replacer http://vivihome.net https://alban.montaigu.io
+  * Plus généralement faire un tour général des configurations
-==== Theme ====
+<note important>
+**[IMPORTANT]** Dans l'url du site wordpress, il faudrait corriger le http en https. En effet, notre configuration est en https mais les liens wordpress ne le semblent pas toujours et cela génère des bugs. Néanmoins dans l'image wordpress bitnami, cette choses et plus ou moins auto détectée / configurée en dur donc non changeable dans l'administration.
-  * Liste à puce Choix du thème twenty seventeen avec image fond du robot blanc
+Dans tous les cas j'ai essayé de le corriger mais cela à complètement fait planter mon site. Donc je me suis arrêté là.
-  * Suppression des autres themes
+</note>
-  * Jeu de couleurs foncées ou autre ?
-Modification CSS pour largeur page adequate a mettre dans le custom css
+<note critique>
+**[IMPORTANT]** Attention en bidoullant la conf wordpress. A la moindre erreur de config, si PHP remonte une erreur, cela va générer des **erreurs dans le monitoring kubernetes** qui va commencer **rebooter non stop votre wordpress**. Cela m'à souvent obligé à réinstaller car impossible de récupérer le conteneur. En effet, modifier les fichiers dans un conteneur qui reboot est un challenge et encore plus dans kubernetes.
-Largeur max 1500 au lieu de 100
+Au mieux, vous pouvez essayer de mettre l'orchestration kubernetes en pause //(pour éviter le reboot en boucle)// et avec un peu de chance le conteneur continuera à vivre suffisamment longtemps pour que vous puissiez corriger l'erreur.
+</note>
-Modification taille des colonnes
+==== Configuration du theme ====
-Largeur 26% au lieu de 36%
+En vrac pour le thème :
+  * Choix du thème ''twenty seventeen''
+  * Suppression des autres themes
+  * Jeu de couleurs foncées
+  * Image personnalisée //(mon cher petit robot)//
-Contenu CSS
+Avec quelques modification CSS pour une largeur page adequate //(j'aime bien les sites qui prennent toute la page)//. A mettre dans le **custom css**.
+**Le contenu du custom CSS à mettre dans la personnalisation du thème :**
 <code css>
 @media screen and (min-width: 48em) {
@@ Ligne 537: / Ligne 704: @@
 </code>
-Reglages commentaires
+**Ma sélection d'extension sur cette base d'image bitnami :**
+  * Activer Askimet
+  * **__NE PAS__** Installer Apocalyspe Meow //(sauf si mode proxy mais il fait planter d'autres truc comme site health)//
+  * Désinstaller All-in-One WP Migration
+  * Désinstaller AMP
+  * Désinstaller Bitnami Production Console Helper
+  * Désinstaller Hello Dolly
+  * Désinstaller Jetpack par WordPress.com
+  * Activer All in One SEO Pack //(ou pas, selon l'envie du moment)//
+  * Activer Simple Tags //(utile pour avoir un nuage de tag avec des tailles différentes par fréquence d'utilisation)//
+  * Désinstaller WP Mail SMTP
+  * Desinstaller wordpress importer //(Plus besoin une fois l'import fait)//
-Desactiver tout
+<note important>
+**[IMPORTANT]** Les permaliens semblent sauter a chaque reboot. Visiblement il suffit de retourer dans l'admin wordpress et enregistrer à nouveau configuration permalien. Me demandez pas pourquoi, je n'ai pas cherché plus avant.
+</note>
-Extensions
+==== La guerre pour faire fonctionner apocalype meow ====
-  * Activer Askimet
+<note important>
-  * NE PAS Installer Apocalyspe Meow (sauf si mode proxy mais il fait planter d'autres truc comme site health)
+**[IMPORTANT]** Cette partie est expérimentale et n'a pas complètement été menée à son terme.
-  * Desinstaller All-in-One WP Migration
+</note>
-  * Desinstaller AMP
-  * Bitnami Production Console Helper
+Quelques références :
-  * Hello Dolly
+  * https://elwpin.com/2019/03/14/quick-fix-for-cloudflare-and-php-remote_addr-ip-detector/
-  * Jetpack par WordPress.com
+  * https://github.com/bitnami/bitnami-docker-wordpress/issues/178
-  * Activer All in One SEO Pack
-  * Activer Simple Tags
+C'est un des trucs qui a contribué à la fin à me faire changer complètement d'infra de serveur.
-  * ???? WP Mail SMTP
-  * Desinstaller wordpress importer (plus besoin)
+Il se trouve que pour bien fonctionner, ce cher plugin à besoin de **l'ip réelle source du client**. Logique, sauf que comme évoqué ce n'est pas si simple à configurer.
+En effet, comme le plugin a des fonctions de ban d'ip source si tentative de bruteforce sur l'admin, il lui faut bien l'information quelque part.
+Sauf que voilà, en admetant que vous avez configuré votre cluster kubernetes correctement, il se trouve que dans les options //(en tout cas pour moi à ce moment)//, le plugin **ne permet pas de sélectionner le header http qui continent l'ip source**. Plus exactement la configuration existe, mais à chaque enregistrement on revient à la valeur de base, la mauvaise évidemment.
+Les commandes suivantes sont donc une tentative de hack pour mettre les bonnes valeurs dans le bon champ puisque le plugin ne permet pas le choix.
-Activer apocalype meow
+L'option de modifier directement la configuration en base peut exister mais bizarrement cela n'a pas fonctionné. Comme si les champs étaient en **lecture seule**. C'est peut être la root cause du problème mais je n'ai pas mené l'investigation jusqu'au bout.
+On se connecte au conteneur et on modifie les fichiers //(le nom du conteneur va forcément changer pour vous)// :
 <code bash>
 kubectl exec -ti -n wordpress wordpress-5498fdfdd6-b5nxw -- bash
 cp wp-config.php wp-config.php.back
 chmod +w wp-config.php.back
 echo "" >> wp-config.php.back
@@ Ligne 571: / Ligne 756: @@
 </code>
-Activer W3 Total Cache
+Une fois que tout est bon //(après vérification donc)// on peut déployer la nouvelle configuration :
+<code bash>
-Chmod 775 pour wp-config
+cp cp wp-config.php.back wp-config.php
+</code>
-A voir ici : https://github.com/bitnami/bitnami-docker-wordpress/issues/203
+==== La guerre pour faire fonctionner W3 Total Cache ====
-Corriger le REMOTE_ADDR (notamment pour apocalypse now)
+Visiblement notre ami rale après installation. De ce que j'ai trouvé c'est lié à un problème de droit :
+<code bash>
+chmod 775 wp-config.php
+</code>
-  * https://elwpin.com/2019/03/14/quick-fix-for-cloudflare-and-php-remote_addr-ip-detector/
+Une référence qui m'a aidé : https://github.com/bitnami/bitnami-docker-wordpress/issues/203
-  * https://github.com/bitnami/bitnami-docker-wordpress/issues/178
-<code php>
+===== Changement DNS vivihome.net =====
-if (isset($_SERVER["HTTP_X_REAL_IP"])) {
-  $_SERVER['REMOTE_ADDR'] = $_SERVER["HTTP_X_REAL_IP"];
-}
-</code>
-Changement DNS vivihome.net
+Comme il s'agit d'une migration, penser à mettre à jour les DNS de l'ancien site :
+  * Supprimer les anciennes défiitions
-  * Ancienne adresse ip vivihome.net 163.172.154.80
+  * Ajouter une redirection visible vers une adresse web //(pas une ip donc)// avec un code http **redirection permanente**
-  * New redirection visible
-Troubleshoot
+===== Commandes utiles en vrac =====
-  * Les permaliens semblent sauter a chaque reboot: go admin enregistrer a nouveau conf permalien
-  * Apocalypse meow ne prend pas le xforwarded for
-==== Commandes utiles en vrac ====
 Excecuter un petit shell dans son conteneur wordpress à des fin de debug par exemple :
@@ Ligne 610: / Ligne 788: @@
 </code>
-====== Install JIRA / CONFLUENCE ====
+===== Installation Jira & Confluence =====
-Ajouter le catalogue helm mox dans rancher (via gestion des catalogues, ajout d'un catalogue helm 3) https://helm.mox.sh.
+On le fait toujours dans rancher via un helm chart bien choisi qu'on ajoute dans les catalogues rancher. Cela permet ensuite de lancer une application pour installation //(comme pour wordpress)//.
+Ici on ajoute le catalogue helm mox dans rancher //(via gestion des catalogues, ajout d'un catalogue helm 3)// en utilisant cette URL : https://helm.mox.sh.
+**Quelques documents / liens de référence utilisés :**
   * https://hub.helm.sh/charts/mox/jira-software
   * https://hub.helm.sh/charts/mox/confluence-server
@@ Ligne 620: / Ligne 801: @@
   * https://github.com/javimox/helm-charts/tree/master/charts
-Comme d'habitude pour avoir l'ip source du client qui redescend jusqu'à l'application (attention ce n'est pas le seul critère hélas), ne pas oublier de mettre le ''externalTraficPolicy'' à ''Local''.
+Comme d'habitude pour avoir l'ip source du client qui redescend jusqu'à l'application //(attention ce n'est pas le seul critère hélas)//, ne pas oublier de mettre le ''externalTraficPolicy'' à ''Local''.
 **Le drame avec les ressources :**
@@ Ligne 632: / Ligne 813: @@
 J'ai pu m'en sortir avec des adaptations de readiness et liveness plus **ajout d'un nouveau pool de nodes avec des conf à 8Go de RAM* sans oublier **des regles d'affinité** pour que les conteneurs jira et confluence aillent sur les nodes les plus généreux en RAM d'une part et d'autre part qu'ils ne soient pas déployés ensemble sur le même noeud (et ainsi se faire la guerre sur les ressources).
-**Conclusion** c'est là que je me suis arrêté et que j'ai renoncé pour être franc. Cela tournait mais pas de manière si rapide d'une part et d'autre part mon **porte monaie commencait à pleurer** car j'avais ajouté 2 noeuds à 8Go de RAM qui valent bien plus cher que mes noeuds de départ (que je devais conserver pour mes autres déploiements). Bref, trop cher, trop compliqué toujours pas fini, tant pis...
+C'est là que je me suis arrêté et que j'ai renoncé pour être franc. Cela tournait mais pas de manière si rapide d'une part et d'autre part mon **porte monaie commencait à pleurer** car j'avais ajouté 2 noeuds à 8Go de RAM qui valent bien plus cher que mes noeuds de départ (que je devais conserver pour mes autres déploiements). Bref, trop cher, trop compliqué toujours pas fini, tant pis...
+===== Conclusion =====
+Alors heureux ? Non pour être clair. J'ai passé un temps bien trop long à tatonner pour un résultat complexe, difficile à maintenir et en plus cher en hébergement.
-===== LEs trucs encore en vrac à formaliser =====
+J'ai du tout recommencer un nombre incalculable de fois parfois pour une erreur idiote. Donc oui c'est sexy, oui j'ai écrit ce guide pour ne pas perdre les connaissances acquises. Oui j'espère que cela pourra être utile à d'autres. Mais en vrai moi, je vais trouver une autre solution.
-  * Corriger le http://alban.montaigu.io dans la conf wordpress vers https ? Attention fait bug dans wp config et fait bug health check kubernetes
+Mes feedbacks plus détaillés sur mon blog :
-  * Xforwarded for pour notamment akismet ?
+  * https://alban.montaigu.io/2020/05/26/premiers-retours-sur-la-nouvelle-infra-alban-montaigu-io/
-    * Empeche apocalyspe meow de fonctionner et proablement les google analytics
+  * https://alban.montaigu.io/2020/05/26/second-retour-sur-la-nouvelle-infra-alban-montaigu-io/
-    * https://github.com/kubernetes/ingress-nginx/issues/3529
+  * https://alban.montaigu.io/2020/05/27/retour-en-2013-2014-nouvelle-infra-montaigu-io/
-    * A tester : https://github.com/bitnami/bitnami-docker-wordpress/issues/117
-    * https://docs.ovh.com/gb/en/kubernetes/getting-source-ip-behind-loadbalancer/
-    * https://atodorov.me/2019/11/21/getting-started-with-scaleways-managed-kubernetes-service-kapsule/
-    * https://github.com/nginxinc/kubernetes-ingress/blob/master/examples/proxy-protocol/README.md
-    * https://www.scaleway.com/en/docs/configure-proxy-protocol-with-a-load-balancer/