Я следую этому руководству для Google Cloud Platform: https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app. По сути, я клонировал пример проекта hello-app от Github как в Google Cloud (с помощью облачной оболочки Google), так и локально на своем компьютере, потому что я хочу попрактиковаться в этом учебном пособии, используя как облачный подход, так и мой локальный компьютер (с помощью Google Cloud SDK) - где я затем перенесу образ Docker в облако, затем собрал и запустил его в Kubernetes.
1- Первый раз, когда я добрался до шага 8, где я изменил строку исходного кода с «Hello, World» на «Hello, world! Версия 2 »и строка« Версия: 1.0.0 »-« Версия: 2.0.0 »в файле Go, в основном строки:
fmt.Fprintf(w, "Hello, world! Version 2\n")
fmt.Fprintf(w, "Version: 2.0.0\n")
Я понял, что изменил исходный код на своей локальной машине (а не в облаке). Затем я зашел в консоль Google Cloud Shell в консоли, пересоздал образ Docker с тегом v2, а затем отправил его в реестр контейнеров Google (не понимая, что я создаю изображение из проекта неизмененного кода, хранящегося в облако, а не тот, что с моей локальной машины). Когда я применил скользящее обновление к существующему развертыванию с обновлением образа, используя kubectl, неудивительно, что оно не сработало.
Таким образом, чтобы исправить это, мне нужно создать образ из (измененного) проекта исходного кода на моем локальном компьютере и передать его в реестр контейнеров Google (используя оболочку Google Cloud SDK). Это теория (я полагаю, по крайней мере, из моего понимания). Я создал изображение с точно таким же тегом (т. Е. V2), имея в виду, что уже есть изображение v2 (с неизмененным кодом), хранящееся в реестре контейнеров, выполненное с моего предыдущего шага. Мне было интересно, если бы он просто перезаписал существующий образ в реестре контейнеров, что он и сделал (просматривая раздел «Реестр контейнеров»> «Изображения», я вижу изображение v2 с обновлением, отображаемое всего несколько секунд назад).
Теперь все готово для последнего шага, который заключается в применении непрерывного обновления к существующему развертыванию с обновлением образа:
kubectl set image deployment/hello-web hello-web=gcr.io/${PROJECT_ID}/hello-app:v2
Это было успешно, так как я получил ответ:
deployment.extensions/hello-web image updated
Однако, когда я перешел к Kubernetes Engine> Рабочие нагрузки, чтобы просмотреть развернутое приложение в Kubernetes, хотя состояние показывает = OK, в разделе Managed pods отображаются модули, запущенные со вчерашнего и предыдущего дня (в столбец даты Created on, а не развертывание сегодня (29 июня):
1 (a) - что подводит меня к дополнительному вопросу (все еще связанному с первым вопросом), столбец Revision в таблице выше, означает ли это, сколько раз я развертывал новые модули из образа? Потому что на самом деле я пробовал этот шаг несколько раз, в тщетной попытке исправить проблему (думаю, это могло быть 4 раза).
Возвращаясь к основному вопросу, аналогично, если я пытаюсь загрузить внешний сайт из службы Load Balancer, он не показывает измененный код. Кроме того, когда я проверяю последнее изображение, помещенное в Реестр контейнеров, перейдя в Реестр контейнеров> Изображения, я вижу v2 изображения, загруженного несколько минут назад. Таким образом, в Реестр контейнеров действительно загружено последнее загруженное изображение (это означает, что оно перезаписало предыдущую версию 2 с тем же именем изображения в реестре контейнеров. В противном случае должно произойти сбой, если он не может перезаписать его). Поэтому я не совсем понимаю, не должен ли последний шаг (ниже) означать развертывание этого последнего образа v2 из реестра контейнеров?:
kubectl set image deployment/hello-web hello-web=gcr.io/${PROJECT_ID}/hello-app:v2
Я не уверен, что мне не хватает.
2- Поскольку я новичок в Docker, мне было интересно, есть ли способ извлечь изображение из реестра контейнеров и просмотреть исходный код на изображении. В противном случае, как можно проверить, какое изображение содержит какую версию исходного кода? Это может привести к путанице со многими версиями изображений, равно как и со многими версиями изменений в истории исходного кода. Как определить, какой коммит исходного кода соответствует какому образу Docker?
3- Наконец, кто-нибудь может посоветовать лучший PRакты управления Kubernetes, в различных сценариях. Скажем, в сценарии, в котором вы развернули контейнер из обновленной версии образа, но поняли это после того, как возникли проблемы или отсутствуют функции, поэтому вы хотите вернуться к предыдущему развертыванию. Так есть ли лучшие практики для управления такими сценариями.
Извиняюсь за скучный текст, и большое спасибо заранее.