# #google-cloud-platform #google-cloud-storage #google-cloud-build
Вопрос:
- name: 'google/cloud-sdk:alpine'
entrypoint: 'gsutil'
args: ['-m', 'rsync', '-r', '-d', '-p', 'dist/', 'gs://my-site-frontend']
Доброе утро, приведенный выше фрагмент-это команда, которая с помощью Google Cloud Build копирует сборку моего интерфейса VueJS в хранилище Google Cloud, где будет размещен веб-сайт.
Мой вопрос прост и краток: если какой-либо пользователь просматривает во время этого развертывания (выполнение команды выше), заметит ли он какие-либо несоответствия, простои или что-то в этом роде, когда Cloud Build копирует/синхронизирует новые файлы через rsync? Достаточно ли легко выполнить эту задачу? Может быть, пользователь может почувствовать некоторую несогласованность при доступе к какому-либо копируемому файлу? Должен ли я вместо этого использовать Cloud Run?
Комментарии:
1. Если вы размещаете веб-сайт в статическом режиме, вы можете создавать новую корзину при каждом развертывании и в конце изменять DNS, чтобы указывать на новый веб-сайт.
Ответ №1:
Да, некоторое время у вас может быть несогласованность (файлы устарели или не найдены). Лучшим решением является использование продукта, который последовательно упаковывает источники. Вы можете использовать облачный запуск, но для этого вы также можете использовать стандарт App Engine.
Основное преимущество этих 2 решений заключается в том, что каждая версия является единой, упакованной в один и тот же контейнер. Таким образом, вы можете легко выполнить откат, разделение трафика, выпуск канарейки, A/B-тестирование,…. Все это невозможно с облачным хранилищем.
Комментарии:
1. Еще раз спасибо. Вы всегда очень полезны.
Тогда я буду использовать облачный запуск.
2. Может ли облачный CDN или какая-либо другая стратегия помочь кому-либо развернуть интерфейс VueJS в облачном хранилище, не страдая от этих временных несоответствий во время развертывания?
3. Облачный CDN или другая стратегия кэширования могут помочь вам или убить вас! Действительно, если все файлы кэшируются одновременно, это может вам помочь. Если файлы не загружаются в одно и то же время, например, с интервалом в 1 минуту каждый, CDN создаст несоответствие, обслуживая устаревшие и несуществующие файлы. Если вы используете CDN, аннулируйте кэш после развертывания.
4. Спасибо, так что я буду в порядке с несоответствиями во времени развертывания (404 или устаревшие файлы), если я буду использовать облачный CDN и аннулировать его после каждого развертывания? Доступ к файлам всегда будет осуществляться с CDN и никогда (напрямую) из корзины? Кроме того, какой конвейер/стратегию развертывания для облачного хранилища с облачной сборкой вы бы порекомендовали, чтобы я мог вернуться к предыдущей сборке? Управление версиями объектов кажется негибким для отката на уровне проекта.
5. GCS не является хорошим кандидатом для легкого отката. Самый простой способ-сделать резервную копию файлов текущей редакции по другому пути в GCS и перезаписать их в текущей новой версией.