Consumo da nuvem Apache CloudStack
Este documento apresenta o conceito de ambientes de computação em nu-
vem, no contexto de nuvem privada, e uma introdução à plataforma de or-
questração de nuvem Apache CloudStack, com foco no processo de consumo
da mesma.
Data de atualização: 7 de outubro de 2024
Revision: 774b16a47611371568767a362e7f712a9012450f
Conteúdo
1 Introdução 26
1.1 Plataformas de nuvem privada . . . . . . . . . . . . . . . . . . . . . 27
1.1.1 Funcionalidades básicas . . . . . . . . . . . . . . . . . . . . . 27
1.2 História do Apache CloudStack . . . . . . . . . . . . . . . . . . . . . 29
2 Funcionalidades do Apache CloudStack 30
2.1 Dashboard inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 Gestão de acesso à nuvem . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.1 Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.1.1 Adição de account . . . . . . . . . . . . . . . . . . . 33
2.2.1.2 Visualização de detalhes de account . . . . . . . . 34
2.2.1.3 Deleção de account . . . . . . . . . . . . . . . . . . 35
2.2.1.4 Configuração de acesso de uma account . . . . . . 35
2.2.1.5 Desabilitação de account . . . . . . . . . . . . . . . 37
2.2.1.6 Bloqueio de account . . . . . . . . . . . . . . . . . . 38
2.2.1.7 Restrição de acesso à API por IP . . . . . . . . . . . 39
2.2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.2.1 Adição de role . . . . . . . . . . . . . . . . . . . . . 40
2.2.2.2 Visualização de detalhes de role . . . . . . . . . . . 41
2.2.2.3 Customização de uma role . . . . . . . . . . . . . . 42
2.2.2.4 Remoção de role . . . . . . . . . . . . . . . . . . . . 42
2.2.3 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2.3.1 Adição de domain . . . . . . . . . . . . . . . . . . . 45
2.2.3.2 Configuração de domain . . . . . . . . . . . . . . . 46
2.2.3.3 Definição de acessos do domain . . . . . . . . . . . 47
2.2.3.4 Reestruturação da árvore de domínios . . . . . . . 48
2.2.4 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.4.1 Adição de user . . . . . . . . . . . . . . . . . . . . . 49
2
2.2.4.2 Edição de user . . . . . . . . . . . . . . . . . . . . . 51
2.2.4.3 Deleção de user . . . . . . . . . . . . . . . . . . . . 53
2.2.4.4 Desabilitação/habilitação de user . . . . . . . . . . 53
2.2.4.5 Políticas de senha . . . . . . . . . . . . . . . . . . . 54
2.2.4.6 Desabilitação de user por erro de senha . . . . . . 56
2.2.4.7 Gerência de chaves de API dos users . . . . . . . . 56
2.2.4.8 Uso das chaves de API no CloudMonkey . . . . . . 58
2.2.4.9 Autenticação de dois fatores . . . . . . . . . . . . . 58
2.2.4.10 Timezone . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.2.5 Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.2.5.1 Adição de project . . . . . . . . . . . . . . . . . . . . 64
2.2.5.2 Adição de accounts e users ao project . . . . . . . . 69
2.2.5.3 Edição de project . . . . . . . . . . . . . . . . . . . . 72
2.2.5.4 Suspensão de project . . . . . . . . . . . . . . . . . 73
2.2.5.5 Deleção de project . . . . . . . . . . . . . . . . . . . 74
2.2.6 Observações e considerações . . . . . . . . . . . . . . . . . 75
2.3 Gerência de VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.3.1 Adição de VM . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.3.1.1 Adição de VM como root admin . . . . . . . . . . . 77
2.3.1.2 Adição de VM como admin . . . . . . . . . . . . . . 79
2.3.1.3 Adição de VM como user . . . . . . . . . . . . . . . 81
2.3.1.4 Criação de VM com inicialização UEFI . . . . . . . . 82
2.3.2 Remoção de VM . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.3.3 Parada e início de VM . . . . . . . . . . . . . . . . . . . . . . 87
2.3.4 Reinício de VM . . . . . . . . . . . . . . . . . . . . . . . . . . 87
2.3.5 Acesso à VM via interface web . . . . . . . . . . . . . . . . . 88
2.3.6 Aumento de recursos computacionais da VM . . . . . . . . 89
2.3.7 Atribuição de VM a outra account . . . . . . . . . . . . . . . 92
2.3.8 Adição de user-data na VM . . . . . . . . . . . . . . . . . . . 94
3
2.3.9 Configurações da VM . . . . . . . . . . . . . . . . . . . . . . 96
2.3.9.1 Configurações gerais . . . . . . . . . . . . . . . . . 97
2.3.9.2 Configurações para VM com compute offering per-
sonalizada . . . . . . . . . . . . . . . . . . . . . . . . 97
2.3.9.3 Configurações diversas para uso interno . . . . . 98
2.3.9.4 Configurações para importação de VM com NIC,
disco e parâmetros personalizados para compute
offering personalizada . . . . . . . . . . . . . . . . . 98
2.3.9.5 Adicionar configurações da VM via API . . . . . . . 98
2.4 Gerência de volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.4.1 Operações em data e root disks . . . . . . . . . . . . . . . . . 100
2.4.1.1 Vizualização de discos e volumes . . . . . . . . . . 101
2.4.1.2 Criação de volume . . . . . . . . . . . . . . . . . . . 101
2.4.1.3 Upload de volume local . . . . . . . . . . . . . . . . 102
2.4.1.4 Upload de volume local usando cURL . . . . . . . . 103
2.4.1.5 Upload de volume on-line via URL . . . . . . . . . . 105
2.4.1.6 Adição de volume a uma VM . . . . . . . . . . . . . 106
2.4.1.7 Remoção de volume de uma VM . . . . . . . . . . 107
2.4.1.8 Remoção e adição de volume ROOT . . . . . . . . 107
2.4.1.9 Redimensionamento de volume data disk . . . . . 108
2.4.1.10 Download de volume . . . . . . . . . . . . . . . . . 109
2.4.1.11 Snapshots recorrentes . . . . . . . . . . . . . . . . . 110
2.4.1.12 Deleção de volume . . . . . . . . . . . . . . . . . . 111
2.5 Redes guest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
2.5.1 Operações com redes guest . . . . . . . . . . . . . . . . . . . 112
2.5.1.1 Adicionar rede guest . . . . . . . . . . . . . . . . . . 112
2.5.1.2 Tipos de redes . . . . . . . . . . . . . . . . . . . . . 112
2.5.1.3 Acesso aos detalhes de uma rede guest . . . . . . 118
2.5.1.4 Exclusão de rede . . . . . . . . . . . . . . . . . . . . 118
4
2.5.1.5 Edição de rede . . . . . . . . . . . . . . . . . . . . . 119
2.5.1.6 Reinicialização de rede . . . . . . . . . . . . . . . . 119
2.5.1.7 Egress rules . . . . . . . . . . . . . . . . . . . . . . . 119
2.5.2 Network permissions . . . . . . . . . . . . . . . . . . . . . . . 120
2.6 IPs públicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
2.6.1 Operações com IPS públicos . . . . . . . . . . . . . . . . . . 124
2.6.1.1 Configuração de firewall . . . . . . . . . . . . . . . 124
2.6.1.2 Habilitação de static NAT . . . . . . . . . . . . . . . 125
2.6.1.3 Habilitação de port forwarding . . . . . . . . . . . . 127
2.6.1.4 Habilitação de load balancing . . . . . . . . . . . . 128
2.6.2 Aquisição de IP público . . . . . . . . . . . . . . . . . . . . . 130
2.7 Virtual Private Cloud (VPC) . . . . . . . . . . . . . . . . . . . . . . . . 132
2.7.1 Operações com a VPC . . . . . . . . . . . . . . . . . . . . . . 133
2.7.1.1 Adição de VPC . . . . . . . . . . . . . . . . . . . . . 133
2.7.1.2 Reinicialização de VPC . . . . . . . . . . . . . . . . . 135
2.7.1.3 Remoção de VPC . . . . . . . . . . . . . . . . . . . . 136
2.7.1.4 Aquisição de IP público para uma VPC . . . . . . . 136
2.7.2 Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
2.7.2.1 Adição de tiers à VPC . . . . . . . . . . . . . . . . . 138
2.7.2.2 Remoção de tiers da VPC: . . . . . . . . . . . . . . . 140
2.7.3 Network ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
2.7.4 Domain VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.7.4.1 Alocação de IPs públicos em domain VPCs . . . . . 145
2.8 Virtual Private Network (VPN) . . . . . . . . . . . . . . . . . . . . . . . 146
2.8.1 Tipos de VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
2.8.2 Operações com VPN . . . . . . . . . . . . . . . . . . . . . . . 147
2.8.2.1 Criação de VPN . . . . . . . . . . . . . . . . . . . . . 147
2.8.2.2 Desabilitação de VPN para a VPC . . . . . . . . . . 149
2.8.2.3 Gerência de usuários . . . . . . . . . . . . . . . . . 150
5
2.8.2.4 Adição de usuário . . . . . . . . . . . . . . . . . . . 150
2.8.2.5 Definição da quantidade máxima de usuário da
VPN por conta . . . . . . . . . . . . . . . . . . . . . 151
2.8.2.6 Exclusão de usuário . . . . . . . . . . . . . . . . . . 151
2.8.2.7 Conexão à VPN pelo Linux . . . . . . . . . . . . . . 152
2.8.2.8 Conexão à VPN pelo Windows . . . . . . . . . . . . 154
2.8.3 S2S (Site-to-Site) VPNs . . . . . . . . . . . . . . . . . . . . . . 158
2.9 Assinatura de requisições HTTP . . . . . . . . . . . . . . . . . . . . 163
2.10 Templates e ISOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
2.10.1 Operações com templates/ISOs . . . . . . . . . . . . . . . . . 170
2.10.1.1 Vizualização . . . . . . . . . . . . . . . . . . . . . . . 170
2.10.1.2 Listagem . . . . . . . . . . . . . . . . . . . . . . . . . 172
2.10.1.3 Resgitro . . . . . . . . . . . . . . . . . . . . . . . . . 174
2.10.1.4 Upload . . . . . . . . . . . . . . . . . . . . . . . . . . 177
2.10.1.5 Edição . . . . . . . . . . . . . . . . . . . . . . . . . . 179
2.10.1.6 Edição de permissões de template/ISO . . . . . . . 181
2.10.1.7 Edição de compartilhamento do template . . . . . 182
2.10.1.8 Remoção de template/ISO . . . . . . . . . . . . . . 184
2.10.1.9 Criação de template baseado em uma VM existente185
2.11 Resource Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
2.12 Affinity Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
2.12.1 Tipos de affinity groups . . . . . . . . . . . . . . . . . . . . . . 188
2.12.2 Operações com affinity groups . . . . . . . . . . . . . . . . . 189
2.12.2.1 Adição de affinity group . . . . . . . . . . . . . . . . 189
2.12.2.2 Adição de VM ao affinity group . . . . . . . . . . . . 190
2.12.2.3 Visualização de VMs no affinity group . . . . . . . . 191
2.12.2.4 Exclusão de affinity group . . . . . . . . . . . . . . . 193
2.13 Autoscale VM groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
2.13.1 Criação de um autoscale VM group . . . . . . . . . . . . . . . 194
6
2.13.1.1 Configuração da scale-down policy . . . . . . . . . . 199
2.13.1.2 Configuração dos detalhes do autoscale VM group 199
2.13.1.3 Criação do grupo . . . . . . . . . . . . . . . . . . . . 200
2.13.2 Teste de autoscaling . . . . . . . . . . . . . . . . . . . . . . . 201
2.13.3 Edição de autoscale VM group . . . . . . . . . . . . . . . . . . 202
2.13.4 Exclusão de autoscale VM group . . . . . . . . . . . . . . . . 205
2.14 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
2.14.1 Versões suportadas do Kubernetes . . . . . . . . . . . . . . 207
2.14.2 Adição de ISO Kubernetes ao Apache CloudStack . . . . . . 207
2.14.3 Deleção de ISO Kubernetes . . . . . . . . . . . . . . . . . . . 209
2.14.4 Clusters Kubernetes . . . . . . . . . . . . . . . . . . . . . . . 210
2.14.4.1 Criando clusters Kubernetes . . . . . . . . . . . . . 211
2.14.4.2 Scaling de cluster Kubernetes . . . . . . . . . . . . 213
2.14.4.3 Upgrade de cluster Kubernetes . . . . . . . . . . . . 214
2.14.5 Acesso ao Kubernetes . . . . . . . . . . . . . . . . . . . . . . 214
2.14.6 Gerando Token para a Dashboard . . . . . . . . . . . . . . . 216
2.15 Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
2.15.1 Tipos de snapshot . . . . . . . . . . . . . . . . . . . . . . . . . 216
2.15.1.1 Snapshot de volume/disco . . . . . . . . . . . . . . 216
2.15.1.2 Snapshot de VM . . . . . . . . . . . . . . . . . . . . 217
2.15.2 Operações com snapshot . . . . . . . . . . . . . . . . . . . . 217
2.15.2.1 Snapshot de volume . . . . . . . . . . . . . . . . . . 218
2.15.2.2 Snapshot de VM . . . . . . . . . . . . . . . . . . . . 219
2.15.2.3 Visualização dos snapshots criados . . . . . . . . . 220
2.15.2.4 Criação de template a partir de uma snapshot de
volume . . . . . . . . . . . . . . . . . . . . . . . . . 221
2.15.2.5 Criação de volume a partir de uma snapshot de
volume . . . . . . . . . . . . . . . . . . . . . . . . . 222
2.15.2.6 Reversão de snapshot de volume . . . . . . . . . . 223
7
2.15.2.7 Deleção de snapshot de volume . . . . . . . . . . . 224
2.15.2.8 Criação de snapshot de volume a partir de uma
snapshot de VM . . . . . . . . . . . . . . . . . . . . . 224
2.15.2.9 Reversão de snapshot de VM . . . . . . . . . . . . . 226
2.15.2.10Deleção de snapshot de VM . . . . . . . . . . . . . 226
2.15.2.11Configuração de snapshots recorrentes . . . . . . 227
2.16 Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
2.16.1 Níveis de eventos . . . . . . . . . . . . . . . . . . . . . . . . . 227
2.16.2 Busca e filtro de eventos . . . . . . . . . . . . . . . . . . . . 227
2.16.3 Remoção ou arquivamento de eventos . . . . . . . . . . . . 228
2.17 Interface de usuário (UI) . . . . . . . . . . . . . . . . . . . . . . . . . 229
2.17.1 Uso de timezone do browser . . . . . . . . . . . . . . . . . . . 229
2.17.2 Documentação na UI . . . . . . . . . . . . . . . . . . . . . . . 230
2.18 Service offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
2.18.1 Disk offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
2.18.1.1 Criação de disk offering . . . . . . . . . . . . . . . . 231
2.18.1.2 Edição de disk offering . . . . . . . . . . . . . . . . . 234
2.18.1.3 Exclusão de disk offering . . . . . . . . . . . . . . . 236
2.18.2 Compute offerings . . . . . . . . . . . . . . . . . . . . . . . . . 237
2.18.2.1 Criação de compute offering . . . . . . . . . . . . . 237
2.18.2.2 Edição de compute offering . . . . . . . . . . . . . . 242
2.18.2.3 Exclusão de compute offering . . . . . . . . . . . . . 243
2.18.2.4 Alteração de compute offering da VM . . . . . . . . 244
2.18.3 Network offerings . . . . . . . . . . . . . . . . . . . . . . . . . 246
2.18.3.1 Criação de network offering . . . . . . . . . . . . . . 246
2.18.3.2 Edição de network offering . . . . . . . . . . . . . . 250
2.18.3.3 Exclusão de network offering . . . . . . . . . . . . . 252
2.18.4 VPC Offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
2.18.4.1 Criação de VPC offering . . . . . . . . . . . . . . . . 253
8
2.18.4.2 Edição de VPC offering . . . . . . . . . . . . . . . . . 254
2.18.4.3 Exclusão de VPC offering . . . . . . . . . . . . . . . 256
3 CloudMonkey, API e outros 258
3.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
3.2 Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
3.3 Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
4 Contabilização do consumo de recursos 265
4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
4.1.1 Relatórios de uso de recursos . . . . . . . . . . . . . . . . . 265
4.2 Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
4.2.1 Tarifas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
4.2.2 Relatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
4.2.2.1 Créditos . . . . . . . . . . . . . . . . . . . . . . . . . 267
4.2.2.2 Uso de recursos . . . . . . . . . . . . . . . . . . . . 268
4.2.2.3 Balanço . . . . . . . . . . . . . . . . . . . . . . . . . 271
5 Cloud-init 274
5.1 Etapas de inicialização . . . . . . . . . . . . . . . . . . . . . . . . . . 274
5.2 Frequência de execução . . . . . . . . . . . . . . . . . . . . . . . . . 275
5.3 DataSources conhecidos . . . . . . . . . . . . . . . . . . . . . . . . . 276
5.4 Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
5.5 Criação de uma imagem personalizada . . . . . . . . . . . . . . . . 277
5.6 Cloud-init no Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 280
5.7 Troubleshooting do cloud-init . . . . . . . . . . . . . . . . . . . . . . 280
5.8 Obrigação de troca de senha no primeiro login . . . . . . . . . . . 280
5.9 Auto incremento do tamanho do disco durante o boot . . . . . . . 281
5.10 Interação com o user-data . . . . . . . . . . . . . . . . . . . . . . . . 282
6 Conclusão 283
Apêndice A Terminologia 285
9
Lista de Figuras
1 Computação em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . 27
2 Dashboard inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Diagrama de relacionamento entre contas, domínios, projetos e
usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Navegando até a página de adição de accounts . . . . . . . . . . . 33
5 Adicionando uma nova account . . . . . . . . . . . . . . . . . . . . . 33
6 Navegando até a página de detalhes de uma account . . . . . . . . 34
7 Vendo os detalhes da account . . . . . . . . . . . . . . . . . . . . . . 34
8 Deletando uma account . . . . . . . . . . . . . . . . . . . . . . . . . 35
9 Confirmando a remoção da account . . . . . . . . . . . . . . . . . . 35
10 Editando os limites de uma account . . . . . . . . . . . . . . . . . . 36
11 Editando as configurações de uma account . . . . . . . . . . . . . . 37
12 Desabilitando uma account . . . . . . . . . . . . . . . . . . . . . . . 37
13 Confirmando a desabilitação da account . . . . . . . . . . . . . . . 38
14 Bloqueando uma account . . . . . . . . . . . . . . . . . . . . . . . . 38
15 Confirmando o bloqueio da account . . . . . . . . . . . . . . . . . . 38
16 Definindo duas faixas IPv4 e uma IPv6 . . . . . . . . . . . . . . . . 39
17 Iniciando a criação de uma nova role . . . . . . . . . . . . . . . . . 40
18 Criando a nova role . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
19 Acessando a recém-criada role . . . . . . . . . . . . . . . . . . . . . 42
20 Customizando as regras da role . . . . . . . . . . . . . . . . . . . . 42
21 Iniciando a edição de uma role . . . . . . . . . . . . . . . . . . . . . 43
22 Editando a role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
23 Removendo uma role . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
24 Confirmando a remoção da role . . . . . . . . . . . . . . . . . . . . 43
25 Acessando a página de domains . . . . . . . . . . . . . . . . . . . . 45
26 Criando um novo domain . . . . . . . . . . . . . . . . . . . . . . . . 45
10
27 Definindo o nome do novo domain . . . . . . . . . . . . . . . . . . 46
28 Visualizando o domain criado . . . . . . . . . . . . . . . . . . . . . . 46
29 Selecionando o domain criado . . . . . . . . . . . . . . . . . . . . . 46
30 Iniciando a edição do novo domain . . . . . . . . . . . . . . . . . . 47
31 Editando o domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
32 Navegando até a página de accounts . . . . . . . . . . . . . . . . . . 50
33 Selecione a account que o novo user fará parte . . . . . . . . . . . 50
34 Veja os users da account . . . . . . . . . . . . . . . . . . . . . . . . . 51
35 Adicionando um novo user . . . . . . . . . . . . . . . . . . . . . . . 51
36 Defina os dados do novo user e salve as alterações . . . . . . . . . 51
37 Selecionando o user para editá-lo . . . . . . . . . . . . . . . . . . . 52
38 Iniciando a edição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
39 Editando o user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
40 Deletando um user . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
41 Confirme a remoção do user . . . . . . . . . . . . . . . . . . . . . . 53
42 Desabilitando um user . . . . . . . . . . . . . . . . . . . . . . . . . . 53
43 Selecionando o user que deseja reabilitar . . . . . . . . . . . . . . . 54
44 Habilitando um user . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
45 Encontrando as configurações . . . . . . . . . . . . . . . . . . . . . 55
46 Mensagem exibida ao tentar realizar login com user desabilitado . 56
47 Gerar chaves de acesso para um usuário . . . . . . . . . . . . . . . 57
48 Mensagem de confirmação para gerar chaves de acesso . . . . . 57
49 Configurando a autenticação de dois fatores. . . . . . . . . . . . . 59
50 Opções de provedores de autenticação de dois fatores. . . . . . . 59
51 Configurando a autenticação de dois fatores com TOTP. . . . . . . 60
52 Verificação com TOTP durante o login. . . . . . . . . . . . . . . . . . 60
53 Configurando a autenticação de dois fatores com static PIN. . . . . 61
54 Verificação com static PIN durante o login. . . . . . . . . . . . . . . 61
55 Desativando a autenticação de dois fatores. . . . . . . . . . . . . . 62
11
56 Configurando a autenticação de dois fatores no login. . . . . . . . 62
57 Exemplo de como o timezone afeta a interface do Apache Cloud-
Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
58 Editando o timezone do user . . . . . . . . . . . . . . . . . . . . . . . 63
59 Ativando a funcionalidade de timezone local . . . . . . . . . . . . . 64
60 Iniciando a criação de um novo project . . . . . . . . . . . . . . . . 65
61 Criando o novo project . . . . . . . . . . . . . . . . . . . . . . . . . . 65
62 Limites de recursos de um project . . . . . . . . . . . . . . . . . . . 66
63 Alterando os limites de recursos de um project . . . . . . . . . . . 67
64 Iniciando a criação de uma project role . . . . . . . . . . . . . . . . 68
65 Criando uma project role . . . . . . . . . . . . . . . . . . . . . . . . . 68
66 Definindo as regras da project role . . . . . . . . . . . . . . . . . . . 68
67 Iniciando a adição de membros no project . . . . . . . . . . . . . . 69
68 Adicionando uma account no project . . . . . . . . . . . . . . . . . . 69
69 Adicionando um user no project . . . . . . . . . . . . . . . . . . . . 70
70 Selecionando a view . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
71 Iniciando a edição do project . . . . . . . . . . . . . . . . . . . . . . 72
72 Editando o project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
73 Iniciando a suspensão do project . . . . . . . . . . . . . . . . . . . . 73
74 Suspendendo o project . . . . . . . . . . . . . . . . . . . . . . . . . . 73
75 Iniciando a exclusão do project . . . . . . . . . . . . . . . . . . . . . 74
76 Excluíndo o project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
77 Adicionando uma VM . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
78 Criação de uma VM com uma conta de usuário do tipo root admin 78
79 Criação de uma VM como admin . . . . . . . . . . . . . . . . . . . . 80
80 Criação de uma VM como user . . . . . . . . . . . . . . . . . . . . . 82
81 Visualização das opções de inicialização . . . . . . . . . . . . . . . 84
82 Opções de inicialização no formulário de deploy de uma VM . . . 84
83 Configuração final da VM . . . . . . . . . . . . . . . . . . . . . . . . 85
12
84 Escolhendo a VM que será destruída . . . . . . . . . . . . . . . . . 86
85 Confirmando a destruição da VM . . . . . . . . . . . . . . . . . . . . 87
86 Parando e iniciando uma VM . . . . . . . . . . . . . . . . . . . . . . 87
87 Escolhendo a VM que será reiniciada . . . . . . . . . . . . . . . . . 87
88 Reiniciando a VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
89 Botões de acesso e cópia de URL do console da VM . . . . . . . . . 88
90 Resposta da API createConsoleEndpoint . . . . . . . . . . . . . . . 89
91 Ativando dynamic scaling em uma VM . . . . . . . . . . . . . . . . . 90
92 Configurando dynamic scaling em um template . . . . . . . . . . . . 91
93 Escolhendo a VM que terá sua account migrada . . . . . . . . . . . 93
94 Migrando account da VM . . . . . . . . . . . . . . . . . . . . . . . . . 94
95 Adicionando user-data na criação da VM . . . . . . . . . . . . . . . 95
96 Alterando user-data na edição da VM . . . . . . . . . . . . . . . . . 96
97 Verificando funcionalidade do user-data . . . . . . . . . . . . . . . 96
98 Aba de configurações da VM . . . . . . . . . . . . . . . . . . . . . . 97
99 Visualizar todos os volumes . . . . . . . . . . . . . . . . . . . . . . . 101
100 Criar novo volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
101 Configurar novo volume . . . . . . . . . . . . . . . . . . . . . . . . . 102
102 Verificando novo volume . . . . . . . . . . . . . . . . . . . . . . . . 102
103 Upload de volume local . . . . . . . . . . . . . . . . . . . . . . . . . 102
104 Realizar upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
105 Fazendo upload de volume . . . . . . . . . . . . . . . . . . . . . . . 105
106 Configurando o upload de volume . . . . . . . . . . . . . . . . . . . 105
107 Acessando os detalhes do volume . . . . . . . . . . . . . . . . . . . 106
108 Adicionando o volume à VM . . . . . . . . . . . . . . . . . . . . . . . 106
109 Configurando a VM que receberá o novo volume . . . . . . . . . . 107
110 Removendo o volume da VM . . . . . . . . . . . . . . . . . . . . . . 107
111 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
112 Redimensionar o volume . . . . . . . . . . . . . . . . . . . . . . . . 108
13
113 Configurar redimensionamento . . . . . . . . . . . . . . . . . . . . 109
114 Fazer download do volume . . . . . . . . . . . . . . . . . . . . . . . 109
115 Confirmar download . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
116 Adicionando automatização de snapshots para um volume . . . . 110
117 Configurando a automatização das snapshots . . . . . . . . . . . . 110
118 Removendo o volume . . . . . . . . . . . . . . . . . . . . . . . . . . 111
119 Confirmar a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
120 Navegando até a rede guest . . . . . . . . . . . . . . . . . . . . . . . 112
121 Rede isolada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
122 Rede isolada criada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
123 Criando uma rede L2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
124 Rede L2 criada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
125 Rede shared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
126 Rede shared criada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
127 Acessando os detalhes de uma rede guest . . . . . . . . . . . . . . 118
128 Excluindo uma rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
129 Confirmando a exclusão da rede . . . . . . . . . . . . . . . . . . . . 118
130 Editando uma rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
131 Reiniciando uma rede . . . . . . . . . . . . . . . . . . . . . . . . . . 119
132 Configurando as egress rules . . . . . . . . . . . . . . . . . . . . . . 120
133 Acessando a rede client-network. . . . . . . . . . . . . . . . . . . . 121
134 Adicionando uma conta em Add network permission. . . . . . . . 122
135 Após adição da network permission. . . . . . . . . . . . . . . . . . . 123
136 Acessando o IP público . . . . . . . . . . . . . . . . . . . . . . . . . . 124
137 Vendo os detalhes do IP público . . . . . . . . . . . . . . . . . . . . 124
138 Configurando o firewall . . . . . . . . . . . . . . . . . . . . . . . . . 125
139 Habilitando static NAT . . . . . . . . . . . . . . . . . . . . . . . . . . 125
140 Configurando o IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
141 Verificando a configuração final . . . . . . . . . . . . . . . . . . . . 126
14
142 Acessando e configurando as portas da aba de port forwarding . . 127
143 Escolhendo a VM que terá a porta mapeada . . . . . . . . . . . . . 127
144 Exemplo de configuração de port forwarding com várias VMs . . . 128
145 Acessando e configurando as portas do load balancing . . . . . . . 128
146 Adicionando as VMs que serão gerenciadas pelo load balancer . . 129
147 Load balancer criado . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
148 Removendo o IP público . . . . . . . . . . . . . . . . . . . . . . . . . 130
149 Acessando os detalhes da rede . . . . . . . . . . . . . . . . . . . . . 130
150 Acesse os IPs públicos da rede . . . . . . . . . . . . . . . . . . . . . 131
151 Adquirir um novo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
152 Lista de IPs disponíveis . . . . . . . . . . . . . . . . . . . . . . . . . . 131
153 Novo IP adquirido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
154 Criando uma nova VPC . . . . . . . . . . . . . . . . . . . . . . . . . . 133
155 Configurando a nova VPC . . . . . . . . . . . . . . . . . . . . . . . . 133
156 Verificando se a VPC foi corretamente criada . . . . . . . . . . . . . 134
157 Reiniciando uma VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
158 Opções de reinicialização de uma VPC . . . . . . . . . . . . . . . . . 135
159 Removendo uma VPC . . . . . . . . . . . . . . . . . . . . . . . . . . 136
160 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
161 Erro que ocorre ao tentar deletar uma VPC . . . . . . . . . . . . . . 136
162 Acessando a VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
163 Acessando os IPs públicos da VPC . . . . . . . . . . . . . . . . . . . 137
164 Escolhendo um IP público . . . . . . . . . . . . . . . . . . . . . . . . 137
165 Acessando a VPC criada . . . . . . . . . . . . . . . . . . . . . . . . . 138
166 Verificando os detalhes da VPC . . . . . . . . . . . . . . . . . . . . . 138
167 Adicionando um novo tier . . . . . . . . . . . . . . . . . . . . . . . . 139
168 Criando um novo tier . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
169 Navegando até os tiers . . . . . . . . . . . . . . . . . . . . . . . . . . 140
170 Removendo um tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
15
171 Confirmando a remoção do tier . . . . . . . . . . . . . . . . . . . . 140
172 Adicionando uma nova ACL . . . . . . . . . . . . . . . . . . . . . . . 141
173 Criando uma nova ACL . . . . . . . . . . . . . . . . . . . . . . . . . . 142
174 Navegando até a ACL criada . . . . . . . . . . . . . . . . . . . . . . . 142
175 Navegando até a criação de uma nova regra na ACL . . . . . . . . 142
176 Adicionando regra que permite o tráfego de entrada da porta 22
do protocolo TCP (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . 143
177 Adicionando regra que permite o tráfego de saída da porta 22 do
protocolo TCP (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
178 Seleção da conta dona do tier . . . . . . . . . . . . . . . . . . . . . . 145
179 Seleção da conta no formulário de aquisição de IP público . . . . 146
180 Selecionando a VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
181 Detalhes da VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
182 Detalhes do public IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
183 Habilitando a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
184 VPN habilitada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
185 Desabilitar a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
186 Gerenciar usuários da VPN . . . . . . . . . . . . . . . . . . . . . . . 150
187 Iniciando adição de usuário à VPN . . . . . . . . . . . . . . . . . . . 150
188 Adicionando usuário à VPN . . . . . . . . . . . . . . . . . . . . . . . 151
189 Excluíndo usuário da VPN . . . . . . . . . . . . . . . . . . . . . . . . 151
190 Iniciando a adição de uma VPN no Linux . . . . . . . . . . . . . . . 152
191 Adicionando uma VPN no Linux . . . . . . . . . . . . . . . . . . . . 152
192 Informando a IPSec pre-shared key . . . . . . . . . . . . . . . . . . . 153
193 Informando a IPSec pre-shared key . . . . . . . . . . . . . . . . . . . 153
194 Desabilitando o protocolo EAP . . . . . . . . . . . . . . . . . . . . . 153
195 Desabilitando o protocolo EAP . . . . . . . . . . . . . . . . . . . . . 154
196 Adicionando uma VPN no Windows . . . . . . . . . . . . . . . . . . 154
197 Iniciando a adição de uma VPN no Windows . . . . . . . . . . . . . 155
16
198 Finalizando a adição de uma VPN no Windows . . . . . . . . . . . . 155
199 Alterando configurações do PPP . . . . . . . . . . . . . . . . . . . . 156
200 Habilitando o protocolo MS-CHAP v2 . . . . . . . . . . . . . . . . . 157
201 Desabilitando IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
202 Desabilitando o uso de gateway padrão na rede remota . . . . . . 158
203 Navegando até a aba VPN customer gateway . . . . . . . . . . . . . 158
204 Criando um VPN customer gateway . . . . . . . . . . . . . . . . . . . 159
205 Editando um VPN customer gateway . . . . . . . . . . . . . . . . . . 160
206 Deletando um VPN customer gateway . . . . . . . . . . . . . . . . . 160
207 Navegando até VPN gateway nos detalhes da VPC . . . . . . . . . . 160
208 Criando um VPN gateway . . . . . . . . . . . . . . . . . . . . . . . . 161
209 Navegando até VPN connection nos detalhes da VPC . . . . . . . . 161
210 Criando uma conexão VPN S2S . . . . . . . . . . . . . . . . . . . . . 162
211 Reiniciando uma conexão VPN S2S . . . . . . . . . . . . . . . . . . . 162
212 Removendo uma conexão VPN S2S . . . . . . . . . . . . . . . . . . 162
213 Gerando keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
214 Visualizando templates e ISOs . . . . . . . . . . . . . . . . . . . . . . 170
215 Acessando os detalhes do template . . . . . . . . . . . . . . . . . . 171
216 Detalhes do template . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
217 Acessando os detalhes da ISO . . . . . . . . . . . . . . . . . . . . . 172
218 Detalhes da ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
219 Filtros para listagem de ISOs e templates. . . . . . . . . . . . . . . . 174
220 Registrando o template . . . . . . . . . . . . . . . . . . . . . . . . . . 174
221 Configurando o template . . . . . . . . . . . . . . . . . . . . . . . . . 175
222 Registrando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
223 Configurando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
224 Fazendo upload do template . . . . . . . . . . . . . . . . . . . . . . . 177
225 Configurando o template . . . . . . . . . . . . . . . . . . . . . . . . . 178
226 Fazendo upload da ISO . . . . . . . . . . . . . . . . . . . . . . . . . . 178
17
227 Configurando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
228 Editando detalhes do template . . . . . . . . . . . . . . . . . . . . . 179
229 Editando o template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
230 Editando detalhes da ISO . . . . . . . . . . . . . . . . . . . . . . . . 180
231 Editando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
232 Editando as permissões do template . . . . . . . . . . . . . . . . . . 181
233 Editando as permissões da ISO . . . . . . . . . . . . . . . . . . . . . 182
234 Editando permissões . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
235 Editando compartilhamento do template . . . . . . . . . . . . . . . 183
236 Editando compartilhamento da ISO . . . . . . . . . . . . . . . . . . 183
237 Editando opções de compartilhamento . . . . . . . . . . . . . . . . 183
238 Deletando o template . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
239 Deletando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
240 Navegando até as VMs . . . . . . . . . . . . . . . . . . . . . . . . . . 185
241 Indo até o volume da VM . . . . . . . . . . . . . . . . . . . . . . . . 186
242 Criando o template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
243 Configurando o template . . . . . . . . . . . . . . . . . . . . . . . . . 187
244 Resource tags de um componente qualquer . . . . . . . . . . . . . 188
245 Navegando até os affinity groups . . . . . . . . . . . . . . . . . . . . 189
246 Criando um affinity group . . . . . . . . . . . . . . . . . . . . . . . . 190
247 Affinity group criado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
248 Acessando a VM que será movida ao grupo . . . . . . . . . . . . . 190
249 Movendo a VM para um affinity group . . . . . . . . . . . . . . . . . 191
250 Selecionando o grupo . . . . . . . . . . . . . . . . . . . . . . . . . . 191
251 Acessando o grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
252 Visualizando as VMs no grupo . . . . . . . . . . . . . . . . . . . . . 192
253 Lista de VMs no grupo . . . . . . . . . . . . . . . . . . . . . . . . . . 192
254 Excluindo o grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
255 Criando uma rede isolada . . . . . . . . . . . . . . . . . . . . . . . . 195
18
256 Acessando a aba de Public IP addresses . . . . . . . . . . . . . . . . 195
257 Adquirindo um novo IP público . . . . . . . . . . . . . . . . . . . . . 196
258 Adicionando uma regra de load balancing . . . . . . . . . . . . . . 196
259 Selecionando a rede isolada . . . . . . . . . . . . . . . . . . . . . . . 197
260 Selecionando a regra de load balancing . . . . . . . . . . . . . . . . 197
261 Configurando a scale-up policy . . . . . . . . . . . . . . . . . . . . . 198
262 Configurando a scale-down policy . . . . . . . . . . . . . . . . . . . . 199
263 Configurando os detalhes do autoscale VM group . . . . . . . . . . 200
264 Visualizando as instâncias do autoscale VM group . . . . . . . . . . 200
265 Instâncias do autoscale VM group . . . . . . . . . . . . . . . . . . . . 201
266 Instâncias do autoscale VM group após o scale-up . . . . . . . . . . 201
267 Instâncias do autoscale VM group após o scale-down . . . . . . . . . 202
268 Desativando o autoscale VM group . . . . . . . . . . . . . . . . . . . 202
269 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
270 Editando os detalhes do grupo e parâmetros de deploy das VMs . 203
271 Diálogo de edição dos detalhes do grupo e parâmetros de deploy
das VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
272 Editando a scale-up policy do grupo . . . . . . . . . . . . . . . . . . 204
273 Editando a scale-down policy do grupo . . . . . . . . . . . . . . . . . 204
274 Ativando o autoscale VM group . . . . . . . . . . . . . . . . . . . . . 205
275 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
276 Excluindo o autoscale VM group . . . . . . . . . . . . . . . . . . . . . 205
277 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
278 Formulário de adição de versão Kubernetes . . . . . . . . . . . . . 209
279 Deletando ISO Kubernetes via UI . . . . . . . . . . . . . . . . . . . . 210
280 Confirmar exclusão da ISO Kubernetes . . . . . . . . . . . . . . . . 210
281 Formulário de criação de cluster Kubernetes . . . . . . . . . . . . . 212
282 Formulário de scaling de cluster Kubernetes . . . . . . . . . . . . . 213
283 Formulário de upgrade de cluster Kubernetes . . . . . . . . . . . . 214
19
284 Acessando o Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . 215
285 Acessando os detalhes de uma VM . . . . . . . . . . . . . . . . . . 218
286 Tirando uma snapshot do Volume . . . . . . . . . . . . . . . . . . . 218
287 Escolhendo o volume que será tirada a snapshot . . . . . . . . . . 218
288 Configurando a snapshot . . . . . . . . . . . . . . . . . . . . . . . . 219
289 Tirando uma snapshot da VM . . . . . . . . . . . . . . . . . . . . . . 219
290 Configurando a snapshot . . . . . . . . . . . . . . . . . . . . . . . . 219
291 Acessando as snapshots . . . . . . . . . . . . . . . . . . . . . . . . . 220
292 Acessando as snapshots de volumes . . . . . . . . . . . . . . . . . . 220
293 Acessando as snapshots de VM . . . . . . . . . . . . . . . . . . . . . 220
294 Acessando os detalhes da snapshot . . . . . . . . . . . . . . . . . . 221
295 Criando o template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
296 Configurando os dados do template . . . . . . . . . . . . . . . . . . 222
297 Criando o novo volume . . . . . . . . . . . . . . . . . . . . . . . . . 222
298 Configurando o novo volume . . . . . . . . . . . . . . . . . . . . . . 223
299 Revertendo para a snapshot . . . . . . . . . . . . . . . . . . . . . . . 223
300 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
301 Deletando a snapshot de volume . . . . . . . . . . . . . . . . . . . . 224
302 Confirmando a remoção . . . . . . . . . . . . . . . . . . . . . . . . . 224
303 Acessando os detalhes da snapshot da VM . . . . . . . . . . . . . . 224
304 Criando uma snapshot de volume a partir da snapshot da VM . . . 225
305 Configurando qual volume será extraído . . . . . . . . . . . . . . . 225
306 Criando uma snapshot de volume . . . . . . . . . . . . . . . . . . . 225
307 Revertendo a snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . 226
308 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
309 Removendo a snapshot de VM . . . . . . . . . . . . . . . . . . . . . 226
310 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
311 Navegando pelos eventos . . . . . . . . . . . . . . . . . . . . . . . . 228
312 Arquivando ou deletando um evento . . . . . . . . . . . . . . . . . 228
20
313 Habilitando a configuração . . . . . . . . . . . . . . . . . . . . . . . 229
314 Exemplo de popup com os ícones de ajuda . . . . . . . . . . . . . . 230
315 Iniciando a criação de uma nova disk offering . . . . . . . . . . . . . 231
316 Criando a nova disk offering . . . . . . . . . . . . . . . . . . . . . . . 232
317 Iniciando a edição da disk offering . . . . . . . . . . . . . . . . . . . 234
318 Editando a disk offering . . . . . . . . . . . . . . . . . . . . . . . . . . 235
319 Iniciando a atualização de acesso da disk offering . . . . . . . . . . 235
320 Atualizando o acesso da disk offering . . . . . . . . . . . . . . . . . 235
321 Alterando ordem da disk offering . . . . . . . . . . . . . . . . . . . . 236
322 Iniciando a exclusão da disk offering . . . . . . . . . . . . . . . . . . 236
323 Excluindo a disk offering . . . . . . . . . . . . . . . . . . . . . . . . . 236
324 Iniciando a criação de uma nova compute offering . . . . . . . . . . 238
325 Criando a nova compute offering - 1 - continua . . . . . . . . . . . . 239
326 Iniciando a edição da compute offering . . . . . . . . . . . . . . . . 242
327 Editando a compute offering . . . . . . . . . . . . . . . . . . . . . . . 242
328 Iniciando a atualização de acesso da compute offering . . . . . . . 243
329 Atualizando o acesso da compute offering . . . . . . . . . . . . . . . 243
330 Alterando a ordem da compute offering . . . . . . . . . . . . . . . . 243
331 Iniciando a exclusão da compute offering . . . . . . . . . . . . . . . 243
332 Excluíndo a compute offering . . . . . . . . . . . . . . . . . . . . . . 244
333 Iniciando a alteração da compute offering . . . . . . . . . . . . . . . 244
334 Alterando a compute offering . . . . . . . . . . . . . . . . . . . . . . 245
335 Alterando a compute offering . . . . . . . . . . . . . . . . . . . . . . 245
336 Iniciando a criação de uma nova network offering . . . . . . . . . . 247
337 Criando a nova network offering - 1 - continua . . . . . . . . . . . . 247
338 Criando a nova network offering - 2 . . . . . . . . . . . . . . . . . . . 249
339 Iniciando a edição da network offering . . . . . . . . . . . . . . . . . 250
340 Editando a network offering . . . . . . . . . . . . . . . . . . . . . . . 250
341 Iniciando a desabilitação da network offering . . . . . . . . . . . . . 251
21
342 Desabilitando a network offering . . . . . . . . . . . . . . . . . . . . 251
343 Iniciando a atualização de acesso da network offering . . . . . . . . 251
344 Atualizando o acesso da network offering . . . . . . . . . . . . . . . 251
345 Alterando ordem da network offering . . . . . . . . . . . . . . . . . 252
346 Iniciando a exclusão da network offering . . . . . . . . . . . . . . . . 252
347 Excluíndo a network offering . . . . . . . . . . . . . . . . . . . . . . . 252
348 Iniciando a criação de uma nova VPC offering . . . . . . . . . . . . . 253
349 Criando a nova VPC offering . . . . . . . . . . . . . . . . . . . . . . . 254
350 Iniciando a edição da VPC offering . . . . . . . . . . . . . . . . . . . 255
351 Editando a VPC offering . . . . . . . . . . . . . . . . . . . . . . . . . . 255
352 Iniciando a desabilitação da VPC offering . . . . . . . . . . . . . . . 255
353 Desabilitando a VPC offering . . . . . . . . . . . . . . . . . . . . . . . 255
354 Iniciando a atualização de acesso da VPC offering . . . . . . . . . . 256
355 Atualizando o acesso da VPC offering . . . . . . . . . . . . . . . . . 256
356 Alterando a ordem da VPC offering . . . . . . . . . . . . . . . . . . . 256
357 Iniciando a exclusão da VPC offering . . . . . . . . . . . . . . . . . . 256
358 Excluíndo a VPC offering . . . . . . . . . . . . . . . . . . . . . . . . . 257
359 Utilizando o autocomplete . . . . . . . . . . . . . . . . . . . . . . . . 260
360 Verificando o autocomplete para um comando específico . . . . . 261
361 Verificando o autocomplete para uma API específica . . . . . . . . 261
362 Utilizando o -h para obter ajuda . . . . . . . . . . . . . . . . . . . . 262
363 Realizando uma chamada . . . . . . . . . . . . . . . . . . . . . . . . 263
364 Fazendo deploy de uma VM via CloudMonkey . . . . . . . . . . . . 264
365 Listagem das tarifas ativas . . . . . . . . . . . . . . . . . . . . . . . . 266
366 Detalhes das tarifas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
367 Acessando detalhes e relatórios de uma conta . . . . . . . . . . . . 267
368 Listagem de créditos . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
369 Listagem de uso de recurso . . . . . . . . . . . . . . . . . . . . . . . 269
370 Listagem detalhada de uso de recurso . . . . . . . . . . . . . . . . 270
22
Lista de Tabelas
24
Notas
• Este documento não abrange todos os tópicos, assuntos ou casos de uso
do Apache CloudStack. Portanto, caso não encontre o que está procu-
rando, faça uma solicitação de ajuste ou inclusão via GitLab.
• Este documento é atualizado periodicamente. Portanto, fique atento a
novas atualizações.
25
1. Introdução
Durante os últimos anos, o uso da computação em nuvem (privada, pública
e/ou híbrida) teve um grande crescimento, intensificando as oportunidades no
mercado de serviços digitais. Para atender a demanda, a infraestrutura ne-
cessária para criar e manter esse tipo de ambiente aumenta constantemente,
impactando diretamente nos custos de gerenciamento e operação.
Ambientes de computação em nuvem são complexos e heterogêneos, pos-
suindo variáveis dinâmicas e inúmeros componentes que devem ser interliga-
dos e gerenciados. Para uma eficiente gestão de tais ambientes, é necessária a
adoção de ferramentas capazes de orquestrar a infraestrutura, auxiliando na
implantação, manutenção e gerência de serviços e sistemas de nuvem.
As plataformas Apache CloudStack e OpenStack são as principais alterna-
tivas opensource para criação de ambientes de nuvem privada, se destacando
pela robustez, maturidade dos projetos e amplitude de tecnologias e funciona-
lidades suportadas. Tais características se traduzem em centenas de compa-
nhias que adotam alguma dessas plataformas ao redor do mundo, sendo algu-
mas delas: USP, UNICAMP, Dell, Deutsche Telekom, Apple, Planetel, Locaweb e
muitas outras.
A SC Clouds vem ao encontro dessa necessidade, fornecendo consultoria,
suporte e desenvolvimento continuados aos provedores de infraestrutura de
nuvem e às empresas que possuem a tecnologia de nuvem como seu pilar base
para criação e fornecimento de serviços. Em modo de parceria com os clien-
tes, é realizado o planejamento e execução de ambientes de computação em
nuvem que fornecem infraestrutura como serviço. Nossos profissionais pos-
suem domínio pleno das plataformas Apache CloudStack e OpenStack, sendo
responsáveis por diversas funcionalidades novas e correções de bugs dos pro-
jetos. Atualmente a SC Clouds atua auxiliando na gerência, planejamento, im-
plantação, suporte, correção de bugs e implementação de novas funcionalida-
des para empresas na Alemanha, Brasil, Itália, México e Suiça.
26
1.1. Plataformas de nuvem privada
Plataformas de orquestração de nuvem, como o Apache CloudStack e Open-
Stack, são utilizadas para prover nuvem privada, pública ou híbrida em empre-
sas e instituições ao redor do mundo. Elas são capazes de conectar diferentes
sistemas computacionais (armazenamento, rede e virtualizadores), criando a
abstração do modelo de infraestrutura como serviço para usuários e adminis-
tradores de sistema.
Tanto o OpenStack quanto o CloudStack são softwares de orquestração de
ambientes de nuvem de código aberto e de uso gratuito. Ambos têm como ob-
jetivo o gerenciamento de recursos computacionais, trabalhando com o con-
ceito de virtualização para fornecimento de recursos sob demanda, focando
no provimento de recursos de infraestrutura como serviço.
Figura 1: Computação em nuvem
1.1.1. Funcionalidades básicas
Tanto o CloudStack quanto o OpenStack oferecem funcionalidades básicas
e necessárias para o provisionamento de serviços de computação em nuvem.
Algumas das funcionalidades providas são:
27
• Serviços de computação
– Provisionamento de VMs e gerenciamento de seus recursos (redes,
memória, CPU, discos...);
– Gestão de imagens com as quais as VMs serão criadas;
– Suporte a múltiplos hypervisors, tais como KVM, XenServer e Vmware.
• Serviços de rede
– Gestão e configuração de redes compartilhadas e dedicadas;
– Criação de VLANS, VxLANS (Overlay Networks) e novas topologias;
– Definição de políticas de acesso e roteamentos;
– Gestão de QoS, Load Balancers e Firewalls;
• Serviços de armazenamento
– Gestão de discos;
– Armazenamento baseado em objetos e blocos;
– Backups;
– Suporte a SDS (Software Defined Storage), e.g. Ceph/RBD.
• Serviços de monitoramento de recursos
– Monitoramento de eventos;
– Apresentação dos recursos disponíveis e utilizados;
– Precificação e cobrança (billing).
• APIs REST abertas, padronizadas e documentadas, para gerenciamento
de todos os serviços, automação e integração com outras ferramentas;
• Serviço de autenticação com integração nativa com LDAP;
• Suporte a sistemas federados SAML2 e OpenID Connect;
28
• Containers como serviço.
Das funcionalidades básicas de um sistema de orquestração de nuvem, o
Apache CloudStack possui limitações em relação a sistemas federados, visto
que suporta somente o protocolo SAML2.
1.2. História do Apache CloudStack
O projeto CloudStack teve seu início em 2008 como um projeto da startup
conhecida como VMOps. A companhia mudou seu nome para Cloud.com e
lançou uma versão estável do CloudStack em 2010, sob a licença GNU GPLv3
(General Public License version 3). Em 2011, a Cloud.com foi adquirida pela
Citrix, e em 2012 o projeto foi doado à fundação Apache. O CloudStack vem
crescendo nos últimos anos e tem se tornado uma ferramenta de orquestra-
ção de referência, sendo utilizado por diversas organizações, como a Globo,
RNP, UNICAMP, Universidade de São Paulo, Locaweb, CGEE, Apple, Dell, Nokia
e Disney.
29
2. Funcionalidades do Apache CloudStack
Nessa seção serão introduzidas, de forma breve, as principais funcionali-
dade do Apache CloudStack e como utilizá-las.
2.1. Dashboard inicial
Esse é o dashboard padrão do Apache CloudStack, onde é possível visualizar
a quantidade de recursos consumidos pelo usuário.
Figura 2: Dashboard inicial
2.2. Gestão de acesso à nuvem
O CloudStack permite que o administrador da nuvem defina e gerencie com
precisão quais recursos estão disponíveis e para quem através de domínios,
contas, usuários, projetos e roles. Para tal, primeiramente é necessário enten-
der esses conceitos.
• Conta: uma conta representa um cliente do provedor de serviços da nu-
vem, podendo ser acessada, ou não, por diversos usuários. Nesse con-
texto uma conta define, por exemplo, um departamento de uma empresa
ou uma faculdade dentro de uma universidade, abrigando os usuários
desses setores.
30
• Usuário: o usuário, por sua vez, é um integrante da conta. Ele pertence
apenas à uma conta, possui acesso aos recursos de acordo com o tipo da
conta e recebe o mesmo nível de privilégios da conta que o abriga. Eles
são alias para a conta.
• Domínio: um domínio pode conter diversas contas que, geralmente, pos-
suem um relacionamento lógico entre si. São utilizados para limitar os
recursos que serão entregues aos usuários desse domínio.
• Projeto: projetos são uma forma de organizar contas e recursos. Os
usuários podem ser agrupados em projetos para compartilhar recursos
como VMs, snapshots, templates e endereços IP. Recursos criados em um
projeto pertencem apenas a ele, não à uma conta, e só podem ser usa-
dos dentro dele. Os membros do projeto podem visualizar e gerenciar os
recursos virtuais criados por qualquer conta dentro dele.
• Roles: definido a nível de conta e/ou de projeto, são conjuntos que defi-
nem as permissões que as contas e os usuários terão no ambiente, como
criação, listagem e remoção de recursos.
A figura a seguir apresenta um diagrama de relacionamento entre contas,
domínios, projetos e usuários.
Figura 3: Diagrama de relacionamento entre contas, domínios, projetos e usuários.
31
2.2.1. Account
Representa um cliente que utiliza os serviços da nuvem. No CloudStack,
uma account pode ser utilizada por mais de um usuário, ao ponto em que uma
organização inteira pode utilizar a mesma conta. Ela pode ser dividida em três
tipos básicos para visualização dos recursos, sendo estes tipos definidos no
momento da criação da role:
• Admin: possui acesso a todos os recursos do ambiente, incluindo ele-
mentos de infraestrutura e configurações da plataforma. Essas contas
também são chamadas de root admin.
• DomainAdmin: possui acesso a todos os elementos alocados em seu
domínio, incluindo gestão de usuários.
• ResourceAdmin: possui acesso a todos os elementos alocados em seu
domínio, exceto gestão de usuários.
• User: possui acesso somente aos elementos alocados em sua conta.
O conjunto de permissões para cada tipo de conta é definido através das
roles; contudo, algumas ações, bem como o escopo dos recursos visualizados,
dependem do tipo da conta.
Uma account criada não pode ter seu tipo alterado, mas pode ter seu con-
junto de permissões alterado.
É possível realizar as seguintes operações sobre as accounts:
32
2.2.1.1. Adição de account
Figura 4: Navegando até a página de adição de accounts
Figura 5: Adicionando uma nova account
33
2.2.1.2. Visualização de detalhes de account
Figura 6: Navegando até a página de detalhes de uma account
Figura 7: Vendo os detalhes da account
Todas as operações abaixo detalhadas são realizadas nessa página.
34
2.2.1.3. Deleção de account
Figura 8: Deletando uma account
Ao tentar deletar uma account, um popup irá pedir a confirmação dessa ação.
Durante esse processo de remoção, todos os usuários e recursos (VM, snapshots,
templates, volumes, etc) relacionados à account também serão removidos.
Figura 9: Confirmando a remoção da account
2.2.1.4. Configuração de acesso de uma account
Existem duas formas de configurar o acesso de uma account:
• Editar os limites da account: essa é a forma mais básica de configurar o
acesso de uma account, a qual o administrador do sistema define limites
de recursos que a mesma pode acessar.
35
Figura 10: Editando os limites de uma account
• Editar as settings da account: apresenta opções mais avançadas para con-
figurar o acesso dela.
36
Figura 11: Editando as configurações de uma account
2.2.1.5. Desabilitação de account
Essa opção impede os usuários da account de acessar e gerenciar qualquer
recurso, e automaticamente desliga as VMs criadas pelos mesmos. Ela pode
ser reabilitada posteriormente.
Figura 12: Desabilitando uma account
37
Figura 13: Confirmando a desabilitação da account
2.2.1.6. Bloqueio de account
Opção semelhante à de desabilitar account, no entanto ela apenas impede os
usuários de criar e gerenciar novos recursos. Recursos já existentes não serão
afetados.
Figura 14: Bloqueando uma account
Figura 15: Confirmando o bloqueio da account
38
2.2.1.7. Restrição de acesso à API por IP
Dentro das configurações globais, de account ou domain
1
, pode-se alterar o
parâmetro api.allowed.source.cidr.list para definir uma lista (separada por vír-
gula) dos únicos endereços IPv4 e IPv6 com permissão para acessar a API do
CloudStack. O valor padrão é 0.0.0.0/0,::/0, permitindo acesso por qualquer IP.
Se houver disparidade entre as configurações, a de account tem prioridade.
É preciso que a configuração global api.source.cidr.checks.enabled seja true
para utilizar esta função.
Figura 16: Definindo duas faixas IPv4 e uma IPv6
O ACS utiliza o header X-Forwarded-For da requisição HTTP para identificar
o IP de origem das requisições à API. Isso permite a auditoria dos processos
realizados pelos usuários e a restrição de IP mencionada nesta seção. Este
header pode ser alterado pelo requisitante, portanto é necessário configurar
os firewalls e proxies que intermedeiam a comunicação com o ACS de forma
que isso seja identificado e o header repassado para o ACS contenha o IP de
origem real do requisitante.
2.2.2. Roles
Roles representam conjuntos de permissões que as contas possuem den-
tro da infraestrutura de nuvem. Além do conjunto de permissões, conforme
apresentado na Seção 2.2.1, roles definem os tipos das contas, que indicam o
escopo para gerenciamento dos recursos. Os tipos de conta são:
• Admin: possui acesso a todos os recursos do ambiente, incluindo ele-
mentos de infraestrutura e configurações da plataforma. Essas contas
1
Se a configuração global enable.account.settings.for.domain for true.
39
também são chamadas de root admin.
• DomainAdmin: possui acesso a todos os elementos alocados em seu
domínio, incluindo gestão de usuários.
• ResourceAdmin: possui acesso a todos os elementos alocados em seu
domínio, exceto gestão de usuários.
• User: possui acesso somente aos elementos alocados em sua conta.
O CloudStack providencia roles padrões, as quais não podem ser editadas
ou removidas. Contudo, é possível criar roles personalizadas, as quais têm-se
completo acesso. O procedimento para realizar essa ação é o seguinte:
2.2.2.1. Adição de role
1. Navegue até Roles e adicione uma nova role.
Figura 17: Iniciando a criação de uma nova role
2. Adicione a configuração básica da nova role:
40
Figura 18: Criando a nova role
O campo Based on é obrigatório. Ele pode se referir à tipos ou roles já
existentes. Ele é utilizado para determinar qual o tipo de account que
pode utilizar tal role. Exempo: uma role do tipo Admin apenas pode ser
alocada em accounts do tipo Admin.
Sobre as duas opções disponíveis:
• Type: define qual será o tipo de account que pode utilizar essa role.
• Role: utiliza uma role já existente para definir qual será o tipo de ac-
count que pode utilizar essa role e faz uma cópia das regras contidas
na mesma.
2.2.2.2. Visualização de detalhes de role
1. Navegue até os detalhes da role criada.
41
Figura 19: Acessando a recém-criada role
2.2.2.3. Customização de uma role
1. Customize as regras dessa role.
Figura 20: Customizando as regras da role
Para utilizar essa nova role é necessário criar uma nova account utilizando-a.
2.2.2.4. Remoção de role
1. Também é possível editar e remover roles, exceto por uma situação que
será melhor explicada adiante.
42
Figura 21: Iniciando a edição de uma role
Figura 22: Editando a role
Figura 23: Removendo uma role
Figura 24: Confirmando a remoção da role
43
Algumas observações importantes:
• Roles que já estão associadas a uma account não podem ser editadas ou
deletadas, sendo necessário remover a account primeiro.
• Uma única role pode ser utilizada por várias accounts, mas uma account
pode utilizar apenas uma role.
• Apesar de roles associadas a accounts não poderem ser editadas ou dele-
tadas, ainda é possível alterar as regras que compõem essa role, seja as
editando, removendo ou adicionando.
2.2.3. Domains
Agregação de várias accounts, geralmente usado para unificar accounts com
diferentes roles, mas que fazem parte da mesma organização. Domains per-
mitem isolar e limitar o acesso aos recursos da nuvem para as accounts que o
compõem. A arquitetura padrão do CloudStack já possui um domain padrão,
chamado de ROOT, que é o “pai” de todos os outros domains, além de possuir
acesso total aos recursos da nuvem.
• O Domain ROOT:
O domain ROOT é considerado o domain padrão. Ele não pode ser dele-
tado e nem pode ter seu acesso aos recursos da nuvem reduzidos. Ape-
nas usuários que fazem parte de accounts que utilizam a role root admin
podem ter acesso à esse domain. A partir desse domain são configurados
os demais.
44
Figura 25: Acessando a página de domains
2.2.3.1. Adição de domain
• Ao adicionar um novo domain, ele será criado como subdomain (filho) do
domain atual. No exemplo apresentado, existe apenas um domain. Po-
rém, em organizações mais complexas, onde existem diversos domains,
é necessária atenção na criação da hierarquia.
Figura 26: Criando um novo domain
45
Figura 27: Definindo o nome do novo domain
Figura 28: Visualizando o domain criado
Figura 29: Selecionando o domain criado
2.2.3.2. Configuração de domain
• Configurando o novo domain:
Por padrão, novos domains herdam do parent domain (pai) os privilégios
de acesso aos recursos. Porém, esses acessos podem ser alterados.
46
Figura 30: Iniciando a edição do novo domain
2.2.3.3. Definição de acessos do domain
• Definindo os novos acessos do domain:
Por padrão, o valor -1 indica limites infinitos, ou seja, accounts desse do-
main podem utilizar todos os recursos da nuvem. O valor 0 indica que
elas não podem utilizar aquele recurso. Qualquer valor maior que 0 de-
fine qual o valor máximo que as accounts daquele domain podem utilizar.
47
Figura 31: Editando o domain
Com o novo domain criado e configurado, o próximo passo é adicionar ac-
counts ao mesmo. Atualmente, não é possível migrar uma account de um do-
main para outro. Portanto, em estruturas nas quais os domains gerenciam a
nuvem, é necessário criá-los antes de criar as accounts.
2.2.3.4. Reestruturação da árvore de domínios
Para reestruturar a árvore de domínios, pode-se utilizar a API moveDomain
2
:
move domain domainid=<id_do_domain> parentdomainid=<id_do_parent_domain_destino>
É importante ressaltar que, para que o domain seja movido, é necessário seguir
as seguintes restrições:
• O domain e o parent domain devem estar ativos.
2
O parâmetro parentdomainid é opcional. Caso não seja informado, o domain será movido
para o parent domain ROOT.
48
• O novo parent domain não pode ser um subdomain do domain.
• Não deve existir um domain com o mesmo nome do domain a ser movido
no novo parent domain.
• O novo parent domain deve ter acesso a todos os recursos que o domain
e seus subdomains utilizam (redes shared e affinity groups).
2.2.4. Users
Representa um usuário que faz parte de uma account e tem um username
único dentro do domain. Usuários dentro do mesmo domínio conseguem se
comunicar e ver o que outros usuários estão fazendo, mas não conseguem ter
acesso à usuários que fazem parte de outros domínios. Eles possuem os pri-
vilégios concedidos para a account e atuam dentro de um domínio definido.
Dependendo da account que o usuário faz parte, o mesmo terá privilégios di-
ferentes dentro do domínio. Por exemplo:
• Usuários sem privilégio de administrador podem apenas utilizar os recur-
sos disponíveis dentro do domínio, respeitando as limitações da account
do qual faz parte e as limitações da role utilizada pela account
• Usuários administradores podem gerenciar os recursos, além de também
poderem gerenciar accounts e usuários dentro do domínio.
É possível adicionar vários users à mesma account, cada um deles possu-
indo um nome e senha próprios. Também é possível editar ou deletar users
já criados. Porém, essas duas operações só são permitidas para um usuário
admin.
2.2.4.1. Adição de user
Os passos para adicionar um novo user são:
1. Vá até Accounts.
49
Figura 32: Navegando até a página de accounts
2. Selecione em qual account o novo user será adicionado.
Figura 33: Selecione a account que o novo user fará parte
3. Navegue até a página de users dessa account.
50
Figura 34: Veja os users da account
4. Adicione um novo user.
Figura 35: Adicionando um novo user
Figura 36: Defina os dados do novo user e salve as alterações
2.2.4.2. Edição de user
Para editar um user:
51
1. Repita os passos 1, 2 e 3 da explicação anterior, mas dessa vez selecione
a account que contém o user que deseja editar.
2. Clique no user que deseja editar.
Figura 37: Selecionando o user para editá-lo
3. Clique em editar o user.
Figura 38: Iniciando a edição
4. Realize as alterações necessárias e salve.
Figura 39: Editando o user
52
2.2.4.3. Deleção de user
Para deletar um user:
1. Repita todos os passos (2) para chegar até a página de detalhes sobre o
user.
2. Remova o user.
Figura 40: Deletando um user
Figura 41: Confirme a remoção do user
2.2.4.4. Desabilitação/habilitação de user
Também é possível desabilitar um user, impedindo-o de acessar e gerenciar
qualquer recurso.
Figura 42: Desabilitando um user
Para liberar o acesso novamente é necessário que um administrador do
Domain habilite o user desabilitado.
53
Figura 43: Selecionando o user que deseja reabilitar
Figura 44: Habilitando um user
2.2.4.5. Políticas de senha
A fim de aumentar a segurança dos usuários do ambiente de nuvem, o opera-
dor pode habilitar políticas de senha (regras que a senha deve seguir), que po-
dem ser acessadas nas configurações globais. Vale ressaltar que essas regras
somente são impostas em senhas de usuários, outras senhas, por exemplo de
VMs, não são afetadas.
Atualmente existem 7 opções de políticas de senhas disponíveis:
• password.policy.allowPassw ordToContainUsername: indica se a senha
pode conter o nome do usuário.
54
• password.policy.mi nimum.digits: quantidade mínima de dígitos presen-
tes.
• password.policy.minimum.length: tamanho mínimo.
• password.policy.min imum.lowercase.letters: quantidade mínima de le-
tras minúsculas.
• pa s s w ord.policy.minimum.special.ch a racters: quantidade mínima de ca-
racteres especiais.
• password.policy.min imum.uppercase .letter s: quantidade mínima de le-
tras maiúsculas.
• password.policy.regex: expressão regular que a senha deve seguir.
Figura 45: Encontrando as configurações
Por padrão, não há nenhuma restrição para a criação da senha, todas as
configurações mencionadas acima são definidas da forma mais abrangente
possível. Cabe ao operador identificar se há necessidade de implementar essas
medidas de segurança e configurar as políticas de senha de acordo.
55
2.2.4.6. Desabilitação de user por erro de senha
O ACS possui a funcionalidade de desabilitar um user por realizar muitas ten-
tativas incorretas de login. Por padrão, é necessário que o usuário erre a senha
5 vezes seguidas para ser desabilitado. Esse valor pode ser alterado na confi-
guração global incorrect.login.attempts.allowed.
Para habilitá-lo novamente, siga os passos descritos na seção Desabilitar/Ha-
bilitar um user.
Figura 46: Mensagem exibida ao tentar realizar login com user desabilitado
2.2.4.7. Gerência de chaves de API dos users
Chaves de API são credenciais de acesso fornecidas de maneira a autorizar o
uso de funcionalidades específicas de uma ou mais APIs. Elas muitas vezes
atuam como um identificador único de autenticação de usuários. No Cloud-
Stack elas podem ser utilizadas para realizar operações e integrações (muitas
vezes de forma automatizada), acessar dados de uso e ferramentas específicas
do CloudStack para desenvolvimento, testes e integração.
O ACS permite que os usuários gerem suas próprias chaves e que adminis-
tradores criem e atualizem chaves de acesso para os seus usuários. Algumas
56
das operações possíveis com elas são:
1. registerUserKeys: Esse comando pede como entrada o ID do usuário para
qual será gerada as chaves de acesso, e como retorno apresenta a chave
da API e a chave secreta registrada para o ID informado.
2. getUserKeys: Retorna as chaves registradas para o ID de usuário infor-
mado na entrada.
3. updateUser: Dentro do contexto de chaves de acesso, o comando upd
ateUser permite que as chaves do usuário sejam atualizadas, para isso,
basta informar o ID do usuário e ambos os parâmetros userapikey e use
rsecretkey
Para gerar as chaves pela UI, é preciso editar o usuário para o qual deseja-se
gerá-las. Siga os passos descritos em Editar um user e clique no botão na parte
superior direita conforme a imagem ??.
Figura 47: Gerar chaves de acesso para um usuário
fig:generate-keys
Após clicar no botão será apresentada uma janela solicitando a confirmação
da ação.
Figura 48: Mensagem de confirmação para gerar chaves de acesso
57
Basta confirmar para que o par de chaves seja gerado e registrado para esse
usuário.
2.2.4.8. Uso das chaves de API no CloudMonkey
Para utilizar as chaves de acesso no CloudMonkey é possível defini-las atuali-
zando diretamente no arquivo de configuração
3
. Basta preencher os parâme-
tros apikey e secre tkey adequadamente no arquivo e salvá-lo. A próxima vez
que o CloudMonkey iniciar, ele irá utilizar as chaves configuradas.
asyncblock = true
timeout = 1800
output = json
verifycert = true
profile = mylab
[mylab]
url = http://my-local-lab/client/api
domain = /
apikey = IsBXfV_Km9sgbc3zYsf6fiia2z19qCnB80S7quN2lSy0SvD97A
secretkey = crmgT-n820MGl8EYZ37yRvnjDjfQyV8FWHBb5EmFxN5JiqZg1ZHRk6vsNw
Outra forma de utilizar as chaves usando o CloudMonkey é configurar ma-
nualmente os parâmetros. Para isso, abra o CloudMonkey e execute os coman-
dos a seguir:
(mylab) > set username your-username
(mylab) > set domain your-domain
(mylab) > set apikey YOUR-API-KEY
(mylab) > set url https://your-lab/client/api
(mylab) > set secretkey YOUR-SECRET-KEY
Após finalizar esses passos execute um comando de syn c para verificar se
as alterações surtiram o efeito desejado.
(mylab) > sync
Discovered 623 APIs
2.2.4.9. Autenticação de dois fatores
O CloudStack tem suporte à autenticação de dois fatores (2FA), na qual o se-
gundo fator utilizado pode ser o Google Authenticator, qualquer autenticador
com suporte ao algoritmo TOTP ou um PIN estático.
3
Este arquivo normalmente fica na pasta home/.cmk/config ou em
home/snap/cloudmonkey/current/.cmk/config dependendo da forma como foi instalado.
58
Esta camada extra de segurança pode ser configurada para um domínio ou
globalmente pelo administrador através das seguintes configurações:
Configuração Descrição Valor
Padrão
enable.user.2fa Determina se a autenticação de
dois fatores está hablitada.
false
mandate.user.2fa Determina se a autenticação de
dois fatores é obrigatória aos
usuários.
false
user.2fa.default.provider Provedor padrão de autenticação
de dois fatores.
totp
Ao ativar a autenticação de dois fatores, os usuários podem configurar o
2FA acessando seus perfis.
Figura 49: Configurando a autenticação de dois fatores.
No pop-up, o usuário deve selecionar um dos provedores e realizar a res-
pectiva configuração.
Figura 50: Opções de provedores de autenticação de dois fatores.
59
Ao escolher o Google Authenticator ou algum outro autenticador com su-
porte ao algoritmo TOTP, é necessário configurar a conta no respectivo aplica-
tivo escaneando o código QR ou utilizando a chave de configuração fornecida
pelo CloudStack. Após a configuração, o usuário deve fornecer o código gerado
pelo aplicativo para realizar o login.
Figura 51: Configurando a autenticação de dois fatores com TOTP.
Figura 52: Verificação com TOTP durante o login.
60
Ao escolher static PIN, o usuário deve fornecer durante o login o código ge-
rado pelo CloudStack no setup do 2FA.
Figura 53: Configurando a autenticação de dois fatores com static PIN.
Figura 54: Verificação com static PIN durante o login.
O usuário pode desativar o 2FA a qualquer momento em seu perfil
4
.
4
Caso a configuração mandate.user.2fa seja tr ue, o usuário deverá reconfigurar a autenti-
cação no próximo login.
61
Figura 55: Desativando a autenticação de dois fatores.
Além disso, o administrador também pode tornar a autenticação de dois
fatores obrigatória através da configuração mandate.user.2fa. Assim, os usuá-
rios deverão configurar a autenticação no próximo login.
Figura 56: Configurando a autenticação de dois fatores no login.
Caso seja necessário tornar o 2FA obrigatório para apenas um usuário, é
possível utilizar a API updateUser:
(mylab) > update user id=<id_do_usuario> mandate2fa=true
Caso um usuário perca o aplicativo de autenticação ou esqueça o PIN, ele
deverá contatar o administrador do sistema para desabilitar a autenticação de
dois fatores. Ela pode ser desativada acessando o perfil do usuário e selecio-
nando a opção Disable User Two Factor Authentication como explicado anterior-
mente.
62
Caso o próprio administrador perca o segundo fator, ele pode chamar a API
setupUserTwoFactorAuthentication utilizando secretkey e apikey
5
:
(mylab) > setup usertwofactorauthentication userid=<id_do_usuario_administrador> enable=false
Caso o administrador não possua secretkey e apikey configuradas, é neces-
sário entrar em contato com o suporte para que a recuperação da conta seja
realizada.
2.2.4.10. Timezone
Ao criar um novo user, é necessário definir um timezone para o mesmo (vide
seção Adicionar um novo user). Esse parâmetro é responsável pelos horários
exibidos em diversas páginas da interface do Apache CloudStack, deixando as
informações de acordo com o fuso horário escolhido.
Figura 57: Exemplo de como o timezone afeta a interface do Apache CloudStack
É possível editar o timezone atual do user. Para isso, siga os passos em Editar
um user.
Figura 58: Editando o timezone do user
5
Ao utilizar secretkey e apikey, o 2FA é ignorado.
63
Por padrão, a interface do Apache CloudStack irá exibir os horários de acordo
com o fuso horário escolhido. Porém, existe a opção de mudar para o fuso ho-
rário local sem precisar editar o user. Para isso, basta ativar a opção "Use local
timezone" conforme ilustra a imagem abaixo:
Figura 59: Ativando a funcionalidade de timezone local
2.2.5. Projects
Projects servem para organizar recursos e agrupar accounts e users. Por pa-
drão, tanto users administradores quanto regulares podem criar um projeto,
sendo o criador automaticamente o administrador do mesmo. É possível al-
terar esse comportamento através da configuração allow.use r.creat e.project
s:
Configuração Descrição Valor
Padrão
allow.user.create.projects Define se um usuário regular
pode criar um projeto.
true
2.2.5.1. Adição de project
Para criar um project:
64
Figura 60: Iniciando a criação de um novo project
Ao clicar no botão New Project, será aberto um formulário para preenchi-
mento das informações:
Figura 61: Criando o novo project
Projects possuem limites para alocação de recursos:
65
Figura 62: Limites de recursos de um project
Esses limites são herdados das configurações globais:
Configuração Descrição Valor
Padrão
max.project.cpus Número máximo de CPU cores
que o projeto pode usar.
40
max.project.memory Número máximo de memória
(em MiB) que o projeto pode
usar.
40960
max.project.networks Número máximo de redes que
pode ser criado para o projeto.
20
max.project.primary.storage Número máximo de primary sto-
rage (em GiB) que o projeto pode
usar.
200
max.project.public.ips Número máximo de IPs que o
projeto pode consumir.
20
max.project.secondary.storage Número máximo de secondary
storage (em GiB) que o projeto
pode usar.
400
66
Configuração Descrição Valor
Padrão
max.project.snapshots Número máximo de snapshots
que pode ser criado para o pro-
jeto.
20
max.project.templates Número máximo de templates
que pode ser criado para o pro-
jeto.
20
max.project.user.vms Número máximo de VMs de
usuário que podem ser feitas
deploy para o projeto.
20
max.project.volumes Número máximo de volumes que
pode ser criado para o projeto.
20
max.project.vpcs Número máximo de VPCs que
pode ser criado para o projeto.
20
Porém, eles podem ser alterados em cada project:
Figura 63: Alterando os limites de recursos de um project
Projects também possuem roles, as quais estão acima das roles de uma ac-
67
count. Caso uma account seja adicionada ao project sem uma role, a role da
account entrará em vigor.
Figura 64: Iniciando a criação de uma project role
Figura 65: Criando uma project role
Figura 66: Definindo as regras da project role
68
2.2.5.2. Adição de accounts e users ao project
Para adicionar accounts e users no project, basta preencher o formulário e en-
viar o convite:
Figura 67: Iniciando a adição de membros no project
Figura 68: Adicionando uma account no project
69
Figura 69: Adicionando um user no project
Ao finalizar a adição, a account ou o user farão parte do project, no entanto é
possível alterar esse comportamento para que seja necessário eles confirma-
rem o convite, através de um e-mail, antes de participarem efetivamente. Para
isso, existem as seguintes configurações:
Configuração Descrição Valor
Padrão
project.invite.required Define se a account ou o user ne-
cessitam aceitar o convite para o
projeto.
false
project.invite.timeout Tempo (em segundos) de expira-
ção do convite.
86400
Para que seja possível enviar os e-mails de confirmação, é necessário confi-
gurar o serviço de envio de e-mails para projects:
70
Configuração Descrição Valor
Padrão
project.email.sender Endereço que estará no header
From do e-mail de confirmação.
null
project.smtp.enabledSecurity
Protocols
Protocolos de segurança para
envio de e-mail, separado por
espaços. Protocolos suporta-
dos: SSLv2Hello; SSLv3; TLSv1;
TLSv1.1; TLSv1.2; TLSv1.3.
project.smtp.host Endereço do servidor SMTP para
envio de e-mails.
null
project.smtp.password Senha para autenticação no ser-
vidor SMTP (apenas se a confi-
guração project.smtp.useAuth es-
tiver como true).
null/false
project.smtp.port Porta que o servidor SMTP está
ouvindo.
465
project.smtp.useAuth Define se utilizará autenticação
para envio de e-mails.
null
project.smtp.username Usuário para autenticação no
servidor SMTP (apenas se a con-
figuração project.smtp.useAuth
estiver como true)
null
project.smtp.useStartTLS Define se utilizará StartTLS
para proteger a conexão (ape-
nas se a configuração pro-
ject.smtp.useAuth estiver como
true).
false
Uma account ou um user podem estar em diversos projetos simultanea-
mente. Para que seja possível consumir e visualizar os recursos do projeto,
é necessário alterar a visualização:
71
Figura 70: Selecionando a view
Além das funcionalidades citadas, também é possível:
2.2.5.3. Edição de project
• Editar:
Figura 71: Iniciando a edição do project
72
Figura 72: Editando o project
2.2.5.4. Suspensão de project
• Suspender:
Figura 73: Iniciando a suspensão do project
Figura 74: Suspendendo o project
73
2.2.6. Observações e considerações
Há situações onde um usuário possui um domain com diversas accounts,
com roles distintas, que necessitarão compartilhar recursos. De acordo com a
arquitetura utilizada pelo CloudStack, há duas alternativas para que seja pos-
sível compartilhar recursos entre diferentes accounts:
• Através de projects, onde serão adicionadas as accounts e users que com-
partilharão os recursos. É possível também criar diferentes project roles,
limitando o acesso aos recursos compartilhados de cada um.
• Criando uma role para accounts, baseada no tipo DomainAdmin. Essa role
trabalhará no mesmo nível da DomainAdmin padrão, no entanto será pos-
sível limitar o acesso da role DomainAdmin criada através das regras de
acesso.
É importante notar que um projeto apenas pode conter accounts do mesmo
domain onde o projeto foi criado. Não sendo possível accounts de diferentes
domains serem adicionadas a um mesmo projeto.
2.3. Gerência de VMs
É possível realizar as seguintes ações com VMs:
2.3.1. Adição de VM
Figura 77: Adicionando uma VM
Para adicionar uma VM, é necessário especificar algumas configurações, as
quais variam de acordo com o tipo de conta do usuário. É preciso atentar-se
75
também na existência de componentes que supram os requisitos de hardware
dessa VM, tanto em questão de CPU e RAM, quanto em questão de redes.
Para a implantação de uma VM baseada em uma ISO, o Apache CloudStack
utilizará o data disk para fazer o boot do OS. Com isso, o data disk será alterado
para root disk posteriormente. Sendo assim, apenas com a VM criada será
possível alocar um data disk de fato, uma vez que o volume inicial se tornará
o root disk para que a implementação do sistema operacional da VM ocorra.
76
2.3.1.1. Adição de VM como root admin
77
Figura 78: Criação de uma VM com uma conta de usuário do tipo root admin
78
2.3.1.2. Adição de VM como admin
79
Figura 79: Criação de uma VM como admin
80
2.3.1.3. Adição de VM como user
81
Figura 80: Criação de uma VM como user
2.3.1.4. Criação de VM com inicialização UEFI
A UEFI (Unified Extensible Firmware Interface) permite ultrapassar as limitações
impostas pela BIOS. Uma diferença entre as duas formas de inicialização é que
UEFI armazena todos os dados sobre a inicialização em um arquivo .efi e não
no firmware. Abaixo se encontram algumas vantagens da UEFI em relação a
BIOS:
• Suporta tamanhos de unidade de até 9 zetabytes (Bios até 2,2 terabytes);
• Possui tempo de inicialização menor;
• Oferece segurança com “Secure Boot”, o que evita que a máquina faça boot
a partir de aplicações não autorizadas;
• Roda em 32 ou 64 bits (o que permite a navegação com o mouse), en-
quanto a BIOS utiliza 16 bits (navegação pelo teclado)
82
O Libvirt convencionalmente utiliza o BIOS como firmware padrão para a
inicialização de VMs guests. Para que o mesmo inicialize VMs com UEFI, é ne-
cessário instalar os pacotes ovmf no host onde serão implantadas as VMs, que
estão disponíveis na maioria dos repositórios Linux. Verifique a existência do
pacote no host com o seguinte comando: dpkg -s ovmf. Caso o pacote não
exista, siga:
• 1. Para os sistemas baseados em Debian execute:
sudo apt install ovmf
• 2. Para sistemas baseados em RHEL, é necessário instalar o pacote edk2
-ovmf usando os seguintes comandos:
sudo dnf install edk2-ovmf
ou
sudo yum install edk2-ovmf
• 3. Já para sistemas baseados em Arch Linux:
sudo pacman -S edk2-ovmf
Para o segundo passo é necessário que se empregue na VM um template que
suporte a inicialização UEFI.
Para a implementação da VM, certifique-se de que o Cloudstack considera
apenas os hosts habilitados para UEFI, conforme registrado no banco de dados,
para alocação. Configure a máquina virtual conforme necessário, ajustando as
definições XML no caso de uso do KVM, para garantir a compatibilidade com
UEFI.
83
Figura 81: Visualização das opções de inicialização
Figura 82: Opções de inicialização no formulário de deploy de uma VM
Durante a criação de VMs, é possível observar os detalhes das configurações
finais da VM antes de criá-la:
84
Figura 83: Configuração final da VM
85
2.3.2. Remoção de VM
É possível realizar a remoção de uma VM através do CloudMonkey ou atra-
vés da UI. Ao realizar tal procedimento, deve-se atentar ao parâmetro expun
ge. Por padrão, ele possui o valor false, o que permite a recuperação da VM
excluída por parte do administrador. Caso ele receba o valor true, a VM é com-
pletamente removida e não poderá ser recuperada posteriormente.
Através da API, é possível usar o comando destroyVirtualMachine para colo-
car uma VM no estado Destroyed, marcando-a para exclusão definitiva após o
período definido pela configuração global expunge.delay. O CloudStack realiza
verificações de expurgação de acordo com o intervalo definido na configura-
ção global expunge.interval. A API pode ser auxiliada pelo parâmetro expung
e. Vale ressaltar que contas com roles do tipo Admin sempre poderão informar
tal parâmetro; contas que possuem outra role terão acesso apenas caso a con-
figuração allow.user.expunge.recover.vm (ao nível de conta) estiver como tru
e.
(localcloud) > destroy virtualmachine id=<id da VM escolhida> expunge=<False or True>
Existe também a API expungeVirtualMachine, que pode ser executado para
remover definitivamente VMs que se encontram nos estados de Destroyed, Ex
punging ou Error.
(localcloud) > expunge virtualmachine id=<id da VM escolhida>
Ambos os processos podem ser realizados via UI, como mostrado a seguir:
Figura 84: Escolhendo a VM que será destruída
86
Figura 85: Confirmando a destruição da VM
2.3.3. Parada e início de VM
Figura 86: Parando e iniciando uma VM
2.3.4. Reinício de VM
Para reiniciar uma VM, a mesma deve, obrigatoriamente, estar rodando.
Figura 87: Escolhendo a VM que será reiniciada
87
Figura 88: Reiniciando a VM
2.3.5. Acesso à VM via interface web
Atualmente, o ACS permite o acesso ao console de VM pelo navegador. Para
isso, existe um botão na UI que fornece este acesso em uma nova guia. Entre-
tanto, há um mecanismo que, por razões de segurança, restringe o acesso ao
console a um uso por vez. Assim, se o console estiver em uso, outro console da
mesma VM não pode ser aberto, apresentando a mensagem de erro: Failed to
connect to server / access token has expired. Para fins de compartilhamento
e/ou acesso posterior ao console de VM, existe um botão ao lado que copia a
URL do console diretamente para a área de transferência.
Figura 89: Botões de acesso e cópia de URL do console da VM
Via CloudMonkey, o acesso ao console da VM é possível através do uso da
API createConsoleEndpoint, onde o parâmetro que deve ser passado é o ID da
VM, e, como retorno, apresenta a URL de acesso ao console pelo navegador.
Para obter acesso à URL via CloudMonkey, deve-se executar o comando a
seguir:
$ create consoleendpoint virtualmachineid=<id-da-VM>
88
Figura 90: Resposta da API createConsoleEndpoint
2.3.6. Aumento de recursos computacionais da VM
Apesar da funcionalidade ser suportada pelos virtualizadores VMware, Xen-
Server e KVM, a presente seção irá demonstrar somente como preparar o am-
biente com o virtualizador KVM para viabilizar a alteração de recursos compu-
tacionais (RAM e CPU) com a VM em execução. No contexto do virtualizador
KVM, essa funcionalidade existe com algumas ressalvas:
• A VM deve estar configurada como dynamically scalable;
• A compute offering type da VM em questão precisa ser do tipo custom cons-
trained ou custom unconstrained;
• O sistema operacional da VM deve suportar dynamic scale dos recursos;
• Não é possível trocar a família de vGPU nem de CPU da VM com a mesma
em execução, já que os sistemas operacionais em geral não suportam
esse tipo de substituição com a VM rodando;
• Não é possível diminuir os recursos da VM, apenas aumentar;
É preciso que configuração global enable.dynamic.sca le.vm, cujo valor pa-
drão é false, seja true.
89
Para configurar as VMs desejadas, é necessário que elas estejam paradas.
As definições necessárias para o dynamic scalling no KVM apenas são informa-
das no Document Object Model (DOM) no deploy da VM. Assim, não é possível
alterar essas definições com a VM em execução.
VMs já existentes que estão paradas podem ser configuradas como dyna-
mically scalable:
Figura 91: Ativando dynamic scaling em uma VM
Também é possível configurar templates para que VMs criadas com eles se-
jam dynamically scalable desde o momento de sua criação:
90
Figura 92: Configurando dynamic scaling em um template
Finalmente, para aumentar os recursos computacionais de uma VM, basta
invocar o seguinte comando da API através do CloudMonkey:
scale virtualmachine id=<ID DA VM> serviceofferingid=<ID DA COMPUTE OFFERING>
details[0].memory=<NOVO VALOR DE MEMORIA> details[0].cpuNumber=<NOVO NUMERO
DE CPUS> details[0].cpuSpeed=<NOVA VELOCIDADE>
Por exemplo:
scale virtualmachine id=13661a05-6640-48d3-938f-2ba054356d0b
serviceofferingid=daa3225c-caa8-4a37-a534-cf53635aaaf9 details[0].memory=512
details[0].cpuNumber=2 details[0].cpuSpeed=1000
Alguns detalhes importantes na hora de executar o comando:
• Na API, os valores de memória (details[0].memory) e número de CPUs (d
etails[0].cpuNumber) são obrigatórios na API. Caso não se deseje alterar
a memória, basta informar o valor corrente e vice-versa;
• O valor de memória (details[0].memory) informado na API deve ser o valor
atual + algum número múltiplo de 128.
• No caso da VM possuir uma compute offering do tipo custom unconstrained,
o valor de velocidade de CPU (details[0].cpuSpeed) também é obrigatório;
Dependendo do sistema operacional usado na VM, pode ser necessário ativar
91
as CPUs ou a RAM para que elas comecem a serem utilizadas. No Ubuntu, é
possível ativar a CPU da seguinte maneira:
1. Torne-se usuário root:
sudo su
2. Ative a CPU com o seguinte comando, mudando o número da CPU para
o desejado:
echo 1 > /sys/devices/system/cpu/cpu<NUMERO DA CPU>/online
3. Repita para as outras CPUs a serem ativadas.
No CentOS e no RHEL o seguinte procedimento é utilizado para ativar RAM:
1. Use este comando para checar se existe RAM desativada:
grep line /sys/devices/system/memory/*/state
2. Caso exista RAM desativada, ative-a com o comando;
echo online >/sys/devices/system/memory/memory[number]/state
Caso o usuário prefira, é possível aumentar os recursos computacionais da
VM via UI do CloudStack também, conforme explicado na seção 2.18.2.4 (Alte-
ração de compute offering da VM).
2.3.7. Atribuição de VM a outra account
Por meio de usuários root admin ou domain admin é possível atribuir uma
VM de uma account para outra. Usuários root admin poderão atribuir VMs
para accounts em qualquer domain, já usuários domain admin poderão apenas
atribuir VMs a accounts do mesmo domain e seus subdomains.
Para exemplificar, considere a seguinte estrutura de domínios:
ROOT
-> domain1
-> subdomain1
-> subdomain2
-> domain2
-> subdomain1
92
Um usuário domain admin do domain1 poderá reatribuir VMs de/para ac-
counts nos domains R OOT/domain1, ROOT/domain1/ subdomain1 e ROOT/ do
main1/subdomain2. No entanto, não poderá reatribuir VMs de/para accounts
no domain ROOT/domain2 e seus subdomains.
Além disso, este processo possui alguns pontos importantes:
• A VM precisa estar parada;
• A VM não pode ter snapshots;
• A account para a qual a VM está sendo migrada precisa ter acesso às re-
des que a VM utiliza. Neste sentido, é importante considerar que não é
possível migrar uma network entre accounts;
• Caso o NIC padrão esteja conectado a uma rede isolada, e a nova account
possua mais de uma rede isolada, será necessário especificar a rede;
• Os IPs da VM não podem ter regras de Port Forwarding/Load Balancing ou
serem Static Nat.
Figura 93: Escolhendo a VM que terá sua account migrada
93
Figura 94: Migrando account da VM
Também é possível fazer este processo usando o CloudMonkey, descrito na
seção 3, através do seguinte comando:
(localcloud) > assign virtualmachine virtualmachineid=<vm-id> domainid=<domain-id>
account=<account-name>
2.3.8. Adição de user-data na VM
O user-data é um script que executa no boot da VM, podendo ser adicionado
durante a criação da VM e também após, atualizando a definição da mesma.
Sua atribuição pode ser feita de duas formas, pelo CloudMonkey e pela UI.
Pelo CloudMonkey, o script deve ser atribuído em formato de codificação
base64 (devido ao desenho do CloudMonkey, o base64 pode ter até 2KB de
tamanho), com o parâmetro userdata= e o script codificado em seguida.
Exemplo de atribuição de user-data via CloudMonkey:
(localcloud) > deploy/update virtualmachine [...] userdata=IyEvYmluL2Jhc2gKCmVjaG8gInVzZXJkYXR
hIHRlc3QgLSAkKGRhdGUpIiA+IC90bXAvdXNlcmRhdGE=
Script acima decodificado:
#!/bin/bash
echo "userdata test - $(date)" > /tmp/userdata
Note que [...] foi usado apenas para melhor visualização do parâmetro user-
data, excluindo os outros parâmetros obrigatórios.
94
A API updateVirtualMachine utilizada no exemplo acima, além de alterar as
configurações de boot, também pode ser usada para alterar outras configura-
ções, como os valores de memória, número de CPUs e a velocidade da CPU.
Assim, para evitar que outras configurações possam ser alteradas pelos usuá-
rios finais, é necessário adicionar alguns valores na configuração global user.v
m.denied.details.
Esses valores são os nomes das configurações separados por vírgula. Por
exemplo, para bloquear o usuário de alterar as configurações de memória e
CPU, a configuração deverá ter o seguinte valor: cpuNumber, cpuSpeed, mem
ory. É importante ressaltar que essa configuração tem como valor padrão: ro
otdisksize, cpuOvercommitRat i o , memor y O v e r c o m m it R a t i o , Mess a g e . Re s e r v e
dCapacityFreed.Flag.
Pela UI, o user-data pode ser adicionado no campo de texto disponível, onde
a codificação não é necessária, pois o próprio CloudStack codifica ao enviar o
script para o back-end, e o limite aplicado é de 1048576 caracteres (1MB de
tamanho).
Figura 95: Adicionando user-data na criação da VM
95
Figura 96: Alterando user-data na edição da VM
Com o user-data adicionado, pode-se verificar sua funcionalidade como mos-
tra o screenshot a seguir:
Figura 97: Verificando funcionalidade do user-data
2.3.9. Configurações da VM
Para editar as configurações de uma VM, é necessário primeiramente parar
a mesma. Em seguida, as configurações da VM podem ser modificadas aces-
sando a aba Settings.
96
Figura 98: Aba de configurações da VM
2.3.9.1. Configurações gerais
Configuração Descrição.
keyboard Define o layout do teclado da VM.
cpu.corespersocket Define o número de núcleos de CPU por soquete.
nicAdapter Define o adaptador de rede virtual usado pela VM.
2.3.9.2. Configurações para VM com compute offering personalizada
Configuração Descrição
cpuNumber Número de núcleos de CPU atribuídos à VM.
cpuSpeed Velocidade do clock do processador atribuída à VM.
memory Quantidade de memória RAM atribuída à VM.
97
2.3.9.3. Configurações diversas para uso interno
Configuração Descrição
deployvm Ação para implantar uma nova VM.
SSH.PublicKey Chave pública SSH usada para autenticar o acesso à
VM.
password Senha usada para autenticar o acesso à VM.
Encrypted.Password Senha criptografada usada para autenticar o acesso à
VM.
configDriveLocation O local onde a unidade de configuração da VM será
montada.
2.3.9.4. Configurações para importação de VM com NIC, disco e parâmetros
personalizados para compute offering personalizada
Configuração Descrição
nic Adaptador de rede virtual usado pela VM.
network Rede virtual usada pela VM.
ip4Address Endereço IPv4 atribuído à VM.
ip6Address Endereço IPv6 atribuído à VM.
disk Disco virtual usado pela VM.
diskOffering Oferta de disco virtual usada pela VM.
configurationId ID de configuração usada para implantar uma VM existente
em uma nova máquina host.
2.3.9.5. Adicionar configurações da VM via API
Nem todas as configurações de VMs estão acessíveis por meio da UI. Contudo,
é possível efetuar modificações e adições por meio da API updateVirtualMachi
ne, como mostrado a seguir:
update virtualmachine id=<ID-da-VM> details[0].<propriedade1>=<valor1>
details[0].<propriedade2>=<valor2> <demais parametros>
Ao executar o comando updateVirtualMachine para atualizar as configura-
ções da VM, apenas as configurações passadas através do comando serão atri-
buídas à VM. As configurações existentes serão removidas caso não estejam
presentes no mesmo.
(admin) > update virtualmachine id=565f5741-315e-47ea-816b-3f4d98b49553
details[0].keyboard=us details[0].cpu.corespersocket=1
98
details[0].Message.ReservedCapacityFreed.Flag=true details[0].video.hardware=vga
details[0].io.policy=threads details[0].iothreads=enabled
É possível inserir configurações com um nome incorreto ou inexistente, mas
tais configurações não afetam o funcionamento da VM, pois são ignoradas. No
entanto, elas permanecem visíveis na aba de configurações da VM.
2.4. Gerência de volumes
Existem dois tipos de volumes que são utilizados pelas VMs:
• Root Disk: O disco que abriga o "núcleo" ou a "base" do sistema operaci-
onal de uma máquina virtual é conhecido como "root disk". Em sistemas
operacionais do tipo Unix, essa partição é geralmente designada como "/".
Cada máquina virtual contém um único root disk, não sendo possível que
VM contenha dois ou mais discos desse tipo.
• Data Disk: Refere-se a uma unidade de disco de dados que expande a ca-
pacidade de armazenamento disponível para uma máquina virtual. Uma
VM pode conter diversos data disks anexados; contudo, o número má-
ximo varia por hypervisor.
A diferença entre os dois tipos é a posição deles na VM. Um volume que está
marcado como Root Disk pode tornar-se um Data disk e vice-versa.
Além dos diferentes tipos de volumes, os mesmos podem se encontrar nos
seguintes estados:
• Ready: Volumes neste estado já existem no primary storage, podendo es-
tar tanto desvinculados e prontos para serem direcionados a uma VM,
quanto já sendo utilizados por uma VM, sendo possível verificar a por-
centagem de utilização de sua capacidade.
• Allocated: Representa que o volume ainda não existe fisicamente, porém
os metadados do volume já estão armazenados no CloudStack.
99
• Uploaded: Ao fazer o upload do volume, ele fica armazenado no secon-
dary storage. Ele apenas será copiado para o primary storage quando for
vinculado a uma VM. Neste estado, o volume pode somente ser anexado
a uma VM como um DATADISK
6
.
• Migrating: Estado transicional que indica que o volume está migrando
entre storages.
• Destr oy: O volume neste estado ainda pode ser recuperado ou deletado
definitivamente; neste estado o volume não pode ser vinculado a uma
VM.
• Expunging: Estado transicional que indica que o volume já passou do es-
tado Destroy, mas ainda está em processo de exclusão permanente.
Discos gerados por um hypervisor, como o KVM, não são compatíveis com
outros hypervisors devido à criação e ao reconhecimento de formatos de disco
específicos por parte de cada um deles.
2.4.1. Operações em data e root disks
Nesta subseção são apresentadas algumas operações em root e data disks.
A seção 2.18.1 possui mais detalhes quanto às operações com root disks.
6
Para maiores informações, consulte a seção 2.4.1.6
100
2.4.1.1. Vizualização de discos e volumes
Figura 99: Visualizar todos os volumes
2.4.1.2. Criação de volume
Figura 100: Criar novo volume
101
Figura 101: Configurar novo volume
Figura 102: Verificando novo volume
Todos os volumes criados serão do tipo Data Disks.
2.4.1.3. Upload de volume local
Figura 103: Upload de volume local
102
Figura 104: Realizar upload
Para realizar o upload de um volume, a disk offering 2.18.1 deve ser do tipo
custom disk, visto que, durante o upload, o tamanho do disco é desconhecido.
2.4.1.4. Upload de volume local usando cURL
Utilizando CloudMonkey e cURL via terminal, também é possível realizar upload
de volumes locais. Para isso, deve-se reproduzir os seguintes passos:
103
1. No CloudMonkey, utilize o seguinte comando
7
para obter os parâmetros
que serão utilizados para o próximo passo:
get uploadparamsforvolume format=<Formato_do-volume> name=<nome> zoneid=<UUID_da_zona>
Um exemplo de saída do comando:
{
"getuploadparams": {
"expires": "2022-02-07T15:43:12.591Z",
"id": "41af6492-8695-4b08-b04b-170edfd4f092",
"metadata": "XsUP46nagJgEdN0ZVLHEBMFxJysHre6RtCtGh7+/4/nrK3LvslGsct44QcjIH0sheCig
N9NTn/MElyuv8uxx3V8cA1pc/3KFFZAv9Ycn3XWXBKdUQsKfYe3h/NLnzPv4klpPU35o4h8qjTi+BTTPT
hotakSWWVZybe0gcYKXZGVOHeZOLqL3PMsGC+TumrSFcvW79smfytdMAebNG2nhekVmf8Lwbqdhn0G9Cl
0Szv4NAl4ZIJValMBz+qL84Z/GDEw/V1Nq1EYVqQpoyftlA9ZkhPiitLGeQgJ7UzyHaoMG3vCu0EQgBDe
IgyoJdVRpkw23BR35WTvK2HSIijjOkm/fQJJbMzwBAdLRN1wW+4bPhzLQfc+Jf/ruVk1BDEA3RRDQLp5o
VDfqveV/fj6fpnkjUmyJJ3trDlitb5i/ZnqPGt+2VeJu/UJzNUtDorV/9KVUVf7SEHTL9B154ds1RNAiK
CLM3mfo",
"postURL": "https://172.16.200.99/upload/41af6492-8695-4b08-b04b-170edfd4f092",
"signature": "A8ElmOHx3gAC5xA43b0Kwa97qac="
}
}
2. Via terminal, utilize o comando curl para realizar o upload do volume:
curl -X POST "<postURL>" -H "X-signature:<signature>" -H "X-metadata:<metadata>" \
-H "X-expires:<expires>" -H "Expect:" \
-F "file=@<caminho_do_arquivo_a_ser_feito_upload>" -v --insecure
É importante notar que o header Expect deve estar vazio, caso contrário o
cURL esperará por um sinal da SSVM para fazer o upload, ocasionando em um
timeout, já que a SSVM não implementa esta função.
A operação de geração de um template utilizando um volume está descrita
na página 185.
7
São apenas apresentados os parâmetros obrigatórios. Existem outros que permitem con-
trolar melhor como o volume será criado. Por exemplo, o parâmetro account permite designar
o volume a uma conta (neste caso, o domainid também deve ser informado).
104
2.4.1.5. Upload de volume on-line via URL
Figura 105: Fazendo upload de volume
Figura 106: Configurando o upload de volume
105
2.4.1.6. Adição de volume a uma VM
Figura 107: Acessando os detalhes do volume
Figura 108: Adicionando o volume à VM
106
Figura 109: Configurando a VM que receberá o novo volume
2.4.1.7. Remoção de volume de uma VM
Figura 110: Removendo o volume da VM
Figura 111: Confirmando a ação
2.4.1.8. Remoção e adição de volume ROOT
Via CLI, é possível fazer tanto a remoção quanto a adição de volumes ROOT,
desde que a VM esteja parada. Para fazer a remoção do volume, utilize o se-
guinte comando:
107
detach volume id=<id_do_volume>
Já para fazer adição do volume como ROOT, use o seguinte comando, defi-
nindo o deviceid dele como 0:
attach volume id=<id_do_volume> virtualmachineid=<id_da_VM> deviceid=0
O deviceid define qual a posição do volume na lista de devices. O volume
ROOT sempre tem a posição 0. Caso queira adicionar um volume que não seja
ROOT, pode-se omitir o parâmetro ou escolher um outro número. A quantidade
máxima de volumes que são suportados depende do hypervisor adotado:
Hypervisor Número de volumes
KVM 32
VMWare 13
XenServer 6
2.4.1.9. Redimensionamento de volume data disk
Essa opção só é disponível para volumes criados pelo usuário, não estando
disponível para os que foram criados via upload.
Figura 112: Redimensionar o volume
108
Figura 113: Configurar redimensionamento
2.4.1.10. Download de volume
É importante notar que o download de volumes ROOT é possível somente se a
VM estiver parada.
Figura 114: Fazer download do volume
Figura 115: Confirmar download
109
2.4.1.11. Snapshots recorrentes
Automatiza o processo de criação de snapshot de um volume. Na seção 2.15,
podem ser encontradas mais informações sobre as funcionalidades e utilida-
des de snapshots.
Figura 116: Adicionando automatização de snapshots para um volume
Figura 117: Configurando a automatização das snapshots
110
2.4.1.12. Deleção de volume
Figura 118: Removendo o volume
Figura 119: Confirmar a ação
2.5. Redes guest
Redes guest são responsáveis pela comunicação interna das VMs, seja entre
si mesmas ou com seus respectivos gateways. Uma rede guest pode ser ou não
utilizada por um VPC, além de suportar operações de IPs públicos. As opera-
ções possíveis são:
111
2.5.1. Operações com redes guest
2.5.1.1. Adicionar rede guest
Figura 120: Navegando até a rede guest
2.5.1.2. Tipos de redes
Existem 3 tipos diferentes de redes que podem ser criadas, a saber:
• Isolated:
É uma rede isolada que permite apenas a comunicação entre as VMs que
a utilizam, não sendo possível a comunicação com VMs que rodam em
outra rede isolada. As operações referentes ao uso de IPs públicos se
aplicam a esse tipo de rede também.
112
Figura 121: Rede isolada
Figura 122: Rede isolada criada
• L2:
Permite que os serviços de rede sejam fornecidos e gerenciados por equi-
pamentos externos ao CloudStack. Como resultado, o virtual router não é
113
necessário e as VMs implantadas nesse tipo de rede obterão seus ende-
reços IP e outros serviços a partir destes equipamentos externos.
Figura 123: Criando uma rede L2
Figura 124: Rede L2 criada
• Shared:
No momento em que essa seção foi escrita (ACS versão 4.16), as redes
desse tipo são criadas apenas por administradores root da nuvem. Além
disso, redes desse tipo não podem ser atualizadas com relação ao inter-
valo de IP previamente configurado, sendo possível atualizar apenas o
name e displayname.
114
Uma rede compartilhada executa um serviço DHCP único e estático, for-
necendo um intervalo IPv4 público com endereços IP para atribuir às ins-
tâncias. Máquinas virtuais criadas com essa oferta receberão um IPv4
público, tornando-as disponíveis diretamente para a Internet. Durante a
criação, o escopo da rede pode ser:
– Account: Visível para todos os usuários de uma determinada conta;
– Domain: A rede estará disponível para todas as contas desse domí-
nio e seus usuários. Usando essa configuração, pode-se optar por
torná-la visível aos subdomínios também, ou seja, todos os usuários
de subdomínios dentro do domínio onde foi definida a rede terão
acesso à mesma;
– Project: Embora esteja visível na UI, atualmente não é possível criar
uma rede compartilhada por projeto;
– All: Todos os usuários da nuvem têm acesso à rede criada ao definí-la
nesse escopo.
115
116
Figura 125: Rede shared
Figura 126: Rede shared criada
117
2.5.1.3. Acesso aos detalhes de uma rede guest
Figura 127: Acessando os detalhes de uma rede guest
2.5.1.4. Exclusão de rede
Navegue até os detalhes da rede que deseja excluir.
Figura 128: Excluindo uma rede
Figura 129: Confirmando a exclusão da rede
118
Só é possível excluir uma rede caso não existam VMs a utilizando. Do con-
trário, será necessário excluir essas VMs ou alterar suas redes.
2.5.1.5. Edição de rede
Figura 130: Editando uma rede
2.5.1.6. Reinicialização de rede
Essa opção só existe para redes do tipo isolated e shared.
Figura 131: Reiniciando uma rede
2.5.1.7. Egress rules
Para que a rede guest consiga se comunicar com o exterior, é preciso que suas
egress rules estejam configuradas.
119
Figura 132: Configurando as egress rules
• Source CIDR: Faixa de endereços da rede local a receber permissão de
acesso.
• Destination CIDR: Faixa de endereços externos à rede local que poderão
ser acessados.
• Protocol: TCP, UDP, ICMP ou todos
• Start port e End port: Primeira e última das portas a serem acessadas.
2.5.2. Network permissions
Ao criar uma rede isolada ou L2 no ACS, a rede estará visível somente para a
conta dona da rede. No entanto, é possível permitir que outras contas dentro
do mesmo domínio tenham acesso à rede por meio das network permissions.
Para demonstração, foram criados um domínio chamado client, duas con-
tas, client e client-users, e uma rede client-network.
• Ao acessar a aba Guest networks com a conta client-users, nenhuma rede
aparecerá.
Para permitir que a conta tenha acesso à essa rede, será necessário criar uma
nova network permission na rede client-network e adicionar a conta client-user
s.
120
• Acesse o menu Guest networks, selecione a rede e clique em Add ne t w o
rk permissions
Figura 133: Acessando a rede client-network.
• Em seguida, adicione uma conta na network permission
121
Figura 134: Adicionando uma conta em Add network permission.
• Após ter adicionado a conta, a rede estará visível.
122
Figura 135: Após adição da network permission.
As network permissions também permitem o compartilhamento de redes en-
tre contas de um mesmo projeto. Basta criar uma network permission e adicio-
nar o projeto desejado.
2.6. IPs públicos
As possíveis operações utilizando IPs públicos podem ser acessadas ao en-
trar nos detalhes do IP público desejado:
123
Figura 136: Acessando o IP público
Figura 137: Vendo os detalhes do IP público
2.6.1. Operações com IPS públicos
2.6.1.1. Configuração de firewall
Um IP público vinculado a uma rede guest pode ter o firewall configurado para
receber comunicações.
124
Figura 138: Configurando o firewall
• Source CIDR: Faixa de endereços externos à rede local a receber permissão
de acesso.
• Protocol: TCP, UDP ou ICMP
• Start port e End port: Primeira e última das portas a serem abertas para a
faixa de endereços do source CIDR.
2.6.1.2. Habilitação de static NAT
Ao habilitar o Static NAT, é possível reservar o IP público para uma VM.
Figura 139: Habilitando static NAT
125
Figura 140: Configurando o IP
Figura 141: Verificando a configuração final
Com isso, a VM escolhida se torna visível e acessível na rede externa.
126
2.6.1.3. Habilitação de port forwarding
Ao habilitar o mapeamento de portas é possível alocar portas específicas para
o IP público que “redirecionam” o tráfego para uma outra porta de determinada
VM.
Figura 142: Acessando e configurando as portas da aba de port forwarding
Figura 143: Escolhendo a VM que terá a porta mapeada
127
Figura 144: Exemplo de configuração de port forwarding com várias VMs
A grande vantagem do uso de port forwarding é tornar várias VMs acessíveis
a rede externa através de apenas um único IP, além de permitir um controle
de quais portas da VM podem ser acessíveis na rede externa.
2.6.1.4. Habilitação de load balancing
Ao habilitar essa opção, é possível realizar a operação de balanceamento de
carga entre diversas VMs através de apenas um IP público e de acordo com as
regras definidas pelo usuário.
Figura 145: Acessando e configurando as portas do load balancing
128
Figura 146: Adicionando as VMs que serão gerenciadas pelo load balancer
Figura 147: Load balancer criado
Uma vez que o load balancer esteja criado, é possível adicionar regras mais
complexas ao mesmo.
É importante frisar que todas as operações aqui apresentadas podem ser
facilmente desfeitas simplesmente removendo as configurações adicionadas
ao IP público ou ainda removendo o próprio IP público.
129
Figura 148: Removendo o IP público
2.6.2. Aquisição de IP público
Para poder realizar as operações com os IPs públicos em uma rede, é ne-
cessário que seja alocado um IP público para essa rede. Por padrão, redes
gerenciadas pelo ACS possuem pelo menos um IP, chamado Source NAT, que
não pode ser removido.
Redes guest com conserve mode igual a false na sua network offering (seção
2.18.3) e tiers de uma VPC não suportam mais de um serviço no mesmo IP
público. Só podem ter uma função dentre Source Nat, Static Nat, Port Forwarding
e Load Balancing.
Dessa forma, o procedimento para adquirir um novo IP público em uma
rede é:
1. Navegar até a rede desejada:
Figura 149: Acessando os detalhes da rede
2. Navegar até a aba de IPs públicos:
130
Figura 150: Acesse os IPs públicos da rede
3. Adquirir um novo IP público para a rede:
Figura 151: Adquirir um novo IP
Figura 152: Lista de IPs disponíveis
131
Figura 153: Novo IP adquirido
Aqui é importante frisar que os IPs públicos disponíveis dependem de três
fatores:
(a) Faixa de IPs públicos alocada durante a criação da Zona no ACS;
(b) Quantidade de IPs públicos ainda disponíveis
8
.
(c) E se a account que está tentando alocar novos IPs públicos possui
uma faixa de IPs dedicados, além de a configuração global use.syste
m.public.ips estar como true.
2.7. Virtual Private Cloud (VPC)
Uma VPC é uma rede composta por múltiplas sub-redes isoladas, camadas
9
,
todas conectadas e gerenciadas através do mesmo roteador virtual. Ao utilizar
uma VPC, é possível estabelecer para a mesma uma topologia de rede virtual
própria, que simula uma rede física real.
Além disso, uma única VPC pode ser usada para gerenciar diversas redes
isoladas, podendo ser utilizada para incrementar a segurança da nuvem.
As operações possíveis usando VPCs e seus componentes são:
8
Não foram alocados para outras redes.
9
Também chamadas de tiers.
132
2.7.1. Operações com a VPC
2.7.1.1. Adição de VPC
Figura 154: Criando uma nova VPC
Figura 155: Configurando a nova VPC
133
Figura 156: Verificando se a VPC foi corretamente criada
Nesse ponto, é importante ressaltar alguns aspectos:
• CIDR: define o intervalo possível de IPs que essa rede virtual terá. Tiers
alocados dentro dessa rede deverão estar dentro desse intervalo. Além
disso, uma VPC não é acessível fora da zona na qual foi criada.
• VPC Offering: As opções disponíveis são:
– Default VPC Offering:
Suporta os serviços: VPN, DNS, Static Nat, Network ACL, User Data,
Source Nat, Lb,Port Forwarding, DHCP. Cria um virtual router, mas não
o torna redundante.
– Default VPC Offering with Netscaler:
Realiza o mesmo que o Default VPC Offering, porém, por utilizar Nets-
caler, acrescenta a possibilidade de realizar balanceamento de carga.
– Redundant VPC Offering:
Realiza o mesmo que o Default VPC Offering, porém cria um virtual
router redundante.
Por padrão, ao criar uma VPC, o Apache CloudStack cria automaticamente um
virtual router.
134
2.7.1.2. Reinicialização de VPC
É possível reiniciar a VPC, seja para aplicar alguma mudança mais complexa ou
para tentar solucionar algum problema. Ao realizar essa operação, é impor-
tante lembrar que VMs que utilizam tal VPC irão ficar sem conexão durante o
tempo de reinicialização.
Figura 157: Reiniciando uma VPC
Figura 158: Opções de reinicialização de uma VPC
Sendo as opções possíveis:
• Clean up: irá tentar limpar elementos antigos da rede, caso houver.
• Make redundant: irá criar e iniciar um segundo virtual router em um dos
hosts da estrutura, preferencialmente um que seja diferente do que já
possui o primeiro virtual router. Essa opção só irá aparecer caso a VPC
não seja redundante.
135
2.7.1.3. Remoção de VPC
Ao remover uma VPC, é necessário remover os tiers que fazem parte dela. Os
virtual routers, entretanto, serão automaticamente deletados.
Figura 159: Removendo uma VPC
Figura 160: Confirmando a ação
Figura 161: Erro que ocorre ao tentar deletar uma VPC
Uma descrição detalhada de como remover os tiers de uma VPC pode ser
encontrada na página 140. Uma vez que os tiers dessa VPC estejam devida-
mente removidos, basta repetir o processo.
2.7.1.4. Aquisição de IP público para uma VPC
Os passos para adquirir um IP público são:
136
Figura 162: Acessando a VPC
Figura 163: Acessando os IPs públicos da VPC
Figura 164: Escolhendo um IP público
137
Esses passos apenas alocam um IP público para a VPC, mas não o relacio-
nam com nenhuma VM. As possíveis operações com IPs públicos são descritas
na seção 2.6.
2.7.2. Tiers
Um tier funciona como uma rede isolada dentro da VPC.
2.7.2.1. Adição de tiers à VPC
Figura 165: Acessando a VPC criada
Figura 166: Verificando os detalhes da VPC
138
Figura 167: Adicionando um novo tier
Figura 168: Criando um novo tier
É importante ressaltar que não é possível ter dois tiers com o mesmo CIDR na
mesma VPC.
139
Após adicionado um tier à VPC, é possível selecioná-lo durante a criação de
uma VM para adicioná-la à rede isolada do tier.
2.7.2.2. Remoção de tiers da VPC:
Figura 169: Navegando até os tiers
Figura 170: Removendo um tier
Figura 171: Confirmando a remoção do tier
140
Caso exista alguma VM que utilize esse tier, um erro ocorrerá, sendo necessário
parar e remover
10
todas as VMs que utilizam esse tier
11
e repetir o processo de
remoção do mesmo.
2.7.3. Network ACL
Uma ACL (ou Network ACL/ACL list) é um conjunto de regras que permitem
ou bloqueiam o tráfego que passa pelos tiers. Estas regras podem ser utilizadas
para liberar ou restringir a comunicação entre a Internet e os tiers e entre os
próprios tiers.
Essencialmente, a ACL funciona como uma junção das egress rules de uma
rede guest com o firewall de um IP público, mas é destinada aos tiers. Cada tier
possui apenas uma ACL, mas uma ACL pode ser utilizada por vários tiers.
Por padrão, o CloudStack possui duas opções de ACLs que não podem ser
alteradas: defaul t_allow, a qual libera todo o tráfego de entrada e de saída, e
default_deny, a qual bloqueia todo o tráfego. Para adicionar um conjunto de
regras personalizadas, deve-se criar uma ACL:
Figura 172: Adicionando uma nova ACL
10
Ou alterar a rede usada pela VM.
11
Esse processo é descrito na página 86.
141
Figura 173: Criando uma nova ACL
Figura 174: Navegando até a ACL criada
Figura 175: Navegando até a criação de uma nova regra na ACL
Para adicionar uma regra à ACL, é preciso preencher os seguintes campos:
• #Rule:
Número da regra. As regras são avaliadas do menor para o maior nú-
mero. Se deixado em branco, ele será definido automaticamente (auto-
incrementado).
142
• CIDR list:
Define o intervalo possível de IPs em que esta regra será aplicada.
• Action:
Define se a regra é de permissão ou restrição.
• Protocol:
As opções disponíveis são: TCP, UDP, ICMP, All e Protocol Number. Isso
permite uma alta flexibilização em relação a criação das regras.
• Traffic Type:
Define o tipo de tráfego, se é de entrada ou saída.
• Description:
Descrição da regra.
A seguir, é demonstrado um exemplo de criação de regra para o funciona-
mento do comando SSH:
Figura 176: Adicionando regra que permite o tráfego de entrada da porta 22 do protocolo TCP
(SSH)
143
Figura 177: Adicionando regra que permite o tráfego de saída da porta 22 do protocolo TCP
(SSH)
Assim, ao criar um novo tier naquela VPC, é possível utilizar nele a ACL
recém-criada.
No momento de escrita deste documento, ao criar uma ACL pela UI do
CloudStack, ela só poderá ser utilizada por tiers que pertencem à VPC na qual
foi criada. No entanto, por meio da API createNetworkACLList, ao não informar
o parâmetro vpcId, também é possível às contas root admin criar ACLs globais
que, da mesma forma que as ACLs default _allow e def ault_deny, estarão dis-
poníveis para uso em todas as VPCs. Exemplo:
create networkacllist name=<nome_da_acl>
2.7.4. Domain VPC
Domain VPC é um recurso que permite que a VPC seja gerenciada por uma
conta e que os tiers de uma mesma VPC possam ser criados para diferentes
contas, possibilitando assim o compartilhamento de recursos.
Com a utilização da Domain VPC, diversas contas podem usar a mesma VPC
144
e consumir apenas um VR; cada tier continuará sendo isolado via broadcast
domain.
Para utilizar esta funcionalidade, basta selecionar uma conta para ser dona
do tier na criação do mesmo:
Figura 178: Seleção da conta dona do tier
Para que a criação do tier seja possível, a conta criando o tier e a conta dona
da VPC devem ter acesso à conta para qual o tier será criado. A conta criando
o tier também deve ter acesso à conta dona da VPC.
2.7.4.1. Alocação de IPs públicos em domain VPCs
Caso seja necessário alocar um IP público para ser utilizado em uma domain
VPC, o IP público deve ser adquirido à conta dona da tier que irá utilizá-lo, e não
à conta dona da domain VPC. Se ele for adquirido à conta dona da domain VPC,
somente a conta dona da domain VPC poderá utilizá-lo; as contas que possuem
145
tiers na VPC não. A seleção da conta é feita no formulário de aquisição de IP
público.
Figura 179: Seleção da conta no formulário de aquisição de IP público
2.8. Virtual Private Network (VPN)
2.8.1. Tipos de VPN
O CloudStack possibilita a criação de VPNs para que usuários acessem suas
VMs, sendo possível criar dois tipos de VPNs:
• C2S (Client-to-Site) VPNs: Permite ao usuário a criação de uma conexão se-
gura com a VPC, possibilitando a ele se conectar em suas VMs sem a ne-
cessidade de atribuir IPs públicos para as mesmas. O CloudStack utiliza o
protocolo IPSec para realizar as conexões. Ele realiza uma única conexão
por vez entre dois IPs públicos, portanto, nesse tipo de VPN, somente um
usuário por vez conseguirá se conectar com a VPC quando estes estive-
rem utilizando o mesmo IP público.
• S2S (Site-to-Site) VPNs: Permite ao usuário a criação de uma conexão se-
gura entre um datacenter e a VPC, por exemplo, conectar a rede de um
escritório na cloud.
146
2.8.2. Operações com VPN
2.8.2.1. Criação de VPN
• Para criar uma VPN, primeiramente é necessário ter uma VPC (seção 2.7)
com uma offering (seção 2.18.4) que suporte o serviço de VPN. Caso ela já
exista, basta selecioná-la:
Figura 180: Selecionando a VPC
• Nos detalhes da VPC existirão diversas abas, no entanto a relacionada à
User VPN é a Public IP Addresses. As demais abas, Private Gateway, VPN
Gateway e VPN Connection, estão relacionadas à S2S VPN.
Figura 181: Detalhes da VPC
147
• As informações sobre as VPNs estarão no Public IP marcado como source-
NAT.
• Para configurar a VPN, deve-se navegar até a aba VPN do Public IP:
Figura 182: Detalhes do public IP
• Nessa aba existirá um botão (Enable Remote Access VPN) para habilitar a
VPN para aquela VPC:
Figura 183: Habilitando a VPN
Para habilitar a VPN, é necessário que as seguintes portas do protocolo
UDP estejam abertas:
1. 500 (IKE)
148
2. 1701 (L2TP)
3. 4500 (NAT-T)
• Então, o CloudStack irá habilitar a VPN para a VPC e gerar uma pre-shared
key para ser utilizada na conexão com IPSec, como no exemplo abaixo:
– VPN gateway: 192.168.100.52
– IPSec pre-shared key: kuNbGHMBvODUxztzUXtyDz7q
Figura 184: VPN habilitada
• O tamanho da IPSec pre-shared key pode ser alterado através das confi-
gurações globais:
Nome Descrição Valor pa-
drão
remote.access.vpn.psk.length Tamanho da chave IPSec
compartilhada (min: 8, max:
256)
24
2.8.2.2. Desabilitação de VPN para a VPC
Após habilitada, é possível desabilitar a VPN para a VPC:
149
Figura 185: Desabilitar a VPN
2.8.2.3. Gerência de usuários
Para gerenciar os usuários basta navegar até os VPN users:
Figura 186: Gerenciar usuários da VPN
2.8.2.4. Adição de usuário
Para adicionar um usuário à VPN, clique no botão Add VPN user e preencha
as informações no formulário:
Figura 187: Iniciando adição de usuário à VPN
150
Figura 188: Adicionando usuário à VPN
2.8.2.5. Definição da quantidade máxima de usuário da VPN por conta
É possível configurar a quantidade máxima de usuários da VPN que cada
account pode ter através das configurações globais:
Nome Descrição Valor pa-
drão
remote.access.vpn.user.limit Máximo de usuários da VPN
por account
8
2.8.2.6. Exclusão de usuário
Após criado, o usuário não poderá ser editado, apenas excluído:
Figura 189: Excluíndo usuário da VPN
151
Após configurar a VPN e adicionar o usuário, a conexão poderá ser esta-
belecida.
2.8.2.7. Conexão à VPN pelo Linux
Nas configurações de rede, deve ser adicionada uma nova VPN:
Figura 190: Iniciando a adição de uma VPN no Linux
O protocolo utilizado pelo CloudStack é o L2TP.
No formulário deverão ser informados o gateway da VPN, o usuário e a se-
nha cadastrados.
Figura 191: Adicionando uma VPN no Linux
Deve ser informada a IPSec pre-shared key:
152
Figura 192: Informando a IPSec pre-shared key
Figura 193: Informando a IPSec pre-shared key
Também deve ser desabilitado o protocolo EAP, pois o CloudStack não o
suporta:
Figura 194: Desabilitando o protocolo EAP
153
Figura 195: Desabilitando o protocolo EAP
Após adicionar a VPN, a conexão poderá ser estabelecida.
2.8.2.8. Conexão à VPN pelo Windows
Em configurações de rede e internet, vá até a aba VPN e adicione uma conexão
VPN:
Figura 196: Adicionando uma VPN no Windows
154
O seguinte formulário será aberto:
Figura 197: Iniciando a adição de uma VPN no Windows
Configurações importantes:
• Nome ou endereço do servidor: insira o gateway da VPN.
• Tipo de VPN: selecione a opção L2TP/IPSec com chave pré-compartilhada.
• Chave pré-compartilhada: informe a IPSec pre-shared key.
Figura 198: Finalizando a adição de uma VPN no Windows
155
No campo Tipo de informações de entrada, selecione a opção Nome de
usuário e senha e, em seguida, preencha os campos com o usuário e a senha
cadastrados anteriormente.
Após adicionar a VPN, é necessário realizar algumas configurações:
1. Vá até Network connections e abra as propriedades do adaptador da VPN.
2. Options → Properties → PPP settings → assinalar todas as opções.
Figura 199: Alterando configurações do PPP
3. Security → Allow these protocols → Microsoft CHAP Version 2 .
156
Figura 200: Habilitando o protocolo MS-CHAP v2
4. Networking → Desabilitar IPv6.
Figura 201: Desabilitando IPv6
5. Botão direito IPv4 → Properties → Advanced → Ip Settings →
Desabilitar "Use default gateway on remote network".
157
Figura 202: Desabilitando o uso de gateway padrão na rede remota
Por fim, estabeleça a conexão com a VPN.
2.8.3. S2S (Site-to-Site) VPNs
Para configurar uma conexão VPN S2S, primeiramente é necessário criar
um VPN customer gateway:
Figura 203: Navegando até a aba VPN customer gateway
O seguinte formulário de criação será aberto:
158
Figura 204: Criando um VPN customer gateway
Basta informar o gateway, o CIDR (separados por vírgula caso tenha mais
de um) e a IPsec preshared-key do cliente. Também é possível alterar algumas
configurações de segurança no restante dos campos se necessário.
Após criar um VPN customer gateway, é possível editá-lo:
159
Figura 205: Editando um VPN customer gateway
E, se o VPN customer gateway não fizer parte de nenhuma conexão, também
é possível removê-lo:
Figura 206: Deletando um VPN customer gateway
O próximo passo é criar um VPN gateway para a VPC que fará parte da cone-
xão VPN S2S. Nos detalhes da VPC, navegue até a aba VPN gateway e procure
pelo botão Create site-to-site VPN gateway:
Figura 207: Navegando até VPN gateway nos detalhes da VPC
Ao clicar no botão, o CloudStack disponibilizará um endereço IP que será o
160
VPN gateway da VPC.
Figura 208: Criando um VPN gateway
Por último, deve-se criar uma conexão VPN S2S na VPC. Ainda nos detalhes
da VPC, vá até a aba VPN connection e procure pelo botão Create site-to-site VPN
connection:
Figura 209: Navegando até VPN connection nos detalhes da VPC
O seguinte formulário será aberto:
161
Figura 210: Criando uma conexão VPN S2S
Informe o VPN customer gateway e, caso a conexão seja entre duas VPCs,
marque a opção Passive na VPC que não iniciará a conexão.
Depois de criada a conexão, é possível reiniciá-la:
Figura 211: Reiniciando uma conexão VPN S2S
E também é possível removê-la:
Figura 212: Removendo uma conexão VPN S2S
162
2.9. Assinatura de requisições HTTP
A API do CloudStack requer um processo de assinatura ao enviar requisi-
ções HTTP, com o objetivo de autenticar o operador e autorizá-lo de forma
apropriada. Para que isso seja possível, o ACS permite a emissão de api keys e
secret keys, que serão usadas no corpo da request durante o procedimento.
• Emissão de keys via UI
163
Figura 213: Gerando keys.
• Emissão de keys via CloudMonkey
register userkeys id=<id do usuário> filter=<filtro desejado>
• Consulta de keys via CloudMonkey
164
get userkeys id=<id do usuário> filter=<filtro desejado>
As requests enviadas à API do CloudStack pode ser do tipo GET ou POST e
possuem o seguinte corpo:
• URL principal do CloudStack, por exemplo:
http://example.com:8080/client/api
• O comando que será executado, por exemplo: listUsers
• Parâmetros exigidos pelo comando
• A api key que será usada para identificar o usuário
• A assinatura(signature) que será usada para autenticar o usuário
• Exemplo de uma requisição
http://localhost:8080/client/api?
command=<comando>&
<parametro(s)>&
apiKey=<chave da api>&
signature=<assinatura>
Toda requisição terá o formato URL + Comando + Assi n atura; para gerar a
assinatura, siga os passos abaixo:
1. Separe cada campo da requisição com um & e aplique URL encode
2. Certifique-se de que a string dos comandos esteja inteiramente em letras
minúsculas, por exemplo:
apikey=mivr6x7u6bn_sdahobpjnejpgest35exq-jb8cg20yi3yaxxcgpyuairmfi_ejtvwz0nukkjbpmy3y2bcikwfq&
command=deployvirtualmachine&
diskofferingid=1&serviceofferingid=1&
templateid=2&zoneid=4
3. Após isso, é necessário calcular o hash da string de comandos usando o
algorítimo de hashing SHA-1 com a secret key do usuário;
4. Por último codifique a string resultante em Base64, o resultado final será
semelhante ao exemplo abaixo:
165
http://localhost:8080/client/api?
command=deployVirtualMachine&serviceOfferingId=1&
diskOfferingId=1&
templateId=2&
zoneId=4&
apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&
signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1
Para ilustrar o processo de assinatura de requisições na prática, abaixo é
apresentado um passo a passo de como realizar o procedimento:
1. Realize a importação dos módulos utilizados
>>> import urllib2
>>> import urllib
>>> import hashlib
>>> import hmac
>>> import base64
2. Especifique o endpoint do ACS, os comandos a serem executados e as
chaves do usuário:
>>> baseurl='http://localhost:8080/client/api?'
>>> request={}
>>> request['command']='listUsers'
>>> request['response']='json'
>>> request['apikey']=
'plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdM-kAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg'
>>> secretkey=
'VDaACYb0LV9eNjTetIOElcVQkvJck_J_QljX_FcHRj87ZKiy0z0ty0ZsYBkoXkY9b7eq1EhwJaw7FF3akA3KBQ'
3. Crie a string de requisição:
>>> request_str='&'.join(['='.join([k,urllib.quote_plus(request[k])]) for k in request.keys()])
4. Inicie o processo de encriptação da assinatura com HMAC, Base64 e URL
encoding:
>>> sig_str=
'&'.join(['='.join([k.lower(),urllib.quote_plus(request[k]).lower().replace('+','%20')])
for k in sorted(request.iterkeys())])
>>> sig_str
'apikey=
plgwjfzk4gys3momtvmjuvg-x-jlwlnfauj9gabbbf9edm-kaymmailqzzq1elzlyq_u38zcm0bewzgudp66mg&
command=listusers&
response=json'
>>> sig=hmac.new(secretkey,sig_str,hashlib.sha1)
>>> sig
<hmac.HMAC instance at 0x10d91d680>
>>> sig=hmac.new(secretkey,sig_str,hashlib.sha1).digest()
166
>>> sig
'M:]x0exafxfbx8fxf2yxf1px91x1ex89x8axa1x05xc4Axdb'
>>> sig=base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest())
>>> sig
'TTpdDq/7j/J58XCRHomKoQXEQds=n'
>>> sig=base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest()).strip()
>>> sig
'TTpdDq/7j/J58XCRHomKoQXEQds='
>>> sig=urllib.quote_plus(base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest())
.strip())
5. Por último monte a string e envie a requisição:
>>> req=baseurl+request_str+'&signature='+sig
>>> req
>>> 'http://localhost:8080/client/api?
apikey=plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdM-kAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg&
command=listUsers&
response=json&
signature=TTpdDq%2F7j%2FJ58XCRHomKoQXEQds%3D'
>>> res=urllib2.urlopen(req)
>>> res.read()
'{ "listusersresponse" :
{ "count":3 ,"user" :
[
{"id":"7ed6d5da-93b2-4545-a502-23d20b48ef2a",
"username":"admin",
"firstname":"admin",
"lastname":"cloud",
"created":"2012-07-05T12:18:27-0700",
"state":"enabled",
"account":"admin",
"accounttype":1,
"domainid":"8a111e58-e155-4482-93ce-84efff3c7c77",
"domain":"ROOT",
"apikey":
"plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdM-kAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg",
"secretkey":
"VDaACYb0LV9eNjTetIOElcVQkvJck_J_QljX_FcHRj87ZKiy0z0ty0ZsYBkoXkY9b7eq1EhwJaw7FF3akA3KBQ",
"accountid":"7548ac03-af1d-4c1c-9064-2f3e2c0eda0d"},
{"id":"1fea6418-5576-4989-a21e-4790787bbee3",
"username":"runseb",
"firstname":"foobar",
"lastname":"goa",
"email":"joe@smith.com",
"created":"2013-04-10T16:52:06-0700",
"state":"enabled",
"account":"admin",
"accounttype":1,
"domainid":"8a111e58-e155-4482-93ce-84efff3c7c77",
"domain":"ROOT",
"apikey":
"Xhsb3MewjJQaXXMszRcLvQI9_NPy_UcbDj1QXikkVbDC9MDSPwWdtZ1bUY1H7JBEYTtDDLY3yuchCeW778GkBA",
"secretkey":
"gIsgmi8C5YwxMHjX5o51pSe0kqs6JnKriw0jJBLceY5bgnfzKjL4aM6ctJX-i1ddQIHJLbLJDK9MRzsKk6xZ_w",
"accountid":"7548ac03-af1d-4c1c-9064-2f3e2c0eda0d"},
{"id":"52f65396-183c-4473-883f-a37e7bb93967",
"username":"toto",
"firstname":"john",
"lastname":"smith",
"email":"john@smith.com",
167
"created":"2013-04-23T04:27:22-0700",
"state":"enabled",
"account":"admin",
"accounttype":1,
"domainid":"8a111e58-e155-4482-93ce-84efff3c7c77",
"domain":"ROOT",
"apikey":
"THaA6fFWS_OmvU8od201omxFC8yKNL_Hc5ZCS77LFCJsRzSx48JyZucbUul6XYbEg-ZyXMl_wuEpECzK-wKnow",
"secretkey":
"O5ywpqJorAsEBKR_5jEvrtGHfWL1Y_j1E4Z_iCr8OKCYcsPIOdVcfzjJQ8YqK0a5EzSpoRrjOFiLsG0hQrYnDA",
"accountid":"7548ac03-af1d-4c1c-9064-2f3e2c0eda0d"} ] } }'
É importante mencionar que também é possível definir um tempo de ex-
piração para as chamadas da API. O servidor irá monitorar a faixa de tempo
especificada e em seguida rejeitará todas as requests enviadas após a expira-
ção. Para habilitar essa feature é necessário adicionar os seguintes parâmetros
à requisição:
Parâmetro Valor Descrição
signatureVersion 3 Se esse parâmetro não
for igual a 3 ou estiver va-
zio ele será ignorado na
request.
expires YYYY-MM-DDThh:mm:ssZ(ISO 8601) Especifica a data em que
a assinatura presente na
request irá expirar.
Exemplo de uso:
• expires=2011-10-10T12:00:00+0530
• Exemplo de uma requisição com expiração:
http://<IPAddress>:8080/client/api?
command=listZones&
signatureVersion=3&
expires=2011-10-10T12:00:00+0530&
apiKey=
miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&
signature=
Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
168
2.10. Templates e ISOs
Templates são imagens reutilizáveis que servem como modelo ou padrão
para a criação de VMs. Intrinsecamente, um template é uma imagem de um
disco virtual que contém de configurações básicas, como o sistema operaci-
onal, os usuários e as senhas padrões, até configurações avançadas, como
softwares previamente instalados e configurados. Vale ressaltar que os tem-
plates são dependentes do hypervisor que será utilizado.
No momento de criação do template o usuário irá definir se o mesmo será
público ou privado. Quando selecionado public, o template ficará disponível
para todos os usuários que consigam acessar a zona onde o template foi arma-
zenado. O novo template ficará visível no menu Templates quando o processo
de criação do template for concluído, isto é, quando o ACS terminar o download
e a preparação do mesmo. O template fica então disponível ao criar uma nova
VM.
ISO refere-se a uma imagem de disco óptico, como um CD, DVD ou Blu-ray.
É um arquivo que contém uma cópia exata, ou imagem, de todo o conteúdo
de um disco óptico. Essas imagens são frequentemente usadas para distribuir
grandes programas e sistemas operacionais, permitindo que o usuário grave a
imagem em um disco físico ou a monte como um disco virtual em seu sistema
para acessar o conteúdo sem a necessidade de um disco físico.
Assim como os templates, as ISOs podem ser públicas ou privadas. Um
ponto importante é que as ISOs não dependem de hypervisors específicos, isto
é, pode-se montar a mesma imagem utilizando hypervisor distintos, diferente-
mente dos templates. VMs criadas com esse recurso precisam ser configuradas
desde a instalação.
Semelhantes aos templates, as ISOs podem ser armazenadas, e disponibili-
zadas com certo nível de privacidade. No momento de registro o usuário irá
classificar a imagem como inicializável ou não inicializável. Sendo a inicializável
a que contém um sistema operacional.
169
2.10.1. Operações com templates/ISOs
O Apache CloudStack oferece diversas opções de operações com templates
e ISOs, sendo possível:
2.10.1.1. Vizualização
Figura 214: Visualizando templates e ISOs
• Template:
170
Figura 215: Acessando os detalhes do template
Figura 216: Detalhes do template
• ISO:
171
Figura 217: Acessando os detalhes da ISO
Figura 218: Detalhes da ISO
2.10.1.2. Listagem
Por padrão a interface gráfica envia o filtro all (lista todos os elementos regis-
trados no ambiente) quando uma conta do tipo root admin ou domain admin
172
envia a requisição, quando trata-se de uma conta do tipo user a requisição é
enviada com o filtro self (que lista as ISOs e templates que foram registradas
pelo usuário). Esses filtros podem ser alterados clicando no campo de texto ao
lado do botão refresh.
Estão disponíveis para consulta os seguintes filtros:
• featured: Retorna os elementos que foram marcados como destaque;
• self : Retorna os elementos registrados pelo usuário que enviou a requi-
sição;
• selfexecutable: Idem ao filtro anterior, porém retorna apenas aqueles
que podem ser usados para instanciar novas VMs;
• sharedexecutable: Retorna os elementos que foram criados por outros
usuários, cuja permissão foi concedida para o usuário que enviou a requi-
sição;
• executable: Retorna os elementos que pertencem ao usuário que enviou
a requisição, bem como os elementos marcados como público e que po-
dem ser usados para instanciar novas VMs;
• community: Retorna os elementos marcados como público e que não
foram marcados como destaque;
• all: Retorna todos os elementos do ambiente (pode ser usado apenas por
administradores)
173
Figura 219: Filtros para listagem de ISOs e templates.
2.10.1.3. Resgitro
• Template:
Figura 220: Registrando o template
174
Figura 221: Configurando o template
– Direct download: se selecionado, o template será baixado diretamente
no primary storage na primeira vez que uma VM for criada. Após, ele
ficará armazenado no primary storage como cache e só será remo-
vido quando todas as VMs que o utilizam forem destruídas. Assim,
somente será feito um novo download em caso de remoção de todas
as VMs que usam o template.
Templates marcados com essa opção possuirão o estado Bypassed
175
Secondary Storage, indicando que foram baixados diretamente para
o primary storage e que nunca estarão armazenados no secondary
storage.
• ISO:
Figura 222: Registrando a ISO
Figura 223: Configurando a ISO
É necessário indicar qual o tipo de sistema operacional do template/ISO, pois
essa informação será utilizada pelo hypervisor. Caso o sistema operacional es-
176
colhido for diferente do template/ISO, algumas inconsistências podem surgir
durante a criação de VMs.
2.10.1.4. Upload
• Template:
Figura 224: Fazendo upload do template
177
Figura 225: Configurando o template
• ISO:
Figura 226: Fazendo upload da ISO
178
Figura 227: Configurando a ISO
2.10.1.5. Edição
Navegue até os detalhes do template/ISO.
• Template:
Figura 228: Editando detalhes do template
179
Figura 229: Editando o template
• ISO:
Figura 230: Editando detalhes da ISO
180
Figura 231: Editando a ISO
2.10.1.6. Edição de permissões de template/ISO
Mudanças nas permissões dos templates/ISOs podem ser realizadas via UI e
API. Via API, utiliza-se o comando updateTemplatePermissions ou updateIsoP
ermissions, sendo possível remover, adicionar e redefinir todas a permissões
dos templates/ISOs.
• Template:
Figura 232: Editando as permissões do template
• ISO:
181
Figura 233: Editando as permissões da ISO
Figura 234: Editando permissões
As opções de editação de permissões são as mesmas para templates e ISOs.
Sendo as possíveis operações:
• Add:
Usada para adicionar o template/ISO para determinada account ou pro-
jeto.
• Remove:
Usada para remover o template/ISO de determinada account ou projeto.
• Reset:
Reiniciar todas as permissões do template/ISO para o padrão.
2.10.1.7. Edição de compartilhamento do template
Navegue até os detalhes do template/ISO.
182
• Template:
Figura 235: Editando compartilhamento do template
• ISO:
Figura 236: Editando compartilhamento da ISO
Figura 237: Editando opções de compartilhamento
A configuração global allow.user.view.all.domain.accounts, que possui valor
padrão false, faz com que os usuários regulares não vejam a lista de contas
existentes no domínio do qual ele faz parte, isso o obriga saber especificamente
o nome da conta destino ao qual ele estará compartilhando o template/ISO.
É apresentado ao usuário um campo que faz a requisição do nome da conta
destino.
183
As opções de editação de compartilhamento são as mesmas para templates
e ISOs.
2.10.1.8. Remoção de template/ISO
Templates/ISOs podem ser excluídos, mas existem algumas ressalvas. O com-
portamento padrão do CloudStack é recusar a exclusão do template/ISO quando
existem VMs o utilizando.
Após a exclusão de templates/ISOs, as instâncias de VMs (pertencentes à
zona) que utilizam a imagem não serão afetadas, isto é, continuarão em exe-
cução. No entanto, o template/ISO excluído não poderá ser utilizado em novas
instâncias.
• Template:
Figura 238: Deletando o template
• ISO:
184
Figura 239: Deletando a ISO
2.10.1.9. Criação de template baseado em uma VM existente
Para criar um template baseado em uma VM existente, ela precisa estar no
estado Stopped:
Figura 240: Navegando até as VMs
185
Figura 241: Indo até o volume da VM
Figura 242: Criando o template
186
Figura 243: Configurando o template
2.11. Resource Tags
Tags, ou resource tags, são pares no formato key:value que guardam meta-
dados sobre algum recurso para categorizá-lo.
É bastante útil para filtrar listas e utilizar em relatórios do CloudStack Usage
(como em regras de ativação do Quota, seção 4) de forma personalizada.
Para adicionar ou remover tags:
• Via UI:
187
Figura 244: Resource tags de um componente qualquer
• Via CloudMonkey: Pode-se utilizar as chamadas de API listTags, createTa
gs e deleteT a g s. No deleteTags, pode-se omitir os parâmetros tags [0] se
for desejada a remoção de todas as tags.
Um host, um storage pool ou uma offering também podem possuir resource
tags (que não devem ser confundidas com host tags ou storage tags.
2.12. Affinity Groups
Affinity groups é uma funcionalidade que permite ao usuário definir quais
VMs devem rodar, ou não, no mesmo host. Estes grupos podem ser utilizados,
por exemplo, para garantir uma conexão e uma baixa latência entre VMs ao
agrupar todas no mesmo host ou para aumentar a tolerância a falhas de um
sistema ao especificar que VMs que oferecem um mesmo serviço não devem
rodar no mesmo host, possibilitando assim que, caso algum host apresente
uma falha, as VMs que estão em outros hosts continuem rodando e oferecendo
o serviço normalmente.
Os affinity groups não devem ser confundidos com os Instance Groups: estes
últimos servem apenas para o usuário organizar as VMs, agrupando-as, e não
influenciam em quais hosts as VMs irão rodar.
2.12.1. Tipos de affinity groups
Existem quatro tipos de affinity groups a partir da versão 4.18 do Cloud-
Stack
12
:
12
Em versões anteriores à 4.18, existem somente os tipos host affinity e host anti-affinity, que
equivalem aos tipos host affinity (strict) e host anti-affinity (strict).
188
• Host affinity (strict): especifica que as VMs devem sempre rodar no mesmo
host. No entanto, se o host não possuir capacidade suficiente para rodar
todas as VMs do grupo, ocorrerá um erro na criação de novas instâncias.
• Host anti-affinity (strict): especifica que as VMs devem sempre rodar em
hosts diferentes. De maneira semelhante, se não existirem hosts suficien-
tes para todas as VMs, ocorrerá um erro na criação de novas instâncias.
• Host affinity (non-strict): especifica que as VMs devem rodar no mesmo
host sempre que possível. Se o host não possuir capacidade, novas ins-
tâncias serão criadas em algum outro host.
• Host anti-affinity (non-strict): especifica que as VMs devem rodar em
hosts diferentes sempre que possível. Se não há hosts suficientes, novas
instâncias serão criadas em um host que já tem outras instâncias.
2.12.2. Operações com affinity groups
2.12.2.1. Adição de affinity group
Figura 245: Navegando até os affinity groups
189
Figura 246: Criando um affinity group
Figura 247: Affinity group criado
2.12.2.2. Adição de VM ao affinity group
A VM deve estar parada para que a opção de mover ao affinity group apareça.
Figura 248: Acessando a VM que será movida ao grupo
190
Figura 249: Movendo a VM para um affinity group
Figura 250: Selecionando o grupo
2.12.2.3. Visualização de VMs no affinity group
Figura 251: Acessando o grupo
191
Figura 252: Visualizando as VMs no grupo
Figura 253: Lista de VMs no grupo
192
2.12.2.4. Exclusão de affinity group
Figura 254: Excluindo o grupo
2.13. Autoscale VM groups
A funcionalidade de autoscale VM groups permite a criação de grupos de
VMs que automaticamente aumentam e reduzem em número conforme a de-
manda pelos recursos das VMs aumenta ou diminui. Esta funcionalidade pode
ser utilizada para, por exemplo, adicionar mais máquinas que oferecem um
serviço quando todas as existentes estiverem com um alto uso e removê-las
quando a demanda reduzir sem a necessidade da intervenção de um opera-
dor. Assim, ela possibilita um uso mais eficiente dos recursos de computação
e, consequentemente, a redução de custos.
Esta gerência automática de instâncias funciona através da criação de dois
conjuntos de regras: um que determina quando devem ser criadas novas VMs,
e outro que determina quando elas devem ser removidas. Por exemplo, pode-
se definir que serão adicionadas novas máquinas quando a média do uso de
CPU de todas as instâncias estiver acima de 70% e que elas serão removidas
193
quando a média estiver abaixo de 40%.
O CloudStack monitora as estatísticas de uso das instâncias fornecidas pelo
hypervisor
13
para realizar esta gestão. Além disso, ele usa um load balancer para
balancear o uso entre as VMs. Assim sendo, os grupos devem estar associados
à uma rede isolada ou à uma VPC com o serviço de load balancing ativado e
configurado.
2.13.1. Criação de um autoscale VM group
Antes de criar um autoscale VM group, é necessário criar uma rede isolada ou
uma VPC e configurar o serviço de load balancing. Abaixo, está exemplificada a
configuração de uma rede isolada:
1. Criar uma rede isolada:
13
Os hypervisors VMWare, XenServer e KVM suportam a funcionalidade de autoscale VM
groups.
194
Figura 255: Criando uma rede isolada
2. Acessar a aba Public IP addresses e adquirir um novo IP público para a
rede:
Figura 256: Acessando a aba de Public IP addresses
195
Figura 257: Adquirindo um novo IP público
3. No IP público, acessar a aba Load balancing e adicionar uma regra de load
balancing
14
:
Figura 258: Adicionando uma regra de load balancing
Com a rede isolada configurada, pode-se prosseguir ao menu de criação do
autoscale VM group:
1. Configurar as VMs do grupo por meio das configurações de zona, tem-
plate, compute offering e data disk.
14
A configuração AutoScale indica que a regra vai ser utilizada por um autoscale VMs group.
196
2. Selecionar a rede isolada criada:
Figura 259: Selecionando a rede isolada
3. Selecionar a regra de load balancing criada:
Figura 260: Selecionando a regra de load balancing
4. Configurar a scale-up policy:
A scale-up policy é um conjunto de regras que determina quando novas
máquinas devem ser adicionadas ao grupo. Ela possui as seguintes con-
figurações:
• Condition: regras que determinam quando adicionar mais VMs ao
grupo. Quando há mais de uma condition, todas devem ser verda-
deiras para acontecer o scale-up;
• Duration: tempo em segundos no qual as regras devem ser verdadei-
ras para serem adicionadas VMs;
197
• Quiet Time: após serem adicionadas VMs, tempo no qual a scale-up
policy não adicionará mais instâncias.
Cada condition possui os seguintes parâmetros:
• Counter: estatística das VMs do grupo a ser monitorada. Os counters
disponíveis são:
– VM CPU - average percentage: média de uso da CPU das VMs em
porcentagem (0 a 100);
– VM Memory - average percentage: média de uso da memória prin-
cipal das VMs em porcentagem (0 a 100);
– Public Network - mbps received per vm: média de dados sendo re-
cebidos pelas VMs em Mbps;
– Public Network - mbps transmit per vm: média de dados sendo
enviados pelas VMs em Mbps;
– Load Balancer - average connections per vm: média de conexões
por VM.
• Operator: operador utilizado para comparar os valores;
• Threshold: valor a ser comparado com o counter.
Figura 261: Configurando a scale-up policy
198
Na imagem, por exemplo, foi criada uma scale-up policy que adiciona no-
vas VMs quando a média do uso de CPU das atuais for maior que 10% por
30 segundos.
2.13.1.1. Configuração da scale-down policy
A scale-down policy segue o mesmo conceito que a scale-up policy, mas
determina quando VMs devem ser removidas.
Figura 262: Configurando a scale-down policy
Na imagem, foi definida uma scale-down policy que remove VMs quando
a média do uso de CPU for menor que 10% por 60 segundos.
2.13.1.2. Configuração dos detalhes do autoscale VM group
• As configurações são as seguintes:
– Name: nome do grupo;
– Expunge VM grace period: tempo em segundos a ser esperado
após um scale-down antes de remover as VMs. Este tempo é para
garantir que todas as sessões pendentes e transações sejam en-
cerradas.
– Max members: número máximo de VMs no grupo;
– Min members: número mínimo de VMs no grupo;
199
– Polling interval: intervalo em segundos no qual as conditions vão
ser conferidas.
Figura 263: Configurando os detalhes do autoscale VM group
2.13.1.3. Criação do grupo
Após a criação do grupo de autoscale VMs, as instâncias nele podem ser
visualizadas da seguinte forma:
Figura 264: Visualizando as instâncias do autoscale VM group
200
Figura 265: Instâncias do autoscale VM group
2.13.2. Teste de autoscaling
Com as instâncias criadas, é possível testar a funcionalidade de autoscaling.
Para forçar o aumento do uso da CPU e um scale-up, pode-se acessar as ins-
tâncias e executar o seguinte comando:
for i in 1 2 3 4; do while : ; do : ; done & done
Este comando irá criar quatro processos com loops infinitos. Cada loop gera
100% de uso de um núcleo da CPU.
Após alguns minutos, será realizado o scale-up e o grupo terá atingido o
número máximo de instâncias.
Figura 266: Instâncias do autoscale VM group após o scale-up
Para realizar o scale-down, pode-se finalizar os processos:
sudo killall -9 bash
Assim, após alguns minutos, o número de instâncias terá reduzido ao mí-
nimo.
201
Figura 267: Instâncias do autoscale VM group após o scale-down
2.13.3. Edição de autoscale VM group
Para editar um autoscale VM group, é necessário desativá-lo antes:
Figura 268: Desativando o autoscale VM group
Figura 269: Confirmando a ação
202
Enquanto o grupo estiver desativado, as VMs permanecerão rodando nor-
malmente. No entanto, não será realizado o scale-up, nem o scale-down do
grupo conforme a demanda.
Após desativado, é possível editar os detalhes do grupo, os parâmetros de
deploy das VMs e as scale-up e scale-down policies:
Figura 270: Editando os detalhes do grupo e parâmetros de deploy das VMs
Figura 271: Diálogo de edição dos detalhes do grupo e parâmetros de deploy das VMs
203
Figura 272: Editando a scale-up policy do grupo
Figura 273: Editando a scale-down policy do grupo
Após as edições, ative o grupo novamente:
204
Figura 274: Ativando o autoscale VM group
Figura 275: Confirmando a ação
2.13.4. Exclusão de autoscale VM group
Também é possível excluir o autoscale VM group:
Figura 276: Excluindo o autoscale VM group
205
Figura 277: Confirmando a ação
2.14. Kubernetes
O plugin Kubernetes Service adiciona a integração do Kubernetes ao Cloud-
Stack. Tal plugin vem desabilitado por padrão, e apenas usuários administrado-
res podem habilitá-lo através da configuração global cloud.kubernetes.service
.enabled. Ele permite que os usuários executem serviços em contêiner usando
clusters do Kubernetes.
Desde a versão 4.16 do ACS, o plugin Kubernetes Service usa o template de
system VM padrão para implantação dos clusters Kubernetes. Além disso, é utili-
zada uma ISO para instalação dos binários do Kubernetes nos nós do cluster de
forma que, para cada versão do Kubernetes que se deseje utilizar, é necessário
prover uma ISO específica para o CloudStack.
Para implantação e configuração do Kubernetes nos nós do cluster, o plugin
usa a ferramenta kubeadm do Kubernetes. O kubeadm é uma ferramenta de
linha de comando para provisionar facilmente um cluster Kubernetes em ser-
vidores físicos, em nuvem ou em máquinas virtuais. Por debaixo dos panos, os
nós de controle iniciam um cluster Kubernetes usando o comando kubeadm in
it com um token customizado e os nós workers ingressam nesse cluster Kuber-
netes usando o comando kubeadm join com o mesmo token. Mais informações
sobre o kubeadm podem ser encontradas na documentação oficial. Para rote-
amento do cluster o plugin Weave Net CNI é utilizado. Mais informações sobre
o Weave Net CNI pode ser encontradas na documentação oficial.
206
O plugin permite a criação de clusters Kubernetes usando a UI ou a API. Tanto
a UI quanto a API fornecem a capacidade de listar, excluir, dimensionar, atua-
lizar, parar e iniciar esses clusters.
2.14.1. Versões suportadas do Kubernetes
O ACS permite que o usuário mantenha diversas versões do Kubernetes,
para fazer upload de uma versão do Kubernetes, é necessária a criação de uma
ISO que possua certos arquivos dentro:
1. Arquivos binários do Kubernetes
2. Arquivos binários do CNI
3. Arquivos binários do CRICTL
4. Arquivos de configuração de rede do Weave
5. Arquivos de configuração do painel do Kubernetes
2.14.2. Adição de ISO Kubernetes ao Apache CloudStack
A comunidade disponibiliza algumas ISOs prontas. Os testes e exemplos
deste documento foram feitos com a ISO de versão 1.23.3. Porém, devido ao
rápido ciclo de releases de ISOs do Kubernetes, é recomendado o uso da versão
mais recente. É importante notar que operações sobre ISOs Kubernetes só
estão disponíveis para usuários root admin.
A matriz de compatibilidade entre as ISOs e o ACS se encontra abaixo:
K8s
ACS
4.18.0
< 1.23.3
1.24.0
1.25.0
1.26.*
1.27.*
1.28.4
207
A partir da versão 4.16, o Kubernetes começou a utilizar do template da
SystemVM (Debian) para o deploy dos clusters, e o usuário para SSH passou a
ser cloud.
Ao criar o cluster, o ACS permite nomes com letras maiúsculas, porém o Ku-
bernetes trabalha apenas com nomenclaturas em minúsculo. Sendo assim, ao
criar clusters Kubernetes é necessário informar o nome do cluster em minús-
culo. Caso contrário, ao tentar realizar operações que demandam comunica-
ção com o cloudstack, o Kubernetes não encontrará os nós do cluster.
Através da API addKubernetesSu pportedVersion é possível adicionar uma
ISO Kubernetes ao ACS.
add kubernetessupportedversion name=exemplo mincpunumber=2 minmemory=2048 semanticversion=1.23.3 \
url=<URL_de_download_da_ISO> zoneid=<ID_da_zona>
Também é possível fazer a mesma operação via UI, acessando a página Ku-
bernetes ISOs, no submenu imagens; clicando no botão “Adicionar versão Ku-
bernetes”, o formulário abaixo será aberto:
208
Figura 278: Formulário de adição de versão Kubernetes
2.14.3. Deleção de ISO Kubernetes
Através da API deleteKubernete sSupportedVersion é possível deletar uma
ISO Kubernetes do ACS.
delete kubernetessupportedversion id=<ID_da_ISO> filter=<opcional>
Também é possível fazer a mesma operação via UI, acessando a página Ku-
bernetes ISOs, no submenu Images; clicando na ISO a ser deletada; e clicando
no botão de delete.
209
Figura 279: Deletando ISO Kubernetes via UI
Figura 280: Confirmar exclusão da ISO Kubernetes
2.14.4. Clusters Kubernetes
Um cluster Kubernetes consiste em dois principais componentes: o nó de
controle e os nós de trabalho. O nó de controle é responsável por organizar
e configurar o funcionamento do cluster, podendo haver réplicas para garantir
robustez ao sistema. Nos nós de trabalho, rodam as aplicações. Os nós podem
ser VMs ou máquinas físicas, os quais contêm pods, a menor unidade de um
cluster Kubernetes. Eles funcionam como templates de criação para um tipo de
container.
O plugin Kubernetes Service fornece a funcionalidade de criar e gerenciar
clusters Kubernetes, facilitando implantações em contêineres sem a necessi-
210
dade de configurar o Kubernetes em cada nó de contêiner manualmente. O
serviço provisionará automaticamente o número desejado de máquinas virtu-
ais de acordo com o tamanho do cluster, usando os binários correspondentes à
versão fornecida do Kubernetes. Além disso, o serviço fornece a funcionalidade
para atualizar e dimensionar clusters. Esses, quando em execução, podem ser
atualizados para uma versão minor ou patch mais recente do Kubernetes por
vez, como também podem ser ampliados ou reduzidos.
2.14.4.1. Criando clusters Kubernetes
O plugin fornece a funcionalidade de criar clusters Kubernetes para redes com-
partilhadas ou isoladas no CloudStack.
A API createKubernetesCluster permite que seja criado um cluster Kuberne-
tes, o uso dela está ilustrado abaixo.
create KubernetesCluster name=exemplo description=exemplo zoneid=<ID_da_zona> \
kubernetesversionid=<ID_da_ISO_Kubernetes> serviceofferingid=<ID_da_compute_offering> \
size=<numero_de_nodos_trabalhadores>
A mesma operação também está disponível na UI, acessando a página Ku-
bernetes, no submenu Compute; clicando no botão Create Kubernetes cluster, o
formulário abaixo será aberto:
211
Figura 281: Formulário de criação de cluster Kubernetes
Existem alguns pontos que devem ser atentados ao criar clusters Kuberne-
tes:
• Atualmente só é possível ter um único cluster Kubernetes por rede.
• As Kubernetes ISOs, ao serem criadas, possuem um requisito mínimo de
recursos como CPU cores e memória alocada. Por isso, é necessário que
tenha uma compute offering que cumpra com todos esses requisitos.
• Ao criar um cluster Kubernetes, serão instanciadas, no mínimo, duas VMs
com a compute offering selecionada: uma para o nó de controle e outra
para um nó de trabalho. O número aumenta com base no tamanho do
cluster usado na criação. Por isso, vale se atentar de que o gasto com
212
recursos será maior do que os requisitos mínimos.
• Para poder acessar os nós via SSH é preciso informar um par de chaves
SSH na criação de clusters Kubernetes. Além disso, o usuário para se co-
nectar via SSH é o cloud
15
.
2.14.4.2. Scaling de cluster Kubernetes
A API scaleKubernetesCl uster permite que seja feito o scaling de um cluster
Kubernetes, aumentando ou diminuindo o número de nós trabalhadores, ou
mudando a oferta de computação utilizada no cluster. Entretanto, a oferta de
computação só pode ser aumentada e não diminuída. Um exemplo do uso da
API é mostrado abaixo.
scale KubernetesCluster id=<id_cluster_Kubernetes> size=<novo_tamanho_do_cluster> \
serviceofferingid=<id_da_compute_offering>
Essa mesma API pode ser chamada via UI, como ilustrado abaixo.
Figura 282: Formulário de scaling de cluster Kubernetes
15
Até a versão 4.16 do ACS, o usuário para conexão chamava-se core.
213
2.14.4.3. Upgrade de cluster Kubernetes
A API upgradeKubernetesCluster permite atualizar a versão minor ou patch de
um cluster Kubernetes em execução. Para isso, é necessário que uma ISO com
a versão desejada já esteja disponível no ACS.
upgrade kubernetescluster id=<id_cluster_Kubernetes> kubernetesversionid=<id_versao_kubernetes>
Essa mesma API pode ser chamada via UI, como ilustrado abaixo.
Figura 283: Formulário de upgrade de cluster Kubernetes
É importante observar que a atualização da versão do Kubernetes só pode
ser realizada entre versões patches da mesma versão minor ou de uma versão
minor para a próxima; não é possível pular versões. Essa restrição também se
aplica ao ACS.
2.14.5. Acesso ao Kubernetes
Enquanto o cluster Kubernetes é criado, automaticamente é gerada uma
interface de usuário para o cluster. A documentação do Kubernetes, disponível
neste link, apresenta mais informações sobre o dashboard do Kubernetes. A
UI disponibiliza uma aba Access com informações e o passo a passo de como
acessar o Kubernetes.
214
Figura 284: Acessando o Kubernetes
Essencialmente, um usuário precisa rodar primeiro um proxy local usando
kubectl e o arquivo kubeconfig para o cluster ter acesso ao dashboard. Por ques-
tão de segurança, não é permitido login com base no kubeconfig, sendo neces-
sário gerar um token de acesso e o kubectl para fazer a conexão. O comando
abaixo pode ser usado, com o path correto para o arquivo kubeconfig, para ro-
dar o proxy.
kubectl --kubeconfig /custom/path/kube.config proxy
Assim que o proxy estiver rodando, pode-se acessar o dashboard clicando
no link disponível. O token para o login pode ser obtido usando o seguinte
comando:
215
kubectl --kubeconfig /custom/path/kube.config describe secret $(kubectl --kubeconfig
/custom/path/kube.config get secrets -n kubernetes-dashboard |
grep kubernetes-dashboard-token | awk '{print $1}') -n kubernetes-dashboard
2.14.6. Gerando Token para a Dashboard
Um token de usuário default não pode ser utilizado para acessar o dashboard
do Kubernetes. Para acessá-lo, é necessário criar um token para o usuário kube
rnetes-dashboard no namespace kubernetes-dashboard e informá-lo no login.
O token pode ser criado usando o seguinte comando:
kubectl --kubeconfig <caminho-arquivo-kube.conf> create token kubernetes-dashboard -n kubernetes-dashboard
2.15. Snapshots
Snapshots são pontos de recuperação de uma VM por completo ou apenas
de um disco. Elas podem ser utilizadas como uma forma de recuperação de fa-
lhas ou ainda para criação de template e novos volumes. Em alguns hypervisors,
como VMWare e KVM, elas se comportam como backups.
2.15.1. Tipos de snapshot
Existem dois tipos possíveis de snapshots:
2.15.1.1. Snapshot de volume/disco
Tira uma snapshot dos discos
16
da VM. O administrador da nuvem pode defi-
nir um limite de snapshots que cada usuário pode ter. Usuários podem criar
volumes
17
e templates baseados em uma snapshot.
É possível realizar snapshots manualmente ou automaticamente, através de
configurações. Elas são criadas no Primary Storage e, se a configuração glo-
bal snapshot.backup.to.secondary estiver como true
18
, quando finalizados, são
16
A seção 2.4 detalha melhor o assunto de discos de uma VM.
17
Usuários podem adicionar o volume criado a partir da snapshot na VM, cujo representará
uma unidade externa, a fim de acessar arquivos sem a necessidade de restaurar o sistema
para a snapshot.
18
Recomendamos sempre utilizar essa configuração como true
216
transferidos para o Secondary Storage, onde permanecerão até serem removi-
dos.
2.15.1.2. Snapshot de VM
Tira uma snapshot semelhante à de volume, no entanto essa contém opções
para incluir o estado da memória/CPU da VM. Esse procedimento pode facilitar
a restauração rápida de uma VM
19
. Esse tipo de snapshot suporta snapshots
incrementais. A partir da primeira snapshot de uma VM, as demais salvarão as
diferenças que ocorrerão em um arquivo delta
20
.
Algumas das limitações existentes sobre snapshots são:
• Alterações de volumes, CPU ou memória em uma VM que possui snapshots
podem ocasionar erros, seja ao tentar realizar essas alterações na VM ou
ao tentar restaurar a snapshot.
• Não é possível salvar uma cópia de dois volumes de uma VM na mesma
snapshot.
• Não é possível realizar snapshots de VM e de volume ao mesmo tempo.
• Apenas snapshots geradas através do CloudStack são gerenciados pelo
mesmo.
2.15.2. Operações com snapshot
As operações possíveis com snapshots são:
19
Desde que não seja realizada nenhuma alteração de memória/CPU nessa VM.
20
Essa função depende do virtualizador utilizado, para maiores informações, consulte a do-
cumentação do virtualizador.
217
2.15.2.1. Snapshot de volume
Figura 285: Acessando os detalhes de uma VM
Figura 286: Tirando uma snapshot do Volume
Figura 287: Escolhendo o volume que será tirada a snapshot
218
Figura 288: Configurando a snapshot
2.15.2.2. Snapshot de VM
Figura 289: Tirando uma snapshot da VM
Figura 290: Configurando a snapshot
219
2.15.2.3. Visualização dos snapshots criados
Figura 291: Acessando as snapshots
Figura 292: Acessando as snapshots de volumes
Figura 293: Acessando as snapshots de VM
220
2.15.2.4. Criação de template a partir de uma snapshot de volume
Figura 294: Acessando os detalhes da snapshot
Figura 295: Criando o template
221
Figura 296: Configurando os dados do template
2.15.2.5. Criação de volume a partir de uma snapshot de volume
Figura 297: Criando o novo volume
222
Figura 298: Configurando o novo volume
2.15.2.6. Reversão de snapshot de volume
Figura 299: Revertendo para a snapshot
Figura 300: Confirmando a ação
223
2.15.2.7. Deleção de snapshot de volume
Figura 301: Deletando a snapshot de volume
Figura 302: Confirmando a remoção
2.15.2.8. Criação de snapshot de volume a partir de uma snapshot de VM
Figura 303: Acessando os detalhes da snapshot da VM
224
Figura 304: Criando uma snapshot de volume a partir da snapshot da VM
Figura 305: Configurando qual volume será extraído
Figura 306: Criando uma snapshot de volume
225
2.15.2.9. Reversão de snapshot de VM
Figura 307: Revertendo a snapshot
Figura 308: Confirmando a ação
2.15.2.10. Deleção de snapshot de VM
Figura 309: Removendo a snapshot de VM
226
Figura 310: Confirmando a ação
2.15.2.11. Configuração de snapshots recorrentes
Essa operação é descrita na página 110.
2.16. Eventos
Eventos são gerados quando um usuário realiza alguma ação na nuvem ou
quando o estado de algum recurso, virtual ou físico, é alterado.
É possível utilizar os eventos para monitorar tasks, jobs ou processos do
CloudStack, incluindo possíveis erros, em cada um deles.
2.16.1. Níveis de eventos
Os níveis possíveis de evento são:
• INFO: informa quando o processo monitorado ocorreu corretamente.
• WARN: informa quando o processo monitorado encontrou algum pro-
blema, porém ele não é terminal.
• ERROR: informa quando ocorreu um erro terminal no processo monito-
rado.
2.16.2. Busca e filtro de eventos
Para visualizar e buscar os eventos na interface web é necessário:
227
Figura 311: Navegando pelos eventos
A filtragem de eventos por data não é suportada na interface web.
2.16.3. Remoção ou arquivamento de eventos
Ao selecionar o checkbox de um evento, também é possível removê-lo ou
arquivá-lo:
Figura 312: Arquivando ou deletando um evento
Independente da ação selecionada, um pop-up irá surgir para confirmá-la.
228
2.17. Interface de usuário (UI)
Esse tópico tem como objetivo detalhar informações sobre a UI do Apache
CloudStack, além de prover dicas para facilitar a sua usabilidade.
2.17.1. Uso de timezone do browser
Todas as datas manipuladas pelo ACS são armazenadas no banco de dados
no padrão UTC, e, ao consultar os dados via API, os mesmos também retornam
em UTC. Para tornar a experiência do usuário mais agradável, na GUI existe a
opção Use local timezone, que, quando habilitada, faz com que as datas infor-
madas nas APIs e apresentadas para os usuários sejam convertidas para o fuso
horário do navegador.
Figura 313: Habilitando a configuração
Um exemplo de uso dessa opção é na filtragem de estatísticas de VMs. Com
a opção Use local timezone desabilitada, um usuário que esteja no horário de
Brasília, por exemplo, teria que inserir um intervalo de tempo num fuso horá-
rio diferente do dele para obter as estatísticas desejadas. Por exemplo, se o
usuário deseja buscar as estatísticas de uma VM e inserir o horário das 12:00h
às 17:00h sem habilitar a opção, ele receberá as estatísticas correspondentes
ao período das 9:00h às 14:00h, pois os horários seriam interpretados em UTC.
Com a opção habilitada, a UI realiza automaticamente a conversão para o fuso
horário do navegador, permitindo que o usuário busque e visualize as estatís-
ticas sem realizar conversões manuais de fuso horário.
Essa opção também influencia na manipulação das tarifas e relatórios do
Quota.
229
2.17.2. Documentação na UI
A maioria das telas e/ou páginas da interface web do CloudStack possui pe-
quenos ícones de ajuda, os quais ao passar o mouse por cima, pode-se obter
uma pequena descrição sobre aquele componente que pode ser bastante útil.
Também existem ícones em formato de ponto de interrogação (?) que quando
clicados abrem uma aba no navegador na seção da documentação oficial do
CloudStack que aborda aquele componente.
Figura 314: Exemplo de popup com os ícones de ajuda
2.18. Service offerings
Para que seja possível criar VMs, os virtualizadores exigem especificações
das características delas, como quantidade de CPU, tamanho da memória ou
do disco a ser alocado, entre outras definições. No CloudStack, essas caracte-
rísticas das VMs são agrupadas e padronizadas em forma de ofertas de serviço,
a fim de facilitar a especificação das VMs, mapear o uso dos recursos e, se for
o caso, aplicar cobrança sobre a utilização dos mesmos. O CloudStack divide
as ofertas de serviços em dois segmentos:
• Disk offerings
• Compute offerings
2.18.1. Disk offerings
Disk offerings são as ofertas de serviço destinadas aos recursos de armaze-
namento de uma VM. Máquinas virtuais criadas a partir de um template uti-
230
lizarão as disk offerings para criação de discos extras, já as criadas com ISOs
necessitarão de uma disk offering para criação do root disk.
2.18.1.1. Criação de disk offering
Para criar uma disk offering:
Figura 315: Iniciando a criação de uma nova disk offering
Ao clicar no botão Add Disk Offering, será aberto um formulário para preen-
chimento das informações:
231
Figura 316: Criando a nova disk offering
232
Explicação de alguns campos do formulário:
• Tipos de provisionamento:
1. Thin Provisioning: discos desse tipo serão alocados com o mínimo
necessário e poderão crescer, de acordo com a necessidade, até o
limite estabelecido.
2. Sparse Provisioning: discos desse tipo já iniciarão alocados com o ta-
manho estabelecido na oferta, no entanto, eles poderão conter da-
dos antigos. A criação dos mesmos será rápida, pois os dados antigos
não serão apagados ou sobrescritos, porém será necessário fazê-lo
antes de escrever novos dados. A performance desse tipo de disco
será baixa para as primeiras escritas.
3. Fat Provisioning: discos desse tipo já iniciarão alocados com o tama-
nho estabelecido na oferta e todo o espaço utilizado será sobres-
crito, apagando quaisquer dados que estejam nos blocos. Suas cria-
ções serão mais demoradas em relação ao sparse provisioning, devido
ao processo de limpeza dos dados antigos, no entanto, sua perfor-
mance nas primeiras escritas será superior.
• Disk Size Strictness: Quando o valor for verdadeiro, o tamanho do volume
não pode ser alterado.
• QoS Type: define o QoS para os discos. Para utilizar o QoS de hypervisor
ou de storage, é necessário que eles suportem essa funcionalidade.
1. None: Por padrão as ofertas não a implementam.
2. Hypervisor: Define taxas de leitura e escrita pelo hypervisor. Depen-
dendo do hypervisor, algumas definições de QoS podem não estar
implementadas, portanto, é necessário validá-las antes de aplicá-las
em produção.
3. Storage: Define um mínimo e um máximo de IOPS no lado do storage.
233
• Hypervisor Snapshot Reserve: Permite reservar espaços para snapshots além
do disco de dados. Medido em porcentagem em relação ao data disk, o
valor final reservado é a porcentagem escolhida mais o tamanho do pró-
prio data disk. Isto não se aplica ao KVM.
• Storage Tags: As storage tags serão utilizadas para direcionar os volumes
para os storages compatíveis.
• Sobre o acesso:
1. Public: Define se a oferta de serviço estará disponível para todos os
domínios ou será de uso restrito. Selecione sim para o acesso em
todos os domínios.
2. Domain: Essa opção só aparecerá quando Public estiver desmarcado.
Essa opção determina os domínios que utilizarão a oferta.
3. Zone: Define em quais zonas a oferta estará disponível.
2.18.1.2. Edição de disk offering
Após criada, poucos atributos da disk offering podem ser alterados.
• Editar:
Figura 317: Iniciando a edição da disk offering
234
Figura 318: Editando a disk offering
• Atualizar acesso:
Figura 319: Iniciando a atualização de acesso da disk offering
Figura 320: Atualizando o acesso da disk offering
• Alterar ordem:
235
Figura 321: Alterando ordem da disk offering
2.18.1.3. Exclusão de disk offering
Para excluir uma disk offering basta acessar a mesma e clicar no ícone de lixeira:
Figura 322: Iniciando a exclusão da disk offering
Figura 323: Excluindo a disk offering
Caso haja volumes com a disk offering, eles continuarão funcionando nor-
malmente, bem como os processos de migração e reinício da VM, pois o Cloud-
Stack copia as características da disk offering para o disco, no entanto não será
possível criar novos volumes com ela.
Mais informações na documentação oficial.
236
2.18.2. Compute offerings
Compute offerings são as ofertas destinadas aos recursos computacionais
de uma VM, como CPU e memória RAM. Uma compute offering também pos-
sui uma disk offering, que define as características do root disk da VM (quando
criada a partir de um template).
No momento de criação de uma compute offering, a mesma será asssoci-
ada a uma disk offering. Este vínculo pode ocorrer de duas maneiras. Uma
delas é através de especificações dos discos, o tipo de armazenamento e as
tags, podendo ser incluídas diretamente na oferta de cálculo. A segunda forma
é conectar uma disk offering a uma compute offering, sendo assim a oferta de
disco será utilizada para o Root Disk durante a criação da instância. Vale ressal-
tar que os usuários poderão utilizar uma oferta de disco diferente para o root
disk durante o processo de criação da VM.
2.18.2.1. Criação de compute offering
Para criar uma compute offering:
237
Figura 324: Iniciando a criação de uma nova compute offering
Ao clicar no botão Add Compute Offering, será aberto um formulário para
preenchimento das informações:
238
Figura 325: Criando a nova compute offering - 1 - continua
239
Explicação de alguns campos do formulário:
• Compute Offering Type: trata-se de alternativas que controlam a autono-
mia com que o usuário final tem para criar uma disk offering. São três as
opções:
1. Fixed offerings: são ofertas com valores de CPU (cores e velocidade) e
memória fixos. Todas as VMs criadas com essa oferta terão a mesma
configuração.
2. Custom constrained offerings: nesse tipo de oferta o usuário final
utilizará os recursos alocados dentro de uma faixa valores definida
pelo administrador. O usuário que utilizar essa oferta terá de sele-
cionar um valor entre os limites definidos para cada parâmetro no
momento da criação da VM.
3. Custom unconstrained offerings: são ofertas sem limites. Qualquer
valor pode ser informado no momento de criação da VM, desde que
ele esteja dentro do disponível para uso.
• CPU cores: é a quantidade de núcleos alocados para atender uma VM
que utiliza essa oferta de serviço. Se a opção Custom constrained offe
rings estiver escolhida, é necessário determinar a quantidade mínima e
máxima de cores na criação da oferta. Se a opção Custom unconstrained
for escolhida, este campo não será exibido.
• CPU (in MHz): determina a velocidade dos núcleos. Essa definição só é
utilizada se o limite da CPU estiver ativo. Se a opção Custom Unconstrain
ed for escolhida, este campo não será exibido.
• Memory (in MB): define a quantidade de memória em megabytes que a
VM do sistema deve ser alocada. Se for selecionada a opção Cust om co
nstrained, será necessário informar a quantidade mínima e máxima de
240
memória durante a criação da oferta. Se for selecionada Custom uncons
trained, este campo não aparecerá.
• Host tags: serão utilizadas para direcionar as VMs para os hosts compatí-
veis.
• Network Rate: define a transferência de dados em MB por segundo.
• Offer HA: Se sim, a VM será monitorada e em caso de falha do host, ela
será reiniciada em outro host disponível.
• Dynamic Scaling Enabled: se escolhida, a CPU e a memória da instância
podem ser escalonadas dinamicamente.
• CPU Cap: limita o uso de CPU mesmo que haja recursos disponíveis.
• Volatile: VMs criadas com uma compute offering volátil terão seus root
disks restaurados ao estado inicial toda vez que for realizado o boot das
mesmas.
• Deployment Planner: Algoritmo utilizado pelo o CloudStack para escolha
de qual host implantar VMs criadas com essa oferta de serviço.
1. First Fit: escolhe o host que tiver capacidade suficiente para suportar
os requisitos da instância.
2. User Dispersing: dispersa uniformemente as instâncias pertencen-
tes à mesma conta em diferentes clusters ou pods.
3. User Concentrated: concentra instâncias pertencentes à mesma conta
num único pod.
4. Implicit Dedication: implantará instâncias que são dedicadas a um
domínio ou conta específica. Se você escolher esse planejador, tam-
bém deverá escolher um valor para o parâmetro
planner mode.
5. Bare Metal: é usado com host bare metal.
241
• Planner Mode: esta opção só estará disponível se for selecionada impl ic
it dedication. O planner mode determinará como o deploy das instâncias
será feito na infraestrutura privada.
1. Strict: Um host não será compartilhado entre contas distintas.
2. Preferred: A instância será implantada em uma infraestrutura dedi-
cada, se possível. Caso contrário, a instância pode ser implementada
numa infraestrutura partilhada.
• GPU: Atribui uma GPU física, ou parte dela, à uma instância. Isso faz com
que aplicações gráficas sejam executadas na VM. É mostrada uma lista de
GPU disponíveis.
2.18.2.2. Edição de compute offering
Após criada a compute offering, poucos atributos da mesma podem ser altera-
dos.
• Editar:
Figura 326: Iniciando a edição da compute offering
Figura 327: Editando a compute offering
242
• Atualizar acesso:
Figura 328: Iniciando a atualização de acesso da compute offering
Figura 329: Atualizando o acesso da compute offering
• Alterar ordem:
Figura 330: Alterando a ordem da compute offering
2.18.2.3. Exclusão de compute offering
Para excluir uma compute offering basta acessar a mesma e clicar no ícone de
lixeira:
Figura 331: Iniciando a exclusão da compute offering
243
Figura 332: Excluíndo a compute offering
Caso haja VMs rodando com a compute offering, elas continuarão funcio-
nando normalmente, pois o CloudStack copia as características da compute of-
fering para a VM, no entanto não será possível criar novas com ela. No live
scaling da VM que a utiliza, será necessário trocá-la.
2.18.2.4. Alteração de compute offering da VM
Também é possível realizar a troca da compute offering utilizada por uma VM
já existente. Há duas formas de realizar essa troca: via UI e via CloudMonkey,
sendo que em ambos os casos é necessário que a VM esteja parada.
• Via UI:
Figura 333: Iniciando a alteração da compute offering
244
Figura 334: Alterando a compute offering
Figura 335: Alterando a compute offering
Após a realização desses passos a compute offering da VM será atualizada.
• Via CloudMonkey: Pode-se utilizar as APIs scaleVirtualMachine ou chan-
geServiceForVirtualMachine
21
. Nessa situação, ambas possuem o mesmo
funcionamento e obterão o mesmo resultado. Basta utilizar o comando:
scale virtualmachine id=<VM id> serviceofferingid=<compute offering id>
21
A sintaxe utilizada pelas APIs é a mesma, trocando apenas a chamada de s c a l e virtualma
chine por change serviceforvirtualmachine.
245
Ao executar esse comando com sucesso, o resultado do mesmo apresen-
tará diversas informações relacionadas à VM alterada, inclusive a nova
compute offering definida.
{
"virtualmachine": {
"account": "admin",
"affinitygroup": [],
"cpunumber": 1,
"cpuspeed": 1000,
"created": "2022-03-08T17:06:23+0000",
"details": {
"Message.ReservedCapacityFreed.Flag": "true",
"rootDiskController": "osdefault"
},
"displayname": "VM-ea2c34dd-a8a9-4b6a-b6c4-9404e034f3b7",
...
"serviceofferingid": "ab647165-7a0a-4984-8452-7bfceb036528",
"serviceofferingname": "Small Instance",
"state": "Stopped",
"tags": [],
"templatedisplaytext": "Macchinina - Light SO",
"templateid": "b81aab72-2c37-466e-b53f-bdaf398322fa",
"templatename": "Macchinina",
"userid": "af1818b9-26de-11ec-8dcf-5254005dcdac",
"username": "admin",
"zoneid": "8b2ceb16-a2f2-40ea-8968-9e08984bdb17",
"zonename": "sc-floripa-01"
}
}
Ao realizar a alteração da compute offering de uma VM, é importante levar
em conta suas host tags e storage tags, além das tags da compute offering dese-
jada. Isso porque serão apresentadas como opções para scale da VM apenas
as compute offerings compatíveis, ou seja, apenas as compute offerings que pos-
suam as mesmas tags que a VM ou que não possuam restrição de tags.
Mais informações na documentação oficial.
2.18.3. Network offerings
Network offerings são as ofertas destinadas a recursos de rede, como DNS,
DHCP, firewall, load balancing, entre outros serviços.
2.18.3.1. Criação de network offering
Para criar uma network offering:
246
Figura 336: Iniciando a criação de uma nova network offering
Ao clicar no botão Add Network Offering, será aberto um formulário para
preenchimento das informações:
Figura 337: Criando a nova network offering - 1 - continua
É possível criar três tipos de redes:
247
• Isolated: redes destinadas a apenas uma conta.
• L2: redes sem serviços. Ao utilizar esse tipo de rede, o usuário final deve
realizar o gerenciamento de IPs ou devem ser utilizados IPs estáticos. Esse
tipo de rede possui uma limitação a nível lógico, a qual permite que ela
seja criada apenas para uma conta, contudo, quando é necessário que
diversas contas a utilizem, é possível criar uma rede do tipo shared e sem
serviços, simulando uma rede L2 (ao realizar a criação de uma rede com
essa oferta, os dados nos campos de IPv4 são obrigatórios pelo Cloud-
Stack, contudo eles não serão utilizados, portanto pode ser informado
qualquer coisa).
• Shared: redes que podem ser compartilhadas entre contas do mesmo
domínio.
A opção Specify VLAN permite que o administrador da nuvem atribua uma
VLAN específica à rede criada. É importante que esta VLAN específica não faça
parte da faixa disponível para alocação dinâmica, descrita na rede física de trá-
fego Guest (pode ser consultada na aba Physical network da zona correspon-
dente). Se não for marcada, o CloudStack atribuirá uma VLAN de maneira ale-
atória dentre as disponíveis quando a rede passar para o estado Implemented
e a removerá quando a rede não estiver mais em uso (estado Allocated). Para
redes L2, a VLAN é atribuída automaticamente.
Redes com Network offerings marcadas como Persistent serão implementa-
das sem a necessidade de adicionar uma VM à rede.
248
Figura 338: Criando a nova network offering - 2
• Com o Internet Protocol, é possível especificar qual versão de IP a offe-
ring irá suportar. O CloudStack oferece duas opções: IPv4 (padrão) e Dual
Stack. O Dual Stack permite que a offering suporte tanto IPv4 quanto IPv6.
• As opções Promiscuous Mode, MAC Address Changes e Forged Transmits são
destinadas à Nested Virtualization, no VMWare.
• Os Supported Services são os serviços disponíveis para seleção. Cada ser-
viço possui uma configuração, sendo possível escolher o provedor para
cada um deles.
• A partir da compute offering, é possível informar a service offering que o
VR irá utilizar. Para conseguir usar essa funcionalidade, é preciso que ao
menos um dos serviços a seguir esteja habilitado na lista de Supported
Services: VPN, DHCP, DNS, Firewall, LB, UserData, SourceNat, StaticNat,
PortForwarding.
249
• Redes com Conserve Mode irão alocar os recursos somente quando a pri-
meira VM for criada.
• É possível marcar a opção Enable network offering para que a network of-
fering criada já esteja pronta para uso. Caso contrário, será necessário
habilitá-la antes de utilizá-la.
2.18.3.2. Edição de network offering
Após criada, poucos atributos da network offering podem ser alterados.
• Editar:
Figura 339: Iniciando a edição da network offering
Figura 340: Editando a network offering
• Habilitar/desabilitar a oferta:
250
Figura 341: Iniciando a desabilitação da network offering
Figura 342: Desabilitando a network offering
Se houver alguma rede criada e a oferta for desabilitada, a rede continu-
ará funcionando normalmente, no entanto não será possível criar novas
redes.
• Atualizar acesso:
Figura 343: Iniciando a atualização de acesso da network offering
Figura 344: Atualizando o acesso da network offering
251
• Alterar ordem:
Figura 345: Alterando ordem da network offering
2.18.3.3. Exclusão de network offering
Para excluir uma network offering basta acessar a mesma e clicar no ícone de
lixeira:
Figura 346: Iniciando a exclusão da network offering
Figura 347: Excluíndo a network offering
Caso haja redes com a network offering ou ela for default, não será possível
excluí-la, no entanto é possível desabilitá-la.
Mais informações na documentação oficial.
252
2.18.4. VPC Offerings
VPC offerings são as ofertas destinadas ao VPC (mais informações sobre VPC
na seção 2.7). Elas são similares à network offerings (seção 2.18.3)
2.18.4.1. Criação de VPC offering
Para criar uma VPC offering:
Figura 348: Iniciando a criação de uma nova VPC offering
Ao clicar no botão Add VPC Offering, será aberto um formulário para preen-
chimento das informações:
253
Figura 349: Criando a nova VPC offering
Os Supported Services são os serviços disponíveis para seleção. Cada serviço
possui uma configuração, sendo possível escolher o provedor para cada um
deles. Em sua maioria, existe apenas o provedor VpcVirtualRouter.
O campo Compute offering é explicado na Seção 2.18.3.
Em seguida, é possível marcar a opção Enable VPC offering para que a VPC of-
fering criada já esteja pronta para uso. Caso contrário, será necessário habilitá-
la antes de utilizá-la.
2.18.4.2. Edição de VPC offering
Após criada, poucos atributos da VPC offering podem ser alterados.
• Editar:
254
Figura 350: Iniciando a edição da VPC offering
Figura 351: Editando a VPC offering
• Habilitar/desabilitar a oferta:
Figura 352: Iniciando a desabilitação da VPC offering
Figura 353: Desabilitando a VPC offering
Se houver algum VPC criado e a oferta for desabilitada, o VPC continuará
funcionando normalmente, no entanto não será possível criar novos.
255
• Atualizar acesso:
Figura 354: Iniciando a atualização de acesso da VPC offering
Figura 355: Atualizando o acesso da VPC offering
• Alterar ordem:
Figura 356: Alterando a ordem da VPC offering
2.18.4.3. Exclusão de VPC offering
Para excluir uma VPC offering basta acessar a mesma e clicar no ícone de lixeira:
Figura 357: Iniciando a exclusão da VPC offering
256
Figura 358: Excluíndo a VPC offering
Caso haja VPCs com a VPC offering ou ela for default, não será possível excluí-
la, no entanto é possível desabilitá-la.
257
3. CloudMonkey, API e outros
O CloudMonkey é uma ferramenta de linha de comando (Command Line
Interface - CLI) escrito em Go e utilizado para interação com a API do CloudStack.
O mesmo se trata de um projeto open-source, que pode ser acessado através
do seu github.
Os passos para a instalação, configuração e uso do CloudMonkey se encon-
tram nas próximas subseções. Os passos para a instalação, configuração e uso
do CloudMonkey se encontram nas próximas subseções.
3.1. Instalação
O CloudMonkey possui duas formas de instalação distintas, uma para usuá-
rios de Linux/Mac e outra para usuários de Windows: O CloudMonkey possui
duas formas de instalação distintas, uma para usuários de Linux/Mac e outra
para usuários de Windows:
• Linux/Mac:
É necessário realizar o download da última release lançada, escolhendo o
binário correspondente à plataforma utilizada, e copiá-lo para um diretó-
rio que faça parte da variável $PATH, como /usr/local/bin. Via terminal:
sudo wget <file link> -O /usr/local/bin/cmk
sudo chmod +x /usr/local/bin/cmk
• Windows:
No link de releases citado anteriormente, é necessário realizar o download
do executável (.exe) correspondente à plataforma utilizada e copiá-lo para
um diretório que faça parte dos diretórios com executáveis do Windows,
como C:\Windows\System32\. Após, é necessário verificar a execução do
arquivo cmk.exe.
3.2. Configuração
Por padrão, o CloudMonkey criará um perfil inicial que terá algumas cre-
denciais padrões do CloudStack. Para configurar o CloudMonkey, existe o co-
mando set:
258
$ cmk
Apache CloudStack CloudMonkey 6.1.0
Report issues: https://github.com/apache/cloudstack-cloudmonkey/issues
(localcloud) > set url http://myprovider.cloud/client/api
(localcloud) > set username myusername
(localcloud) > set password mypassword
(localcloud) > sync
Discovered 622 APIs
Caso se queira criar um novo perfil, pode-se usar o mesmo comando set:
(localcloud) > set profile newprofile
(newprofile) > set url http://myprovider.cloud/client/api
(newprofile) > set username myusername
(newprofile) > set password mypassword
(newprofile) > sync
Discovered 622 APIs
Pode ser necessário também desabilitar a configuração de verificação de
certificado SSL caso seja usado HTTP e não HTTPS:
(localcloud) > set verifycert false
Ao realizar o login com outro usuário, é recomendado sempre utilizar o co-
mando sync, a fim de buscar as APIs às quais esse usuário possui acesso. Para
retornar ao perfil anterior, basta executar o comando:
(newprofile) > set profile localcloud
3.3. Uso
O CloudMonkey, realiza chamadas para a API do CloudStack. Portanto, para
utilizá-lo, é necessário ter um conhecimento prévio do que se deseja fazer e
quais APIs serão necessárias. Para isso o CloudMonkey possui alguns facilita-
dores:
• Verificação das APIs disponíveis:
(localcloud) > list apis
{
"api": [
{
"description": "Creates VPC offering",
"isasync": true,
"name": "createVPCOffering",
"params": [
{
259
"description": "desired service capabilities as part of vpc offering",
"length": 255,
"name": "servicecapabilitylist",
"required": false,
"since": "4.4",
"type": "map"
},
...
}
],
"count": 622
}
• autocomplete: ao utilizar TABs, é possível obter uma lista de sugestões de
comandos.
Figura 359: Utilizando o autocomplete
260
Figura 360: Verificando o autocomplete para um comando específico
Figura 361: Verificando o autocomplete para uma API específica
• Detalhes sobre uma API: é possível obter uma descrição detalhada de
uma API específica com os comandos:
261
Figura 362: Utilizando o -h para obter ajuda
Ou através do comando:
(localcloud) > help createAccount
Uma vez que sabe-se o que deve ser feito, basta realizar a chamada para
API via CloudMonkey:
262
Figura 363: Realizando uma chamada
263
4. Contabilização do consumo de recursos
O módulo de contabilização do consumo de recursos computacionais é sub-
dividido em dois mecanismos: coleta de uso (Usage) e contabilização de uso
(Quota), sendo o segundo complementar ao primeiro.
O mecanismo Usage realiza periodicamente a identificação e a coleta dos
dados de uso de recursos no ambiente. Já o mecanismo Quota é um plugin que
permite gerenciar um modelo de tarifas sobre o consumo de recursos compu-
tacionais.
Essa seção descreve como acessar os relatórios de uso de recursos do Usage,
e as tarifas ativas e os relatórios do Quota.
4.1. Usage
4.1.1. Relatórios de uso de recursos
Os relatórios de uso dos recursos poderão ser acessados através da API lis
tUsageRecords, como mostrado a seguir:
(admin) > list usagerecords startdate='yyyy-MM-dd'T'HH:mm:ssZ' enddate='yyyy-MM-dd'T'HH:mm:ssZ'
Esse comando irá retornar uma lista de diversos relatórios com a seguinte
estrutura:
...
{
"account": "<conta>",
"accountid": "<Identificador da conta>",
"description": "<Descrição do relatório>",
"domain": "<nome do dominio>",
"domainid": "<ID do dominio>",
"enddate": "yyyy-MM-ddTHH:59:59+0000",
"rawusage": "depende do usagetype",
"startdate": "yyyy-MM-ddTHH:00:00+0000",
"tags": [<conjunto de tags>],
"usage": "<depende do usagetype>",
"usagetype": <tipo de recurso contabilizado>,
"zoneid": "<ID da zona>"
},
...
Ao lançar um evento no Cloustack, ele não ficará visível nessas tabelas de
requisição API de forma síncrona, e sim periodicamente, após a atualização dos
dados com base no tempo escolhido pelo operador nas configurações globais.
265
4.2. Quota
4.2.1. Tarifas
Para visualizar as tarifas ativas para a conta de usuário deve-se:
Figura 365: Listagem das tarifas ativas
Outras informações das tarifas, como nome, descrição e valor, podem ser
acessadas na página de detalhes de cada tarifa.
Figura 366: Detalhes das tarifas
4.2.2. Relatórios
Ao selecionar o sub-menu Summary e selecionar a conta de usuário de-
sejada, é possível visualizar os detalhes e os relatórios do Quota referentes a
conta.
266
Figura 367: Acessando detalhes e relatórios de uma conta
4.2.2.1. Créditos
Para visualizar o histórico de adição/remoção de créditos (quem adicionou,
quanto adicionou, quando adicionou), basta navegar até a aba Credits:
Figura 368: Listagem de créditos
Essa listagem também pode ser realizada via CloudMonkey. Exemplo:
(admin) > quota creditslist accountid=af16aaed-26de-11ec-8dcf-5254005dcdac domainid=52d83793-26de-11ec
-8dcf-5254005dcdac
267
{
"count": 3,
"credit": [
{
"credit": -192.87,
"creditedon": "2023-10-04T13:05:13+0000",
"creditorid": "af16aaed-26de-11ec-8dcf-5254005dcdac",
"creditorname": "admin",
"currency": "$",
"postingdate": "2023-10-04T13:05:06+0000"
},
{
"credit": 350,
"creditedon": "2023-10-04T13:20:24+0000",
"creditorid": "af16aaed-26de-11ec-8dcf-5254005dcdac",
"creditorname": "admin",
"currency": "$",
"postingdate": "2023-10-04T13:20:24+0000"
},
{
"credit": -25,
"creditedon": "2023-10-05T15:56:58+0000",
"creditorid": "af16aaed-26de-11ec-8dcf-5254005dcdac",
"creditorname": "admin",
"currency": "$",
"postingdate": "2023-10-05T15:56:58+0000"
}
]
}
4.2.2.2. Uso de recursos
A aba Quota usage apresenta dados de uso dos recursos no período filtrado:
268
Figura 369: Listagem de uso de recurso
Via CloudMonkey a consulta deve ser realizada conforme o exemplo a se-
guir:
(admin) > quota statement account=admin domainid=52d83793-26de-11ec-8dcf-5254005dcdac startdate=2023-1
0-01T00:00:00+0000 enddate=2023-10-05T13:55:01+0000
{
"statement": {
"account": "admin",
"accountid": "af16aaed-26de-11ec-8dcf-5254005dcdac",
"currency": "$",
"domain": "52d83793-26de-11ec-8dcf-5254005dcdac",
"enddate": "2023-10-05T13:55:01+0000",
"quotausage": [
{
"name": "RUNNING_VM",
"quota": 0,
"type": 1,
"unit": "Compute*Month"
},
{
"name": "ALLOCATED_VM",
"quota": 195,
"type": 2,
"unit": "Compute*Month"
},
...outros recursos...
{
"name": "NETWORK",
"quota": 0,
269
"type": 30,
"unit": "Compute*Month"
},
{
"name": "BACKUP_OBJECT",
"quota": 0,
"type": 31,
"unit": "GB*Month"
}
],
"startdate": "2023-10-01T00:00:00+0000",
"totalquota": 202.64381816
}
}
Também é possível realizar a consulta detalhada do consumo:
Figura 370: Listagem detalhada de uso de recurso
Via CloudMonkey:
(admin) > quota statement account=admin domainid=52d83793-26de-11ec-8dcf-5254005dcdac startdate=2023-1
0-04T00:00:00+0000 enddate=2023-10-05T13:55:01+0000 showresources=true type=6
{
"statement": {
"account": "admin",
"accountid": "af16aaed-26de-11ec-8dcf-5254005dcdac",
270
"currency": "$",
"domain": "52d83793-26de-11ec-8dcf-5254005dcdac",
"enddate": "2023-10-05T13:55:01+0000",
"quotausage": [
{
"name": "VOLUME",
"quota": 7.64381816,
"resources": [
{
"displayname": "usage",
"quotaconsumed": 4.805108,
"removed": false,
"resourceid": "f710ed0f-c234-4c31-89ae-de23c9d8779f"
},
{
"displayname": "DATA-220",
"quotaconsumed": 2.83871016,
"removed": false,
"resourceid": "e4727094-2571-4ebb-aca7-5cc97778fde0"
}
],
"type": 6,
"unit": "GB*Month"
}
],
"startdate": "2023-10-04T00:00:00+0000",
"totalquota": 7.64381816
}
}
4.2.2.3. Balanço
A aba Daily Quota balance apresenta os balanços diários (crédito + uso de re-
cursos) referentes ao período filtrado. O balanço é fechado diariamente e re-
presenta um somatório dos dados anteriores, sendo o balanço mais recente
sempre referente ao dia anterior.
Exemplo: diariamente é gerado R$100,00 de uso de recurso. Ao final do
primeiro dia, o balanço será -R$100,00. Ao final do segundo dia, o balanço
será -R$200,00. Ao final do terceiro dia, o balanço será -R$300,00 e assim por
diante. Ao realizar a busca filtrando entre o terceiro e quinto dia, os balanços
retornados serão -R$300,00 (terceiro dia), -R$400,00 (quarto dia) e -R$500,00
(quinto dia).
271
Figura 371: Listagem do balanço do Quota
Via CloudMonkey:
(lab) > quota balance account=oliver domainid=7efa7a0c-8f43-4564-b8cc-d709424dc69a startdate=2022-04-1
0 enddate=2022-04-16
{
"balance": {
"currency": "$",
"dailybalances":
[
{
"balance": 99.67,
"date": "2022-04-10T00:00:00+0000"
},
{
"balance": 99.6,
"date": "2022-04-11T00:00:00+0000"
},
{
"balance": 99.53,
"date": "2022-04-12T00:00:00+0000"
},
{
"balance": 99.47,
"date": "2022-04-13T00:00:00+0000"
},
{
"balance": 94.23,
"date": "2022-04-14T00:00:00+0000"
},
{
"balance": 88.96,
"date": "2022-04-15T23:59:59+0000"
},
272
{
"balance": 83.7,
"date": "2022-04-16T23:59:59+0000"
}
]
}
}
273
5. Cloud-init
O cloud-init é um software open source criado para automatizar a iniciali-
zação e configuração de sistemas operacionais durante o boot, com foco em
máquinas virtuais para nuvem. Dentre suas diversas funcionalidades estão:
gerência de senhas, injeção de chaves SSH e injeção de metadados de usuá-
rios. Ele é suportado pelos maiores sistemas de orquestração de nuvem, como
Azure, Google Compute Engine, OpenStack e CloudStack.
5.1. Etapas de inicialização
O cloud-init possui cinco etapas de inicialização, sendo elas:
• Generator: disponível apenas para sistemas que utilizam systemd, essa
etapa é a primeira a ser executada e define se o cloud-init deve ser exe-
cutado durante o boot. Para desabilitar a execução do cloud-init no boot
do sistema operacional, basta que exista o arquivo / etc/cloud/cloud-init.
disabled.
• Local: etapa que irá localizar os datasources locais e aplicar as configura-
ções de rede no sistema.
• Network: essa etapa é executada após a Local e requer que as configu-
rações de rede estejam funcionando. Nela serão processados todos os
módulos informados na seção cloud-init-modules do arquivo /etc/cloud/c
loud.cfg. Essa etapa realiza as configurações iniciais da máquina virtual,
como a definição do hostname e a execução do comando mount.
• Config: essa etapa é executada após a Network e nela serão processados
todos os módulos informados na seção cloud-config-modules do arquivo /
etc/cloud/cloud.cfg. Ela é destinada a módulos de configuração indepen-
dentes, que não afetam outros módulos, como a troca de senha de um
usuário e a localidade e o fuso-horário do sistema operacional.
274
• Final: última etapa a ser executada no boot do sistema operacional. Nela
serão processados todos os módulos informados na seção cloud-final-
modules do arquivo /etc/cloud/cloud.cfg. Ela é destinada a processos que
são geralmente executados pelo usuário, como atualização e instalação
de pacotes e execução de scripts.
Caso o usuário queira executar scripts próprios, ele deve colocar os mes-
mos no diretório /var/lib/clou d/scripts, o qual possui três subdiretórios
representando a frequência de execução dos mesmos:
– per-boot: scripts dentro desse diretório serão executados toda vez
que for feito boot no sistema operacional.
– per-instance: scripts dentro desse diretório serão executados apenas
na primeira vez que for feito boot no sistema operacional. Mais in-
formações na seção 5.2.
– per-once: scripts dentro desse diretório serão executados apenas na
primeira vez, mesmo se o sistema operacional sofrer alterações. Mais
informações na seção 5.2.
5.2. Frequência de execução
O cloud-init possui três frequências de execução dos módulos e scripts, sendo
elas:
• per-boot/always: executa toda vez que for feito boot.
• per-instance: executa apenas na primeira vez que for feito boot no sis-
tema operacional. Para determinar se é o primeiro boot do sistema ope-
racional, o cloud-init guarda um cache para futuras validações. Se o cache
existe, significa que o cloud-init já foi executado uma vez, portanto não é o
primeiro boot. Esse comportamento pode causar inconsistências quando
é feita uma imagem a partir dessa instância, portanto o cloud-init adota
um comportamento padrão, chamado check, o qual valida o atual instance
275
ID com o gravado no cache. Caso sejam diferentes, ele irá considerar como
primeiro boot. Também existe o comportamento trust, o qual não valida
os instance ID. O instance ID normalmente é definido pelo orquestrador
quando uma nova máquina virtual é criada. Também é possível limpar o
cache manualmente para redefinir o primeiro boot.
• per-once: executa apenas na primeira vez que for feito boot no sistema
operacional, mesmo se houver alterações no instance ID. Esse compor-
tamento é similar ao trust da frequência per-instance. Recursos sob essa
frequência podem ser reexecutados caso seja feita limpeza manual do
cache e o reboot no sistema operacional.
Para limpar manualmente o cache do cloud-init, basta executar o comando:
cloud-init clean
5.3. DataSources conhecidos
O cloud-init possui integração com os maiores sistemas de orquestração de
nuvem, como Azure, Google Compute Engine, OpenStack e CloudStack (a lista
completa pode ser encontrada em known-sources). Cada um deles opera de
uma forma única e possui suas próprias configurações. Para o CloudStack, por
exemplo, ele necessita que a máquina virtual esteja em uma rede que possua
um virtual router, pois é dele que o cloud-init irá recuperar as informações e
metadados dos usuários.
5.4. Módulos
O cloud-init possui diversas funcionalidades, como gerência de senhas, in-
jeção de chaves SSH e injeção de metadados de usuários (a lista completa pode
ser encontrada em modules). Caso o usuário necessite de alguma funcionali-
dade que o cloud-init não possui, ele ainda pode criar scripts personalizados
(mais informações na seção 5.1). Para cada script é necessário informar, na
primeira linha, qual programa irá executá-lo. Por exemplo:
276
#!/bin/bash
É necessário estar atento às frequências de execução dos módulos aplica-
dos. Módulos como ssh e set-passwords executam, por padrão, na frequência
per-instance, ou seja, irão executar somente no primeiro boot. Caso seja neces-
sário alterar esta frequência, o cloud-init permite sobrescrevê-la da seguinte
forma:
...
cloud_init_modules:
...
- update_etc_hosts
- ca-certs
- rsyslog
- users-groups
- [ ssh, always ]
...
5.5. Criação de uma imagem personalizada
É possível criar uma imagem personalizada via CloudStack reproduzindo os
seguintes passos:
• Criar uma VM a partir de uma ISO, como descrito nas seções 2.10 e 2.3.
• Com o sistema operacional instalado e configurado, instalar o pacote do
cloud-init.
• Por padrão, o cloud-init tenta buscar dados de todos os datasources. Caso
ele não consiga por um, tenta por outro. No entanto, é possível limitar os
datasources que o cloud-init irá utilizar. Como essa imagem será desti-
nada ao CloudStack, os datasources serão limitados a ele. Para isso, no
diretório /etc/cloud/cloud.cfg.d/, deve ser criado o arquivo 99_cloudstack
.cfg com os seguintes dados:
datasource:
CloudStack: {}
None: {}
datasource_list: [CloudStack, None]
277
A configuração limitará os datasources para CloudStack e None. Caso os
dados não sejam encontrados pelo CloudStack, eles não serão buscados
de mais nenhum. As demais configurações também podem ser criadas
no mesmo diretório e serão lidas em ordem alfabética pelo cloud-init, no
entanto, por padrão, elas serão definidas no arquivo /et c/cloud/cloud.cf
g.
• No arquivo /etc/cloud/cloud.cfg, na seção users, podem ser definidos usuá-
rios a serem criados. Por padrão, já existe a entrada default, que refe-
rencia a entrada default_user, na seção system_info. Os valores do de-
fault_user podem ser alterados para condizerem com o usuário desejado.
• No arquivo /etc /cloud/cloud.cfg, ao ser instalado o pacote do cloud-init,
diversos módulos vêm pré-definidos. É possível adicionar, alterar pro-
priedades ou remover os módulos, de acordo com a necessidade. Mais
informações sobre módulos na seção 5.4.
Para alterar o nome do host, é necessário utilizar os módulos set_hostname,
update_hostname e update_etc_hosts. Para injetar chaves SSH, é necessário
utilizar o módulo ssh. Para atualizar a senha do default user, é necessário
utilizar o módulo set-passwords.
Segue exemplo de configuração dos módulos e etapas:
# The modules that run in the 'init' stage
cloud_init_modules:
- migrator
- seed_random
- bootcmd
- write-files
- growpart
- resizefs
- disk_setup
- mounts
- set_hostname
- update_hostname
- update_etc_hosts
- ca-certs
- rsyslog
- users-groups
- [ssh, always]
# The modules that run in the 'config' stage
cloud_config_modules:
278
# Emit the cloud config ready event
# this can be used by upstart jobs for 'start on cloud-config'.
- emit_upstart
- snap
- ssh-import-id
- locale
- [set-passwords, always]
- grub-dpkg
- apt-pipelining
- apt-configure
- ubuntu-advantage
- ntp
- timezone
- disable-ec2-metadata
- runcmd
- byobu
# The modules that run in the 'final' stage
cloud_final_modules:
- package-update-upgrade-install
- fan
- landscape
- lxd
- ubuntu-drivers
- chef
- reset_rmc
- refresh_rmc_and_interface
- rightscale_userdata
- scripts-per-boot
- ssh-authkey-fingerprints
- keys-to-console
- phone-home
- power-state-change
• Ao executar o módulo ssh, o cloud-init também gerará novas chaves públi-
cas para o host. Caso o usuário salve as fingerprints, ele poderá se deparar
com a seguinte mensagem e não conseguirá conectar, a menos que cor-
rija o problema:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
...
Para evitar a situação, que ocorrerá toda vez que o usuário reiniciar a
VM, é possível adicionar uma configuração no cloud-init para que ele não
gere novas chaves públicas ao executar o módulo ssh. Para isso, deve ser
criado o arquivo 49_hostkeys.cfg no diretório /etc/cloud/cloud.cfg.d/, com
o seguinte conteúdo:
279
ssh_deletekeys: false
• Para uma simples validação das configurações do cloud-init, é possível
desligar a máquina virtual, alterar o nome da mesma no CloudStack e
ligá-la novamente. Assim que iniciada, seu hostname deverá ser o mesmo
que o definido no CloudStack.
• Após validada as configurações, deve-se desligar a máquina virtual e criar
um template a partir do volume, como descrito na seção 2.10. O template
estará com o cloud-init configurado e pronto para ser utilizado.
5.6. Cloud-init no Windows
O cloud-init é uma solução desenvolvida para Linux, no entanto existe um
equivalente para Windows, chamado cloudbase-init. Ele também possui inte-
gração com o CloudStack, com suporte, mas não limitado, à alteração de host-
name, alteração de senha e injeção de chaves SSH.
5.7. Troubleshooting do cloud-init
Caso algum erro ocorra na execução dos módulos do cloud-init, é possível
iniciar o troubleshooting através dos logs escritos nos arquivos /va r/log/cloud-i
nit*.
5.8. Obrigação de troca de senha no primeiro login
Quando o cloud-init injeta a senha para o usuário default, é interessante,
por uma questão de segurança, obrigá-lo a trocá-la no primeiro login.
Para que isso aconteça, é necessário criar um script na VM com o cloud-init
instalado. Basta seguir os seguintes passos:
1. Acesse a VM com o cloud-init;
2. crie o arquivo de script:
sudo touch /var/lib/cloud/scripts/per-instance/reset_password.sh
280
3. adicione o comando do Linux para expirar senhas dentro do arquivo cri-
ado (no lugar de <usuario-padrao> deve ser informado o usuário padrão
da VM):
#!/bin/bash
echo "Expirando a senha do usuário padrão para forçar a troca de senha no primeiro acesso..."
passwd --e <usuario-padrao>
4. altere o acesso do arquivo para que ele se torne um executável:
sudo chmod +x /var/lib/cloud/scripts/per-instance/reset_password.sh
Após esses passos, basta criar um template baseado nessa VM, conforme a
seção 2.10. A partir disso, todas as VM criadas com esse template irão obrigar
o usuário a trocar a senha no primeiro login.
5.9. Auto incremento do tamanho do disco durante o boot
O processo a seguir foi testado pela equipe da SC Clouds com o sistema ope-
racional Ubuntu 20.04 LTS, Cloud.init na versão 21.4, LVM na versão 2.03.07.
Não garantimos o pleno funcionamento para outros sistemas, bibliotecas
e componentes. Utilize essa seção somente como exemplo.
O redimensionamento automático de disco durante o boot é possível atra-
vés de um script que será executado per-boot pelo Cloud.init. Como requisito, é
necessário que a última partição do device seja configurada como um volume
group (VG) e um logical volume (LV) seja configurado dentro desse VG.
1. Acesse a VM com o cloud-init;
2. Crie um arquivo de script:
sudo touch /var/lib/cloud/scripts/per-boot/resizelvm.sh
3. O script a seguir expande o LV com todo o bloco disponível no final do
disco, assumindo que:
(a) O device seja o /dev/vda
(b) A partição que contém o VG seja a 3
(c) O caminho para o LV seja /dev/vg0/lv0
281
#!/bin/bash
DEVICE="/dev/vda"
LVPARTITION="3"
LVPATH="/dev/vg0/lv0"
growpart "$DEVICE" "$LVPARTITION"
pvresize "$DEVICE""$LVPARTITION"
lvextend -l +100%Free "$LVPATH"
resize2fs "$LVPATH"
4. Garanta permissão de execução para esse script:
sudo chmod +x /var/lib/cloud/scripts/per-boot/resizelvm.sh
Com isso, a instância irá verificar se há espaço disponível para expandir o
LVM durante o processo de boot e, caso haja, a expansão será realizada alo-
cando os blocos disponíveis para a partição pre-configurada no script.
5.10. Interação com o user-data
É importante ter em mente a interação do cloud-init com o script de user-
data da VM. O user-data executa após o cloud-init. Sendo assim, caso o cloud-
init defina a senha dos usuários:
chpasswd:
expire: false
users:
- name: ubuntu
password: cloudinit
type: text
- name: teste
password: cloudinit
type: text
E o script de user-data também:
#!/bin/bash
echo "ubuntu:userdata" > senhas
cat senhas | chpasswd
rm senhas
As configurações do cloud-init serão sobrescritas pelo user-data. No exem-
plo, a senha do usuário ubuntu será userdata, e a do usuário teste será cloudi
nit.
282
6. Conclusão
Esse documento abordou, de forma geral, os principais conceitos e dúvidas
recorrentes sobre o Apache CloudStack e ferramentas auxiliares. Ambos são
extensos e complexos, portanto não é possível abordá-los em sua totalidade,
contudo, caso haja dúvidas ou sugestões de melhorias na documentação, pode
ser lançado um issue no GitLab.
283
Apêndices
284
Apêndice A. Terminologia
• Infrastructure-as-a-Service:
Infraestrutura como Serviço, em uma tradução livre, consiste em ofere-
cer recursos computacionais, como processamento, armazenamento e
acesso à redes, sobre demanda, usualmente tendo uma cobrança pelo
tempo de uso desses recursos.
• Hypervisor:
Consiste em um software responsável por criar e executar máquinas vir-
tuais (VMs). Um hypervisor permite que um computador host ofereça su-
porte a várias VMs guest, compartilhando virtualmente seus recursos, como
memória, armazenamento e processamento, permitindo, assim, um me-
lhor uso dos recursos disponíveis.
• VM:
Sigla de Virtual Machine, Máquina Virtual em português, trata-se de um
software que emula um computador real. Também chamada de guest, é
criada em outro computador, chamado de host, e utiliza uma parte dos
recursos do mesmo. As vantagens do uso de VMs são:
– Permite utilizar diferentes sistemas operacionais em um único com-
putador.
– Extremamente fáceis de gerenciar e manter.
– VMs podem ser facilmente criadas ou replicadas com um sistema
operacional já previamente instalado e configurado.
– Fácil migração de uma VM de um host para outro, sem perda de da-
dos.
• Placa de rede virtual:
Comumente referida como NIC, VNIC ou VIF. É um software que cumpre o
papel de uma placa de rede em um sistema virtual.
285
