Access Denied após habilitar o RBAC no JBoss EAP 6

Após criar o usuário administrador do JBoss…

[jboss@rhel7-server-1 bin]$ cd $JBOSS_HOME/bin
[jboss@rhel7-server-1 bin]$ ./add-user.sh

What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a):

Enter (a) para criar um usuário de administração.

Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : admin

Após definir o nome do usuário (admin neste exemplo) defina uma senha obedecendo algus prereqs.

The username 'admin' is easy to guess
Are you sure you want to add user 'admin' yes/no? yes
Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
- The password must not be one of the following restricted values {root, admin, administrator}
- The password must contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
- The password must be different from the username
Password :
Re-enter Password :

Caso queira criar/associar o usuário à um grupo (ex: administradores) informe o nome do(s) grupo(s) neste momento. Ou Enter para continuar sem grupo.

What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
About to add user 'admin' for realm 'ManagementRealm'
Is this correct yes/no? yes

Por padrão o mecanismo de autenticação (Simple) do EAP mantém usuários e grupos em arquivos texto. As senhas são codificadas usando um algoritmo Hash.

Added user 'admin' to file '/opt/redhat/jboss-eap-6.3/standalone/configuration/mgmt-users.properties'
Added user 'admin' to file '/opt/redhat/jboss-eap-6.3/domain/configuration/mgmt-users.properties'
Added user 'admin' with groups to file '/opt/redhat/jboss-eap-6.3/standalone/configuration/mgmt-groups.properties'
Added user 'admin' with groups to file '/opt/redhat/jboss-eap-6.3/domain/configuration/mgmt-groups.properties'

Este usuário será usado para chamadas remotas ou por algum Host Controller (Domain Mode)?

Is this new user going to be used for one AS process to connect to another AS process?
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? no

Você acessa a console, abre a aba Administration e vê a seguinte mensagem:

JBoss EAP 6 RBAC Auth

Ahmmm! Legal! Quero habilitar o mecanismo de autenticação RBAC para criar usuários com diferentes perfis de gerência (Administrator, Deployer, Monitor, Operator, etc)…

Aí você copia o comando, acessa a CLI e executa…

[jboss@rhel7-server-1 bin]$ ./jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect 192.168.122.65:9999
[standalone@192.168.122.65:9999 /] /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@192.168.122.65:9999 /] reload

Volta na console web e tenta logar novamente ou executar alguma operação…

jboss-eap-access-denied-after-enable-rbac

Ops! :-/

Deu merda!

Sim! Quando você habilita o RBAC o JBoss troca o mecanismo de autenticação original (simple) pelo mecanismo RBAC. Por este motivo a role que antes era mapeada nos arquivos:

/opt/redhat/jboss-eap-6.3/standalone/configuration/mgmt-users.properties
/opt/redhat/jboss-eap-6.3/standalone/configuration/mgmt-groups.properties

passa a ser mapeada dentro do standalone.xml ou domain.xml.

...
        <access-control provider="rbac">
            <role-mapping>
                <role name="SuperUser">
                    <include>
                        <user name="$local"/>
                    </include>
                </role>
            </role-mapping>
        </access-control>
...

Agora precisamos mapear o usuário admin (criado com o script add-user.sh) para as roles pré definidas no RBAC. Como o admin é o usuário administrador, precisamos associar ele à role SuperUser. Para isso execute o comando abaixo na CLI do JBoss.

[standalone@192.168.122.65:9999 /] /core-service=management/access=authorization/role-mapping=SuperUser/include=user-admin:add(name=admin,realm=ManagementRealm,type=USER)
{"outcome" => "success"}

Pronto!

Agora se abrir o standalone.xml irá observar que o usuário admin está associado à role Super User

...
        <access-control provider="rbac">
            <role-mapping>
                <role name="SuperUser">
                    <include>
                        <user name="$local"/>
                        <user name="admin" realm="ManagementRealm"/>
                    </include>
                </role>
            </role-mapping>
        </access-control>
...

Agora o usuário admin pode ser visto na console.

jboss-eap-after-fix-rbac

;-)


Ref: https://access.redhat.com/solutions/696693

JBoss EAP 6.x como serviço no RHEL7: Systemd

Para aqueles que já estão utilizando o RHEL 7 (ou suas derivações: Centos, OEL, Scientific Linux) perceberam que os serviços não são mais controlados pelo mecanismo SysV (adicionados através do comando chkconfig). O RHEL 7 utiliza um novo mecanismo de gerência de serviços e inicialização do sistema chamado Systemd. Para mais detalhes ou um overview do Systemd veja as referências [1] e [2].

Abaixo descrevo um passo a passo de como adicionar o JBoss EAP 6 como serviço através do Systemd.

Crie um usuário chamado jboss.

[root@rhel7-server-1 bin]# adduser jboss
[root@rhel7-server-1 bin]# passwd jboss

Instale o JBoss EAP em um diretório de sua preferência. O script original sugere o diretório: /usr/share/jboss-as.

Eu particularmente costumo instalar em /opt.

