-
Notifications
You must be signed in to change notification settings - Fork 29
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
[2pt] PR: docker file for OWP, non root user #1322
base: dev
Are you sure you want to change the base?
Conversation
I got an error running
|
udpates for the new name of Dockerfile.dev and look for minor changes for FIM output files folder convention of `hand_` instead of `fim_`
…ion-mapping into dev-docker-root
|
||
### Additions | ||
|
||
- owp.Dockerfile: as described |
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 should be changed to Dockerfile.prod
.
ENTRYPOINT ["/bin/bash", "/entrypoint.sh"] | ||
|
||
## This results in the default user being the svc_user user | ||
USER $RuntimeUser |
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.
Should USER
be set earlier in the Dockerfile? I think the convention is to set USER
as early in the Dockerfile as possible (i.e., after root
is used to install necessary packages) to accidentally allow permissions. If USER
is set after the ENTRYPOINT
is there a chance that the command prompt in the container is not RuntimeUser
but root
?
For security reasons, we needed to create a docker image that does not use the root user in anyway. The new
Dockerfile.prod
file is to be used when we want to use a non-root user. The originalDockerfile
has been renamed toDockerfile.dev
and will continue to use it's root users which has no problems with interacting with external mounts.Note: Re: using pip or pipenv installs.
In the Dockerfile.prod, you can not do installs or update using either pipenv or pip. Those types of tests and adjustments need to be done in the
Dockerfile.dev
.Dockerfile.dev
will also allow change to thePipfile
andPipfile.lock
. Both docker files share the Pipfiles so it should be just fine.File Renames
Dockerfile
, nowDockerfile.dev
Additions
Changes
README.md
: change notes from phraseDockerfile
toDockerfile.dev
. Also added some notes about the new convention of outputs no longer starting withfim_
but nowhand_
fim_pipeline.sh
: Change for the newDockerfile.prod
for permissions.fim_post_processing.sh
: Change for the newDockerfile.prod
for permissions.fim_pre_processing.sh
: Change for the newDockerfile.prod
for permissions.fim_process_unit_wb.sh
: Change for the newDockerfile.prod
for permissions.Testing
Deployment Plan (For developer use)
How does the changes affect the product?
Issuer Checklist (For developer use)
You may update this checklist before and/or after creating the PR. If you're unsure about any of them, please ask, we're here to help! These items are what we are going to look for before merging your code.
[_pt] PR: <description>
dev
branch (the default branch), you have a descriptive Feature Branch name using the format:dev-<description-of-change>
(e.g.dev-revise-levee-masking
)dev
branchpre-commit
hooks were run locally4.x.x.x
Merge Checklist (For Technical Lead use only)