How can I copy an existing overthere.SshHost file in XL Deploy UI using Puppet?

105 views Asked by At

The Infra team in my company has provided us with sample overthere.SshHost under 'Infrastructure' in XL-Deploy UI that has a predefined private key file and passphrase which is not shared with us.
We are asked to duplicate this file manually in the UI, rename it and create infra entries for our application.

How can I achieve this with puppet?

Lets say the sample file is placed under: Infrastructure/Project1/COMMONS/Template_SshHost and I need to create an overthere.SshHost under

Infrastructure/Project1/UAT/Uat_SshHost and
Infrastructure/Project1/PREPROD/Preprod_SshHost by copying the sample file.

Thanks in advance!

1

There are 1 answers

0
John Bollinger On

You can sync a target file with another file accessible via the local file system by using a File resource whose source attribute specifies the path to the original. You can produce a modified copy in a variety of ways, such as by applying one or more File_line resources (from stdlib) or by applying an appropriate script via an Exec resource.

But if you go that route then you have to either

  • accept that the target file will be re-synced on every Puppet run, OR
  • set the File resource's replace attribute to false, in which case changes to the original file will not be propagated into the customized copy.

The latter is probably the more acceptable choice for most people. Its file-copying part might look something like this:

$project_dir = '/path/to/Infrastructure/Project1'

file { "${project_dir}/UAT/Uat_SshHost/overthere.SshHost":
  ensure  => 'file',
  source  => "${project_dir}/COMMONS/Template_SshHost/overthere.SshHost",
  replace => false,
}

But you might want to consider instead writing a custom type and provider for the target file. That would allow you to incorporate changes from the original template without re-syncing the file on every run, and it would give you a lot more flexibility with respect to the customizations you need to apply. It would also present a simpler interface for you to use in your manifests, which could make managing these easier. But, of course, that's offset by the cost is that writing and maintaining a custom type and provider. Only you can determine whether that would be a worthwhile trade-off.