brwilkinson
commented
1 year ago Hi @jamil-z
The sample uses Desired State Configuration (DSC) for all setup on the Virtual Machine ScaleSets (VMSS).
The DSC configuration is deployed via the DSC extension in the Bicep Template.
The raw configuration is here and there is a specific custom DSC resource that copies the App Files.
That custom DSC Resource is here for deploying the App Files from the Build pipeline and it allows for continuous integration for new builds.
https://github.com/brwilkinson/AppReleaseDSC
All code is in this single file.
https://github.com/brwilkinson/AppReleaseDSC/blob/main/AppReleaseDSC.psm1
DSC is going to always run the first time... then there is a configuration setting to say if it should run later on to autocorrect.
That specific setting is here:
# given this is for a lab and load test, just always pull down the latest App config
DSCConfigurationMode = 'ApplyAndAutoCorrect'Which actually gets used here in the DSC on the ConfigurationMode.
LocalConfigurationManager
{
ActionAfterReboot = 'ContinueConfiguration'
ConfigurationMode = iif $node.DSCConfigurationMode $node.DSCConfigurationMode 'ApplyAndMonitor'
RebootNodeIfNeeded = $True
AllowModuleOverWrite = $true
}You can comment out that setting in the ConfigurationData, then deploy again and it will be set to ApplyAndMonitor instead of ApplyAndAutoCorrect or change the setting yourself to whatever you prefer.
It was set to autocorrect, since if you rerun the build pipeline, it automatically pulls down the latest build basically CI/CD.
So it's hard to say what your exact issue is or what you are experiencing, however the custom DSC resource above uses AZCopy to do all files copies for the App Files and we log everything to the AzCopy Logs on the Filesystem.
One thing, since you are stopping the service, when DSC runs which is default every 15 minutes, it's going to see that the machine is not in the desired state and it's going to run ALL of the DSC configuration again. So definitely if you plan to stop the service flip to ApplyAndMonitor because it's just going to restart the service anyway.
However you won't get new builds pulled down... But also know without that change, as I just mentioned above, DSC is going to restart the service every 15 minutes anyway, because it's in the DSC configuration.
So let me know how you go... the answer could be in the AZCopy logs, however I think it's best to tweak DSC for your use case.
It could be something unrelated to this, however this appears like the most likely scenario.
jamil-z
Describe the issue We are already running EchoBot, and the service is running on VM instances. When the project is built, there are 175 files that are added for the service execution. However, after some time or when the instance is restarted, the number of files decreases to 82. We want to resolve this issue where more than half of the files are being deleted.
Expected behavior We want the service to continue running and no files to be deleted even after a certain period of time or when the instances are restarted.
Additional context We suspect that in the scripts, there might be an error where, upon detecting that the service is not running, it attempts to rebuild or copy the files but fails to complete this action successfully. When the files already exist, it should not attempt to copy anything but simply execute the service.