Руководство по настройке контейнера на стороне для пользовательского контейнера в службе приложение Azure

В этом руководстве вы добавите сборщик OpenTelemetry в качестве контейнера на стороне в пользовательское приложение контейнера Linux в службе приложение Azure. Сведения о том, как использовать собственные приложения Linux, см. в руководстве по настройке контейнера на стороне для приложения Linux в службе приложение Azure.

Если у вас нет аккаунта Azure, создайте бесплатную учетную запись перед началом.

В службе приложение Azure можно добавить до девяти контейнеров бокового автомобиля для каждого приложения Linux. Контейнеры на стороне позволяют развертывать дополнительные службы и функции в приложениях Linux без тесной привязки к основному контейнеру (встроенному или пользовательскому). Например, можно добавить мониторинг, ведение журнала, конфигурацию и сетевые службы в качестве контейнеров на стороне. Боковая машина сборщика OpenTelemetry является одним из таких примеров мониторинга.

Контейнеры-сайдкары запускаются вместе с основным контейнером приложения в том же плане App Service.

Сначала вы создадите ресурсы, используемые в руководстве. Они используются для этого конкретного сценария и не требуются для контейнеров боковинка в целом.

1. В Azure Cloud Shell выполните следующие команды:

   git clone https://github.com/Azure-Samples/app-service-sidecar-tutorial-prereqs
   cd app-service-sidecar-tutorial-prereqs
   azd env new my-sidecar-env
   azd provision
   

2. При появлении запроса укажите нужную подписку и регион. Например:

   • Подписка: ваша подписка.
   • Регион: (Европа) Западная Европа.

   После завершения развертывания вы увидите следующие выходные данные:

    APPLICATIONINSIGHTS_CONNECTION_STRING = InstrumentationKey=...;IngestionEndpoint=...;LiveEndpoint=...
   
    Open resource group in the portal: https://portal.azure.com/#@/resource/subscriptions/.../resourceGroups/...
    

3. Откройте ссылку группы ресурсов на вкладке браузера. Вам потребуется использовать строка подключения позже.

   Примечание

   azd provision использует включенные шаблоны для создания следующих ресурсов Azure:

   • Группа ресурсов с именем my-sidecar-env_group.
   • Реестр контейнеров с двумя образами, развернутыми:
     • Изображение Nginx с модулем OpenTelemetry.
     • Образ сборщика OpenTelemetry, настроенный для экспорта в Azure Monitor.
   • Рабочая область Log Analytics
   • Компонент Application Insights

1. На странице управления группой ресурсов нажмите кнопку "Создать".

2. Найдите веб-приложение, а затем щелкните стрелку вниз в разделе "Создать" и выберите "Веб-приложение".

   

3. Настройте панель "Основные сведения", как показано ниже.

   • Имя: уникальное имя.
   • Публикация: контейнер
   • Операционная система: Linux
   • Регион: тот же регион, с которым вы выбрали azd provision
   • План Linux: новый план Служба приложений

   

4. Выберите Контейнер. Настройте панель контейнеров следующим образом:

   • Поддержка бокового автомобиля: включено
   • Источник изображения: Реестр контейнеров Azure
   • Реестр: реестр, созданный с помощью azd provision
   • Изображение: nginx
   • Тег: последняя версия
   • Порт: 80

   

   Примечание

   Эти параметры настраиваются по-разному в приложениях с поддержкой бокового автомобиля. Дополнительные сведения см. в разделе "В чем различия пользовательских контейнеров с поддержкой сайдкара?".

5. Выберите Проверить и создать, а затем выберите Создать.

6. После завершения развертывания выберите "Перейти к ресурсу".

7. На новой вкладке браузера перейдите https://<app-name>.azurewebsites.net на страницу Nginx по умолчанию и просмотрите страницу Nginx.

В этом разделе описано, как добавить контейнер бокового контейнера в пользовательское приложение контейнера.

1. На странице управления приложения в меню слева выберите Центр развертывания.

   В центре развертывания отображаются все контейнеры в приложении. Сейчас он имеет только основной контейнер.

2. Выберите " Добавить " и настройте новый контейнер следующим образом:

   • Имя: otel-collector
   • Источник изображения: Реестр контейнеров Azure
   • Реестр: реестр, созданный с помощью azd provision
   • Изображение: otel-collector
   • Тег: последняя версия

3. Выберите Применить.

   

   Теперь в центре развертывания должно появиться два контейнера. Основной контейнер помечается Main, а контейнер боковинка помечается боковинка. Каждое приложение должно иметь один основной контейнер, но может иметь несколько контейнеров боковинка.

В примере сценария на стороне otel-сборщика настроен экспорт данных OpenTelemetry в Azure Monitor, но он нуждается в строка подключения в качестве переменной среды (см. файл конфигурации OpenTelemetry для образа otel-сборщика).

