DevSecOps

7 nov, 2018

10 dicas para usar containers na otimização do seu aplicativo

Publicidade

Nuvem, containers Linux e orquestração de containers (na forma de Kubernetes) são os tópicos mais discutidos hoje em dia. Boa parte das organizações de TI também está falando sobre DevOps e microsserviços.

A vontade de aprofundar esse conjunto de novas experiências está levando muitas companhias a repensar ferramentas, cultura e processos internamente. Afinal, as empresas querem todos os benefícios dessa transformação digital, mas será que elas estão realmente preparadas para esse novo paradigma? Estão realmente prontas para os containers?

Seja para padronizar ambientes, isolar processos ou aumentar a modularidade, poder produzir melhores códigos, serviços e manutenção, a solução que vem a calhar são os containers. Com uma pegada (footprint) menor, padronizada e isolada, enquanto consomem os recursos do host – os containers são a receita perfeita. Mas como usá-los de modo a obter lucro e todos esses benefícios? Veja a seguir dez passos para chegar lá!

1 – Desmembre sua aplicação em Microsserviços

Quando pensamos em modularidade, temos que começar a dividir o aplicativo monolítico em partes menores, onde uma peça não influencia o comportamento de outra. Em vez disso, cada peça tem uma única responsabilidade. Já em um aplicativo monolítico, um problema em uma pequena parte pode ter um efeito cascata no restante da funcionalidade.

Se tiver desmembrado esse aplicativo em serviços pequenos, no caso de você ter um problema de pagamento por cartão de crédito, os usuários que estiverem fazendo relatórios, verificando a página inicial, pagando com cartões de débito, bitcoins, etc., não devem ser afetados porque estão usando outros métodos. E como seus serviços são isolados e independentes, um problema em um container/aplicativo não deve interferir em outro.

2 – Gerencie seus containers

Ao adicionar containers Linux a um ambiente e substituir aplicações monolíticas com containers, é possível endereçar uma série de questões. Mas assim que você separa seu grande app em microsserviços e os coloca em containers, como você vai gerir e desfrutar dos benefícios reais? É preciso definir permissões de usuários? Devo armazenar dados dentro de um container? E quanto às sessões HTTP? E a autenticação de microsserviço?

Um container é fácil de gerenciar. Porém, quando falamos de dez, cem ou mil, não é bem assim. Como você pode aumentar o número de containers em execução quando a carga do site aumenta? Ou como você pode escalá-lo durante a noite quando ninguém está acessando? Que tal ter uma maneira de fazer isso automaticamente? Como ou onde o log pode ser gravado pelo seu aplicativo? E como você pode acessá-los mais tarde?

Os containers incluem o ambiente necessário para sua aplicação, fornecem isolamento e são independentes, o que significa que não requerem outros containers ou recursos externos. No entanto, é possível ter um banco de dados ou outros serviços vinculados ou dependentes dele. E como os containers são isolados, a premissa é que terão o mesmo comportamento, independentemente do ambiente. Você não ouvirá mais “funciona no meu laptop”.

3 – Evite rodar como Root

O usuário que será configurado para executar seu aplicativo não deve ser root. Ele deve ter os direitos necessários para escrever e ler nos diretórios que seu aplicativo precisa, e é isso. Não há mais direitos do que o necessário.

Atribuir as permissões e a propriedade corretas à pasta necessária é uma prática recomendada para controlar e manter seu ambiente.

4 – Faça o Logging por meio da saída padrão

Como o aplicativo está sendo executado agora dentro de um container, e o próprio container é efêmero, o registro torna-se um pouco mais complexo, já que você não pode mais simplesmente gravar em /var /log/qualquer coisa. Se os logs do seu aplicativo não forem gravados em /var/log, o que devemos fazer? Nós os enviamos para a saída padrão (STDOUT).

Sabemos que este aplicativo tem a finalidade de coletar e armazenar logs que podem fazer o trabalho. Consequentemente, os logs podem ser acessados em todo o aplicativo a qualquer momento. Não é necessário que os desenvolvedores solicitem logs da equipe de operações e não é necessário copiar os registros para os desenvolvedores analisarem.

5 – Armazene dados de forma dedicada

Se o seu aplicativo usar qualquer diretório para persistir uma configuração ou persistir qualquer tipo de dado dentro do container, por exemplo, gravar informações em um banco de dados, em primeiro lugar você deve repensar a necessidade de gravar localmente. Como os containers entram em ação, o banco de dados ou diretórios devem ser gravados em armazenamento dedicado, o qual o seu container lerá/gravará, integrado por sua solução de orquestração de containers.

