Развертывание приложений в среде тестирования и рабочей среде

improve this page | report issue

Обзор

После завершения цикла разработки приложение развертывается в среде тестирования, а затем

  • в рабочей среде.

Перейти к

Развертывание или обновление адаптера в рабочей среде

Адаптеры содержат серверный код приложений, которые развертываются в Mobile Foundation и обслуживаются этим продуктом. Ознакомьтесь со следующим контрольным списком перед развертыванием или обновлением адаптера в рабочей среде. Дополнительная информация о создании и компоновке адаптеров приведена в разделе Разработка серверной части приложения MobileFirst.

Операции передачи, обновления и настройки адаптеров можно выполнять только в том случае, если рабочий сервер запущен. После передачи нового адаптера или конфигурации на все узлы фермы серверов новые параметры начинают применяться для обработки всех входящих запросов к адаптеру.

  1. В случае обновления существующего адаптера в рабочей среде убедитесь, что в адаптере отсутствуют несовместимости или регрессии с существующими приложениями, зарегистрированными на сервере.

    Один и тот же адаптер может использоваться несколькими приложениями или несколькими версиями одного приложения, опубликованными в магазине. Перед обновлением адаптера в рабочей среде выполните тесты без регрессии на сервере тестирования для нового адаптера и копий приложений, скомпонованных для сервера тестирования.

  2. Если адаптер Java использует URLConnection с HTTPS, сертификаты базовой системы должны быть доступны в хранилище ключей MobileFirst Server.

    Дополнительная информация приведена в разделе Использование SSL в адаптерах HTTP. Дополнительная информация о собственных сертификатах приведена в разделе Настройка SSL между адаптерами и базовыми серверами с помощью собственных сертификатов

    Примечание: если в качестве сервера приложений применяется WebSphere Application Server Liberty, то сертификаты также следует разместить в хранилище доверенных сертификатов Liberty.

  3. Проверьте конфигурацию адаптера на стороне сервера.

  4. Передайте адаптер вместе с конфигурацией с помощью команд mfpadm deploy adapter и mfpadm adapter set user-config.

    Дополнительная информация о команде mfpadm для адаптеров приведена в разделе Команды для адаптеров.

Настройка SSL между адаптерами и базовыми серверами с помощью собственных сертификатов

Вы можете настроить SSL между адаптерами и базовыми серверами путем импорта собственных сертификатов SSL сервера в хранилище ключей MobileFirst.

  1. Экспортируйте общий сертификат сервера из хранилища ключей базового сервера.

    Примечание: для экспорта общих сертификатов сервера из хранилища ключей базового сервера следует использовать keytool или библиотеку openssl. Не используйте функцию экспорта в веб-браузере.

  2. Импортируйте сертификат базового сервера в хранилище ключей MobileFirst.
  3. Разверните новое хранилище ключей 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.

  1. Создайте хранилище ключей базового сервера с частным сертификатом со сроком действия 365 дней.

     keytool -genkey -alias backend -keyalg RSA -validity 365 -keystore backend.keystore -storetype JKS

    Примечание: поле Имя и фамилия содержит URL сервера, применяемый в файле конфигурации adapter.xml, например mydomain.com или localhost.

  2. Настройте базовый сервер для работы с хранилищем ключей. Например, в 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"/>

  3. Проверьте конфигурацию соединений в файле 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>

  4. Экспортируйте общий сертификат из созданного хранилища ключей базового сервера:

    keytool -export -alias backend -keystore backend.keystore -rfc -file backend.crt

  5. Импортируйте экспортированный сертификат в хранилище ключей MobileFirst Server:

    keytool -import -alias backend -file backend.crt -storetype JKS -keystore mfp.keystore

  6. Убедитесь, что сертификат правильным образом импортирован в хранилище ключей:

    keytool -list -keystore mfp.keystore

  7. Разверните новое хранилище ключей MobileFirst Server.

