AgentBaker
v0.20230216.5
AgentBaker est une collection de composants utilisés pour provisionner les nœuds Kubernetes dans Azure.
AgentBaker a quelques pièces
Le principal consommateur d'agentbaker est le service Azure Kubernetes (AKS).
AKS utilise AgentBaker pour provisionner les nœuds Linux et Windows Kubernetes.
Le développement d'agentbaker nécessite quelques conditions de base:
Exécutez make -C hack/tools install pour installer tous les outils de développement.
Si vous modifiez du code ou des artefacts utilisés pour générer des données personnalisées ou des charges utiles d'extension de script personnalisées, vous devez exécuter make .
Cela réinstalle le code pour intégrer des fichiers statiques dans le code GO, ce qui sera réellement utilisé lors de l'exécution.
Cela exécute en outre des tests unitaires (équivalent du go test ./... ) et régénère un test de test de snapshot.
Nous utilisons Golangci-lint pour appliquer le style.
Exécutez make -C hack/tools install pour installer le linter.
Exécutez ./hack/tools/bin/golangci-lint run pour exécuter le linter.
Nous avons actuellement de nombreux échecs que nous espérons éliminer.
Nous avons un travail pour exécuter Golangci-lint sur les demandes de traction.
Ce travail utilise la fonctionnalité "No-New-Issues".
Tant que les PR n'introduisent pas de nouveaux problèmes nets, ils devraient passer.
Nous avons également un travail de liaison pour appliquer le style de message de validation.
Nous adhérons aux commits conventionnels.
Préférez les demandes de traction avec des commits simples.
Pour nettoyer les engagements en cours, vous pouvez utiliser git rebase -i pour fixer les validations.
Voir la documentation GIT pour plus de détails.
La plupart du code peut être testé avec des tests unitaires Vanilla GO.
Veuillez visiter le lien Github officiel pour plus de détails. Vous trouverez ci-dessous un bref cas d'utilisation.
Shellspec est utilisé comme cadre pour le test unitaire. Il existe 2 options pour l'installer.
Shellspec est déjà inclus dans le makefile. Vous pouvez l'installer simplement en exécutant make tools-install ou make generate dans le répertoire root (/ agentbaker).
Remarque: make generate va installer et exécuter les tests ShellSpec.
Si vous souhaitez l'installer dans votre machine locale, veuillez exécuter curl -fsSL https://git.io/shellspec | sh .
Par défaut, il doit être installé dans ~/.local/lib/shellspec . Veuillez l'ajouter au chemin $ pour votre commodité. Exemple de commande export PATH=$PATH:~/.local/lib/shellspec .
Vous devrez écrire le fichier xxx_spec.sh pour le test.
Par exemple, AgentBaker/spec/parts/linux/cloud-init/artifacts/cse_install_spec.sh est un fichier de test pour AgentBaker/parts/linux/cloud-init/artifacts/cse_install.sh
Pour exécuter tous les tests, dans le dossier agentbaker, exécutez simplement bash ./hack/tools/bin/shellspec dans le répertoire root (/ agentbaker).
bash ./hack/tools/bin/shellspec -x => Avec -x , il montrera une trace verbale pour le débogage.bash ./hack/tools/bin/shellspec -E "<test name>" => Vous pouvez exécuter un seul cas de test en utilisant -E et le nom de test. Par exemple, bash ./hack/tools/bin/shellspec -E "returns downloadURIs.ubuntu."r2004".downloadURL of package runc for UBUNTU 20.04" . Vous pouvez également faire -xE pour une trace verbale pour un seul cas de test.bash ./hack/tools/bin/shellspec "path to xxx_spec.sh" => En fournissant un chemin complet un fichier de spécification particulier, vous ne pouvez exécuter que ce fichier de spécification au lieu de tous les fichiers de spécifications dans le projet AgentBaker. Par exemple, bash ./hack/tools/bin/shellspec "spec/parts/linux/cloud-init/artifacts/cse_install_spec.sh" Nous avons également des tests de données d'instantané, qui stockent la sortie des API clés sous forme de fichiers sur le disque.
Nous pouvons vérifier manuellement le contenu instantané semble correct.
Nous avons maintenant des tests unitaires qui peuvent directement valider le contenu sans laisser de fichiers générés sur le disque.
Voir ./pkg/agent/baker_test.go pour les exemples (recherchez dynamic-config-dir pour voir un échantillon de validation.).
Découvrez le répertoire E2E.
Ce projet accueille les contributions et les suggestions. La plupart des contributions vous obligent à accepter un accord de licence de contributeur (CLA) déclarant que vous avez le droit de faire et en fait, accordez-nous les droits d'utilisation de votre contribution. Pour plus de détails, visitez https://cla.opensource.microsoft.com.
Lorsque vous soumettez une demande de traction, un bot CLA déterminera automatiquement si vous devez fournir un CLA et décorer le RP de manière appropriée (par exemple, vérification d'état, commentaire). Suivez simplement les instructions fournies par le bot. Vous n'aurez besoin de le faire qu'une seule fois sur tous les dépositions en utilisant notre CLA.
Ce projet a adopté le code de conduite open source Microsoft. Pour plus d'informations, consultez le code de conduite FAQ ou contactez [email protected] avec toute question ou commentaire supplémentaire.
Un fichier CGManifest est un fichier JSON utilisé pour enregistrer les composants manuellement lorsque le type de composant n'est pas pris en charge par la gouvernance. Le nom du fichier est "cgmanifest.json" et vous pouvez en avoir autant que vous avez besoin et peut être n'importe où dans votre référentiel.
Chemin de fichier: ./vhdbuilder/cgmanifest.json
Référence: https://docs.opensource.microsoft.com/tools/cg/cgmanifest.html
Emballer:
