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.
|
1 2 3 4 |
az acr create --resource-group ClusterAKSResourceGroup \ --name clusteraksregistry \ --sku Basic |
Após a criação do cluster, precisamos habilitar o acesso admin:
|
1 2 |
az acr update -n clusteraksregistry --admin-enabled true |
E então precisaremos descobrir qual a senha do registry. Para exibir a senha:
|
1 2 |
az acr credential show --name clusteraksregistry --query passwords[0] |
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.
|
1 2 3 4 5 6 |
kubectl create secret docker-registry acrcredentials \ --docker-server=clusteraksregistry.azurecr.io \ --docker-username=clusteraksregistry \ --docker-password=kJAYQFLLnLcWNU3ceZMc1Rr0RYfH/UFz \ --docker-email=fulano@empresa.com.br |
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.
|
1 2 3 |
helm install stable/nginx-ingress --namespace kube-system \ --set controller.replicaCount=2 |
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:
|
1 2 3 4 5 6 |
$ kubectl get service -l app=nginx-ingress --namespace kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE masked-otter-nginx-ingress-controller LoadBalancer 10.0.92.99 40.117.74.8 80:31077/TCP,443:32592/TCP 7m masked-otter-nginx-ingress-default-backend ClusterIP 10.0.46.106 <none> 80/TCP 7m |
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.
|
1 2 3 4 |
helm install stable/kube-lego \ --namespace kube-system \ --set config.LEGO_EMAIL=fulano@empresa.com.br,config.LEGO_URL=https://acme-v01.api.letsencrypt.org/directory |
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:
|
1 2 3 |
git clone https://github.com/kubernetes/charts cd charts/stable/jenkins |
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.
|
1 2 3 4 5 6 7 8 9 |
InstallPlugins: - kubernetes:1.2 - workflow-aggregator:2.5 - workflow-job:2.17 - credentials-binding:1.15 - git:3.7.0 - ghprb:1.40.0 - blueocean:1.4.1 |
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.
|
1 2 |
ServiceType: ClusterIP |
Localize a sessão JavaOpts
|
1 2 3 |
JavaOpts: > -Dmail.smtp.starttls.enable=true |
Localize a sessão ScriptApproval e ajuste os scripts de aprovação.
|
1 2 3 4 5 6 7 8 9 |
ScriptApproval: - "method groovy.json.JsonSlurperClassic parseText java.lang.String" - "new groovy.json.JsonSlurperClassic" - "staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods leftShift java.util.Map java.util.Map" - "staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods split java.lang.String" - "method java.util.Collection toArray" - "staticMethod org.kohsuke.groovy.sandbox.impl.Checker checkedCall java.lang.Object boolean boolean java.lang.String java.lang.Object[]" - "staticMethod org.kohsuke.groovy.sandbox.impl.Checker checkedGetProperty java.lang.Object boolean boolean java.lang.Object" |
Se necessário ajuste também o uso de recursos:
|
1 2 3 |
Cpu: "200m" Memory: "1024Mi" |
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:
|
1 2 |
helm install --name jenkins -f stable/jenkint/values.yaml stable/jenkins |
ou se estiver na pasta:
|
1 2 |
helm install --name jenkins -f values.yaml . |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: jenkins-devops-ingress annotations: kubernetes.io/tls-acme: "true" nginx.ingress.kubernetes.io/rewrite-target: / spec: tls: - hosts: - jenkins.devops.empresa.com.br secretName: tls-secret rules: - host: jenkins.devops.empresa.com.br http: paths: - path: / backend: serviceName: jenkins servicePort: 8080 |
|
1 2 |
kubectl apply -f ingress-nginx-jenkins.yaml |
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.
|
1 2 |
printf $(kubectl get secret --namespace default jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo |
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.
|
1 2 |
helm install --name sonar stable/sonarqube --set persistence.enabled=true,persistence.accessMode="ReadWriteOnce",persistence.size=8Gi |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: sonar-devops-ingress annotations: kubernetes.io/tls-acme: "true" nginx.ingress.kubernetes.io/rewrite-target: / spec: tls: - hosts: - sonar.devops.empresa.com.br secretName: tls-secret rules: - host: sonar.devops.empresa.com.br http: paths: - path: / backend: serviceName: sonar servicePort: 9000 |
Aplique as configurações para criação do serviço do Ingress.
|
1 2 |
kubectl apply -f ingress-nginx-sonar.yaml |
Nexus
|
1 2 |
helm install --name registry stable/sonatype-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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nexus-devops-ingress annotations: kubernetes.io/tls-acme: "true" nginx.ingress.kubernetes.io/rewrite-target: / spec: tls: - hosts: - nexus.devops.empresa.com.br secretName: tls-secret rules: - host: nexus.devops.empresa.com.br http: paths: - path: / backend: serviceName: registry-sonatype-nexus servicePort: 8081 |
Aplique as configurações para criação do serviço do Ingress.
|
1 2 |
kubectl apply -f ingress-nginx-nexus.yaml |
