Docker-images: Docker image for Oracle Database 12c EE fails to build

[zaunerc]

When using the latest clone of this repository (commit b4f2f00a70e60fb1b39767ff6c085546dada9bb6) to build an Docker image for the Oracle Database 12c Enterprise Edition I get the following error:

christoph@nelap:~/repos/docker-images/OracleDatabase/dockerfiles$ sudo ./buildDockerImage.sh -v 12.1.0.2 -e
<...>
Step 10 : USER root
 ---> Running in 0786cd59c1b2
 ---> a4f49555ad17
Removing intermediate container 0786cd59c1b2
Step 11 : RUN $ORACLE_BASE/oraInventory/orainstRoot.sh &&     $ORACLE_HOME/root.sh &&     rm -rf $INSTALL_DIR
 ---> Running in 8a347f5bcaa0
/bin/sh: /opt/oracle/oraInventory/orainstRoot.sh: No such file or directory
Removing intermediate container 8a347f5bcaa0
The command '/bin/sh -c $ORACLE_BASE/oraInventory/orainstRoot.sh &&     $ORACLE_HOME/root.sh &&     rm -rf $INSTALL_DIR' returned a non-zero code: 127
There was an error building the image.
christoph@nelap:~/repos/docker-images/OracleDatabase/dockerfiles$

[gkgeorgiev]

That's exactly the same issue I'm struggling now! I use the latest Master version and I have the same behavior. Any break through?

BTW, @zaunerc, which OS do you use? Not that it should make any difference, but I'm using Windows 7 and we've already noticed that with Kitematic and the Linux VirtualBox image, not all Docker features work smoothly :/

Just to add that I added ls -la in the docker file and I got the following output:
_Step 11 : RUN ls -la $ORACLE_BASE/oraInventory/
---> Running in fbcb7f5a850e
ls: cannot access /opt/oracle/oraInventory/: No such file or directory_

@gvenzl , if you have a few minutes, could you please assist us?

[gvenzl]

Looks like the database binaries installation failed before and hence why /opt/oracle/oraInventory isn't created. Can you please post the entire output of the build.

Thx,

[gkgeorgiev]

Here you go...
output.txt

Thanks in advance!

[gvenzl]

There you go, you don't have enough space available for the installation:

Preparing to launch Oracle Universal Installer from /tmp/OraInstall2016-12-23_01-42-13PM. Please wait ...
[FATAL] [INS-32021] Insufficient disk space on this volume for the selected Oracle home.
   CAUSE: The selected Oracle home was on a volume without enough disk space.
   ACTION: Choose a location for Oracle home that has enough space (minimum of 6,553MB) or free up space on the existing volume.
A log of this session is currently saved as: /tmp/OraInstall2016-12-23_01-42-13PM/installActions2016-12-23_01-42-13PM.log. Oracle recommends that if you want to keep this log, you should move it from the temporary location.

[gkgeorgiev]

Strange, isn't there any way to exit Docker script on the first error?

Hmm where does the space limit come from? From the unix user quota? I thought that root user doesn't have disk space quota? The VirtualBox image that my Kitematic is using, has dynamically allocated storage, which is limited only by the physical disk space (150GB free).

[zaunerc]

@gvenzl, you are right. I took a second look at the log file of my Docker build run and it reports that there is no space left for the Oracle Universal Installer to continue (docker_build_log.txt).

Building the image requires approx. 10GB. Therefore be sure that the Docker base device size is set to at least 25GB. You can check the Base Device Size using the docker info command. The base device size is the maximum size that a container/image can grow to. The default is 10G (at least for the devicemapper storage driver). The base device size can be set on a global level when starting the docker daemon (see here and here) or on a per container basis (see here).

See section about dm.basesize in the docker daemon command reference if you want to change the base device size globally.

See notes about the --storage-opt option in the docker create command reference if you want set the base device size on a per container basis.

I would suggest adding this information to the Oracle Database on Docker README.md file.

@gkgeorgiev, I am using Debian Stretch running Docker 1.12.5:

christoph@nelap:/home/docker_data$ sudo docker info
Containers: 9
 Running: 0
 Paused: 0
 Stopped: 9
Images: 276
Server Version: 1.12.5
Storage Driver: devicemapper
 Pool Name: docker-8:4-2883588-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: ext4
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 33.55 GB
 Data Space Total: 107.4 GB
 Data Space Available: 73.82 GB
 Metadata Space Used: 22.91 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.125 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /home/docker_data/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /home/docker_data/devicemapper/devicemapper/metadata
 Library Version: 1.02.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.0-2-amd64
Operating System: Debian GNU/Linux stretch/sid
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.666 GiB
<...>
Docker Root Dir: /home/docker_data
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8
christoph@nelap:/home/docker_data$

[gkgeorgiev]

@zaunerc, you are the man! Thanks for finding this docker option! I will try it next Monday.

Marry Christmas to all of you guys!

Update: I no longer get the error by modifying the /etc/default/docker by adding the following line

DOCKER_OPTS="--storage-opt=dm.basesize=20G"

@zaunerc , did it work for you? I came across another issue that I will report separately.

[zaunerc]

@gkgeorgiev: After increasing the size of the base device I could successfully build the image and start the container.

[gkgeorgiev]

How did you pass the basesize option? Was it the same way like me or you have another approach?

[zaunerc]

I created the file /etc/systemd/system/docker.service and added the following lines:

christoph@nelap:~$ cat /etc/systemd/system/docker.service 
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --storage-opt dm.basesize=25G 
christoph@nelap:~$

After reloading the systemd unit files and restarting the Docker daemon I verfied that the base device size has actually been increased:

christoph@nelap:~$ sudo docker info
<...>
Storage Driver: devicemapper
 Pool Name: docker-8:4-2883588-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 26.84 GB
<...>
christoph@nelap:~$

Finally I deleted all images and containers and rebuilt the Oracle 12c EE docker image. I did this to make sure that all images which are part of the Oracle Database 12c EE image build process are based on the increased base device size (see here for a more detailed explanation).

[gvenzl]

Glad to see that you managed to change the configuration and build the image. Note, Oracle recommends to use btrfs instead of the device mapper. As per the Oracle Linux Docker User's Guide (4.):

Oracle recommends using btrfs because of the stability and maturity of the technology. If a new device for btrfs is not available, you should use overlay as the storage driver instead of device-mapper for performance reasons. You can configure overlay by adding the --storage-driver=overlay option to DOCKER_STORAGE_OPTIONS in /etc/sysconfig/docker-storage. The overlayfs file system is available with UEK R4.

For more information, see https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/.