Πώς να τρέξουμε 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.

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'
 

Τρέχοντας Oracle Enterprise Linux στο Docker

Είχαμε αναφερθεί πριν λίγο διάστημα στο ότι Maven και Docker είναι δυο τεχνολογίες που αναμένουμε πολλές περισσότερες καινοτομίες από την Oracle στο άμεσο μέλλον. Το Docker είναι κάτι που μιλάει όλος ο κόσμος είτε πρόκειται για:

- continuous delivery infrastructure
- multi-tenant environments
- server consolidation
- ή πολλά άλλα...

Ας εστιάσουμε σε αυτό το άρθρο στο Docker και σε μερικές συμβουλές για την εγκατάσταση των Oracle προϊόντων. Ειδικά αν χρησιμοποιούμε Ubuntu, τότε η τελευταία έκδοση του Docker είναι διαθέσιμη από ένα ειδικό PPA (διαθέσιμο και στην έκδοση LTS 14.04) με εντολές που περιγράφονται εδώ.


Από τον Νοέμβριο του 2014 είναι διαθέσιμο το Oracle Enterprise Linux (OEL) 6 και 7 ως container από το Docker Hub Registry. Επίσης στο GitHub μπορούμε να βρούμε Dockerfiles για την εγκατάσταση του Weblogic, βασισμένα στο OEL image.
Ξεκινάμε λοιπόν. Ας τα κάνουμε όλα διαμέσου ενός Dockerfile ώστε να φτιάξουμε ένα image, βασισμένο στο OEL 6.6 που εγκαθιστά τις βασικά prerequisite πακέτα για την Oracle καθώς και τα αποθετήρια (repositories) του OEL. Το Dockerfile μπορεί να μοιάζει σαν το εξής:

 FROM oraclelinux:6.6  
 MAINTAINER Serafeim Karapatis <serafeim.karapatis@gmail.com>  
 RUN yum -y install wget  
 RUN wget --no-check-certificate https://public-yum.oracle.com/public-yum-ol6.repo -O /etc/yum.repos.d/pu  
 blic-yum-ol6.repo  
 RUN wget --no-check-certificate https://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6 -O /etc/pki/rpm-gpg  
 /RPM-GPG-KEY-oracle  
 RUN yum install -y oracle-rdbms-server-12cR1-preinstall --skip-broken  
 RUN yum install -y unzip --skip-broken  

Ας τρέξουμε τώρα το Dockerfile δημιουργώντας το δικό μας image (ας το ονομάσουμε myoel6) Αυτό θα τρέξει τις παραπάνω εντολές.

sudo docker build -f Dockerfile -t myoel6 .

Μερικές συμβουλές για τον νέο μας container ώστε να κάνουμε επιτυχημένη εγκατάσταση των Oracle προϊόντων:

1. Για τον Oracle Database Server χρειάζεται να κάνουμε mount το /dev/shm filesystem, που το Docker το αρχικοποιεί στα 64MB. Αυτό μπορεί να γίνει με την εκκίνηση του container ως εξής:

sudo docker run -v /dev/shm:/dev/shm myoel6

ώστε να περάσουμε στον container, το mounted /dev/shm σύστημα του host. 

