Case: DevOps na AKS – Parte 2

Introdução

Estamos dando continuidade no artigo escrito sobre implantação de Devops no AKS. Já esta disponível a primeira parte onde configuramos o AKS. Nesse segunda etapa vamos iniciar a configuração das ferramentas básicas para criação do pipeline.

Preparação do Cluster – Ferramental DevOps

Container Registry

Normalmente quando você quer subir um container docker você utiliza as imagens do Docker Hub, este é o padrão.Porém você pode querer que suas imagens fiquem na sua própria infraestrutura. Veja alguns motivos para ter seu próprio servidor de imagens Docker.

  • Privacidade – Você não quer carregar suas imagens do Docker Hub, já que o Docker Hub é público, logo todos terão acesso as suas imagens Docker.
  • Disponibilidade – Não depender unicamente do Docker Hub.
  • Segurança – Configurar suas próprias políticas de segurança para o acesso as imagens.
  • Velocidade – Mantendo seu servidor de imagens na sua própria rede, você não vai precisar baixar as imagens da internet, aumentando consideravelmente sua velocidade de download.
  • CI e CD – Facilidade de integração contínua e entrega contínua, já que suas imagens personalizadas estarão disponíveis para todos os hosts Docker da sua infraestrutura.

Para podermos gerenciar imagens de containers privadas, precisaremos criar um Container Registry. A Azure fornece uma ferramenta chamada ACR – Azure Container Registry.

O Registro de Contêiner do Azure (ACR) permite armazenar imagens para todos os tipos de implantações de contêiner, incluindo DC/OS, Docker Swarm, Kubernetes e serviços do Azure como Serviço de Aplicativo, Lote, Service Fabric e outros. A equipe de DevOps pode gerenciar a configuração de aplicativos isolados da configuração do ambiente de hospedagem.

Para começar, vamos criar um registry com o comando abaixo. O parâmetro name definirá o nome do registro que deverá ser único, no exemplo abaixo clusteraksregistry, pois formará a URL: clusteraksregistry.azurecr.io. A conta do tipo “Basic” determina quanto de espaço você terá para armazenar as imagens.

Após a criação do cluster, precisamos habilitar o acesso admin:

E então precisaremos descobrir qual a senha do registry. Para exibir a senha:

Tendo a senha em mãos precisamos definir em nosso cluster um secret do tipo docker-registry. Lembre-se de trocar todos os locais com clusteraksregistry pelo nome do seu registry.

Ingress

O Ingress é um controlador de entrada. Um controlador de entrada é uma parte do software que fornece proxy reverso, roteamento de tráfego configurável e terminação TLS para serviços de Kubernetes. Os recursos de entrada de Kubernetes são usados para configurar as regras de entrada e as rotas para os serviços de Kubernetes individuais. Usando um controlador de entrada e regras de ingresso, um único endereço IP pode ser usado para rotear tráfego a vários serviços em um cluster de Kubernetes.

Para criar o controlador de entrada, use Helm para instalar nginx-ingress. Para redundância adicional, duas réplicas dos controladores de entrada NGINX são implementadas com o parâmetro --set controller.replicaCount. Para se beneficiar totalmente da execução de réplicas do controlador de entrada, verifique se há mais de um nó em seu cluster AKS.

O exemplo a seguir instala o controlador de entrada no namespace kube-system. Você poderá especificar um namespace diferente para seu próprio ambiente se desejar. Se o cluster AKS não for habilitado para RBAC, adicione –set rbac.create=false aos comandos.

Quando o serviço de balanceador de carga do Kubernetes é criado para o controlador de entrada NGINX, um endereço IP público dinâmico é atribuído, conforme mostrado na seguinte saída de exemplo:

Certificados SSLs

Existem dois projetos muito utilizados para conceder certificados SSL para suas aplicações apartir do Let’s Encrypt. O primeiro foi o kube-lego, muito utilizado, que agora passa a ser substituido pelo cert-manager. A tabela abaixo mostra um compartivo entre os dois.

Feature kube-lego cert-manager
Configuration Annotations on Ingress resources CRDs
CAs ACME ACME, signing key pair
Kubernetes v1.2 – v1.8 v1.7+
Debugging Look at logs Kubernetes Events API
Multi-tenancy Not supported Supported
Distinct issuance sources per Certificate Not supported Supported
Ingress controller support (ACME) GCE, NGINX All

Kubernetes < 1.8

A instalação do kube-lego, pode ser feita diretamente via Helm. Segue abaixo um exemplo de comando para instalação.

Kubernetes > 1.7

A instalação do Cert-Manager é um pouco mais complicada. E como durante a instalação desse case, utilizamo o kube-lego, deixarei essa explicação para outro momento.

Jenkins

Para instalação do Jenkins, vamos clonar o chart estável e fazer as alterações para customizar nossa instalação do Jenkins via Helm.

Clonar o charts do Jenkins

Use o comando abaixo para clonar os charts:

Vamos agora editar o arquivo values.xml, busque pela sessão InstallPlugins, as versão não precisam ser idênticas, porém garantam que os plugins abaixo estejam entre os instalados.

Caso você vá usar um Ingress para gerenciar todas as conexões de entrada do cluster mude o ServiceType de LoadBalancer para ClusterIP. Caso deixe como LoadBalancer, um IP público será atribuído para service.

Localize a sessão JavaOpts

Localize a sessão ScriptApproval e ajuste os scripts de aprovação.

Se necessário ajuste também o uso de recursos:

Salve as alterações no arquivo, respeitando corretamente as indentações.

Ao término execute o comando para instalar o jenkins usando o arquivo alterado.

Caso não esteja na pasta:

ou se estiver na pasta:

Configurar o Ingress para Jenkins

Para rotear o tráfego para jenkins, crie um recurso de entrada do Kubernetes. O recurso de entrada configura as regras que roteiam o tráfego para um aplicativo.

No exemplo a seguir, o tráfego para o endereço jenkins.devops.empresa.com.br é roteado para o serviço nomeado jenkins.

Crie um arquivo chamado ingress-nginx-jenkins.yaml e copie-o no YAML de exemplo a seguir.

Caso não tenha definido o atributo AdminPassword no arquivo values.yaml, a senha será gerada automaticamente de forma randômica dentro de um secret. Use o comando abaixo para descobrir qual é a senha.

Sonarqube

Vamos criar o Sonarqube. Por default ele não possui armazenamento, em alguns casos isso gera problemas quando o cluster é parado e reiniciado diariamente, para evitar esses problemas precisamos criar um volume para persistência dos dados.

Configurar o Ingress para o Sonarqube

Abaixo temos o arquivo para criação do domínio para acessar o Sonarqube. No exemplo vamos redirecionar sonar.devops.empresa.com.br para service do Sonar.

Aplique as configurações para criação do serviço do Ingress.

Nexus

Configurar o Ingress para o Sonarqube

Abaixo temos o arquivo para criação do domínio para acessar o Sonarqube. No exemplo vamos redirecionar nexus.devops.empresa.com.br para service do Nexus

Aplique as configurações para criação do serviço do Ingress.

Leave a Reply

Pin It on Pinterest