In a previous post I show you how you can integrate DevOps automation and orchestration tools to provision Oracle databases by leveraging Enterprise Manager (EM) and the Cloud Management Pack (CMP). Once provisioned, databases need to be fully maintained in terms of monitoring but most precisely patching.
Patching databases decreases the risk of breach by timely mitigating vulnerabilities, but in can be a daunting task for organizations. Manual patching is time consuming and error prone. Home grown scripts are difficult to maintain and they increase maintenance cost. So the question is, how can I automate the patching process and even better, how can I integrate it with my current orchestration workflow?
Let me explain how you can achieve all this by making use of Oracle’s Database Lifecycle Management Pack (DBLM) and CMP. DBLM’s Fleet Maintenance help us patch and upgrade Oracle databases at scale with minimum downtime. It makes use of Gold Images and out-of-place patching in order to achieve this.
Fleet Maintenance Benefits
All this functionality can be integrated with CMP’s DBaaS in order to provide and end-to-end automation solution. DBaaS exposes REST APIs that we could then call using the automation tool of choice. Database Administrators, end users or 3rd party tools can then use these features to patch Oracle databases.
DBaaS Automation Diagram
Do you want to learn more about this and even be able to try it? We’ve created an Oracle LiveLabs that cover’s all this functionality. This lab will guide you through the request of a PDB, setup DBaaS configuration, setup Fleet Maintenance and finally patch the PDB.
Follow the link below for the Oracle LiveLabs workshop.
In this post I want to show you how Oracle Enterprise Manager 13c using the Cloud Management pack, can be easily integrated with DevOps automation and orchestration tools like Ansible in order to provision Oracle Databases.
These can be either single instance, multi-tenant container databases, pluggable databases, schemas or databases running on high availability clusters and Dataguard configurations. EM 13c implements pre-checks, best practices and processes to provision all these configurations in a secure, automated and controlled fashion.
We have created an step by step laboratory in the Oracle LiveLabs framework. This lab contains a demo environment and a workbook that guide through all the steps. This lab shows you how to provision a PDB using Ansible and Oracle Enterprise Manager 13c. It also shows you how to shutdown, start, resize and check the status of the PDB using Ansible.
With this kind of integration, enterprises can close the loop in terms of DevOps or CI/CD pipeline provisioning. They can provision the Virtual Machines, Application and Oracle Databases automatically.
Follow the link below for the Oracle LiveLabs demo.
As IT moves towards virtualization, cloud and hybrid environments, containers, agile developments, etc. Automation and orchestration tools are gaining popularity to build and deliver environments faster and efficiently.
In this post, I want to show how Oracle Enterprise Manager (EM) interacts with 3rd party tools and how this can be used to integrate EM’s functionality with DevOps tools like Ansible or Terraform for configuration management and automation.
Oracle Enterprise Manager (EM) offers a complete tool-set for monitoring, provisioning, upgrade and patching, consolidation, compliance, DBaaS, etc., for the Oracle Database. Oracle Enterprise Manager makes use of Plug-ins and managements packs in order to discover, monitor and manage targets. EM’s functionality can be further extended with connectors and the EM’s extensibility framework in order to interact with 3rd party tools.
You can interact with Oracle Enterprise Manager (EM) in several ways:
Oracle Enterprise Manager Console
Oracle Enterprise Manager Command Line Interface (EMCLI)
Management Repository Views
Web Service REST APIs
Executing SQL via REST APIs (13.4 only)
We can leverage all the EMCLI commands and REST API’s that Oracle EM exposes with tools like Ansible or Terraform for a complete automation and orchestration solution.
One of the requirements for Oracle EM to monitor and manage a target is to deploy an Oracle Management Agent (OMA) to the machine hosting the target. Many organizations use DevOps tools to deploy virtual machines in an automated fashion. We can integrate the Oracle EM’s agent deployment process with these tools. This helps to drive consistency and reduces the efforts and time that administrators spend deploying Oracle Management Agents.
Let’s deploy an OMA to a Linux host using Ansible and Oracle’s EMCLI interface.
First of all, I need to download and install Ansible in a test server. My test server is a small virtual machine running Oracle Linux 7.
Ansible is now installed in the test machine. The Ansible installion will create a directory under “/etc” that contains the configuration, host inventory and roles.
[root@ansible-s02 ~]# cd /etc/ansible/
[root@ansible-s02 ansible]# ls
ansible.cfg hosts roles
Our next step is to edit the host inventory file and add both, our Oracle EM server and the machine where we want to deploy the OMA into. This will look similar to my configuration file below.
# This is the default ansible 'hosts' file.
#
# It should live in /etc/ansible/hosts
#
# - Comments begin with the '#' character
# - Blank lines are ignored
# - Groups of hosts are delimited by [header] elements
# - You can enter hostnames or ip addresses
# - A hostname/ip can be a member of multiple groups
# Ex 1: Ungrouped hosts, specify before any group headers.
## green.example.com
## blue.example.com
## 192.168.100.1
## 192.168.100.10
# Ex 2: A collection of hosts belonging to the 'webservers' group
## [webservers]
## alpha.example.org
## beta.example.org
## 192.168.1.100
## 192.168.1.110
# If you have multiple hosts following a pattern you can specify
# them like this:
## www[001:006].example.com
# Ex 3: A collection of database servers in the 'dbservers' group
## [dbservers]
##
## db01.intranet.mydomain.net
## db02.intranet.mydomain.net
## 10.25.1.56
## 10.25.1.57
# Here's another example of host ranges, this time there are no
# leading 0s:
## db-[99:101]-node.example.com
[local]
127.0.0.1
[emserver]
10.0.0.28
[emtarget]
10.0.0.11
I also configured a password-less SSH connectivity between the Ansible test machine and both, the EM’s server and the server where I want to deploy the OMA into. After this, I’m going to verify the connectivity from Ansible to both servers.
[root@ansible-s02 ansible]# ansible emserver -m ping -u oracle
[WARNING]: Platform linux on host 10.0.0.28 is using the discovered Python
interpreter at /usr/bin/python, but future installation of another Python
interpreter could change this. See https://docs.ansible.com/ansible/2.8/referen
ce_appendices/interpreter_discovery.html for more information.
10.0.0.28 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
[root@ansible-s02 ansible]# ansible emtarget -m ping -u oracle
[WARNING]: Platform linux on host 10.0.0.11 is using the discovered Python
interpreter at /usr/bin/python, but future installation of another Python
interpreter could change this. See https://docs.ansible.com/ansible/2.8/referen
ce_appendices/interpreter_discovery.html for more information.
10.0.0.11 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
I see the SUCCESS flag on both of them. Now is time to develop my .yml file with all the necessary steps to deploy the OMA to the host.
Let’s pause for a minute and review all the available options to deploy an OMA to servers. The list below show’s these options:
Oracle Enterprise Manager Console
Oracle Enterprise Manager Command Line Interface (EMCLI)
Now let’s verify our agent deployment. I’m going to login to the Oracle Enterprise Manager Console and I should be able to see the details of the deployment.
Here you go! The OMA was successfully deployed to my target host. I now need to manually execute the “root.sh” script, this because I didn’t specify a privileged credential during the deployment.
Hope this helps to demonstrate the flexibility of Oracle’s EM and also as an example on how to integrate it’s functionality with DevOps tools like Ansible. This is not by any means the best way to deploy an agent for your particular environment but rather an example of how to integrate EM with Ansible.
