Upgrading your SDL Tridion 2013 SP1 HR1 Content Deployer to a combined Content Deployer
To upgrade your Content Deployer to a combined Content Deployer, replace it with a standalone combined Content Deployer microservice. If you currently have a Content Deployer (HTTP or HTTPS) Role running as a Java/JSP Web application, you can also turn it into a Java/JSP Web application-based combined Content Deployer microservice, but such an upgrade is actively discouraged.
- Copying resources for the combined Content Deployer in an upgrade scenario
Copy microservice resources to your target machine. - Restoring backed-up resources from your existing Content Deployer (HTTP or HTTPS) or HTTP Upload role to the combined Content Deployer
Reapply your customizations by restoring your backup. - Configuring a non-HTTP(S) transport protocol
As of SDL Web 8, any transport protocol other than HTTP or HTTPS is deprecated. Using a mix of legacy transport and HTTP(S) transport is discouraged. If you use a deprecated transport protocol, you can only publish to local file system or to binary storage, and you cannot use a Redis database for temporary storage. If, despite these drawbacks, you still wish to continue using a deprecated transport protocol, edit the Content Deployer configuration file, cd_deployer_conf.xml . - Setting a log location for your microservice
By default, Content Delivery microservices write their log files to a folder called c:/SDLWeb/log/. Set a proper location in the Logback configuration file for your microservice, logback.xml. - Installing the combined Content Deployer as a standalone microservice
Run the appropriate microservice installation PowerShell or Unix script to install and run the standalone microservice. - Installing the combined Content Deployer microservice as a Java/JSP Web application (discouraged)
To install the combined Content Deployer as a deprecated Java/JSP Web application-based microservice rather than as a standalone microservice, deploy the Web application using your Java/JSP Web application server. - Configuring the State Store database as part of an upgrade
The Content Deployer upgrade adds a section for the new State Store database to your Content Deployer configuration file, deployer-conf.xml. By default, the State Store is configured to reuse your Content Delivery Broker database. To give the State Store its own database (a recommended setup), reconfigure it in your deployer-conf.xml file(s). - Securing the microservice with SSL
You may wish to secure your microservice using Secure Socket Layer (SSL), so that an HTTPS connection is required to interact with the service. If you do, you require a certificate signed and issued by a Certificate Authority (CA), a private key, and a keystore containing both of these. You then configure the keystore in the application.properties file of your microservice. You can reuse the same certificate, key and keystore for multiple microservices, so long as they are all running on the same machine. This section assumes that you have no certificate, key or keystore yet. If you do, you can skip the topics that do not apply. - Connecting to an HTTPS-secured Discovery Service
If you secured your Discovery Service with HTTPS, you imported your certificate into a keystore which you passed to the Discovery Service. To connect to the Discovery Service, import the same certificate into your local Java keystore. - Registering the Content Deployer microservice as a Capability
If you already used theauto-registerswitch to register this Server Role as a Capability when you installed it as a standalone microservice, you can skip this task. If you did not, you can make this microservice discoverable through the Discovery Endpoint by hand by adding it as a Capability to the Discovery Service's Storage Layer configuration file and update the Capability registry by rerunning the Discovery Service registration tool.