These events start with food and I was looking longingly at the pizzas, but I know enough about myself to know it would make me sleepy, so I distanced myself from them until later.
First up was Richard Horridge with “A Brief History of Containers”. As the name suggests this was a history lesson, but it started much further back than most do when discussing this subject. With punched cards in fact. Fortunately I never had the “pleasure” of those, but I did find myself thinking, “Oh yeah, I’ve used that!”, about a bunch of stuff mentioned. That’s it. I’m now part of ancient history. I think it’s good for some of the younger folks to understand about the history of some of this stuff, and the difference in focus from the system administration focus of the past, to the application focus of the present.
Next up was Matt Todd with “Say Yes! To K8s and Docker”. Let me start by saying I like Swarm. It feels almost like a dirty statement these days, but I do. Matt started in pretty much the same way. He gave a quick pros vs. cons between Swarm and Kubernetes, then launched into the main body of the talk, which was trying to find a convenient way to learn about Kubernetes on your laptop without needing to install a separate hypervisor. So basically how to run Kubernetes in Docker. He did a comparison between the following.
K9s. He described as looking like htop for Kubernetes.
Of course, the obvious question was, “Why not Minikube?”, and that came down to his preference of not having to install another hypervisor. It was an interesting take on the subject, and mentioning Octant certainly got my attention.
So once again, I noobed my way through another event. Thanks to the speakers for taking their time to come and educate us, and to the sponsor Black Cat Technology Solutions for the venue, food and drinks. See you all soon!
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?
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.
Is it safe to talk about this now? The announcement has happened and Mike Dietrich has posted about it, so I think so…
A couple of massive things have happened regarding the multitenant architecture in Oracle 19c and 20c.
Prior to 19c, you were only allowed to have a single user-defined pluggable database (plus a root container and a proxy) without having to license the full multitenant option. I’ve been a big proponent of single-tennant or lone-PDB, but I can understand the reluctance of people to go that way, as it’s harder to realise the benefits, even though they do exist.
Oracle have now announced from 19c onward you can have 3 user-defined PDBs, without having the multitenant option. This is similar to what we got with 18c XE. As Mike points out, the documentation has already been changed to reflect this.
“For all offerings, if you are not licensed for Oracle Multitenant, then you may have up to 3 PDBs in a given container database at any time.”
This means your 20c upgrade will also include a migration to the multitenant architecture. What I would suggest is you start down that road today by moving to multitenant in 19c, then when you have to move to the next long term support release (2?c), you won’t be getting any surprises. What’s more, the 3 PDBs thing in 19c makes that all the more attractive!
If this announcement has made you panic, don’t worry. I’ve written a bunch of stuff about multitenant over the years, and there’s a YouTube playlist too.
Yesterday evening I went along to the Birmingham Digital & DevOps Meetup for the first time. It followed the usual meetup format of quick intro, talk, break, talk then home.
First up was Elton Stoneman from Docker with “Just What Is A “Service Mesh”, And If I Get One Will It Make Everything OK?” The session started by describing the problems associated with communication between the building blocks of a system, and how a service mesh can alleviate some of them. It then moved on to some service mesh demos using Istio. These included examples of altering the routing of traffic to do canary testing and targeting specific groups etc.
Elton was really honest about the learning curve, issues and overhead associated with this sort of setup. One comment I really liked was when he showed a slide containing the following, saying that often people assume there is a progression from left to right.
Meaning people assume you learn Docker, then you need some form of orchestration so you learn Swarm. From there you naturally progress to Kubernetes and once you understand that, you will inevitably move on to a service mesh using something like Istio. Elton’s point was you don’t *have to* continue on this progression. You can step off at any point once you’ve achieved the functionality you need. I think this is a really important point and I can see it reflected in what I do with Docker. We’ve got some things that stop at just using Docker containers, with no orchestration at all. I work on a project that requires some orchestration, so we use Swarm, which is really easy to use. So far I’ve had no reason to go beyond Swarm, and even considering a service mesh is so far down the line for us. I’m not discounting the relevance of these for everyone, but they don’t make sense for me at this point.
It was a really good session and I learned a lot. You can check out Elton’s blog here.
After the break it was James Relph with “Container Security Fundamentals”. This started of with a basic introduction to containers, using that as an entry point to explain how containers can be problematic from a security perspective, and what you can do to reduce the impact. He covered a lot of stuff, some of which I already do, some I know about and some stuff that was new to me. This is not an exhaustive list.
Don’t automatically trust images from Docker hub. Do your due diligence, even when they are from a reputable source.
Use your own image repository. He mentioned ECR amongst others. This can be used for your own images, but also base images from Docker Hub, which you have verified.
Don’t use “latest”, but use specific tagged versions. Latest gives you all the latest fixes, but all the latest bugs too. You should test and verify before you let images out into your infrastructure.
Multi-stage builds to reduce the size of containers and minimise the attack surface. Basically, copy out what you need and leave the crap behind.
Using sidecar containers to provide specific services, allowing your application images to remain more focused. The sidecar images can be maintained by feature experts to make sure they are as secure as possible.
Scanning images using Clair, amongst other things, to check for dodgy software. One of the audience mentioned Anchore.
Using microVMs like Firecracker to provide additional isolation, whilst retaining the ease of use of containers. I’ve not played with this, but I have tried Kata Containers, which seems to do pretty much the same.
There was a lot in there!
I was a bit nervous going into the event thinking it would all go over my head, and some of it probably did, but it was cool. I got to speak to a few people before the event, during the break and at the end. It seemed like there were quite a mix of people there from beginners in these areas upward, so I didn’t feel out of place.
A few times I found myself thinking, that’s great, but what do I do about my 3rd party applications? I’ve written before (here) about how 3rd party apps screw everything up. 🙂
There is a new feature listed in the docs as as “Support for PDBs with Different Character Sets, Time Zone File Versions, and Database Time Zones in a CDB”. I’ve already written about the PDB character set stuff and it is also listed separately as a new feature. The time zone stuff works in 12.1, so it doesn’t appear to be a 12.2 new feature. The different Time Zone File Versions functionality, as far as I can see, relates to OCI client connections to the server and was introduced in 11.2. With all that in mind, I’m really not sure what this listed new feature specifically relates to. If someone can clear that up for me I would be really grateful, as I’m wondering if I’ve just missed the point somewhere. 🙂
I’ve added these to the list of all my multitenant articles here.