{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/30716","repository_url":"https://api.github.com/repos/kubernetes/kubernetes","labels_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/30716/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/30716/comments","events_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/30716/events","html_url":"https://github.com/kubernetes/kubernetes/issues/30716","id":171535837,"number":30716,"title":"Proposal: Template object for in-container configuration files","user":{"login":"jberkus","id":115146,"avatar_url":"https://avatars.githubusercontent.com/u/115146?v=3","gravatar_id":"","url":"https://api.github.com/users/jberkus","html_url":"https://github.com/jberkus","followers_url":"https://api.github.com/users/jberkus/followers","following_url":"https://api.github.com/users/jberkus/following{/other_user}","gists_url":"https://api.github.com/users/jberkus/gists{/gist_id}","starred_url":"https://api.github.com/users/jberkus/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jberkus/subscriptions","organizations_url":"https://api.github.com/users/jberkus/orgs","repos_url":"https://api.github.com/users/jberkus/repos","events_url":"https://api.github.com/users/jberkus/events{/privacy}","received_events_url":"https://api.github.com/users/jberkus/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/team/ux","name":"team/ux","color":"d2b48c"},{"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/team/workloads","name":"team/workloads","color":"d2b48c"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":15,"created_at":"2016-08-16T22:46:45Z","updated_at":"2016-08-18T16:19:55Z","closed_at":null,"body":"**Summary**\r\n\r\nI would like us to get rid of custom entrypoint.sh scripts by supporting templating of in-container files.\r\n\r\n**The Problem**\r\n\r\nDespite current ConfigMap features, it remains necessary for many or most container images under Kubernetes to include \"entrypoint.sh\" scripts and/or customizations to the containerized applications which are particular to the Kubernetes environment.  This results in forking of upstream images and limits portability of images between environments.  It also results in some very hackish startup scripts (see Kelsey's \"init scripts for hipsters\").\r\n\r\nBased on feedback through numerous issues and PRs, the main shortcoming in ConfigMap which would allow elimination of entrypoint scripts is the inability to include elements into a configuration file which are only available at deployment time.  For example, some services, such as clustered databases or load balancers, need to know the Pod IP or the pod name as part of their configuration.\r\n\r\n**Suggested Solution: ConfigTemplate**\r\n\r\nSeveral proposals have been made to enhance ConfigMaps to embrace templating functionality, and they have met with significant opposition.  \r\n\r\nMy proposal is that we create a new object ... named here a \"ConfigTemplate\" as placeholder until someone suggests a better one.  This Template object would produce a file inside the deployed container, and could consume the Downward API, Secrets, and ConfigMaps in order to populate a template.  This would be largely the same as PR #30502, but with a new object type instead of overloading ConfigMaps.\r\n\r\nAt a sketch, a ConfigTemplate for an ini-style config file could be inlined, and might look like this:\r\n\r\n```\r\napiVersion: extensions/v1beta1\r\nkind: ConfigTemplate\r\nmetadata:\r\n  name: postgresNodeConf\r\nspec:\r\n  ConfigMapRefs:\r\n     - name: patroniMap\r\n     - name: productionMap\r\n  Template: \r\n     data:\r\n         node_ip: ${status.podIP}\r\n         dcs: ${patroniMap.dcsconn}\r\n         cluster_name: ${productionMap.cluster}\r\n         memory: 128MB\r\n```\r\n\r\nNote: what syntax we use for the exact substitutions is unimportant; let's just use whatever is easiest to support/code.\r\n\r\nFor inline versions, it is likely that only key: $value substitutions would be supported.  For more complex behavior, including differently-formatted configuration files, we'd support file-based substitution, ala:\r\n\r\n```\r\napiVersion: extensions/v1beta1\r\nkind: ConfigTemplate\r\nmetadata:\r\n  name: postgresNodeConf\r\nspec:\r\n  ConfigMapRefs:\r\n     - name: patroniMap\r\n     - name: productionMap\r\n  Template: \r\n      file: templates/pg.conf.prod\r\n```\r\n\r\nThe file in question would be some kind of text file, with substitution tags in whatever syntax we decide on.  Either way, the ConfigTemplate would then be used inside Pod definitions like this:\r\n\r\n```\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n  name: pgProdPod\r\nspec:\r\n  containers:\r\n    - name: postgres\r\n      image: jberkus/patroni\r\n      templates:\r\n         - name: postgresNodeConf\r\n           path: /etc/postgres/pgnode.conf\r\n```\r\n\r\n**Why not volumes?**\r\n\r\nYou'll notice above that I'm not taking a regular \"volume\" approach to this. That's because in many cases ... including some cases I have personally ... the rendered config file needs to share directories with files which come from the container image.  Doing this in a volume is complicated, and will lead (again) to custom entrypoint.sh scripts.\r\n\r\nHowever, if there are strong reasons to handle this as a volume, that could be worked around.\r\n\r\n**Templating Engines and Sidecars**\r\n\r\nThere is some discussion about how templating would be handled and what templating engine we'd use.  This includes a suggestion by @thockin that this be entirely sidecar functionality.\r\n\r\nI will argue that providing config file templates which allow containers to start inside Kubernetes pods without modification is fairly central functionality to what Kubernetes does, and as such the general Template object should be a core Kubernetes object.  However, I can certainly see the value of allowing the user to plug in their choice of rendering library for the actual template rendering for file-based templates; if nothing else, it would forestall a lot of arguments about syntax.\r\n\r\nEven in that case, however, I would like us to provide a built-in very simple template renderer, one which is capable of just swapping in upstream facts for some specific variable syntax, such as ${fact} or {{fact}} or similar, and nothing else.  Such a built-in renderer would satisfy 90% of users, and not push the user into installing extra dependencies.\r\n\r\n**Alternatives**\r\n\r\nI cannot personally think of any alternatives which will lead to the elimination of the majority of entrypoint.sh scripts.  Suggestions welcome.\r\n\r\n**References**\r\n\r\n* PR #30502\r\n* Issue #29607\r\n* Issue #28560\r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/comments/240776467","html_url":"https://github.com/kubernetes/kubernetes/issues/30716#issuecomment-240776467","issue_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/30716","id":240776467,"user":{"login":"jberkus","id":115146,"avatar_url":"https://avatars.githubusercontent.com/u/115146?v=3","gravatar_id":"","url":"https://api.github.com/users/jberkus","html_url":"https://github.com/jberkus","followers_url":"https://api.github.com/users/jberkus/followers","following_url":"https://api.github.com/users/jberkus/following{/other_user}","gists_url":"https://api.github.com/users/jberkus/gists{/gist_id}","starred_url":"https://api.github.com/users/jberkus/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jberkus/subscriptions","organizations_url":"https://api.github.com/users/jberkus/orgs","repos_url":"https://api.github.com/users/jberkus/repos","events_url":"https://api.github.com/users/jberkus/events{/privacy}","received_events_url":"https://api.github.com/users/jberkus/received_events","type":"User","site_admin":false},"created_at":"2016-08-18T16:19:55Z","updated_at":"2016-08-18T16:19:55Z","body":"I'm OK with that.  Would you be willing to sketch out a doc on how you'd do it, now?  Because you seem to find existing approaches easier than I do."}}
{"actor":{"display_login":"jberkus"}}