Add volumes and mount points

[flah00]

• Define volumes the instance exports
• Define mount points the container imports

[jenkinsadmin]

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.

[ndeloof]

Method name is a bit surprising, I suggest getVolumeSpec or anything that make it clean what type of Volume we are talking about here

[ndeloof]

From a technical PoV, sounds to me from user point of view volume and mountpoint should be defined as a single "volume" configuration element, not as separated entities - even this is the cas on the API, but we need to consider UX here, not ECS API design.

Also, I'm not convinced about the actual benefit. Persistent volumes aren't replicated by ECS around the cluster, so you can't rely on them to let build container run on arbitrary node. So you can't safely rely on this. IMHO A better approach to persistent data is to rely on a data volume container and use volumesFrom. ECS plugin could check the cluster to determine if the data volume container exists (based on job name for sample) and if required create a fresh new one, then run builds with volumesFrom to get persistent workspace.

[flah00]

Technical critique

I thought about limiting the input to a single entry, instead of following the API. It seemed like the best option was to follow the API, because if a user becomes confused, they can still reference ECS docs and make meaningful changes to their task template. If we stray from the API, the user will have to understand the ECS API and the way the plugin uses the API. I think that invites misunderstandings. But I don't feel super religious about it... So I'll push the change up.

I'm happy to add help files, I tried adding them in src/main/resources/com/cloudbees/jenkins/plugins/amazonecs/ECSTaskTemplate/ as help-sourcePath.html and help-mountPoints-sourcePath.html but neither showed up in the UI. If you have any suggestions, I can put the files where they belong.

Use case

We need these options to share configuration files across workers.

In our environment, we use chef to keep our configuration files updated. This includes some AWS credentials (because we use multiple AWS accounts), chef encryption keys, pem files, and berkshelf configuration flies. Generally speaking, I would never want to put these files into the image. But more importantly, if we did, we'd have to create new images each time we updated one of the configuration files. Also, putting these files into a data volume container would be cumbersome.

We guarantee chef's presence, by including its installation and configuration in the UserData section of our cloudformation template. Thus, we can be assured the files will always be there.

[afejiang]

@flah00 @ndeloof we have the same situation here too, thanks for it, how to compile and install it manually?

[ndeloof]

Your use case is reasonable, but unfortunately require some additional setup for use with ECS. A docker-centric solution to inject secrets in containers would be better, and more portable.

Anyway, I get your point, will maybe just add some warning in helper.

[ndeloof]

@afejiang get development builds from https://jenkins.ci.cloudbees.com/job/plugins/job/amazon-ecs-plugin/