2. Συνήθως, τα προϊόντα της Oracle διαθέτουν γραφικούς installers (GUI installers) Εδώ έχουμε τις εξής επιλογές:
1. είτε να εκκινήσουμε το sshd στον container (# service sshd start) και να κάνουμε ssh με το export του DISPLAY
   
2. είτε να περάσουμε σαν παράμετρο τις λεπτομέρειες του γραφικού περιβάλλοντος που είναι σε ισχύ (πχ sudo docker run -v /tmp/.X11-unix:/tmp/.X11-unix -v $HOME/.Xauthority:/home/oracle/.Xauthority myoel6)
3. να χρησιμοποιήσουμε τους silent installers (ενδεχομένως σε συνδιασμό με provisioning εργαλεία όπως το εξαιρετικό Ansible)

3. Αν δεν μπορούμε ή δεν θέλουμε να παρακάμψουμε τους τυπικούς συστεμικούς ελέγχους της Oracle κατά την εγκατάσταση που έχουν να κάνουν με την παραμετροποίηση των kernel flags (shm, κλπ) τότε στην εκκίνηση του container πρέπει να περάσουμε την παράμετρο: --privileged=true
   

lxc virtualization και docker practices

Έχει περάσει ακριβώς ένας χρόνος από το πρώτο μου άρθρο για τους Linux containers και στο διάστημα που έχει μεσολαβήσει αυτή η λύση για lightweight virtualization έχει γίνει πιο ώριμη και εγώ ταυτόχρονα έχω αποκτήσει περισσότερη εμπειρία στην χρήση του. Το lxc:

• έχει φθάσει αισίως σε μια σταθερή έκδοση (1.0.5 αυτή την στιγμή στο Ubuntu 14.04)
• απαιτεί λιγότερες ρυθμίσεις σε σχέση με έναν χρόνο πίσω ενώ υποστηρίζει και containers χωρίς root δικαιώματα (unprivileged)
  
• εξακολουθεί να τρέχει δίχως πρόβλημα τα βασικά προϊόντα τεχνολογίας της Oracle (όπως Database XE/11g/12c, SOA Suite 11g/12c) διαμέσου του πιστοποιημένου Oracle Enterprise Linux (OEL - ως virtual machine template)
  
• αποτελεί την βάση της τεχνολογίας για το αναδυόμενο προϊόν του docker που προσπαθεί να οδηγήσει σε τυποποίηση την κατασκευή, παράδοση και συντήρηση lightweight virtual machines

Είχα την ευκαιρία να δουλέψω λίγο το docker και είναι πολύ ενθαρρυντικός ο αριθμός των δυνατοτήτων που ενσωματώνονται πολύ γρήγορα σε αυτό. Ωστόσο, από άποψη παραμετροποίησης το lxc, κατά την γνώμη μου, διαθέτει εκ φύσεως περισσότερες δυνατότητες (πχ διαμοιρασμός συστήματος αρχείων, port forwarding, κ.α.) Επιπλέον, το docker δεν υποστηρίζει ακόμα δυναμικές μνήμες (file system /dev/shm) που είναι προαπαιτούμενο για την εγκατάσταση του Oracle Database Server, αλλά ούτε υπάρχει το Oracle Enterprise Linux στα αποθετήρια του (αν και ένα κόλπο είναι να μετατρέψουμε ένα CentOS σε OEL)

Από την άλλη μεριά, υπάρχει πλήθος από εξαιρετικές ιδέες στο docker, που είναι άμεσα εφαρμόσιμες σε μια τυπική εγκατάσταση lxc. Μια από αυτές είναι η χρήση ενός layered file system. Έτσι μπορούμε να χρησιμοποιήσουμε ένα base template image (πχ OEL 6.5) στο οποίο θα προσθέσουμε τα πακέτα που μας ενδιαφέρουν, και το οποίο στην συνέχεια θα χρησιμοποιήσουμε ως βάση για την παραγωγή virtual machines, που όμως θα περιλαμβάνουν μόνο τις διαφορές (σε επίπεδο αρχείων) από το template image. Η υποδομή που υλοποιείται αυτή η ιδέα στο docker βρίσκεται στο file system aufs και την ίδια θα χρησιμοποιήσω και στο lxc για την κατασκευή ενός template image βασισμένο στο OEL 6.5. Έπειτα, σύμφωνα με τις ανάγκες, μπορώ να φτιάξω ακαριαία, μια καινούργια εικονική μηχανή βασισμένη στο template. Τα δεδομένα και οι παραμετροποιήσεις της νέας μηχανής αποθηκεύονται σε ξεχωριστό αποθηκευτικό χώρο. Οποιεσδήποτε αλλαγές στο template (πχ προσθήκη νέων προγραμμάτων) είναι αυτόματα ορατές και σε όλα τα virtual machines που το χρησιμοποιούν. Η ιδέα για την εφαρμογή αυτής της υλοποίησης προήλθε από αυτό το post και συμπυκνώνεται στην εικόνα:

Ας φτιάξουμε λοιπόν μια νέα μηχανή βασισμένη στο Oracle Enterprise Linux (πχ orabase):

sudo lxc-create -n orabase -t oracle

Μόλις τελειώσει αυτή η διαδικασία, πρέπει να εγκαταστήσουμε όλα τα πακέτα που χρειάζεται ο Oracle Database Server 11g/12c, που καλύπτουν και τις ανάγκες του Oracle Fusion Middleware. H λίστα αυτών των πακέτων προκύπτει από αυτήν την εντολή (το lxc δεν επιτρέπει την εγκατάσταση του Oracle unbreakable kernel, οπότε θα χρησιμοποιήσουμε την ακόλουθη εντολή για να πάρουμε απλά την λίστα των προγραμμάτων):

yum install oracle-rdbms-server-11gR2-preinstall --skip-broken

Σε αυτό το oracle base template, θα προσθέσουμε και μερικά πολύ βασικά εργαλεία διαχείριση και δυνατότητες ssh και X, απλά με μια εντολή:

yum install xauth bc unzip libXtst.* xdpyinfo openssh-clients libXext.i686 mlocate tar gcc kernel-devel make ncurses-devel wget telnet perl sudo

Ο χρήστης της εγκατάστασης όλου του λογισμικού της Oracle θα είναι ο "oracle" οπότε ας τον προετοιμάσουμε στο template για όλες τις μετέπειτα μηχανές:

/usr/sbin/groupadd dba
/usr/sbin/groupadd oinstall
/usr/sbin/useradd -g oinstall -G dba oracle

Έχουμε τελειώσει με το base image! Ας δούμε τώρα πώς θα φτιάξουμε τις επόμενες μηχανές. Ο κατάλογος που βρίσκονται οι containers στο Ubuntu είναι ο /var/lib/lxc.  Για να φτιάξουμε έναν νέο container (πχ oradb) θα του υποδείξουμε έναν κατάλογο όπου θα αποθηκεύονται τα ιδιωτικά του αρχεία (πχ /var/lib/lxc/oradb) που θα συγχωνεύονται μέσω του aufs με το template σε ένα άλλο σημείο (πχ /var/lib/lxc/oradb-aufs) που θα έχει την ολιστική εικόνα για το file system.

sudo mkdir -p /var/lib/lxc/oradb/rootfs /var/lib/lxc/oradb-aufs
sudo mount -t aufs -o br=/var/lib/lxc/oradb/rootfs:/var/lib/lxc/orabase/rootfs none /var/lib/lxc/oradb-aufs
sudo cp /var/lib/lxc/orabase/config /var/lib/lxc/oradb

Κάνουμε τώρα επεξεργασία το config αρχείου της εικονικής μας μηχανής oradb (/var/lib/lxc/oradb/config) ώστε να διαβάζει από το ενοποιημένο σύστημα αρχείων και να έχει αλλαγμένο όνομα:

lxc.rootfs = /var/lib/lxc/oradb-aufs
lxc.utsname = oradb

Αυτό ήταν. Μόλις ξεκινήσουμε την εικονική μηχανή μας (oradb) θα διαβάσει το λειτουργικό σύστημα από το template ενώ οποιοδήποτε αρχείο αλλάξουμε, θα αποθηκευτεί στο δικό της κατάλογο. Για παράδειγμα, αν θέλουμε να ορίσουμε μια στατική διεύθυνση για την νέα μας μηχανή, θα κάνουμε τις εξής ενέργειες:

1) Επεξεργασία του /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=oradb
GATEWAY=10.0.3.1

