-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Make Production Dockerfile OpenShift-compatible #9545
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
Merged
potiuk
merged 1 commit into
apache:master
from
PolideaInternal:makep-prod-dockerfile-openshift-compatible
Jun 27, 2020
Merged
Make Production Dockerfile OpenShift-compatible #9545
potiuk
merged 1 commit into
apache:master
from
PolideaInternal:makep-prod-dockerfile-openshift-compatible
Jun 27, 2020
Conversation
This file contains hidden or 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
Member
Author
672bac2 to
1bef8ff
Compare
kaxil
approved these changes
Jun 27, 2020
OpenShift (and other Kubernetes platforms) often use the approach that they start containers with random user and root group. This is described in the https://docs.openshift.com/container-platform/3.7/creating_images/guidelines.html All the files created by the "airflow" user are now belonging to 'root' group and the root group has the same access to those files as the Airflow user. Additionally, the random user gets automatically added /etc/passwd entry which is name 'default'. The name of the user can be set by setting the USER_NAME variable when starting the container. Closes apache#9248 Closes apache#8706
1bef8ff to
6cc9de5
Compare
potiuk
added a commit
that referenced
this pull request
Jun 29, 2020
OpenShift (and other Kubernetes platforms) often use the approach that they start containers with random user and root group. This is described in the https://docs.openshift.com/container-platform/3.7/creating_images/guidelines.html All the files created by the "airflow" user are now belonging to 'root' group and the root group has the same access to those files as the Airflow user. Additionally, the random user gets automatically added /etc/passwd entry which is name 'default'. The name of the user can be set by setting the USER_NAME variable when starting the container. Closes #9248 Closes #8706 (cherry picked from commit cf510a3)
kaxil
pushed a commit
that referenced
this pull request
Jul 1, 2020
OpenShift (and other Kubernetes platforms) often use the approach that they start containers with random user and root group. This is described in the https://docs.openshift.com/container-platform/3.7/creating_images/guidelines.html All the files created by the "airflow" user are now belonging to 'root' group and the root group has the same access to those files as the Airflow user. Additionally, the random user gets automatically added /etc/passwd entry which is name 'default'. The name of the user can be set by setting the USER_NAME variable when starting the container. Closes #9248 Closes #8706 (cherry picked from commit cf510a3)
greenape
added a commit
to Flowminder/FlowKit
that referenced
this pull request
Dec 16, 2020
greenape
added a commit
to Flowminder/FlowKit
that referenced
this pull request
Jan 4, 2021
cfei18
pushed a commit
to cfei18/incubator-airflow
that referenced
this pull request
Mar 5, 2021
OpenShift (and other Kubernetes platforms) often use the approach that they start containers with random user and root group. This is described in the https://docs.openshift.com/container-platform/3.7/creating_images/guidelines.html All the files created by the "airflow" user are now belonging to 'root' group and the root group has the same access to those files as the Airflow user. Additionally, the random user gets automatically added /etc/passwd entry which is name 'default'. The name of the user can be set by setting the USER_NAME variable when starting the container. Closes apache#9248 Closes apache#8706 (cherry picked from commit cf510a3)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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.
OpenShift (and other Kubernetes platforms) often use the approach
that they start containers with random user and root group. This is
described in the https://docs.openshift.com/container-platform/3.7/creating_images/guidelines.html
All the files created by the "airflow" user are now belonging to
'root' group and the root group has the same access to those
files as the Airflow user.
Additionally, the random user gets automatically added
/etc/passwd entry which is name 'default'. The name of the user
can be set by setting the USER_NAME variable when starting the
container.
Closes #9248
Closes #8706
Make sure to mark the boxes below before creating PR: [x]
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.
Read the Pull Request Guidelines for more information.