Вы настраиваете переменные среды для контейнеров, таких как любое приложение Служба приложений, путем настройки параметров приложения. Параметры приложения доступны для всех контейнеров в приложении.

1. На странице управления приложения в меню слева выберите переменные среды.

2. Добавьте параметр приложения, выбрав "Добавить " и настройте его следующим образом:

   • Имя: APPLICATIONINSIGHTS_CONNECTION_STRING
   • Значение: строка подключения в выходных azd provisionданных . Если вы потеряли сеанс Cloud Shell, его также можно найти на странице обзора ресурса Application Insights в разделе "Строка подключения".

3. Нажмите кнопку "Применить", а затем "Применить", а затем подтвердите.

   

Теперь боковой контейнер otel-сборщика должен экспортировать данные в Application Insights.

1. Вернитесь на вкладку https://<app-name>.azurewebsites.netбраузера, обновите страницу несколько раз, чтобы создать некоторые веб-запросы.

2. Вернитесь на страницу обзора группы ресурсов, а затем выберите ресурс Application Insights. Теперь в диаграммах по умолчанию должны отображаться некоторые данные.

   

Если вам больше не нужна среда, вы можете удалить группу ресурсов, службу приложений и все связанные ресурсы. Просто выполните следующую команду в Cloud Shell в клонированного репозитория:

azd down

• Каковы различия для пользовательских контейнеров с включенной функцией sidecar?
• Как контейнеры на стороне обрабатывают внутреннюю связь?
• Может ли контейнер побочного процесса принимать интернет-запросы?

Вы настраиваете приложения с поддержкой бокового автомобиля по-разному, чем приложения, которые не включены на стороне.

• Имя контейнера и типы напрямую настраиваются с LinuxFxVersion=DOCKER|<image-details> (см. az webapp config set --linux-fx-version).
• Основной контейнер настраивается с параметрами приложения, такими как:
  • DOCKER_REGISTRY_SERVER_URL
  • DOCKER_REGISTRY_SERVER_USERNAME
  • DOCKER_REGISTRY_SERVER_PASSWORD
  • WEBSITES_PORT

• Приложение с поддержкой сайдкара обозначено как LinuxFxVersion=sitecontainers (см. az webapp config set --linux-fx-version).
• Основной контейнер настраивается с ресурсом sitecontainers . Эти параметры не применяются для приложений с поддержкой сайдкара
  • DOCKER_REGISTRY_SERVER_URL
  • DOCKER_REGISTRY_SERVER_USERNAME
  • DOCKER_REGISTRY_SERVER_PASSWORD
  • WEBSITES_PORT

Контейнеры на стороне используют тот же сетевой узел, что и основной контейнер, поэтому основной контейнер (и другие контейнеры бокового контейнера) может достичь любого порта на боковой стороне localhost:<port>. В примере startup.sh используется для доступа к порту 4318 на боковой localhost:4318.

В диалоговом окне "Изменить контейнер" поле "Порт" в настоящее время не используется Служба приложений. Его можно использовать как часть метаданных боковой панели, например, чтобы указать, какой порт прослушивает боковая машина.

Нет. Служба приложений направляет интернет-запросы только в основной контейнер. Для приложений Linux на основе кода встроенный контейнер Linux является основным контейнером, и любой боковойcar контейнер (sitecontainers) следует добавить с помощью IsMain=false. Для пользовательских контейнеров все, кроме одного, должны иметь в IsMain=false.

Дополнительные сведения о настройке IsMainсм. в разделе Microsoft.Web sites/sitecontainers.

Функция подключения томов позволяет совместно использовать не постоянные файлы и каталоги между контейнерами в веб-приложении.

Подпуть тома: Это логический путь к каталогу, который создается автоматически и не используется в контейнере. Контейнеры, настроенные с тем же вложенным путем тома, могут совместно использовать файлы и каталоги друг с другом.

Путь монтирования контейнера: Это соответствует пути к каталогу, который вы указываете в контейнере. Путь монтирования контейнера сопоставляется с подпутем тома.

Например, предположим, что настроены следующие подключения томов:

На основе этих параметров применяются следующие условия:

• Если Container1 создает /container1Vol/myfile.txt, контейнер2 может считывать файл с помощью /container2Vol/myfile.txt.
• Если container1 создает /container1Vol/directory3/myfile.txt, контейнер2 может считывать файл с помощью /container2Vol/directory3/myfile.txt, а Container3 может читать и записывать в файл с помощью /container3Vol/myfile.txt.
• Container4 не предоставляет общий доступ к подключению тома к любому из других контейнеров.

• Настройка пользовательского контейнера
• REST API: веб-приложения — создание или обновление контейнера сайта
• Инфраструктура как код: Microsoft.Web sites/sitecontainers
• Развертывание пользовательских контейнеров с помощью GitHub Actions