Deploying a Container to Google Cloud

Having created the container, we now need to deploy it to the Google cloud. We create a deploy project. This was created for me, I believe from our Boilerplate Google Cloud Deployment project This project can currently only be viewed from within the University. The gitlab-ci.yml contained the following at the time of writing: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 # Use UIS deployment workflow, adding jobs based on the templates to deploy# synchronisation imagesinclude:- project:'uis/devops/continuous-delivery/ci-templates'file:'/auto-devops/deploy.

Building A Container with AutoDevops in GitLab

In the last post I set up a runner. Now lets see if we can use it to create a container. I am looking into how my colleagues at Cambridge do things. They have a handy guide to the Google cloud using what colleagues call click ops. When I ran through it I was given a project which already had an ID, so had to make sure I used the project ID I was given rather than the one in the document.

Gitlab Runner for Auto Devops

The Auto DevOps pipeline in GitLab is supposed to be magic! It just reads your mind and does whatever you wanted! At least that seems to be what the sales blurb says! Over the next few posts I will investigate how we use it. It is pretty clever, but we do need to set a couple of things first. Requirements This assumes docker is installed and working on the machine that will be used for the runner.

Oracle 19c Critical Patching

It is the time of year to apply critical patches. This time round we have some databases at version 19c. We tend to install a new oracle home for each patch, as we find this helps us manage the migration. It also reduces downtime, especially if you have not yet taken advantage of pluggable databases as we haven’t. Oracle Installer I notice from the documentation that there is an applyRU parameter that can be passed to the installer to apply the patch.

Change Assistant on Linux

Automating Tools Patches I have already automated the VM builds, so now I want to automate the application of the patch into the database. Oracle have done some work here with their Change Assistant tool, which once the database is set up can be used to apply the patch. Hopefully I can find a way to run change assistant from the Linux command line and apply the patch using the automated procedure.

Cloning a Pluggable Database using Unix commands

I read a lot about the flexibility of Oracle commands for pluggable databases. I haven’t seen as much about the old fashioned way to copy data files around and manually creating a control file. So lets see if that still works. I have a campus solutions demo instance, lets see if I can copy it and rename it. Back Up and Edit the Control File Running a familiar command is promising:

Java in the database

Why start using Java in the database? I have had a couple of situations recently where using Java in the database might come in handy. One is replacing a self-hosted database with one on the cloud. The provider gives access to the database, which means remote procedure calls don’t work - the provider doesn’t give access to the underlying OS, they provide the database as a service. This means the remote procedure call will have to be replaced in some way.

More Lessons About IO

I expect the question after the last I/O article is: How did we make our server go faster? Things That Did Work Looking at the AWR report, I could see the main problem was that async I/O was slow. We set 1 filesystemio_options='SETALL' in the spfile, and this helped a lot. As I understand it, this enables asynchronous I/O, which means that rather than waiting for confirmation after writing, the database keeps on sending data to the SAN.