Skip to content
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

OracleRestDataServices/dockerfiles/buildDockerImage.sh oracle/serverjre:8 Issue #646

Closed
martindsouza opened this issue Nov 9, 2017 · 8 comments
Assignees

Comments

@martindsouza
Copy link
Contributor

martindsouza commented Nov 9, 2017

Note: my copy of buildDockerImage.sh was updated to get around a gawk issue in macOS. The version I am running is in PR #645 (fixing issues #644)

When I run

cd docker-images/OracleRestDataServices/dockerfiles
./buildDockerImage.sh -i

I get:

...
==========================
Building image 'oracle/restdataservices:3.0.12' ...
Sending build context to Docker daemon  47.62MB
Step 1/10 : FROM oracle/serverjre:8
pull access denied for oracle/serverjre, repository does not exist or may require 'docker login'
There was an error building the image.

If I then run the following to confirm no container registry issues

docker login container-registry.oracle.com

# And run
docker pull container-registry.oracle.com/java/serverjre

If I run ./buildDockerImage.sh -i again I get the same error as initial shown.

@gvenzl
Copy link
Member

gvenzl commented Nov 9, 2017

This is a good discussion to have, hence assigning to @Djelibeybi. As we already have the jdk on the hub itself, why can't we just use that one directly: https://hub.docker.com/r/oracle/openjdk/
Why do we have to force users to build their own Java image first when they use the images on Github? It would make more sense to get that layer out of the way. Just like we do with the oraclelinux:7-slim base image we can do the same with the openjdk image from the hub and make it easier for folks to build their images.

@gvenzl
Copy link
Member

gvenzl commented Nov 9, 2017

Also, how do we overcome the different naming conventions? For those images on the container-registry that are built using those build files on Github, why not just keep the same label?

@martindsouza
Copy link
Contributor Author

@gvenzl if we can use the hub image even better. But something is still wrong as I manually pulled the server-jre image.

@Djelibeybi
Copy link
Member

The idea was that all the GitHub images work together. However, I think there is possibly some scope for adjusting the instructions here on GitHub to match the naming we have on Oracle Container Registry.

@gvenzl
Copy link
Member

gvenzl commented Nov 29, 2017

Hey @Djelibeybi, I was actually referring to the image that we provide on the Docker hub itself and not on the container store: https://hub.docker.com/r/oracle/openjdk/ Given that we have a fully open source image of Oracle Linux and OpenJDK I see no reason to have to push users through an additional click-through just to download it from the container-registry when all we need is the JDK on OL.

@brunoborges
Copy link
Contributor

Only issue is that ServerJRE is different than OpenJDK. They are not exactly the same thing. Commercial support for ORDS is provided when running on Oracle Java (e.g. ServerJRE)

@gvenzl
Copy link
Member

gvenzl commented Dec 19, 2017

I suppose the answer to this then is:

The build files on Github depend on each other, i.e. one has to build the Java image first before building the ORDS image.

The images on the container-store depend on each other, i.e. the upcoming ORDS image will pull the serverjre from the container-registry as prerequisite.

@Djelibeybi, @brunoborges do you guys agree?

@Djelibeybi
Copy link
Member

The specifics are slightly different in that the GItHub ORDS image would share layers with the Java image, while the Container Registry ORDS image shares similar layers with the Java image from OCR.

But that's close enough for me to agree with you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants