| 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] – alban | guide:installation_kapsule_2020 [2020/08/20 10:12] – alban |
|---|
| |
| **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/|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/|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|https://wiki.ubuntu.com/Releases]] et à ce jour c'est la version 20.04 |
| 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 systemOn 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. |
| | |
| 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. | |
| |
| <code bash> | <code bash> |
| apt-get update | apt-get update |
| apt-get upgrade -y | apt-get upgrade -y |
| | |
| </code> | </code> |
| |
| apt-get update | apt-get update |
| apt-get install -y kubectl | apt-get install -y kubectl |
| | |
| </code> | </code> |
| |
| mkdir ~/.kube | mkdir ~/.kube |
| cp kubeconfig-k8s-01.yaml ~/.kube/config | cp kubeconfig-k8s-01.yaml ~/.kube/config |
| | |
| </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> |
| |
| ==== Digression sur la récupération de l'ip client source ==== | **[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<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/]]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>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<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).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.**Quelques liens utiles:** |
| | |
| <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/]] | |
| | |
| 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> | |
| | |
| 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 ==== | |
| | |
| <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). | |
| | |
| 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. | |
| | |
| **Quelques liens utiles:** | |
| |
| * [[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/]] | * [[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/]] |
| * [[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/]] | * [[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> | <note important> |
| |
| **Préparation de l'installation du ingress avec 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)**. </note>**Préparation de l'installation du ingress avec helm :** |
| |
| <code bash> | <code bash> |
| **Ensuite avec le fichier de configuration suivant :** | **Ensuite avec le fichier de configuration suivant :** |
| |
| <file yaml ingress_nginx_helm_values.yaml> | ingress_nginx_helm_values.yaml |
| | |
| | <code yaml> |
| ## nginx configuration | ## nginx configuration |
| ## Ref: https://github.com/kubernetes/ingress/blob/master/controllers/nginx/configuration.md | ## Ref: https://github.com/kubernetes/ingress/blob/master/controllers/nginx/configuration.md |
| externalTrafficPolicy: Local | externalTrafficPolicy: Local |
| |
| </file> | </code> |
| | |
| <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 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 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> | <note info> |
| |
| **On déploie l'ingress avec les bonnes options de configuration :** | **[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 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 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 :** |
| |
| <code bash> | <code bash> |
| * [[https://github.com/kubernetes/ingress-nginx/issues/1067|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> |
| |
| Un exemple du fichier de configuration en question : | **[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 : |
| |
| <file yaml ingress_nginx_config.yaml> | ingress_nginx_config.yaml |
| | |
| | <code yaml> |
| kind: ConfigMap | kind: ConfigMap |
| apiVersion: v1 | apiVersion: v1 |
| ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;" | ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;" |
| |
| </file> | </code> |
| |
| Et la commande pour l'appliquer : | Et la commande pour l'appliquer : |
| </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> |
| | |
| 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 ===== | |
| | |
| 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 :** | **[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>Installation rancherA 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 :** |
| |
| * [[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/]] |
| </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> |
| |
| **Donc __ne pas appliquer__ les comdandes suivantes :** | **[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>**Donc __ne pas appliquer__ les comdandes suivantes :** |
| |
| <code bash> | <code bash> |
| </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> |
| |
| La commande en question pour reset le password : | **[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 : |
| |
| <code bash> | <code bash> |
| **Ma configuration :** | **Ma configuration :** |
| |
| <file yaml wordpress_helm_values.yaml> | wordpress_helm_values.yaml |
| | |
| | <code yaml> |
| ## Global Docker image parameters | ## Global Docker image parameters |
| ## Please, note that this will override the image parameters, including dependencies, configured to use the global value | ## Please, note that this will override the image parameters, including dependencies, configured to use the global value |
| size: 8Gi | size: 8Gi |
| |
| </file> | </code> |
| | |
| <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 ==== | |
| | |
| 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]] | |
| | |
| 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]] | |
| |
| 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)//. | <note important> |
| |
| On crée le fichier de configuration : | **[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 wordpressCette 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]]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]]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> | <code bash> |
| Avec son contenu : | Avec son contenu : |
| |
| <file yaml staging_issuer.yaml> | staging_issuer.yaml |
| | |
| | <code yaml> |
| apiVersion: cert-manager.io/v1alpha2 | apiVersion: cert-manager.io/v1alpha2 |
| kind: ClusterIssuer | kind: ClusterIssuer |
| class: nginx | class: nginx |
| |
| </file> | </code> |
| |
| On déploie l'issuer pour les tests : | On déploie l'issuer pour les tests : |
| Le contenu du fichier : | Le contenu du fichier : |
| |
| <file yaml prod_issuer.yaml> | prod_issuer.yaml |
| | |
| | <code yaml> |
| apiVersion: cert-manager.io/v1alpha2 | apiVersion: cert-manager.io/v1alpha2 |
| kind: ClusterIssuer | kind: ClusterIssuer |
| class: nginx | class: nginx |
| |
| </file> | </code> |
| |
| **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 :** |
| Le contenu du fichier : | Le contenu du fichier : |
| |
| <file yaml wordpress_ingress.yaml> | wordpress_ingress.yaml |
| | |
| | <code yaml> |
| apiVersion: networking.k8s.io/v1beta1 | apiVersion: networking.k8s.io/v1beta1 |
| kind: Ingress | kind: Ingress |
| servicePort: 80 | servicePort: 80 |
| |
| </file> | </code> |
| |
| 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**. |
| </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> |
| |
| Avoir des infos sur le ingress wordpress : | 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> | <code bash> |
| ==== 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> |
| |
| 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> | **[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><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>**Sinon, en vrac, les quelques choses que j'ai du faire //(à remettre en forme un jour)// :** |
| | |
| <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> | |
| | |
| **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 |
| * 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> |
| |
| 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> | **[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><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>Configuration du themeEn vrac pour le thème : |
| | |
| <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> | |
| | |
| ==== Configuration du theme ==== | |
| | |
| En vrac pour le thème : | |
| |
| * Choix du thème ''twenty seventeen'' | * Choix du thème ''twenty seventeen'' |
| * 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> |
| | |
| ==== 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> | |
| |
| Quelques références : | **[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<note important>**[IMPORTANT]** Cette partie est expérimentale et n'a pas complètement été menée à son terme. </note>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://elwpin.com/2019/03/14/quick-fix-for-cloudflare-and-php-remote_addr-ip-detector/]] |