mkdir /opt/redhat
unzip /tmp/jboss-eap-6.x.zip -d /opt/redhat
chown -R jboss.jboss /opt/redhat

Crie os seguintes diretórios que serão utilizados pelo script de inicialização.

[root@rhel7-server-1 bin]# mkdir /etc/jboss-as
[root@rhel7-server-1 bin]# mkdir /var/log/jboss-as
[root@rhel7-server-1 bin]# mkdir /var/run/jboss-as
[root@rhel7-server-1 bin]# chown jboss.jboss /etc/jboss-as
[root@rhel7-server-1 bin]# chown jboss.jboss /var/log/jboss-as
[root@rhel7-server-1 bin]# chown jboss.jboss /var/run/jboss-as

Copie e altere o arquivo de configuração auxiliar do script de init

[root@rhel7-server-1 bin]# cp init.d/jboss-as.conf /etc/jboss-as/
[root@rhel7-server-1 bin]# vim /etc/jboss-as/jboss-as.conf

Remova o comentário das variáveis e adiciene novas conforme destacado no trecho abaixo.

# General configuration for the init.d scripts,
# not necessarily for JBoss AS itself.

# Path to JBoss EAP Installation
JBOSS_HOME=/opt/redhat/jboss-eap-6.3

# The username who should own the process.
#
JBOSS_USER=jboss

# The amount of time to wait for startup
#
STARTUP_WAIT=30

# The amount of time to wait for shutdown
#
SHUTDOWN_WAIT=30

# Location to keep the console log
#
JBOSS_CONSOLE_LOG=/var/log/jboss-as/console.log

# JBoss configuration file
JBOSS_CONFIG=standalone.xml

# Public IP Address where JBoss will listen
JBOSS_PUB_BIND=192.168.122.65

# Management IP Address where JBoss will listen
JBOSS_MGMT_BIND=192.168.122.65

Faça a seguinte alteração no script de init original do JBoss EAP

vim $JBOSS_HOME/bin/init.d/jboss-as-standalone.sh
if [ -z "$JBOSS_PUB_BIND" ]; then
JBOSS_PUB_BIND=127.0.0.1
fi

if [ -z "$JBOSS_MGMT_BIND" ]; then
JBOSS_MGMT_BIND=172.0.0.1
fi

JBOSS_SCRIPT="$JBOSS_HOME/bin/standalone.sh -b $JBOSS_PUB_BIND -bmanagement=$JBOSS_MGMT_BIND"

Nota: por padrão o JBoss sobe na interface de loopback (localhost – 127.0.0.1). Essa alteração é necessária para informar/parametrizar os endereços onde as interfaces pública e de gerência devem ouvir conexões externas.

Caso tenha instalado a JVM OpenJDK (Default no REHL 7), edite o arquivo abaixo.
Nota: Caso o arquivo não exista, crie!

vim /etc/java/java.conf
# System-wide Java configuration file -*- sh -*-

# Location of jar files on the system
JAVA_LIBDIR=/usr/share/java

# Location of arch-specific jar files on the system
JNI_LIBDIR=/usr/lib/java

# Root of all JVM installations
JVM_ROOT=/usr/lib/jvm

# You can define a system-wide JVM root here if you're not using the
# default one.
#
# If you have a base JRE package installed
# (e.g. java-1.6.0-openjdk):
JAVA_HOME=$JVM_ROOT/jre
#
# If you have a devel JDK package installed
# (e.g. java-1.6.0-openjdk-devel):
#JAVA_HOME=$JVM_ROOT/java

# Options to pass to the java interpreter
#JAVACMD_OPTS=

Crie o script que será adicionado ao systemd com o seguinte conteúdo:

[jboss@rhel7-server-1 init.d]$ sudo vim /etc/systemd/system/jboss-as.service
[Unit]
Description=JBoss EAP Service
After=syslog.target network.target

[Service]
ExecStart=/opt/redhat/jboss-eap-6.3/bin/init.d/jboss-as-standalone.sh start
ExecStop=/opt/redhat/jboss-eap-6.3/bin/init.d/jboss-as-standalone.sh stop
Type=forking
PIDFile=/var/run/jboss-as/jboss-as-standalone.pid

[Install]
WantedBy=multi-user.target

Execute os comandos abaixo para habilitar o serviço no systemd:

[jboss@rhel7-server-1 init.d]$ sudo chmod 644 /etc/systemd/system/jboss-as.service

[jboss@rhel7-server-1 init.d]$ sudo systemctl enable jboss-as.service
ln -s '/etc/systemd/system/jboss-as.service' '/etc/systemd/system/multi-user.target.wants/jboss-as.service'

Inicie o serviço.

[jboss@rhel7-server-1 init.d]$ sudo systemctl start jboss-as.service

