Oracle welcomes contributions to this repository from anyone.
If you want to submit a pull request to fix a bug or enhance an existing
Dockerfile, please first open an issue and link to that issue when you
submit your pull request.
If you have any questions about a possible submission, feel free to open an issue too.
Contributing to the Oracle Docker Images repository
Pull requests can be made under The Oracle Contributor Agreement (OCA).
For pull requests to be accepted, the bottom of your commit message must have the following line using your name and e-mail address as it appears in the OCA Signatories list.
Signed-off-by: Your Name <email@example.com>
This can be automatically added to pull requests by committing with:
git commit --signoff
Only pull requests from committers that can be verified as having signed the OCA can be accepted.
Pull request process
- Fork this repository
- Create a branch in your fork to implement the changes. We recommend using
the issue number as part of your branch name, e.g.
- Ensure that any documentation is updated with the changes that are required by your fix.
- Ensure that any samples are updated if the base image has been changed.
- Submit the pull request. Do not leave the pull request blank. Explain exactly what your changes are meant to do and provide simple steps on how to validate your changes. Ensure that you reference the issue you created as well. We will assign the pull request to 2-3 people for review before it is merged.
We have some golden rules that we require all submitted
Dockerfiles to abide
by. These rules are provided by Oracle Global Product Security and may change
at any time.
Most of these are targeted at Oracle employees, but apply to anyone who submits a pull request.
Base Image Rules
- All Oracle product images must use an Oracle Linux base image.
- Extend an existing product image wherever possible. For example, if your product requires WebLogic, then extend the WebLogic image instead of creating your own WebLogic installation.
- Re-use existing scripts wherever possible. If a particular base image or script doesn't have the functionality you need, open an issue and work with the image owner to implement it.
- Specify a fixed version in the
FROMdirective, i.e. use
- All images must provide a
ENTRYPOINT. If your image is designed to be extended, then this should output documentation on how to extend the image to be useful.
Do not require the use of the
--privilegedflag when running a container.
Do not run an SSH daemon (
sshd) inside a container.
Do not use host networking mode (
--net=host) for a container.
Do not hard-code any passwords. If passwords are required, generate them on container startup using
openssl randor accept a password argument during container startup (via
Guidelines and Recommendations
The following are some guidelines that will not prevent an image from being merged, but are generally frowned upon if breached.
- Always aim to produce the smallest possible image. This means the least amount of layers (combine directives wherever possible) and cleaning up as much as possible inside a single directive so the layer only stores the binary changes.
- Don't install all possible required RPMs, even if the product
documentation says so. Some RPMs aren't applicable inside a container, e.g
filesystem utilities (
- Don't install any interactive/user tools, e.g. things like
man. Debugging should be done prior to the image submission.
- Don't install
wgetas the base images already include
- Always remember to run
rm -rf /var/cache/yumin the same
RUNdirective as a
yum installso that the yum metadata is not stored in the layer.
- Always document any inputs (via
-e) required by
docker run. This documentation should also clearly state any defaults that are used if no input is provided.
- If a custom value must be provided by the end-user, the build or run should gracefully fail if that value is not provided.
Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.