Users are better served by not using the built-in gitRepo volume
type. Update the documentation to suggesting using an init
container instead.
NOTE: This doesn't need to wait for 1.11 and can be merged
to master.
Background discussion can be found in:
kubernetes/kubernetes#60999
kubernetes/kubernetes#63445
cc @kubernetes/sig-storage-pr-reviews
https://github.com/kubernetes/website/pull/8429
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.![]()
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: heckj
Assign the PR to them by writing /assign @heckj in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Deploy preview for kubernetes-io-master-staging ready!
Built with commit 5624d3b
https://deploy-preview-8429--kubernetes-io-master-staging.netlify.com
@msau42 commented on this pull request.
In content/en/docs/concepts/storage/volumes.md:
> @@ -370,19 +370,44 @@ spec: ### gitRepo -A `gitRepo` volume is an example of what can be done as a volume plugin. It -mounts an empty directory and clones a git repository into it for your pod to -use. In the future, such volumes may be moved to an even more decoupled model, -rather than extending the Kubernetes API for every such use case. - -Here is an example for gitRepo volume: +While Kubernetes has a built-in `gitRepo` volume type, its functionality is
Maybe here, the doc should say gitRepo volume type is deprecated. And then point to a new doc, maybe under tasks?
@ericchiang commented on this pull request.
In content/en/docs/concepts/storage/volumes.md:
> @@ -370,19 +370,44 @@ spec: ### gitRepo -A `gitRepo` volume is an example of what can be done as a volume plugin. It -mounts an empty directory and clones a git repository into it for your pod to -use. In the future, such volumes may be moved to an even more decoupled model, -rather than extending the Kubernetes API for every such use case. - -Here is an example for gitRepo volume: +While Kubernetes has a built-in `gitRepo` volume type, its functionality is
What about adding this example to the init containers doc? https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#what-can-init-containers-be-used-for
@msau42 commented on this pull request.
In content/en/docs/concepts/storage/volumes.md:
> @@ -370,19 +370,44 @@ spec: ### gitRepo -A `gitRepo` volume is an example of what can be done as a volume plugin. It -mounts an empty directory and clones a git repository into it for your pod to -use. In the future, such volumes may be moved to an even more decoupled model, -rather than extending the Kubernetes API for every such use case. - -Here is an example for gitRepo volume: +While Kubernetes has a built-in `gitRepo` volume type, its functionality is
I think it might be better as a new task doc. I think users will want to know "how do I access git in my container", and won't think to go to the init containers page.
@msau42 added a task document.
@msau42 commented on this pull request.
In content/en/docs/tasks/configure-pod-container/git-repo/configmap.yaml:
> @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: git-clone +data: + git-clone.sh: | + #!/bin/sh -e + + # Init Containers will re-run on Pod restart. Remove the directory's contents
Can you document in a comment what each argument is?
In content/en/docs/tasks/configure-pod-container/git-repo/configmap.yaml:
> @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: git-clone +data: + git-clone.sh: | + #!/bin/sh -e + + # Init Containers will re-run on Pod restart. Remove the directory's contents
Is storing a script a recommended use of a configmap?
@ericchiang commented on this pull request.
In content/en/docs/tasks/configure-pod-container/git-repo/configmap.yaml:
> @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: git-clone +data: + git-clone.sh: | + #!/bin/sh -e + + # Init Containers will re-run on Pod restart. Remove the directory's contents
Is storing a script a recommended use of a configmap?
I couldn't find an example in https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/
However, I think it's nice to be able to inline the example like this. Realistically, a user would probably build a "git-puller" image or something like that.
Command arguments now documented.
@ericchiang Thanks for adding this, great job on the formatting. 👍
/approve
@msau42 If this looks good to you, please /lgtm it to merge.
/assign @msau42
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: zacharysarah
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
—
/assign @tallclair
/hold
@tallclair It would be great to get your review on this in light of CVE 2018-11235.
@tallclair commented on this pull request.
In content/en/docs/tasks/configure-pod-container/git-repo/configmap.yaml:
> @@ -0,0 +1,21 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: git-clone +data: + git-clone.sh: |
I haven't seen the pattern of passing a script as a configmap before.... I'm not sure that's a pattern we should be encouraging? I think this can all just be inlined into the deployment.
In content/en/docs/tasks/configure-pod-container/git-repo/configmap.yaml:
> @@ -0,0 +1,21 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: git-clone +data: + git-clone.sh: | + #!/bin/sh -e + + REPO=$1 + REF=$2 + DIR=$3
nit: I think it's simpler to just use environment variables instead.
In content/en/docs/tasks/configure-pod-container/git-repo/configmap.yaml:
> + name: git-clone +data: + git-clone.sh: | + #!/bin/sh -e + + REPO=$1 + REF=$2 + DIR=$3 + + # Init Containers will re-run on Pod restart. Remove the directory's contents + # and reprovision when this happens. + if [ -d "$DIR" ]; then + rm -rf $( find $DIR -mindepth 1 ) + fi + + git clone $REPO $DIR
nit: prefer git clone -- $REPO $DIR (less error-prone)
In content/en/docs/tasks/configure-pod-container/configure-git-repo.md:
> +single-node cluster, you can create one by using
+[Minikube](/docs/getting-started-guides/minikube).
+
+* Familiarize yourself with the material in
+[Init Containers](/docs/concepts/workloads/pods/init-containers/).
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Cloning a Git repo
+
+The [emptyDir](/docs/concepts/storage/volumes/#emptydir) volume type can be used
+to share data between multiple containers in a Pod.
+
+First, define a script for cloning a repo to run in the Init Container:
Should we also mention https://github.com/kubernetes/git-sync as another approach, when continuous syncing is desired?
Closed #8429.
@ericchiang 👋 Please feel free to reopen this PR when you're ready to incorporate review feedback.