feat: add support for proxy settings during docker build #45
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,6 +7,11 @@ ARG BASE_IMAGE="quay.io/centos/centos:stream8" | |
| FROM ${BASE_IMAGE} | ||
| MAINTAINER "Will Szumski" <[email protected]> | ||
|
|
||
| ARG http_proxy | ||
| ARG https_proxy | ||
| ENV http_proxy $http_proxy | ||
| ENV https_proxy $https_proxy | ||
|
There was a problem hiding this comment. It's quite common to also need no_proxy, but I note that Will had problems will commas. |
||
|
|
||
| # Unclear at this time if different environments will change | ||
| # control host bootstrap. | ||
| ARG KAYOBE_ENVIRONMENT="" | ||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back 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.
We already pass these args in when building the image in SKC CI. Presumably they were unused.
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 also see that http(s)_proxy are referenced on L69, perhaps coming from Docker config?
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.
If that is the case then we would need to move them before download packages as SMSLab kayobe-automation cannot build unless these proxy settings are present.
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.
Let's wait for Will to get the history on this.
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.
CC @jovial
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 think I did once bake in the the proxy environment variables as env vars, but I recall I had issues when using the same image in another environment (which used another proxy). Passing these variables in at runtime seemed like the better option. Is this the only way to set a proxy at build time? I thought there were some command line parameters to docker build 🤔
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 will investigate further. Good point about sharing the image between environment and still carrying the proxy settings.
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.
If we could make them not persistent after build that would be ideal. Can we get away with the build arg only and possibly pass them in like this:
or possibly you can clear the env var?
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.
Missed the comment in https://github.com/stackhpc/kayobe-automation/pull/45/files#r1440221535, so that code is still in there. I guess this isn't so bad then. My feeling is that approach of baking it in was a bit of a mistake though.
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 think this is the magic that means that you don't need to explicitly define the build arg: https://docs.docker.com/engine/reference/builder/#predefined-args