Migration du site

Migration du site

Introduction

Dans l’objectif d’optimiser un peu mon budget, voir ce petit article, j’ai décidé de bouger le blog vers un autre VPS. Cela va permettre de libérer de la ressource et accessoirement de payer un peu moins par mois mon petit VPS qui ne sert en ce moment que trop sporadiquement.

Admin Fail

One fail after one another, Minio a déprécié certaines variables et donc mon container ne fonctionnait plus très bien. Je dois d’abord réparer cette injustice dans ma sauvegarde… Une fois corrigé, le revoilà qui renaît de ses cendres, de plus ils ont ajouté un port console et ne passe plus par le port API. Bref je n’arrive pas à comprendre tout cela surtout quand on veut que tout se mette à jour frictionless… Pas le temps j’y reviendrais plus tard…

Je remarque au passage que le projet est devenu mature, bravo pour cette belle progression.

Enfin bon c’est de ma faute si j’avais supervisé l’accès à tous mes services, j’aurais probablement réparé tout ça. Mais bon moins d’efforts, plus de réconfort ailleurs, je vais y penser pour la prochaine…

Note : Cette migration elle se fera à la méthode la R.A.C.H.E, mère de toutes les méthodologies actuelles et seule à laquelle je peux me fier aujourd’hui…

Objectif : quick and easy

Bon le plan est de faire le même déploiement qu’actuellement et d’aller au plus rapide. Je vais compléter mes articles fleuves sur le DevSecOps en ajoutant une brique qui me faisait de l’oeil depuis le début : Calico.

Pour cela je déploie Calico sur k3s, tout est expliqué sur cette page pas besoin d’aller plus loin.

Note après migration : En vrai cette méthode de déploiement ne fonctionne pas bien surtout avec Traefik qui a besoin de l’IP forwarding activable dans le conteneur, alors privilégier cette méthode.

Installer Helm

curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -
sudo apt-get install apt-transport-https --yes
echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

Restaurer le driver de stockage

(Bon je suis root et je m’en balec)

# Installation du driver open-iscsi
apt install open-iscsi
systemctl status iscsid
systemctl enable --now iscsid
systemctl status iscsid

# Installation du repo openebs
helm repo add openebs https://openebs.github.io/charts
helm repo update

# Installation d'openebs
helm install openebs --namespace openebs openebs/openebs --create-namespace

# Mettre openebs par défaut :
kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
kubectl patch storageclass openebs-hostpath -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Installer Traefik

Bon là tout ce que j’avais prévu doit être mis à la poubelle, trop d’évolutions de Kubernetes depuis la dernière fois que j’ai mis les mains dedans. Pas grave, faut tout réécrire et mettre à jour mon Kustomize.

Voilà c’est déjà mieux…

Note : Il se peut que lors de la première installation la création des CRDs soit trop rapide vis à vis de la définition qui est effectuée avant. J’ai eu des problèmes de « rapidité », et j’ai juste eu besoin de ré-appliquer le Kustomize une fois de plus…

Installer WordPress

Après la mise à jour des versions, dans le fichier Kustomize de l’overlay prod, là ça redevient quick and easy…

Restaurer le site

Là je n’ai pas été dans la dentelle, j’ai juste utilisé le plugin « All in one WP Migration », qui fait tout de manière simple…

Conclusion

J’ai eu 2/3 jour de downtime pour faire la migration, j’en ai beaucoup plus souffert que prévu. Je ne prévoyais pas forcément ce chemin, mais le fait d’installer Calico au départ m’a ralenti, le fait que les versions d’API évoluent dans Kubernetes, cela à remis en cause aussi le coté « quick » de la chose. Maintenant cela fonctionne, il faudra que je revienne sur quelques points par la suite…