[jboss@rhel7-server-1 bin]$ sudo systemctl status jboss-as.service
jboss-as.service - JBoss EAP Service
Loaded: loaded (/etc/systemd/system/jboss-as.service; enabled)
Active: active (running) since Wed 2014-11-12 22:40:58 BRST; 8s ago
Main PID: 6969 (java)
CGroup: /system.slice/jboss-as.service
├─6877 /bin/sh /opt/redhat/jboss-eap-6.3/bin/init.d/jboss-as-standalone.sh start
├─6879 runuser -s /bin/bash jboss -c ulimit -S -c 0 >/dev/null 2>&1 ; LAUNCH_JBOSS_IN_BACKGROUND=1 JBOSS_PIDFILE=/var/run/jboss-as/jboss-as-standalone.pid /opt/redha...
├─6881 bash -c ulimit -S -c 0 >/dev/null 2>&1 ; LAUNCH_JBOSS_IN_BACKGROUND=1 JBOSS_PIDFILE=/var/run/jboss-as/jboss-as-standalone.pid /opt/redhat/jboss-eap-6.3/bin/st...
├─6882 /bin/sh /opt/redhat/jboss-eap-6.3/bin/standalone.sh -b 192.168.122.65 -bmanagement=192.168.122.65 -c standalone.xml
└─6969 java -D[Standalone] -server -XX:+UseCompressedOops -verbose:gc -Xloggc:/opt/redhat/jboss-eap-6.3/standalone/log/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateSta...

Nov 12 22:40:58 rhel7-server-1 systemd[1]: Starting JBoss EAP Service...
Nov 12 22:40:58 rhel7-server-1 systemd[1]: Started JBoss EAP Service.
Nov 12 22:40:58 rhel7-server-1 runuser[6879]: pam_unix(runuser:session): session opened for user jboss by (uid=0)
Nov 12 22:41:02 rhel7-server-1 jboss-as-standalone.sh[6869]: Starting jboss-as: [ OK ]

Verifique o log do serviço:

[jboss@rhel7-server-1 init.d]$ tail -f /var/log/jboss-as/console.log

22:13:13,010 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.3.0.Final-redhat-3
22:13:13,033 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) JBWEB003000: Coyote HTTP/1.1 starting on: http-/127.0.0.1:8080
22:13:13,081 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /opt/redhat/jboss-eap-6.3/standalone/deployments
22:13:13,084 INFO [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on 127.0.0.1:4447
22:13:13,084 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:9999
22:13:13,338 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
22:13:13,465 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
22:13:13,465 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
22:13:13,466 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started in 3564ms - Started 151 of 189 services (56 services are lazy, passive or on-demand)

Veja o arquivo de PID do processo do serviço

[jboss@rhel7-server-1 init.d]$ cat /var/run/jboss-as/jboss-as-standalone.pid
5615

[jboss@rhel7-server-1 init.d]$ pstree -U -h -l -s 5615
systemd───jboss-as-standa───runuser───bash───standalone.sh───java───34*[{java}]
[jboss@rhel7-server-1 init.d]$

[1] https://access.redhat.com/articles/754933
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/chap-Managing_Services_with_systemd.html

Instalando o Postgres 9 no RHEL 7

Recentemente precisei instalar um Postgres DB em uma VM RHEL 7 para testes. Aproveitei para compartilhar os passos seguidos aqui no Blog. Esse passo a passo deve funcionar em qualquer Distro RHEL-like: Fedora, Centos, Scientific Linux, OEL, etc.

A instalação é a mais básica possível, pois o propósito desse DB é apenas para testes e laboratórios. Nada de tuning ou personalização.
Instale os seguintes pacotes do repositório Postgresql.org oficial.

[rsoares@rhel7-server-1 ~]$ sudo yum install http://yum.postgresql.org/9.4/redhat/rhel-7-x86_64/pgdg-redhat94-9.4-1.noarch.rpm
[rsoares@rhel7-server-1 ~]$ sudo yum groupinstall "PostgreSQL Database Server 9.4 PGDG"

Inicialize o Postgres DB.

sudo /usr/pgsql-9.4/bin/postgresql94-setup initdb

Habilite e teste o serviço do Postgres.

[rsoares@rhel7-server-1 ~]$ sudo systemctl enable postgresql-9.4.service
[rsoares@rhel7-server-1 ~]$ sudo systemctl start postgresql-9.4.service
[rsoares@rhel7-server-1 ~]$ sudo systemctl stop postgresql-9.4.service

Troque para o usuário de sistema do postgres.

[rsoares@rhel7-server-1 ~]$ sudo su - postgres

Altere o pg_hba.conf (espécie de “firewall” do Postgres) para permitir o acesso externo através da rede da VM.

-bash-4.2$ vim /var/lib/pgsql/9.4/data/pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 ident
host all all 192.168.122.0/24 md5

Altere o binding do serviço para aceitar conexões em qualquer endereço IP da VM.

-bash-4.2$ vim /var/lib/pgsql/9.4/data/postgresql.conf
#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------

# - Connection Settings -

listen_addresses = '*' # what IP address(es) to listen on;

Logout do postgres user.

Ctrl + D no terminal

Reinicie o serviço postgres

[rsoares@rhel7-server-1 ~]$ sudo systemctl start postgresql-9.4.service
[rsoares@rhel7-server-1 ~]$ sudo systemctl status postgresql-9.4.service
postgresql-9.4.service - PostgreSQL 9.4 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-9.4.service; enabled)
Active: active (running) since Thu 2014-11-06 17:21:38 BRST; 1s ago
Process: 24832 ExecStop=/usr/pgsql-9.4/bin/pg_ctl stop -D ${PGDATA} -s -m fast (code=exited, status=0/SUCCESS)
Process: 25292 ExecStart=/usr/pgsql-9.4/bin/pg_ctl start -D ${PGDATA} -s -w -t 300 (code=exited, status=0/SUCCESS)
Process: 25286 ExecStartPre=/usr/pgsql-9.4/bin/postgresql94-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 25296 (postgres)
CGroup: /system.slice/postgresql-9.4.service
├─25296 /usr/pgsql-9.4/bin/postgres -D /var/lib/pgsql/9.4/data
├─25297 postgres: logger process
├─25299 postgres: checkpointer process
├─25300 postgres: writer process
├─25301 postgres: wal writer process
├─25302 postgres: autovacuum launcher process
└─25303 postgres: stats collector process

