Introduction
Este documento descreve como usar o CloudCenter para migrar um aplicativo para fazer backup e restaurar o conteúdo para um Amazon S3 Bucket.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Linux
- CloudCenter
- Amazon S3
Componentes Utilizados
As informações neste documento são baseadas no CloudCenter v4.8.1.1.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Informações de Apoio
Este documento pressupõe que o CloudCenter já está instalado e funciona corretamente. Além disso, o WordPress já foi modelado e confirmado para funcionar corretamente. Esse processo só foi testado com o uso de um Balde S3 como repositório e migra de uma implantação para outra entre nuvens públicas, embora deva funcionar entre nuvens públicas e privadas, desde que a conectividade com o Balde S3 seja confirmada na nuvem de destino. Este procedimento só deve ser feito para uma prova de conceito. Ele não utiliza as melhores práticas, pois as chaves secretas são codificadas no script para facilitar o uso. Os scripts especificados foram escritos para CentOS com o uso de um servidor web Apache.
Coletar informações necessárias
O CloudCenter usa alguns scripts para poder fazer backup e restaurar os dados para a VM correta, a fim de preencher os scripts, algumas informações devem ser coletadas antes.
- Nome do Amazonas S3 Bucket
- Caminho no bucket onde os dados de backup são armazenados
- Chave Amazon S3
- Chave secreta do Amazon S3
Note: O bucket S3 também deve ser adicionado como um repositório no CloudCenter.
Baixe e atualize scripts
- Quatro Scripts são necessários para lidar com a migração do WordPress. Dois scripts de backup, um para o banco de dados e outro para o servidor web e dois scripts de restauração.
- Baixe BackupRestore.zip e extraia dele RestoreServer.sh, RestoreDB.sh, BackupDB.sh e BackupServer.sh.
- A partir de cada um, atualize o Bucket, Path, S3 Key, S3 Secret.
- O script de backup para o servidor web zipa o diretório /var/www/ em um arquivo chamado server.zip que está armazenado no diretório /tmp. Em seguida, ele carrega o server.zip no Bucket S3 com as credenciais especificadas.
- O script de restauração para o webserver faz o download do arquivo server.zip e o descompacta no diretório /var/www/. Nenhum desses scripts faz nenhuma verificação de erros, nem verifica o SO instalado, o que pode causar problemas se o WordPress foi instalado em um sistema operacional diferente ou com um servidor Web diferente, diferente do Apache.
- O script de backup para o banco de dados executa um dump de banco de dados (DB) e o zipa para cima antes de carregar no Bucket S3.
- O script de restauração do banco de dados cria o banco de dados e, em seguida, usa o dump do banco de dados que ele baixou do Bucket S3 para recriar o banco de dados.
Note: Esses scripts têm a chave e segredo S3 armazenados em texto simples, isso não é recomendado e deve ser usado apenas como prova de conceito ou no momento do teste inicial.
Depois que todos os campos tiverem sido atualizados, faça o upload dos scripts para um repositório do CloudCenter para que eles possam ser consultados em um perfil de aplicativo.
Atualizar perfil do WordPress
Algumas atualizações do perfil são necessárias para fazer uso desses novos scripts.
No WebServer, selecione Migração e adicione um caminho ao BackupServer.sh no Script de Backup, também consulte o Local de Backup no Local de Backup e, finalmente, adicione o caminho ao RestoreServer.sh no Script de Restauração como mostrado na imagem.
O RestoreServer.sh precisa de permissão para descompactar os arquivos para /var/www/que o cliqruser não tem permissão para fazer. Em Node Initialization & Clean Up, adicione unzip à lista de comandos Sudo. Isso dá ao script a permissão para executar unzip como raiz, como mostrado na imagem.
A camada de banco de dados precisa de alterações semelhantes às do WebServer, ou seja, o script de backup, o local de backup e o script de restauração como mostrado na imagem.
Depois que essas alterações forem feitas, basta salvar o perfil do aplicativo.
Agora, uma nova implantação deve ser capaz de migrar de um nó para outro.