Weblogic - Configurando ORDS para uso do APEX

      Bueno, em minhas atividades atuais com Weblogic precisei migrar o uso do APEX de um OHS para o Weblogic.

______________________________________________________________
APEX: https://apex.oracle.com/en/
OHS: https://docs.oracle.com/cd/E28280_01/web.1111/e10144/intro_ohs.htm#HSADM101
Weblogic: http://www.oracle.com/br/products/middleware/cloud-app-foundation/weblogic/overview/index.html
______________________________________________________________


     Para tal, é necessário usar o ORDS, que pode ser executado em standalone, Glassfish ou Weblogic, para a postagem corrente falaremos de seu uso no Weblogic.

Pré-requisitos
______________________________________________________________
- WLS instalado
- JDK instalado e JAVA_HOME configurado
______________________________________________________________

Premissas
______________________________________________________________
- HTTPS não será abordado;
- Instalação do APEX na database Oracle não será abordada;
- Comandos de configuração do WLST não serão foco do post.
______________________________________________________________

     Primeiramente baixe o ORDS no site da Oracle:
______________________________________________________________
http://www.oracle.com/technetwork/developer-tools/rest-data-services/downloads/index.html
______________________________________________________________

     Após o download extraia o pacote e visualizará um pacote 'ords.war', é esse pacote que utilizarás no Weblogic.

     Antes de nos preocuparmos com este WAR precisaremos criar um novo war com o conteúdo estático de imagens para o APEX, eles podem ser localizados no OHS, possívelmente em '/apex/images'.

    Faça a cópia de todo o conteúdo dessa pasta, pois precisaremos compactá-las em um WAR e implantar no Weblogic, utilize para tal o seguinte comando:
______________________________________________________________
java -jar ords.war static \images
______________________________________________________________

    Esse comando gerará o arquivo 'i.war', o qual tu farás a implantação no Weblogic com custom security roles(Custom Roles: Use roles that are defined in the Administration Console; use policies that are defined in the deployment descriptor).

    Bem, já temos as imagens, nos falta configurar no ORDS a database que tem o APEX instalado(a instalação do APEX na database Oracle não é o objetivo desta postagem), bem como criar um cluster no Weblogic que serão os alvos da aplicação do ORDS.

    Realize a criação de um cluster, pode ser via WLST ou Admin-Server do DAS, e garanta que exista ao menos um managed-server neste cluster, pode ser localizado no nodemanager do mesmo servidor que possui o DAS, sem problemas.

    Feito isto vamos configurar o ORDS, então para tal utilize o comando abaixo:

______________________________________________________________
java -jar ords.war install simple
______________________________________________________________

   Aqui precisará das seguintes informações:

Host da database onde o APEX foi instalado;
Porta da database onde o APEX foi instalado;
Usuário e senha de um usuário com grant de sysdba para instalação do usuário do ORDS;
Usuário e senha do usuário do APEX_PUBLIC_USER e demais usuários relacionados ao APEX;
Especificar um caminho de configuração dos parâmetros de configuração do ORDS, aqui é ideal utilizar uma pasta dentro do $MIDDLEWARE_HOME;

   Caso ocorra um erro de sintaxe na instalação do ORDS, usando um WinRAR ou extrair o 'ords.war' e edite o arquivo 'ords_create_rest_users.sql' e altere deixando como abaixo:
______________________________________________________________
create user ORDS_PUBLIC_USER identified by $minhasenha account unlock default tablespace ^PUB_DATATBS temporary tablespace ^PUB_TEMPTBS;
______________________________________________________________

     Onde $minhasenha é a senha que definiu na instalação.

     Feito isto, execute a desinstalação do ORDS e execute a instalação novamente.
______________________________________________________________
java -jar ords.war uninstall
java -jar ords.war install simple
______________________________________________________________

     Bueno, estamos pendente apenas com o deploy(implantação) pendente no WLS. Execute deixando como target(alvo) o cluster que criaste. Utilize também custom rules para security no processo de deploy. E se fez tudo corretamente o APEX estará disponível no endereço abaixo:

______________________________________________________________
http://localhost:9003/ords 

Onde localhost é o IP do(s) managedserver(s) que configuraste no cluster, e 9003 é a porta que o managedserver escuta. 
______________________________________________________________

   

MySQL - Backup full e incremental com innobackupex

     Em um dos últimos projetos em que atuei precisei configurar uma rotina de backup no MySQL. Com isto veio a necessidade do uso do 'innobackupex', pois o mesmo me possibilitaria gerar backups completos e incrementais, sejam eles compactados ou não, sem downtime da instância de 1TB.

      Depois de ler diversos materiais relacionados a execução de backup remoto ou local, cheguei aos comandos abaixo, bem como as conclusões que seguem: 

1. O backup incremental não foi de fato efetivo, pois a redução de armazenamento foi de 50% por backup com relação ao backup completo;
2. A compactação durante a execução mostrou-se eficaz no sentido de espaço em disco, entretanto péssima para o tempo de execução do backup, pois o uso do 'gzip' fez com que a opção de multi-thread parasse e a compressão ficasse em um só core do processador;
3. O comando de extração xbstream, quando utilizada a compressão de stream não funcionou, precisando do outro lado no servidor de destino utilizar ele diretório por diretório;
4. Tar sem compressão foi a solução mais aderente. 

    Comandos utilizados:

Backup FULL:

     innobackupex --stream=tar /tmp | cat - > /disk2/backup-dir/full-base-backup/backup.tar

Aplicando os binlogs em caso de restore(para abrir a instância):

