Restructure Service Platform hosting docs to make it clearer for containers - #8449
Restructure Service Platform hosting docs to make it clearer for containers#8449WilliamBZA wants to merge 4 commits into
Conversation
WilliamBZA
changed the title
| 2. **ServiceControl Error instance**, the only required piece. See [Deploying ServiceControl Error instances using Containers](/servicecontrol/servicecontrol-instances/deployment/containers.md). | ||
| 3. **ServiceControl Audit instance** (optional), if audit message history is needed. See [Deploying ServiceControl Audit instances using containers](/servicecontrol/audit-instances/deployment/containers.md). | ||
| 4. **ServiceControl Monitoring instance** (optional), if endpoint performance monitoring is needed. See [Deploying ServiceControl Monitoring instances using containers](/servicecontrol/monitoring-instances/deployment/containers.md). | ||
| 5. **ServicePulse**, the web UI that connects to the instances above. See [Running ServicePulse in containers](/servicepulse/containerization). |
There was a problem hiding this comment.
Can SP be hosted via SC when using containers? (Perhaps that would simplify this further)
There was a problem hiding this comment.
Definitely, we should be simplifying the deployment so less is more 😉
Co-authored-by: Mauro Servienti <mauro.servienti@gmail.com>
johnsimons
left a comment
johnsimons
left a comment
There was a problem hiding this comment.
If the aim of this PR is to simplify deployment, I personally believe that we should update the whole docs to use SP embeeded, this thinking is that the less things the user needs to setup the better.
However, when using the embedded SP, we need to consider that hosting it in port 33333 is not very "standard", so we may need to adjust docs to explain this hurdle.
The whole RavenDB does not work in cloud providers and customers need to run the Raven Cloud, that to me is another friction point that is difficult to grasp, so I don't know @WilliamBZA whether the case you are deailing with touched on that.
| ## Working with the platform | ||
|
|
||
| ServiceControl and ServicePulse are server applications. They should be deployed in each environment, for example: test, QA, and production. | ||
| ServiceControl and ServicePulse are server applications. They should be deployed in each environment, for example: test, QA, and production. See [Running the Particular Service Platform in containers](/platform/containers.md) for an overview of deploying them as containers. |
There was a problem hiding this comment.
This feels a bit out of place here. Why are we mentioning containers but not all other deployment methods?
| Deploy the pieces in this order: | ||
|
|
||
| 1. **RavenDB**, one container per Error or Audit instance. See [Managing ServiceControl RavenDB instances via Containers](/servicecontrol/ravendb/containers.md). | ||
| 2. **ServiceControl Error instance**, the only required piece. See [Deploying ServiceControl Error instances using Containers](/servicecontrol/servicecontrol-instances/deployment/containers.md). | ||
| 3. **ServiceControl Audit instance** (optional), if audit message history is needed. See [Deploying ServiceControl Audit instances using containers](/servicecontrol/audit-instances/deployment/containers.md). | ||
| 4. **ServiceControl Monitoring instance** (optional), if endpoint performance monitoring is needed. See [Deploying ServiceControl Monitoring instances using containers](/servicecontrol/monitoring-instances/deployment/containers.md). | ||
| 5. **ServicePulse**, the web UI that connects to the instances above. See [Running ServicePulse in containers](/servicepulse/containerization). |
There was a problem hiding this comment.
Given that this page is part of the "learning path", I don't think we can just say "optional"!
This is the area where I would also explain why they need these extra features deployed. And then add a link to another page to learn more about them, and on that page we would say it is optional.
| 2. **ServiceControl Error instance**, the only required piece. See [Deploying ServiceControl Error instances using Containers](/servicecontrol/servicecontrol-instances/deployment/containers.md). | ||
| 3. **ServiceControl Audit instance** (optional), if audit message history is needed. See [Deploying ServiceControl Audit instances using containers](/servicecontrol/audit-instances/deployment/containers.md). | ||
| 4. **ServiceControl Monitoring instance** (optional), if endpoint performance monitoring is needed. See [Deploying ServiceControl Monitoring instances using containers](/servicecontrol/monitoring-instances/deployment/containers.md). | ||
| 5. **ServicePulse**, the web UI that connects to the instances above. See [Running ServicePulse in containers](/servicepulse/containerization). |
There was a problem hiding this comment.
Definitely, we should be simplifying the deployment so less is more 😉
There was a problem hiding this comment.
I personally find these modes quite complex, and I am not sure they really work in practice.
For example, when we build the Helm charts, we just went with --setup-and-run because otherwise things get super confusing.
I would suggest --setup-and-run is really the mode they want to use for container deployments.
Everything else is kind of an "advanced" setup mode.
| ## Overview | ||
|
|
||
| When MassTransit is used with the rest of the platform, there are in total 4 containers that need to be deployed: | ||
| See [Running the Particular Service Platform in containers](/platform/containers.md) for an overview of deploying the platform as containers. When MassTransit is used with the rest of the platform, there are in total 4 containers that need to be deployed: |
There was a problem hiding this comment.
This can be further reduced to 3, if we make the embedded ServicePulse the default in docs (it is already the default in SCMU).
| --- | ||
|
|
||
| ServiceControl 5.3.0 adds the ability to host ServiceControl instances in Linux containers. This article describes how to migrate from ServiceControl hosted on Windows hosting to new ServiceControl instances hosted in containerized infrastructure. | ||
| ServiceControl 5.3.0 adds the ability to host ServiceControl instances in Linux containers. This article describes how to migrate from ServiceControl hosted on Windows hosting to new ServiceControl instances hosted in containerized infrastructure. See [Running the Particular Service Platform in containers](/platform/containers.md) for an overview of the resulting container topology. |
There was a problem hiding this comment.
This prompt feels a bit too early; don't we want them to read the migration first? Consider moving the prompt later on the page.
| - [Audit instances](/servicecontrol/audit-instances/) provide valuable information about the message flow through a system. These instances are used by ServicePulse to help visualize a distributed system. | ||
| - [Monitoring instances](/servicecontrol/monitoring-instances/) provide performance monitoring and metrics analytics that are useful for keeping track of the health of a distributed system. | ||
|
|
||
| See [Running the Particular Service Platform in containers](/platform/containers.md) for an overview of deploying these instances as containers. |
There was a problem hiding this comment.
Again, this feels out of place. They are on the learning path. Do we want them to go somewhere else?
| monitoring --> pulse | ||
| ``` | ||
|
|
||
| Only the Error and Audit instances need a RavenDB container; Monitoring instances don't store any data. Audit and Monitoring instances are optional, but recommended: an Error instance is required to run ServiceControl at all. |
There was a problem hiding this comment.
| Only the Error and Audit instances need a RavenDB container; Monitoring instances don't store any data. Audit and Monitoring instances are optional, but recommended: an Error instance is required to run ServiceControl at all. | |
| Only the Error and Audit instances need a RavenDB container; Monitoring instances don't store any data. | |
| Audit and Monitoring instances are optional but recommended. |
5 participants
No description provided.