Introdução
Neste artigo, vamos descrever todo processo realizado para implantação de uma esteira ferramental de DevOps utilizando a nuvem da Azure, com o seu serviço de Kubernetes gerenciado, chamado de AKS (Azure Kubernetes Services). Esse processo foi realizado em uma empresa com um único sistema legado altamente complexo, que desejava crescer utilizando novas tecnologias voltadas a microserviços.
Cenário Atual
Hoje a empresa possui um sistema legado utilizando tecnologia Java, utilizando paginas JSPs, com algo em torno de 2700 páginas, altamente acoplado, não tendo sido atualizado tecnologicamente ao longo do tempo. O processo de desenvolvimento atual era todo controlado manualmente por desenvolvedor/gerente de projetos.
Instalação das Ferramentas
Para esse tutorial será preciso preparar a máquina com as ferramentas necessárias.
- Azure Cli – Página da Microsoft.
- kubectl – Página do Kubernetes ou
az aks install-cli
. - helm – Página do Helm.
Criação do Cluster
Vamos realizar o login no AKS
1 2 |
az login |
Esse login irá redirecioná-lo para a página de login da microsoft.
Caso deseje logar diretamente do console use:
1 2 |
az login -u <username> -p <password> |
Ou se você não tiver o login e senha poderá pedir para que alguém que o possua libere o acesso a você através do comando:
1 2 |
az login --use-device-code |
Esse comando retornará uma mensagem como essa abaixo, e ficará esperando até que o login seja executado.
1 2 |
To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code BG3NVHPMB to authenticate. |
Após o login podemos criar um grupo de recursos caso ainda não exista.
1 2 |
az group create --name ClusterAKSResourceGroup --location eastus |
Com o grupo de recurso criado, vamos criar o cluster. Observe o comando abaixo, nele o parâmetro name
será o nome do nosso cluster, o parâmetro node-count
definirá o número de nós que o cluster terá, o padrão é 3, o parâmetro node-vm-size
definirá os recursos de cada nó, o padrão hoje é Standard_DS2_v2 (2 vCPU, 7GB de RAM). Lembre-se que o nós de um cluster precisam ser idênticos, assim o tipo de nó definido na criação será o mesmo quando estar houver a escalonamento do cluster, não podendo ser alterados depois, apenas alterando o número de nós.
1 2 3 4 5 6 |
az aks create --resource-group ClusterAKSResourceGroup \ --name ClusterAKS \ --generate-ssh-keys \ --node-count 3 \ --node-vm-size Standard_DS2_v2 |
O comando abaixo cria o número em uma rede já existente (parâmetro vnet-subnet-id
) e defini um endereço IP diferente do padrão 10.0.0.0/24
para evitar problemas de coexistência de redes.
1 2 3 4 5 6 7 8 9 10 11 |
az aks create --resource-group ClusterAKSResourceGroup \ --name ClusterAKS \ --generate-ssh-keys \ --node-count 3 \ --node-vm-size Standard_DS2_v2 \ --network-plugin azure \ --vnet-subnet-id <subnet-id> \ --docker-bridge-address 172.17.0.1/16 \ --dns-service-ip 192.1.0.10 \ --service-cidr 192.1.0.0/24 |
Caso seja preciso aumentar o número de nós do cluster.
1 2 3 4 |
az aks scale --resource-group ClusterAKSResourceGroup \ --name ClusterAKS \ --node-count 4 |
Setup das Ferramentas
Kubectl
Com o cluster criado vamos agora obter acesso ao cluster. É preciso obter as credenciais e caminhos para gerenciamento do cluster. Isso é feito via az cli
.
1 2 |
az aks get-credentials --resource-group ClusterAKSResourceGroup --name ClusterAKS |
Para testarmos liste os nós do cluster com o seguinte comando:
1 2 |
kubectl get nodes |
A saída será algo assim:
1 2 3 4 |
NAME STATUS ROLES AGE VERSION aks-agentpool-50765233-0 Ready agent 11d v1.9.11 aks-agentpool-50765233-1 Ready agent 7d v1.9.11 |
Para obter as informações do nosso cluster rode o seguinte comando:
1 2 |
kubectl cluster-info |
A saída será algo assim:
1 2 3 4 5 6 7 8 9 |
Kubernetes master is running at https://devops-XXXXXXX.hcp.eastus.azmk8s.io:443 addon-http-application-routing-default-http-backend is running at https://devops-XXXXXXX.hcp.eastus.azmk8s.io:443/api/v1/namespaces/kube-system/services/addon-http-application-routing-default-http-backend/proxy addon-http-application-routing-nginx-ingress is running at http://104.211.36.102:80 http://104.211.36.102:443 Heapster is running at https://devops-XXXXXXX.hcp.eastus.azmk8s.io:443/api/v1/namespaces/kube-system/services/heapster/proxy KubeDNS is running at https://devops-XXXXXXX.hcp.eastus.azmk8s.io:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy kubernetes-dashboard is running at https://devops-XXXXXXX.hcp.eastus.azmk8s.io:443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. |
Helm
Helm é uma ferramenta de empacotamento de software livre que ajuda a instalar e gerenciar o ciclo de vida de aplicativos Kubernetes. Semelhante a gerenciadores de pacotes do Linux, como APT e Yum, o Helm é usado para gerenciar charts
Kubernetes, que são pacotes de recursos de Kubernetes pré-configurados.
Criar uma conta de serviço (RBAC Habilitado)
Antes de implantar o Helm em um cluster AKS habilitado para RBAC, você precisa de uma conta de serviço e ligação de função para o serviço do Tiller. Para obter mais informações sobre como proteger o Helm / cluster habilitado para o Tiller em um RBAC, consulte Tiller, Namespaces e RBAC. Se seu cluster do AKS não for habilitado o RBAC, ignore esta etapa.
Crie um arquivo chamado helm-rbac.yaml e o copie no YAML a seguir:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: v1 kind: ServiceAccount metadata: name: tiller namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: tiller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: tiller namespace: kube-system |
Crie a conta de serviço e a associação de funções com o comando kubectl apply
:
1 2 |
kubectl apply -f helm-rbac.yaml |
Proteger o Tiller e o Helm
O cliente do Helm e o serviço do Tiller são autenticados e se comunicam entre si usando TLS/SSL. Esse método de autenticação ajuda a proteger o cluster Kubernetes e quais serviços podem ser implantados. Para aumentar a segurança, você pode gerar seus próprios certificados autoassinados. Cada usuário do Helm receberia seu próprio certificado do cliente e o Tiller seria inicializado no cluster Kubernetes com os certificados aplicados.
Ao usar um cluster Kubernetes habilitado para RBAC, você pode controlar o nível de acesso que o Tiller tem ao cluster. Você pode definir o namespace do Kubernetes em que o Tiller é implantado e pode restringir em quais namespaces o Tiller pode implantar recursos. Essa abordagem permite criar instâncias do Tiller em namespaces diferentes, definir limites de implantação e definir o escopo dos usuários do cliente do Helm a determinados namespaces.
Configurar o Helm
Para implantar um Tiller básico em um cluster do AKS, use o comando helm init. Se o cluster não está habilitado o RBAC, remova o --service-account
argumento e o valor. Se você configurou TLS/SSL para o Tiller e o Helm, ignore esta etapa de inicialização básica e, em vez disso, forneça o --tiller-tls-
necessário conforme mostrado no exemplo a seguir.
1 2 |
helm init --upgrade --service-account tiller |
Se você configurou TLS/SSL entre o Helm e o Tiller, forneça os parâmetros de --tiller-tls-*
e os nomes de seus próprios certificados, conforme mostrado no exemplo a seguir:
1 2 3 4 5 6 7 8 |
helm init \ --tiller-tls \ --tiller-tls-cert tiller.cert.pem \ --tiller-tls-key tiller.key.pem \ --tiller-tls-verify \ --tls-ca-cert ca.cert.pem \ --service-account tiller |
Verifique se o pod do tiller já esta com status running
antes de usar o helm pela primeira vez.
1 2 |
kubectl --namespace kube-system get pods | grep tiller |
Dashboard
Uma ferramenta muito útil que já vem disponível no AKS é o Dashboard. Ele poderá ser acessado pelo comando do az cli
que irá criar um túnel na porta 9000, redirecionado para o dashboard do cluster.
1 2 |
az aks browse --resource-group ClusterAKSResourceGroup --name ClusterAKS |
Conclusão
Vamos continuar esse tutorial em pelo menos mais 3 ou 4 partes. Até mais.