Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Multi-Node deployment

Hello everyone,

I am currently struggeling with a use-case of one of our Bamboo users.

There is a deployment-project that is logically shared between two groups. One group (A) provides the code/artifacts to be deployed, the other group (B) provides the access to the targets where the deployment shall be executed at.

Access is via a SSH-Key. Due to how the SCP and SSH Tasks handle the key (retrieving the key once, using it, but never showing it again). Therefore group A can easily use the deployment and deployment environments, make changes to the tasks and even deploy. Group B can be quite sure that the SSH Key can not be read and is only handled by Bamboo and its Agents.

But: The deployment needs to be done to two identical servers that are behind some kind of round-robin load-balancing. The SSH and SCP Tasks dont support multiple hosts though. Therefore I currently only see the solution to have every SSH- and SCP-Task twice, completly identical, just with another hostname as target.

I cant use script-tasks, as then I would need to either place the ssh-key as a file somewhere or create it as a file via a bamboo variable during runtime. With each of those ways it would be possible to e.g. redirect the key to somewhere else to read it. I also thought about using specs to at least make it less tideous to create every task twice. But then again, I have to store the ssh-key somewhere for the spec execution to pick it up, right? And as group A maintains the deployment tasks they can again add a way to obtain the key.

I found as a feature request. But that seems to be quite dead.

Any other suggestions?

0 answers

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events