Contexte

Infra

Sur mon infra perso, j’ai fais pas mal de choix à la va-vite, qui m’ont utiliser des solutions pas forcément adaptées. J’ai commencé aussi à avoir des gens que je connaissais avoir des besoins de sauvegarde, tout en sachant que j’ai un paquet d’espace libre sur mes serveurs.

Pas mal de ce qui tourne sur mon infra est encore sur des machines virtuelles séparées, et je commence à migrer des composants plutôt critiques sur mon cluster Kubernetes.

Par commencer par le serveur LDAP, qui fonctionne avec LLDAP, ou encore Gitea et son runner associé.

Cette infra doit être au moins la v10 de ma toute premiére infra, mais ça commence vraiment à être très stable, et le fait de tout uniformiser sur du kubernetes en est surement la cause (en plus du meilleur matos).

Dans les quelques composants pas encore migré vers du kubernetes (enfin de base minIO était installé sur mon cluster), j’ai le grand gagnant minIO, qui tourne dans un conteneur Docker sur ma machine virtuelle OpenMediaVault. Et il commence à me taper sur les nerfs malgré ses avantages.

MinIO

Exemple concret: MinIO. MinIO intégre un paquet de fonctionnalité, dont une interface graphique (accessible par un login Oauth2 ou LDAP), un gestion complexe à la AWS des ACL pour les accès au bucket, le multi-utilisateur.ice. Je ne referai pas la liste compléète mais minIO fonctionne très bien en tant que tel et n’a rien à envier à pas mal de stockages objets proprio.

Selon voilà le soucis: ça force à mort pour passer sur la version avec support qui coûte une blinde, et surtout j’ai aucune utilité des fonctionnalités supplémentaires apportés par cette autre version. En plus de ça, j’ai déjà eu plusieurs soucis avec minIO au niveau des performances sur HDD (qui m’ont refais migrer de Kubernetes vers une VM). 

Je souhaitais aussi exploiter le même endpoint S3 pour taper sur différents types de volumes (HDD, SDD, toussa), mais ça me semblait galére à mettre en place avec minIO.

En plus, autre soucis, c’est plutôt une purge pour mettre ça en place, et je souhaitais minimiser la moindre intervention via une interface graphique.

Sans compter que la boite derrière minIO a l’air plutôt aggressive au niveau des licenses (compréhensible malgré tout vu comment le boulot fait par les contributeur.ice.s de minIO est pompé par les entreprises sans payer la license ou apporter la moindre chose.)

Garage: c’est bien

Et puis j’ai vu que Garage existait! 

Dans mes points importants, la configuration uniquement via un fichier de config, pas de GUI (pour en mettre une autre qui s’appuirait sur les API si besoin évidemment), de meilleures performances, et en plus de ça avec une consommation modérée de ressources (200Mi de RAM, et 0.1 coeur de CPU).

Autre avantage: comme minIO, un helm-chart est fourni. Et il est un peu moins étoffé, tout comme le fichier de config généré: 

garage.toml

metadata_dir = "/mnt/meta"

data_dir = "/mnt/data"

db_engine = "sled"

block_size = 1048576

sled_cache_capacity = 134217728

sled_flush_every_ms = 2000

replication_mode = "1"

compression_level = 19

rpc_bind_addr = "[::]:3901"

# rpc_secret will be populated by the init container from a k8s secret object

rpc_secret = "__RPC_SECRET_REPLACE__"

bootstrap_peers = []

[kubernetes_discovery]

namespace = "garage"

service_name = "garage-cfast"

skip_crd = false

[s3_api]

s3_region = "eu-west-1"

api_bind_addr = "[::]:3900"

root_domain = ".cfast.s3.domain.local"

[s3_web]

bind_addr = "[::]:3902"

root_domain = ".cfast.garage.domain.local"

index = "index.html"

[admin]

api_bind_addr = "[::]:3903"

admin_token = "ohno"

Mon implémentation custom 

Déploiement

Eh ben, je déploie tout ça via un helm chart où j’ai fais un petit bidouillage custom, pour rajouter par exemple de l’ajout de PVC.

Enfin si, il y a un autre bidouillage: le helm chart en question est devenu un helm-chart parapluie, avec trois sous-helm-chart:

• Le “ucslow” correspond à l’espace disque qui n’est pas chiffré et qui est un RAID 5 de disques durs

