Partilhar via

Pacotes de aplicativos nativos da nuvem

  • Artigo

Gorjeta

Este conteúdo é um excerto do eBook, Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.

Descarregar PDF

Cloud Native .NET apps for Azure eBook cover thumbnail.

Uma propriedade fundamental dos aplicativos nativos da nuvem é que eles aproveitam os recursos da nuvem para acelerar o desenvolvimento. Este design geralmente significa que uma aplicação completa usa diferentes tipos de tecnologias. Os aplicativos podem ser enviados em contêineres do Docker, alguns serviços podem usar o Azure Functions, enquanto outras partes podem ser executadas diretamente em máquinas virtuais alocadas em grandes servidores de metal com aceleração de GPU de hardware. Não há dois aplicativos nativos da nuvem iguais, por isso tem sido difícil fornecer um único mecanismo para enviá-los.

Os contêineres do Docker podem ser executados no Kubernetes usando um gráfico de leme para implantação. O Azure Functions pode ser alocado usando modelos Terraform. Finalmente, as máquinas virtuais podem ser alocadas usando Terraform, mas construídas usando o Ansible. Trata-se de uma grande variedade de tecnologias e não foi possível agrupá-las todas num pacote razoável. Até agora.

Os Cloud Native Application Bundles (CNABs) são um esforço conjunto de muitas empresas voltadas para a comunidade, como Microsoft, Docker e HashiCorp, para desenvolver uma especificação para empacotar aplicativos distribuídos.

O esforço foi anunciado em dezembro de 2018, então ainda há um pouco de trabalho a fazer para expor o esforço à comunidade maior. No entanto, já existe uma especificação aberta e uma implementação de referência conhecida como Duffle. Esta ferramenta, que foi escrita em Go, é um esforço conjunto entre o Docker e a Microsoft.

Os CNABs podem conter diferentes tipos de tecnologias de instalação. Esse aspeto permite que coisas como Helm Charts, modelos Terraform e Playbooks do Ansible coexistam no mesmo pacote. Uma vez construídos, os pacotes são independentes e portáteis; eles podem ser instalados a partir de um stick USB. Os pacotes são assinados criptograficamente para garantir que são originários da parte que reivindicam.

O núcleo de um CNAB é um arquivo chamado bundle.json. Este arquivo define o conteúdo do pacote, sejam eles Terraform ou imagens ou qualquer outra coisa. A Figura 11-9 define um CNAB que invoca algum Terraform. Observe, no entanto, que ele realmente define uma imagem de invocação que é usada para invocar o Terraform. Quando empacotado, o arquivo do Docker localizado no diretório cnab é incorporado a uma imagem do Docker, que será incluída no pacote. Ter o Terraform instalado dentro de um contêiner do Docker no pacote significa que os usuários não precisam ter o Terraform instalado em sua máquina para executar a agregação.

{
    "name": "terraform",
    "version": "0.1.0",
    "schemaVersion": "v1.0.0-WD",
    "parameters": {
        "backend": {
            "type": "boolean",
            "defaultValue": false,
            "destination": {
                "env": "TF_VAR_backend"
            }
        }
    },
    "invocationImages": [
        {
        "imageType": "docker",
        "image": "cnab/terraform:latest"
        }
    ],
    "credentials": {
        "tenant_id": {
            "env": "TF_VAR_tenant_id"
        },
        "client_id": {
            "env": "TF_VAR_client_id"
        },
        "client_secret": {
            "env": "TF_VAR_client_secret"
        },
        "subscription_id": {
            "env": "TF_VAR_subscription_id"
        },
        "ssh_authorized_key": {
            "env": "TF_VAR_ssh_authorized_key"
        }
    },
    "actions": {
        "status": {
            "modifies": true
        }
    }
}

Figura 10-18 - Um exemplo de arquivo Terraform

O bundle.json também define um conjunto de parâmetros que são passados para o Terraform. A parametrização do bundle permite a instalação em vários ambientes diferentes.

O formato CNAB também é flexível, permitindo que seja usado em qualquer nuvem. Ele pode até ser usado em soluções locais, como o OpenStack.

Decisões de DevOps

Existem tantas ferramentas excelentes no espaço de DevOps nos dias de hoje e ainda mais livros e artigos fantásticos sobre como ter sucesso. Um livro favorito para começar a jornada de DevOps é The Phoenix Project, que acompanha a transformação de uma empresa fictícia de NoOps para DevOps. Uma coisa é certa: o DevOps não é mais um "bom de se ter" ao implantar aplicativos complexos e nativos da nuvem. É um requisito e deve ser planejado e dotado de recursos no início de qualquer projeto.

Referências

AnteriorSeguinte