Confira o binding do serviço na porta TCP padrão so Postgres (5432)

[rsoares@rhel7-server-1 ~]$ netstat -tanp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:55970 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN -
tcp 0 0 192.168.122.65:22 192.168.122.1:39634 ESTABLISHED -
tcp6 0 0 ::1:25 :::* LISTEN -
tcp6 0 0 :::47021 :::* LISTEN -
tcp6 0 0 :::111 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:631 :::* LISTEN -
tcp6 0 0 :::5432 :::* LISTEN -

Crie um novo DB User

-bash-4.2$ createuser -d -l -P --interactive NEW_DB_USER
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n

Crie um novo Data Base

-bash-4.2$ createdb -e -O NEW_DB_USER NEW_DB "New DataBase"
CREATE DATABASE "NEW_DB" OWNER "NEW_DB_USER";
COMMENT ON DATABASE "NEW_DB" IS 'New DataBase';

ref:

[1] https://wiki.postgresql.org/wiki/YUM_Installation

#JUDCon2014:Brazil em Setembro!

Neste ano teremos mais uma edição do #JUDCon no Brail. Evento que reune a comunidade de desenvolvedores e arquitetos para discutir e compartilhar experiências sobre arquitetura e desenvolvimento de software corporativo. O evento conta com renomados profissionais e personalidades envolvidos em projetos de diversas áreas como: JavaEE, Cloud Computing, BigData, SOA, DevOps e muito mais.

Se você utiliza alguma tecnologia JBoss ou está interessado em conhecer as últimas novidades do universo JavaEE e outras tendências, participe do evento que ocorrerá dia 26 de Agosto em São Paulo.

Veja alguns nomes já confirmados para esta edição do evento.

Incrições podem ser feitas aqui.

Caso tenha interesse em compartilhar suas experiências submeta sua palestra aqui:

Participe!

 

Um pouco sobre a plataforma OpenStack

Neste post pretendo falar um pouco sobre a plataforma OpenStack. Apesar de não ser um especialista em Cloud Computing, gosto de ficar antenado no que acontece no vasto mundo da TI.

O que é OpenStack?

Em um primeiro momento poderíamos definir vagamente OpenStack como um software de cloud computing. Sendo um pouco mais específico: um Sistema Operacional projetado para nuvem capaz de controlar uma enorme quantidade de recursos computacionais (processamento, armazenamento e rede) em um Datacenter. Um cenário típico de um ambiente de cloud.

Entretanto, acho mais apropriando definir OpenStack como um projeto aberto cujo objetivo é servir como plataforma base para construção de nuvens públicas ou privadas.

o termo “projeto aberto” neste contexto merece destaque, pois implica que o projeto nasceu com o objetivo de ser transparente e independente de fabricante. O site do projeto destaca os seguintes valores baseados nessa filosofia: open source, open design, open development and an open community.

Como “plataforma base” poderíamos empregar o software OpenStack, por exemplo, para construção de uma solução de Infraestutura como Serviço (Infrastructure as a Service – IaaS). Sendo um pouco mais prático, uma plataforma de IaaS é um dos serviços oferecidos pela Amazon AWS através da plataforma Amazon EC2. Basicamente uma plataforma de IaaS fornece meios para criação/provisionamento de máquinas virtuais (ou nós computacionais) sob demanda. Permitindo ainda que sua infraestrutura de servidores possa expandir ou encolher de forma elástica de acordo com a necessidade da sua aplicação (Workload computacional). Usando o OpenStack teríamos neste caso uma versão OpenSource da Amazon EC2 :-p

Projetos semelhantes e “concorrentes”

Os três principais projetos de sofware para cloud computing baseados em desenvolvimento aberto no momento são:

