Docker-images: 19.3 base docker image cannot be extended to support patching

Created on 18 May 2020  路  6Comments  路  Source: oracle/docker-images

  1. InstallDBBinaries.sh removes components from Oracle Home which are not needed after database software installation.
  2. If a developer wants to make use of the base docker image and extend it to create a patched (let's say 19.4 RU) image, it is not possible as many components are removed from the base docker image as part of the above mentioned cleanup.
  3. An argument must be exposed in the base dockerfile for the developer to choose if he wants to keep those components for future use while building the base image.

Most helpful comment

I think having a set of individual options ("ENABLE_APEX", "ENABLE_PATCHING") over a single option would be better so that end-users can truly customise the build to their particular needs.

All 6 comments

Why retain all the additional options though? If the goal is to allow patching, things like APEX are still not required. I would focus on retaining just the components required to support OPatch and create the flag of "ALLOW_PATCHING" or similar.

Agreed, but patching is not the only thing one might want to do. That is just one use-case that I listed here in this issue. There can be various operations one might want to do as part of docker build and each of them could have a dependency on different components. For every new operation, the user will have to come and request for a change and also introduce a new variable.

Additionally, finding the exhaustive list of components needed for patching is also not straight-forward. So, instead we thought if one wants to extend the image they can just make the exposed argument as false and remove these components at the end of docker build after doing the needed operations.

For the rest of the users, the image is still light as the default value will be true for the exposed argument.

I think having a set of individual options ("ENABLE_APEX", "ENABLE_PATCHING") over a single option would be better so that end-users can truly customise the build to their particular needs.

towards the end of the install of the oracle database, I think having removed the installer causes some diagnostics to fail, also, here is the install log:

INFO:  [May 26, 2020 1:00:02 AM] InstallProgressMonitor: Completed phase 64
INFO: Adding the iterator oracle.sysman.oii.oiic.OiicCloneAPISession$OiicAPISelCompsInstall
INFO: Adding the iterator oracle.sysman.oii.oiif.oiifw.OiifwInstExitWCDE
INFO: Since operation was successful, move the current OiicAPISessionDetails to installed list
INFO:  [May 26, 2020 1:00:02 AM] Number of root scripts to be executed = 2
INFO:  [May 26, 2020 1:00:02 AM] isSuccessfullInstallation: true
INFO:  [May 26, 2020 1:00:02 AM] isSuccessfullRemoteInstallation: true
INFO:  [May 26, 2020 1:00:02 AM] Adding ExitStatus SUCCESS to the exit status set
INFO:  [May 26, 2020 1:00:02 AM] Completed setting up Clone
WARNING:  [May 26, 2020 1:00:03 AM] Could not locate file: /opt/oracle/product/19c/dbhome_1/install/files.lst
INFO:  [May 26, 2020 1:00:04 AM] Executing [/opt/oracle/product/19c/dbhome_1/bin/diagsetup, clustercheck=false, basedir=/opt/oracle, oraclehome=/opt/oracle/product/19c/dbhome_1]
INFO:  [May 26, 2020 1:00:04 AM] Starting Output Reader Threads for process /opt/oracle/product/19c/dbhome_1/bin/diagsetup
WARNING:  [May 26, 2020 1:00:04 AM] /opt/oracle/product/19c/dbhome_1/bin/diagsetup: line 89: file: command not found
INFO:  [May 26, 2020 1:00:04 AM] The process /opt/oracle/product/19c/dbhome_1/bin/diagsetup exited with code 0

I had a chat with @Djelibeybi and explained the background to this PR/issue.

Was this page helpful?
0 / 5 - 0 ratings