cd /data/mysql ; tar xvfi /mnt/backup.tar ; innobackupex --apply-log /data/mysql

Script de backup:

#!/bin/bash
#     Full backup mysql percona
# Developped by:
#     Gabriel Prestes - helkmut@gmail.com
# Last update:
#     2015-08-21
#
## DEFAULT SETTINGS ###########################################
BACKUP_DESTINATION='/disk2/backup-dir/full-base-backup'
HOST_NAME="teste.athore.org"
DAYS=3

source /etc/profile

## STOP EDITING HERE ###########################################

function remove() {
        log_this "Removing older than ${DAYS_TO_KEEP}"
find ${BACKUP_DESTINATION}/* -type f -name "${HOST_NAME}*" -mtime +${DAYS_TO_KEEP} | xargs ls -lha find ${BACKUP_DESTINATION}/* -type f -name "${HOST_NAME}*" -mtime +${DAYS_TO_KEEP} | xargs rm -fv

}

function log() {
        echo $(date "+[ %d-%m-%Y %H:%M:%S ]:") "${1}"
}

function start() {

        log "Starting backup job..."

        innobackupex --stream=tar /tmp | cat - > ${BACKUP_DESTINATION}/${HOST_NAME}-$(date "+%d-%m-%Y_%H-%M-%S").tar
        flag=$?

        if [ ${flag} -eq 0 ]; then

                echo "0" > /opt/resources/backup/percona-mysql-backup-agent.mon

        else

                echo "1" > /opt/resources/backup/percona-mysql-backup-agent.mon

        fi


        remove

        log "Job fished."
}


start


Crontab:

## Backup full daily Percona - MySQL

00 12   * /opt/resources/backup/percona-mysql-backup-agent.sh > /opt/resources/backup/percona-mysql-backup-agent.out 2>&1

      

Puppet - Exportando site.pp para CouchDB

   Quando estamos no caminho da automação de processos e garantia de estado uma das ferramentas poderosas e nossa aliada é o Puppet. 

   Quanto mais se conhece de Puppet, mais quer integrá-lo ao CouchDB para que o mesmo responda de forma inteligente consultas no formato JSON via Hiera. 

   O que essa publicação de propõe é a facilitar, apoiando-o na migração do site.pp dos seus ambientes, hoje com todas informações de classes, includes e tasks carregadas dos agents no site.pp e que serão exportadas para o CouchDB. 

   Segue abaixo a explicação de uso de um programa que criei para automatizar o processo de exportação. Ele já faz a análise se o agent existe no CouchDB, caso exista o mesmo ignora, do contrário, exporta para a base. 

   Repositório GIT do programa: https://github.com/helkmut/couchdb-populate

   Exemplo de execução: 

[root@Teste-CouchDB rb-couchdb-populate]# ./bin/rb-couchdb-populate.rb

| Starting agent Current Time : 2015-02-04 23:41:22 -0200 |

| Test database connection > configuration |

| Connection PASS |

| Directory /etc/puppet exist |

| Parse file /etc/puppet/environments/prd/manifests/site.pp |

| Import node 1.teste.com.br to CouchDB |

| Import node 2.teste.com.br to CouchDB |

| Import node 3.teste.com.br to CouchDB |

| Import node 4.teste.com.br to CouchDB |

| Import node 5.teste.com.br to CouchDB |

| Import node 6.teste.com.br to CouchDB |

| Import node 7.teste.com.br to CouchDB |

| Import node 8.teste.com.br to CouchDB |

| Import node 9.teste.com.br to CouchDB |

| Import node 10.teste.com.br to CouchDB |

| Import node 11.teste.com.br to CouchDB |

| Import node 12.teste.com.br to CouchDB |

| Import node 13.teste.com.br to CouchDB |

| Import node 14.teste.com.br to CouchDB |

| Import node 15.teste.com.br to CouchDB |

| Import node 16.teste.com.br to CouchDB |

| Import node 17.teste.com.br to CouchDB |

| Import node 18.teste.com.br to CouchDB |

| Import node 19.teste.com.br to CouchDB |

| Import node 20.teste.com.br to CouchDB |

| Parse file /etc/puppet/environments/dev/manifests/site.pp |

| Node 21.teste.com.br already exists in CouchDB |

| Import node 22.teste.com.br to CouchDB |

| Import node 23.teste.com.br to CouchDB |

| Import node 24.teste.com.br to CouchDB |

| Node 25.teste.com.br already exists in CouchDB |

| Node 26.teste.com.br already exists in CouchDB |

| Import node 27.teste.com.br to CouchDB |

| Node vagrant-teste.local already exists in CouchDB |

| Parse file /etc/puppet/environments/hlg/manifests/site.pp |

| Import node 28.teste.com.br to CouchDB |

| Import node 29.teste.com.br to CouchDB |

| Import node 30.teste.com.br to CouchDB |

| Node 31.teste.com.br already exists in CouchDB |

| Import node 32.teste.com.br to CouchDB |

| Import node 33.teste.com.br to CouchDB |

| Import node 34.teste.com.br to CouchDB |

| OK - Program end with success |

   O que o programa não contempla: 

1 - se o Document existir ele não atualiza os fields;

2 - ainda não está fazendo parse das 'tasks', mas faz de chamadas 'includes' e 'classes'.  

   Sugiro testar em um laboratório com uma Vagrant de CounchDB, hiera e Puppet Master. Naturamente que isto não se aplica a versão Enterprise do Puppet, que já não faz o gerenciamento dos agents por site.pp.