Vagrant & Docker Builds : ORDS and SQLcl 20.3

In a previous post I discussed the recent release of APEX 20.2 and the subsequent builds it triggered. Last night I pulled down ORDS 20.3 and SQLcl 20.3, so I updated my Vagrant and Docker builds again.

The ORDS download page is here. At the time of writing, the SQLcl download page is still showing 20.2, but the SQL Developer download page has a link for the 20.3 SQLcl download at the bottom. Both these versions have been available for about a week. Update: It’s showing 20.3 on both SQLcl pages now. πŸ™‚

Vagrant

All my GitHub Vagrant builds that include ORDS and SQLcl have been updated to use version 20.3.

I had previously updated Tomcat, and a few days ago I updated Java as soon as AdoptOpenJDK was available.

Docker

This is pretty much the same as the Vagrant story.

The relevant GitHub Docker builds, like the ORDS containers, have been updated to include ORDS and SQLcl 20.3.

They are on the latest release of Tomcat and Java from AdoptOpenJDK.

Conclusion

As always, this is made simple using automation! πŸ™‚

Cheers

Tim…

Vagrant & Docker Builds : APEX 20.2 and other updates

The recent release of APEX 20.2 has triggered a build frenzy.

Vagrant

All my GitHub Vagrant builds that include APEX have been updated to APEX 20.2. The builds themselves are unchanged. This was literally an update to the environment files, so it took longer to test the builds than it did to make the changes.

While I was at it, I did a couple of extra updates. I updated Tomcat to version 9.0.39 on all relevant builds, and updated the optional patch script for the single instance database 19c on OL8 build to use the October 2020 bundle patch. The GI bundle isn’t available yet, so I’ve not altered the OL8 19c RAC build. That will happen soon.

Update: I’ve got the GI bundle patch now, and the OL8 19c RAC build has been updated to use it.

There will of course be more updates to the builds once we get the new versions of AdoptOpenJDK, ORDS and SQLcl, that are probably coming soon.

Packer

I mentioned in my VirtualBox 6.1.16 post I would be updating the oraclebase/oracle-7 and oraclebase/oracle-8 vagrant boxes to include the VirtualBox 6.1.16 guest additions. Those are done now.

Docker

This is pretty much the same as the Vagrant story.

The relevant GitHub Docker builds for Oracle database and ORDS containers have been updated to include APEX 20.2.

I’ve also added Tomcat 9.0.39 to the ORDS builds, and updated the optional patch script for the database 19c on OL8 build to use the October 2020 bundle patch.

Once again, more changes will appear as the new versions of AdoptOpenJDK, ORDS and SQLcl appear.

Conclusion

Automation is awesome! A few minutes and we are bang up to date!

Cheers

Tim…

Vagrant and Docker Builds : ORDS 20.2 and SQLcl 20.2 Updates

The recent Oracle REST Data Services (ORDS) 20.2 release prompted my usual reaction. I’ve gone through my Vagrant and Docker builds, and updated them to use ORDS 20.2 and SQLcl 20.2.

The Vagrant database builds, which include ORDS, can be found here.

The Docker ORDS builds can be found here.

There were also some small Tomcat mods.

  • Tomcat upgraded to 9.0.37.
  • HTTP/2 enabled.
  • Compression enabled.
  • Cache-Control enabled for images, CSS and Javascript.

All that went pretty well so as soon as I got to work yesterday I rolled ORDS 20.2 to all non-production environments, and a few “not yet production” environments. If you follow the blog you will know we use Docker for ORDS (similar to my Github builds). It makes rolling out a new version really simple. Just throw away all the containers and replace them with the spangly new ones.

If it’s looking OK after a few days we’ll push it out to the remaining production installations.

Cheers

Tim…

Video : Podman : Generate and Play Kubernetes YAML Files

Today’s video demonstrates Podman’s ability to generate and play Kubernetes YAML files.

This is based on the following article.

You can might want to check out these also.

The star of today’s video is Max McDonald, son of Connor McDonald.

Cheers

Tim…

Video : Using Podman With Existing Dockerfiles (Oracle Database and ORDS)

Today’s video shows me using some of my existing Docker builds with Podman. Specifically a 19c database container and an Oracle REST Data Services (ORDS) container.

For those with an understanding of Docker, it should look really familiar, but it does introduce a twist in the form of a pod.

