Container Infrastructure Development (CID)

Bem-vindo ao ambiente de desenvolvimento para infraestrutura totalmente baseado em Docker.

Objetivo deste projeto é ter um ponto único para vários projetos (chamados de clients) e para cada client ter seus mais diversos ambientes de desenvolvimento, assim não sendo mais necessário criar máquinas virtuais ou coisas do genêro para controlar estas peculiaridades.

Todo o projeto está sendo criado em BASH Shell Script para fácil compreensão de Administradores de Sistemas e/ou pessoas que querem um pouco mais de "simplicidade" para um ambiente de desenvolvimento para seus projetos/clientes com diversos ambientes.

Estrutura de diretórios necessário

O mínimo que sua estrutura deve ter é a seguinte:

.
├── cid # Aqui está este projeto
├── projects
└── terraform

Se não for detectado estes diretórios (menos o cid, é claro) o instalador fará a criação para você.

Caso seja necessário mudar o formato dessa árvore, faça as devidas modificações no arquivo docker-compose.yml.

Diretório .credentials

Todas as credenciais que devem ir para dentro do seu container setados por ambiente. Cuidado para não commitar nada sensível aqui.

Diretório configs

Arquivos que serão injetados dentro do seu container como volume. Quando houver necessidade de incluir mais arquivos, faça a chamada deste novo arquivo dentro do arquivo docker-compose.yml

Diretório bootstrap

Instalação das ferramentas que serão adicionadas dentro do container no diretório /app.

Caso necessite acrescentar mais ferramentas, crie a função desejada e faça sua chamada no arquivo bootstrap.sh

Diretório cli

Um dos principais diretórios do sistema. Todas funções para serem consumidas nos containers estão presentes aqui dentro.

Cada função tem sua própria documentação e deve/deveria? conter todos os parâmetros necessários e outras funções que foram chamadas durante sua execução.

Caso for contribuir com novas funções, pode-se adicionar no seu vscode o seguinte snippet para facilitar a criação dessas "annotations" para melhorar a documentação.

{
  "Annotation for comments": {
    "prefix": ["shell-function-with-annotations"],
    "body": [
      "# @function: ",
      "# @description: ",
      "# @arg: <VariableName>",
      "# @noargs",
      "# @return: String",
      "# @exitcode 0 Sucesso",
      "# @exitcode 1 Função <FunctionName> não foi encontrada",
      "# @exitcode 1 Parâmetro <ParameterName> não foi definida",
      "function FunctionName() {",
      "",
      "}",
    ],
    "description": "Cria uma function com annotations para os comentários em Shell Script"
  }
}

Caso esteja criando um provider totalmente novo (por exemplo Google Cloud ou Azure), crie o diretório para o provider e dentro deste provider adicione um arquivo com mesmo nome contendo todas as demais funções que foram criadas, como neste exemplo da aws.sh:

# @description: Abaixo fica a inclusão de todos os tipos de serviços que são utilizados pela AWS.
# @description: Quando houver necessidade de usar outro serviço dentro da AWS, acrescente aqui o arquivo responsável pelas chamadas.
# @arg: CLI_FULL_PATH

source ${CLI_FULL_PATH}/src/aws/aws.sh
source ${CLI_FULL_PATH}/src/aws/api-gateway.sh
source ${CLI_FULL_PATH}/src/aws/cloudfront.sh
source ${CLI_FULL_PATH}/src/aws/eks.sh
source ${CLI_FULL_PATH}/src/aws/lambda.sh
source ${CLI_FULL_PATH}/src/aws/secrets-manager.sh

Diretório clients

Este diretório contem todos os ambientes para os containers do cliente em questão. Aqui é possível setar variáveis de ambiente que devem ser carregadas para dentro do container. Também no momento setamos nomes de pacotes que estão sendo selecionados "a dedo" para ser instalados dentro do container.

Abaixo iremos mostrar o que cada arquivo é responsável.

Arquivo .env.common

Arquivo de configuração responsável por todas variáveis em comum nos mais diferentes ambientes que deseja fazer.

Algumas variáveis são obrigatórias, como por exemplo:

PATH=/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/app:/app/aws-cli-bin
CLI_FULL_PATH=/root/cli
CLIENT_NAME=client1
CLI_ALIAS=c

PATH é responsável por ser alimentado para encontrar binários espalhados pelo sistema.

CLIENT_NAME nome do cliente em questão, deve fazer match com o nome do diretório do cliente em questão. Utilizado para padronização e também para ser chamado como alias para a linha de comando.

CLI_ALIAS atua como alias para a linha de comando.

Arquivo .env.

Este arquivo é reponsável por injetar todas variáveis de ambiente que deseja ter no container, caso necessite algo a mais, apenas é necessário adicionar aqui.

No momento temos uma lista definida do que pode ser instalado dentro do container.

• AWS_CLI_VERSION=2.7.4
• AWS_CLI_PIP_VERSION=2.2.0
• KUBECTL_VERSION=1.22.0
• ISTIOCTL_VERSION=1.13.3
• KUSTOMIZE_VERSION=v4.5.5
• HELM_VERSION=3
• ARGO_VERSION=v2.4.14

Informações sobre o ambiente que está sendo setado:

• ENV_NAME=dev
• ENV_PREFIX=${CLIENT_NAME}-${ENV_NAME}

CLIENT_NAME é definido dentro do arquivo .env.common pois ele é variável em comum para qualquer ambiente que deseja contruir.

ENV_PREFIX para padronização de alguns nomes dentro da CLI.

Opções para AWS:

• AWS_DEFAULT_REGION=us-east-1
• AWS_PROFILE=${ENV_PREFIX}
• AWS_CLI_FILE_ENCODING=UTF-8

AWS_PROFILE se utilizado, matenha o mesmo nome da propriedade ENV_PREFIX

Opções para Terraform:

• TF_WORKSPACE=${ENV_NAME}
• TF_WORKING_DIRECTORY=/root/terraform
• TF_WORKING_DIRECTORY_AWS=${TF_WORKING_DIRECTORY}/aws

Nome padrão onde será guardado todos as informações do Terraform. Cuidado ao precisar apontar para outro local.

• TF_DEFAULT_BUCKET_NAME="${CLIENT_NAME}-terraform-backend-${ENV_NAME}"

Arquivo client1.containers.yml

Reponsável por TODOS os seus containers. Toda documentação necessária esta neste arquivo para cada passo.

Obviamente se necessário acrescentar novas configurações é possível de ser feito.

Arquivo client1.secrets.yml

Responsável por TODAS as secrets que são necessárias de acesso de dentro dos containers. Toda documentação necessária esta neste arquivo.