Я смотрел на https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade и смотрел, можем ли мы изменить нашу VMSS (в настоящее время использующую режим политики обновления вручную) на автоматическое обновляемое обновление, но обнаружил, что зонд работоспособности приложения не может использовать наше существующее приложениеПроверка работоспособности шлюза, так как она должна быть именно LoadBalancer.Облом.
В любом случае, я решил протестировать нашу VMSS, чтобы убедиться, что мы можем вручную обновить каждый экземпляр из Portal / CLI, но намеренно выбрал старый идентификатор изображения 16.04 LTS (вместо тега 'последней' версии),Из "az vm image list --location canadacentral --publisher Canonical --offer UbuntuServer --SKU 16.04-LTS --all --output table" я выбрал первое изображение 16.04, опубликованное в 2018 году, т.е. 16.04.201801050.Последний из них - «16.04.201811140»
Microsoft.Compute / virtualMachineScaleSets / cluster? Api-версия = 2018-06-01:
"properties": {
"singlePlacementGroup": false,
"upgradePolicy": {
"mode": "Manual",
"automaticOSUpgrade": false
},
...
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "16.04.201801050"
},
Я могуподтвердите, что каждый новый экземпляр VMSS действительно имеет желаемое изображение «16.04.201801050» по SSH на коробке (с большим количеством обновлений для применения):
```
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.11.0-1016-azure x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud
202 packages can be updated.
118 updates are security updates.
jiraadmin@jiranode-000001:~$ apt list linux-image-azure
Listing... Done
linux-image-azure/xenial-updates,xenial-security 4.15.0.1032.37 amd64 [upgradable from: 4.11.0.1016.16]
N: There is 1 additional version. Please use the '-a' switch to see it
```
, но я был удивлен, увидев, что портал и RESTВ API для каждого экземпляра с примененной последней моделью установлено значение true (что явно не так)
Microsoft.Compute / virtualMachineScaleSets / cluster / virtualMachines / 0? Api-version = 2018-06-01:
"properties": {
"latestModelApplied": true,
"vmId": "...",
"hardwareProfile": {},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "16.04.201801050"
}
Нажатие на кнопку «Обновить» для экземпляра виртуальной машины на портале Azure запускает очень короткую задачу без изменений в базовой виртуальной машине.
Поэтому я предположил следующее:
- При указании более старой версии образа перед «последней» необходимо установить для параметра lastModelApplied экземпляра VMSS значение false
- При нажатии кнопки «Обновить» из Poisal должно появиться «старыйmsgstr "версия изображения до" последней "версии образа, т.е., по сути, выполняющая 'sudo apt-get upgrade' или 'sudo apt dist-upgrade'.С lastModelApplied в false, это также не работает.
- Нажав на Reimage на портале, вы получаете предупреждение о возвращении экземпляра в исходное состояние, но из https://docs.microsoft.com/en-us/rest/api/compute/virtualmachinescalesets/reimage он предполагает, что собираетсяобновить образ ОС, т.е.
sudo apt dist-upgrade.Он делает первое, переустанавливает исходный образ, сдувая все.
Так что, как мне кажется, через минуту вы не можете использовать Портал для поддержки обновлений ОС и безопасности на работающей в данный момент ВМ из-зак ошибочному свойству latestModelApplied.Правильно ли поведение и мои предположения выше?
Спасибо, Стивен.