Serviços

O que é o OpenShift?

Continuando com os posts sobre as ferramentas de DevOps, vamos abordar uma ferramenta que vem se tornando cada vez mais popular: o OpenShift, da Red Hat.

O que vem a ser o OpenShift?

O OpenShift é uma plataforma de código aberto desenvolvida pela Red Hat que auxilia no processo de orquestração de containers baseada em Kubernetes e containers Linux de maneira independente da plataforma na qual os containers serão executados.

Através de uma interface muito amigável e intuitiva, o OpenShift oferece a possibilidade de controlar todo o ciclo de vida de uma aplicação baseada em containers, desde o deploy até a execução efetiva.

Isso é possível graças a integração facilitada com várias outras ferramentas e SDKs para diferentes linguagens, o que torna o OpenShift uma ferramenta muito competente e completa não somente para o gerenciamento de containers, mas também para o controle de todo o ciclo de vida de uma aplicação.

O diagrama abaixo, fornecido pela própria Red Hat, oferece uma visão geral das ferramentas que são integradas e orquestradas pelo OpenShift.

Pela imagem acima, podemos perceber que o OpenShift oferece uma infinidade de serviços, como gerenciamento dos processos de integração contínua/entrega contínua (CI/CD), gerenciamento de configurações e logs, monitoramento da saúde das aplicações e containers que estão sendo gerenciados e até mesmo aspectos de segurança, isso tudo de maneira completamente desacoplada do container e/ou da infraestrutura que você esteja utilizando.

Segundo a Red Hat, o OpenShift consegue oferecer todos estes serviços por ser fundamentado em uma arquitetura baseada em microsserviços que conseguem se “encaixar” uns aos outros e prover as diferentes funcionalidades que cada projeto necessita.

Como o OpenShift funciona?

Segundo a Red Hat, o OpenShift funciona em cima de um sistema baseado em camadas, onde cada camada é responsável por determinada funcionalidade. A sobreposição destas camadas é que faz com que o OpenShift consiga oferecer a quantidade de funcionalidades que são oferecidas.

A imagem abaixo, retirada da própria documentação do OpenShift ilustra estas sobreposições de camadas.

No diagrama acima, percebemos inicialmente um benefício importantíssimo do OpenShift: ele é agnóstico a ferramentas de Continuous Integration/Continuous Delivery e também a ferramentas de automação de operações, como ferramentas de automação de provisionamento de infraestrutura. Isso quer dizer que você pode utilizar o OpenShift com o Jenkins, CircleCI, TravisCI, GitLab, Terraform ou qualquer uma das ferramentas desse nicho.

O OpenShift roda em cima de cluster baseado no Kubernetes, cluster no qual os componentes são organizados em um esquema de microsserviços. Estes componentes do coração do OpenShift ficam em um nó master dentro dessa infraestrutura. Entre estes componentes que ficam dentro desse nó master, podemos destacar:

  • API/Authentication: controle de acesso às APIs do OpenShift e do Kubernetes. Esse processo de autenticação é baseado no padrão OAuth e em certificados SSL;
  • Data Store: responsável por armazenar o estado e outras informações e meta-informações dos componentes do OpenShift. O OpenShift geralmente utiliza o etcd, uma estrutura de armazenamento baseada em chave/valor, para realizar o armazenamento destes dados;
  • Scheduler: responsável por distribuir as cargas de trabalho entre nós dos clusters de componentes do OpenShift. Trata-se de um dos principais componentes do OpenShift;
  • Management/Replication: mecanismo responsável pelo processo de replicação e por coletar informações sobre o estado dos componentes e elementos do cluster. Ele é basicamente um loop infinito que, de tempos em tempos, coleta estes dados e atualiza o estado dos componentes, armazenando estes estados no Data Store (etcd). Estes processos são controlados através de estruturas chamadas controllers. Os principais controllers dentro do OpenShift são: replication controller, endpoint controller, namespace controller e service account controller. É importante salientar que as informações coletadas pelos controllers refletem na API exposta pelo nó master, assim como os comandos dados às APIs do OpenShift e do Kubernetes são executados de fato também pelos controllers.