The video is based on this article.

You can see more information about containers here.

The star of today’s video is Bart Sjerps. It was really hard to find a piece of this recording that didn’t have James Morle wittering over everyone on it. πŸ™‚

Cheers

Tim…

Oracle Linux 8 (OL8) : Podman

When Oracle Linux 8 (OL8) was released, one of the first things I did was check for the Oracle supplied Docker engine. Nothing.

Not to worry I thought. They are probably waiting for UEK6 to ship before they worry about the Docker engine. I pretty much left it at that. I wasn’t really in much of a rush. To be honest, a new version of Oracle Linux doesn’t really hit my radar until the Oracle database is certified on it. πŸ™‚

UEK6 went live in March and still no sign, so in a recent email exchange with Simon Coter I mentioned it, and was set on the path to Podman.

If I’m honest my first thought was, “Oh FFS! I’ve only just learnt Docker and now I’ve got to start again!” To qualify that, having used Oracle databases for 25 years, using Docker for about 2.5 years feels like I’ve only just started. πŸ™‚

First things first. We currently use Docker in production, so I wanted a route to OL8 without any substantial change, should I need it. So I did this.

It’s not a recommendation. Just something to keep in my back pocket.

After a quick bout of denial I sat down and started to work through some stuff with Podman. Time for a couple of quotes to set some context.

“What is Podman? Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode. Simply put: `alias docker=podman`.”

https://podman.io/

“The podmanbuildah, and skopeo container tools are provided in the Oracle Linux 8 release. These tools are compatible with the Open Container Initiative (OCI) and can be used to manage the same Linux containers that are produced and managed by Docker and other compatible container engines. Because these tools are light-weight and primarily focused on a subset of features, you can run them minus the overhead of working with a daemon process.”

Release Notes for Oracle Linux 8

After reading this, I was a little less daunted. I installed Podman on OL8 and started to play. That resulted in these posts.

The later is an example of how I run up my demo Docker system using Podman. It’s made up of a container for Oracle Database 19c, and a separate container running ORDS on Tomcat. You’ll notice I use my Docker builds with no changes. It just shows that from a basic usage perspective Podman=Docker.

A few quick things I noticed immediately when switching to Podman.

  • Networking is a little different. You define a pod to hold containers, and you expose services to the outside world at the Pod level. Containers inside the Pod can speak to each other. For the simple examples I’ve worked with is actually easier than using Docker networks.
  • There is a package called “podman-docker”, which allows you to use the Docker command, even though you are using Podman. I don’t really like this. I think it’s better to just stick to a regular alias if you feel the need to retain the Docker command. Better still, just get used to typing podman instead of docker.
  • There is no native equivalent of docker-compose. There is a podman-compose project you might want to try. Of course the name “Podman” gives you a clue about what you should really be doing. Defining pods. In addition to manually defining pods, they can get run from a YAML file that’s compatible with Kubernetes. You can generate these YAML files from an existing pod. I’ve not written up this aspect yet, but it’s coming. πŸ™‚

So far it’s been a pretty simple journey, but remember I’m a noob. The articles and my opinions on this will evolve over time.

A quick mention about Vagrant. When I am playing with Docker and Podman I use Vagrant to build a play VM. As a result of this stuff I’ve changed things around a little. If you look at my Vagrant respository you will see the old docker directory has gone and now we have these.

I’ve now pretty much ditched my OL7 Docker environment in favour of the OL8 Podman environment. The only way I’m really going to learn it is by forcing myself to use it. πŸ™‚

If anyone else is in the denial phase, I understand where you are at. Just get started. It’s not so bad. πŸ™‚

Cheers

Tim…

PS. I’ve not played with Buildah and Skopeo yet.

PPS. The image has no significance. It just looks good. πŸ™‚

APEX 20.1 : Vagrant and Docker Builds (and Some Comments)

About 2 days ago we saw the announcement of the release of APEX 20.1.

I normally set myself quite an aggressive timetable to get new APEX releases to production. So much of what we do lags behind the curve, to the point where I just want to see it burn, so when I get the opportunity to force the issue, like I do with APEX, I do.

In my typical fashion I move all my builds to the latest release and kind-of forget any prior release ever existed. As result, you will see all my Vagrant and Docker builds have been updated to use APEX 20.1, along with updates of OpenJDK and Tomcat.

The basic installation is the same as always (here), so there is no drama there.