• Le “cslow” correspond à l’espace disque chiffré et qui est un RAID 1 de disques durs

• Et le “cfast” à l’espace disque disque chiffré mais non répliqué, et qui est tourne via un SSD NVME.

En fait, le stockage se fera sur une machine OpenMediaVault distante, avec un montage NFS de plusieurs volumes.

Pourquoi plusieurs ? C’est plutôt simple, pour stocker ses infos de fonctionnement, contrairement à minIO qui le fait dans le répertoire du bucket des données dans un sous-répertoire caché, Garage fait ça dans un répertoire séparé “meta”, et le bucket lui-même tient dans le répertoire “data”.

Vu qu’il n’y a pas assez de répertoire et que j’ai besoin de plusieurs modes de stockages dans du S3, je ferai tourner une instance par mode de stockage. 

Principal raison à cette sépération: le Nexus3 ne supportera pas niveau débit de stocker des images Docker sur un volume en HDD. Et puis, aucun intérêt de stocker des logs récupérés par Loki sur un SSD NVME (à part abimer le SSD) !

Organisation

Donc du coup, on commence à avoir pas mal de dispos utilisables, et pas mal de possiblités. Chaque Garage crée a ses endpoints:

• ucslow.s3.domain.local

• *.ucslow.garage.domain.local

• cslow.s3.domain.local

• *.cslow.garage.domain.local

• cfast.s3.domain.local

• *.cfast.garage.domain.local

Pour les endpoints eux-même:

• Le premier endpoint de chaque liste correspond au endpoint vers l’API S3, qui permettra de pouvoir push des artefacts dessus, et qui logiquement est exposé publiquement.

• Le second correspond aux sous-domaines qui exposent le contenu du bucket. Et oui, petite découvete sympa, on peut servir du contenu directement depuis un bucket S3 

Ici, j’expose donc en tout six ingress, même si ceux qui exposent le contenu du bucket seront sûrement inutiles dans un premier temps. 

Pour exposer tout ça, c’est Traefik qui fait le boulot, avec un petit passage par cert-manager pour récupérer des certificats locaux générés par un Vault (autorité de certification locale) ou par letsencrypt (pour les endpoints exposés publiquement). Et tout ça automatisé.

Monitoring 

Le helm chart fourni comprend un service monitor, à activer évidemment, et qui permet de scrapper un endpoint /metrics. Ici donc je passe par ma stack de monitoring qui fonctionne avec Prometheus Operator.

Du coup le monitoring est plutôt très simple à mettre en place si l’on dispose de connaissances sur Prometheus. En plus de ça, y a un dashboard de fourni de base aussi disponible dans la documentation, certaines métriques semblent manquer donc à voir si ce dashboard est cassé ou que j’ai mal configuré dans mon coin.

Pour le reste du monitoring, plus classique on va dire, je passe par Uptime Kuma, et j’ajoute encore les endpoints à la main. D’ici peu de temps, j’espére essayer de dev un opérateur UptimeKuma parce que je commence à avoir la flemme de le faire à la main.

Sauvegardes  

Toutes les nuits, j’ai une sauvegarde BorgBackup qui passe et qui va sauvegarder de façon chiffrée une grosse partie de mes données et aussi des partages NFS sur un espace de stockage Storage Box chez Hertzner. La volumétrie commence à être importante d’ailleurs. Donc du coup, je peux rollback si besoin à une vielle sauvegarde la nuit passée à 3h du matin.

Clustering

Il y a possibilité de faire facilement du clustering, je n’ai pas encore poussé ce point là vu que mes besoins sont limités, mais la création de cluster semble hyper simple (il faut init un cluster même en single-node lors d’un déploiement via un helm-chart).

Migration

Eh ben, c’est à l’arrache, pour la plupart des buckets existants sur minIO (Une vingtaine), je n’avais pas un usage soutenu dans tous les cas, et la migration se fera surtout au fil de l’eau.

Tout ce qui est logs et métriques Prometheus, je nettoie l’ancien pour partir sur des bases saines sur de nouveaux buckets, ce qui n’est pas possible sur des buckets contenant des sauvegardes. 

Dans l’idée, je pense refaire un reupload via la cli aws sur les nouveaux buckets, en espérant que ça passe, ça sera mis à jour ici petit à petit.