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…

Video : Docker Compose – Defining Multi-Container Applications

In today’s video we’ll take a look at Docker Compose, which allows you to define multi-container applications. In this example we are using the Oracle REST Data Services and Oracle Database 19c images we built on Oracle Linux 8 (oraclelinux:8-slim) in previous videos.

For those that prefer to read, this is based on the following information.

The star of today’s video is Murali Vallath, who looks incredibly suspicious of my motivation for videoing him. πŸ™‚

Cheers

Tim…

Vagrant Build of AWX on Oracle Linux 7 Using Docker-Compose Method

I may need to do a bunch of scripting related to our load balancers, and I have the choice of using the API from the servers directly, Ansible Core or the web services exposed by AWX. I wanted to play around with AWX anyway, so that seemed like a good excuse…

First step was to install AWX. It’s pretty easy, but I must admit to spending a few minutes in a state of confusion until I rebooted my brain and started again. Turning things off and on always works. I’m an Oracle Linux person and “I do Docker”, so the obvious choice was to install it using the Docker-Compose method on Oracle Linux 7 (OL7).

The post includes the basic Docker setup, but if you need something a little more, check out the installation article and video.

If you don’t care about the build and just need AWX up quickly, you can use this Vagrant build that does everything for you, including Docker and AWX on Oracle Linux. πŸ™‚

Cheers

Tim…

Docker Birmingham – September

Yesterday evening I went to my first Docker Birmingham meetup, sponsored by Black Cat Technology Solutions.

I was so tired before the event I was really nervous I would fall asleep half way through a presentation and start snoring. πŸ™‚ When I got there I was greeted by an array of pizzas. I wanted to eat them so badly, but then I would definitely sleep, so I resisted. πŸ™‚ I spent a bit of time chatting to one of the hosts Shaun McLernon before the sessions started.

The agenda had a last minute change, as one of the speakers was ill, so the first presentation was a lighthearted one by Alistair Hey called “CV Driven Development – Why it’s ok not to be ‘cool’. ” He spoke about the things that trigger alarm bells when he’s looking at CVs, and used that as a segway into comparing what’s cool, with what just works. A specific case being a comparison between Kubernetes and AWS ECS, where he compared the pros and cons of each. The take home message was use the correct tool for the job, where the “correct tool” choice will be influenced by your requirements, skills and what works for your organisation.

Being short of a speaker, a couple of folks stepped up to talk about their projects in a lightning talk style. First up was Marcus Oaten with a talk about an environment built on Docker for testing new architectures for a Drupal application. Essentially using Docker to model all the services and layers to try new approaches out before having to commit to a specific architectural change.

Next up was Dan Webb speaking about the evolution of the builds used for a PHP environment he was working on. Moving from large-ish multi-purpose containers to smaller single-purpose containers with separation of duties and multi-stage builds.

I think the lightning talks worked really well. They triggered a lot of discussion, with people throwing out ideas.

The meetup was really useful. I like the “this is what we are doing” stuff, as it feels a lot more real, and shows the thought process and progression. I’m not sure about the experience level of the other folks, but I’m a Docker newbie, so this sort of thing is more important to me than hearing all about the super-cool stuff I will probably never use. I like hearing that as well, but this this stuff is more relevant to me at this stage.

I definitely plan to go again. Thanks to the folks at Black Cat Technology Solutions for sponsoring and organising the event, and to the speakers for stepping up to the plate.

Cheers

Tim…