Introdução
Nesta etapa vamos definir quais ambientes vamos utilizar. Essa é a teceira parte de um tutorial sobre implantanção de DevOps sobre Kubernetes em um ambiente AKS gerenciado da Azure.
Preparação dos Ambientes de Homologação e Produção
Vamos montar uma estrutura em cluster compartilhando os recursos de nosso cluster entre os ambientes. Vamos utilizar um ambiente de homologação, que será o ambiente equivalente a branch “Release” do Git-Flow, que aqui chamaremos de “homolog”, e o ambiente de Produção, que será usado para promoção do executável do ambiente de homologação, que aqui será chamado “production”.
|
1 2 3 4 5 6 7 |
apiVersion: v1 kind: Namespace metadata: name: homolog labels: name: homolog |
|
1 2 |
kubectl create -f namespace-homolog.yaml |
|
1 2 3 4 5 6 |
kubectl create secret -n homolog docker-registry acrcredentials \ --docker-server=clusteraksregistry.azurecr.io \ --docker-username=clusteraksregistry \ --docker-password=kJAYQFLLnLcWNU3ceZMc1Rr0RYfH/UFz \ --docker-email=fulano@empresa.com.br |
|
1 2 3 4 5 6 7 |
apiVersion: v1 kind: Namespace metadata: name: production labels: name: production |
|
1 2 |
kubectl create -f namespace-production.yaml |
|
1 2 3 4 5 6 |
kubectl create secret -n production docker-registry acrcredentials \ --docker-server=clusteraksregistry.azurecr.io \ --docker-username=clusteraksregistry \ --docker-password=kJAYQFLLnLcWNU3ceZMc1Rr0RYfH/UFz \ --docker-email=fulano@empresa.com.br |
Configurando variáveis de ambientes
O problema de usar variáveis de ambiente Docker, declarando no Dockerfile, ou no Kubernetes, declarando no arquivo de deployment, é que elas estão vinculadas ao contêiner ou à implementação. Se você quiser alterá-los, precisará reconstruir o contêiner ou modificar a implementação. Pior ainda, se você quiser usar a variável com vários contêineres ou implantações, terá que duplicar os dados!
O Kubernetes resolve esse problema com o Secrets (para dados confidenciais) e o ConfigMaps (para dados não confidenciais).
A grande diferença entre Secrets e ConfigMaps é que os Secrets são ofuscados com uma codificação Base64. Pode haver mais diferenças no futuro, mas é uma boa prática usar Secrets para dados confidenciais (como chaves de API) e ConfigMaps para dados não confidenciais (como números de porta).
Criando as secrets
O comando abaixo nos permite criar um arquivo de Secrets no ambiente “homolog” apartir de três conjuntos de chave/valor.
|
1 2 3 4 5 |
kubectl create secret generic nomedasecret -n homolog \ --from-literal=SECRET_DB_USER=sa \ --from-literal=SECRET_DB_PASSWORD=Ma123456! \ --from-literal=SECRET_DB_IP=10.0.0.1 |
Após a criação podemos pegar o Yaml gerado com seguinte comando:
|
1 2 |
kubectl get secret nomedasecret -o yaml -n homolog |
Usando a Secret na aplicação
Vamos agora alterar o arquivo de deployment para buscar a variáveis de ambiente a partir da Secret criada. O exemplo abaixo é apenas didático.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: hello-world spec: replicas: 1 template: metadata: labels: app: pre-impresso spec: containers: - image: clusteraksregistry.azurecr.io/hello-world:__BUILDNUMBER__ name: hello-world imagePullPolicy: Always ports: - containerPort: 8080 envFrom: ### Uso de todas as varíaveis secrets. - secretRef: name: nomedasecret env: ### Uso variaveis isoladas. - name: SECRET_DB_IP valueFrom: secretKeyRef: name: nomedasecret key: SECRET_DB_IP - name: SECRET_DB_PASSWORD valueFrom: secretKeyRef: name: nomedasecret key: SECRET_DB_PASSWORD - name: SECRET_DB_USER valueFrom: secretKeyRef: name: nomedasecret key: SECRET_DB_USER imagePullSecrets: - name: acrcredentials --- apiVersion: v1 kind: Service metadata: name: hello-world spec: ports: - protocol: TCP port: 80 targetPort: 8080 selector: app: hello-world type: LoadBalancer |