2) Επεξεργασία του /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=10.0.3.12
NETMASK=255.255.255.0
DHCPCLASS=
ONBOOT=yes

3) Αλλαγή του /etc/hosts
127.0.0.1 localhost oradb

Αν δούμε τώρα τα περιεχόμενα του καταλόγου /var/lib/lxc/oradb θα μοιάζουν ως εξής. Θα περιλαμβάνονται μόνο τα νέα ή αλλαγμένα αρχεία σε σχέση με το template.

Disaster-Recovery Weblogic Servers διαμέσου του LXC

Σε περίπτωση που θέλουμε να σχεδιάσουμε μια αρχιτεκτονική υψηλής διαθεσιμότητας, βασισμένη στον Oracle Weblogic Server, σε ένα δευτερεύον σημείο πρόσβασης (disaster-recovery site) το πρώτο που θα κάνουμε είναι να διαβάσουμε την επίσημη τεκμηρίωση. Εκεί περιγράφεται κατά κύριο λόγο μια συμμετρική αρχιτεκτονική, όπου η ενημέρωση του μεσαίου επιπέδου (middleware) πραγματοποιείται με disc replication ή αλλιώς με τον συγχρονισμό των shared storages μεταξύ των δυο sites (production και disaster-recovery) που περιλαμβάνει τα Weblogic domains, εφαρμογές, κλπ.