As aplicações acabam ficando armazenadas nos outros nós da infraestrutura do OpenShift. Na ilustração acima, por exemplo, temos uma estrutura inspirada no Docker: temos as aplicações dentro de containers, containers estes que ficam agrupados pelos pods. Todos estes pods desenvolvem seu ciclo de vida dentro de um nó, ou seja: uma máquina que faz parte do cluster Kubernetes gerenciado pelo OpenShift.

A relação entre o OpenShift e o OKD

O OKD é basicamente uma distribuição “personalizada” do Kubernetes. OKD é um acrônimo para “Origin Kubernetes Distribution”. O OKD foi criado pela Red Hat para que existisse uma distribuição do Kubernetes mais otimizada para processos tradicionais em ambientes baseados em nuvem, como aplicações multi-tenancy e aplicação de processos de continuous delivery/continuous integration. Ou seja: o OKD é um Kubernetes otimizado para as situações previamente citadas, otimizações estas realizadas pela Red Hat.

O OKD não é concorrente do OpenShift. Na verdade, o core do OpenShift é justamente o OKD. A estrutura baseada em Kubernetes que é utilizada pelo OpenShift é, na verdade, o OKD. Caso você julgue necessário, você pode utilizar o OKD de maneira direta, ou seja: sem passar necessariamente pelo OpenShift.

Segurança em SOA: Como proteger os web services?

No último artigo sobre SOA, vimos sobre a Arquitetura Orientada a Serviços e como ela funciona. Vimos que uma implementação dessa arquitetura pode ser realizada com qualquer tecnologia baseada em web, mas geralmente a SOA é implementada utilizando Web Services, já que estes são fáceis de implementar e distribuir. Estes mesmos web services também são responsáveis por expor, através de uma rede, um determinado serviço. Sendo assim, eles precisam de uma atenção especial quanto à segurança. Como saber se meus web services estão realmente protegidos?

Serviços

Antes de qualquer coisa vamos retomar à definição sobre o que é um serviço. Para que se possa ter uma real governança em TI em uma empresa é necessário saber que isso não é atingido do dia para a noite. É um processo de longo prazo, por isso exige muita cautela dos processos como um todo, mantendo um alinhamento estratégico entre o negócio e a TI. O Negócio e a TI precisam trabalhar juntos!

Um dos autores mais famosos deste segmento, Thomas Erl, escreveu o livro SOA: Princípios do Design de Serviços, onde ele aborda 8 “regras” para definir um serviço. Nesse livro, ele enumera o que considera essencial para fazer uso da SOA “de verdade”. São eles:

Serviços são reutilizáveis

Essa é talvez uma das principais regras. Para isso acontecer, é necessária a interação da TI e do negócio. Quanto mais um serviço for genérico e puder ser reaproveitado, melhor!

Serviços compartilham um contrato formal

Todo serviço deve vir acompanhado de um “contrato”, onde ele deve informar o que o serviço faz e como ele se comunica.

Serviços possuem baixo acoplamento

Baixo acoplamento significa que certas implementações de um serviço podem ser modificadas, evoluídas e até mesmo substituídas, sem afetar negativamente os consumidores deste serviço.

Serviços abstraem a lógica

Serviços não devem expressar as regras de negócio. Os serviços SOA devem guardar os detalhes de sua implementação, até mesmo caso seja preciso modificar a lógica do negócio, não comprometendo as obrigações do serviço escritos no seu contrato.

Serviços são capazes de se compor de outros serviços

A composição também é uma forma de reutilização. Sendo assim, um serviço pode muito bem chamar um outro serviço para executar a sua tarefa.

Serviços são autônomos

Um serviço também deve ser autônomo, ou seja, apenas ele é suficiente para executar sua lógica.

Serviços evitam alocação de recursos por longos períodos

