Развертывание приложений в среде тестирования и рабочей среде
improve this page | report issueОбзор
После завершения цикла разработки приложение развертывается в среде тестирования, а затем
- в рабочей среде.
Перейти к
- Развертывание или обновление адаптера в рабочей среде
- Настройка SSL между адаптерами и базовыми серверами с помощью собственных сертификатов
- Компоновка приложения для тестовой или рабочей среды
- Регистрация приложения в рабочей среде
- Передача серверных артефактов на тестовый или рабочей сервер
- Обновление приложений MobileFirst в рабочей среде
Развертывание или обновление адаптера в рабочей среде
Адаптеры содержат серверный код приложений, которые развертываются в Mobile Foundation и обслуживаются этим продуктом. Ознакомьтесь со следующим контрольным списком перед развертыванием или обновлением адаптера в рабочей среде. Дополнительная информация о создании и компоновке адаптеров приведена в разделе Разработка серверной части приложения MobileFirst.
Операции передачи, обновления и настройки адаптеров можно выполнять только в том случае, если рабочий сервер запущен. После передачи нового адаптера или конфигурации на все узлы фермы серверов новые параметры начинают применяться для обработки всех входящих запросов к адаптеру.
-
В случае обновления существующего адаптера в рабочей среде убедитесь, что в адаптере отсутствуют несовместимости или регрессии с существующими приложениями, зарегистрированными на сервере.
Один и тот же адаптер может использоваться несколькими приложениями или несколькими версиями одного приложения, опубликованными в магазине. Перед обновлением адаптера в рабочей среде выполните тесты без регрессии на сервере тестирования для нового адаптера и копий приложений, скомпонованных для сервера тестирования.
-
Если адаптер Java использует URLConnection с HTTPS, сертификаты базовой системы должны быть доступны в хранилище ключей MobileFirst Server.
Дополнительная информация приведена в разделе Использование SSL в адаптерах HTTP. Дополнительная информация о собственных сертификатах приведена в разделе Настройка SSL между адаптерами и базовыми серверами с помощью собственных сертификатов
Примечание: если в качестве сервера приложений применяется WebSphere Application Server Liberty, то сертификаты также следует разместить в хранилище доверенных сертификатов Liberty.
- Проверьте конфигурацию адаптера на стороне сервера.
-
Передайте адаптер вместе с конфигурацией с помощью команд
mfpadm deploy adapter
иmfpadm adapter set user-config
.Дополнительная информация о команде mfpadm для адаптеров приведена в разделе Команды для адаптеров.
Настройка SSL между адаптерами и базовыми серверами с помощью собственных сертификатов
Вы можете настроить SSL между адаптерами и базовыми серверами путем импорта собственных сертификатов SSL сервера в хранилище ключей MobileFirst.
-
Экспортируйте общий сертификат сервера из хранилища ключей базового сервера.
Примечание: для экспорта общих сертификатов сервера из хранилища ключей базового сервера следует использовать keytool или библиотеку openssl. Не используйте функцию экспорта в веб-браузере.
- Импортируйте сертификат базового сервера в хранилище ключей MobileFirst.
- Разверните новое хранилище ключей MobileFirst. Дополнительная информация приведена в разделе Настройка хранилища ключей MobileFirst Server.
Пример
Имя CN сертификата базовой системы должно совпадать со значением, настроенным в файле описания адаптера adapter.xml. В качестве примера рассмотрим следующих файл adapter.xml:
<protocol>https</protocol>
<domain>mybackend.com</domain>
Сертификат базового сервера должен содержать CN=mybackend.com.
Еще один пример конфигурации адаптера:
<protocol>https</protocol>
<domain>123.124.125.126</domain>
Сертификат базового сервера должен содержать CN=123.124.125.126.
В следующем примере рассмотрена настройка с помощью программы Keytool.
-
Создайте хранилище ключей базового сервера с частным сертификатом со сроком действия 365 дней.
keytool -genkey -alias backend -keyalg RSA -validity 365 -keystore backend.keystore -storetype JKS
Примечание: поле Имя и фамилия содержит URL сервера, применяемый в файле конфигурации adapter.xml, например mydomain.com или localhost.
-
Настройте базовый сервер для работы с хранилищем ключей. Например, в Apache Tomcat необходимо внести изменения в файл server.xml:
<Connector port="443" SSLEnabled="true" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="200" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="backend.keystore" keystorePass="password" keystoreType="JKS" keyAlias="backend"/>
-
Проверьте конфигурацию соединений в файле adapter.xml:
<connectivity> <connectionPolicy xsi:type="http:HTTPConnectionPolicyType"> <protocol>https</protocol> <domain>mydomain.com</domain> <port>443</port> <!-- Администратор ключей адаптера использует следующие свойства для выбора конкретного сертификата в хранилище ключей <sslCertificateAlias></sslCertificateAlias> <sslCertificatePassword></sslCertificatePassword> --> </connectionPolicy> <loadConstraints maxConcurrentConnectionsPerNode="2"/> </connectivity>
-
Экспортируйте общий сертификат из созданного хранилища ключей базового сервера:
keytool -export -alias backend -keystore backend.keystore -rfc -file backend.crt
-
Импортируйте экспортированный сертификат в хранилище ключей MobileFirst Server:
keytool -import -alias backend -file backend.crt -storetype JKS -keystore mfp.keystore
-
Убедитесь, что сертификат правильным образом импортирован в хранилище ключей:
keytool -list -keystore mfp.keystore
-
Разверните новое хранилище ключей MobileFirst Server.
Компоновка приложения для тестовой или рабочей среды
Компоновка приложения для тестовой или рабочей среды предусматривает его настройку для целевого сервера. В случае компоновки приложения для рабочей среды требуются дополнительные действия.
-
Убедитесь, что на целевом сервере настроено хранилище ключей. Дополнительная информация приведена в разделе Настройка хранилища ключей MobileFirst Server.
- Если требуется распространить устанавливаемый артефакт приложения, увеличьте версию приложения.
-
Перед тем как приступить к компоновке приложения, настройте его для целевого сервера.
Укажите URL и имя среды выполнения целевого сервера в файле свойств клиента. Кроме того, целевой сервер можно изменить с помощью MobileFirst CLI. Для того чтобы настроить приложение для целевого сервера без регистрации приложения на активном сервере, выполните команды
mfpdev app config server <server URL>
и `mfpdev app config runtime
Измените следующие элементы URL с учетом конфигурации сервера: * **9080** - это порт HTTP по умолчанию, применяемый MobileFirst Server в ходе разработки. * **mfpadmin** - это корневой контекст службы администрирования. Дополнительная информация об API REST приведена в разделе API REST для службы администрирования MobileFirst Server. * Загрузите дескриптор приложения с помощью команды **mfpadm**. Программа **mfpadm** устанавливается программой установки MobileFirst Server. Ее следует запускать из каталога **product\_install\_dir/shortcuts/**, где **product\_install\_dir** - это установочный каталог MobileFirst Server. Следующий пример создает файл пароля, необходимый для команды **mfpadm**, затем загружает дескриптор приложения с ИД **my.test.application** для платформы **ios** и версии **0.0.1**. В команде указан URL HTTPS сервера MobileFirst Server, который использовался для разработки. ```bash echo password=admin > password.txt mfpadm --url https://localhost:9443/mfpadmin --secure false --user admin \ --passwordfile password.txt \ app version mfp my.test.application ios 0.0.1 get descriptor > desc.json rm password.txt ``` Измените следующие элементы командной строки с учетом конфигурации сервера: * **9443** - это порт HTTPS по умолчанию, применяемый MobileFirst Server в ходе разработки. * **mfpadmin** - это корневой контекст службы администрирования. * --secure false указывает, что сертификат SSL сервера принимается даже в том случае, если он является собственным или создан для другого имени хоста. Дополнительная информация о программе **mfpadm** приведена в разделе [Администрирование приложений MobileFirst с помощью командной строки](../using-cli). 3. Передайте дескриптор приложения на новый сервер, чтобы зарегистрировать приложение или обновить его конфигурацию. Для этой цели можно использовать API REST или **mfpadm**. * Для передачи дескриптора приложения с помощью API REST примеряется API REST [Приложение (POST)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_application_post.html?view=kc#Application--POST-). Следующий URL позволяет передать дескриптор приложения в среду выполнения mfp. Отправьте запрос POST, указав дескриптор приложения в формате JSON в качестве полезных данных. В этом примере вызывается сервер, работающий в локальной системе, через порт HTTP 9081. ```bash http://localhost:9081/mfpadmin/management-apis/2.0/runtimes/mfp/applications/ ``` Например, URL можно указать в инструменте, таком как curl. ```bash curl -H "Content-Type: application/json" -X POST -d @desc.json -u admin:admin \ http://localhost:9081/mfpadmin/management-apis/2.0/runtimes/mfp/applications/ ``` * Передайте дескриптор приложения с помощью команды mfpadm. Следующий пример создает файл пароля, необходимый для команды mfpadm, затем передает дескриптор приложения с ИД my.test.application для платформы ios и версии 0.0.1. В команде указан URL HTTPS сервера, работающего в локальной системе, с портом HTTPS 9444 и средой выполнения mfp. ```bash echo password=admin > password.txt mfpadm --url https://localhost:9444/mfpadmin --secure false --user admin \ --passwordfile password.txt \ deploy app mfp desc.json rm password.txt ``` ### Передача серверных артефактов с помощью API REST {: #transferring-server-side-artifacts-by-using-the-rest-api } Вне зависимости от роли вы можете экспортировать приложения, адаптеры и ресурсы для целей резервными копиями и повторного использования с помощью службы администрирования MobileFirst Server. Кроме того, администратор или ответственный за развертывание может развернуть экспортированный архив на другом сервере. Доступ к коду приложения не требуется, однако клиентское приложение должно быть скомпоновано для целевого сервера. #### Перед тем как начать {: #before-you-begin-2 } Скомпонуйте клиентское приложение для целевого сервера. Дополнительная информация приведена в разделе [Компоновка приложения для тестовой или рабочей среды](#building-an-application-for-a-test-or-production-environment). API экспорта извлекает выбранные артефакты для среды выполнения в виде архива .zip. Для повторного использования содержимого из архива применяется API развертывания. > **Важная информация:** внимательно изучите ваш вариант использования: > > * Файл экспорта включает данные о подлинности приложения. Эти данные относятся к компоновке мобильного приложения. В мобильном приложении указаны URL сервера и имя среды выполнения. Следовательно, для применения другого сервера или среды выполнения потребуется повторная компоновка приложения. Передача только экспортированных файлов приложения не работает. > * Разные серверы могут использовать различные наборы артефактов. Идентификационные данные push-уведомлений зависят от того, работаете ли вы в среде разработки или рабочей среде. > * Конфигурация среды выполнения приложения (содержащая активное/выключенное состояние и профайлы протоколов) может быть передана не во всех случаях. > * Передача веб-ресурсов не всегда целесообразна, например в случае повторной компоновки приложения для нового сервера. * Для экспорта всех ресурсов или выбранного подмножества ресурсов отдельного адаптера или всех адаптеров можно использовать API [Экспортировать ресурсы адаптера (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_export_adapter_resources_get.html?view=kc) или [Экспортировать адаптеры (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_export_adapters_get.html?view=kc). * Для экспорта всех ресурсов из конкретной среды приложения (такой как Android или iOS), включая все версии и все ресурсы версий, можно использовать API [Экспортировать среду приложения (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_export_application_environment_get.html?view=kc). * Для экспорта всех ресурсов конкретной версии приложения(например, версии 1.0 или 2.0 приложения Android) можно использовать API [Экспортировать ресурсы среды приложения (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_export_application_environment_resources_get.html?view=kc). * Для экспорта конкретного приложения или всех приложений для среды выполнения можно использовать API [Экспортировать приложения (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_export_applications_get.html?view=kc) или [Экспортировать ресурсы приложения (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_export_application_resources_get.html?view=kc). Примечание: вместе с ресурсами приложения экспортируются идентификационные данные push-уведомлений. * Для экспорта содержимого адаптера, дескриптора, конфигурации лицензий, содержимого, конфигурации пользователей, хранилища ключей и веб-ресурсов приложения можно использовать API [Экспортировать ресурсы (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_export_resources_get.html?view=kc#Export-resources--GET-). * Для экспорта всех или выбранных ресурсов среды выполнения можно использовать API [Экспортировать ресурсы среды выполнения (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_export_runtime_resources_get.html?view=kc). Пример общей команды curl для извлечения всех ресурсов в файл .zip. ```bash curl -X GET -u admin:admin -o exported.zip "http://localhost:9080/worklightadmin/management-apis/2.0/runtimes/mfp/export/all" ``` * Для развертывания архива, содержащего такие ресурсы веб-приложения, как адаптер, приложение, конфигурация лицензии, хранилище ключей, веб-ресурс, можно использовать API [Развернуть (POST)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_deploy_post.html?view=kc). Пример команды curl для развертывания существующего файла .zip с артефактами. ```bash curl -X POST -u admin:admin -F file=@/Users/john_doe/Downloads/export_applications_adf_ios_2.zip "http://localhost:9080/mfpadmin/management-apis/2.0/runtimes/mfp/deploy/multi" ``` * Для развертывания данных о подлинности приложения применяется API [Развернуть данные о подлинности приложения (POST)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_deploy_application_authenticity_data_post.html?view=kc). * Для развертывания веб-ресурсов приложения применяется API [Развернуть веб-ресурс (POST)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_deploy_a_web_resource_post.html?view=kc). Если для развертывания архива выбрана та же среда выполнения, то приложение или версия не всегда восстанавливается до исходного состояния. Таким образом, повторное развертывание не удаляет последующие изменения. Если ресурсы приложения были изменены после экспорта, то в ходе повторного развертывания в исходное состояние возвращаются только ресурсы из экспортированного архива. Например, если экспортировать приложение без данных о подлинности, затем передать данные о подлинности, а после этого импортировать исходный архив, то данные о подлинности не будут удалены. ### Экспорт и импорт приложений и адаптеров из MobileFirst Operations Console {: #exporting-and-importing-applications-and-adapters-from-the-mobilefirst-operations-console } С помощью консоли можно экспортировать приложение или одну из его версий и затем импортировать его в другую среду выполнения на том же или другом сервере. Кроме того, можно экспортировать и заново импортировать адаптеры. Эта функция предназначена для целей повторного использования и резервного копирования. Если вам предоставлена роль администратора **mfpadmin** и роль развертывающего **mfpdeployer**, то вы можете экспортировать отдельную или все версии приложения. Приложение или версия поддерживается в виде файла .zip вместе с ИД приложения, дескрипторами, данными о подлинности и веб-ресурсами. Впоследствии можно импортировать архив для повторного развертывания приложения или версии в другой среде выполнения на том же или другом сервере. > **Важная информация:** внимательно изучите ваш вариант использования: > > * Файл экспорта включает данные о подлинности приложения. Эти данные относятся к компоновке мобильного приложения. В мобильном приложении указаны URL сервера и имя среды выполнения. Следовательно, для применения другого сервера или среды выполнения потребуется повторная компоновка приложения. Передача только экспортированных файлов приложения не работает. > * Разные серверы могут использовать различные наборы артефактов. Идентификационные данные push-уведомлений зависят от того, работаете ли вы в среде разработки или рабочей среде. > * Конфигурация среды выполнения приложения (содержащая активное/выключенное состояние и профайлы протоколов) может быть передана не во всех случаях. > * Передача веб-ресурсов не всегда целесообразна, например в случае повторной компоновки приложения для нового сервера. Кроме того, дескрипторы приложений можно передать с помощью API REST или инструмента mfpadm. Дополнительная информация приведена в разделе [Передача конфигурации приложения с помощью службы администрирования](#transferring-an-application-configuration-with-the-administration-service). 1. На боковой панели навигации выберите приложений, версию приложения или адаптер. 2. Выберите **Действия → Экспортировать приложение**, **Экспортировать версию** или **Экспортировать адаптер**. Будет предложено сохранить файл .zip с экспортированными ресурсами. Окно диалога зависит от браузера, а целевая папка - от параметров браузера. 3. Сохраните файл архива. Имя файла архива содержит имя и версию приложения или адаптера, например **export_applications_com.sample.zip**. 4. Для повторного использования экспортированного архива выберите **Действия → Импортировать приложение** или **Импортировать версию**, выберите архив и нажмите кнопку **Развернуть**. В основном фрейме консоли показаны сведения об импортированном приложении или адаптере. Если для импорта выбрана та же среда выполнения, то приложение или версия не всегда восстанавливается до исходного состояния. Таким образом, повторное развертывание в ходе импорта не удаляет последующие изменения. Если ресурсы приложения были изменены после экспорта, то в процессе импорта в исходное состояние возвращаются только ресурсы из экспортированного архива. Например, если экспортировать приложение без данных о подлинности, затем передать данные о подлинности, а после этого импортировать исходный архив, то данные о подлинности не будут удалены. ## Обновление приложений MobileFirst в рабочей среде {: #updating-mobilefirst-apps-in-production } При обновлении приложений MobileFirst, которые уже доступны рабочей среде, в Application Center или в магазинах приложений, следует придерживаться общих рекомендаций. После развертывания новой версии приложения вы можете оставить старую версию в работе или блокировать ее. В случае приложения, разработанного с помощью Apache Cordova, можно ограничиться только обновлением веб-ресурсов. ### Развертывание новой версии приложения без прерывания работы старой версии {: #deploying-a-new-app-version-and-leaving-the-old-version-working } При добавлении новых функции или изменении нативного кода процесс обновления, как правило, предусматривает выпуск новой версии приложения. Рекомендуется выполнить следующие действия: 1. Увеличьте номер версии приложения. 2. Выполните компоновку и тестирование приложения. Дополнительная информация приведена в разделе [Компоновка приложения для тестовой или рабочей среды](#building-an-application-for-a-test-or-production-environment). 3. Зарегистрируйте приложение в MobileFirst Server и настройте его. 4. Передайте новые файлы .apk, .ipa, .appx или .xap в соответствующие магазины приложений. 5. Дождитесь публикации приложений после проверки и утверждения. 6. Необязательно: отправьте пользователям старой версии уведомление о выходе новой версии. См. разделы [Отображение сообщения администратора](../using-console/#displaying-an-administrator-message) и [Определение сообщений администратора на разных языках](../using-console/#defining-administrator-messages-in-multiple-languages). ### Развертывание новой версии приложения с блокировкой старой версии {: #deploying-a-new-app-version-and-blocking-the-old-version } Эта процедура обновления предусматривает принудительный переход пользователей на новую версию приложения с блокировкой доступа к старой версии. Рекомендуется выполнить следующие действия: 1. Необязательно: отправьте пользователям старой версии уведомление об обязательном переходе на новую версию через несколько дней. См. разделы [Отображение сообщения администратора](../using-console/#displaying-an-administrator-message) и [Определение сообщений администратора на разных языках](../using-console/#defining-administrator-messages-in-multiple-languages). 2. Увеличьте номер версии приложения. 3. Выполните компоновку и тестирование приложения. Дополнительная информация приведена в разделе [Компоновка приложения для тестовой или рабочей среды](#building-an-application-for-a-test-or-production-environment). 4. Зарегистрируйте приложение в MobileFirst Server и настройте его. 5. Передайте новые файлы .apk, .ipa, .appx или .xap в соответствующие магазины приложений. 6. Дождитесь публикации приложений после проверки и утверждения. 7. Скопируйте ссылки на новую версию приложения. 8. Заблокируйте старую версию приложения в MobileFirst Operations Console, указав сообщение и ссылку на новую версию. См. раздел [Удаленный запрет доступа приложения к защищенным ресурсам](../using-console/#remotely-disabling-application-access-to-protected-resources). > **Примечание:** после блокировки старое приложение больше не сможет взаимодействовать с MobileFirst Server. Пользователи по-прежнему смогут запускать приложение и работать с ним в автономном режиме, если вы активируете принудительное подключение к серверу при запуске приложения. ### Непосредственное обновление (без изменения нативного кода) {: #direct-update-no-native-code-changes } Непосредственное обновление - это обязательный механизм обновления, применяемый для развертывания быстрых исправлений в рабочем приложении. В случае повторного развертывания приложения в MobileFirst Server без изменения его версии MobileFirst Server передает обновленные веб-ресурсы на устройство, когда пользователь подключается к серверу. При этом не передается обновленный нативный код. Обратите внимание на следующие особенности непосредственного обновления: 1. Непосредственное обновление не изменяет версию приложения. Версия приложения сохраняется, однако изменяется набор веб-ресурсов. Сохранение версии может вызывать путаницу в случае неправильного применения 2. Непосредственное обновление не требует повторного утверждения магазином приложений, поскольку с технической точки зрения это не новый выпуск. Этим не следует злоупотреблять, поскольку вендорам может не понравиться, если вы развернете новую версию приложения, не пройдя проверку. Вся ответственность за изучение условий использования каждого магазина и их соблюдение лежит на вас. Непосредственное обновление оптимальным образом подходит для оперативного устранения неполадок, которые не могут ждать несколько дней. 3. Непосредственное обновление считается механизмом обеспечения безопасности и является обязательным. При запуске непосредственного обновления все пользователи должны обновить приложение, чтобы продолжить работу с ним. 4. Непосредственное обновление не будет работать, если приложение скомпилировано (скомпоновано) с помощью версии Mobile Foundation, отличной от той, которая использовалась для начального развертывания. > **Примечание:** архивы/файлы IPA, созданные с помощью Test Flight или iTunes Connect для отправки в магазин/проверки приложений iOS, могут вызывать сбой среды выполнения. Дополнительная информация приведена в блоге [Подготовка приложений iOS к отправке в App Store в Mobile Foundation](https://mobilefirstplatform.ibmcloud.com/blog/2016/10/17/prepare-ios-apps-for-app-store-submission/).
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.