Προκειμένου να επιβεβαιώσουμε μια τέτοιου είδους αρχιτεκτονική, μπορούμε είτε να την εφαρμόσουμε απευθείας σε ένα σύστημα (πχ με την χρήση virtualization software OVM ή VMWare) είτε με έναν πιο απλό τρόπο που είναι το lxc. Για παράδειγμα, έχω κατασκευάσει έναν Oracle Linux-based container (με το όνομα orasoa) στον οποίον εγκαθίσταται ένας Weblogic Server και γίνονται deployments εφαρμογών. Ας υποθέσουμε πως πρόκειται για τον production server. Η δημιουργία ενός αντιγράφου (clone)  είναι απλή υπόθεση για το lxc, απλά χρησιμοποιούμε την εντολή lxc-clone. Έτσι δημιουργείται μια δεύτερη μηχανή (πχ orasoaclone), με τα ίδια ακριβώς χαρακτηριστικά όπως στο production.

Τελικά, για να ελέγξουμε την τακτική ενημέρωση ενός DR site, ας προσομοιάσουμε την αντιγραφή των περιοχών shared storages ανάμεσα στα δυο sites, με την αντιγραφή σε επίπεδο host OS που φιλοξενεί τα lxc containers. Αν λοιπόν, όλοι μας οι containers βρίσκονται στην διαδρομή /var/lib/lxc (default για το Ubuntu) τότε απλά αρκούν εντολές σαν αυτές:

rsync -azv orasoa/rootfs/home/oracle/user_projects/prod_domain/servers/AdminServer/ orasoaclone/rootfs/home/oracle/user_projects/prod_domain/servers/AdminServer
rsync -azv orasoa/rootfs/home/oracle/user_projects/prod_domain/config/ orasoaclone/rootfs/home/oracle/user_projects/prod_domain/config

ώστε να μεταφερθούν καινούργιες εκδόσεις των εφαρμογών αλλά και εν γένει των Weblogic domains στο δευτερεύον site. Φυσικά, όπως αναφέρει και το documentation της Oracle, το δευτερεύον site δεν είναι ενεργό παρά μόνο για τις ανάγκες του switchover. Ωστόσο, το shared storage του DR θα πρέπει να είναι προσβάσιμο από το παραγωγικό σύστημα για τις ανάγκες του συγχρονισμού.

Εγκατάσταση Oracle Database 12c σε Linux Containers (lxc) στο Ubuntu

Έχει περάσει καιρός από την τελευταία μου αναφορά στο lxc, την ελαφριά εκδοχή του virtualization που προσφέρεται από το Linux kernel με τη βοήθεια μικρών εργαλείων. Το lxc βασίζεται σε τεχνολογίες του πυρήνα που επιτρέπουν την απομόνωση διεργασιών (cgroups) και την οργάνωση πόρων σε namespaces. Στους τελευταίους μήνες έχω αποκτήσει μεγαλύτερη εμπειρία στην χρήση του lxc, σε σχέση με τα προϊόντα της Oracle (Fusion Middleware, Glassfish και Database) και θεωρώ πως πρόκειται για ένα πολύ ισχυρό περιβάλλον για virtualization provisioning ανάλογο ή και καλύτερο σε σχέση με άλλα ανταγωνιστικά (πχ Vagrant) με το σαφές πλεονέκτημα της λειτουργίας απευθείας στον πυρήνα του Linux. Το lxc πλησιάζει πια την σταθερή έκδοση 1.0 και όλο αυτό το διάστημα βλέπω δραστηριότητα και υποστήριξη εκ μέρους της Oracle, γεγονός που προοιωνίζει ακόμα πιο ενδιαφέρουσες καινοτομίες στο μέλλον. Σε κάθε περίπτωση, η σκοπιά μου παραμένει αυτή του developer, αν και το lxc φαντάζει ιδανικό για large scale virtualization provisioning.

