It's quite vague your description of what changes you did.
First it looks like that registry only has OBIEE 184.108.40.206 and error correction support for that version ended April 2019. Weird that Oracle doesn't have a 220.127.116.11 image if that was a really officially supported registry ...
Keep in mind that the image is probable in a state before configuration, while your container is already fully configured. This make it impossible to "clone" and replicate multiple times as they would all share the same RCU schemas and that's not how multiple OBIEE instances works: 1 OBIEE = 1 RCU schema!
Therefore your changes either needs to be done into a docker image, which you can base on the one you got from the registry and you than extend as you want. Or they needs to be all packaged into a script you could deploy on new containers based on the reference image and executed to bring in your changes.
thanks for your reply.
So it will be like do standard intsallation of obiee and do all configurations like security, skins..etc
Now, we can write dockerfile and with help of shell scripts we build docker image.
I think we can use oracle GIT repository script & docker files for starting of it.
Sir, few more clariifications:
1) Once docker image is deployed in production as container. In future there are some fixes and want to push to existing docker prod container. How do we handle this situation?
2) Normally who will be taking care of building image (like writing required scripts/docker files.etc), OBIEE admin/deploymen team?
I have a docker image which deploy a custom style on top of OBIEE, and those are definitely tasks which needs to be performed after OBIEE is configured and therefore inside the container. The image simple take care of knowing it must do something.
In case you want an alternative image you can also have a look at https://github.com/gianniceresa/docker-images/tree/master/OracleBIEE , standard OBIEE silent installs.
Ideally what you want to achieve is what Oracle added to some of their database docker images: https://github.com/oracle/docker-images/blob/master/OracleDatabase/SingleInstance/README.md#running-scripts-after-setup-…
They added some hooks in the scripts allowing the container to execute all the scripts it find in a specific folder. They have one which is execute after every start up of the database, and one which is execute after the configuration of the database (so only once in the life of a container).
Just keep in mind that your scripts must not be executed while building the image but (almost) all of them require OBIEE to be configured, so you need to hook them into the running script to call them after configuration.
Once docker image is deployed in production as container.
Triple check with Oracle you will have support for OBIEE in production in Docker. I would never run OBIEE in Docker in prod just because OBIEE inside Docker is not really a natural match. Dev / Test all good, Prod I would still have a written confirmation Oracle support it!
The lifecycle management of OBIEE in Docker doesn't follow any fixed rule, it's a bit just like for a physical server or a VM: you need to define the process based on your rules, tools and standard way of doing things.
For any "fix" on the tool (so OBIEE and not user generated content) I would probably create an updated image, for example one with a bundle patch applied, and migrate the user generated content to it. I don't see a single docker container as an object which needs to have a long life, but more like a disposable resource. This obviously requires you to have processes in place handling deployment of user generated content and backups etc. (BAR files?)
Who is supposed to write the scripts? The same who were in charge of installing and scripting OBIEE in physical servers or VM: it's more about knowing OBIEE than knowing Docker, so pick somebody knowing what they are doing