Dos três o que tem recebido mais atenção no mercado é sem dúvida o OpenStack. Apesar de ser um projeto recente e imaturo, podemos afirmar que ele se destaca pela comunidade envolvida, bem como o grande número de fabricantes apoiando e suportando o projeto. Outro fator importante é a adoção em larga escala no mercado de cloud. Empresas como HP, Rackspace, eBay, NASA, MercadoLibre, PayPal dentre outras, vêm adotado o OpenStack como base para suas plataformas de IaaS.

A página OpenStack Marketplace oferece uma lista atualizada de como o mercado tem utilizado e oferecido soluções de cloud baseadas no OpenStack. As empresas se dividem em ofertas de: Training, Distros e Appliances, Public Clouds, Consulting & Integrators e Drivers.

Aplicabilidade

OpenStack não se aplica apenas a Cloud Providers (ex: Amazon AWS, Rackspace ou Microsoft Azure) ou empresas que desejam implementar uma nuvem pública. Para aquelas organizaçcões que desejam implementar um modelo de computação em nuvem semelhante ao praticado pelos grandes provedores, OpenStack fornece a base ideal para a implementação de uma nuvem privada em um Datacenter corporativo.

A arquitetura do OpenStack contempla um Dashboard de administração que fornece as ferramentas necessárias para provisionamento e gerenciamento dos recursos computacionais. Veja este vídeo demostrando as funcionalidades do OpenStack Dashboard.

Outro ponto importante a ser considerado diz respeito ao tipo de aplicação costuma ser hospedada em cima de uma infraestrutura de nuvem. Não apenas na plataforma OpenStack, mas em qualquer plataforma de nuvem. Esse tipo de infraestrutura é projetado para oferecer acima de tudo escalabilidade, ou seja, para suportar workloads que demandam principalmente elasticidade. Dessa forma as aplicações desenvolvidas para este tipo de ambiente devem seguir um paradigma que permita escalar de forma indefinida. Geralmente são aplicações web sem estado (stateless web apps), Big Data processing, Web Services, RESTful Services, Caching, HPC processing etc, projetadas para nuvem. Aplicações preparadas para lidar com tolerância a falha, crescimento e diminuição, dados e processamento distribuída, cache em memória, multi-tenancy e todas as demais particularidades inerentes à este tipo de ambiente.

Partindo deste conceito OpenStack não deve ser confundido como uma plataforma de virtualização tradicional (ex: RHEV, Citrix Xen Server, VMWare etc). Pois como o próprio site sugere:

OpenStack Software delivers a massively scalable cloud operating system.

OpenStack é uma plataforma para provisionamento massivo de recursos computacionais. Tem como característica primordial a elasticidade (scale up/scale down). Neste tipo de ambiente máquinas (server nodes) são criadas e eliminadas sem prejuízo para o funcionamento da aplicação. Para aplicações projetadas para esse tipo de ambiente.

Arquitetura

Como uma plataforma de computação em nuvem o OpenStack foi projetado para ser extremamente escalável e flexível. A plataforma é composta por vários “sub-projetos” que juntos formam o seu núcleo (core).  Sua arquitetura é modular e formada por vários componentes que juntos implementam as funcionalidades dos três pilares que sustentam uma infraestrutura de nuvem: Processamento (compute), Rede (networking) e  Armazenamento (storing).

Cada componente possui um codename que o identifica e implementa um conjunto de funcionalidades dentro da plataforma:

  • Nova (openstack compute)
  • Neutron (openstack networking)
  • Swift (openstack object storage)
  • Cinder (openstack block storage)
  • Horizon (openstack dashboard)

Além dos componentes que formam o core do OpenStack a plataforma conta com um conjunto de serviços que integra cada componente para fornecer uma plataforma de IaaS completa. Essa integração é possível porque cada componente disponibiliza um conjunto APIs que permite o acesso às suas funcionalidades. Os serviços são os seguintes:

  • Keystone (Identity Service)
  • Glance (Image Service)
  • Ceilometer (Telemetry Service)
  • Heat (Orchestration Service)
  • Trove (Database Service)

Devido a sua arquitetura modular e flexível a plataforma permite a extensão de forma que serviços e ferramentas de terceiros possam ser integrados ao OpenStack para formar uma solução de cloud computing ainda mais rica e completa. Esse tipo de extensão permite que fornecedores de software ofereçam plataformas que vão além do IaaS. Contemplando soluções de PaaS (ex: Red Hat Openshift Enterprise) e Governança de nuvens híbridas (Red Hat Cloud Forms).

Não pretendo abordar cada componente ou serviço neste post. Seria necessário um post específico para entrarmos em detalhes técnicos. Esta página da documentação oficial descreve um overview explorando detalhes técnicos dos componentes e serviços do OpenStack, bem como suas respectivas funcionalidades e responsabilidades dentro do projeto.

Implementação

Apesar de ser um software o OpenStack não deve ser considerado um produto. OpenStack está mais para um framework de infraestrutura para nuvem do que para um produto final. É um projeto que evolui em uma velocidade incrível, mas com consistência.

