NIST SP 500-292: Cloud Computing Reference Architecture
O O
─┼─ ─┼─
│ (3) (4) │
╱ ╲ ╱ ╲
desenvolvedor usuário
━━┳━━ ┊┊ ┊┊
┃ ┊┊ ↓↓ ━━┳━━
┃ ↓↓ ┌────────────────────┐ ┃
┃ ┌────────────────────┐ │ ↓↓ │ ┃
┃ │ ↓↓ │ │ ━━━━━━━━━━ │ ┃
┃ │ ╭────╮ ╭────╮ │ deploy │ ↓ ↓ │ ┌┸┐
┃ │ │ │┈┈┈→│ │┈→│┈┈┈┈┈┈┈→│ ╭────╮ ╭────╮ │ │P│
┃ │ ╰────╯ ╰────╯ │ app │ │App │ │App │ │ │a│
┌┸┐ │ (5) │ │ ╰────╯ ╰────╯ │ │a│
│C│ │ ╭────╮ ╭────╮ │ │ ↓ (6) ↓ │ │S│
│l│ ┌┈┈┈┈→┊┈→│ │┈┈┈→│ │┈→│┈┈┈┐ │ ╭────╮ ╭────╮ │ └┰┘
│o│ ┊ │ ╰────╯ ╰────╯ │ ┊ │ │ BD │ │ BD │ │ ┃
│u│ ┊ │ │ ┊ │ ╰────╯ ╰────╯ │ ┃
│d│ └──────┤tooling├─────┘ ┊ └─────┤produção├─────┘ ┃
└┰┘ O deploy ┊ IaC ↑ ━━┻━━
┃ ─┼─ ┈┈┈┈┈┈┈┈┈┈┈┐ ├┈┈┈┈┈┈┈┈┤
┃ │ ↓ ↓ ↓
┃ ╱ ╲ ╭─┤VM1├─╮╭─┤VM2├─╮╭─┤VM3├─╮╭─┤VM4├─╮╭─┤VM5├─╮╭─┤VM6├─╮
┃ │ ││ ││ ││ ││ ││ │
┃ cloud │ ││ ││ ││ ││ ││ │
┃ consumer │ ││ ││ ││ ││ ││ │
┃ ╰───────╯╰───────╯╰───────╯╰───────╯╰───────╯╰───────╯
┃ (2) ╏ ╏ ╏ ╏ ╏ ╏
┃ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┈
━━┻━━
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
━━┳━━
┃ (1)
┃
┌┸┐ O ╔══╡HW╞══╗╔══╡HW╞══╗╔══╡HW╞══╗╔══╡HW╞══╗╔══╡HW╞══╗
│I│ ─┼─ ╠════════╣╠════════╣╠════════╣╠════════╣╠════════╣
│a│ │ ╠════════╣╠════════╣╠════════╣╠════════╣╠════════╣
│a│ ╱ ╲ ╠════════╣╠════════╣╠════════╣╠════════╣╠════════╣
│S│ ╠════════╣╠════════╣╠════════╣╠════════╣╠════════╣
└┰┘ cloud ╚════════╝╚════════╝╚════════╝╚════════╝╚════════╝
┃ provider ╏ ╏ ╏ ╏ ╏
┃ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┈
━━┻━━
O ambiente de nuvem (tanto pública quanto privada) é o compartilhamento de recursos de hardware entre consumidores diferentes através de uma camada de abstração e de gerenciamento. Essa camada permite a instanciação de recursos virtuais, como máquinas e redes, e é chamada de IaaS (Infrastructure as a Service). O OpenStack é uma opção de IaaS para nuvem privada.
A equipe do provedor de nuvem cuida dos componentes físicos, como datacenter, fornecimento de energia, switches, roteamento externo, storages etc. Essa equipe precisa ter conhecimentos em ferramentas de provisionamento de máquinas físicas e monitoramento de hardware, incluindo termos como IPMI, SNMP, BGP etc. A equipe também precisa conhecer o software de IaaS, para que consiga adicionar, remover, manter e resolver problemas tanto no hardware quanto no IaaS.
Acima do IaaS, outra equipe consome os recursos físicos pela instanciação (através de APIs) de recursos virtuais, como máquinas e redes. Essa equipe é responsável por projetos, contas ou namespaces da empresa na nuvem, assim como pelos custos que os acompanham.
Essa equipe consumidora da nuvem precisa ter conhecimentos em ferramentas de provisionamento e orquestração, como Ansible, Puppet, Terraform, Heat, entre outros. Adicionalmente, é desejável que esse provisionamento seja versionado, o que permite que a infraestrutura virtual seja tratada como código (IaC) e aplicada ao ambiente através de métodos ágeis.
Os desenvolvedores, mantendo o projeto sob um ciclo de vida DevSecOps, publicam as alterações em repositórios de código versionado, o que aciona esteiras de compilação, empacotamento e testes (unitários e de integração) que podem resultar em entregas contínuas ao ambiente produtivo.
Essa equipe, além do domínio das linguagens de programação relevantes, também devem ter conhecimentos em áreas variadas como servidores de aplicação, segurança, redes, banco de dados, assim como em ferramentas de testes, de automatização, de provisionamento, entre outros.
Idealmente o usuário final acessará apenas o ambiente produtivo de forma segura, efetiva, eficiente e transparente. Ele não deveria conhecer ou se importar com a implementação da aplicação ou topologia do ambiente produtivo. Dessa forma, o ambiente tem a flexibilidade e agilidade necessárias para evoluir de forma segura e confiável.
Como apoio a todas as atividades de desenvolvimento e manutenção, é quase sempre necessário que exista um grande conjunto de ferramentas responsáveis por tarefas específicas, como repositório de código, gerenciador de tarefas e de esteiras, compilador de código, armazenamento de artefatos, testador estático de código, provisionador de infraestrutura etc.
Essas ferramentas não são estritamente necessárias para o ambiente produtivo, mas permitem que o desenvolvimento seja ágil e seguro. Contudo elas não têm os mesmos requisitos de disponibilidade e confiabilidade do ambiente produtivo, já que uma indisponibilidade delas não impacta a produção exceto pelo impedimento de novas entregas.
Alguns exemplos de ferramentas:
- GitLab, Gitea, Gitolite...
- Jenkins, Rundeck...
- Nexus, Harbour...
- Sonarqube, Clair...
- Terraform, Puppet, Chef, Juju...
O ambiente de produção tem requisitos estritos de tempo de resposta, escalabilidade, redundância, disponibilidade, segurança e outros. Para atender esses requisitos, são necessárias diversas camadas de recursos como máquinas virtuais, redes virtuais, volumes, proxies e outros. Adicionalmente, quando a aplicação recebe atualizações, é desejável que essas atualizações sejam efetivadas com mínima indisponibilidade e máxima confiabilidade.
É possível montar o ambiente de produção sobre os recursos disponibilizados pela nuvem, mas isso traz desafios de planejamento, orquestração e manutenção. Outra possibilidade é usar uma solução PaaS (Platform as a Service) como o OpenShift, que facilita todas as operação do ambiente produtivo, trazendo maior estabilidade, segurança e confiabilidade para a aplicação.
┃ ┌─────────┐ ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┥Openstack┝━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ └─────────┘ ┃
┌────────────────────┐
╔═╡Domínio: treinamento╞═════════════════════════════════════════════╗
O ║ └────────────────────┘ ║
─┼─ ║ (3) ║
│ ║ ┌───────────────────┐ ║
╱ ╲ ║ ┌──────────────────┤Projeto: turma 1234├────────────────────┐ ║
aluno ║ │ └───────────────────┘ │ ║
║ │ (4) │ ║
║ │ ┌─┤Subprojeto: aluno A├───────────┐ │ ║
║ │ ╭─┤VMP├─╮ │ │ │ ║
O ║ │ │ │ ┃ │ (5) ╭─┤VM1├─╮╭─┤VM2├─╮╭─┤VM3├─╮ │ │ ║
─┼─ ║ │ │ │╍╍╍╍╍╍┃ │ │ ││ ││ │ │ │ ║
│ ║ │ │ │ ┃ │ │ ││ ││ │ │ │ ║
╱ ╲ ║ │ ╰───────╯ ┃ │ │ ││ ││ │ │ │ ║
instrutor ║ │ ┃ │ ╰───────╯╰───────╯╰───────╯ │ │ ║
║ │ ┃ │ ┏━━━┓ ╏ ╏ ╏ │ │ ║
║ │ ╭─┤VMP├─╮ ┃╍╍╍╍│━┃R╳A┃━━━━━━━━━━━━━━━━━━━━━━━━━┈ │ │ ║
║ │ │ │ ┃ │ ┗━━━┛ │ │ ║
O ║ │ │ │╍╍╍╍╍╍┃ └─────────────────────────────────┘ │ ║
─┼─ ║ │ │ │ ┃ │ ║
│ ║ │ ╰───────╯ ┃ ┌─┤Subprojeto: aluno B├───────────┐ │ ║
╱ ╲ ║ │ ┃ │ │ │ ║
suporte ║ │ ┃ │ ╭─┤VM1├─╮╭─┤VM2├─╮╭─┤VM3├─╮ │ │ ║
║ │ ┊ ┃ │ │ ││ ││ │ │ │ ║
║ │ ┃ │ │ ││ ││ │ │ │ ║
(2) ║ │ ┃ │ │ ││ ││ │ │ │ ║
║ │ ┃ │ ╰───────╯╰───────╯╰───────╯ │ │ ║
║ │ ┃ │ ┏━━━┓ ╏ ╏ ╏ │ │ ║
║ │ ┃╍╍╍╍│━┃R╳B┃━━━━━━━━━━━━━━━━━━━━━━━━━┈ │ │ ║
║ │ ┃ │ ┗━━━┛ │ │ ║
║ │ ┃ └─────────────────────────────────┘ │ ║
║ │ ┏━━━┓ ┊ │ ║
║ │ ┃R╳P┃ ┊ │ ║
║ │ ┗━━━┛ ┊ │ ║
║ │ ┃ ┊ │ ║
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ║ └───────────────────────────────────────────────────────────┘ ║
┊ ║ ╏ ║
internet ┊ ║ ┏━━━┓ ╏ ║
━━━━━━━━━━━━━━━━━━━━━━━║━┃R╳D┃━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ║
╏ ┊ ║ ┗━━━┛ ╏ ╏ ╏ ║
╭─┤VMC├─╮ ┊ ║ ╭─┤VMD├─╮ ╭─┤VMD├─╮ ╭─┤VMD├─╮ ║
│ │ ┊ ║ │ │ │ │ │ │ ║
│ │ ┊ ║ │ │ │ │ │ │ ║
│ │ ┊ ║ │ │ │ │ │ │ ║
╰───────╯ ┊ ║ ╰───────╯ ╰───────╯ ╰───────╯ ║
┊ ║ ║
(1) ┊ ║ ║
╚════════════════════════════════════════════════════════════════════╝
- Servidor LDAP para autenticação de usuários no domínio de treinamento
- Servidores repositórios de pacotes
- Servidores repositórios de código
Podemos apontar a autenticação inteira do OpenStack para o LDAP de treinamento ou apontar apenas a autenticação do domínio de treinamento para ele. Nos dois casos os usuários virão do LDAP.
Cada aluno deveria ter acesso de admin apenas no seu próprio subprojeto, sobre recursos como VMs do curso. Assim ele conseguiria destruir e recriar o seu próprio ambiente acionando os templates do Heat no seu projeto sempre que precisasse. Ele não deveria ter acesso a outros subprojetos ou projetos ou domínios.
Cada instrutor deveria ter acesso de admin ao projeto da turma que ministra, assim como aos subprojetos dos alunos da turma. Com isso ele pode investigar e resolver problemas durante o andamento do curso, assim como recriar componentes que precisar através dos templates do Heat.
A equipe de suporte deveria ter acesso de admin ao domínio, assim como a todos os seus projetos e subprojetos. Assim é possível investigar e resolver problemas do treinamento de todas as turmas, assim como criar e destruir turmas inteiras caso necessário.
Precisa existir um domínio para conter os objetos do treinamento. Podemos usar o domínio padrão 'default' ou criar um próprio para o treinamento. Esse domínio seria criado uma vez mas nunca destruído.
O domínio do treinamento teria os componentes compartilhados pelo treinamento, como imagens, templates, rede com saída para a internet, serviços e VMs acessíveis pelos alunos (como proxies para cache de pacotes). Também é possível alocar recursos não acessíveis aos alunos, como monitoramento sobre os projetos, subprojetos, turmas e alunos.
- Cria domínio para o treinamento
- Cria rede do domínio, compartilhada entre todos os projetos
- Cria subredes para recursos do domínio e para projetos
- Cria roteador de acesso externo do domínio: RXD
- Cria VMs e outros recursos compartilhados por todas as turmas
Cada turma tem diversos alunos e cada aluno tem diversos recursos de nuvem provisionados. Se todos esses recursos estivessem num mesmo domínio e projeto, seria muito fácil perdermos a contabilidade e o controle deles.
Então um projeto para cada turma permite um controle melhor dos recursos que precisam ser alocados no início do curso e liberados no final. Também permite que alguns recursos sejam alocados para cada turma, de forma que os alunos possam compartilhá-los, como serviços que os alunos precisam acessar como leitura (por exemplo, monitoramento black box, autenticação LDAP, redirecionamento de APIs etc) ou serviços que precisam acessar os recursos dos alunos (por exemplo, monitoramento ou validação de desafios e estágios do curso).
Alguns recursos iguais em todos os projetos/turmas/cursos, como a rede com saída para internet. Mas outros recursos são específicos de cada curso. Portanto, é necessário fazer ao menos dois templates: um com recursos comuns e outro com recursos específicos do curso (VMs, por exemplo).
- Cria projeto da turma dentro do domínio de treinamento
- Cria rede do projeto, compartilhada entre todos os subprojetos
- Cria subrede do projeto para recursos do projeto e para os subprojetos
- Cria roteador para acesso externo do projeto usando a rede do domínio como gateway
- Cria VMs e outros recursos compartilhados por todos os alunos da turma
Cada curso deve ter um template diferente que instancia os recursos específicos do curso, com VMs compartilhadas pelos alunos para as atividades do curso.
- Executa o Heat de criação de turma genérica
- Cria recursos específicos da turma, mas compartilhados entre os alunos
Quando um curso termina, todos os recursos alocados no projeto precisam ser desalocados, assim como o próprio projeto. É possível que um template seja suficiente para isso.
- Executa o Heat de destruição de subprojetos filhos
- Destrói o projeto da turma
Cada aluno terá alguns recursos próprios, como VMs, assim como acesso a recursos compartilhados entre os alunos da turma, como validadores de desafios, e acesso a recursos compartilhados entre todos os usuários da nuvem de treinamento, como cache de pacotes. Portanto, é necessário que os recursos próprios de cada aluno estejam também agrupados, na forma de um subprojeto, para que possamos criar e destruir os recursos de cada aluno independentemente à medida que alunos entram e saem das turmas.
Alguns recursos são iguais em todos os alunos, como a rede com saída para a internet. Mas outros recursos são específicos de cada curso, como VMs próprias dos alunos. Portanto, é necessário fazer ao menos dois templates: um com recursos comuns e outro com recursos específicos do curso para o aluno, como as instanciações das VMs do aluno.
- Cria subprojeto do aluno dentro do projeto da turma
- Cria rede do subprojeto
- Cria subrede do subprojeto
- Cria roteador para acesso externo do subprojeto usando a rede do projeto como gateway
Cada curso deve ter um template diferente que instancia os recursos específicos do curso por aluno, como VMs customizadas para cada aluno.
- Executa o Heat de criação de aluno para curso genérico
- Cria recursos específicos do curso
- Destrói recursos do subprojeto do aluno
- Destrói subprojeto do aluno