guide:installation_kapsule_2020

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
Prochaine révisionLes deux révisions suivantes
guide:installation_kapsule_2020 [2020/06/01 13:15] albanguide:installation_kapsule_2020 [2020/06/01 13:18] alban
Ligne 6: Ligne 6:
  
 **En vrac :** **En vrac :**
-  * Choisir son moteur network : [[https://kubernetes.io/fr/docs/concepts/services-networking/service/|https://kubernetes.io/fr/docs/concepts/services-networking/service/]] +  * Choisir son moteur network : https://kubernetes.io/fr/docs/concepts/services-networking/service/ 
-  * Matrice de compatibilité rancher 2.4.2 [[https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.4.2/|https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.4.2/]] +  * Matrice de compatibilité rancher 2.4.2 https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.4.2/ 
-  * La dernière LTS ubuntu en ce mois de mai 2020 [[https://wiki.ubuntu.com/Releases|https://wiki.ubuntu.com/Releases]] et à ce jour c'est la version 20.04+  * 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|https://console.scaleway.com]], aller dans la partie **kapsule**  et créer son cluster kubernetes.+Dans **l'interface web scaleway** https://console.scaleway.com, aller dans la partie **kapsule** et créer son cluster kubernetes.
  
 **Les infos à saisir :** **Les infos à saisir :**
- 
   * Nom k8s-01 dans mon cas. Evidemment, mettez ce que vous voulez   * Nom k8s-01 dans mon cas. Evidemment, mettez ce que vous voulez
   * Les deux points suivant sont dans les options avancées du cluster kubernetes   * Les deux points suivant sont dans les options avancées du cluster kubernetes
-  * Pas de //kubernetes dashboard//  car je prévois d'installer //rancher 2//  qui fournit son propre dashboard +  * Pas de //kubernetes dashboard// car je prévois d'installer //rancher 2// qui fournit son propre dashboard 
-  * Pas de ''ingress''  car je prévois d'installer le mien, à ma façon+  * Pas de ''ingress'' car je prévois d'installer le mien, à ma façon
   * *A ce stade, on peut se poser la question de rattacher lecluster à un network privé, je choisis de ne pas le faire surtout que ce sera payant à un moment*   * *A ce stade, on peut se poser la question de rattacher lecluster à un network privé, je choisis de ne pas le faire surtout que ce sera payant à un moment*
   * Choisir la version de Kubernetes 1.18 dans mon cas   * Choisir la version de Kubernetes 1.18 dans mon cas
-  * Choix de 3 noeuds ''DEV-M''  pour limiter le cout tout en ayant quand même 3 noeuds+  * Choix de 3 noeuds ''DEV-M'' pour limiter le cout tout en ayant quand même 3 noeuds
   * Pour le moteur réseau, choix de flannel car plus performant (plus light en ressources pour mes petits DEV-M) et pas besoin de grosse sécurité   * Pour le moteur réseau, choix de flannel car plus performant (plus light en ressources pour mes petits DEV-M) et pas besoin de grosse sécurité
  
Ligne 31: Ligne 30:
 J'ai un PC Windows et je n'ai pas envie de devoir installer sur mon poste perso tout l'outillage pour piloter mon cluster Kubernetes. Ceci d'autant plus que je peux être amené à devoir intervenir sur le serveur sans avoir mon PC perso sous la main. J'ai un PC Windows et je n'ai pas envie de devoir installer sur mon poste perso tout l'outillage pour piloter mon cluster Kubernetes. Ceci d'autant plus que je peux être amené à devoir intervenir sur le serveur sans avoir mon PC perso sous la main.
  
-Je prévois donc de déployer en plus un simple **serveur linux**  ''DEV-S''  chez scaleway avec tout l'outillage d'amdin installé dessus.+Je prévois donc de déployer en plus un simple **serveur linux** ''DEV-S'' chez scaleway avec tout l'outillage d'amdin installé dessus.
  
 Pour cela, go sur la console web scaleway et ajout d'une instance avec les informations ci-dessous. Pour cela, go sur la console web scaleway et ajout d'une instance avec les informations ci-dessous.
  
 **Les infos que j'utilise pour l'installation :** **Les infos que j'utilise pour l'installation :**
- 
   * Nom scw-k8s-adm-01 mais choisissez ce que vous voulez   * Nom scw-k8s-adm-01 mais choisissez ce que vous voulez
   * Ubuntu LTS 20.04   * Ubuntu LTS 20.04
Ligne 42: Ligne 40:
 Un peu d'attente et ensuite il est possible de s'y connecter en SSH. Un peu d'attente et ensuite il est possible de s'y connecter en SSH.
  
-<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é. </note>+<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é. 
 +</note>
  
 ==== Première connection & Maj system ==== ==== Première connection & Maj system ====
  
-On se connecte en SSH avec par exemple ''putty''  sans oublier d'avoir préchargé sa clé dans ''pagent''.+On se connecte en SSH avec par exemple ''putty'' sans oublier d'avoir préchargé sa clé dans ''pagent''.
  
 Puis, comme on est bien élevés, avant toute chose on commence par mettre à jour le système. Puis, comme on est bien élevés, avant toute chose on commence par mettre à jour le système.
Ligne 59: Ligne 59:
 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. 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.
  
-La documentation de référence : [[https://kubernetes.io/fr/docs/tasks/tools/install-kubectl/#installer-kubectl-sur-linux|https://kubernetes.io/fr/docs/tasks/tools/install-kubectl/#installer-kubectl-sur-linux]]+La documentation de référence : https://kubernetes.io/fr/docs/tasks/tools/install-kubectl/#installer-kubectl-sur-linux
  
 <code bash> <code bash>
Ligne 71: Ligne 71:
 ==== Installation 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.+Pour pouvoir piloter le cluster kubernetes, il faut le fichier ''kubeconfig'' qu'on va ensuite installer sur le serveur d'admin.
  
-Rendez-vous dans l'interface d'admin **kapsule**  scaleway pour le téléchargement du kubeconfig.+Rendez-vous dans l'interface d'admin **kapsule** scaleway pour le téléchargement du kubeconfig.
  
 **Puis installation sur le serveur après téléchargement :** **Puis installation sur le serveur après téléchargement :**
- 
 <code bash> <code bash>
 mkdir ~/.kube mkdir ~/.kube
Ligne 83: Ligne 82:
  
 Pour vérifier que tout fonctionne on essaye d'obtenir les infos du cluster kapsule : Pour vérifier que tout fonctionne on essaye d'obtenir les infos du cluster kapsule :
- 
 <code bash> <code bash>
 kubectl cluster-info kubectl cluster-info
- 
 </code> </code>
  
Ligne 95: Ligne 92:
 <code bash> <code bash>
 snap install helm --classic snap install helm --classic
- 
 </code> </code>
  
-Ce qui est amusant et qui n'est pas dit de manière évidente c'est que le repo helm ''stable''  de base n'est pas dispo out of the box. Il faut donc installer le repo. J'ai trouvé les informations ici : [[https://github.com/helm/charts/issues/19279|https://github.com/helm/charts/issues/19279]]+Ce qui est amusant et qui n'est pas dit de manière évidente c'est que le repo helm ''stable'' de base n'est pas dispo out of the box. Il faut donc installer le repo. J'ai trouvé les informations ici : https://github.com/helm/charts/issues/19279
  
 <code bash> <code bash>
 helm repo add stable https://kubernetes-charts.storage.googleapis.com helm repo add stable https://kubernetes-charts.storage.googleapis.com
- 
 </code> </code>
  
 ===== Configuration Kapsule ===== ===== Configuration Kapsule =====
  
-<note important> **[IMPORTANT]**  A ce stade vous devez savoir que, pour des raisons de cout notamment, j'ai choisi de ne déployer **qu'un seul ingress / loadbalancer**. J'y reviens un peu plus tard. Cela implique donc des configuration séparées, ou je déploie mes back-end d'un côté et met à jour mon ingress manuellement en central de l'autre. </note>+<note important> 
 +**[IMPORTANT]** A ce stade vous devez savoir que, pour des raisons de cout notamment, j'ai choisi de ne déployer **qu'un seul ingress / loadbalancer**. J'y reviens un peu plus tard. Cela implique donc des configuration séparées, ou je déploie mes back-end d'un côté et met à jour mon ingress manuellement en central de l'autre.  
 +</note>
  
 ==== Digression sur la récupération de l'ip client source ==== ==== Digression sur la récupération de l'ip client source ====
  
-<note info> **[INFO]**  Cette étape est clairement optionelle et ne fait pas partie de l'installation en tant que tel. J'ai préféré la noter car à un moment c'est ce qui m'a aidé pour déboguer et résoudre mes soucis d'ip client source qui n'allait pas jusqu'à mon backend wordpress. </note>+<note info> 
 +**[INFO]** Cette étape est clairement optionelle et ne fait pas partie de l'installation en tant que tel. J'ai préféré la noter car à un moment c'est ce qui m'a aidé pour déboguer et résoudre mes soucis d'ip client source qui n'allait pas jusqu'à mon backend wordpress. 
 +</note>
  
-J'avoue que cette documentation m'a été utile : [[https://docs.ovh.com/gb/en/kubernetes/getting-source-ip-behind-loadbalancer/|https://docs.ovh.com/gb/en/kubernetes/getting-source-ip-behind-loadbalancer/]]+J'avoue que cette documentation m'a été utile : https://docs.ovh.com/gb/en/kubernetes/getting-source-ip-behind-loadbalancer/
  
 Aussi bien pour comprendre un peu mieux ce qu'il y avait à faire mais aussi pour avoir les moyens de tester sans trop me prendre la tête. Aussi bien pour comprendre un peu mieux ce qu'il y avait à faire mais aussi pour avoir les moyens de tester sans trop me prendre la tête.
  
-<note important> **[IMPORTANT]**  A noter ici que si vous suivez tout ce qui est dans ce guide vous déploierez __un autre ingress__. Encore une fois cette partie n'avance pas la configuration en tant que tel mes ses conclusions sont intégrées dans les autres parties de ce guide. </note>+<note important> 
 +**[IMPORTANT]** A noter ici que si vous suivez tout ce qui est dans ce guide vous déploierez __un autre ingress__. Encore une fois cette partie n'avance pas la configuration en tant que tel mes ses conclusions sont intégrées dans les autres parties de ce guide. 
 +</note>
  
-Tester avec ce guide et des ingress à part, c'est une chose que j'ai d'ailleurs faite au début car je pensais que mon //impossibilité//  d'avoir l'ip source réelle (oui c'était une vrai guerre) venait de ma façon de déployer l'ingress. Ce qui n'était pas tout à fait vrai. Oui il y en avait un peu à cet endroit mais aussi a d'autres+Tester avec ce guide et des ingress à part, c'est une chose que j'ai d'ailleurs faite au début car je pensais que mon //impossibilité// d'avoir l'ip source réelle (oui c'était une vrai guerre) venait de ma façon de déployer l'ingress. Ce qui n'était pas tout à fait vrai. Oui il y en avait un peu à cet endroit mais aussi a d'autres...
  
 ==== Digression sur la configuration SSL de l'ingress ==== ==== Digression sur la configuration SSL de l'ingress ====
  
-<note important> **[IMPORTANT]**  Cette section est à vocation explicative principalement car elle a été intégrée à la configuration ingress nginx citée par ailleurs dans ce guide. </note>+<note important> 
 +**[IMPORTANT]** Cette section est à vocation explicative principalement car elle a été intégrée à la configuration ingress nginx citée par ailleurs dans ce guide. 
 +</note>
  
-Chose intéressante, j'ai remarqué qu'avec internet explorer 11 //(oui je sais c'est mal mais parfois on a pas le choix)//, mon blog n'était pas accessible en https pour une raison obscure. Après enquête //(pas facile, j'ai du déduire un peu)//, il s'avère que c'est parceque les paramètres TLS et les **algorithmes fournis de base par ma configuration TLS serveur son trop récents**  et non pris en compte par ce vieux ie 11 (et d'autres config de là même époque).+Chose intéressante, j'ai remarqué qu'avec internet explorer 11 //(oui je sais c'est mal mais parfois on a pas le choix)//, mon blog n'était pas accessible en https pour une raison obscure. Après enquête //(pas facile, j'ai du déduire un peu)//, il s'avère que c'est parceque les paramètres TLS et les **algorithmes fournis de base par ma configuration TLS serveur son trop récents** et non pris en compte par ce vieux ie 11 (et d'autres config de là même époque).
  
-Pour y voir plus clair j'avoue que [[https://www.ssllabs.com|https://www.ssllabs.com]] a été d'une grande aide pour avoir des infos sur la compatibilité et ce que mon serveur sait faire.+Pour y voir plus clair j'avoue que https://www.ssllabs.com a été d'une grande aide pour avoir des infos sur la compatibilité et ce que mon serveur sait faire.
  
 **Quelques liens utiles:** **Quelques liens utiles:**
 +  * https://www.linode.com/docs/web-servers/nginx/tls-deployment-best-practices-for-nginx/
 +  * https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#ssl-ciphers
 +  * https://www.ssllabs.com/ssltest/analyze.html?d=alban.montaigu.io
  
-  * [[https://www.linode.com/docs/web-servers/nginx/tls-deployment-best-practices-for-nginx/|https://www.linode.com/docs/web-servers/nginx/tls-deployment-best-practices-for-nginx/]] +Donc pour améliorer la compatibilté il suffit d'ajouter 1 ou deux ''ciphers'' //weak// qui sont pris en charge par les vieux navigateurs :
-  * [[https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#ssl-ciphers|https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#ssl-ciphers]] +
-  * [[https://www.ssllabs.com/ssltest/analyze.html?d=alban.montaigu.io|https://www.ssllabs.com/ssltest/analyze.html?d=alban.montaigu.io]] +
- +
-Donc pour améliorer la compatibilté il suffit d'ajouter 1 ou deux ''ciphers''  //weak//  qui sont pris en charge par les vieux navigateurs :+
 <code> <code>
- 
 ssl-protocols: "TLSv1.2 TLSv1.3" ssl-protocols: "TLSv1.2 TLSv1.3"
 ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;" ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;"
- 
 </code> </code>
  
-A noter que si vous voulez éviter de forcer le tls partout sur vos déploiement web quand ya des soucis de conf / compat mieux vaut désactiver la redirection //(qui se fait par défaut je crois)//  : +A noter que si vous voulez éviter de forcer le tls partout sur vos déploiement web quand ya des soucis de conf / compat mieux vaut désactiver la redirection //(qui se fait par défaut je crois)// :
 <code> <code>
 ssl-redirect: "false" ssl-redirect: "false"
- 
 </code> </code>
  
Ligne 153: Ligne 151:
  
 <code> <code>
-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK    256 +TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 256 
-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK +TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK
 </code> </code>
  
-**Les commandes ci-dessous peuvent être utiles pour debug un peu le TLS**  //(a adapter en fonction de votre domaine bien sur)//  : +**Les commandes ci-dessous peuvent être utiles pour debug un peu le TLS** //(a adapter en fonction de votre domaine bien sur)// :
 <code bash> <code bash>
 curl -v --tlsv1.3 -s https://alban.montaigu.io/wp-json > /dev/null curl -v --tlsv1.3 -s https://alban.montaigu.io/wp-json > /dev/null
 curl -v -s http://alban.montaigu.io/wp-json > /dev/null curl -v -s http://alban.montaigu.io/wp-json > /dev/null
- 
 </code> </code>
  
 ==== Installation & configuration de l'ingress ==== ==== Installation & configuration de l'ingress ====
  
-Après toutes ces **digressions**  voici ce que cela donne.+Après toutes ces **digressions** voici ce que cela donne.
  
 **La documentation que j'ai utilisée et qui m'a servi à un moment ou un autre :** **La documentation que j'ai utilisée et qui m'a servi à un moment ou un autre :**
 +  * https://kubernetes.github.io/ingress-nginx/deploy/#using-helm
 +  * https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-on-digitalocean-kubernetes-using-helm
 +  * https://hub.helm.sh/charts/nginx/nginx-ingress
 +  * https://github.com/kubernetes/ingress-nginx/blob/master/charts/ingress-nginx/values.yaml
 +  * https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies
 +  * https://www.ovh.com/blog/getting-external-traffic-into-kubernetes-clusterip-nodeport-loadbalancer-and-ingress/
  
-  * [[https://kubernetes.github.io/ingress-nginx/deploy/#using-helm|https://kubernetes.github.io/ingress-nginx/deploy/#using-helm]] +<note important> 
-  * [[https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-on-digitalocean-kubernetes-using-helm|https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-on-digitalocean-kubernetes-using-helm]] +**[IMPORTANT]** La configuration du paramètre ''externalTrafficPolicy'' doit être à ''Local'' pour éviter les hop dans le cluster kubernet et préserver l'ip client source. En effet, il ne faut pas oublier que les loadbalancer / ingress vont être en front de vos applications et si vous voulez que l'ip client passe jusqu'à votre application web il va falloir faire quelques efforts de configuration en commencant par celui là **(ce n'est pas le seul malheureusement)**. 
-  * [[https://hub.helm.sh/charts/nginx/nginx-ingress|https://hub.helm.sh/charts/nginx/nginx-ingress]] +</note>
-  * [[https://github.com/kubernetes/ingress-nginx/blob/master/charts/ingress-nginx/values.yaml|https://github.com/kubernetes/ingress-nginx/blob/master/charts/ingress-nginx/values.yaml]] +
-  * [[https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies|https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies]] +
-  * [[https://www.ovh.com/blog/getting-external-traffic-into-kubernetes-clusterip-nodeport-loadbalancer-and-ingress/|https://www.ovh.com/blog/getting-external-traffic-into-kubernetes-clusterip-nodeport-loadbalancer-and-ingress/]] +
- +
-<note important> **[IMPORTANT]**  La configuration du paramètre ''externalTrafficPolicy''  doit être à ''Local''  pour éviter les hop dans le cluster kubernet et préserver l'ip client source. En effet, il ne faut pas oublier que les loadbalancer / ingress vont être en front de vos applications et si vous voulez que l'ip client passe jusqu'à votre application web il va falloir faire quelques efforts de configuration en commencant par celui là **(ce n'est pas le seul malheureusement)**. </note>+
  
 **Préparation de l'installation du ingress avec helm :** **Préparation de l'installation du ingress avec helm :**
- 
 <code bash> <code bash>
 helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
 kubectl create namespace ingress-nginx kubectl create namespace ingress-nginx
- 
 </code> </code>
  
 **Ensuite avec le fichier de configuration suivant :** **Ensuite avec le fichier de configuration suivant :**
- 
 <file yaml ingress_nginx_helm_values.yaml> <file yaml ingress_nginx_helm_values.yaml>
 ## nginx configuration ## nginx configuration
Ligne 224: Ligne 217:
     #  service.beta.kubernetes.io/scw-loadbalancer-send-proxy-v2: "true"     #  service.beta.kubernetes.io/scw-loadbalancer-send-proxy-v2: "true"
     }     }
 +    
     ## Set external traffic policy to: "Local" to preserve source IP on     ## Set external traffic policy to: "Local" to preserve source IP on
     ## providers supporting it     ## providers supporting it
     ## Ref: https://kubernetes.io/docs/tutorials/services/source-ip/#source-ip-for-services-with-typeloadbalancer     ## Ref: https://kubernetes.io/docs/tutorials/services/source-ip/#source-ip-for-services-with-typeloadbalancer
     externalTrafficPolicy: Local     externalTrafficPolicy: Local
- 
 </file> </file>
  
-<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]** ''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>+<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>
  
-<note important> **[IMPORTANT]**  A ce state vous pouvez choisir d'activer ou non le **proxy protocol**  et tout ce qu'il va avec. Néanmoins, dans mes expériences c'est un choix qui prête à conséquence. En effet, l'activer permettra à vos applications d'avoir à terme l'**ip source client**  //(par exemple les modules de stats wordpress)//. Le **problème**  de ca c'est que de ce que j'ai pu constater, activer cela faisait à minima planter certaines résolutions réseau "locales".+<note important> 
 +**[IMPORTANT]** A ce state vous pouvez choisir d'activer ou non le **proxy protocol** et tout ce qu'il va avec. Néanmoins, dans mes expériences c'est un choix qui prête à conséquence. En effet, l'activer permettra à vos applications d'avoir à terme l'**ip source client** //(par exemple les modules de stats wordpress)//. Le **problème** de ca c'est que de ce que j'ai pu constater, activer cela faisait à minima planter certaines résolutions réseau "locales".
  
-Je m'explique, si jamais vous donnez un domaine associé a l'ip de l'ingress / loadbalancer pour pointer sur vos applications, j'ai constaté que les ''curl''  vers ce domaine depuis n'importe quel conteneur du cluster ne fonctionnaient pas //(je m'en suis rendu compte car l'outil de **santé wordpress**  utilise curl pour tester le loopback et ce dernier plantait lamentablement)//.+Je m'explique, si jamais vous donnez un domaine associé a l'ip de l'ingress / loadbalancer pour pointer sur vos applications, j'ai constaté que les ''curl'' vers ce domaine depuis n'importe quel conteneur du cluster ne fonctionnaient pas //(je m'en suis rendu compte car l'outil de **santé wordpress** utilise curl pour tester le loopback et ce dernier plantait lamentablement)//.
  
-Je n'ai pas réellement trouvé de solution à vrai dire. La seule chose que j'ai constaté c'est que ce problème n'arrive pas quand on laisse le ingress / loadbalancer **en mode tcp de base sans proxy**. </note>+Je n'ai pas réellement trouvé de solution à vrai dire. La seule chose que j'ai constaté c'est que ce problème n'arrive pas quand on laisse le ingress / loadbalancer **en mode tcp de base sans proxy**.  
 +</note>
  
 **On déploie l'ingress avec les bonnes options de configuration :** **On déploie l'ingress avec les bonnes options de configuration :**
- 
 <code bash> <code bash>
 helm install ingress-nginx ingress-nginx/ingress-nginx -f ingress_nginx_helm_values.yaml -n ingress-nginx helm install ingress-nginx ingress-nginx/ingress-nginx -f ingress_nginx_helm_values.yaml -n ingress-nginx
- 
 </code> </code>
  
-A noter qu'il est possible aussi d'appliquer des configurations **à postériori**  comme décrit ci dessous.+A noter qu'il est possible aussi d'appliquer des configurations **à postériori** comme décrit ci dessous.
  
 ==== Changer la configuration de l'ingress ==== ==== Changer la configuration de l'ingress ====
  
-Un peu de documentation utile //(intégrée aussi pour la définition du helm values)//  : +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://stackoverflow.com/questions/54884735/how-to-use-configmap-configuration-with-helm-nginx-ingress-controller-kubernet|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://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#custom-max-body-size|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/2007|https://github.com/kubernetes/ingress-nginx/issues/2007]] +  * https://github.com/kubernetes/ingress-nginx/issues/3529 
-  * [[https://github.com/kubernetes/ingress-nginx/issues/3529|https://github.com/kubernetes/ingress-nginx/issues/3529]] +  * https://github.com/kubernetes/ingress-nginx/issues/1067
-  * [[https://github.com/kubernetes/ingress-nginx/issues/1067|https://github.com/kubernetes/ingress-nginx/issues/1067]]+
  
-<note important> **[IMPORTANT]**  Cette étape peut être **optionelle**  grâce aux helm values du fichier ''ingress_nginx_helm_values.yaml''  mais c'est bon à savoir que vous pouvez l'utiliser __s'il faut changer quelque chose dans la configuration de votre ingress__. </note>+<note important> 
 +**[IMPORTANT]** Cette étape peut être **optionelle** grâce aux helm values du fichier ''ingress_nginx_helm_values.yaml'' mais c'est bon à savoir que vous pouvez l'utiliser __s'il faut changer quelque chose dans la configuration de votre ingress__. 
 +</note>
  
 Un exemple du fichier de configuration en question : Un exemple du fichier de configuration en question :
- 
 <file yaml ingress_nginx_config.yaml> <file yaml ingress_nginx_config.yaml>
 kind: ConfigMap kind: ConfigMap
Ligne 283: Ligne 279:
   ssl-protocols: "TLSv1.2 TLSv1.3"   ssl-protocols: "TLSv1.2 TLSv1.3"
   ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;"   ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;"
- 
 </file> </file>
  
 Et la commande pour l'appliquer : Et la commande pour l'appliquer :
- 
 <code bash> <code bash>
 kubectl apply -f ingress_nginx_config.yaml kubectl apply -f ingress_nginx_config.yaml
- 
 </code> </code>
  
-<note critique> **[IMPORTANT]**  Le déploiement d'ingress va créer automatiquement un **loadbalancer**  associé chez scaleway. C'est assez important à savoir car de mémoire il en va d'environ __9 euros__  par mois il vaut donc mieux le savoir avant de déployer des ingress partout. +<note critique> 
- +**[IMPORTANT]** Le déploiement d'ingress va créer automatiquement un **loadbalancer** associé chez scaleway. C'est assez important à savoir car de mémoire il en va d'environ __9 euros__ par mois il vaut donc mieux le savoir avant de déployer des ingress partout. 
-C'est d'ailleurs __un problème de fond que je n'ai jamais vu sur le net__. En effet, nombre de déploiements helm comportent un ingress intégré. Quand on est innocent, on déploie sans trop se poser de question. Sauf qu'à la fin on se rend compte qu'__**on a déployé une 10aine de load balancer à 9 euros par mois**__ . Je ne sais pas pour vous mais pour moi, c'est vraiment trop cher ! </note>+
  
 +C'est d'ailleurs __un problème de fond que je n'ai jamais vu sur le net__. En effet, nombre de déploiements helm comportent un ingress intégré. Quand on est innocent, on déploie sans trop se poser de question. Sauf qu'à la fin on se rend compte qu'__**on a déployé une 10aine de load balancer à 9 euros par mois**__. Je ne sais pas pour vous mais pour moi, c'est vraiment trop cher !
 +</note>
 +
 ===== Installation rancher ===== ===== 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 **Rancher**  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 :** **Les documentations de référence :**
- +  * https://rancher.com/docs/rancher/v2.x/en/installation/ 
-  [[https://rancher.com/docs/rancher/v2.x/en/installation/|https://rancher.com/docs/rancher/v2.x/en/installation/]] +  * https://rancher.com/docs/rancher/v2.x/en/installation/k8s-install/helm-rancher/
-  * [[https://rancher.com/docs/rancher/v2.x/en/installation/k8s-install/helm-rancher/|https://rancher.com/docs/rancher/v2.x/en/installation/k8s-install/helm-rancher/]]+
  
 On prépare les repo helm : On prépare les repo helm :
- 
 <code bash> <code bash>
 helm repo add rancher-stable https://releases.rancher.com/server-charts/stable helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
 helm repo add jetstack https://charts.jetstack.io helm repo add jetstack https://charts.jetstack.io
 helm repo update helm repo update
- 
 </code> </code>
  
 On crée les namespaces qui seront utiles plus tard : On crée les namespaces qui seront utiles plus tard :
- 
 <code bash> <code bash>
 kubectl create namespace cattle-system kubectl create namespace cattle-system
 kubectl create namespace cert-manager kubectl create namespace cert-manager
- 
 </code> </code>
  
-<note important> **[IMPORTANT]**  A ce stade, je fais une déviation par rapport à l'installation officielle rancher. En effet, pour l'installation de ''cert-manager''  j'ai préféré me référer à [[https://cert-manager.io/docs/installation/kubernetes/|https://cert-manager.io/docs/installation/kubernetes/]] </note> +<note important> 
- +**[IMPORTANT]** A ce stade, je fais une déviation par rapport à l'installation officielle rancher. En effet, pour l'installation de ''cert-manager'' j'ai préféré me référer à https://cert-manager.io/docs/installation/kubernetes/ 
-**Donc __ne pas appliquer__  les comdandes suivantes :**+</note>
  
 +**Donc __ne pas appliquer__ les comdandes suivantes :**
 <code bash> <code bash>
 # kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml # kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
 # helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v0.12.0 # helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v0.12.0
- 
 </code> </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> <code bash>
 helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v0.15.0 --set installCRDs=true helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v0.15.0 --set installCRDs=true
- 
 </code> </code>
  
 Et on vérifie que tout fonctionne bien comme cela par exemple : Et on vérifie que tout fonctionne bien comme cela par exemple :
- 
 <code bash> <code bash>
 kubectl get pods --namespace cert-manager kubectl get pods --namespace cert-manager
- 
 </code> </code>
  
-**On continue avec l'install de rancher**  //(ici avec option letsEncrypt, à adapter avec vos infos à vous)//  : +**On continue avec l'install de rancher** //(ici avec option letsEncrypt, à adapter avec vos infos à vous)// :
 <code bash> <code bash>
 helm install rancher rancher-stable/rancher --namespace cattle-system --set hostname=k8s.montaigu.io --set ingress.tls.source=letsEncrypt --set letsEncrypt.email=alban.montaigu@gmail.com helm install rancher rancher-stable/rancher --namespace cattle-system --set hostname=k8s.montaigu.io --set ingress.tls.source=letsEncrypt --set letsEncrypt.email=alban.montaigu@gmail.com
- 
 </code> </code>
  
 Et on vérifie l'avancement du déploiement / que tout se passe bien avant de passer à la suite : Et on vérifie l'avancement du déploiement / que tout se passe bien avant de passer à la suite :
- 
 <code bash> <code bash>
 kubectl -n cattle-system rollout status deploy/rancher kubectl -n cattle-system rollout status deploy/rancher
 kubectl -n cattle-system get deploy rancher kubectl -n cattle-system get deploy rancher
- 
 </code> </code>
  
-Il n'est pas inutile non plus de vérifier les certificats ''letsEncrypt''  : +Il n'est pas inutile non plus de vérifier les certificats ''letsEncrypt'' :
 <code bash> <code bash>
 kubectl -n cattle-system describe certificate kubectl -n cattle-system describe certificate
 kubectl -n cattle-system describe issuer kubectl -n cattle-system describe issuer
- 
 </code> </code>
  
-<note info> **[INFO]**  Au cas ou vous auriez besoin de reset le password rancher (parce que mal noté ou autre), utilisez la commande ci-dessous pour reset le mot de passe. </note>+<note info> 
 +**[INFO]** Au cas ou vous auriez besoin de reset le password rancher (parce que mal noté ou autre), utilisez la commande ci-dessous pour reset le mot de passe. 
 +</note>
  
 La commande en question pour reset le password : La commande en question pour reset le password :
- 
 <code bash> <code bash>
 kubectl  -n cattle-system exec $(kubectl  -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- reset-password kubectl  -n cattle-system exec $(kubectl  -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- reset-password
- 
 </code> </code>
  
Ligne 383: Ligne 363:
 ==== Installation du backend applicatif ==== ==== Installation du backend applicatif ====
  
-La documentation / le contenu de référence :+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://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
  
-  * [[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]] +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.
-  * [[https://github.com/bitnami/charts/tree/master/bitnami/wordpress|https://github.com/bitnami/charts/tree/master/bitnami/wordpress]] +
-  * [[https://bitnami.com/stack/wordpress/helm|https://bitnami.com/stack/wordpress/helm]] +
-  * [[https://github.com/bitnami/charts/tree/master/bitnami/wordpress/#installing-the-chart|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''. 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|https://github.com/bitnami/charts/blob/master/bitnami/wordpress/values.yaml]]+Ma configuration ''helm'' wordpress se base sur https://github.com/bitnami/charts/blob/master/bitnami/wordpress/values.yaml
  
 Ajout catalogue chart bitnami dans rancher : Ajout catalogue chart bitnami dans rancher :
- 
   * Add catalog   * Add catalog
   * Global catalog   * Global catalog
-  * Utiliser cette adresse [[https://charts.bitnami.com/bitnami|https://charts.bitnami.com/bitnami]]+  * 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 :) 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 :** **Ma configuration :**
- 
 <file yaml wordpress_helm_values.yaml> <file yaml wordpress_helm_values.yaml>
 ## Global Docker image parameters ## Global Docker image parameters
Ligne 526: Ligne 503:
         - ReadWriteOnce         - ReadWriteOnce
       size: 8Gi       size: 8Gi
- 
 </file> </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>+<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 ==== ==== Configurer le (seul et unique) ingress pour causer avec le backend wordpress ====
  
-Cette documentation comporte des informations qui peuvent être utiles : [[https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes|https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes]]+Cette documentation comporte des informations qui peuvent être utiles : https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes
  
-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|https://itnext.io/save-on-your-aws-bill-with-kubernetes-ingress-148214a79dcb]]+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 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 : On crée le fichier de configuration :
- 
 <code bash> <code bash>
 nano staging_issuer.yaml nano staging_issuer.yaml
- 
 </code> </code>
  
 Avec son contenu : Avec son contenu :
- 
 <file yaml staging_issuer.yaml> <file yaml staging_issuer.yaml>
 apiVersion: cert-manager.io/v1alpha2 apiVersion: cert-manager.io/v1alpha2
Ligne 568: Ligne 543:
        ingress:        ingress:
          class:  nginx          class:  nginx
- 
 </file> </file>
  
 On déploie l'issuer pour les tests : On déploie l'issuer pour les tests :
- 
 <code bash> <code bash>
 kubectl create -f staging_issuer.yaml kubectl create -f staging_issuer.yaml
- 
 </code> </code>
  
 On crée ensuite la configuration pour la production : On crée ensuite la configuration pour la production :
- 
 <code bash> <code bash>
 nano prod_issuer.yaml nano prod_issuer.yaml
- 
 </code> </code>
  
 Le contenu du fichier : Le contenu du fichier :
- 
 <file yaml prod_issuer.yaml> <file yaml prod_issuer.yaml>
 apiVersion: cert-manager.io/v1alpha2 apiVersion: cert-manager.io/v1alpha2
Ligne 607: Ligne 576:
         ingress:         ingress:
           class: nginx           class: nginx
- 
 </file> </file>
  
 **Et enfin, une fois la configuration de base let'sencrypt faite, on passe à la configuration ingress pour notre wordpress :** **Et enfin, une fois la configuration de base let'sencrypt faite, on passe à la configuration ingress pour notre wordpress :**
- 
 <code bash> <code bash>
 nano wordpress_ingress.yaml nano wordpress_ingress.yaml
- 
 </code> </code>
  
 Le contenu du fichier : Le contenu du fichier :
- 
 <file yaml wordpress_ingress.yaml> <file yaml wordpress_ingress.yaml>
 apiVersion: networking.k8s.io/v1beta1 apiVersion: networking.k8s.io/v1beta1
Ligne 640: Ligne 605:
           serviceName: wordpress           serviceName: wordpress
           servicePort: 80           servicePort: 80
- 
 </file> </file>
  
 Maintenant que tous les fichiers de configuration sont prets, on passe au **deploiement**. 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)//  : +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> <code bash>
 kubectl create -f staging_issuer.yaml kubectl create -f staging_issuer.yaml
- 
 </code> </code>
  
-**Le déploiement du ''letsEncrypt''  de prod et de la configuration ingress de wordpress**  //(avec certificat letsEncrypt)//  : +**Le déploiement du ''letsEncrypt'' de prod et de la configuration ingress de wordpress** //(avec certificat letsEncrypt)// :
 <code bash> <code bash>
 kubectl create -f prod_issuer.yaml kubectl create -f prod_issuer.yaml
 kubectl apply -f  wordpress_ingress.yaml kubectl apply -f  wordpress_ingress.yaml
- 
 </code> </code>
  
 Pour vérifier que la génération de certificat fonctionne : Pour vérifier que la génération de certificat fonctionne :
- 
 <code bash> <code bash>
 kubectl describe certificate wordpress-tls kubectl describe certificate wordpress-tls
- 
 </code> </code>
  
-<note info> Les commandes ci-dessous peuvent être utiles pour des fins de début. Elles ne sont pas nécessaires à l'installation. </note>+<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 : Avoir des infos sur le ingress wordpress :
- 
 <code bash> <code bash>
 kubectl get ing -n wordpress kubectl get ing -n wordpress
- 
 </code> </code>
  
 Des infos de manière plus détaillée : Des infos de manière plus détaillée :
- 
 <code bash> <code bash>
 kubectl describe ing wordpress-ingress -n wordpress kubectl describe ing wordpress-ingress -n wordpress
- 
 </code> </code>
  
 ==== Configuration wordpress ==== ==== Configuration wordpress ====
  
-<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.+<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.
  
-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>+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>
  
-<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.+<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. 
  
-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. </note>+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. 
 +</note>
  
-**Sinon, en vrac, les quelques choses que j'ai du faire //(à remettre en forme un jour)//  :** +**Sinon, en vrac, les quelques choses que j'ai du faire //(à remettre en forme un jour)// :** 
- +  * ''Export'' dans le site d'origine wordpress (via les fonction admin) des articles & média 
-  * ''Export''  dans le site d'origine wordpress (via les fonction admin) des articles & média +  * ''Import'' dans le nouveau site des media puis articles séparés en associant l'ancien auteur au nouveau 
-  * ''Import''  dans le nouveau site des media puis articles séparés en associant l'ancien auteur au nouveau +  * 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/
-  * 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/|https://fr.wordpress.org/plugins/better-search-replace/]]+
   * Changer la langue en Français   * Changer la langue en Français
   * Changer le slogan du blog   * Changer le slogan du blog
Ligne 708: Ligne 667:
   * Plus généralement faire un tour général des configurations   * Plus généralement faire un tour général des configurations
  
-<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.+<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. 
  
-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à. </note>+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à. 
 +</note>
  
-<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.+<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. 
  
-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>+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>
  
 ==== Configuration du theme ==== ==== Configuration du theme ====
  
 En vrac pour le thème : En vrac pour le thème :
- 
   * Choix du thème ''twenty seventeen''   * Choix du thème ''twenty seventeen''
   * Suppression des autres themes   * Suppression des autres themes
Ligne 728: Ligne 690:
  
 **Le contenu du custom CSS à mettre dans la personnalisation du thème :** **Le contenu du custom CSS à mettre dans la personnalisation du thème :**
- 
 <code css> <code css>
 @media screen and (min-width: 48em) { @media screen and (min-width: 48em) {
   .wrap {   .wrap {
-    max-width: 1500px;+    max-width: 1500px;  
   }   }
   .has-sidebar:not(.error404) #primary {   .has-sidebar:not(.error404) #primary {
Ligne 741: Ligne 702:
   }   }
 } }
- 
 </code> </code>
  
 **Ma sélection d'extension sur cette base d'image bitnami :** **Ma sélection d'extension sur cette base d'image bitnami :**
- 
   * Activer Askimet   * Activer Askimet
-  * **__NE PAS__**  Installer Apocalyspe Meow //(sauf si mode proxy mais il fait planter d'autres truc comme site health)//+  * **__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 All-in-One WP Migration
   * Désinstaller AMP   * Désinstaller AMP
Ligne 756: Ligne 715:
   * Activer Simple Tags //(utile pour avoir un nuage de tag avec des tailles différentes par fréquence d'utilisation)//   * 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   * Désinstaller WP Mail SMTP
-  * Desinstaller wordpress importer //(Plus besoin une fois l'import fait)//<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>+  * Desinstaller wordpress importer //(Plus besoin une fois l'import fait)// 
 + 
 +<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>
  
 ==== La guerre pour faire fonctionner apocalype meow ==== ==== La guerre pour faire fonctionner apocalype meow ====
  
-<note important> **[IMPORTANT]**  Cette partie est expérimentale et n'a pas complètement été menée à son terme. </note>+<note important> 
 +**[IMPORTANT]** Cette partie est expérimentale et n'a pas complètement été menée à son terme. 
 +</note>
  
 Quelques références : Quelques références :
- +  * https://elwpin.com/2019/03/14/quick-fix-for-cloudflare-and-php-remote_addr-ip-detector/ 
-  [[https://elwpin.com/2019/03/14/quick-fix-for-cloudflare-and-php-remote_addr-ip-detector/|https://elwpin.com/2019/03/14/quick-fix-for-cloudflare-and-php-remote_addr-ip-detector/]] +  * https://github.com/bitnami/bitnami-docker-wordpress/issues/178
-  * [[https://github.com/bitnami/bitnami-docker-wordpress/issues/178|https://github.com/bitnami/bitnami-docker-wordpress/issues/178]]+
  
 C'est un des trucs qui a contribué à la fin à me faire changer complètement d'infra de serveur. C'est un des trucs qui a contribué à la fin à me faire changer complètement d'infra de serveur.
Ligne 779: Ligne 743:
 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. 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)//  : +On se connecte au conteneur et on modifie les fichiers //(le nom du conteneur va forcément changer pour vous)// :
 <code bash> <code bash>
 kubectl exec -ti -n wordpress wordpress-5498fdfdd6-b5nxw -- bash kubectl exec -ti -n wordpress wordpress-5498fdfdd6-b5nxw -- bash
 cp wp-config.php wp-config.php.back cp wp-config.php wp-config.php.back
 chmod +w wp-config.php.back chmod +w wp-config.php.back
-echo "">> wp-config.php.back +echo "" >> wp-config.php.back 
-echo "// Fix the REMOTE_ADDR value (since not possible to simply fix it in httpd with docker image)">> wp-config.php.back +echo "// Fix the REMOTE_ADDR value (since not possible to simply fix it in httpd with docker image)" >> wp-config.php.back 
-echo "if (isset(\$_SERVER[\"HTTP_X_REAL_IP\"])) {">> wp-config.php.back +echo "if (isset(\$_SERVER[\"HTTP_X_REAL_IP\"])) {" >> wp-config.php.back 
-echo "\$_SERVER[\"REMOTE_ADDR\"] = \$_SERVER[\"HTTP_X_REAL_IP\"];">> wp-config.php.back3 +echo "\$_SERVER[\"REMOTE_ADDR\"] = \$_SERVER[\"HTTP_X_REAL_IP\"];" >> wp-config.php.back3 
-echo "}">> wp-config.php.back+echo "}" >> wp-config.php.back
 chmod -w wp-config.php.back chmod -w wp-config.php.back
- 
 </code> </code>
  
-Une fois que tout est bon //(après vérification donc)//  on peut déployer la nouvelle configuration : +Une fois que tout est bon //(après vérification donc)// on peut déployer la nouvelle configuration :
 <code bash> <code bash>
 cp cp wp-config.php.back wp-config.php cp cp wp-config.php.back wp-config.php
- 
 </code> </code>
  
Ligne 804: Ligne 764:
  
 Visiblement notre ami rale après installation. De ce que j'ai trouvé c'est lié à un problème de droit : Visiblement notre ami rale après installation. De ce que j'ai trouvé c'est lié à un problème de droit :
- 
 <code bash> <code bash>
 chmod 775 wp-config.php chmod 775 wp-config.php
- 
 </code> </code>
  
-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/203]]+Une référence qui m'a aidé : https://github.com/bitnami/bitnami-docker-wordpress/issues/203
  
 ===== Changement DNS vivihome.net ===== ===== Changement DNS vivihome.net =====
  
 Comme il s'agit d'une migration, penser à mettre à jour les DNS de l'ancien site : Comme il s'agit d'une migration, penser à mettre à jour les DNS de l'ancien site :
- 
   * Supprimer les anciennes défiitions   * Supprimer les anciennes défiitions
-  * Ajouter une redirection visible vers une adresse web //(pas une ip donc)//  avec un code http **redirection permanente** +  * Ajouter une redirection visible vers une adresse web //(pas une ip donc)// avec un code http **redirection permanente**   
 +
 ===== Commandes utiles en vrac ===== ===== Commandes utiles en vrac =====
  
 Excecuter un petit shell dans son conteneur wordpress à des fin de debug par exemple : Excecuter un petit shell dans son conteneur wordpress à des fin de debug par exemple :
- 
 <code bash> <code bash>
 kubectl exec -ti -n wordpress wordpress-5498fdfdd6-hrhfp /bin/bash kubectl exec -ti -n wordpress wordpress-5498fdfdd6-hrhfp /bin/bash
- 
 </code> </code>
  
 Exectuer un conteneur oneshot pour avoir shell : Exectuer un conteneur oneshot pour avoir shell :
- 
 <code bash> <code bash>
 kubectl run my-shell --rm -i --tty --image ubuntu -- bash kubectl run my-shell --rm -i --tty --image ubuntu -- bash
- 
 </code> </code>
  
Ligne 839: Ligne 792:
 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)//. 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|https://helm.mox.sh]].+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 :** **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
 +  * https://github.com/javimox/helm-charts
 +  * https://github.com/javimox/helm-charts/releases
 +  * https://github.com/javimox/helm-charts/tree/master/charts
  
-  * [[https://hub.helm.sh/charts/mox/jira-software|https://hub.helm.sh/charts/mox/jira-software]] +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''.
-  * [[https://hub.helm.sh/charts/mox/confluence-server|https://hub.helm.sh/charts/mox/confluence-server]] +
-  * [[https://github.com/javimox/helm-charts|https://github.com/javimox/helm-charts]] +
-  * [[https://github.com/javimox/helm-charts/releases|https://github.com/javimox/helm-charts/releases]] +
-  * [[https://github.com/javimox/helm-charts/tree/master/charts|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''.+
  
 **Le drame avec les ressources :** **Le drame avec les ressources :**
  
-Ne pas oublier que les déploiements sont fait à l'origine sur des nodes ''DEV-M''  avec de mémoire ''4Go''  de RAM. Sachant que JIRA dans la config helm en requiert ''2G''  de réservés. Ces besoins assez importants qui devront être partagé avec les éventuels autres conteneurs déployés sur le node qui sera élu. Or, la litérature sur le net doit normalement le confirmer, java a du mal (moins avec les versions récentes) avec les conteneurs notamment sur la gestion de la mémoire. Et la le police kubernetes arrive avec du ''OOMkill''  ou autre.+Ne pas oublier que les déploiements sont fait à l'origine sur des nodes ''DEV-M'' avec de mémoire ''4Go'' de RAM. Sachant que JIRA dans la config helm en requiert ''2G'' de réservés. Ces besoins assez importants qui devront être partagé avec les éventuels autres conteneurs déployés sur le node qui sera élu. Or, la litérature sur le net doit normalement le confirmer, java a du mal (moins avec les versions récentes) avec les conteneurs notamment sur la gestion de la mémoire. Et la le police kubernetes arrive avec du ''OOMkill'' ou autre.
  
-C'est un peu ce qui a du m'arriver à ce stade, j'ai eu la joie d'avoir des [[https://sysdig.com/blog/debug-kubernetes-crashloopbackoff/|https://sysdig.com/blog/debug-kubernetes-crashloopbackoff/]] ou autres joyeusetées.+C'est un peu ce qui a du m'arriver à ce stade, j'ai eu la joie d'avoir des https://sysdig.com/blog/debug-kubernetes-crashloopbackoff/ ou autres joyeusetées.
  
-**Autre problème à corriger**  le ''liveness''  et le ''readiness''  qu'il faut adapter car au premier démarrage jira et confluence mettent un temps infini a démarrer et se préparer (phase d'install). Donc par défaut kubernetes perds patience et des timeout se déclenchent pour voir finalement son conteneur redémarré par kubernetes sans que le démarrage soit terminé.+**Autre problème à corriger** le ''liveness'' et le ''readiness'' qu'il faut adapter car au premier démarrage jira et confluence mettent un temps infini a démarrer et se préparer (phase d'install). Donc par défaut kubernetes perds patience et des timeout se déclenchent pour voir finalement son conteneur redémarré par kubernetes sans que le démarrage soit terminé.
  
-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). 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+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). 
 + 
 +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 ===== ===== Conclusion =====
Ligne 868: Ligne 822:
  
 Mes feedbacks plus détaillés sur mon blog : Mes feedbacks plus détaillés sur mon blog :
- +  * https://alban.montaigu.io/2020/05/26/premiers-retours-sur-la-nouvelle-infra-alban-montaigu-io/ 
-  [[https://alban.montaigu.io/2020/05/26/premiers-retours-sur-la-nouvelle-infra-alban-montaigu-io/|https://alban.montaigu.io/2020/05/26/premiers-retours-sur-la-nouvelle-infra-alban-montaigu-io/]] +  * https://alban.montaigu.io/2020/05/26/second-retour-sur-la-nouvelle-infra-alban-montaigu-io/ 
-  * [[https://alban.montaigu.io/2020/05/26/second-retour-sur-la-nouvelle-infra-alban-montaigu-io/|https://alban.montaigu.io/2020/05/26/second-retour-sur-la-nouvelle-infra-alban-montaigu-io/]] +  * https://alban.montaigu.io/2020/05/27/retour-en-2013-2014-nouvelle-infra-montaigu-io/
-  * [[https://alban.montaigu.io/2020/05/27/retour-en-2013-2014-nouvelle-infra-montaigu-io/|https://alban.montaigu.io/2020/05/27/retour-en-2013-2014-nouvelle-infra-montaigu-io/]] +
- +
  • guide/installation_kapsule_2020.txt
  • Dernière modification : 2021/04/18 22:24
  • de 127.0.0.1