Por que integrado? Se você usar o OpenShift, poderá integrar suas soluções da plataforma de container com armazenamento, como o Red Hat OpenShift Container Storage. Portanto, a solução de armazenamento fornecerá o armazenamento solicitado sob demanda para aplicativos executados em contêineres no OpenShift.

6 – Evite a declaração “CMD”

Muitos exemplos na internet mostram a execução do seu aplicativo usando a instrução “CMD” no seu Dockerfile. Esse comando não garante que seu aplicativo seja executado no caso de outro comando ser passado como um parâmetro para o container. Use “ENTRYPOINT” em vez disso. O ENTRYPOINT garante que seu aplicativo/serviço/processo será executado, independentemente do parâmetro passado para o container.

7 – Faça a autenticação em um aplicativo à parte

Uma coisa que também deve ser considerada é que quando você começa a dividir seu serviço em microsserviços, algumas responsabilidades são tiradas dele. Uma delas é a autenticação. Seu aplicativo não precisa ser responsável pela autenticação. E se um aplicativo projetado apenas para isso pudesse autenticar e autorizar seus microsserviços? Seu aplicativo só teria a responsabilidade de fazer o que foi projetado para fazer. Para ajudá-lo a implementar esse tipo de serviço, você deve considerar o uso de aplicativos de Logon Único, como o Red Hat Single Sign On.

8 – O mesmo vale para o armazenamento em cache

Mais uma vez, os containers são efêmeros, e não é responsabilidade do aplicativo armazenar dados em cache por si só. Essa responsabilidade deve ser atribuída a um aplicativo projetado com essa finalidade. Esse é um motivo pelo qual os aplicativos de cache estão se tornando cada vez mais populares nos dias de hoje.

O Redis, por exemplo, é um projeto de código aberto que ajuda seu microsserviço a armazenar dados em cache. Pensando um pouco mais além, o que acontece com a replicação de dados cross-site (entre data centers).

Aplicativos de cache, como o Red Hat JBoss Data Grid, ajudam seus serviços a armazenar e buscar dados e evitar perda usando a capacidade de replicação entre sites.

9 – Orquestre a operação dos seus containers

Recipientes não são a bala de prata. Containers por si só não podem resolver seus problemas, complexidades, automação e escalabilidade. Uma maneira de resolver esses problemas é adotar uma ferramenta de orquestração de containers, responsável por criar, implantar, gerenciar e dimensionar aplicativos.

Você pode usar a plataforma baseada no OpenShift Kubernetes da Red Hat, por exemplo, para construir seu aplicativo em um container. Por meio dela, é possível ampliar e manter o número de réplicas de containers em seu ambiente e diminuir quando não forem mais usados. Alta disponibilidade e recursos de escalabilidade são trazidos para você.

O OpenShift também oferece a possibilidade de fazer uma verificação de integridade em seus containers, para que recebam tráfego somente se ainda estiverem em execução e prontos para isso. Se o container falhar na verificação de disponibilidade ou no probe “liveness”, o OpenShift encerrará o container e o reiniciará com base na política da aplicação. Consequentemente, os usuários não devem ser encaminhados para containers que não estão atendendo às solicitações.

10 – Implemente aplicativos facilmente

Para usar os containers em sua totalidade, você precisará pensar em escala e orquestração e, ao mesmo tempo, em como atingir todos esses pontos. Isso é possível quando a adoção do Openshift entra em cena. Ele realmente permite que sua equipe implante aplicativos em containers. Por padrão, o OpenShift não permite que containers sejam executados usando o usuário root, embora seja possível configurar uma exceção.

Seus registros podem ser consultados em um painel Kibana, fornecido pela pilha EFK (Elasticsearch, FluentD e Kibana), e ele é multilocatário. Os dados do aplicativo devem ser armazenados em uma solução que seja fácil de conectar ao OpenShift, como o OpenShift Container Storage.

Como o OpenShift é baseado no Kubernetes, ele lida com a orquestração, a implantação e também com o desenvolvimento de versões. Além disso, um roteador receberá todo o tráfego externo para seus serviços de aplicativos. Os serviços equilibrarão toda a solicitação entre os containers. Estando ciente de todos os tópicos listados, com certeza você pode alcançar os containers da sua empresa.