Julien RATONDisclaimer: le but de cet article n’est pas d’apporter une solution parfaite.Il est basé sur mon expérience pour répondre à un besoin client avec ses contraintes, mes connaissances et ma vision de la solution pour y répondre.
Qu’est-ce que Rancher ? Rancher est un outil qui permet de manager différents clusters Kubernetes, tout en fournissant des outils pour gérer des workflows conteneurisés.
Représentation de 2 architectures possibles pour Rancher (Schéma issue de la documentation du site Rancher)
Le client chez qui je suis intervenu pour faire cette migration avait un Rancher qui tournait dans un container. Ils avaient comme besoin de rendre l’outil plus résilient et robuste. Effectivement Rancher était l’outil permettant de générer les accès aux clusters pour toute leur population de développeur. Cet outil était utilisé quotidiennement par plusieurs personnes pour déployer des environnements dans des clusters Kubernetes. La migration de Rancher vers un cluster Kubernetes (RKE2 ici) s’est imposée d'elle-même à la vue des différents enjeux et contraintes de ce client.
Certains systèmes ou outils ont parfois besoin d’être migrés. Cependant tous n’ont pas été développés ou même pensés pour répondre à un tel besoin. C’est le cas de Rancher qui offre un outil de dump de ses données mais n’apporte pas de réelle solution à sa migration.
Effectivement on peut trouver un outil sur le site de Rancher qui permet de faire une migration. Seulement cet outil apporte des contraintes qui n’étaient pas contournables lors de mon expérience. La première (et pas des moindres), le hostname doit rester le même. Cela peut paraître assez anodin, mais si on souhaite faire évoluer ce dernier, pour des contraintes réseaux, ou simplement que l’on ai envie de changer de hostname, l’outil fourni par Rancher n’est pas envisageable. La seconde contrainte était le fait de conserver l’environnement de départ. La migration peut s’effectuer de Docker vers Docker, de Kubernetes vers Kubernetes, mais pas de Docker vers Kubernetes ou inversement.
Heureusement, le rancher propose un outil pour extraire les données liées à un cluster et également pour les importer. Cet outil est une CLI qui permet de contacter l’API de Rancher et d'interagir avec.
Dans la suite de cet article je vous présente la façon dont j’ai pensé cette migration en ayant le moins d’indisponibilité possible pour les utilisateurs. Je pense que ce processus est fortement corrélé aux contraintes, au contexte et au besoin du projet sur lequel je suis intervenu. A vous de vous approprier la méthode plutôt que le processus lui-même.
L’objectif était de créer le moins d’indisponibilité possible de la plateforme Rancher pour les utilisateurs. Il était donc nécessaire de bien préparer en amont de la bascule pour que cette dernière soit la plus rapide possible. La préparation commençait donc par extraire les ACLs (utilisateurs, rôles associés par projets et namespace). Pour cette partie là j’ai donc écrit un script Bash qui s’appuyait sur la CLI fournie par Rancher. Dans une boucle, le script récupère l’ensemble des projets, et pour chacun des projets, le(s) namespace(s) associé(s), avec les utilisateurs associés à leur(s) rôle(s). Ces informations, une fois récupérées, sont inscrites dans un fichier texte.
#!/bin/bash
echo "clusters list"
clusters=$(rancher clusters ls | grep active | grep -v local | awk '{ print $1 }')
echo $clusters
echo ""
for cluster in $clusters
do
cluster_name=$(rancher clusters ls | grep $cluster | awk '{ print $3 }')
echo "project of current cluster - $cluster_name"
projects=$(: | rancher context switch | grep -v local | grep -v 'Select a Project' | grep $cluster | awk '{ print $3 }')
echo "cluster:$cluster_name" > $cluster_name.txt
rancher clusters list-members --cluster-id $cluster | tail -n +2 | grep -v "Default Admin" | awk '{print $2 ":" $3}' >> $cluster_name.txt
for project in $projects
do
rancher context switch $project
project_name=$(: | rancher context switch | grep $project | awk '{ print $4 }')
echo "members of current project - $project_name"
echo "project:$project_name" >> $cluster_name.txt
rancher namespaces ls -q | sed -E 's/(.*)/namespace:\1/' >> $cluster_name.txt
rancher projects list-members --project-id $project | awk '{ print $2 ":" $3 }' | tail -n +2 >> $cluster_name.txt
done
echo ""
done
Exemple de code d’export en bash
La préparation à ce stade est terminée. L’étape suivante cause de l’indisponibilité, puisqu’il s’agit de la migration des agents. Avant de commencer, il faut créer le cluster dans le nouveau Rancher. Il suffit ensuite de récupérer la commande “kubectl apply” pour installer les nouveaux agents sur le cluster (et la garder de côté, la commande). Connectez-vous à votre cluster, et supprimez les anciens agents (vous pouvez supprimer le namespace, il sera recréé). Une fois supprimés, jouez la commande “kubectl apply” récupérée sur le nouveau Rancher.
La bascule est maintenant terminée, il suffit donc de remapper l’ensemble des ACLs, que l’on a conservées dans un fichier texte avant la bascule. Pour ce faire, j’ai écrit un second script bash (qui s’appuie aussi sur la CLI fourni par Rancher). Dans ce dernier, il y a une boucle qui parcourt notre fichier texte pour récupérer les différentes informations et, à l’aide de la CLI Rancher, les injecte directement dans le nouveau Rancher.
#!/bin/bash
imported_file=$1
echo "file $imported_file"
cluster_acls=$(cat $imported_file)
cluster=""
project=""
for cluster_acl in $cluster_acls
do
echo $cluster_acl
title=$(echo $cluster_acl | cut -d':' -f1)
role=$(echo $cluster_acl | cut -d':' -f2)
if [ "$title" = "cluster" ]
then
cluster=$role
cluster_id=$(rancher clusters ls | grep $cluster | awk '{ print $1 }')
echo "you are working on $cluster cluster with id $cluster_id"
elif [ "$title" = "project" ]
then
project=$role
project_id=$(: | rancher context switch | grep $cluster | grep $project | awk '{ print $3 }' | cut -d':' -f2)
if [ "$project_id" = "" ]
then
rancher projects create --cluster $cluster_id $project
project_id=$(: | rancher context switch | grep $cluster | grep $project | awk '{ print $3 }' | cut -d':' -f2)
fi
echo ""
rancher context switch $cluster_id:$project_id
echo "you are working on $project project with id $project_id"
elif [ "$title" = "namespace" ]
then
namespace=$role
rancher namespace move $namespace $cluster_id:$project_id
else
user=$title
if [ "$project" = "" ]
then
current_user=$(rancher clusters list-members --cluster-id $cluster_id | grep $user | grep $role)
if [ "$current_user" = "" ]
then
rancher clusters add-member-role --cluster-id $cluster_id $title $role
echo "user $user added to the cluster $cluster with id $cluster_id with role $role"
else
echo "user $user with role $role already exists on current cluster $cluster"
fi
else
current_user=$(rancher projects list-members | grep $user | grep $role)
if [ "$current_user" = "" ]
then
rancher projects add-member-role $title $role
echo "user $user added to the project $project with id $project_id with role $role"
else
echo "user $user with role $role already exists on current project $project"
fi
fi
fi
done
Exemple de code d’import en bash
Il ne reste plus qu’à communiquer le nouveau DNS aux utilisateurs pour qu’ils récupèrent le nouveau contexte, le mettent en place sur leur espace de travail, et la migration est terminée !
En conclusion: la solution Rancher apporte une solution simple pour manager ses clusters Kubernetes, mais ne semble pas être le moyen le plus efficace et le plus maintenable dans le temps. Cependant certaines facilités et outils qu’elle apporte peuvent faciliter certaines tâches (comme la délégation de droits sur les clusters par exemple).
Concernant la migration, si vous vous retrouvez avec le même besoin et les mêmes contraintes, la solution est simple à mettre en place (quelques scripts bash, et de la configuration Rancher) et avec une rupture de service relativement courte.
Merci d’avoir lu mon article! Je suis Julien, cloud engineer chez Stack Labs.
Si vous voulez en savoir plus sur Stack Labs ou rejoindre une équipe de passionnés de tech, n’hésitez pas à nous contacter ici.
