Upgrade paths for the SDL Web 8 Content Deployer Role
A reorganization of the Content Deployer feature means that you need to make some decisions about how to upgrade your existing Content Deployer setup.
| Role name | Role folder | Description | Runs as standalone microservice? | Runs as Java/JSP Web application-based microservice? |
|---|---|---|---|---|
| Content Deployer endpoint | roles\deployer\deployer | The endpoint that receives published incoming content | yes | yes |
| Content Deployer worker | roles\deployer\deployer-worker | The processing engine that handles incoming content and stores it | yes | no |
| Content Deployer combined | roles\deployer\deployer-combined | The previous two Roles combined in one. | yes | yes |
- A Content Deployer endpoint and a Content Deployer worker, each running in a standalone microservice
-
If you currently run your Content Deployer as a standalone microservice, this scenario separates the endpoint and processing parts of your Content Deployer, and the setup is fully scalable. Alternatively, if you currently run your Content Deployer as a deprecated Java/JSP Web application-based microservice, this is the recommended way of migrating to a non-deprecated, scalable and separable setup.
- A single-role Content Deployer running in a standalone microservice
-
If you currently run your Content Deployer as a standalone microservice, this is the least-effort upgrade of your Content Deployer. But also if you currently run your Content Deployer as a deprecated Java/JSP Web application-based microservice, migrating to a standalone version is strongly recommended. The drawback of using a combined Content Deployer is that you cannot scale out, or separate the parts of, your Content Deployer.
- A single-role Content Deployer running in a deprecated Java/JSP Web application-based microservice
-
If you currently run your Content Deployer as a deprecated Java/JSP Web application-based microservice, this is the least-effort upgrade of your Content Deployer, and it is strongly discouraged. The drawbacks are that this upgrade is not provided with the product deliverable; that your Role runs as a deprecated Web application; and that you cannot scale out, or separate the parts of, your Content Deployer.
- A Content Deployer endpoint running in a deprecated Java/JSP Web application-based microservice, and a Content Deployer worker running in a standalone microservice
-
If you currently run your Content Deployer as a deprecated Java/JSP Web application-based microservice, this scenario is closer to a migration than to an upgrade. You enable the processing part of your Content Deployer (the worker) to be installed on a different machine, but your endpoint still runs in a Web application, which is a deprecated setup, and is strongly discouraged. The drawbacks are that this upgrade is not provided with the product deliverable, and that part of your Role still runs as a deprecated Web application.