предыдущие части:
Google Cloud Endpoints на Java: Руководство. ч. 1
Google Cloud Endpoints на Java: Руководство. ч. 2 (Frontend)
Работа с версиями
Google App Engine предоставляет возможность загрузить до 10 различных версий приложения.
Одна из них (по умолчанию — первая загруженная) является основной (default) и доступна по основному адресу приложения, и соответственно по адресу собственного домена(ов).
Остальные доступны по адресу вида {версия}-dot-{проект ID}.appspot.com
Версии называть можно как угодно, это не обязательно должно быть 1-dot-{проект ID}.appspot.com, можно применять более сложные обозначения, что в частности делает адрес сырой версии труднодоступным для широкой аудитории
Но, естественно, поскольку имя версии становиться частью веб-адреса, то там не должно быть точки или символов недопустимых в веб-адресах.
Для A/B тестирования, можно включить traffic splitting и перенаправлять определенный процент посетителей на версию отличную от версии по умолчанию.
Управление версиями доступно в меню разработчика: Compute -> App Engine -> Versions:
В приложении мы указываем версии в двух местах в /src/main/webapp/WEB-INF/appengine-web.xml:
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>{проект ID}</application> <version>{наименование версии}</version> — это собственно версия приложения в GAE,
и в pom.xml:
<modelVersion>4.0.0</modelVersion> <packaging>war</packaging> <version>{версия}</version> — это будет часть названия .war-файла: target/{проект ID}-{версия}.war
Собственно обозначения версии в appengine-web.xml и pom.xml технически не связаны и могут быть совершенно разными, но с точки зрения поддержания порядка логично чтобы они совпадали.
Команда mvn appengine:update размещает обновления в версию с именем ‘1’ независимо от версии .war файла и значения версии указанного в /src/main/webapp/WEB-INF/appengine-web.xml
Поэтому для работы с разными версиями приложения нам потребуется Google App Engine SDK. На момент написания данной статьи последняя версия 1.9.28. Скачиваем на: cloud.google.com/appengine/downloads#Google_App_Engine_SDK_for_Java и разархивируем в директорию по выбору, и, для удобства, прописываем в PATH, например:
mkdir ~/GAE-SDK # any path you like cd $_ wget https://storage.googleapis.com/appengine-sdks/featured/appengine-java-sdk-1.9.28.zip unzip appengine-java-sdk-1.9.28.zip cd appengine-java-sdk-1.9.28/bin echo 'export PATH=$PATH:'$(pwd) >> ~/.bashrc # adds current dir to PATH source ~/.bashrc cd Для деплоя используется утилита appcfg.sh, в директории проекта запускаем команду:
appcfg.sh update ./src/main/webapp/ --noisy Утилита производит аутентификацию пользователя через браyзер, и сохраняет токены в ~/.appcfg_oauth2_tokens_java
В качестве параметров указываем путь к директории в которой располагается WEB-INF, где в свою очередь находиться appengine-web.xml, и проект будет загружен на сервер в версию наименование которой указанно в appengine-web.xml
Ну и при смене версий надо не забывать обозначать смену версий в комментариях коммитов git.
Скачивание файлов проекта с сервера
С помощью утилиты также можно скачать файлы проекта с сервера. Это делается командой вида:
appcfg.sh -A {проект ID} -V {имя версии} download_app {директория для скачивания}
например:
appcfg.sh -A hello-habrahabr-api -V '1' download_app temp_hello-habrahabr-api.1 Скачанный проект будет выглядеть примерно так:
или так:
Т.е. это результат развертывания .war на сервере но не сам .war и не исходный код.
Скачивание логов с сервера
Логи могут быть скачаны с сервера на локальную машину с помощью той же утилиты в формате простого текстового файла командой вида:
appcfg.sh -A {проект ID, можно упускать — используется из appengine-web.xml} -V {имя версии} —num_days={количество дней, по умолчанию: 1, доступно до 90} —severity={уровень 0 (DEBUG) дo 4 (CRITICAL), если этот параметр пропущен, скачиваются только логи запросов} request_logs src/main/webapp/ {файл для сохранения информации)
Можно также указать опции:
—append (добавить к существующему файлу)
—include_all (включить все содержимое log messages)
—noisy (выводить больше информации о работе утилиты)
Например:
appcfg.sh -A 'hello-habrahabr-api' -V '1' --num_days=90 --noisy request_logs src/main/webapp/ ../$(date '+%Y-%m-%d').LOGS.txt Google Cloud Shell
Еще одной интересной функцией консоли разработчика является Google Cloud Shell.
По клику на пиктограмму изображающую терминал в верхней панели в нижней части страницы запускается консоль, и мы получаем доступ в виртуальную машину Debian-based Linux с предустановленными инструментами необходимыми для работы с облачными сервисами Google, в частности: стандартные утилиты Debian-based Linux, в т.ч. apt-get, wget и др.; Java 7; Maven 3.2; Git; Python 2.7 и pip; Node.js и npm; Google Cloud SDK; Google App Engine SDK; Vim, Nano, Emacs.
Пользователю выделяется 5GB постоянного места на диске, но сохраняется между перезапусками только домашняя директория пользователя. То есть программы, файлы, и настройки в домашней директории будут доступны при каждом новом входе. Можно устанавливать программы с помощью но apt-get — но только на один сеанс.
Доступна также функция Web preview: можно запустить веб сервер (например python -m SimpleHTTPServer) с портом в диапазоне от 8080 до 8084, и открыть его в отдельном окне/вкладке браузера кнопкой «web preview» (доступен только данному пользователю)
Так выглядит Cloud Shell. Стрелками обозначены кнопки запуска консоли и Web preview.
ссылка на оригинал статьи http://habrahabr.ru/post/271385/
Добавить комментарий