Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Las funcionalidades definen lo que puede hacer una extensión de la CLI de desarrollador (azd) de Azure, desde la adición de comandos personalizados para enlazar al ciclo de vida de la implementación. Este artículo te muestra cómo añadir capacidades a la extensión de ejemplo Contoso Resource Tagger desde la guía de Inicio rápido para crear una extensión de ejemplo. Puede aplicar los mismos patrones a cualquier extensión.
Cada funcionalidad requiere dos cosas: una entrada en la matriz capabilities del manifiesto de la extensión y la implementación correspondiente en el código de la extensión.
Note
El marco de extensiones azd ya está disponible de forma general. Es posible que las extensiones o funcionalidades individuales tengan su propio estado de vista previa. Para más información sobre la disponibilidad general, consulte Disponibilidad general: marco de extensiones de la CLI para desarrolladores de Azure (azd).
Funcionalidades disponibles
azd las extensiones pueden declarar las siguientes funcionalidades:
-
custom-commands: Agrega nuevos comandos y grupos de comandos en el espacio de nombres deazdtu extensión. Por ejemplo, la extensión de ejemplo agregaazd tagger show. Use esta funcionalidad para exponer tareas que los usuarios ejecutan directamente desde la línea de comandos. -
lifecycle-events: se suscribe a eventos que se generan a medida queazdse ejecuta, comopreprovision,postprovisionopostdeploy. La extensión ejecuta lógica personalizada en esos puntos sin que el usuario lo llame directamente. Por ejemplo, la extensión de ejemplo comprueba si hay etiquetas necesarias enpreprovisionantes de crear los recursos. -
service-target-provider: registra un nuevo destino de implementación, por lo queazdsabe cómo empaquetar e implementar un servicio en un host que no admite de forma predeterminada. Un destino de servicio se asigna al valorhostenazure.yaml. Por ejemplo, puede agregar un proveedor que implemente un servicio en una plataforma de terceros o en un entorno de hospedaje interno. -
framework-service-provider: registra la compatibilidad con un lenguaje o marco, por lo queazdsabe cómo restaurar, compilar y empaquetar ese tipo de proyecto. Esto corresponde al valor delanguageenazure.yaml. Por ejemplo, puede agregar compatibilidad de compilación para un lenguaje queazdno reconoce de forma predeterminada. -
provisioning-provider: cambia la forma en queazdaprovisiona la infraestructura duranteazd provisionyazd up. En lugar del flujo predeterminado de Bicep o Terraform, tu extensión determina lo que ocurre. Por ejemplo, puede integrar una herramienta de infraestructura como código diferente o una API de implementación personalizada. -
validation-provider: Aporta comprobaciones al canal de validaciónazdque se ejecutan en un proyecto o entorno. Por ejemplo, puede comprobar que las convenciones de nomenclatura, las etiquetas necesarias o la configuración de seguridad están en vigor antes de que continúe una implementación. -
mcp-server: Expone la funcionalidad de su extensión como herramientas del Protocolo de contexto de modelo (MCP) que los agentes de IA, como GitHub Copilot, pueden detectar e invocar. Por ejemplo, la extensión de ejemplo puede poner a disposición una herramientasuggest_tags. Para obtener más información, vea Agregar un servidor MCP a una extensión. -
metadata: proporciona metadatos más completos sobre comandos y configuración queazdusa para describir su extensión, como descripciones detalladas de comandos y sugerencias de configuración que aparecen en la salida de ayuda e IntelliSense.
Este artículo se centra en las dos funcionalidades más comunes: comandos personalizados y eventos de ciclo de vida. Para obtener la mcp-server funcionalidad, consulte Adición de un servidor MCP a una extensión. Para obtener más información sobre las funcionalidades del proveedor, consulte la referencia del marco de extensión.
Adición de comandos personalizados
La capacidad custom-commands permite que su extensión registre nuevos comandos bajo un espacio de nombres en azd. La extensión de ejemplo ya usa esta funcionalidad para el azd tagger show comando .
Declare la funcionalidad en
extension.yaml.capabilities: - custom-commandsCompile los comandos mediante el
azdext.NewExtensionRootCommandasistente, que registra las marcas estándarazdy el control de variables de entorno para que no tenga que declararlos manualmente:import "github.com/azure/azure-dev/cli/azd/pkg/azdext" func NewRootCommand() *cobra.Command { rootCmd, extCtx := azdext.NewExtensionRootCommand(azdext.ExtensionCommandOptions{ Name: "tagger", Use: "tagger <command> [options]", Short: "Standardize and report Azure resource tags.", }) rootCmd.AddCommand(newShowCommand(extCtx)) // Add other subcommands here. return rootCmd }El asistente devuelve un
*ExtensionContextque expone los valores resueltos de las marcas estándar, comoEnvironmentyOutputFormat. Pase el contexto a sus subcomandos y léalo dentro de sus controladoresRunE, en lugar de volver a declarar los indicadores estándar.
Suscripción a eventos de ciclo de vida
La funcionalidad permite que la lifecycle-events extensión ejecute lógica personalizada durante los eventos del ciclo de vida del proyecto y del servicio, como preprovision o postdeploy. Para la extensión de ejemplo, use un preprovision evento para comprobar que las etiquetas necesarias están establecidas antes de azd aprovisionar los recursos.
Declare la funcionalidad en
extension.yaml.capabilities: - custom-commands - lifecycle-eventsAgregue un
listencomando a la extensión.azdinvoca este comando para establecer la conexión bidireccional que se usa para los eventos. Use elazdext.NewExtensionHostgenerador para registrar los controladores de eventos:func newListenCommand() *cobra.Command { return &cobra.Command{ Use: "listen", Short: "Starts the extension and listens for azd events.", Hidden: true, RunE: func(cmd *cobra.Command, args []string) error { ctx := azdext.WithAccessToken(cmd.Context()) azdClient, err := azdext.NewAzdClient() if err != nil { return fmt.Errorf("failed to create azd client: %w", err) } defer azdClient.Close() host := azdext.NewExtensionHost(azdClient). WithProjectEventHandler( "preprovision", func(ctx context.Context, args *azdext.ProjectEventArgs) error { fmt.Printf("Verifying required tags for project: %s\n", args.Project.Name) // Add your tag validation logic here. return nil }, ) // Run blocks until azd closes the connection. if err := host.Run(ctx); err != nil { return fmt.Errorf("failed to run extension: %w", err) } return nil }, } }Registrar el comando
listenen el comando raíz:rootCmd.AddCommand(newListenCommand())
Cuando un usuario ejecuta azd provision o azd up, azd invoca la extensión y llama al preprovision controlador antes de aprovisionar recursos.
Filtrar eventos de servicio
Los controladores de eventos de servicio admiten el filtrado opcional para que solo controle tipos de servicio específicos. Por ejemplo, puede gestionar el evento prepackage solo para los servicios de aplicaciones en contenedor de Python:
host := azdext.NewExtensionHost(azdClient).
WithServiceEventHandler(
"prepackage",
func(ctx context.Context, args *azdext.ServiceEventArgs) error {
fmt.Printf("Packaging service: %s\n", args.Service.Name)
return nil
},
&azdext.ServiceEventOptions{
Host: "containerapp",
Language: "python",
},
)
Recompilación y prueba
Después de agregar una funcionalidad, vuelva a generar la extensión y pruebe el nuevo comportamiento:
Si estás usando el modo de supervisión, los cambios se recompilan automáticamente. De lo contrario, compile manualmente:
azd x buildPruebe la funcionalidad. Para los eventos de ciclo de vida, ejecute un comando que desencadene el evento, como
azd provision.