The only way I saw to provide the best of both worlds was to offer them by providing a small, stripped-down image and a big one with all the great bells and whistles of Oracle XE. More functionality means more libraries and files in the $ORACLE_HOME and that, in turn, means a bigger image. Sure, sometimes I want to be able to just quickly pull a small image to test a bunch of INSERTs, but I also want to be able to use, e.g., Oracle’s Spatial functionality. While I was at it, I thought of the many conversations that I had about the trade-off between image size and additional functionality. And about five months later, the outcome is yet another Docker Hub repository: Why a repository? So, on some Saturday, I sat down to “quickly” put together some new build files for XE, applying some of the lessons learned in the process. I too needed a quick and easy XE Docker image, yet Oracle’s Container Registry did not host an XE image yet (it does now, since about two weeks ago), and all images on Docker Hub that I could find were old 11g R2 XE ones. However, my own needs for some of my private projects such as #csv2db have also caused me to think about how to better streamline and integrate Oracle XE into my own pipelines. A lot of things have changed since then, and I’m happy that my engineering colleagues at Oracle have taken on the maintenance and further enhancements of Oracle’s official Docker build files and images, and integrated them into the internal processes. Pretty much ever since I put together the first official build scripts for Oracle Database, people have asked for faster image pull and startup times to speed up their continuous integration tests. One of the things that kept me busy lately was experimenting with how much an Oracle XE database setup could be streamlined inside a Docker image for things like CI/CD consumption.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |