Infrastruktura agenta hostowanego z użyciem Azure Developer CLI

Po uruchomieniu programu azd ai agent init --infra lub azd ai agent init --infra=bicep interfejs wiersza polecenia dewelopera Azure (azd) wyodrębnia edytowalną infrastrukturę z deklaracji usługi Foundry. Bez istniejącej infrastruktury domyślną ścieżką jest infra. Aby zachować istniejącą infrastrukturę aplikacji, ejection dodaje warstwę Foundry pod infra/foundry. Uruchomienie azd provision wdraża zadeklarowaną infrastrukturę.

Co jest udostępniane

Domyślnie azd ai agent init nie tworzy plików infrastruktury jako kodu. Użyj --infra lub --infra=bicep, aby wysunąć Bicep. Użyj polecenia --infra=terraform, aby wyodrębnić Terraform i zapisać dostawcę warstwy. Jeśli projekt deklaruje już usługi Foundry, wywołaj samo --infra. Ta ścieżka odrzuca niepowiązane dane wejściowe inicjalizacji.

Wyodrębnione szablony pochodzą z syntetyzatora infrastruktury rozszerzenia, a nie z oddzielnego repozytorium startowego. W przypadku nowego projektu wygenerowana infrastruktura aprowizuje zadeklarowane konto usługi Foundry, projekt i wdrożenia modelu. Dodatkowe zasoby zależą od konfiguracji usługi:

Gdy projekt deklaruje izolację sieci, szablony konfigurują również podsieci, prywatny punkt końcowy konta i prywatny system DNS. Tryb ruchu wychodzącego określa wstrzykiwanie do sieci klienta lub sieć zarządzaną przez firmę Microsoft.

Bieżące szablony nie aprowizują automatycznie usługi Application Insights, obszaru roboczego Log Analytics, Wyszukiwanie AI platformy Azure, konta magazynu ani zasobu Bing Grounding. Zadeklaruj dodatkową infrastrukturę aplikacji i zarządzaj nią oddzielnie, zamiast zakładać, że odwołanie do narzędzia ją tworzy.

struktura projektu

infra/
|-- main.bicep
|-- main.parameters.json
|-- abbreviations.json
\-- modules/

W tym przykładzie przedstawiono domyślne dane wyjściowe Bicep, gdy nie ma istniejącej infrastruktury. Projekt z istniejącą infrastrukturą aplikacji otrzymuje oddzielną infra/foundry warstwę; istniejące konfiguracje warstwowe zachowują zadeklarowane ścieżki. Dokładne moduły zależą od tego, czy tworzysz projekt, czy łączysz się z istniejącym. Wyrzucanie Terraform zamiast tego zapisuje pliki .tf i main.tfvars.json.

Przepływ parametrów

Wygenerowany main.parameters.json element zawiera powiązania parametrów i wartości pochodzące z azure.yamlklasy . Na przykład warstwa Bicep używa powiązań środowiskowych, takich jak:

{
  "parameters": {
    "location": { "value": "${AZURE_LOCATION}" },
    "foundryProjectName": { "value": "${AZURE_AI_PROJECT_NAME=${AZURE_ENV_NAME}}" },
    "resourceTokenSalt": { "value": "${AZD_RESOURCE_TOKEN_SALT}" }
  }
}

Podczas azd provision, azd rozwiązuje te odwołania ${VAR} na podstawie środowiska (.azure/<env>/.env) i przekazuje je do wdrożenia Bicep. Dane wyjściowe z wdrożenia, takie jak punkt końcowy projektu Foundry i punkt końcowy rejestru kontenerów, są zapisywane z powrotem do środowiska do użycia przez polecenia azd deploy, azd ai agent run i zasobu azd ai.

Infrastruktura programu Terraform

W przypadku nowego projektu azd ai agent init --infra=terraform generuje pliki, takie jak następujące:

infra/
|-- main.tf
|-- provider.tf
|-- variables.tf
|-- outputs.tf
|-- main.tfvars.json
\-- .azd-foundry