Το development περιβάλλον που θα περιγράψω έχει να κάνει με ένα laptop που τρέχει Ubuntu (13.04 64-bit) και στο οποίο θα εγκαταστήσουμε το lxc. Έπειτα θα δημιουργήσουμε ένα container βασισμένο στο Oracle Enterprise Linux (OEL) 6.4, στο οποίο τελικά θα εγκαταστήσουμε την τελευταία έκδοση του Oracle RDBMS (12c - 12.1.0.1.0) Είναι πραγματικά συναρπαστικό να τρέχεις το OEL και μια Oracle Database σχεδόν εγγενώς πάνω στο Ubuntu. Ένα άλλο ενδιαφέρον της υπόθεσης είναι η επιλογή της ίδιας της έκδοσης της βάσης δεδομένων: η 12c έρχεται με την έννοια των container databases που αφορά την φιλοξενία πολλαπλών instances από ένα κεντρικοποιημένο στη διαχείριση instance. Αν το αναλογιστεί κανείς υπάρχουν αρκετές αναλογίες με το lxc, και κατά τη γνώμη μου είναι η σημαντικότερη καινοτομία της Oracle έπειτα από την έκδοση 9i που εισήγαγε το RAC.

Ας ξεκινήσουμε λοιπόν με την εγκατάσταση του lxc στο Ubuntu μας, καθώς και κάποιων βοηθητικών προγραμμάτων με μια εντολή:

sudo apt-get install lxc bridge-utils yum

Για τις ανάγκες του lxc, θα δημιουργηθεί ένας νέος network adapter για τις διευθύνσεις 10.0.3.x. Για να μπορούν να επικοινωνούν οι containers με τον έξω κόσμο και να μην τους κόβει το firewall του Ubuntu, βάζουμε στο αρχείο /etc/default/ufw την ακόλουθη δήλωση και επανεκκινούμε το ufw service:

DEFAULT_FORWARD_POLICY="ACCEPT"

Έπειτα από αυτό, ας δημιουργήσουμε τον container για την 12c με την εξής απλή εντολή:

sudo lxc-create -n ora12 -t oracle

Ως όνομα του container δίνουμε το ora12. Η εντολή αυτή θα αναλάβει να κάνει ένα minimal install του OEL στην διαδρομή /var/lib/lxc/ora12/rootfs. Στην εκτέλεση της, θα κατεβάσει διάφορα πακέτα από το δίκτυο. Θα δημιουργηθούν επίσης δυο χρήστες, root και oracle.

Η καλή πρακτική λέει να δώσουμε μια στατική διεύθυνση στον database server μας. Ας το κάνουμε λοιπόν επηρεάζοντας (απευθείας!) διάφορα αρχεία του container μας που βρίσκεται στην διαδρομή /var/lib/lxc/ora12/rootfs/ και ας ορίσουμε την στατική διεύθυνση 10.0.3.2. Μην ξεχνάμε, ένας container δεν είναι παρά ένα directory στον δίσκο μας με όλα τα περιεχόμενα του (/dev, /home, κλπ) οπότε μπορούμε να τα αλλάζουμε οποιαδήποτε ώρα και στιγμή από το host σύστημα (ξεχνάμε τα shared directories του VirtualBox !)

# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=10.0.3.2
NETMASK=255.255.255.0
DHCPCLASS=
ONBOOT=yes
HOSTNAME=ora12
NM_CONTROLLED=no
TYPE=Ethernet


# /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=ora12
GATEWAY=10.0.3.1