Quando um serviço é reutilizado, devemos tomar alguns cuidados. Não se deve criar muitas instâncias de um mesmo serviço, pois isso pode sobrecarregar a infra-estrutura. Para isso não acontecer, o serviço deve evitar reter informações específicas em uma determinada atividade.

Serviços devem possuir a capacidade de serem descobertos

O que eu quero dizer é que a capacidade dos serviços serem descobertos significa a visibilidade deles.

Para que isso ocorra, o contrato deve ser bem descrito, evitando que novos requerimentos resultem em serviços redundantes.

Agora que já entendemos um pouco melhor sobre como nossos serviços devem se comportar, vamos a um outro ponto do nosso artigo.

Imagine que uma empresa esteja fazendo o uso de SOA. O que pode acontecer se ela estiver utilizando um web service onde suas informações estão trafegando pela rede sem proteção???

Isso mesmo: acessos indevidos e possíveis interceptações das informações que trafegam pela infraestrutura dos serviços SOA!

Sendo assim, a necessidade de se proteger os recursos envolvidos com a aplicação da SOA no ambiente de TI é uma necessidade real.

Conheça o WS-Security: Segurança para Web Services

A tecnologia WS-Security (Web Services Security) é um padrão que tem a intenção de apoiar a SOA no sentido de prover segurança quando os dados são trocados. O WS-Security disponibiliza um sistema rico para prover segurança, tanto em confidencialidade quanto em autenticação.

Apesar disso, o WS-Security não funciona sozinho. Ele funciona em conjunto com as especificações WS-Policy e WS-SecurityPolicy. Essas especificações têm por objetivo, respectivamente, estabelecer políticas gerais a respeito de segurança, qualidade de serviço, confiabilidade; além de estabelecer quais são as políticas de segurança aplicáveis a um determinado serviço.

Na figura abaixo, podemos ver a estrutura de segurança que é fornecida pelo WS-Security, fazendo também uso da estrutura do WS-Policy.

Esses conceitos são baseados em cinco requisitos comuns de segurança: identificação, autenticação, autorização, confidencialidade e integridade.

Se um solicitante quiser acessar os serviços em segurança, primeiramente ele deve fornecer informações que expressem a sua origem. O WS-Security armazena essas informações em um cabeçalho padronizado, cujo ponto é referido como um token.

A autenticação requer a prova de que a mensagem que está sendo entregue ao destinatário é realmente do remetente que alega ser, fornecendo uma prova de que sua identidade reivindicada é verdadeira.

Após a autenticação, o destinatário pode precisar determinar se o solicitante está autorizado a fazer o que ele tenta fazer. Isto é chamado de autorização. Já a confidencialidade está diretamente ligada com a proteção e privacidade do conteúdo da mensagem, onde a mensagem deve ser mantida como confidencial e nenhum serviço ou mensagem não autorizada deve ver seu conteúdo.

Por último, temos a integridade, que garante que a mensagem não foi alterada desde a sua saída do remetente, garantindo que a mensagem permaneceu intacta a partir do momento de transmissão para o ponto de entrega.

Percebe a necessidade de se proteger as estruturas SOA em uma organização? Os benefícios adquiridos são muitos. Fazendo o uso correto das normas de segurança, a empresa poderá se beneficiar com o uso da SOA sem se preocupar com a integridade de suas informações, ponto de preocupação este que é de certa forma recorrente em organizações que iniciam o processo de adoção de uma arquitetura SOA.

Você sabe o que é Arquitetura Orientada a Serviços (SOA)?

Quando estamos lidando com aplicações a nível empresarial, é muito comum ouvirmos sobre uns tais de Serviços SOA. É comum até mesmo ouvirmos os termos “barramento SOA” ou “fachada SOA”. E tudo isso dentro do que geralmente chamam de “arquitetura SOA”. Mas, o que é tudo isso? Será que estamos falando simplesmente de web services?

Afinal, o que realmente vem a ser SOA?

