Platform application layer deployment 2016 JAN 2 1

Deployment on clean environment

Before next step make sure that you have set up the platform according to Platform Deployment on AWS or Platform Deployment on OpenStack.

If you do not have access to a remote artifacts repository and cannot download artifacts package, please contact one of the TAP developers listed below who will provide it (recommended solution). The package is a zip and needs to be unpacked. It contains two directories: apps (containing application artifacts) and tools (containing the scripts and configuration needed for deployment).

Marko Łaboszczak <[email protected]>
Michał Bultrowicz <[email protected]>
Andrzej Dajnowski <[email protected]>
Grzegorz Świrski <[email protected]>
Andrzej Joskowski <[email protected]>

If you prefer to build TAP from sources instead, please refer to instructions in [this document] (https://github.com/trustedanalytics/platform-wiki/wiki/Building-TAP-from-sources).

Next step is filling the data in Cloud Foundry platform definition files, which provide necessary data for deployment process.

• Unpack cloudfoundry-mkappstack and platform-appstack from tools/ directory (the one in the package zip). For .zip format run: unzip <source_package_name>.zip. For .tar.gz format run: tar -xvzf <source_package_name>.
• Follow instructions in platform-appstack Readme. Make sure that you copied necessary files from your platform-appstack directory to cloudfoundry-mkappstack directory.
• Copy tools/versions.yml to unpacked cloudfoundry-mkappstack source code directory.
• Follow instructions in cloudfoundry-mkappstack ("Platform Deployment" section of the Readme).
• If you need to access cf through proxy server, uncomment and set proxy and noproxy values in cloudfoundry-mkappstack/appstack.mk

Now you are ready to deploy whole platform:

export GODEBUG=netdns=cgo
cf api --unset
make deploy

Upgrade

Works the almost the same as deploying on a clean environment, but some precautions are necessary.

Backup

TAP applications that have been running in the environment for some time may hold important data and should be backed up before an upgrade.

You need to backup:

• Data Catalog entries according to this
• User Management and Data Acquisition (DAS) Redis stores
  • Get on Docker machine.
  • Run shell in the Redis container (separate one for DAS and User Management).
  • Run BGSAVE with redis cli.
  • Wait until dump.rdb is generated.
  • Copy (docker cp) dump.rdb out of the container with a descriptive name, e.g. 2016-02-32_user_management_dump.rdb

New clientId user

Old environments can use "developer_console" OAuth client ID. A new user, "tap_console", with the same settings need to be created in UAA.

Broker upgrade risk

No service instances are recreated. Even when you update a broker, the existing instances won't be touched. If an app is updated (switched to a version with newer code) then it gets the same service instances the old app had.

Let's say a new version of the application needs features found in instance created from a newer broker (that will also be deployed during the upgrade). The app will still have the service instance created by the older broker and errors may ensue.