Переходя к контейнерам, я осознаю, что концепция контейнеров связывает ОС и Приложение в одну и ту же систему развертывания.
Фон
docker pull mcr. microsoft.com/dotnet/core/runtime:3.1.1-buster-slim
Эта команда извлекает настройку образа контейнера Microsoft для. NET Core Runtime. Это изображение контейнера зависит от mcr.microsoft.com/dotnet/core/runtime-deps:3.1-buster-slim изображения контейнера. И этот образ контейнера runtime-deps создается из образа debian:buster-slim.
Образ debian:buster-slim в настоящее время предназначен для версии 10.2 Linux Debian. Но когда выйдет 10.3, он будет нацелен на 10.3. (И я предполагаю, что он был нацелен на 10.1, когда это был текущий выпуск.)
Вопрос
Когда тег buster-slim из debian обновляется до цели 10.3, выполните все загрузки mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim получить обновление, чтобы начать использовать 10.3?
Или mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim каким-то образом заблокирован в 10.2?
Я беспокоюсь о том, как это происходит:
- I создайте контейнер, который зависит от
mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim, и выпустите его для производства (который запускает Debian 10.2) - Debian выпускает 10.3 своей ОС и обновляет тег
buster-slim, чтобы он указывал на 10.3. - Я делаю очень незначительные изменения в своем контейнере (с шага 1), перестраиваю образ контейнера и разворачиваю его Но из-за того, как работает docker, мое небольшое изменение также включает непреднамеренное обновление ОС до Debian 10.3.
Я ожидаю что-то подобное при использовании тега latest, но не при использовании определенный c тег.
Таким образом, это можно подытожить следующим вопросом:
Собираюсь ли я получить обновления зависимостей для тега, даже если я продолжаю использовать точный тот же тег?