Контейнеры в Контейнерах приложений Azure
Контейнеры приложений Azure берут на себя управление оркестрацией для контейнеров и Kubernetes. Контейнеры в Контейнерах приложений Azure могут использовать любую среду выполнения, язык программирования или стек разработки на ваш выбор.
Приложения-контейнеры Azure поддерживают:
- любой образ контейнера на основе Linux x86-64 (
linux/amd64); - контейнеры из любого общедоступного или частного реестра контейнеров.
- Необязательные контейнеры и контейнеры инициализации
Кроме того, к ним относятся следующие функции:
- Приложения используют
templateраздел конфигурации для определения образа контейнера и других параметров. Изменения вtemplateразделе конфигурации активируют новую редакцию приложения контейнера. - в случае аварийного завершения работы контейнер автоматически перезапускается.
К функциям заданий относятся:
- Выполнение заданий использует
templateраздел конфигурации для определения образа контейнера и других параметров при каждом запуске выполнения. - Если контейнер завершает работу с кодом выхода, отличного от нуля, выполнение задания помечается как неудачное. Задание можно настроить для повтора неудачных выполнений.
Настройка
Большинство приложений-контейнеров имеют один контейнер. В расширенных сценариях приложение может также иметь боковую и инициативную контейнеры. В определении приложения контейнера основное приложение и его контейнеры боковинка перечислены в containers массиве в properties.template разделе, а контейнеры инициализации перечислены в массиве initContainers . В следующем фрагменте показаны доступные параметры конфигурации при настройке контейнеров приложения.
{
"properties": {
"template": {
"containers": [
{
"name": "main",
"image": "[parameters('container_image')]",
"env": [
{
"name": "HTTP_PORT",
"value": "80"
},
{
"name": "SECRET_VAL",
"secretRef": "mysecret"
}
],
"resources": {
"cpu": 0.5,
"memory": "1Gi"
},
"volumeMounts": [
{
"mountPath": "/appsettings",
"volumeName": "appsettings-volume"
}
],
"probes": [
{
"type": "liveness",
"httpGet": {
"path": "/health",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "liveness probe"
}
]
},
"initialDelaySeconds": 7,
"periodSeconds": 3
},
{
"type": "readiness",
"tcpSocket": {
"port": 8081
},
"initialDelaySeconds": 10,
"periodSeconds": 3
},
{
"type": "startup",
"httpGet": {
"path": "/startup",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "startup probe"
}
]
},
"initialDelaySeconds": 3,
"periodSeconds": 3
}
]
}
]
},
"initContainers": [
{
"name": "init",
"image": "[parameters('init_container_image')]",
"resources": {
"cpu": 0.25,
"memory": "0.5Gi"
},
"volumeMounts": [
{
"mountPath": "/appsettings",
"volumeName": "appsettings-volume"
}
]
}
]
...
}
...
}
| Параметр | Description | Примечания |
|---|---|---|
image |
Имя образа контейнера для контейнера приложения. | Это значение имеет формат repository/<IMAGE_NAME>:<TAG>. |
name |
Удобное имя контейнера. | Используется для создания отчетов и идентификации. |
command |
Команда запуска контейнера. | Эквивалентно полю entryPoint в Docker. |
args |
Аргументы для команды запуска. | Записи в этом массиве объединяются в список параметров, который передается команде запуска. |
env |
Массив пар name/value, определяющих переменные среды. | Вместо поля value для ссылки на секрет используйте secretRef. |
resources.cpu |
Количество ЦП, выделенных для контейнера. | См. требования к выделению виртуальных ЦП и памяти |
resources.memory |
Объем ОЗУ, выделенный для контейнера. | См. требования к выделению виртуальных ЦП и памяти |
volumeMounts |
Массив с определениями подключений томов. | Вы можете определить временные или постоянные тома хранилища для контейнера. Дополнительные сведения о томах хранилища см. в статье Использование подключений к хранилищу в Контейнерах приложений Azure. |
probes |
Массив проб работоспособности, настроенных в контейнере. | Дополнительные сведения о параметрах проб см. в статье Пробы работоспособности в Контейнерах приложений Azure. |
Требования к выделению виртуальных ЦП и памяти
При использовании плана потребления общий объем ЦП и памяти, выделенной для всех контейнеров в приложении-контейнере, должен добавиться к одному из следующих сочетаний.
| Виртуальные ЦП (ядра) | Память |
|---|---|
0.25 |
0.5Gi |
0.5 |
1.0Gi |
0.75 |
1.5Gi |
1.0 |
2.0Gi |
1.25 |
2.5Gi |
1.5 |
3.0Gi |
1.75 |
3.5Gi |
2.0 |
4.0Gi |
2.25 |
4.5Gi |
2.5 |
5.0Gi |
2.75 |
5.5Gi |
3.0 |
6.0Gi |
3.25 |
6.5Gi |
3.5 |
7.0Gi |
3.75 |
7.5Gi |
4.0 |
8.0Gi |
Примечание.
Приложения, использующие план потребления только в среде потребления , ограничиваются не более 2 ядер и 4 Гига памяти.
Несколько контейнеров
В расширенных сценариях можно запускать несколько контейнеров в одном приложении-контейнере. Используйте этот шаблон только в определенных экземплярах, где контейнеры тесно связаны.
Для большинства сценариев микрослужб рекомендуется развернуть каждую службу как отдельное приложение контейнера.
Несколько контейнеров в одном приложении-контейнере совместно используют жесткие диски и сетевые ресурсы и имеют одинаковый жизненный цикл приложения.
Существует два способа запуска дополнительных контейнеров в приложении контейнера: контейнеры на стороне и контейнеры инициализации.
Контейнеры на стороне
Вы можете определить несколько контейнеров в одном приложении контейнера для реализации шаблона бокового контейнера.
Ниже приведены примеры контейнеров боковинка:
Агент, который считывает журналы из основного контейнера приложений на общем томе и перенаправит их в службу ведения журнала.
Фоновый процесс, который обновляет кэш, используемый контейнером основного приложения в общем томе.
Эти сценарии являются примерами и не представляют только способы реализации бокового автомобиля.
Чтобы запустить несколько контейнеров в контейнерном приложении, добавьте несколько контейнеров в массив containers в шаблоне контейнерного приложения.
Контейнеры инициализации.
Вы можете определить один или несколько контейнеров инициализации в приложении-контейнере. Контейнеры инициализации выполняются до контейнера основного приложения и используются для выполнения задач инициализации, таких как скачивание данных или подготовка среды.
Контейнеры init определяются в initContainers массиве шаблона приложения контейнера. Контейнеры выполняются в том порядке, в который они определены в массиве, и должны успешно завершиться до запуска контейнера основного приложения.
Примечание.
Контейнеры init в приложениях с помощью выделенного плана или запуска в среде потребления только не могут получить доступ к управляемому удостоверению во время выполнения.
Реестры контейнеров
Вы можете развернуть образы, размещенные в частных реестрах, указав их учетные данные в конфигурации Контейнеров приложений.
Чтобы использовать реестр контейнеров, необходимо определить реестр в registries массиве в properties.configuration разделе шаблона ресурса приложения контейнера. Поле passwordSecretRef определяет имя секрета в имени массива secrets, где вы определили пароль.
{
...
"registries": [{
"server": "docker.io",
"username": "my-registry-user-name",
"passwordSecretRef": "my-password-secret-name"
}]
}
Сохраненные учетные данные используются для извлечения образа контейнера из частного реестра при развертывании приложения.
В следующем примере показано, как настроить в контейнере приложения учетные данные для Реестра контейнеров Azure.
{
...
"configuration": {
"secrets": [
{
"name": "docker-hub-password",
"value": "my-docker-hub-password"
}
],
...
"registries": [
{
"server": "docker.io",
"username": "someuser",
"passwordSecretRef": "docker-hub-password"
}
]
}
}
Примечание.
Docker Hub ограничивает количество скачиваемых образов Docker. Когда ограничение достигнуто, контейнеры в приложении не будут запускаться. Используйте реестр с достаточными ограничениями, например Реестр контейнеров Azure, чтобы избежать этой проблемы.
Управляемое удостоверение с помощью Реестр контейнеров Azure
Управляемое удостоверение Azure можно использовать для проверки подлинности с помощью Реестр контейнеров Azure вместо использования имени пользователя и пароля. Дополнительные сведения см. в разделе "Управляемые удостоверения" в приложениях контейнеров Azure.
Чтобы использовать управляемое удостоверение с реестром, удостоверение должно быть включено в приложении и оно должно быть назначено acrPull в реестре. Чтобы настроить реестр, используйте идентификатор ресурса управляемого удостоверения для удостоверения, назначаемого пользователем, или system удостоверения, назначаемого системой, в identity свойстве реестра. Не настраивайте имя пользователя и пароль при использовании управляемого удостоверения.
{
"identity": {
"type": "SystemAssigned,UserAssigned",
"userAssignedIdentities": {
"<IDENTITY1_RESOURCE_ID>": {}
}
}
"properties": {
"configuration": {
"registries": [
{
"server": "myacr1.azurecr.io",
"identity": "<IDENTITY1_RESOURCE_ID>"
},
{
"server": "myacr2.azurecr.io",
"identity": "system"
}]
}
...
}
}
Дополнительные сведения о настройке назначаемых пользователем удостоверений см. в разделе "Добавление удостоверения, назначаемого пользователем".
Ограничения
Для Контейнеров приложений DNS действуют следующие ограничения.
Привилегированные контейнеры: приложения контейнеров Azure не разрешают режим привилегированных контейнеров с доступом на уровне узла.
Операционная система. Требуются образы контейнеров под управлением Linux (
linux/amd64).Максимальный размер изображения:
- Профиль рабочей нагрузки потребления поддерживает образы контейнеров, составляющие до 8 ГБ для каждого приложения или реплики заданий.
- Выделенные профили рабочей нагрузки поддерживают более крупные образы контейнеров. Так как профиль выделенной рабочей нагрузки может запускать несколько приложений или заданий, несколько образов контейнеров совместно используют доступное место на диске. Фактический поддерживаемый размер изображения зависит от ресурсов, потребляемых другими приложениями и заданиями.