Não é raro encontrar relatos pela Internet alegando dificuldades na implementação de um projeto com OpenStack. Entretanto, isso não tem sido considerado impedimento para escolher o OpenStack como base para implementação de uma nuvem pública ou privada. Basta observar o crescente número de casos de uso da plataforma por grandes players da indústria.

O projeto está em constante evolução e não tem por objetivo criar relases do tipo Enterprise Edition. Veja  o que diz o próprio wiki do projeto:

We do not produce “open core” software.

We are committed to creating truly open source software that is usable and scalable. Truly open source software is not feature or performance limited and is not crippled. There will be no “Enterprise Edition”.

OpenStack Enterprise

Existem diferentes distibuições do OpenStack suportadas e oferecidas por diferentes players da industria de software. A Red Hat se destaca nessa lista por sua inquestionável reputação como provedora de software corporativo baseado em código aberto. A Red Hat oferece sua distribuição chamada Red Hat® Enterprise Linux® OpenStack® Platform (RHEL-OSP). Trata-se de uma versão corporativa (enterprise-ready) do OpenStack que utiliza produtos consagrados como o Red Hat Enterprise Linux, SELinux, KVM Hypervisor, Red Hat Storage etc. Veja nesta página quais componentes e serviços da plataforma são oferecidos no RHEL-OSP. Vale ressaltar que a Red Hat faz parte do grupo dos oito membros Platinum que suportam o projeto OpenStack dedicando recursos em tempo integral.

Conclusão

Neste post tentei explorar de forma superficial os principais aspectos da plataforma OpenStack. Fiz questão de referenciar vários artigos e documentos oficiais que dizem respeito ao OpenStack para enriquecer a discussão.

Vimos também alguns pontos que fazem do OpenStack uma plataforma de cloud computing extremamente robusta e flexível. E o mais importante, o compromisso da plataforma de ser independente de fornecedor, primando pelos valores da filosofia OpenSource.

Espero que o post possa agregar valor ao leitor e despertar a curiosidade por assuntos relacionados a computação em nuvem.

Abraço ;-)

Instalando o Oracle VirtualBox no RHEL 6.x

Recentemente precisei instalar o Oracle VirtualBox (um projeto anteriormente mantido pela Sun Microsystems) em um laptop rodando o RHEL 6.5 (x86_64).

Apesar da instalação do pacote ocorrer sem erro.

# sudo yum localinstall ~/Downloads/VirtualBox-4.3-4.3.12_93733_el6-1.x86_64.rpm

Tive algumas dificuldades devido a falta de alguns pacotes e configurações. Ao executar o VirtualBox pelo terminal pela primeira vez uma mensagem de erro é mostrada instruindo executar o seguinte comando:

# sudo /etc/init.d/vboxdrv setup

Mais erros ocorrem devido a falta de algumas dependências, entre elas, os headers e o código fonte do Kernel do Linux. Para sanar este problema instale os seguintes pacotes via YUM:

sudo yum install kernel-devel kernel-headers binutils glibc-headers glibc-devel gcc make patch dkms

em seguida defina a seguinte variável de ambiente

# export KERN_DIR=/usr/src/kernels/2.6.32-431.11.2.el6.x86_64 #a versão do kernel no seu ambiente pode ser diferente

por fim execute novamente o comando abaixo:

# sudo /etc/init.d/vboxdrv setup

Se tudo der certo após esses passos o VirtualBox deverá ser iniciado normalmente sem erros. Pronto, agora pode começar a criar suas VMs com o VirtualBox.

 

 

Oracle Fusion Middleware: conceitos

Oracle Fusion Middleware (OFM) é uma família de produtos que compreende desde ferramentas de desenvolvimento para a plataforma Java Enterprise Edition (JavaEE), até  soluções para integração de sistemas, gerenciamento de identidade, colaboração e Business Intelligence (BI). O OFM é fornecido e mantido pela empresa Oracle e é composto por uma grande variedade de produtos que oferecem suporte ao desenvolvimento, implantação e gerenciamento de sistemas para a plataforma JavaEE.

De forma bem simplista podemos definir middleware como sendo o software responsável por conectar componentes de software ou aplicações corporativas. Em um sistema multicamadas (ex: três camadas: apresentação, lógica/negócio e dados) o Middleware atua na camada do meio hospedando os componentes com a lógica de negócio da aplicação. Outra função importate do Middleware é fornecer a infraestrutura necessária para o desenvolvimento de aplicações de negócio (business applications). Serviços tais como: acesso concorrente à recursos computacionais, controle transacional, mensageria, segurança, logging etc. Tudo isso é oferecido pelo Middleware de forma, pelo menos em tese, a deixar o desenvolvedor responsável apenas com o que diz respeito ao negócio da aplicação.

A imagem a seguir destaca alguns componentes do OFM em uma visão de divisão em três camadas.

Oracle Fusion Middleware Architecture

Não se preocupe com o significado de cada componente que aparece na imagem acima neste momento. Ao longo do post iremos comentar os principais deles.

