Oracle Database: please remove volume from base image

[veqryn]

Base Oracle DB images container-registry.oracle.com/database/enterprise:12.2.0.1 and container-registry.oracle.com/database/enterprise:12.2.0.1-slim have the following volume mount declared:
VOLUME ["/ORCL"]

Because there is no way to remove or unset a volume when extending an image, this basically prevents me from being able to create an image pre-loaded with a test or dev database.
Even if you unpack, setup, configure, and load a database, it just disappears after that Dockerfile line ends.

There are no benefits to declaring a volume line in a dockerfile. Even if you do, the client still has to declare a volume anyway to make any use of it (for example, by declaring it in a run statement or in their docker-compose.yaml file). And removing this line will have no effect, because the client can still create a volume anytime they want to be putting it in their run statement or docker-compose file.

Can you please remove the volume mount declaration from the base image?

[veqryn]

@brunoborges @gvenzl just wondering if there is any update on this?

[brunoborges]

I'd say you should simply get the original Dockerfile, and edit it to your own needs. Most users do want VOLUME.

[Djelibeybi]

@brunoborges: There is no original Dockerfile for the Database images stored on the Oracle Container Registry or Docker Store. Unlike every other product, they do not use the same Dockerfiles hosted here on GitHub.

@veqryn: The only option if you don't want the preconfigured VOLUME is to stop using the prebuilt images and to use the GitHub Dockerfile to build your own image for Database instead.

[brunoborges]

@Djelibeybi sorry, when I said "original Dockerfile" I simply meant the Dockerfile in this repo, and to build from scratch... :P

[veqryn]

So, I prefer to use the containers in the Oracle Container Registry because they are already made and I assume supported by Oracle.

Why do we have two different ways of creating the same container, and why isn't the Dockerfile for the ones in the Oracle Container Registry published? (ie: container-registry.oracle.com/database/enterprise:12.2.0.1)

[Djelibeybi]

Oracle Database is certified to run inside a Docker container regardless of how that container was created.

Having said that, the Dockerfile in this repo was created by Oracle and the image hosted on Oracle Container Registry and Docker Store are created by Oracle. So both are equally acceptable in terms of provenance.

Finally, while there are reasons behind why only the Database image is different, I'm afraid I can't discuss them here on GitHub.

[veqryn]

So, if we aren't able to get into the why, can we at least address the what? ie: what is the actual difference between an Oracle Enterprise Database container image created through the Dockerfile in this repo, and the same version of it found on in the image repo container-registry.oracle.com/database/enterprise?
Like, how are the Dockerfiles different?

[Djelibeybi]

They are completely different. There is no way to even compare them. The image on Container Registry and Docker Store bares almost zero resemblance to the once here on GitHub. I've never actually seen the Dockerfile that was used to build the image on OCR/Store, in fact.

[brunoborges]

@gvenzl may be able to address the differences. But sincerely, you shouldn't worry about the difference. If you don't like the features of the pre-built images, we encourage you to build your own, and support will still be provided if needed.

[gvenzl]

After a while of discussions, etc. I have followed up on this on the Docker Forum: https://forums.docker.com/t/why-use-the-volume-instruction/55420
Let's see what we get back and @veqryn, please feel free to chime in over there as well!

[simpss]

I was about to write up another issue, but luckily did a search instead.

I see a couple reasons why the VOLUME instruction should be removed.

• one can not unset the VOLUME instruction in inheriting dockerfiles. See: Reset properties inherited from parent image moby/moby#3465
• DB images are often used with baked in data(integration testing for example)
• Even if prebaked data is not needed, first start-up is slow.
• When just running the image(docker run), it doesn't even provide that much data-safety for someone who is new to docker, as the container will start with a new anonymous volume when docker run is executed again. (+ not being able to find the correct volume, as said before)
• if disaster recovery is needed, one can docker cp files out from a stopped container.
• (subjective) it's better to inherit from a common base image/dockerfile and bake data by extending the image, instead of having many forks of the original Dockerfile.
• (subjective) People will stumble on this issue, like Reset properties inherited from parent image moby/moby#3465 (comment), I just spent the better part of a night not understanding why my data isn't persisted properly.

I guess the Dockerfile volume instruction is a left-over from a time when docker handed volumes differently and didn't have named volumes yet?

So i'd like to show support towards removing the VOLUME instruction from DB dockerfiles here.

[nochmu]

I would like it if the image can be built without any volume.
So it is possible to build an image that contains a completely preinstalled instance. Especially for testing it would be nice not to wait until the instance has been created.
I think it would be better if the VOLUME were optional at least for the Dockerfiles. The VOLUME could be added at a separate stage at the end of the Dockerfile:
https://docs.docker.com/develop/develop-images/multistage-build/#stop-at-a-specific-build-stage

[rammpeter]

This unremovable VOLUME also hurts me while trying to create a database instance during docker build.

There's a simple workaround possible for the VOLUME-issue:

• copy content of /opt/oracle/oradata at end of db creation to a backup dir
• link the two dirs in /opt/oracle/oradata to the saved content as first step of container creation

The Dockerfile and two wrapper-files for docker build and run I attach here as zip
files.zip
: