microsoft / VSTSAgent.PowerShell

Tools for managing and automating your Azure DevOps Agents.
MIT License
29 stars 23 forks source link

Nodes became noncompliant in Azure Automation after update #27

Closed tbalasavage closed 3 years ago

tbalasavage commented 3 years ago

I've recently been looking for ways to automate the configuration of Windows VMs, part of which includes adding build agents, and so glad to have been directed to this project. This may not be the place to raise this issue so please let me know if that is the case.

I've installed the build agent successfully via DSC in Azure Automation. It appears that it was compliant until I updated the agent in DevOps. Once I did that, it became noncompliant in the dashboard and isn't going to return to a compliant state. Does the project have a recommendation for keeping the nodes in a compliant state? Should updating the agents be avoided and the nodes kept up-to-date via some other means? Thanks for any help.

jwittner commented 3 years ago

Not sure I have the full picture, but I believe if you update your automation DSC script to indicate the version that you now have, it should eventually reach consistency.

tbalasavage commented 3 years ago

Context: My DSC script doesn't specify a version. I installed the agent and it was version 2.10 (making up the number here). In DevOps I updated the agents and it went to 2.17 (again, made up). This seems to have caused the nodes to become noncompliant.

Is this a correct strategy/summary/plan: Don't rely on the latest version in the DSC script but instead specify a version and update the version in the DSC script when you want to upgrade and NOT in Azure Devops? Or specify a minimum version.

tbalasavage commented 3 years ago

Looking into this though, these are the options:

PARAMETER Name
    What's the name of the agent we're concerned with?
.PARAMETER Pool
    What's the pool of the agent we're concerned with? Note, only used on install.
.PARAMETER AgentDirectory
    What directory is used for agents?
.PARAMETER Account
    What VSTS account should we be concerned with?
.PARAMETER AccountCredential
    The credential used to auth with VSTS.
.PARAMETER LogonCredential
    What credential should the agent service use?
.PARAMETER Ensure
    Should we ensure the agent exists or that it doesn't?

It doesn't appear that I can set version. Is that incorrect?

jwittner commented 3 years ago

Whoops, you're right. I was thinking of a similar DSC resource for a different tool. You should be able to update via ADO and retain consistency. Perhaps the update removed the agent from the specified AgentDirectory when it updated? Do you have access to the VM to try running the Test-TargetResource cmdlet directly?

It also logs verbose so if you can capture the logs when DSC does a consistency check you may get some more information about why it believes its not consistent.

jwittner commented 3 years ago

I'm using Azure Automation with this DSC resource and have build agents that have been updated and the consistency is maintained. I'm updating one right now as well to verify that behavior is still functioning for me.

jwittner commented 3 years ago

I've confirmed that the agents were updated (2.1650->2.175.2) and my DSC nodes have tested/reported consistency since the update. We'll need to dig into the details of your setup I think to diagnose what might be going wrong.

tbalasavage commented 3 years ago

If you don't mind providing input, this is my config:

configuration BuildAgentConfig
{   
        $Pat = Get-AutomationPSCredential 'personalAccessToken'
    $Creds = Get-AutomationPSCredential 'userCreds'

    Import-Module Orchestrator.AssetManagement.Cmdlets -ErrorAction SilentlyContinue
    Import-DscResource -ModuleName 'VSTSAgent'

    Node $AllNodes.NodeName
    {
        xVSTSAgent VSTSAgent {
            Name              = 'Agent01'
            ServerUrl         = 'https://dev.azure.com/myorg'
            AccountCredential = $Pat
            LogonCredential   = $Creds
            AgentDirectory    = 'C:\VSTSAgents'
            Work              = 'D:\VSTSAgentsWork\Agent01'
            Pool              = 'Development'
            Ensure            = 'Present'
        }
    }
}
tbalasavage commented 3 years ago

I also had the ConfigurationMode set as ApplyAndMonitor. I've since unregistered the node and changed the configuration to ApplyAndAutoCorrect. I'm new to DSC and Azure Automation so this may have been my stupid mistake and I've wasted your time. I come from a world of Ansible so I understand the core ideas but don't quite understand all the vocabulary and implications of decisions yet.

jwittner commented 3 years ago

Hmmm, the config there seems reasonable. I also use ApplyAndAutoCorrect so that's a good move. Did that resolve the issue? If not I think we'll want to remote into the box and run the test or get the logs so we can see why it believes it's not consistent.

tbalasavage commented 3 years ago

It seems to have yes. The state is compliant now and continues to be.

It does seem that ApplyAndAutoCorrect is reverting the the agent version, which is interesting. Using real numbers, the agent is 2.177.0 when installed by DSC. If I update the agent, and maybe I'm missing something, it "updates" to 2.175.2. Shortly thereafter it's 2.177.0, which I think is being applied by DSC. This indicates that the update was causing the noncompliant state.

jwittner commented 3 years ago

Interesting. I don't have the version revision happening for me. The update went to 2.175.2 and has stayed there. Seems like you have things working, but if you get a chance, learning why it thinks its inconsistent after the update would be great so we can allow updates for everyone. =)

tbalasavage commented 3 years ago

Yep. I'll share what I learn as I go. I'll close this issue for now and then contribute what I can. @jwittner Thanks for all your input.