Usługi oparte na kontenerach mogą również generować container-registry.tf. Istniejące projekty mogą zachować dotychczasową infrastrukturę i otrzymać oddzielną warstwę Foundry pod infra/foundry/. Użyj rzeczywistego wygenerowanego układu, a nie przenoszenia plików między warstwami.

Konfiguracja Terraform aprowizuje konto Foundry, projekt, wdrożenia modeli oraz powiązane zasoby wymagane przez wybrane usługi. Tworzenie rejestru kontenerów zależy od trybu wdrażania i konfiguracji obrazu.

main.tfvars.json wiąże parametry wejściowe infrastruktury z wartościami środowiska azd. outputs.tf udostępnia wartości, takie jak punkt końcowy projektu Foundry, dla azd po zakończeniu aprowizacji. Te powiązania są częścią przepływu pracy azd; nie zakładaj, że wygenerowany plik parametrów będzie działać bez zmian z samodzielnym terraform apply.

Aby dostosować infrastrukturę programu Terraform, zmodyfikuj wygenerowane .tf pliki, zachowaj dane wyjściowe wymagane przez usługi agenta i uruchom polecenie azd provision. Przed zastosowaniem zmian infrastruktury zapoznaj się z planem programu Terraform.

Stan Terraform i CI/CD

Wygenerowane pliki nie uruchamiają zaplecza stanu zdalnego. W przypadku wdrożeń zespołowych przed skonfigurowaniem CI/CD należy skonfigurować plik stanu oparty na usłudze Azure Storage, oddzielne klucze stanu dla każdego środowiska oraz wymagane uprawnienia backendu.

Zobacz Konfigurowanie CI/CD przy użyciu Terraform, aby poznać przepływ wdrażania, oraz Używanie Terraform z azd, aby skonfigurować zaplecze.

Ograniczenia wysuwania narzędzia Terraform

Ścieżka eksportu Terraform nie obsługuje konfiguracji usługi network: w obecnej wersji rozszerzenia agentów Foundry. Przed wyrzuceniem projektu, który ma już infrastrukturę, przejrzyj istniejące ograniczenia zasobów. Ejection nie jest ogólną migracją stanu z Bicep do Terraform, a usuwanie zasobów produkcyjnych nie jest warunkiem wstępnym przejścia na Terraform.

Istniejące zasoby

Aby ponownie użyć istniejącego konta i projektu Foundry, zainicjuj przy użyciu identyfikatora zasobu projektu:

azd ai agent init --project-id "<foundry-project-resource-id>"

Odłączenie istniejącego projektu odwołuje się do konta i projektu, zamiast tworzyć zamienniki. Może dodać zadeklarowane wdrożenia modelu i utworzyć lub ponownie użyć rejestru kontenerów. W przypadku istniejącego podłączonego rejestru należy użyć --acr-connection podczas inicjowania. Zobacz Wdrażanie przy użyciu prywatnego rejestru kontenerów.

Dostosowywanie infrastruktury

Katalog infra/ stanowi standardową azd infrastrukturę. Aby dodać lub zmienić zasoby Bicep:

1. Edytuj infra/main.bicep lub dodaj nowe moduły w obszarze infra/modules/. W przypadku infrastruktury warstwowej użyj zadeklarowanej ścieżki warstwy Foundry.
2. Dodaj nowe parametry do elementu main.parameters.json z ${VAR} powiązaniami.
3. Ustaw odpowiednie azd zmienne środowiskowe za pomocą polecenia azd env set.
4. Uruchom polecenie , azd provision aby zastosować zmiany.

Zmiany w plikach Bicep utrzymują się między wdrożeniami.

Ograniczenia regionów

Bieżący wygenerowany main.bicep nie zawiera listy dozwolonych regionów. Wybierz region, który obsługuje wymagane funkcje i modele agenta hostowanego. Edytowanie szablonu nie włącza usługi w nieobsługiwanym regionie.

Treści powiązane

• azure.yaml reference for hosted agents (Dokumentacja pliku azure.yaml dla hostowanych agentów)
• Wdrażanie hostowanego agenta
• Konfigurowanie sieci wirtualnych