Компоновка приложения для тестовой или рабочей среды

Компоновка приложения для тестовой или рабочей среды предусматривает его настройку для целевого сервера. В случае компоновки приложения для рабочей среды требуются дополнительные действия.

  1. Убедитесь, что на целевом сервере настроено хранилище ключей. Дополнительная информация приведена в разделе Настройка хранилища ключей MobileFirst Server.

  2. Если требуется распространить устанавливаемый артефакт приложения, увеличьте версию приложения.

  3. Перед тем как приступить к компоновке приложения, настройте его для целевого сервера.

    Укажите URL и имя среды выполнения целевого сервера в файле свойств клиента. Кроме того, целевой сервер можно изменить с помощью MobileFirst CLI. Для того чтобы настроить приложение для целевого сервера без регистрации приложения на активном сервере, выполните команды mfpdev app config server <server URL> и `mfpdev app config runtime

`. Кроме того, вы можете зарегистрировать приложение на активном сервере с помощью команды `mfpdev app register`. Используйте общедоступный URL сервера. Этот URL применяется мобильным приложением для подключения к MobileFirst Server. Например, для того чтобы настроить приложение для целевого сервера mfp.mycompany.com со средой выполнения mfp, выполните команды `mfpdev app config server https://mfp.mycompany.com` и `mfpdev app config runtime mfp`. 4. Настройте личные ключи и авторизованные серверы для приложения. * Если приложение реализует прикрепление сертификатов, используйте сертификат целевого сервера. Дополнительная информация приведена в разделе [Прикрепление сертификатов](../../authentication-and-security/certificate-pinning). * Если приложение iOS использует App Transport Security (ATS), настройте ATS для целевого сервера. * Для того чтобы настроить непосредственное обновление для приложения Apache Cordova, обратитесь к разделу [Реализация безопасного непосредственного обновления на стороне клиента](../../application-development/direct-update). * Если приложение разрабатывается с помощью Apache Cordova, настройте Cordova Content Security Policy (CSP). 5. Если планируется использовать непосредственное обновление для приложения, разрабатываемого с помощью Apache Cordova, создайте архив с версиями модулей Cordova, которые использовались для компоновки приложения. Непосредственное обновление нельзя использовать для обновления нативного кода. Если изменить нативную библиотеку или один из инструментов компоновки в проекте Cordova и передать такой файл в MobileFirst Server, то сервер обнаружит разницу и не будет отправлять обновления в клиентское приложение. Изменения нативной библиотеки могут включать другую версию Cordova, модуль Cordova iOS более поздней версии или даже пакет исправлений модуля mfpdev, отличный от того, который использовался для компоновки исходного приложения. 6. Настройте приложение для применения в рабочей среде. * Рекомендуется выключить ведение протокола устройстве. * Если планируется использовать MobileFirst Analytics, убедитесь, что приложение отправляет собранные данные в MobileFirst Server. * Рекомендуется выключить те функции приложения, которые вызывают API `setServerURL`, если вы не планируете создать одну компоновку для нескольких серверов тестирования. 7. Если компоновка выполняется для рабочего сервера и вы планируете распространять устанавливаемый артефакт, создайте архив исходного кода приложения, чтобы выполнять тесты без регрессии на сервере тестирования. Например, если впоследствии адаптер будет обновлен, то вы сможете выполнять тесты без регрессии на уже распределенных приложений, использующих этот адаптер. Дополнительная информация приведена в разделе [Развертывание или обновление адаптера в рабочей среде](#deploying-or-updating-an-adapter-to-a-production-environment). 8. Необязательно: создайте файл подтверждения подлинности приложения. Файл подтверждения подлинности приложения применяется после регистрации приложения на сервере, чтобы обеспечить возможность проверки подлинности приложения. * Дополнительная информация приведена в разделе [Включение проверки подлинности приложения](../../authentication-and-security/application-authenticity). * Дополнительная информация о регистрации приложения на рабочем сервере приведена в разделе [Регистрация приложения в рабочей среде](#registering-an-application-to-a-production-environment). ## Регистрация приложения в рабочей среде {: #registering-an-application-to-a-production-environment } Регистрация приложения на рабочем сервере предусматривает передачу дескриптора приложения, выбор типа лицензии и активацию проверки подлинности приложения (необязательно). #### Перед тем как начать {: #before-you-begin } * Убедитесь, что хранилище ключей MobileFirst Server настроено и не является хранилищем ключей по умолчанию. Сервер не рекомендуется использовать в рабочей среде с хранилищем ключей по умолчанию. Хранилище ключей MobileFirst Server содержит идентификационные данные экземпляров MobileFirst Server и используется для цифровой подписи ключей OAuth и пакетов непосредственного обновления. Перед использованием в рабочей среде настройте личный ключ для хранилища ключей сервера. Дополнительная информация приведена в разделе [Настройка хранилища ключей MobileFirst Server](../../authentication-and-security/configuring-the-mobilefirst-server-keystore/). * Разверните адаптеры, применяемые приложением. Дополнительная информация приведена в разделе [Развертывание или обновление адаптера в рабочей среде](#deploying-or-updating-an-adapter-to-a-production-environment). * Скомпонуйте приложение для целевого сервера. Дополнительная информация приведена в разделе [Компоновка приложения для тестовой или рабочей среды](#building-an-application-for-a-test-or-production-environment). Регистрация приложения на рабочем сервере предусматривает передачу дескриптора приложения, выбор типа лицензии и активацию проверки подлинности приложения (необязательно). Кроме того, может потребоваться создать стратегию обновления, если уже развернута предыдущая версия приложения. Ознакомьтесь со следующей процедурой, в которой описаны важные действия и способы их автоматизации с помощью программы **mfpadm**. 1. Если MobileFirst Server использует лицензии на основе маркеров, убедитесь, что на сервере License Key Server доступно достаточное число маркеров. Дополнительная информация приведена в разделах [Проверка лицензии на основе маркеров](../license-tracking/#token-license-validation) и [Планирование использования лицензий на основе маркеров](../../installation-configuration/production/token-licensing/#planning-for-the-use-of-token-licensing). > **Совет:** лицензию на основе маркеров можно указать перед регистрацией первой версии приложения. Дополнительная информация приведена в разделе [Настройка информации о лицензии приложения](../license-tracking/#setting-the-application-license-information). 2. Передайте дескриптор приложения из сервера тестирования на рабочий сервер. Эта операция регистрирует приложения на рабочем сервере и передает его конфигурацию. Дополнительная информация о передаче дескриптора приложения приведена в разделе [Передача серверных артефактов на тестовый или рабочей сервер](#transferring-server-side-artifacts-to-a-test-or-production-server). 3. Укажите информацию о лицензии приложения. Дополнительная информация приведена в разделе [Настройка информации о лицензии приложения](../license-tracking/#setting-the-application-license-information). 4. Настройте проверку подлинности приложения. Дополнительная информация о настройке проверки подлинности приложения приведена в разделе [Настройка проверки подлинности приложения](../../authentication-and-security/application-authenticity/#configuring-application-authenticity). > **Примечание:** для создания файла подтверждения подлинности приложения требуется двоичный файл приложения. Дополнительная информация приведена в разделе [Включение проверки подлинности приложения](../../authentication-and-security/application-authenticity/#enabling-application-authenticity). 5. Если приложение использует push-уведомления, передайте сертификаты push-уведомлений на сервер. Для передачи сертификатов push-уведомлений можно использовать MobileFirst Operations Console. Все версии приложения использует общие сертификаты. > **Примечание:** в отдельных случаях тестирование push-уведомлений с рабочими сертификатами можно можно выполнить только после публикации приложения в магазине. 6. Перед публикацией приложения в магазине проверьте следующие пункты. * Проверьте все функции управления мобильными приложениями, которые вы планируете использовать, включая выключение удаленных приложений или отображение сообщений администратора. Дополнительная информация приведена в разделе [Управление мобильными приложениями](../using-console/#mobile-application-management). * В случае обновления создайте стратегию обновления. Дополнительная информация приведена в разделе [Обновление приложений MobileFirst в рабочей среде](#updating-mobilefirst-apps-in-production). ## Передача серверных артефактов на тестовый или рабочей сервер {: #transferring-server-side-artifacts-to-a-test-or-production-server } Конфигурацию приложения можно передать с одного сервера на другой с помощью инструментов командной строки или API REST. Дескриптор приложения - это файл JSON, содержащий описание и конфигурацию приложения. Если приложение подключается к экземпляру MobileFirst Server, то его необходимо зарегистрировать и настроить на этом сервере. После настройки приложения дескриптор можно передать на другой сервер, например на сервер тестирования или рабочий сервер. После передачи дескриптора приложения на новый сервер приложение регистрируется на новом сервере. Доступны различные процедуры в зависимости от того, обладаете ли вы доступом к коду мобильных приложений. > **Важная информация:** если импортируемое приложение содержит данные подтверждения подлинности и приложение было перекомпилировано после создания этих данных, то необходимо обновить данные подтверждения подлинности. Дополнительная информация приведена в разделе [Настройка проверки подлинности приложения](../../authentication-and-security/application-authenticity/#configuring-application-authenticity). * Если вы обладаете доступом к коду мобильного приложения, выполните команды `mfpdev app pull` и `mfpdev app push`. * Если вы не обладаете доступом к коду мобильного приложения, используйте консоль администрирования. #### Перейти к {: #jump-to-1 } * [Передача конфигурации приложения с помощью mfpdev](#transferring-an-application-configuration-by-using-mfpdev) * [Передача конфигурации приложения с помощью службы администрирования](#transferring-an-application-configuration-with-the-administration-service) * [Передача серверных артефактов с помощью API REST](#transferring-server-side-artifacts-by-using-the-rest-api) * [Экспорт и импорт приложений и адаптеров с помощью консоли управления MobileFirst](#exporting-and-importing-applications-and-adapters-from-the-mobilefirst-operations-console) ### Передача конфигурации приложения с помощью mfpdev {: #transferring-an-application-configuration-by-using-mfpdev } После разработки приложение можно передать из среды разработки в среду тестирования или рабочую среду. * В локальной системе должно быть установлено приложение MobileFirst. Приложение должно быть зарегистрировано на сервере MobileFirst Server. Для просмотра дополнительной информации о создании профайла сервера выполните команду **mfpdev app register** или обратитесь к инструкциям по регистрации приложения соответствующего типа в разделе Разработка приложений. * Локальная система должна иметь связь с сервером, на котором зарегистрировано приложение, а также с сервером, на который требуется передать приложение. * В локальной системе должен быть доступен профайл исходного сервера MobileFirst Server, а также профайл сервера, на который требуется передать приложение. Для просмотра дополнительной информации о создании профайла сервера выполните команду **mfpdev server add**. * Должен быть установлен MobileFirst CLI. Отправьте копию серверных файлов конфигурации для приложения в локальную систему с помощью команды **mfpdev app pull**. Затем с помощью команды **mfpdev app push** отправьте ее на другой сервер MobileFirst Server. Команда **mfpdev app push** также регистрирует приложение на указанном сервере. Кроме того, с помощью этих команд можно передать конфигурацию среды выполнения с одного сервера на другой. Данные конфигурации включают описание приложения, которая содержит уникальный идентификатор приложения, и другую информацию о приложении. Файлы конфигурации предоставляются в виде сжатых файлов (формат .zip). Файлы .zip размещаются в каталоге **appName/mobilefirst** и имеют следующий формат имени: ```bash appID-platform-version-artifacts.zip ``` где **appID** - это имя приложения, **platform** - **android**, **ios** или **windows**, а version - уровень версии приложения. В случае приложений Cordova для каждой целевой платформы создается отдельный файл .zip. Команда **mfpdev app push** изменяет файл свойств клиента приложения с учетом имени профайла и URL нового MobileFirst Server. 1. В системе разработки перейдите в корневой каталог приложения или один из его подкаталогов. 2. Выполните команду **mfpdev app pull**. Если команда указана без параметров, то приложение извлекается из MobileFirst Server по умолчанию. Кроме того, можно указать конкретный сервер и пароль администратора. Пример для приложения Android с именем **myapp1**: ```bash cd myapp1 mfpdev app pull Server10 -password secretPassword! ``` Команда выполняет поиск файлов конфигурации текущего приложения на сервере MobileFirst Server с профайлом Server10. Затем он отправляет сжатый файл **myapp1-android-1.0.0-artifacts.zip**, содержащий файлы конфигурации, в локальную систему и размещает его в каталоге **myapp1/mobilefirst**. 3. Выполните команду **mfpdev app push**. Если команда указана без параметров, то приложение передается на MobileFirst Server по умолчанию. Кроме того, можно указать конкретный сервер и пароль администратора. Пример для приложения из предыдущего шага: `mfpdev app push Server12 -password secretPass234!`. Эта команда отправляет файл **myapp1-android-1.0.0-artifacts.zip** на MobileFirst Server с профайлом Server12 и паролем администратора **secretPass234!** В файле свойств клиента **myapp1/app/src/main/assets/mfpclient.properties** указываются сервер Server12 и URL сервера. Файлы конфигурации приложения доступны на сервере MobileFirst Server, указанном в команде mfpdev app push. Приложение зарегистрировано на новом сервере. ### Передача конфигурации приложения с помощью службы администрирования {: #transferring-an-application-configuration-with-the-administration-service } Администратор может передать Конфигурацию приложения с одного сервера на другой с помощью службы администрирования MobileFirst Server. Доступ к коду приложения не требуется, однако клиентское приложение должно быть скомпоновано для целевого сервера. #### Перед тем как начать {: #before-you-begin-1 } Скомпонуйте клиентское приложение для целевого сервера. Дополнительная информация приведена в разделе [Компоновка приложения для тестовой или рабочей среды](#building-an-application-for-a-test-or-production-environment). Дескриптор приложения загружается с сервера, на котором приложение настроено, и развертывается на новом сервере. Дескриптор приложения можно просмотреть в MobileFirst Operations Console. 1. Необязательно: проверьте дескриптор приложения на сервере, на котором настроено приложение. Откройте MobileFirst Operations Console для этого сервера, выберите версию приложения и перейдите на вкладку **Файлы конфигурации**. 2. Загрузите дескриптор приложения с сервера, на котором настроено приложение. Для этой цели можно использовать API REST или **mfpadm**. > **Примечание:** приложение или версию приложения также можно экспортировать из MobileFirst Operations Console. См. раздел [Экспорт и импорт приложений и адаптеров из MobileFirst Operations Console](#exporting-and-importing-applications-and-adapters-from-the-mobilefirst-operations-console). * Для загрузки дескриптора приложения с помощью API REST примеряется API REST [Дескриптор приложения (GET)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_application_descriptor_get.html?view=kc#Application-Descriptor--GET-). Следующий URL возвращает дескриптор приложения с ИД **my.test.application** для платформы **ios** и версии **0.0.1**. Вызывается сервер MobileFirst Server: `http://localhost:9080/mfpadmin/management-apis/2.0/runtimes/mfp/applications/my.test.application/ios/0.0.1/descriptor` Например, URL можно указать в инструменте, таком как curl: `curl -user admin:admin http://[...]/ios/0.0.1/descriptor > desc.json`.
Измените следующие элементы 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.
Last modified on August 17, 2020