Dada uma breve descrição sobre o OFM exponho neste post alguns conceitos importantes para aqueles que pretendem iniciar sua jornada pelo arcabouço de produtos que compõem o Middleware da Oracle.

Hoje em dia instalar um software não é tarefa complicada. Para obter o binário correto basta saber em qual plataforma (arquitetura de hardware e sistema operacional) de destino da instalação e realizar o download no site do fornecedor. Em seguida basta seguir o guia de instalação do produto. Entretanto, para alguns tipos de software, existem alguns aspectos importantes que devem ser observados para evitar problemas futuros. É o caso do Middleware. Uma solução de Middleware geralmente é composta por uma variedade de componentes desenvolvida sob uma arquitetura modular. Essa característica implica uma certa complexidade na gerência do software que vai desde a instalação, operação até a gerência do ambiente.

Middleware Component

O primeiro conceito diz respeito aos tipos de componentes utilizados no OFM. Existem dois tipos:

  • java component: componente composto por uma ou mais aplicações e recursos JavaEE impltantado (deployado) em um domínio do Oracle Weblogic Server. Exemplos:
    • Oracle SOA Suite
    • Oracle Webcenter Portal
    • Oracle Business Intelligence Enterprise Edition
  • system component: serviço (processo) gerenciado pelo Oracle Process Manager and Notification (OPMN) – gerenciador de processos com uma interface de linha de comando (CLI). Exemplos:
    • Oracle Http Server
    • Oracle Web Cache
    • Oracle Internet Directory
    • Oracle Forms
    • Oracle Reports
    • Oracle Business Intelligence

Todo produto da linha OFM é executado sobre um mesmo componente de middleware: o Weblogic Server (WLS). Esta é a “runtime” (não confundir com a Java Virtual Machine – JVM sobre a qual roda o Weblogic) de todo o middleware Oracle. Em praticamente toda a instalação de um produto OFM você encontrará uma estrutura de diretórios contendo os binários do Weblogic.

Após instalar o OFM teremos um ambiente composto por, pelo menos:

  • Um Oracle Weblogic Server Domain, que nada mais é que um conjunto de instâncias de servidores conhecido como Managed Servers, sendo que um deles é utilizado para administração dos demais – o Administration Console. Os managed servers hospedam as aplicações e recursos (java component) JavaEE (EJBs, Data Sources, JMS Destinations, etc).
  • Um ou mais Oracle Instance (system component).
  • Se o componente/produto do OFM (ex: Oracle Business Intelligence ou Oracle SOA Suite) necessitar de um banco de dados de metadados, um database será criado como metadata repository.

Dessa forma é muito importante se familiarizar com a estrutura de diretórios utilizada na instalação do WLS. A imagem abaixo esquematiza a estrutura criada para a instalação do produto Oracle SOA Suite.

Oracle Middleware Home

Middleware Home e Weblogic Home

O Middleware Home é o diretório raiz de qualquer componente/produto (java ou system component) do OFM. Logo abaixo encontra-se o Weblogic Server Home criado durante a instalação do Weblogic. O Weblogic Home hospeda o servidor de aplicação Weblogic.

Weblogic Server Home após a instalação do Weblogic

NOTA: um detalhe importante e que confunde bastante em alguns casos é: em um mesmo Host o diretório Middleware Home deve ser único para uma determinada release do OFM (ex: 11g ou 12c). Outro detalhe é que dentro do Middleware Home só pode haver um Weblogic Server Home. Dessa forma não é possível instalar duas versões diferentes do Weblogic dentro de uma mesma estrutura do Middleware Home. Quando for necessário instalar releases diferentes do OFM em um mesmo Host recomenda-se criar estrutura de diretórios diferentes para cada release (ex: Middleware11g e Middleware12c).

No mesmo nível do Weblogic Server Home encontram-se outros diretórios. Abaixo descrevemos cada um deles.

Oracle Home

Com exceção do Weblogic Server Home, que contém os binários do application server, cada produto OFM é instalado em seu próprio Oracle Home. Este diretório armazena os binários do produto. Dessa forma nenhum processo escreve nele. No diagrama abaixo os binários do Oracle SOA Suite foram instalados dentro do Oracle Home chamado oracle_soa1 (neste caso também referenciado como SOA Oracle Home). Para produtos do tipo java component um weblogic domain também é criado para hospeda a aplicação e recursos JavaEE que compõem o produto.

Oracle Home após a instalação do Oracle SOA Suite

Oracle Home após a instalação do Oracle SOA Suite

Domain Home

Um Weblogic Domain deve ser entendido como um grupo lógico de java components (neste contexto são aplicações e recursos JavaEE). Um domínio é composto por um Administration Server (geralmente referenciado como admin server) e geralmente possui um ou mais Managed Servers (também referenciados como instâncias do weblogic). As aplicações e recursos são implantadas e executadas dentro do(s) Managed Server(s). Na instalação padrão de um produto do OFM a estrutura de diretórios utilizada para hospedar um domínio do weblogic segue o digrama abaixo:

