Quelques petites choses à réfléchir avant de se lancer. Quelle version de moteur network Kubernetes, quel OS etc.
En vrac :
Dans l'interface web scaleway https://console.scaleway.com, aller dans la partie kapsule et créer son cluster kubernetes.
Les infos à saisir :
ingress car je prévois d'installer le mien, à ma façonDEV-M pour limiter le cout tout en ayant quand même 3 noeudsJ'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.
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 :
Un peu d'attente et ensuite il est possible de s'y connecter en SSH.
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.
apt-get update apt-get upgrade -y
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
apt-get update && apt-get install -y apt-transport-https curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | tee -a /etc/apt/sources.list.d/kubernetes.list apt-get update apt-get install -y kubectl
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.
Puis installation sur le serveur après téléchargement :
mkdir ~/.kube cp kubeconfig-k8s-01.yaml ~/.kube/config
Pour vérifier que tout fonctionne on essaye d'obtenir les infos du cluster kapsule :
kubectl cluster-info
Après avoir regardé un peu, il m'a semblé que le plus simple d'installation et de mise à jour dans le temps consiste à utiliser snap.
snap install helm --classic
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
helm repo add stable https://kubernetes-charts.storage.googleapis.com
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.
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…
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 a été d'une grande aide pour avoir des infos sur la compatibilité et ce que mon serveur sait faire.
Quelques liens utiles:
Donc pour améliorer la compatibilté il suffit d'ajouter 1 ou deux ciphers weak qui sont pris en charge par les vieux navigateurs :
ssl-protocols: "TLSv1.2 TLSv1.3" ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;"
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) :
ssl-redirect: "false"
Sinon les suites cipher ci-dessous (weak) ne sont pas dispo et ne premettent plus de supporter les vieilles config comme justement notre ami ie11.
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
Les commandes ci-dessous peuvent être utiles pour debug un peu le TLS (a adapter en fonction de votre domaine bien sur) :
curl -v --tlsv1.3 -s https://alban.montaigu.io/wp-json > /dev/null curl -v -s http://alban.montaigu.io/wp-json > /dev/null
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 :
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).
Préparation de l'installation du ingress avec helm :
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx kubectl create namespace ingress-nginx
Ensuite avec le fichier de configuration suivant :
## nginx configuration ## Ref: https://github.com/kubernetes/ingress/blob/master/controllers/nginx/configuration.md ## controller: # Will add custom configuration options to Nginx https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/ config: { proxy-connect-timeout: "30", proxy-read-timeout: "1800", proxy-send-timeout: "1800", proxy-body-size: "500m", use-proxy-protocol: "true", proxy-real-ip-cidr: "51.159.75.81/32", compute-full-forwarded-for: "true", use-forwarded-headers: "true", ssl-redirect: "true", ssl-protocols: "TLSv1.2 TLSv1.3", ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;" } ## Allows customization of the source of the IP address or FQDN to report ## in the ingress status field. By default, it reads the information provided ## by the service. If disable, the status field reports the IP address of the ## node or nodes where an ingress controller pod is running. publishService: enabled: true service: annotations: { # service.beta.kubernetes.io/scw-loadbalancer-send-proxy-v2: "true" } ## Set external traffic policy to: "Local" to preserve source IP on ## providers supporting it ## Ref: https://kubernetes.io/docs/tutorials/services/source-ip/#source-ip-for-services-with-typeloadbalancer externalTrafficPolicy: Local
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.
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.
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.
On déploie l'ingress avec les bonnes options de configuration :
helm install ingress-nginx ingress-nginx/ingress-nginx -f ingress_nginx_helm_values.yaml -n ingress-nginx
A noter qu'il est possible aussi d'appliquer des configurations à postériori comme décrit ci dessous.
Un peu de documentation utile (intégrée aussi pour la définition du helm values) :
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.
Un exemple du fichier de configuration en question :
kind: ConfigMap apiVersion: v1 metadata: name: ingress-nginx-ingress-nginx-controller namespace: ingress-nginx data: proxy-connect-timeout: "30" proxy-read-timeout: "1800" proxy-send-timeout: "1800" proxy-body-size: "500m" use-proxy-protocol: "true" proxy-real-ip-cidr: "51.159.75.81/32" compute-full-forwarded-for: "true" use-forwarded-headers: "true" ssl-redirect: "true" ssl-protocols: "TLSv1.2 TLSv1.3" ssl-ciphers: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;"
Et la commande pour l'appliquer :
kubectl apply -f ingress_nginx_config.yaml
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 !
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 :
On prépare les repo helm :
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable helm repo add jetstack https://charts.jetstack.io helm repo update
On crée les namespaces qui seront utiles plus tard :
kubectl create namespace cattle-system kubectl create namespace cert-manager
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 :
# 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
On utilise plutot la méthode d'installation proposée par cert-manager (la version peut être à mettre à jour) :
helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v0.15.0 --set installCRDs=true
Et on vérifie que tout fonctionne bien comme cela par exemple :
kubectl get pods --namespace cert-manager
On continue avec l'install de rancher (ici avec option letsEncrypt, à adapter avec vos infos à vous) :
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
Et on vérifie l'avancement du déploiement / que tout se passe bien avant de passer à la suite :
kubectl -n cattle-system rollout status deploy/rancher kubectl -n cattle-system get deploy rancher
Il n'est pas inutile non plus de vérifier les certificats letsEncrypt :
kubectl -n cattle-system describe certificate kubectl -n cattle-system describe issuer
La commande en question pour reset le 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
La documentation / le contenu de référence :
J'ai retenu le chart bitnami plutôt que celui proposé par rancher car il est plus récent. Et de toutes façons rancher s'inspire du chart bitnami.
Donc a ce stade go dans la gestion des catalogues de rancher, ajouter la référence vers les charts bitnami et utiliser à la fin la fonction de launch app en choisissant wordpress.
Ma configuration helm wordpress se base sur https://github.com/bitnami/charts/blob/master/bitnami/wordpress/values.yaml
Ajout catalogue chart bitnami dans rancher :
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 :
## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## ## User of the application ## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables ## wordpressUsername: MON_USER ## Application password ## Defaults to a random 10-character alphanumeric string if not set ## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables ## wordpressPassword: MON_PASSWORD ## Admin email ## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables ## wordpressEmail: MON_EMAIL ## First name ## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables ## wordpressFirstName: Alban ## Last name ## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables ## wordpressLastName: Montaigu ## Blog name ## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables ## wordpressBlogName: Alban's Home ## Set up update strategy for wordpress installation. Set to Recreate if you use persistent volume that cannot be mounted by more than one pods to makesure the pods is destroyed first. ## ref: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy ## Example: ## updateStrategy: ## type: RollingUpdate ## rollingUpdate: ## maxSurge: 25% ## maxUnavailable: 25% updateStrategy: type: Recreate ## Kubernetes configuration ## For minikube, set this to NodePort, elsewhere use LoadBalancer or ClusterIP ## service: type: ClusterIP ## HTTP Port ## ## Enable client source IP preservation ## ref http://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip ## externalTrafficPolicy: Local ## Configure the ingress resource that allows you to access the ## WordPress installation. Set up the URL ## ref: http://kubernetes.io/docs/user-guide/ingress/ ## ingress: ## Set to true to enable ingress record generation ## enabled: false ## Set this to true in order to add the corresponding annotations for cert-manager ## certManager: false ## Enable persistence using Persistent Volume Claims ## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/ ## persistence: enabled: true ## wordpress data Persistent Volume Storage Class ## If defined, storageClassName: <storageClass> ## If set to "-", storageClassName: "", which disables dynamic provisioning ## If undefined (the default) or set to null, no storageClassName spec is ## set, choosing the default provisioner. (gp2 on AWS, standard on ## GKE, AWS & OpenStack) ## storageClass: "scw-bssd-retain" ## ## If you want to reuse an existing claim, you can pass the name of the PVC using ## the existingClaim variable # existingClaim: your-claim accessMode: ReadWriteOnce size: 10Gi ## ## MariaDB chart configuration ## ## https://github.com/bitnami/charts/blob/master/bitnami/mariadb/values.yaml ## mariadb: ## Whether to deploy a mariadb server to satisfy the applications database requirements. To use an external database set this to false and configure the externalDatabase parameters enabled: true ## Enable persistence using Persistent Volume Claims ## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/ ## master: persistence: enabled: true ## mariadb data Persistent Volume Storage Class ## If defined, storageClassName: <storageClass> ## If set to "-", storageClassName: "", which disables dynamic provisioning ## If undefined (the default) or set to null, no storageClassName spec is ## set, choosing the default provisioner. (gp2 on AWS, standard on ## GKE, AWS & OpenStack) ## storageClass: "scw-bssd-retain" accessModes: - ReadWriteOnce size: 8Gi
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é.
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
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 :
nano staging_issuer.yaml
Avec son contenu :
apiVersion: cert-manager.io/v1alpha2 kind: ClusterIssuer metadata: name: letsencrypt-staging namespace: cert-manager spec: acme: # The ACME server URL server: https://acme-staging-v02.api.letsencrypt.org/directory # Email address used for ACME registration email: MON_MAIL # Name of a secret used to store the ACME account private key privateKeySecretRef: name: letsencrypt-staging # Enable the HTTP-01 challenge provider solvers: - http01: ingress: class: nginx
On déploie l'issuer pour les tests :
kubectl create -f staging_issuer.yaml
On crée ensuite la configuration pour la production :
nano prod_issuer.yaml
Le contenu du fichier :
apiVersion: cert-manager.io/v1alpha2 kind: ClusterIssuer metadata: name: letsencrypt-prod namespace: cert-manager spec: acme: # The ACME server URL server: https://acme-v02.api.letsencrypt.org/directory # Email address used for ACME registration email: MON_MAIL # Name of a secret used to store the ACME account private key privateKeySecretRef: name: letsencrypt-prod # Enable the HTTP-01 challenge provider solvers: - http01: ingress: class: nginx
Et enfin, une fois la configuration de base let'sencrypt faite, on passe à la configuration ingress pour notre wordpress :
nano wordpress_ingress.yaml
Le contenu du fichier :
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: wordpress-ingress namespace: wordpress annotations: kubernetes.io/ingress.class: "nginx" cert-manager.io/cluster-issuer: "letsencrypt-prod" spec: tls: - hosts: - alban.montaigu.io secretName: wordpress-tls rules: - host: alban.montaigu.io http: paths: - backend: serviceName: wordpress servicePort: 80
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) :
kubectl create -f staging_issuer.yaml
Le déploiement du letsEncrypt de prod et de la configuration ingress de wordpress (avec certificat letsEncrypt) :
kubectl create -f prod_issuer.yaml kubectl apply -f wordpress_ingress.yaml
Pour vérifier que la génération de certificat fonctionne :
kubectl describe certificate wordpress-tls
Avoir des infos sur le ingress wordpress :
kubectl get ing -n wordpress
Des infos de manière plus détaillée :
kubectl describe ing wordpress-ingress -n wordpress
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…
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.
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édiaImport dans le nouveau site des media puis articles séparés en associant l'ancien auteur au nouveauDans tous les cas j'ai essayé de le corriger mais cela à complètement fait planter mon site. Donc je me suis arrêté là.
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.
En vrac pour le thème :
twenty seventeenAvec quelques modification CSS pour une largeur page adequate (j'aime bien les sites qui prennent toute la page). A mettre dans le custom css.
Le contenu du custom CSS à mettre dans la personnalisation du thème :
@media screen and (min-width: 48em) { .wrap { max-width: 1500px; } .has-sidebar:not(.error404) #primary { width: 70%; } .has-sidebar #secondary { width: 24%; } }
Ma sélection d'extension sur cette base d'image bitnami :
Quelques références :
C'est un des trucs qui a contribué à la fin à me faire changer complètement d'infra de serveur.
Il se trouve que pour bien fonctionner, ce cher plugin à besoin de l'ip réelle source du client. Logique, sauf que comme évoqué ce n'est pas si simple à configurer.
En effet, comme le plugin a des fonctions de ban d'ip source si tentative de bruteforce sur l'admin, il lui faut bien l'information quelque part.
Sauf que voilà, en admetant que vous avez configuré votre cluster kubernetes correctement, il se trouve que dans les options (en tout cas pour moi à ce moment), le plugin ne permet pas de sélectionner le header http qui continent l'ip source. Plus exactement la configuration existe, mais à chaque enregistrement on revient à la valeur de base, la mauvaise évidemment.
Les commandes suivantes sont donc une tentative de hack pour mettre les bonnes valeurs dans le bon champ puisque le plugin ne permet pas le choix.
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) :
kubectl exec -ti -n wordpress wordpress-5498fdfdd6-b5nxw -- bash cp wp-config.php wp-config.php.back chmod +w wp-config.php.back echo "" >> wp-config.php.back 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 "\$_SERVER[\"REMOTE_ADDR\"] = \$_SERVER[\"HTTP_X_REAL_IP\"];" >> wp-config.php.back3 echo "}" >> wp-config.php.back chmod -w wp-config.php.back
Une fois que tout est bon (après vérification donc) on peut déployer la nouvelle configuration :
cp cp wp-config.php.back wp-config.php
Visiblement notre ami rale après installation. De ce que j'ai trouvé c'est lié à un problème de droit :
chmod 775 wp-config.php
Une référence qui m'a aidé : https://github.com/bitnami/bitnami-docker-wordpress/issues/203
Comme il s'agit d'une migration, penser à mettre à jour les DNS de l'ancien site :
Excecuter un petit shell dans son conteneur wordpress à des fin de debug par exemple :
kubectl exec -ti -n wordpress wordpress-5498fdfdd6-hrhfp /bin/bash
Exectuer un conteneur oneshot pour avoir shell :
kubectl run my-shell --rm -i --tty --image ubuntu -- bash
On le fait toujours dans rancher via un helm chart bien choisi qu'on ajoute dans les catalogues rancher. Cela permet ensuite de lancer une application pour installation (comme pour wordpress).
Ici on ajoute le catalogue helm mox dans rancher (via gestion des catalogues, ajout d'un catalogue helm 3) en utilisant cette URL : https://helm.mox.sh.
Quelques documents / liens de référence utilisés :
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 :
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/ 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é.
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…
Alors heureux ? Non pour être clair. J'ai passé un temps bien trop long à tatonner pour un résultat complexe, difficile à maintenir et en plus cher en hébergement.
J'ai du tout recommencer un nombre incalculable de fois parfois pour une erreur idiote. Donc oui c'est sexy, oui j'ai écrit ce guide pour ne pas perdre les connaissances acquises. Oui j'espère que cela pourra être utile à d'autres. Mais en vrai moi, je vais trouver une autre solution.
Mes feedbacks plus détaillés sur mon blog :