[Discussion] Managing template source files with container-based drivers
- Dominant language
- Go
- Stars
- 17k
- Forks
- 2.1k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 105
Description
The following is a summary from the nomad/Lobby Gitter room starting around March 1, 2017 11:50am.
I posed the question:
```
Question for those using the docker driver and templating with Nomad:
How did you deal with requirement for template source files to exist on the nomad worker prior to job launch?
I think I've heard the following:
a) Use the artifact stanza to fetch the template source files,
b) Embed consul-template within the container image,
c) Some out-of-band process to fetch the source files,
d) Something else entirely.
e) Embed the template source directly in the job file with the data key. (suggested by @schmichael).
```
My point was: I really like the nomad template functionality, but if I'm going to do containers, I'd really like to have a legit artifact that I can manage.
Michael also summarized the internal flow, which was very helpful:
> To put it in Nomad internal terms: we currently do the following:
(1) download artifacts, (2) render templates, (3) driver.Prestart() downloads image, (4) driver.Start() starts container.
> What we need is: (1) artifacts, (2) driver.Prestart() downloads image and creates container, (3) render templates, (4) start.
Some of this may be in the works already, but @schmichael wanted to capture it as an issue.
Members of the community have developed various solutions that may be of benefit to the project and will hopefully capture those concepts here.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the artifact and template lifecycle around the driver.Prestart() and driver.Start() entry points mentioned in the discussion. Compare the current ordering with the requested container flow, and treat the work as done when artifacts are fetched, the container is created, templates are rendered, and the container starts in that order.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100