# /etc/resolv.conf
; generated by /sbin/dhclient-script
nameserver 10.0.3.1


Είμαστε λίγο πριν την εκκίνηση του server. Για να δουλέψει η Oracle χρειάζεται shared memory στο σύστημα /dev/shm. Το /etc/fstab στο lxc ορίζεται εξωτερικά (όχι μέσα στον container) οπότε προσθέτουμε στο πρότυπο fstab (στην διαδρομή /var/lib/lxc/ora12/fstab) την γραμμή:

tmpfs   /var/lib/lxc/oraxe/rootfs/dev/shm  tmpfs  defaults 0 0

Ας ξεκινήσουμε τον container μας με την εντολή:

lxc-start -n ora12

O container θα ξεκινήσει αστραπιαία (2-4 δευτερόλεπτα) Στο πάνω μέρος βλέπουμε πως πρόκειται για το OEL. Ναι τρέχουμε το OEL στο kernel space του Ubuntu !! (γι' αυτό και έκδοση 3.8.0-34 του kernel)

Εμείς με την εντολή yum μπορούμε να εγκαταστήσουμε τα πακέτα που χρειαζόμαστε για το Oracle Linux 6.4 σύμφωνα με το installation guide. Ενδεικτικά κάποια πακέτα:

yum install xauth unzip xclock

Αφότου εγκαταστήσουμε τα πακέτα ας κάνουμε τις εξής αλλαγές στο /etc/sysctl.conf (/sbin/sysctl -p για να ενεργοποιηθούν):

kernel.sem = 250 32000 100 128
fs.file-max = 6815744
και επίσης στο /etc/security/limits.conf:

oracle         soft     nproc         2047
oracle         hard    nproc         16384

Ας ξεκινήσουμε λοιπόν τον installer:

Ένα σημείο θέλει προσοχή: να μην χτίσουμε απευθείας μια βάση δεδομένων, αλλά να κάνουμε install μόνο το software.

Στην οθόνη με τα prerequisites, τα local_port_range, rmem/wmem αποτυγχάνουν. Ο λόγος είναι πως αυτές οι ιδιότητες δεν μπορούν να οριστούν σε επίπεδο container. Ας το προσπεράσουμε αυτό το σημείο.

Προτού προχωρήσουμε στην δημιουργία της βάσης, τρέχουμε τον netca για τη δημιουργία ενός Oracle listener. Έπειτα, θα χρειαστούμε ένα τρικ. Πιο συγκεκριμένα:

echo "rootfs / rootfs rw 0 0" >> /etc/mtab

Αυτό θα μας εμποδίσει να δούμε το λάθος "[INS-08109] Unexpected error occurred while validating inputs at state 'storageLocationsPage'" στη συνέχεια. Ας ξεκινήσουμε το dbca και ας φτιάξουμε την βάση όπως εμείς θέλουμε.

 Όλα καλά στο τέλος.

Προτού επανεκκινήσουμε, αφαιρούμε την γραμμή που προσθέσαμε στο /etc/mtab. H Oracle 12c βρίσκεται σε εκτέλεση. Από το host λειτουργικό σύστημα τα processes φαίνονται κάπως έτσι. To user id 500 αντιστοιχεί στον oracle χρήστη στο περιβάλλον του container.

Για να τερματίσουμε το container εκτελούμε την εντολή:

sudo lxc-stop -n ora12

Με το lxc, η δημιουργία server-side containers, ειδικά για την Oracle, που βασίζονται στο OEL, είναι παιχνίδι. Αξίζει τον κόπο να το ερευνήσετε παραπάνω.

Εναλλακτική προσέγγιση για virtualization: LXC

Το τελευταίο χρονικό διάστημα εξετάζω λύσεις για την ελάφρυνση του laptop μου και την καλύτερη αξιοποίηση της επεξεργαστικής του ισχύς. Χρησιμοποιώ ευρύτατα εδώ και χρόνια το Oracle VirtualBox για τη συντήρηση του server-side προγραμματιστικού μου περιβάλλοντος (DB, Fusion Middleware, κλπ) και ένα από τα πράγματα που μου κινούν το ενδιαφέρον είναι η εκμετάλλευση αυτής της τεχνολογίας σε υψηλότερες ταχύτητες για τις ανάγκες ενός προγραμματιστικού περιβάλλοντος. Το να τρέχεις κάποιος καθετοποιημένες αρχιτεκτονικές προϊόντων σε εικονικές μηχανές έχει σαφή πλεονεκτήματα συντήρησης, ασφάλειας αναβάθμισης, επίτευξης πολύπλοκων δοκιμών, διασφάλισης ανεξαρτησίας από το πρωτεύον λειτουργικό σύστημα, κλπ. Από την άλλη πλευρά, χρησιμοποιώντας το VirtualBox εδώ και περίπου πέντε χρόνια, σε καθημερινή βάση, και πάντα σε σχέση με τα ιδιαίτερα απαιτητικά σε επεξεργαστικούς πόρους, μνήμη και δίσκο της Oracle, διαπιστώνω πως υπάρχουν κάποια περιθώρια για βελτίωση στη λειτουργία, όπως:

• Ταχύτερη απόκριση στη λειτουργία σε σχέση με CPU και I/O. Λόγω του διαρκούς context switching, μια εικονική μηχανή χρειάζεται διαρκώς πόρους, που ακόμα σε κατάσταση αδράνειας απαιτεί το 5-10% της CPU. Εξίσου η λειτουργία του I/O δεδομένου του ότι πραγματοποιείται μέσω του μηχανισμού της εικονικοποίησης, επιβαρύνει (έστω και σε μικρό βαθμό) την ταχύτητα μιας μηχανής
• Περιορισμοί στην χρήση μνήμης και CPU. Κατά τη δήλωση μιας μηχανής, προχωρούμε σε περιορισμούς στη μνήμη και τους επεξεργαστικούς πυρήνες που αυτή θα έχει πρόσβαση. Για ένα περιβάλλον προγραμματισμού, πολλές φορές είναι προτιμότερο να έχουμε στη διάθεση μας όλους τους πόρους του συστήματος ώστε όποτε χρειάζεται, να προχωρούμε στην κατάλληλη δέσμευση πόρων, αφήνοντας το κύριο λειτουργικό σύστημα να αποφασίζει.
• Καλύτερη αξιοποίηση του αποθηκευτικού χώρου. Ειδικά όταν μιλάμε για SSD, τότε τα GBs κοστίζουν. Είτε δημιουργούμε έναν στατικό ή έναν δυναμικό δίσκο στο VirtualBox, πάντα έχουμε απώλεια αποθηκευτικού χώρου. Θα ήταν ίσως χρήσιμο να έχουμε κατειλημμένα bytes εκεί ακριβώς που τα χρειαζόμαστε.
  
• Ειδική για ένα περιβάλλον προγραμματισμού σε laptop, η χρήση virtualization έχει άμεση επίδραση στην θερμότητα της συσκευής (λόγω CPU, I/O) και στην εν γένει διάρκεια της μπαταρίας

Βάζοντας όλα αυτά σε ένα πλαίσιο, κάνω αποτίμηση εδώ και καιρό μιας τεχνολογίας που ενσωματώνεται στο Linux kernel και προσφέρει ελαφρύς υπηρεσίες virtualization. Πρόκειται για το LXC ή αλλιώς Linux Containers. Πρόκειται για πολύ ελαφρύ περιβάλλον εικονικοποίησης, που τρέχει απευθείας στον πυρήνα του Linux (δίχως να χρειάζονται τρίτες βιβλιοθήκες ή προϊόντα), σε όλες τις μοντέρνες διανομές (πχ Ubuntu, openSuSE, Fedora, κλπ) και επιτρέπει την κατασκευή containers που διαθέτουν μια επαρκή απομόνωση από το κύριο λειτουργικό σύστημα, αξιοποιώντας ταυτόχρονα τις υπηρεσίες του (πχ buffers, scheduling, κλπ) Ως προσέγγιση, προσιδιάζει αυτή των Solaris Containers ή του OpenVZ και επιτρέπει την γρήγορη κατασκευή μηχανών με βάση κάποια πρότυπη διανομή όπως Ubuntu, Debian, Oracle Enterprise Linux, openSuSE, κλπ. Η εκκίνηση μιας τέτοιας μηχανής είναι ακαριαία: δεδομένου πως το host λειτουργικό σύστημα βρίσκεται σε λειτουργία, ένας LXC container δεν χρειάζεται πολλά πράγματα να αρχικοποιήσει καθώς τρέχει στο ίδιο kernel space. Η κατανάλωση πόρων είναι η πιο μικρή δυνατή (μια μηχανή σε αδράνεια καταναλώνει λιγότερο από 1% της CPU) ενώ φυσικά μπορούμε να συνθέσουμε τα δικά μας, ιδιωτικά δίκτυα μεταξύ των μηχανών, να εγκαταστήσουμε όποια software πακέτα θέλουμε μέσα στα πλαίσια ενός container, κλπ.

Στο επίπεδο του συστήματος αρχείων, μια εικονική μηχανή δεν είναι κάποιο μαγικό image file, αλλά μια κανονική δομή αρχείων.(πχ κάτω από το directory /var/lib/lxc/<όνομα container>/rootfs) που μπορούμε να διαβάσουμε ή να μεταβάλλουμε από το κύριο λειτουργικό σύστημα. Ένα σημείο που το paravirtualization υπερτερεί είναι η αποθήκευση της κατάστασης (saved state) μιας εικονικής μηχανής: εδώ το lxc δεδομένου ότι λειτουργεί στο επίπεδο του λειτουργικού συστήματος, με το κλείσιμο του υπολογιστή μας, τερματίζονται οι εικονικές μηχανές. Υπάρχει σε εξέλιξη το CRIU project για αυτόν τον λόγο που όμως δεν με έχει ικανοποιήσει ως προς τα αποτελέσματα του στις δοκιμές μου. Στον αντίλογο, η λήψη cold backup στο lxc αφορά απλά την αντιγραφή ενός συστήματος αρχείων.

Στο στάδιο της αποτίμησης του lxc, αρχικά το έτρεχα στα πλαίσια ενός VirtualBox guest machine (που με τη σειρά του έτρεχε ένα Ubuntu 13.04) Πρόκειται για μια αρχιτεκτονική ευέλικτη, που φέρνει μέσω του VirtualBox τα οφέλη του LXC και σε άλλες πλατφόρμες (πχ Mac OS X ή Microsoft Windows) Επί της ουσίας αντί να δημιουργηθούν πολλαπλά VirtualBox guest machines για διάφορα προϊόντα, δημιούργησα μόνο ένα, και εκτέλεσα το lxc εκεί, φτιάχνοντας κατά αυτόν τον τρόπο πολλαπλές εικονικές μηχανές. Θα έλεγα ένα lxc staging περιβάλλον.

Από τη στιγμή που έμεινα ικανοποιημένος από το lxc, έχω πια προχωρήσει σε deployments δίχως τη μεσολάβηση του VirtualBox.

Το λειτουργικό σύστημα που χρησιμοποιώ στο laptop μου είναι η τελευταία έκδοση του Ubuntu 13.04, που διαθέτει το lxc 0.9. Στις εικονικές μηχανές που έχουν κατασκευαστεί, χρησιμοποιώ το Oracle Enterprise Linux 6.4 ώστε να λειτουργήσουν τα προϊόντα της Oracle. Αυτή τη στιγμή, έχω εγκαταστήσει και λειτουργώ με επιτυχία διάφορα προϊόντα σε Linux Containers όπως:

• Oracle Database 11g R2
• Oracle Database 11g XE edition
• Oracle Weblogic 10.3.6
• Oracle SOA Suite/ESB 11.1.1.6
• Oracle Webcenter/UCM 11.1.1.6
  
• Oracle Identity and Access Management 11g R2
• Oracle Identity Management 11.1.1.7

Στα επόμενα άρθρα θα εστιάσω στην παραμετροποίηση του lxc καθώς και στην εγκατάσταση των προϊόντων της Oracle σε αυτό.