Docker and PDB discussion
This blog-entry will serve as my note-taking and explanation-texts for a Docker discussion that started on Twitter on 30Mar2018.
Topic: Docker and PDBs
Questions:
Here are the key questions I want to ask "everybody", before we dive into discussion:
Q1: What kind of use-cases are developing out there for Oracle on Docker ?
Q2: What do you (all) want to do with OracleDB running from a Docker-container?
Q3: (Gerald?) What is the direction that Oracle wants to take with 18.x and PDBs on docker ?
More detailed questions tend to follow, but ... Later!
I am interested in your answers to Q1/Q2 before we start the detailed discussions, mainly to prevent my own "tunnel vision". I realise that Others have often very different views of products and possibilities. So let's hear it from you!
----- Space for Pause and Reflexion -------
Popssible agenda for discussion:
- open for suggestions...
- me: Use Docker to deploy Oracle-DB software, and plug various PDBs in/out.
(add your suggestions here...)
Docker:
- Simple to deploy, clone-able.
- Runs nearly anywhere.
- Disposable containers, e.g. Cattle, stateless.
(add your items/suggestions.... )
Databases, and PDBs:
- Storage of data (ACID), e.g. Pet, Stateful.
- Application code-base in PL/SQL or similar (#SmartDB).
- PDBs: Easy (re)start of dev sandboxes (including app-code in PL/SQL).
- PDBs: Clone from prod/acc/test/pristine environments.
(add your items/suggestions)
Wishlist for OracleDB on Docker:
- A quick-deploy method to many platforms (that it is already!)
- A guaranteed, known, software version (e.g. known version + patches)
- Image as light (small) as possible.
- Complicated: Patching, First on a "golden" image (per project?), then distributed.
Background:
Gerald Venzl (link) has provided and published Docker Images (link) that can run an Oracle Database. There are also a range of other Oracle-provided containers that allow "devs" to play with various oracle tools, and I'm sure everyone is discovering various ways to use Docker.
In another universe someone (link to jk) even complained that Containers were used for "production databases". I'm really curious to see how+where+when that works, notably if the data is stored persistently, ACIDly, and how the additional layer from container-to-storage is affecting the running and performance.
Storage, persistence:
I can see two distinct cases, your choice will depend on circumstances:
- Data inside the container, and disposable. You can lose the data at some (unexpected?) point.
- Data on mapped volumes, and Persistent. You have more control over the data.
In my case:
- Disposable "sandboxes : can be in the container. But any plug/in/out may have to be done over DB-links, cumbersome.
- Persistent data: mappable (host-)Volumes. Easy to reach, similar to NFS concept with pros/cons.
Notable items for Docker, from my memory/history:
- Avoid splitting the database over "container" and "volumes".
- Keep the spfiles and orapwfiles with the data (linked into the dbconfig in 12.2, nice!)
- Also map diag-directory, prevent container-storage from filling up (was easy)
- Detail: add a "vi" to the container. I had to yum it in.
- Make perl catcon.pl work correctly or use bash. (I like CreateDB, not just dbca...)
( - add your items here...)
My own agenda (if any) is to have the OracleDB software in an easy-deploy, run-anywhere container, with the option to keep the data "external" and to plug-in PDBs at will.
My "containers" resemble old-fashioned VMs. Not sure if that is "correct way"
My deployed-container will be my "processing unit" and my "service".
The docker-host will provide storage as mappable volumes.
The concept I would use would resemble a set of linux-servers with an NFS for filesystem.
Side-topics, optional, later:
- Anything Oracle can do to concentrate all "output files" to a small number of mountpoints is welcome. I used to spend time putting spfile, ctlfiles, redo, data, archives, log/diag all in 1 subdir-tree to allow easy movement of databases between systems. Gerald has mentioned FSH already: that was a good concept on unix once. All output to a "/var" subdir.
- Anything Oracle can do to make (un)plug of containers easier: Welcome. I would like a PDB to be even more simple transportable from 1 subdir, including all files needed (oracle is close!). In another DB, all you do is provide some name, or point 1 (one) environment variable $QHDATA to 1 (one) subdir, and the whole DB materializes under it... Neat! No messing with "file-name-convert" or GUID/random strings. Easy, Flexible!
Open for Discussion... (on twitter?)
Copies of Relevant links:
Gerald : https://geraldonit.com/2017/08/21/creating-an-oracle-database-docker-image/
docker images : https://github.com/oracle/docker-images/tree/master/OracleDatabase
The tweet that started it. https://twitter.com/GeraldVenzl/status/979736165564661760
Topic: Docker and PDBs
Questions:
Here are the key questions I want to ask "everybody", before we dive into discussion:
Q1: What kind of use-cases are developing out there for Oracle on Docker ?
Q2: What do you (all) want to do with OracleDB running from a Docker-container?
Q3: (Gerald?) What is the direction that Oracle wants to take with 18.x and PDBs on docker ?
More detailed questions tend to follow, but ... Later!
I am interested in your answers to Q1/Q2 before we start the detailed discussions, mainly to prevent my own "tunnel vision". I realise that Others have often very different views of products and possibilities. So let's hear it from you!
----- Space for Pause and Reflexion -------
Popssible agenda for discussion:
- open for suggestions...
- me: Use Docker to deploy Oracle-DB software, and plug various PDBs in/out.
(add your suggestions here...)
Docker:
- Simple to deploy, clone-able.
- Runs nearly anywhere.
- Disposable containers, e.g. Cattle, stateless.
(add your items/suggestions.... )
Databases, and PDBs:
- Storage of data (ACID), e.g. Pet, Stateful.
- Application code-base in PL/SQL or similar (#SmartDB).
- PDBs: Easy (re)start of dev sandboxes (including app-code in PL/SQL).
- PDBs: Clone from prod/acc/test/pristine environments.
(add your items/suggestions)
Wishlist for OracleDB on Docker:
- A quick-deploy method to many platforms (that it is already!)
- A guaranteed, known, software version (e.g. known version + patches)
- Image as light (small) as possible.
- Complicated: Patching, First on a "golden" image (per project?), then distributed.
- Nice-to-have: when oracle18 is out: Read-Only OH.
- Clear choice of data: "in" or "outside" of the container (mappable volumes).
- Clear choice of data: "in" or "outside" of the container (mappable volumes).
(add your items here...)
Background:
Gerald Venzl (link) has provided and published Docker Images (link) that can run an Oracle Database. There are also a range of other Oracle-provided containers that allow "devs" to play with various oracle tools, and I'm sure everyone is discovering various ways to use Docker.
In another universe someone (link to jk) even complained that Containers were used for "production databases". I'm really curious to see how+where+when that works, notably if the data is stored persistently, ACIDly, and how the additional layer from container-to-storage is affecting the running and performance.
Storage, persistence:
I can see two distinct cases, your choice will depend on circumstances:
- Data inside the container, and disposable. You can lose the data at some (unexpected?) point.
- Data on mapped volumes, and Persistent. You have more control over the data.
In my case:
- Disposable "sandboxes : can be in the container. But any plug/in/out may have to be done over DB-links, cumbersome.
- Persistent data: mappable (host-)Volumes. Easy to reach, similar to NFS concept with pros/cons.
Notable items for Docker, from my memory/history:
- Avoid splitting the database over "container" and "volumes".
- Keep the spfiles and orapwfiles with the data (linked into the dbconfig in 12.2, nice!)
- Also map diag-directory, prevent container-storage from filling up (was easy)
- Detail: add a "vi" to the container. I had to yum it in.
- Make perl catcon.pl work correctly or use bash. (I like CreateDB, not just dbca...)
( - add your items here...)
My own agenda (if any) is to have the OracleDB software in an easy-deploy, run-anywhere container, with the option to keep the data "external" and to plug-in PDBs at will.
My "containers" resemble old-fashioned VMs. Not sure if that is "correct way"
My deployed-container will be my "processing unit" and my "service".
The docker-host will provide storage as mappable volumes.
The concept I would use would resemble a set of linux-servers with an NFS for filesystem.
Side-topics, optional, later:
- Anything Oracle can do to concentrate all "output files" to a small number of mountpoints is welcome. I used to spend time putting spfile, ctlfiles, redo, data, archives, log/diag all in 1 subdir-tree to allow easy movement of databases between systems. Gerald has mentioned FSH already: that was a good concept on unix once. All output to a "/var" subdir.
- Anything Oracle can do to make (un)plug of containers easier: Welcome. I would like a PDB to be even more simple transportable from 1 subdir, including all files needed (oracle is close!). In another DB, all you do is provide some name, or point 1 (one) environment variable $QHDATA to 1 (one) subdir, and the whole DB materializes under it... Neat! No messing with "file-name-convert" or GUID/random strings. Easy, Flexible!
Open for Discussion... (on twitter?)
Copies of Relevant links:
Gerald : https://geraldonit.com/2017/08/21/creating-an-oracle-database-docker-image/
docker images : https://github.com/oracle/docker-images/tree/master/OracleDatabase
The tweet that started it. https://twitter.com/GeraldVenzl/status/979736165564661760
No comments:
Post a Comment