docs: new content

capsule/content/gemlog/2022-11-17-migration-serveur-on-avance.gmi

@@ -1,6 +1,8 @@
 ---
 title: migration serveur ça avance
 date: 2022-11-17
+params:
+  tags: migration, auto-hébergement
 ---
 
 Depuis quelques semaines, je tente d'appliquer une simplification de mon infrastructure pour mon auto-hébergement. Comme je l'indiquais dans mon précédent billet, utiliser kubernetes pour mon besoin n'était pas très judicieux. Et donc voici l'avancement de cette nouvelle migration.

capsule/content/gemlog/2022-11-24-Migration-terminée.gmi

@@ -0,0 +1,37 @@
+---
+title: Migration terminée
+date: 2022-11-24
+params:
+  tags: migration,auto-hébergement
+---
+
+Le week-end dernier j'ai lancé les différentes migrations de mes services restant sur mon nouveau serveur:
+
+* Wallabag
+* TT-RSS + RSS bridge
+* Wiki.js
+* Ce gemlog et mon proxy https
+
+Tout s'est globalement bien passé et sans encombre. J'avais un playbook ansible pour restaurer mes données que j'ai pu réutiliser et cela m'a fait gagner beaucoup de temps. La "mauvaise" surprise s'est située avec ma façon de déposer mes backups sur un bucket Scaleway. Il s'avère que s3fs n'est pas compatible avec LXC ou tout au moins, il fallait que j'active des options que je ne souhaitais pas sur mon serveur de base de données. Mais au final, on m'a fait découvrir s3cmd qui est bien plus simple à utiliser. Du coup un mal pour un bien. Bon par contre, la granularité des droits pour accéder à un bucket n'est pas au rendez-vous chez Scaleway. Pour se connecter, il faut les credentials de l'utilisateur qui dispose de bien plus de droit que simplement lire / écrire sur le bucket cible (créer des instances ou en détruire...).
+
+J'ai passé une partie de mon week-end et début de semaine sur mon wiki fraichement migré. L'idée étant de plus l'utiliser qu'actuellement. Wiki.js est un peu jeune et il manque quelques fonctionnalités essentielles comme l'organisation des pages. J'ai donc voulu le faire depuis mon dépôt git mais ça n'a pas tout à fait fonctionné comme je le pensais. Ceci dit après avoir râlé, tenté de trouver une alternative (gollum à l'air sympa malgré tout), j'ai tenté de comprendre le fonctionnement et j'ai fini par trouver un contournement. Pour faire simple, le déplacement d'une page via git n'est pas prise en compte lors de la synchro. Ce n'est pas considéré comme une nouvelle page. On se retrouve donc avec des pages présentes sur le dépôt git qui n'ont pas été créées et d'autres sur le wiki qui ne sont plus suivies dans git. À coup d'import, d'ajout de page non suivies et de revert, j'ai fini par réussir à tout remettre dans l'ordre. J'espère vraiment que les fonctionnalités arriveront dans les prochaines versions !
+
+D'ailleurs, j'ai vu passé un lien intéressant autour du "Digital Garden" [1] qui semble plus ou moins correspondre à ce que je cherche à faire sur mon wiki.
+
+J'ai arrêté mes serveurs Hetzner ce dimanche et à priori tout c'est bien passé. Je vais donc pouvoir les supprimer.
+
+Bon, par contre, j'ai encore du travail: 
+
+* Migrer mes différents dépôts git qui le peuvent sur mon gitea
+* Regarder si mettre en place DroneCI est possible pour construire mes images dockers directement sur ce serveur plutôt que d'utiliser les runners de gitlab.com
+* Continuer de créer les playbooks Ansible qui me manque, notamment pour HAproxy et les certificats
+* Mettre au propre les différentes ouvertures de flux réalisées
+* Faciliter l'accès aux  serveurs via SSH plutôt que faire des rebonds
+* Ajouter prometheus / grafana que j'ai mis de côté pour l'instant
+* Déplacer les applications containers sous un utilisateur par application
+* Voir si je me lance dans l'hébergement d'un serveur Nextcloud
+
+Et bien sûr, le plus important, continuer à alimenter mon wiki avec tout ce que j'ai appris ! [2]
+
+==> https://maggieappleton.com/garden-history [1] Article sur les "digital gardens" (en)
+==> https://wiki.valvin.fr [2] mon wiki