-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass proxy environment variables to the building container when building node images #3480
Conversation
|
Welcome @Zumium! |
Hi @Zumium. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
we inherit proxy variables from the environment, is this not the case with building ? https://kind.sigs.k8s.io/docs/user/quick-start/#configure-kind-to-use-a-proxy I don't expect to add flags for this |
pkg/build/nodeimage/buildcontext.go
Outdated
@@ -135,6 +136,9 @@ func (c *buildContext) buildImage(bits kube.Bits) error { | |||
"docker", "commit", | |||
// we need to put this back after changing it when running the image | |||
"--change", `ENTRYPOINT [ "/usr/local/bin/entrypoint", "/sbin/init" ]`, | |||
// remove http proxy setting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why remove?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because during my testing, I found that the control panel wasn't able to start up with my built node image, and the built image was carrying the proxy settings. When I removed them, it worked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this does not gives much confidence on the solution proposed :/
pkg/build/nodeimage/buildcontext.go
Outdated
"--security-opt", "seccomp=unconfined", // ignore seccomp | ||
"--network=host", | ||
} | ||
if c.httpProxy != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this can be obtained from
kind/pkg/cluster/internal/providers/common/proxy.go
Lines 35 to 37 in 40c81f1
// GetProxyEnvs returns a map of proxy environment variables to their values | |
// If proxy settings are set, NO_PROXY is modified to include the cluster subnets | |
func GetProxyEnvs(cfg *config.Cluster) map[string]string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that this GetProxyEnvs
function is for using in provisioning clusters, because it requires a cluster config as its parameter, which we don't have when building node images. I'll just read from env vars directly.
@@ -86,6 +87,12 @@ func NewCommand(logger log.Logger, streams cmd.IOStreams) *cobra.Command { | |||
"", | |||
"architecture to build for, defaults to the host architecture", | |||
) | |||
cmd.Flags().StringVar( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no flags
@aojea Hi, aojea. The "http_proxy" and "https_proxy" env vars are not working with building yet because they are not passed to the building container, which is what happened when I tested it. If no flags is the preferred way, I'll adjust my code to read proxy settings from env vars instead of a flag. |
pkg/build/nodeimage/buildcontext.go
Outdated
"--name=" + id, | ||
"--platform=" + dockerBuildOsAndArch(c.arch), | ||
"--security-opt", "seccomp=unconfined", // ignore seccomp | ||
"--network=host", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was not here before, was it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The line --network=host
is added by me, the others were there before. The purpose of --network=host
is to be able to use local host proxy like "http://127.0.0.1:1080".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can not submit a PR with multiple changes without informing the reviewers, this is a change in behavior, it requires additional discussion, and in this case it seems that is only to fit your personal workflow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please do only one change at a time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of --network=host is to be able to use local host proxy like "http://127.0.0.1:1080/".
@Zumium
This is not necessary for the current PR, you can still use the proxy even without the host network, doesn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liangyuanpeng Well, I'm afraid it's necessary especially for a proxy running on localhost. Imagine your proxy server is running locally on host, for example http://127.0.0.1:1080, which I believe is a common case. If the address is directly set to the container and not using host network, "127.0.0.1" will refer to the container's localhost, and the programs inside the container will fail to connect to proxy because they're not connecting to the right place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BenTheElder I believe that the core of the problem is the meaning of "localhost" changes inside & outside of the container, and proxies usually bind on localhost for safety reason, preventing a process inside container from connecting to it directly. If host network is not accepted, we may have to add some kind of relay-er, and it will be a more complex solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can use the IP of your host, proxies use to listen in all host ip addresses, is easier to modify your proxy than force this pod to run with hostnetwork
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also ok to just keep KIND simple and leave the worry to users. I'll modify my code later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't disagree, but this was this way for years with zero problems, and everytime we change something that sounds simple, it always have consequences
/assign @BenTheElder |
sorry for the delay, we should still make one of the requested changes re: host network |
/ok-to-test |
can you squash all commits? |
…ntainer when building node images
Done. |
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aojea, Zumium 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 |
Thank everyone for helping! What a coincidence that today happens to be 除夕(chu xi) festival, which marks the beginning of a new Chinese year. Again, thank you everyone and happy Chinese new year! |
happy new year :) |
When used in a restricted network environment, KIND may not be able to download necessary resources directly from the Internet during the building process, which makes the building fail. Adding
--http-proxy
option to the "build node-image" command helps to solve the problem by setting up the building container withhttp_proxy
andhttps_proxy
environment variables and making the downloading to be able to use the provided proxy.