As per the wiki on running this pipeline from an existing Concourse it wants you to specify where to download the images from. You're expected to download the content from vmware's site and host it on an accessible webserver. It's not ideal to have to download the file and be responsible for maintaining it on a webserver.
If you're using the Concourse docker image deployment method you can pass it vmware credentials to download it locally to a VM. But this isn't ideal either, as you have to create an Ubuntu VM in vCenter with Docker on it.
And if you run the Concourse docker workflow locally (without using a VM, using a local machine) it's less than ideal because:
Docker is running as root && can modify your filesystem
The pipeline run becomes only accessible to whoever is running it, it's not persistent or visible to the rest of the team
Can't use Concourse secret-manager backends, e.g. credhub/vault. You have to put passwords down in plaintext.
However if you are using the Concourse docker workflow via the docker_image/Dockerfile, it's better to not take advantage of volume mounts to get the *.ova and *.bundle into the pipeline. It's better to assume the pipeline will always have to retrieve those files from some source other than the filesystem; I feel like that could lead to a more flexible implementation?
solution
The *.ova and *.bundle could be downloaded directly from vmware's site from within the pipeline, perhaps via the vmw-cli (or curl resource?) as a resource, rather than using Docker to download those files from my.vmware.com && then serving them up via nginx.
Similar [#37]
As per the wiki on running this pipeline from an existing Concourse it wants you to specify where to download the images from. You're expected to download the content from vmware's site and host it on an accessible webserver. It's not ideal to have to download the file and be responsible for maintaining it on a webserver.
If you're using the Concourse docker image deployment method you can pass it vmware credentials to download it locally to a VM. But this isn't ideal either, as you have to create an Ubuntu VM in vCenter with Docker on it.
And if you run the Concourse docker workflow locally (without using a VM, using a local machine) it's less than ideal because:
However if you are using the Concourse docker workflow via the
docker_image/Dockerfile
, it's better to not take advantage of volume mounts to get the*.ova
and*.bundle
into the pipeline. It's better to assume the pipeline will always have to retrieve those files from some source other than the filesystem; I feel like that could lead to a more flexible implementation?solution
The
*.ova
and*.bundle
could be downloaded directly from vmware's site from within the pipeline, perhaps via thevmw-cli
(orcurl
resource?) as a resource, rather than using Docker to download those files frommy.vmware.com
&& then serving them up vianginx
.Thoughts?