Particular
Feedback: 'Manage ServiceControl instances via PowerShell'
Feedback for 'Manage ServiceControl instances via PowerShell' https://docs.particular.net/servicecontrol/installation-powershell
Location in GitHub: https://github.com/Particular/docs.particular.net/blob/master/servicecontrol/installation-powershell.md
Just when I thought I understood it all...
This page raises more questions for me:
Version 4
Create a ServiceControl instance:$serviceControlInstance = New-ServiceControlInstance ` -Name Test.ServiceControl ` -InstallPath C:\ServiceControl\Bin ` -DBPath C:\ServiceControl\DB ` -LogPath C:\ServiceControl\Logs ` -Port 33334 ` -DatabaseMaintenancePort 33335 ` -Transport MSMQ ` -ErrorQueue error1 ` -ErrorRetentionPeriod 10:00:00:00Optionally create a ServiceControl Audit instance to manage an audit queue:
$auditInstance = New-ServiceControlAuditInstance ` -Name Test.ServiceControl.Audit ` -InstallPath C:\ServiceControl.Audit\Bin ` -DBPath C:\ServiceControl.Audit\DB ` -LogPath C:\ServiceControl.Audit\Logs ` -Port 44444 ` -DatabaseMaintenancePort 44445 ` -Transport MSMQ ` -AuditQueue audit1 ` -AuditRetentionPeriod 10:00:00:00 ` -ForwardAuditMessages:$false ` -ServiceControlQueueAddress Test.ServiceControl Add-ServiceControlRemote ` -Name $serviceControlInstance.Name ` -RemoteInstanceAddress $auditInstance.Url
But, I thought for version 4, when auditing your NServiceBus messages, an Audit instance is required? The documentation on upgrading your ServiceControl infrastructure from v3 to v4 seems to indicate that this separate Audit instance will be automatically created during the upgrade. Assuming that is true, then this leads me to have two more questions:
- Does the automatically created audit instance get added as a ServiceControl remote? I ask this, because I'm going to manually creating the Audit instance in order to have more fine-grained control over the upgrade process, and currently, I am not adding the Audit instance as a remote.
- If the Audit instance resides on the same machine as the primary instance, does it still need to be "registered" as a remote?
(During an upgrade, I plan on disabling audit queue processing on the primary so that during upgrade, the audit instance won't be automatically created so I can have that fine-grained control I was talking about.)
I answered my own question. Again, I encourage you guys to reorganize this documentation to make it a bit more coherent to readers.
On this page, in a Note, the documentation states:
[NOTE!]
The term remote refers to the fact that remote instances are run in separate processes. The primary instance and one or more remote instances can run on the same machine.
So I'm guessing that means that I need to ensure I run Add-ServiceControlRemote for my audit instance. I'm also assuming that the "automated" update process does this for you, but if you're not using this process, you must ensure you do it yourself. That might be helpful to include in the documentation.
But, I thought for version 4, when auditing your NServiceBus messages, an Audit instance is required?
If auditing messages, then yes an audit instance is required. But if the system is not auditing messages, then an audit instance does not need to be created. This is why the word "Optionally" is used. In ServiceControl V4 you can have create the instances separately both from Powershell and from the Management Utility.
To your questions:
- Does the automatically created audit instance get added as a ServiceControl remote? I ask this, because I'm going to manually creating the Audit instance in order to have more fine-grained control over the upgrade process, and currently, I am not adding the Audit instance as a remote.
If using the powershell script to create the audit instance, then no it does not automatically get added as a remote. This is the reason behind the Add-ServiceControlRemote cmdlet. Once the audit instance is created, the primary instance needs to add it's address into it's config. The Add-ServiceControlRemote cmdlet edits the primary instance's config file and adds the audit instance address as a remote.
- If the Audit instance resides on the same machine as the primary instance, does it still need to be "registered" as a remote?
Yes, it still needs to be registered. This is because you can have multiple audit and primary instances on the same machine so doing auto-discovery could lead to invalid configurations.
Again, I encourage you guys to reorganize this documentation to make it a bit more coherent to readers.
💯
We can definitely make big improvements to the readibility of our documentation - especially for the other platform components (e.g. ServiceControl)
Thanks for confirming @WilliamBZA. I did run that cmdlet and have a (mostly) successful deployment of ServiceControl 4. 😉