Azure-pipelines-agent: Multiple agents on same machine - error due to same Windows service name

[NickMRamirez]

The Registration script for the VSTS agent that is shown on when adding a new machine to a Deployment Group doesn't account for adding multiple agents to the same machine. It contains the following line:

.\config.cmd --deploymentgroup --agent $env:COMPUTERNAME --runasservice ...

Where $env:COMPUTERNAME is used to name the VSTS Windows service. However, adding additional agents results in an error because they all try to register a Windows service with the same name.

A fix is:

.\config.cmd --deploymentgroup --agent $env:COMPUTERNAME-$destFolder --runasservice ...

Where the folder name for the agent, such as "A1", "A2", "A3" is appended to the computer name when naming the service. That way, you can have multiple services.

[TingluoHuang]

@NickMRamirez I think you might want to take the generate script as an sample for configure agent and you can modify it yourself. I don't think take folder name is a good idea, since you might have all different weird characters in your folder name, ex: space, localized char, etc. I am pretty sure server has restriction on agent name.

[TingluoHuang]

@chshrikh for thoughts

[NickMRamirez]

In this case, $destFolder is controlled by the script, so there's little chance that it will contain weird characters. It will always be "A1", "A2", etc. Here's the script as it is now (with one additional line to make $destFolder available to other parts of the script). But, as it stands now, the script errs if you try to use it more than once (for different VSTS projects) because the $env:COMPUTERNAME would be used in multiple Windows services, which isn't allowed:

$env:SystemDrive\'vstsagent';

$destFolder = "" # added by me so it's available outside the for block

for($i=1; $i -lt 100; $i++){
    $destFolder="A"+$i.ToString()

    if(-NOT (Test-Path ($destFolder))){
        mkdir $destFolder
        cd $destFolder
        break
    }
}

In any case, since the code is already in the script to create "A1", "A2" etc. folders, I suspect that the intention was to be able to host multiple agents on the same machine and that this is a bug: naming all of the created Windows services the same, even though their folders are named differently.

[chrispat]

@NickMRamirez multiple agents are not supported on a single machine when using deployment groups. Each machine should only be a member of a single deployment group.

[Cristie]

@NickMRamirez Learn more, https://www.visualstudio.com/en-us/docs/build/concepts/definitions/release/deployment-groups/#deploy-agents-to-a-deployment-group

[NickMRamirez]

@chrisrpatterson In my case, I am installing multiple agents per machine, but each of these agents is in a different team project. So if you were to look at just one of the projects, its Deployment Group would only show one agent and the machine would only be in one Group.

It's the downside to that you can't share agents between team projects. If we could do that, we wouldn't need to install the agent multiple times. As it stands, to deploy Team A and Team B projects, each team must register a different agent.

But in any case, my solution would allow it to support multiple agents. I've been using my custom script successfully. If I could find where that script is kept in github, I'd open a pull request.

[mmathias01]

Confirmed that not being able to have a single agent be part of multiple projects / teams is a huge issue. Also having to install the same agent to be both a build and deployment target is less than ideal. IMO the best way to do this would be to have agent's register themselves to the VSTS instance and be usable in either context and across teams / projects within that instance.

[Cristie]

Have we reached a decision on whether or not Deployment Groups will be in TFS 2017 Update?

[chrispat]

@Cristie they will not be in 2017

[chrispat]

@mmathias01 a build agent can be used by many team projects as pools are shared across them and that same agent can be used to execute remote deployments. The deployment group feature is about using an agent based deployment model to machines. I don't think you would want to run a build on a machine that is serving your website to your customers.

[chrispat]

@NickMRamirez sharing deployment groups across team projects is coming in a future update.

[mmathias01]

@chrisrpatterson No I would not. However production machines are not the only thing I use deployment groups for. I also use deployment groups on my dev / stage servers. I also use these servers for performing builds. For these machines being able to use them as a build machine, as well as assign them to a deployment group would be idea.

The way I would see it working in a perfect world (for me) is that I would register an agent to the VSTS instance and could then assign this agent to any number of tags, groups, deployment groups etc as I see fit. Is there a reason why it doesn't work this way?

[cilerler]

sharing deployment groups across team projects is coming in a future update"

@chrisrpatterson any info about when it will be deployed?

I need to deploy 2 sites on 1 machine and hit the same wall 😞 If it will be deployed soon, I won't try to figure out a workaround. 😛

Thanks in advance...

[RoopeshNair]

@cilerler - Sharing of deployment group targets is work in progress. Tentatively it will be available early next year (2018).

I need to deploy 2 sites on 1 machine and hit the same wall 😞 If it will be deployed soon, I won't try to figure out a workaround.

As a workaround, you can install additional agents on the machine by providing unique agent names in your registration script.

[Tarig0]

By sharing of deployment group targets, do you mean being able to have

• 1 Agent -> multiple projects with only 1 group in each
• 1 Agent -> 1 project multiple groups
• 1 Agent -> multiple projects and multiple groups

[RoopeshNair]

@Tarig0, It is the first one: 1 agent --> multiple projects with 1 group in each

[RoopeshNair]

Sharing of deployment group targets is now live on VSTS. Do let us know your feedback.
More info here

[search8]

How about TFS 2018 Upgrade 1? We just upgraded to the current version. I'm able to create a deployment group but unable to share it across multiple projects. I'm unable to see the deployment pools (and I have admin permissions).

[RoopeshNair]

Sharing of deployment group targets will be available in TFS 2018 Update 2 onward.

[Tarig0]

@RoopeshNair The current implementation is 1 agent group\queue multiple projects.
1 agent -> multiple projects sounds like you can re-group agents in each project.

To be fair the original answer was written before the notion of deployment queues was presented to the users of VSTS

|Agent |Deployment Queue |Project|Valid
|--------|----------------------|----------------------|------
| WebA | app1 | app1|Yes
| WebB | app2 | app2|Yes
| DB | app1 | app1|Yes
| ^==> | app2 | app2|No

[RoopeshNair]

Agents are registered against the pool and are at collection/deployment level. Queues/Deployment Groups are proxy for the pool in a team project. So you have the DB agent registered with the pool and use it in one or more projects via. deployment group/queue in respective projects

[search8]

@RoopeshNair Ok, thank you. We'll wait for that then.

[TingluoHuang]

@NickMRamirez is your original question be answered?
@RoopeshNair is the problem been fixed? i didn't see any changes to the generated config script in deployment group

[TingluoHuang]

i am going to close this issue for now, please reopen if needed.