Automatização de ambientes de infraestrutura obtidos por
Gerencia de Configuração de Software
Ênio Machado de Oliveira, Marcos Alberto Lopes da Silva
Instituto de Informática – Centro Universitário do Triângulo (UNITRI) Caixa Postal 309 – 38.411-106 – Uberlândia – MG – Brasil
eniomachadod@gmail.com, malopes@unitri.edu.br
Resumo. As organizações de tecnologia da informação (TI) têm-se destacado
cada vez mais no cenário tecnológico. Novas metodologias são aplicadas para automatizar processos, tornando assim, os ambientes de TI ágeis, com qualidade, além de permitir uma rápida entrega para clientes internos e externos. A Gerência de Configuração de Software (GCS) utiliza como apoio um conjunto de processos para controle e gerenciamento ágil no desenvolvimento, com a proposta em automatizar a instalação do servidor de aplicação Weblogic (WLS). Este artigo tem como objetivo apresentar a funcionalidade do GCS, que propõe um ganho de produtividade no ambiente corporativo e um modo de trabalho para diversas áreas da TI por meio de um estudo de caso realizado demonstrando resultados significativos na operação. 1. Introdução
No ambiente corporativo há um crescente aumento na necessidade de melhorar a produtividade e inserir um departamento de operações ágil. Com foco em otimizar a entrega dos serviços/projetos dentro do período contratado de um Service Level
Agreement (SLA) acordo de nível de serviço, ou cronograma a ser finalizado. Devido ao
desenvolvimento de serviços em grande escala, tem-se a necessidade de implantar uma infraestrutura que suporte as demandas dos clientes internos ou externos durante o processo de integração. Sendo este, testado, homologado e por fim implementado em ambiente produtivo.
Para se preparar a automatização de ambiente de infraestrutura necessita-se primeiramente uma definição de normas e mudança social interna nas organizações, envolvendo assim mudanças de hábitos e padrões que não agregam em agilidade para a TI. Na maioria das vezes, um projeto de grande porte apresenta algumas dificuldades de integração, que podem ser integrações entre sistemas, entre a área de desenvolvimento e infraestrutura. Portanto, é necessário aplicar uma prática que diminua assim, os riscos, e aumentando a qualidade de aceitação de um projeto.
O processo de finalização do ciclo de um projeto para realizar a integração dos sistemas pode causar problemas de qualidade, gerando assim, um atraso no cronograma. Por isso, este artigo tem como objetivo apresentar uma abordagem na GCS junto a Integração Contínua para apoio em automatizar a implementação em um ambiente de infraestrutura para contribuir com o avanço tecnológico nas organizações.
2. GCS
Em um sistema de GCS tem-se como premissa a redução de falhas, bugs, seja na fase de desenvolvimento ou na implantação provendo visibilidade e evolução ao que esta sendo proposto para automatizar a instalação do servidor de aplicação de Weblogic.
2.1. Conceito de GCS
O histórico em desenvolvimento de software necessita de um controle que possa medir e ser indicado, que a partir desta necessidade pode-se definir que a GCS é como se controla a evolução de um projeto de software, estabelecendo e mantendo integridade dos artefatos (códigos/serviços) que ajudaram na automatização do servidor de aplicação ou software [PRESSMAN 2010].
O metodo GCS é utilizado há bastante tempo, Jonh Buckle relata que em 1973, já havia publicações de manuais de Desenvolvimento e Gerencia de Configuração de
Software relatada por um professor de engenharia de software [
BUCKLE 1982].
Dificilmente o processo de software se tornará intratável, pois a GCS controla as alterações e mantem a integridade do sistema. É possivel identificar e controlar a configuração do que esta ou será implementado, do hardware, e das ferramentas que forem usadas durante todo o ciclo de desenvolvimento.
Mudanças são inevitáveis no produto de software, e mudanças tendem a aumental o nivel de problemas quando um grupo de pessoas estão trabalhando no mesmo projeto. O produto da linha de base (baseline) trata-se de uma configuração de referencia para futuros desenvolvimentos/instalações de sistemas. [PRESSMAN
2010].
De acordo com Instituto de Engenharia Eletricistas e Eletrônicos (IEEE) responsável por estabelecer padrões no campo da engenharia e computação, destaca quatro aspectos operacionais clássicos da GCS [IEEE 2014]:
Identificação: É necessária para entender a estrutura do produto. Isso envolve identificar a estrutura/arquitetura e os tipos de componentes, tornando-os acessíveis, dando a cada componente um nome, uma versão, e uma identificação de configuração.
Controle: se faz necessário a partir da criação de um baseline do produto, por ter controle em seu ciclo de vida para alterá-lo e garantir qualidade. Status de Qualidade: Relatar estatísticas vitais dos produtos e alterações. Auditório e Revisão: garantir a integridade de um produto e sua
manutenção, garantindo sua consistência ao longo do ciclo de vida do produto.
2.1.1. Propósito da GCS
A GSC se faz necessária devido ao aumento da complexidade dos sitsemas, aumento da demanda e gerência de varios itens de configuração.
No ambiente corporativo a GCS pode ser utilizada como uma prática de estratégia para dar uma grande vantagem em relação as organizações que não estão utilizando, pois quando utilizada de forma eficaz durante todo o ciclo de vida do produto que está sendo implantado, pode identificar itens de sofware a serem desenvolvidos, evitar problemas, e quando é necessário alguma mudança, fornece informações necessárias sobre o estado de desenvolvimento [LEON 2000].
É importante deixar claro a diferença entre suporte em software e GCS. O suporte são suite de atividades que ocorrem após a entrega do produto para o cliente e introduzido a operação. A GCS é um conjunto de atividades de acompanhamento e de
controle que são iniciadas quando um projeto começa e termina apenas quando o produto é retirado da operação [PRESSMAN 2010].
2.1.2. GCS no ambiente corporativo
A importância de um sistema de GCS em uma organização se torna essencial por várias atividades, principalmente devido aos programas e sistemas que estão se tornando maiores e mais complexos.
Portanto, cada vez mais o grupo de trabalho na organização necessita de um sistema de GCS para aprimorar sua produtividade, garantido sua qualidade de entrega, reduzir custos mantendo o controle de suas entregas até finalizar o projeto. Esse controle aproxima os profissionais facilitando a gestão dos mesmos em um projeto com grande volume de pessoas estando presenciais ou até mesmo remotamente.
2.2.1. Integração Contínua
O uso de Integração Contínua é uma prática adquirida da Extreme Programming (XP). Programação extrema que é um método de desenvolvimento de software adotado nos Estados Unidos na década de 90. As origens do XP foram definidas por Kent Beck em 1996, por intermédio de uma publicação do livro chamado “Smalltalk Best pratice
pattners”, referindo-se a pontos positivos e negativos de projetos de software [BECK
1996].
A Integração Contínua surgiu como uma das práticas da metodologia ágil através da XP, com foco em desenvolvimento de software com ciclos mais curtos, possibilitando uma melhor resposta às alterações e inclusão de novos requisitos ao
software. Mas esta prática não se limita apenas as equipes que adotam a metodologia XP ou frameworks ágeis, trata-se de um conjunto de boas práticas que podem
perfeitamente serem adotadas em metodologias de desenvolvimento convencionais [BECK 2002].
De acordo com Martin Fowler “A Integração Contínua é uma prática de desenvolvimento de software em que um time realiza integrações de códigos, normalmente cada membro realiza integrações com grande frequência, gerando várias integrações. Cada item de configuração pode ser definido como códigos desenvolvidos e scripts que são armazenados em um servidor de controle de versão e verificados por um build automático que pode ser executado diariamente para testes onde são detectados erros o quanto antes”.
O processo de build é o núcleo da engenharia ágil de um sistema de IC, é composto por várias etapas, mas cada etapa com sua tarefa separada, desde a compilação até a realização do deploy, são através dos scripts de build que se realizam as automatizações para garantir o resultado esperado. Sendo assim definidos pelo ciclo de vida do sistema proposto pela equipe de arquitetura, com padrões de implementação documentados.
No cenário apresentado da figura 1, administradores de sistemas ou desenvolvedores iniciam a integração realizando commit dos arquivos modificados de sua estação para o servidor de controle de versões. A partir desta etapa, o servidor IC realiza o download dos scripts e inicia o processo de integração, ou seja, é feito o
checkout com as modificações no projeto e executado o script que automatiza a
Figura 1. Sistema de IC [DUVALL 2008].
Neste script, pode-se ter diferentes configurações para cada implementação, mas é essencial que o administrador compile o projeto e execute os testes unitários e funcionais. Sendo assim, o servidor IC gera e-mail usando um mecanismo de feedback apontando os erros e sucessos da integração, este mecanismo pode ser um simples
script que envia e-mail para determinadas pessoais que podem estar envolvidas no
projeto ou na sustentabilidade do ambiente, caso tenha erro, o processo de instalação volta para o administrador de sistema que corrige a falha no código e executa novamente o build [DUVALL 2008].
Uma vez que criada a automatização do ambiente pelo sistema de SGC e IC a Entrega Contínua (EC) é uma parte sequencial da IC para preparação do ambiente. Uma sequência de práticas destinadas a garantir que o código pode ser implantado com agilidade no ambiente de produção e sendo realizado constantemente versionamento e entrega do software. Com a automatização completa a entregue é garantida apenas com um comando ou agendamento para execução conforme a ferramenta que esteja utilizando [HUMBLE 2010].
A EC se preocupa que todas as etapas estejam alinhadas para que o processo funcione bem, estas etapas são [DUVALL 2011]:
Gerencia de configuração Teste automatizado Integração Contínua
Disponibilização do serviço (Deployment) Gerencia de dados
O Deploy Contínuo (DC) será possível alinhar sua utilização somente se a organização possuir um processo de GCS. IC e EC bem definido, pois uma vez que o software estiver construído e testado, estará pronto para ser disponibilizado (deployed) no servidor de aplicação ou ambiente.
Deploy Contínuo deveria ser objetivo das empresas de TI, porem a maioria não
estão preparadas para executar tal tarefa devido a muitas dependências internas e externas para entrega de projetos. O ponto é decidir quando deploy contínuo é positivo para organização baseado na necessidade do negocio.
3. Ferramentas de suporte a GCS
Uma característica comum entre as ferramentas de IC é um forte apoio para gerenciamento de configuração de software integrando com outras ferramentas, sendo assim em conjunto formando um sistema de IC para automatizar um processo conforme figura 2.
Figura 2. Ferramentas de suporte a GCS. 3.1. Controle de versão
Em um sistema de GCS, o controle de versão é de fundamental importância para gestão de sistemas que estão sendo desenvolvidos ou instalados.
O versionamento ou controle dos itens de configuração tem um papel de grande importância para garantir um nível aceitável do ciclo de vida do produto implementado destes itens. A fácil identificação, armazenamento e gerenciamento dos itens de configuração, histórico de todas as alterações efetuadas e recuperação de um determinado item de configuração [PRESSMAN 2010].
3.1.2. Controle de mudança
O processo de controle de mudança esta ligado diretamente com processo humano e ferramentas automatizadas para disponibilizar um mecanismo de controle de mudanças.
Existem varias ferramentas que são especificas para o controle de mudanças, porem este controle pode ser realizado como uma atividade complementar da ferramenta de controle de versão, oferecendo serviços para identificar, rastrear, controlar mudanças referentes aos itens de configuração [IEEE 2014].
3.2. Ferramentas para implantação da automação da infraestrutura
Para realizar a automação da infraestrutura, será apresentada uma breve descrição das ferramentas que serão utilizadas ao longo do projeto. As ferramentas utilizadas contribuíram para moldar todo cenário desenvolvido, cada uma com sua característica e função específica.
3.2.1. A ferramenta de script WLST
O Weblogic script tool (WLST) é uma ferramenta nativa do servidor de aplicação
possível realizar as mesmas atividades que são desempenhadas através da console administrativa.
O WLST é interpretado em linguagem jython que é uma implementação do
python, que gera código para servidores cliente Java. O WLST oferece modo on-line e offline.
O modo offline oferece recursos para que somente seja possível a criação de domínios, cluster, manage servers (servidores Gerenciados), e não é necessário conectar ao servidor de aplicação, isso significa que o servidor de aplicação não necessita estar no modo ativo.
O modo on-line oferece recursos que somente será possível realizarem caso o servidor de aplicação do WLS (Weblogic) esteja ativo, isso ocorre porque alguns recursos são utilizados em tempo de execução do servidor de aplicação.
3.2.2. Shell script
O shell é utilizado em vários sistemas operacionais linux que tem a função neste projeto de interagir com a linguagem jython para instalação dos binários no servidor de aplicação.
Os scripts em shell desenvolvidos para integração com os códigos jython têm a função de configurar diretórios de instalação comuns para os servidores.
Na arquitetura linux, o shell realiza a intermediação entre o usuário e o sistema operacional. O kernel é o núcleo do linux responsável por Gerenciar os equipamentos de
hardware do servidor, como disco rígido, placa de vídeo e modem.
O shell é a interação entre o usuário e o sistema, responsável por interpretar os comandos e recursos que o usuário executa, dentre os tipos de shell, o mais comum é o (sh) foi escrito em 1975 por S.R Bourne [FERRARI 2002].
3.2.3. Subversion
Este trabalho apresenta um servidor de versões cujo nome é Subversion utilizado para Gerenciar arquivos e diretórios.
A capacidade do subversion em oferecer uma arquitetura dinâmica que possibilita os profissionais de TI modificarem e gerenciarem uma massa de dados sejam eles, documentos, códigos ou instaladores, são o que incentiva a colaboração em disseminar o uso da ferramenta.
As entregas de atividades conforme um cronograma em projeto pode ocorrer mais rapidamente quando não há um ponto focal único por onde todas as modificações devem passar. Sendo assim o fato de todos os artefatos serem versionados, não há receio que algum trabalho perca qualidade por não ter essa via única para modificações caso um código sofra alguma alteração indevida [FORGEL 2007].
3.2.4. Puppet
O Puppet é uma ferramenta open source de sistemas para automatização de servidores e serviços e foi desenvolvida por Luke Kanies, atualmente a empresa Puppet Labs é responsável pelo desenvolvimento. Kanies está envolvido com Unix e administração de sistemas desde 1997 e foi quando se iniciou o desenvolvimento do puppet [KRUM 2013].
O puppet é composto por uma linguagem declarativa que nos permite expressar as configurações que os servidores, sistemas e serviços devem ter, fazendo isto através de uma sintaxe simples e prática, sendo natural para o usuário [PUPPETLABS2 2015].
Portanto, oferecem duas formas de funcionamento, a primeira pode se chamar de autônoma, neste modo são criadas e executadas as configurações localmente. Além do modo autônomo, o puppet também funciona no modelo cliente (agente) e servidor (master) para distribuir estas configurações para todo o parque de servidores através da rede [PUPPETLABS2 2015].
4. Estudo de caso
O estudo de caso apresenta um projeto desenvolvido e implantado em uma empresa no seguimento do varejo localizada na cidade de Franca-SP com objetivo em atender com mais agilidade os projetos internos. Devido ao grande número de servidores para instalação de ambientes Weblogic e tarefas que devem ser executadas diariamente em paralelo, surgiu a necessidade de realizar a automatização evitando atrasos nos cronogramas.
A instalação automatizada mencionada no estudo de caso foi disponibilizada no endereço eletrônico: https://github.com/eniomachado/Artigo
4.1. Estruturas dos servidores e arquitetura do weblogic
O Weblogic é um servidor de aplicação da empresa Oracle que trabalha em plataforma
JEE (Java Platform Enterprise Edition), um produto escalável de servidores dinâmicos
que permite acesso de um serviço ao banco de dados, possibilitando desenvolvedor criarem aplicações. Sua arquitetura é composta pelos seguintes recursos:
Domínio: trata-se de um conjunto de recursos e serviços que são mantidos fisicamente como arquivos. A parte principal do domínio é chamado de
Admin Server, que é uma instância do Weblogic responsável por configurar e
Gerenciar recursos como criação de credencias e integração com banco de dados. O Gerenciamento dos recursos é realizado através do WLST, ou pode
ser realizado pela console administrativa.
Servidores Gerenciados (Managed servers): Os servidores Gerenciados são instâncias do Admin Server, onde aplicações customizadas são disponibilizadas. Quando um managed server é inicializado, conecta-se ao
Admin Server para obter informações de um arquivo chamado config.xml,
que por sua vez é responsável por manter as configurações padrão no ambiente e customizada. Os servidores Gerenciados podem ser criados conforme a capacidade de recursos do servidor.
Conjunto de servidores (Cluster): corresponde a várias instâncias ativas simultaneamente com objetivos de prover escalabilidade e disponibilidade. O cluster é responsável por Gerenciar um grupo de managed servers.
Gerente de nó (Node manager): é um componente ou recurso do Weblogic que está associado a um servidor, pois um servidor pode ter um ou mais
managed servers (instâncias). O node manager tem a responsabilidade em
Gerenciar o início e a parada de uma instância.
Referente à estrutura que foi adotada para o experimento utilizou-se três servidores com sistema de IC no servidor master desenvolvido para instalação
silenciosa do Weblogic servers 12c. Quando o termo instalação silenciosa é mencionado referente à middleware isto significa que uma instalação está sendo realizada por scripts automatizados. Segue abaixo a estrutura utilizada:
s500lxhmlmm02: servidor master responsável por centralizar os códigos e realizar a distribuição dos arquivos necessários para os servidores cliente e iniciar a instalação do servidor de aplicação Weblogic Server.
s500lxhmlmm01: servidor cliente responsável pela parte da arquitetura de
cluster.
s500lxhmlmm03: servidor cliente responsável pela parte da arquitetura de
cluster.
Tabela 1. Estrutura de diretórios.
Diretório Descrição
/apps/install/installSilent Diretório raiz dos instaladores
Config Diretório responsável por manter os arquivos silent
Logs Diretório onde são gerados os logs de instalação para cada
script
Scripts Diretório responsável por armazenar os códigos jython Source Diretório responsável por armazenar os arquivos de
instalação
Para que o processo realizado pelo sistema de GCS e IC tenha sucesso é necessário que o servidor tenha configurado a estrutura de diretórios, conforme mostrado na Tabela 1.
A configuração dos diretórios informados foi necessária sua criação uma única vez manualmente no servidor master, especificamente onde está o sistema de GCS e IC.
Descrição detalhada do ambiente em que foi executado o estudo de caso:
Hardware: 16 Processadores Intel(R) Xeon(R) CPU, 16 GB de RAM (Random Acess Memory) Memória de Acesso Randômico e disco de 48 GB. Sistema Operacional: Linux 2.6.39-400.248.3.el5uek x86_64.
Produto: Oracle Weblogic Server 12c, versão 12.1.3.0. Tecnologia: Oracle.
4.2. Instalação e configuração
A preparação da instalação automatizada a principio é complexa e exige foco e vários testes do profissional que está implementando, pois exige um procedimento de preparação do build que esta sendo implementado de acordo com fabricante do servidor de aplicação.
O administrador de sistemas que executa a instalação não deve se preocupar com a sequência de instalação, pois já está definida no script, mas para conhecimento, segue abaixo o que foi instalado e configurado:
Distribuição dos artefatos para servidor cliente;
Instalar o pacote Weblogic; Criar o domínio;
Criar as Instâncias managed servers; Configurar o node manager.
Para se ter uma instalação automatizada e organizada, houve várias etapas realizadas, que são apresentadas a seguir:
Procedimento 1: Instalação servidores Linux. A equipe de sistema operacional tem como responsabilidade realizar a instalação e configuração dos servidores Linux, incluindo todos os pré-requisitos solicitados pelo fabricante do produto Weblogic, disco rígido, CPU, memória, bibliotecas, usuário e grupo.
Procedimento 2: Criação de DNS (Domain Name System) Sistema de nomes de domínio. A equipe de redes tem a responsabilidade de definir o nome dos servidores clientes onde será instalado o produto.
Procedimento 3: Download dos instaladores e distribuição para servidores cliente. A partir deste ponto o administrador de sistema é responsável por realizar o procedimento, como foi mencionado o propósito deste artigo é realizar a instalação automatizada do servidor de aplicação Weblogic. Os artefatos como pode ser chamados de instaladores e builds desenvolvidos estão armazenados no servidor master s500lxhmlmm02 que tem como função ser um servidor IC apoiando a GCS responsável por replicar todas as configurações necessárias para os servidores clientes onde foram instalados o Weblogic, no caso os servidores s500lxhmlmm01 e s500lxhmlmm03. Date
deployCore() {
scp config/* oracle@srv:/apps/install/installSilent/config scp config/ .bash_profile oracle@srv:/home/oracle
scp source/* oracle@srv:/apps/install/installSilent
scp scrips/*.py scripts/*.properties oracle@srv:/apps/install/install/scripts }
Figura 3. Script que replica arquivos para servidor cliente.
A distribuição dos artefatos é garantida pelo sistema de GCS para os servidores de aplicação é realizada pelo script shell 1.distributeFiles.sh, onde foi implementada uma função com nome de deployCore(), que tem a funcionalidade de copiar arquivos para os servidores cliente , conforme apresentado na figura 3.
Procedimento 4: Instalação do JDK. A partir desta etapa todos clientes servidores estão com os artefatos disponibilizados e aguardando o próximo procedimento. A sequência do que vai ser instalado primeiro não é problema para quem esta executando, pois já foi definido nos scripts de deploy e não é possível alterar esta sequência. A instalação do JDK é bem simples, a mesma é realizada através do comando tar (Tape Archive) em conjunto com os parâmetros -xvf que permitem extrair arquivos de um arquivo compatível e existente conforme figura 4.
ssh oracle@$srv 'tar -xvf /apps/install/installSilent/jdk-7u65-linux-x64 -C /apps/oracle/java -log=/apps/oracle/oraInventory/logs/jdk-7u65-linux-x64.log' 2>> logs/2.installJDK.log
Figura 4. Script de instalação do JDK.
Procedimento 5: Instalação Weblogic. Para o servidor de aplicação Weblogic foi utilizado a instalação silent (silenciosa), que foi disponibilizada através de um arquivo
.rsp configurado conforme orientação do fornecedor do produto WLS apresentada na
figura 5. Um arquivo .rsp contém respostas a perguntas de instalação que de outra forma seriam fornecidos pelo usuário em uma sessão de instalação interativa. Cada resposta é armazenada como um valor para uma variável identificada.
Response File Version=1.0.0.0.0 ORACLE_HOME=/apps/oracle/middleware INSTALL_TYPE=WebLogic Server MYORACLESUPPORT_USERNAME= MYORACLESUPPORT_PASSWORD=<SECURE VALUE> DECLINE_SECURITY_UPDATES=true SECURITY_UPDATES_VIA_MYORACLESUPPORT=false PROXY_HOST= PROXY_PORT= PROXY_USER= PROXY_PWD=<SECURE VALUE>
[scheme[Http/Https]]://[repeater host]:[repeater port] COLLECTOR_SUPPORTHUB_URL=
Figura 5. Arquivo .rsp do WLS
Sendo assim na figura 5 o arquivo .rsp é atribuído com parâmetro –silent
-responseFile no comando de shell script, estes parâmetros realizam a instalação sem
que seja exposto o display de tela, ao invés de interagir selecionando as opções de instalação, o procedimento já esta predefinido com todas as opções.
ssh oracle@$srv $JAVA_HOME'/bin/java -Djava.security.egd=file:/dev/./urandom -Djava.io.tmpdir=/apps/install/installSilent -jar
/apps/install/installSilent/fmw_12.1.3.0.0_wls.jar -silent -responseFile /apps/install/installSilent/config/wls12c_silent.rsp -invPtrLoc
/apps/oracle/oraInventory/oraInst.loc' 2>> logs/3.installWEBLOGIC.log Figura 5. Script de instalação do WLS.
Procedimento 6: Criando Domínio. Com WLS já instalado, o script irá criar um grupo lógico de recursos gerenciados pela instância chamada Admin Server, que é um ponto central por onde serão configurados seus recursos relatados na sessão 4.1. Para criação de tais recursos, foi implementado um arquivo jython, pois o WLS já interpreta esta linguagem por ser nativa da ferramenta que possibilita seu gerenciamento através de linha de comando. loadProperties('./wls_python.properties') readTemplate('/apps/oracle/middleware/wlserver/common/templates/wls/wls.jar') cd('/Servers/AdminServer') set('ListenAddress',listenAdd01) set('ListenPort',int(listenPort01)) create('AdminServer','SSL') cd('SSL/AdminServer') set('Enabled', 'False') set('ListenPort',int(listenPortSsl)) set('HostnameVerificationIgnored', 'true') cd('/Security/base_domain/User/weblogic') cmo.setName(userName) cmo.setPassword(passWord) setOption('ServerStartMode', 'prod') setOption('JavaHome', javaPath) setOption('OverwriteDomain','false') writeDomain(domainsDirectory+'/'+domainName); closeTemplate();
Primeiramente foi definido um arquivo de propriedade
wls_python.properties com variáveis necessárias para criação do domínio, para
processar este arquivo utilizou-se o método loadProperties que carrega estas variáveis na execução do código pyhton. Conforme figura 6, uma vez carregada as variáveis o comando readTemplate faz a leitura do template que referencia ao arquivo JAR (Java
Archive) que contem arquivos necessários para criação do domínio, incluído uma
infraestrutura de componentes, aplicações, serviços, opções de segurança e funções operacionais para sustentar e realizar tunnig de aplicações.
Procedimento 7: Criando Manage Servers. Este recurso será criado basicamente da mesma forma que foi realizado o procedimento anterior para o Admin Server, porém este recurso por característica do produto permite que o WLST mencionado na sessão 3.2.1 seja executado somente no modo on-line, ou seja, é necessário que o Admin
Server esteja criado. Como se pode observar na figura 7, foi utilizado o método loadProperties para carregar as variáveis necessárias para configuração. O comando startServer em seguida inicia o Admin Server para disponibilizar a sessão para iniciar a
configuração dos manage servers, ou seja, se este procedimento fosse em modo gráfico sem o Admin Server não teria como abrir uma interface e realizar a configuração manual, da mesma forma se procede para configuração automatizada.
loadProperties('./wls_python.properties')
connUri = 't3://'+admAdrs+':'+admPort;
startServer(admServer, domainName, connUri, userName, passWord, domainsDirectory+'/'+domainName, 'true', 60000, 'false', jvmArgs='-XX:MaxPermSize=125m, -Xmx512m, -XX:+UseParallelGC');
connect(userName,passWord,connUri); edit()
startEdit() cd('/')
Figura 7. Código de criação do manage server.
Procedimento 8: Configuração Node Manage. O node manage tem uma importante função na administração do servidor de aplicação para sustentar, manter o
WLS, pois facilitará nas configurações, como, iniciar um manage server pela console, e
caso um manage server pare, o mesmo é Gerenciado pelo node manager para iniciar automaticamente sem que haja intervenção manual.
Todos os procedimentos anteriormente citados, são executados pelo arquivo
ppTeste.pp através do servidor master que realiza a execução do shell script 0.execAll.sh que utilizou-se o operador lógico “&&” que resulta na seqüência de
execução de cada script até a conclusão. O procedimento pode ser executado manualmente com comando puppet apply ppTeste.pp ou pode-se criar uma tarefa de
cron no puppet para executar automaticamente. Por fim o ambiente esta disponibilizado
com todos componentes necessários para que possa ser utilizado.
5. Resultados obtidos
Após realizar a instalação do servidor Weblogic aplicando as duas abordagens nos dois momentos propostos TESTE_A e TESTE_B, foi possível comparar o tempo gasto da execução automatizada (TESTE_B) e da execução manual (TESTE_A), os tempos foram definidos pelas unidades HH:MM:SS, que corresponde às horas, minutos e segundos conforme apresentadas nos dois modos de instalação conforme tabela 2.
Componente: Nome do componente instalado. Descrição: Item avaliado no processo de instalação.
Instalação Automática: Resultados obtidos utilizando a instalação automatizada.
Instalação Tradicional: Resultados obtidos utilizando a instalação manual. A principal dificuldade encontrada neste processo de automatização foi o tempo para implementação dos códigos (itens de configuração) e testes unitários realizados para verificação de falhas na execução dos mesmos.
Os tempos de medição em relação a instalação automática foram aferidos conforme registrados nos scripts e em vídeos disponibilizados, no caso da instalação automática foi registrado por vídeo.
Percebe-se que na tabela 2, os resultados obtidos demonstram um ganho de tempo com a instalação automática. A instalação do servidor de aplicação com esta abordagem gastou o tempo de 35,4 minutos, isto significa que o tempo de 35,4 minutos é inferior ao tempo da instalação tradicional de 68,6 minutos.
Observando os dados da tabela 2 existe uma diferença considerável nos tempos, como por exemplo, a cópia de arquivos da instalação tradicional que permeou em média mais de 4 minutos em relação à instalação automática, isso ocorre porque quando o tráfego é de servidor para servidor eles utilizam rede gigabit, o desktop megabit. Os tráfegos dos desktops passam por um switch 10/100 que significam que o tráfego é entre 10 megabit e 100 megabit, entretanto as redes que os servidores trafegam, os pacotes trafegam com 1000 gigabit, devido a isto a instalação automatizada trabalha somente com a rede gigabit.
Tabela 2. Comparativo entre as duas instalações.
Componente Descrição Instalação Tradicional Instalação Automática Teste_A Teste_B Teste_A Teste_B Arquivos de
Instalação Cópia de Arquivos 00:05:22 00:05:50 00:01:05 00:01:13 Jdk Instalação Java 00:01:31 00:01:47 00:00:03 00:00:03 Weblogic Instalação Weblogic 00:11:17 00:11:10 00:02:19 00:02:12 Domínio Configuração Domínio 00:08:25 00:08:11 00:04:42 00:04:57 JVM Criação da JVM 00:37:00 00:31:06 00:13:57 00:13:33 Setup Configuração para start da aplicação 00:18:17 00:20:03 00:13:53 00:13:29
Total Media tempo
gasto 68,6 minutos4116 seg 35,4 minutos2124 seg
Portanto nota-se que no método da instalação tradicional os mesmos 35,4 minutos gastos do processo automatizado para realizar 100% da instalação, foram concluídos somente 51,6% da instalação, isto significa que os outros 48,4% restantes ainda não foram concluídos no mesmo período. Na figura 8 foi apresenta o cálculo realizado utilizando-se a formula de regra de três.
68,6 minutos (tradicional) --- 100 % 35,4 minutos –--- x %
x = 51,6 %
Enquanto que no método da instalação automatizada os mesmos 51,6% referente ao método manual, foram concluídos em apenas 18,2 minutos, apresentado na figura 9.
35,4 minutos (automática) --- 100%
x minutos --- 51,6% x= 18,2 minutos
Figura 9. Cálculo de minutos gastos em 51,6% da instalação automática.
De acordo com as necessidades da GCS, uma ferramenta de controle que gerenciasse a identificação, empacotamento e uma baseline para entrega seria o suficiente, porem a utilização da IC, pode garantir que as mudanças no projeto são construídas, testadas.
Considerando as análises e os resultados conclui-se que é vantajoso utilizar o
uso da metodologia da IC para automatizar a implantação de servidores de aplicação e que apresentou significativos resultados para o ambiente corporativo. A SGC / IC possibilitou tornar a infraestrutura totalmente escalável de um ambiente para outro e programável a mudanças de acordo com a demanda de um projeto.
O resultado obtido demonstrou o aumento na produtividade de administração da infraestrutura e rapidez na entrega de atividade para o cliente.
6. Conclusão
As organizações mudaram a forma de pensar e agir com a necessidade do avanço tecnológico. Com surgimento de novas tecnologias houve-se a necessidade em adaptar-se a uma melhor estrutura física e tecnológica, fazendo com que os profissionais de TI colaborem nas organizações para satisfazer o cliente interno ou externo.
Para adaptar às mudanças tecnológicas, a metodologia da IC une pessoas, primeiramente mudando sua forma de pensar para adquirir uma TI ágil, em seguida
integra cenários que anteriormente eram separados, como a área de desenvolvimento, banco de dados e infraestrutura. A integração e automatização são dois pontos importantes quando se trata de IC, que reforça a necessidade de ter uma infraestrutura automatizada e que é possível ser programada.
Visto as vantagens da GCS em conjunto com a IC durante as duas abordagens de instalação realizadas, pode se observar o ganho de produtividade e uma melhor dinâmica de trabalho, pois possibilita uma entrega ágil, padronizada, e menor possibilidade de erros, visto que o ciclo de vida do processo de IC é interrompido imediatamente sem a possibilidade de continuidade, sendo assim, a entrega da instalação terá uma qualidade garantida no final do trabalho.
Portanto, conclui-se que foi apresentado como é possível realizar uma mudança de paradigma, em busca de uma TI ágil. Para isto foi utilizado sistema de GCS e a metodologia de IC que desenvolveu uma infraestrutura programada e escalável, utilizando teorias baseadas nas melhores práticas adotadas no mercado e ferramentas integradas que fazem com que a engine deste processo funcione sem erros, e com uma entrega satisfatória para cliente final.
Sendo assim este experimento tem como proposta futura dar continuidade na melhoria do método aplicado, reduzindo o número de ferramentas de integração utilizadas e adotar a ferramenta Docker, Ansible como ponto de integração ao ciclo do processo de GCS.
7. Referências
BECK, Kent. (1996). Smalltalk Best Practices Partterns. Editora Prentice-Hall. 147 páginas.
BECK Kent, ANDRES Cynthia. (2002). Extreme Programming Explained, Editora Addison Wesley. Boston. 224 páginas.
BUCKLE .K. Jonh (1982). Software Configuration Management - Computer
Science, Editora MacMillan. 168 páginas.
CAUM Carl (2013). Continuous Delivery Vs Continuous Deployment. Disponível em : < https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff >. Acesso 11 Dez. 2015.
DART Susan (2001). Spectrum of Functionality in Configuration Management Systems. Editora Software Environments Project. 45 páginas
DUVALL Paul M, MATYAS Steve, GLOVER Andrew (2008), Continuous
Integration, Improving Software Quality and Reducing Risk, Editora Publishing
House. 336 páginas.
DUVALL Paul M (2011).Continuous Delivery Patterns and Antipatterns in the
Software Lifecycle. Disponível em: <
http://www.dccia.ua.es/dccia/inf/asignaturas/MADS/lecturas/10_Continuous_Deliver y_Dzone_Refcardz.pdf >. Acesso em: 11 Dez. 2015
FERRARI Fabrício (2002), Curso Prático de Linux, Editora Digerati. 128 páginas. FORGEL Karl. (2007). Controle de versão com Subversion. Disponível em:
<https://svnbook-pt-br.googlecode.com/svn/snapshots/1.4/index.html>. Editora
Creative Commons. Acesso em: 17 Jun. 2015.
FOWLER, Martin (2006). Continuous Integration. Disponível em:
< http://martinfowler.com/articles/continuousIntegration.html >. Acesso em: 16 fev. 2015.
HUMBLE Jez, DAVID Farley (2010). Continuous Delivery: Reliable Software
Releases through Build, Test, and Deployment Automation. Editora
Addison-Wesley. 512 páginas
IEEE (2014).Guide to the Software Engineering Body of Knowledge. Editora ÉTS. 335 páginas.
KRUM Spencer, VAN HEVELINGEN William, KERO Ben, TURNBULL James, MCCUNE Jeffery. (2013). Pro Puppet Second Edition. Editora Apress Media. Berkley. 301 páginas.
LEON Alexis (2000). A Guide to Software Configuration Management. Editora Artech House. 382 páginas.
PRESSMAN S. Roger (2010). Software Engineering – A Practitionner's Approach. Editora McGraw-Hill. 930 páginas.
PUPPETLABS2 (2015). Module Fundamentals. Disponível em:
<https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html>. Acesso em: 18 Abril de 2015.
