Oracle Fusion Middleware RCU στο Amazon cloud (AWS)

To AWS προσφέρει την υποστήριξη της Oracle Database (Oracle RDS) με παρεχόμενες άδειες και με ειδικά γνωρίσματα όπως:

• δίνεται λογαριασμός με DBA privileges αλλά δεν παρέχεται πρόσβαση στα SYS και SYSTEM accounts
• δεν προσφέρεται SSH πρόσβαση στους database servers
  
• υποστηρίζονται μόνο Oracle Managed Files (OMF) για datafiles

Περισσότερες πληροφορίες εδώ και εδώ.

Μέσω του Ansible, όταν έτρεξα το RCU για ένα 12.2.1.1.0 domain διόρθωσα ώστε το script ώστε ο database user να μην έχει SYSDBA δικαιώματα (normal user), αλλά πήρα το ακόλουθο λάθος ORA-20900: RDS only supports Oracle Managed Files.

Έχουμε δυο επιλογές:

• στο RCU script μας παιρνάμε την παράμετρο honorOMF που κατασκευάζει τα datafiles συμβατά με OMF
• κατασκευάζουμε τα tablespaces μόνοι μας και ξανατρέχουμε το RCU

Πέρα από αυτό, δεν αντιμετώπισα κανένα άλλο πρόβλημα στο να τρέξω μια 12.2.1.1.0 ADF εφαρμογή στο AWS χρησιμοποιώντας είτε Oracle RDS 11.2.0.4 είτε το 12.1.0.2.

Πώς να τρέξουμε Ansible scripts από Windows

Το Ansible απέχει μόλις μια εντολή από το να τρέχει σε ένα Linux control machine (πχ sudo apt-get install ansible στην περίπτωση του Ubuntu) Το ίδιο όμως δεν ισχύει στα Windows, ώστε εκεί να κατασκευάζουμε και να τρέχουμε τα Ansible scripts μας. Πέρα από την λύση ενός Linux guest virtual machine, υπάρχει μια ακόμα: το να τρέξουμε το Gygwin, που μας επιτρέπει να κάνουμε compile Linux εφαρμογές στα Windows, και μέσα σε αυτό να κάνουμε build το Ansible.

Το πιο απλό και πλήρες πακετάρισμα του Gygwin για Windows είναι το babun. Αναλυτικές πληροφορίες για το πώς να εγκαταστήσουμε το Ansible βρίσκονται εδώ. Επί της ουσίας θα :

• Κάνουμε εγκατάσταση του Ansible μέσω της εντολής: curl https://raw.githubusercontent.com/chrisgilbert/scripts/master/bootstrap_ansible_windows.sh | bash
  
• Ακολουθεί το rebase του Gygwin
• Κάνουμε compile και install το sshpass

Όλα τα παραπάνω βήματα έχουν ελεγχθεί σε Windows 10 64-bit.

Ξεκινώντας με το Activiti BPM στο Ubuntu

To Activiti BPM αποτελεί μια ελαφριά αλλά και ισχυρή υλοποίηση του BPMN 2.0. Η πλατφόρμα αποτελεί έργο ανοικτού κώδικα (open source) και βασίζεται στην Java . Σαν δομικές αρχές έχει:

• την απλότητα στην κατασκευή και στην πρόσβαση στην πλατφόρμα, προσφέροντας Java και REST APIs
  
• την εύκολη και ευέλικτη πακετοποίηση του, ακόμα και ως τμήμα μιας JEE εφαρμογής (WAR, EAR)
• τον άμεσο έλεγχο μιας BPMN διαδικασίας με testing frameworks όπως για παράδειγμα το JUnit.

Η γραφική απεικόνιση ενός BPMN 2.0 process μπορεί να γίνει στο Eclipse με την βοήθεια ενός ειδικού plugin, ενώ έτοιμες εφαρμογές για τα REST APIs και τον Activiti Explorer (αντίστοιχο του Oracle BPM workspace) προσφέρονται εδώ. Σε αυτό το άρθρο θα περιγραφούν αυτές οι δυο διαστάσεις: η σχεδιαστική μέσω του Eclipse και η runtime σε έναν Tomcat 7 Server. Για όλα αυτά θα χρησιμοποιηθεί το Ubuntu 14.04 (LTS) ως πλατφόρμα ανάπτυξης ώστε σε λιγότερο από 20 λεπτά να έχουμε ένα λειτουργικό περιβάλλον για τα workflows μας.

Αν και μπορούμε να κατεβάσουμε αυτόνομα το Eclipse για να λειτουργήσει στο Ubuntu, μια άλλη προσέγγιση είναι να χρησιμοποιήσουμε το bundled command-line tool "Ubuntu Make" που αποτελεί ένα repository για τα development tools όπως Eclipse, Android Studio, Visual Studio Code, κ.α. Αφού λοιπόν εγκαταστήσουμε το Ubuntu Make με τις εντολές:

$ sudo add-apt-repository ppa:ubuntu-desktop/ubuntu-make
$ sudo apt-get update
$ sudo apt-get install ubuntu-make

Τότε, μπορούμε να εγκαταστήσουμε και το Eclipse με την εντολή umake ide eclipse, που θα μας ζητήσει τον κατάλογο προορισμού και τελικά θα εγκαταστήσει το προϊόν.