Next week I’ll start upgrading a few of our development environments, and check everything looks OK. Assuming I hit no problems, it will be full steam ahead. Fingers crossed.

The new features are always a big draw for most people, but I tend to start by looking at the deprecated features and desupported features.

  • When I saw APEX_UTIL.STRING_TO_TABLE and APEX_UTIL.TABLE_TO_STRING had been deprecated I was about to lose my shit, then I saw they have just been relocated to the APEX_STRING package. Composure regained. πŸ™‚
  • The desupport of some of the productivity apps is a good thing. Some of them were not so good and having a long list of Meh, is not as good as a smaller list that offer something better. Just my opinion.

As far as the new features in the announcement, here are my initial (and uneducated) thoughts.

  • Redwood. I feel a little “Meh” about this. I don’t love it. I don’t hate it. I guess it makes sense to bring it in line with the current Oracle thang! πŸ™‚ I would have had a little more contrast on the icons. They look quite washed out, but I am not renowned for my design aesthetic. πŸ™‚
  • Faceted Search Enhancements. Love this! When I saw Mike Hichwa demonstrate the first iteration of this I had a When Harry Met Sally – Restaurant Scene moment in my head. All additional functionality is welcome. I think Faceted Search is a great and some might say killer feature.
  • Friendly URLs. My first reaction was, “Oh thank God!”. This was quickly followed by, “Oh my God!”. The thought of what some people will name their page aliases fills me with dread, but it is a welcome addition.
  • Native PDF Printing. Nice.
  • Mega Menus. Love it. The traditional side-bar menu is fine for little apps, but it’s a bit dated, takes up a lot of room and is nowhere near as flexible as this looks. I think I would have made it the default choice, but I can see why sticking with the old style is probably the safer option. πŸ™‚

There are a bunch of other things in the release notes that sound interesting, including remote application deployments using REST Enabled SQL, but I’ll leave you to discover those for yourself.

It’s early days, but this looks like a really nice release… Again…

Cheers

Tim…

Data Guard and RAC on Docker : Perhaps I was wrong?

I’ve talked a lot about Docker and containers over the last few years. With respect to the Oracle database on Docker, I’ve given my opinions in this article.

Over the weekend Sean Scott tweeted the following.

“A while back @oraclebase said Data Guard didn’t make sense on Docker.

For those of us disinterested in the sensible I present #Oracle#DataGuard on #Docker. 19c only for now. Please let me know what’s broken. Enjoy!

https://github.com/oraclesean/DataGuard-docker

This was in reference to a statement in my article that said the following.

“Oracle database high availability (HA) products are complicated, often involving the coordination of multiple machines/containers and multiple networks. Real Application Clusters (RAC) and Data Guard don’t make sense in the Docker world. In my opinion Oracle database HA is better done without Docker, but remember not every database has the same requirements.”

For the most part I stick by my statement, for the reasons described in my article. Although both Data Guard and RAC will work in Docker, I generally don’t think they make sense.

But…

A few years ago I had a conversation with Seth Miller, who was doing RAC in Docker. In his case it made sense for testing because of his use cases. I discussed this in this post.

For that use case, Seth was right and I was wrong.

What about Data Guard?

For a two node data guard playground I don’t see any major advantages to using two containers in one VM, compared to two VMs. The overhead of the extra VM and OS is not significant for this use case. Remember, most of the resources are going to the Oracle instances, not the VM and OS. Also, the VM approach will give you something similar to what you will see in production. It feels like a more natural testing scenario to me.

But Sean’s scenario was not this simple. When I questioned him over the value of this, considering the two VM approach had so little extra overhead, he came back with the following.

“There I’ll disagree. I have a Docker/sharding build I’m working on. 7 databases. Starts in moments. On my laptop. I can’t do 7 VM. No way!”

Now this scenario changes the game significantly. All of a sudden we go from the overhead of one extra VM to an overhead of six extra VMs. That’s pretty significant on a laptop. All of a sudden the Docker method probably makes a lot more sense than the VM approach for testing that scenario on a laptop.

Once again, I’m wrong and Sean is correct for this use case.

Conclusion

If you are building a two node RAC or Data Guard playground, I still think the VM approach makes a lot more sense. It’s going to be a lot more like what you use at work, and you don’t have to deal with some of the issues that containers bring with them.