Uma solução fundamentada em SOA geralmente possui uma arquitetura baseada em padrões para a criação de uma infraestrutura de TI, visando simplificar as relações entre sistemas distintos, aperfeiçoando seu funcionamento e facilitando a incorporação de novos elementos. Sendo assim, caso haja mudanças nas necessidades do negócio, estes fatores permitem que a empresa responda a isso de forma rápida.

Essa exposição de regras de negócio é realizada basicamente através dos famosos web services, pois são eles que determinam os padrões e acabam especificando essa infraestrutura de TI que foi citada. A vantagem de termos essa estrutura em uma organização é justamente a flexibilidade que os web services trazem. Para isso ficar mais claro, vamos utilizar o seguinte exemplo:

Imagine que você tem uma infinidade de softwares que devem ser capazes de fazer a inserção de um novo cliente na base de dados de sua empresa. Cada um destes softwares é mantido por um prestador de serviços diferente e, pior ainda, cada um destes softwares foi escrito em uma linguagem diferente. Para piorar mais um pouquinho: sua organização tem uma série de validações que precisam ser realizadas antes de permitir a inserção desse novo cliente, sendo mandatório que todos os softwares realizem essas validações da maneira correta.

Para muitas empresas este é um cenário caótico. São sistemas que utilizam linguagens diferentes e desenvolvidos por pessoas diferentes fazendo a interação direta com o negócio da sua organização, além de existirem regras de validação a serem seguidas para garantir o sucesso e efetividade do negócio.

Sendo assim, como lidar com um cenário tão divergente?

Esse é exatamente o cenário perfeito para a utilização da arquitetura SOA, pois temos ativos de negócio envolvidos em um ambiente completamente heterogêneo. E todo mundo precisa conversar entre si.

Pensando em uma arquitetura voltada a serviços, nós poderíamos resolver isso de maneira muito fácil. Poderíamos criar um web service chamado “IncluirCliente”. Este web service será responsável por fazer todas as validações do cliente antes de o inserir na base de dados. Assim, caberia aos demais softwares simplesmente consumir esse serviço da maneira adequada.

Agora as coisas ficaram muito mais simples. Conseguimos centralizar o nosso ativo de negócio (no caso, o cliente e a sua inserção), garantindo que o fluxo de negócio dele sempre ocorra da maneira correta (temos certeza que o cliente sempre vai ser validado da maneira correta).

Também garantimos reutilização com esse web service: para qualquer software que necessite incluir clientes na base da organização, bastará a utilização deste web service. Sendo assim, facilitamos a relação entre os sistemas distintos da organização, pois qualquer linguagem é capaz de consumir um web service, o que coloca um pouco de ordem neste nosso ambiente completamente heterogêneo.

Por fim, garantimos extensibilidade pois, se quisermos um dia alterar a regra de negócio de validação do cliente ou mesmo acrescentar novas etapas do negócio, basta modificarmos o web service. Todos os softwares que consomem este web service serão automaticamente “atualizados”. Esta é a arquitetura SOA!

Mas então é só eu criar web services para que eu tenha uma arquitetura SOA?

Não, não basta criarmos e expormos web services para dizer que estamos utilizando uma arquitetura orientada a serviços. Perceba que temos um problema que vai muito além da questão técnica de criar ou não um web service em uma determinada linguagem. Temos a barreira do negócio. O modelo de negócio da organização fica exposto nos serviços quando estamos utilizando SOA. Por isso, é essencial uma completa integração entre o setor de negócios e o setor de tecnologia. Essa é outra intenção da utilização da arquitetura SOA: implementar tecnologia de ponta para o negócio da empresa, tornando-a mais competitiva no mercado.

Temos ainda várias outras questões envolvidas nesse processo: como fica a segurança dos dados trafegados, já que serviços SOA certamente receberão dados sensíveis para o negócio? Como saber o que pode ser exposto e o que não pode ser exposto? Como conseguir ter governança de TI de verdade em um ambiente orientado a serviços?

Nos próximos posts dessa série, iremos discutir mais sobre estes pontos. Até lá!

JUNTE-SE A MAIS DE 150.000 PROGRAMADORES