Η έκδοση του Eclipse είναι η Luna (4.4.2) και σε αυτήν θα χρειαστεί να προσθέσουμε το Activiti plugin καθώς και ένα Maven plugin. Μετά από όλα αυτά, είμαστε έτοιμοι να σχεδιάσουμε αλλά και να κάνουμε unit test σε μια BPMN διαδικασία, έχοντας ως οδηγό το αναλυτικό Activiti User Guide.

Για το deployment σε έναν Java server, όπως για παράδειγμα τον Tomcat, μπορούμε να έχουμε μια ειδικού σκοπού virtual machine είτε μέσω Docker (όπου μπορούμε να δανειστούμε έτοιμα images για Tomcat 7) είτε να φτιάξουμε ένα δικό μας. Μιας και προτιμώ το lxc, η δημιουργία ενός Ubuntu container είναι θέμα δευτερολέπτων με την εντολή:

$ sudo lxc-create -t ubuntu -n tomcat

Ξεκινώντας τον container μας, έχουμε ήδη ssh δυνατότητες οπότε μπορούμε να εκμεταλλευτούμε το Ansible για να τρέξουμε την εγκατάσταση του Tomcat με έναν αυτοματοποιημένο και επαναχρησιμοποιήσιμο τρόπο:

To μόνο πια που απομένει είναι να μεταφέρουμε τα WARs activiti-explorer.war, activiti-rest.war του Activiti distribution στον κατάλογο /var/lib/tomcat7/webapps και να δούμε τις sample BPMN διαδικασίες ή να κάνουμε deploy και τις δικές μας.

Patching του Weblogic με την βοήθεια του Ansible

To Ansible είναι από τα εργαλεία αυτοματισμού που με απλό και δομημένο τρόπο λύνουν τα χέρια των DevOps και γλυτώνουν κυριολεκτικά πάρα πολλές ώρες επαναλαμβανόμενων εργασιών. Ως προς τα προϊόντα της Oracle θαυμάσιες πηγές παραδειγμάτων Ansible είναι για την Oracle Database (και το RAC) το oravirt, ενώ για το μεσαίο επίπεδο το Middleware Snippets. H πρόσφατη μάλιστα εξαγορά του από την RedHat αναμένεται να δώσει ακόμα μεγαλύτερη ώθηση στο προϊόν.

Σε αυτό το άρθρο θα ήθελα να δώσω ένα παράδειγμα patching του Weblogic με την χρήση του Ansible. Για να κάνουμε τα πράγματα πιο δύσκολα, παλαιότερες εκδόσεις του Weblogic χρησιμοποιούσαν για αυτήν την δουλειά το Smart Update (bsu) ενώ νεότερες εκδόσεις (συμπεριλαμβανομένης και της 12c) το opatch. Για την απλότητα των πραγμάτων θα κατασκευάσουμε έναν Ansible ρόλο, έστω weblogic-patching. Στον κατάλογο vars/ ας φτιάξουμε το αρχείο weblogic_patches.yml με έστω τα περιεχόμενα:

patches:
- { patch_id: '19637454', patch_dist: 'p19637454_121300_Generic.zip', patch_type
: 'opatch', flags: 'apply', oh: "{{ mw_home }}" }
- { patch_id: '19637463', patch_dist: 'p19637463_1036_Generic.zip', patch_type:
'bsu', flags: '', oh: "{{ mw_home }}" }

H μεταβλητή patches ορίζεται λοιπόν ως ένα collection, που περιλαμβάνει δυο στοιχεία: τα δυο patches που θέλουμε να εφαρμόσουμε. Μπορούμε φυσικά να βάλουμε όσες εγγραφές (patches) χρειαζόμαστε. Στον τύπο αυτών των στοιχείων έχουμε ορίσει το patch_id, την τοποθεσία του στον Ansible host καθώς και ένα attribute, το patch_type, που διακρίνεται σε opatch ή bsu. Επίσης, υπάρχει μια άλλη ιδιότητα που ονομάζεται flags και αφορά πρόσθετες παραμέτρους για το patching.

To playbook μας θα ενσωματώσει το αρχείο των μεταβλητών και θα τις χρησιμοποιήσει για να καλέσει τον κατάλληλο ρόλο:

# hosts could come from tags
- name: Patch Weblogic
  hosts: all
  vars_files:
    - vars/weblogic_patches.yml
  remote_user: root
  gather_facts: no

  roles:
    - {role: weblogic-patching, patch_list: "{{ patches }}" }

Ενώ ο weblogic-patching ρόλος θα κάνει διάσχιση του patches collection και θα αποφασίσει τι θα κάνει ανάλογα με την τιμή του patch_type. Σε αυτό θα μας βοηθήσει η εντολή when του Ansible:

...
- name: launch OPatch
  su: yes
  su_user: oracle
  shell: "export ORACLE_HOME={{ item.oh }};export PATH={{ item.oh }}/OPatch:$PATH;opatch {{ item.flags }} < {{ oracle_base }}/patches/silent.iss"
  args:
     chdir: "{{ oracle_base }}/patches/current/{{ item.patch_id }}"
  with_items: patches
  when: item.patch_type == 'opatch'

- name: launch bsu
  su: yes
  su_user: oracle
  shell: "./bsu.sh -install -patch_download_dir={{ mw_home }}/utils/bsu/cache_dir -patchlist={{ item.patch_id }} -prod_dir={{ mw_home }}/{{ wl_home_11g }}"
  args:
     chdir: "{{ mw_home }}/utils/bsu"
  with_items: patches
  when: item.patch_type == 'bsu'