Having said that, if you are looking to build something more extreme, or you are just trying stuff for fun, then Docker may be the right solution for you.

I still don’t see a realistic future for an RDBMS monolith on containers. I don’t care if it’s a single container or a giant Kubernetes cluster. This is not a criticism of the RDBMS or of containers. They are just things from different worlds for different purposes and continuing to treat them differently seems totally fine to me. Having said all that, it doesn’t mean combining the two can’t be useful for some use cases.

Remember, this is just my opinion! πŸ™‚

Cheers

Tim…

PS. As a general point, trying to build your own data service on containers feels like a mistake. I would just use a cloud service that gives you the features, performance and availability you need. Concentrate on your apps.

Oracle REST Data Services (ORDS) 19.4 : A quick life update…

Almost 2 weeks ago I wrote about the release of Oracle REST Data Services (ORDS), SQLcl, SQL Developer and SQL Developer Data Modeler 19.4.

I spent the holidays playing around with ORDS quite a bit, so I came back to work today and pushed it out across all Dev and Test installations.

As I’ve mentioned before, at work we run ORDS on Tomcat inside Docker containers. The build we use is very similar to this one I put on GitHub, but with some extra work-related bits added.

What did I have to do for this update?

Two things:

  • Build a new version of our ORDS Docker image with version 19.4 of the ORDS and SQLcl software.
  • Remove all the containers based on this image and fire up new containers.

How long did it take to deploy this to all Dev and Test instances?

The build of the new Docker image took about 5 minutes. It’s mostly just unzipping the software. This can be done before we touch any running containers, so there is no downtime associated with this.

The removal and creation of all the containers took about 5 minutes as well. Each container is created in a second, but the first run with a new version of ORDS has to do the ORDS upgrade in the database, which takes a few minutes sometimes. If there were no ORDS upgrade, the containers start really quickly.

So effectively, in 5 minutes we replaced all the “kit” and ran the ORDS upgrade across everything. I could have done production in that same 5 minute span too, but I’m not allowed to yet. πŸ™‚

Why am I talking about this?

It’s just another example of why containers make more sense than conventional app servers for this type of stuff.

To throw away kit and rebuild it from scratch takes an eternity here. I can do the equivalent with containers in seconds.

Once I’ve tested a new image and proved it works, I can roll that same image out across everything with no worries. If it works against one database, it will work against all the others. That’s the great thing about standardising the approach you take!

And another thing!

I’ve enabled SQL Developer Web on every Dev/Test installation too. Now all I’ve got to do is wait for the right opportunity to use it to save the day when someone is waiting for a firewall change, and act all casual like it’s no big thing! πŸ™‚

So in summary

Containers good! ORDS good!

If you are interested in playing with Docker, you can find more information here.

If you want to learn about ORDS, you can find more information here.

Cheers

Tim…

APEX 19.2 : Vagrant and Docker Builds

I’m sure anyone who cares knows that APEX 19.2 was officially released on Friday. I did an upgrade of one of our development instances straight away and it worked fine. it’s subsequently gone to a bunch of other development instances. I’ll be pushing to get this out to production as quickly as possible.

Over the weekend I worked through a bunch of my GitHub stuff.

Vagrant : I’ve updated all my Vagrant builds to use APEX 19.2 and the latest versions of Tomcat 9 and OpenJDK 11. I was using newer versions of OpenJDK, but it seemed a bit silly, so I reverted back to the long term support release. I tried updating the base box to ‘bento/oracle-7.7’, but it kept giving me timeouts, so I’ve reverted back to ‘bento/oracle-7.6’ for the moment.

Docker : Same as above, I’ve updated all my Docker builds to use APEX 19.2 and the latest versions of Tomcat 9 and OpenJDK 11. I noticed oraclelinux:8-slim was behaving a little strangely. I thought it was a PATH issue, but I need to spend some time to understand what is happening. It seems you can’t run basic commands like dnf during the build phase. It’s probably something stupid I’m doing, but for now I’ve switched from oraclelinux:8-slim to oraclelinux:8. Just making that switch made everything work as expected.

My Docker builds within the company have gone through a similar process, so as I’m rolling out APEX 19.2 to the databases, I’m also switching the ORDS containers over to the new images. You gotta love containers!

I guess I’ll be working through all this again when the next version of ORDS and SQLcl drop. πŸ™‚

Cheers

Tim…