SOA Domain após a instalação do Oracle SOA Suite

SOA Domain após a instalação do Oracle SOA Suite

O domínio não necessariamente deve residir dentro do diretório User Projects na estrutura do Oracle Middleware Home. Observe que a estrutura utilizada para hospedar o domain está fora do Weblogic Home e pode, inclusive, residir fora do Middleware Home (ex: em um storage remoto utilizando um protocolo NFS ou SAN). O diagrama abaixo destaca o domain criado para o Oracle SOA Suite.

É muito comum a instalação de vários produtos OFM em um mesmo ambiente/host. Dessa forma cada produto pode utilizar seu próprio domínio weblogic. O diagrama abaixo destaca dois domains distintos: um para hospedar o Oracle WebCenter e outro para o Oracle SOA Suite. Observe também dois Oracle Homes distintos, um para cada produto OFM.

Estrutura de Weblogic Domains para múltiplos produtos OFM instalados em um mesmo ambiente Oracle Middleware.

Estrutura de Weblogic Domains para múltiplos produtos OFM instalados em um mesmo ambiente Oracle Middleware.

NOTA: todos os produtos instalados dentro de uma estrutura Oracle Middleware Home devem ser compatíveis com a mesma release do OFM utilizada no ambiente em questão. Por exemplo, não seria possível instalar o Oracle WebCenter 12c em um ambiente preparado para o OFM 11g.

Outro aspecto interessante relacionado ao Weblogic Domain é possibilidade de extender (escalar) determinado domínio existente dentro de um host. Durante a criação ou configuração de um domain é possível adicionar novos managed servers, seja para extender um produto ou reutilizar um mesmo domínio. Por exemplo, ao invés de criar um novo domínio para instalar o Oracle WebCenter, poderíamos utilizar o mesmo domain criado para o Oracle SOA Suite. Nesse caso a estrutura de diretórios do OFM em nosso ambiente ficaria conforme a imagem abaixo:

Domínio extendido

Domínio extendido

Oracle Instance

Diferentemente dos diretórios descritos nos tópicos anteriores um diretório Oracle Instance hospeda system components, ou seja, serviços/processos não JavaEE tais como: Oracle Http Server, Oracle Web Cache ou Oracle Internet Directory.

Diferentemente do Oracle Home um diretório Oracle Instance contém arquivos passíveis de alteração (configuração, logs e temporários gerados durante a execução do processo/serviço). Assim como o diretório Weblogic Domain um Oracle Instance pode residir fora da estrutura do Oracle Middleware. O diagrama abaixo destaca um ambiente OFM contendo dois produtos instalados: um system component (WebTier composto por Oracle Http Server e Oracle WebCache) e um java component (Oracle SOA Suite), este último reside em um Weblogic Domain:

OFM com Webtier (system component) e SOA Suite (java compoenent - Weblogic Domain)

OFM com Webtier (system component) e SOA Suite (java compoenent – Weblogic Domain)

Oracle Common Home

Este diretório não está associado à um componente ou produto específico dentro da estrutura Oracle Middleware Home. Ele contém uma variedade de utilitários e bibliotecas utilizadas e necessárias pela solução de gerenciamento e monitoramento do OFM conhecida como Oracle (Enterprise Manager) Fusion Middleware Control e também pelo conjunto de bibliotecas, não incluídas por padrão no Weblogic, Java Required Files (JRF).

NOTA: dentro da estrutura Middleware Home só pode haver um único diretório Oracle Common.

O diagrama abaixo destaca o diretório Oracle Common Home:

Oracle Common Directory

Oracle Common Directory

Oracle Metadata Repository

Alguns produtos do OFM, tais como o Oracle BPEL Process Manager, Oracle Business Activity Monitoring, Oracle Business Intelligence necessitam de um Banco de Dados específicos para armazenar metadados do produto. Um Metadata Repository pode ser de dois tipos: baseado em banco de dados (database-based) ou baseado em um sistema de arquivos (filesystem-based). Embora os dois tipos sejam suportados a Oracle recomenda a utilização de repositórios baseados em Banco de Dados para o ambiente de produção.

Para esses produtos que necessitam de um repositório de metadados é necessário executar o passo de criação do repositório antes de prosseguir com a instalação do produto. Para isso é utilizada uma ferramenta específica: o Repository Creation Utility (RCU). Essa ferramenta cria os schemas de Banco de Dados necessários para o funcionamento do produto.

O diagrama abaixo destaca o Metadata Repository utilizado pelo produto Oracle SOA Suite:

Oracle SOA Suite's metadata repository

Oracle SOA Suite’s metadata repository

Espero com este post ter esclarecido alguns conceitos, geralmente ignorados ou confundidos, durante a instalação ou preparação de um ambiente de execução do Oracle Fusion Middleware. A fonte de referência para os conceitos aqui expostos é a excelente documentação oficial do produto disponível no siste da Oracle.

Nos próximos posts pretendo continuar explorando alguns conceitos específicos do Oracle Weblogic Server.

Abraço ;-)