A Biblioteca de Comandos do MCP da Cloudways: Comandos essenciais para servidores e aplicações que vais mesmo usar

O MCP da Cloudways consegue fazer muito mais do que apenas listar servidores e verificar o estado deles.

Assim que estiveres ligado, podes fazer uma cópia de segurança de uma aplicação, reiniciar um serviço, escalar um servidor ou clonar um ambiente inteiro, tudo a partir de um único comando digitado. Este artigo é a referência prática para todo esse leque de funcionalidades e dá continuidade direta ao ponto em que a série começou.

Artigo 1.º comprovámos o conceito com algumas instruções. Este artigo parte daí e aborda o conjunto completo de ferramentas predefinidas: as 65 ferramentas disponíveis assim que te ligas, sem precisares de mudar de conjunto de ferramentas.

Antes de começares

Várias das instruções abaixo alteram algo no teu servidor ou aplicação, não se limitam apenas a apresentar informações. Fazer cópias de segurança, dimensionar, reiniciar e eliminar requerem todas um token de acesso da Cloudways com o âmbito de acesso limitado ou acesso total. Se o teu token for de leitura apenas, estas instruções vão falhar, e isso é um comportamento esperado, não um bug.

Se te ligaste usando um token de «Apenas Leitura» do Artigo 1, cria um novo antes de tentares seguir as instruções que te damos aqui.

Com isso em mente, começa por onde qualquer sessão de resolução de problemas deve começar: ver o que tens realmente.

Ver o que tens (Visibilidade do servidor e da aplicação)

Antes de alterares alguma coisa, tem de saber com o que estás a lidar.

Toda a tua frota num relance

“Mostra-me todos os meus servidores em funcionamento” chama o server_list ferramenta. Mostra todos os servidores da tua conta, com o respetivo estado, fornecedor de serviços na nuvem, região, endereço IP e o número de aplicações que estão a ser alojadas.

Para uma agência, esta única instrução substitui o processo de iniciar sessão na conta e percorrer a página da lista de servidores para cada cliente.

A IA também trata da filtragem natural sem precisar de uma ferramenta separada para isso.

Experimenta “mostra-me só os servidores alojados na DigitalOcean“, e isso vai restringir a mesma lista de servidores resultado que corresponda. Não precisas de saber se existe um parâmetro de filtro. Basta descreveres o que queres.

Há um pormenor na resposta que é fácil deixar passar: o número de aplicações por servidor. Se um servidor estiver a alojar muito mais aplicações do que os outros, isso costuma ser o primeiro sinal de que está a suportar mais carga do que devia, muito antes de conseguires perceber isso num gráfico de utilização.

Um olhar mais atento a uma aplicação

Assim que souberes qual é o servidor que te interessa, «mostra detalhes do servidor [ID]” chama server_get. Mostra a configuração completa desse servidor e de todas as aplicações que estão alojadas nele. Esta é a resposta certa quando um cliente pergunta «o que é que está mesmo a funcionar no meu servidor», já que responde diretamente à pergunta, em vez de te obrigar a comparar duas janelas.

Para aprofundar um pouco mais, «mostrar detalhes da minha aplicação WordPress» chama a função app_get, que devolve a configuração dessa aplicação específica.

Se um servidor tiver mais do que uma aplicação e não souberes a qual te estás a referir, começa por «listar todas as aplicações no servidor [ID]“, que chama a função app_list. A maioria das ferramentas ao nível da aplicação precisa que se identifique uma aplicação específica, e não basta apenas supor qual é, por isso vale a pena executar isto primeiro sempre que não tiveres a certeza.

É também aqui que as instruções vagas costumam dar errado. Se tiveres três sites de clientes num único servidor e disseres «verifica a minha aplicação», a IA não tem como saber a qual te estás a referir. Nomeá-la explicitamente, tipo «o meu site de teste para o Cliente X», evita completamente essa ambiguidade.

Cópias de segurança: protege-te antes de tocares em nada

As próximas secções vão guiar-te passo a passo pelas alterações: reiniciar serviços, dimensionar servidores, clonar aplicações. Antes de mais nada, cria o hábito que deve vir em primeiro lugar: faz uma cópia de segurança.

Faz uma cópia de segurança antes de mexeres em qualquer coisa

“Fazer um backup da minha aplicação de produção antes de enviar as alterações” chamadas app_backup. Isso cria uma cópia de segurança de um momento específico dessa aplicação.

Para qualquer alteração que vá além de uma simples alteração numa aplicação, «faz uma cópia de segurança completa do servidor [ID]” chama server_backup, que faz uma cópia de segurança de todas as aplicações nesse servidor de uma só vez. Esta é a decisão certa antes de uma alteração ao nível do servidor, como o dimensionamento ou a atualização de um pacote, já que protege tudo o que está na máquina, e não só um site.

Faz disso um hábito, em vez de algo pontual. Cada sugestão no operações do dia-a-dia“Os exemplos do Artigo 1.º ficam mais seguros se aparecer primeiro um aviso de segurança. Custa só mais uma frase, e é a diferença entre um erro ser apenas chato e um erro que te faz perder um cliente.

Verificar o progresso e restaurar

As cópias de segurança, tal como a maioria das outras ações que demoram algum tempo, são executadas em segundo plano. “O meu backup já acabou?” chamadas operation_status, e funciona para qualquer operação assíncrona, não só para backups. O mesmo padrão de mensagem verifica se está a decorrer um clone, uma expansão ou uma restauração. Não precisas de uma mensagem diferente para cada uma delas.

Se algo correr mal, «restaura a minha app para o último backup” chama a função app_restore. Como tenho uma aplicação do WordPress no meu servidor, posso ser mais específico e perguntar: «restaurar a minha aplicação do WordPress a partir do último backup”.

E se a restauração em si acabar por ser uma má decisão, «desfaz essa restauração“, chama a função app_restore_rollback. Este é um pormenor que a maioria dos leitores nem sabe que existe até precisar dele num momento de pânico, e vale a pena lembrares-te disso agora, antes que esse momento chegue.

Manter tudo a funcionar (controlo de serviços)

Verificar a saúde

“Todos os serviços estão a funcionar bem no meu servidor de produção?” chamadas service_status, que te dá informações sobre o NGINX, o MySQL, o PHP-FPM e tudo o que estiver a funcionar, tudo numa única chamada.

Executa isto primeiro quando algo te parecer estranho, mas ainda não souberes onde procurar, antes de consultares um gráfico de monitorização.

Vale a pena esclarecer em que é que isto difere de server_get, já que a diferença não é óbvia só pelos nomes das ferramentas. O `server_get` diz-te o que está configurado. service_status mostra-te o que está a funcionar neste momento e se está tudo bem. Um é um plano, o outro é uma verificação do estado atual.

Reiniciar sem passar pelo painel de controlo

“Reinicia o PHP-FPM no servidor [ID]” chamadas service_state_update, que aceita start, stop ou restart como ação.

Essa mesma ferramenta também gere outros serviços. “Reinicia o MySQL no servidor [ID]“usa a mesma ferramenta, só que para um serviço diferente. Não precisas de memorizar um comando diferente para cada um.”

Reiniciar um serviço em produção interrompe momentaneamente tudo o que depende dele. Isso é um pequeno inconveniente para a maioria dos serviços, mas pensa bem antes de reiniciar uma base de dados de produção a meio do dia, porque a interrupção afeta todas as aplicações que dependem dela.

Camadas de cache

“Limpar todas as caches do meu blogue WordPress” chama app_purge_cache, que limpa o cache da aplicação, o Varnish e o cache de objetos de uma só vez.

Se precisares de mais controlo sobre o Varnish em particular, «ativa o Varnish para esta aplicação” chama varnish_app_manage ao nível da aplicação, enquanto o equivalente a nível do servidor é varnish_manage. Se estiveres a gerir várias aplicações num único servidor, é importante saberes em que camada estás realmente a fazer a alteração, já que a versão ao nível da aplicação afeta apenas aquele site, enquanto a versão ao nível do servidor afeta tudo o que está nesse servidor.

Esta é a solução direta para uma situação que provavelmente já viveste: um cliente diz «as minhas alterações não estão a aparecer» e, em nove de cada dez vezes, limpar a cache resolve o problema.

Dimensionamento e expansão dos teus servidores

Alterar a capacidade

“Aumenta a memória do meu servidor para 4 GB de RAM” chama server_scale. O processo de escalabilidade causa um breve período de inatividade. Isso representa um custo real, que vale a pena ter em conta antes de enviares o prompt, especialmente num servidor de produção durante o horário de expediente.

O armazenamento funciona de forma diferente consoante o teu fornecedor de serviços na nuvem, e esta é uma área em que, se cometeres um erro, simplesmente não se nota nada. “Redimensionar o volume de armazenamento no servidor [ID]” chamam server_scale_volume se o teu servidor estiver na AWS ou no GCE, ou server_storage_scale se estiver a funcionar no DigitalOcean Block Storage. Se o comando para redimensionar o armazenamento não funcionar, a primeira coisa a verificar é qual é o fornecedor em que o teu servidor está realmente alojado, já que pedir a ferramenta errada ao fornecedor errado não vai funcionar de todo.

Criar e remover infraestrutura

“Cria um servidor DigitalOcean de 2 GB em Nova Iorque chamado testServer2 com uma aplicação WordPress chamada testWPApp2” chama server_create, que configura o servidor e pré-instala a aplicação num único passo. Para uma agência, isto transforma um processo de configuração em várias etapas numa única ação, o que é fundamental durante a integração do cliente.

“Apaga o servidor antigo que já não uso” chamadas server_delete. Isto é definitivo. Vai eliminar o servidor e todas as aplicações que nele estão alojadas, sem possibilidade de voltar atrás.

A advertência do Artigo 1.º continua a aplicar-se aqui, mas vale a pena transformá-la num hábito de verdade, em vez de ser só um aviso que lês uma vez e depois esqueces. Antes de enviar um comando de eliminação, executa o comando «list server IDs», que lista todos os IDs dos servidores. Deves sempre confirmar o ID do servidor antes de executares qualquer outro comando, para teres a certeza de que não estás a eliminar ou a alterar um servidor que não pretendias. “

Clonagem para ganhar velocidade

“Clona o servidor [ID] para criar uma versão de teste” chama app_clone, e clona a aplicação no mesmo servidor. “Clonar a minha aplicação do servidor A para o servidor B” chama app_clone_to_server , transferindo o clone para um servidor completamente diferente.

Na prática, essa distinção é importante. A clonagem no mesmo servidor é rápida e barata, e é o que precisas para testes rápidos. A clonagem entre servidores é a forma como as agências migram um cliente para um servidor maior ou diferente sem ter de desligar o site durante o processo.

Se estiveres a duplicar um ambiente inteiro, em vez de apenas uma aplicação, «clona o servidor [ID] para um novo servidor com as mesmas aplicações” chama server_clone. Isto é útil para agências que mantêm um ambiente de modelos e querem criar a mesma configuração para um novo cliente sem terem de a reconstruir do zero.

Descobrir o que se passa (Monitorização e resolução de problemas)

Utilização de recursos

“Mostrar a utilização da CPU do meu servidor nas últimas 24 horas para o servidor [ID]” chamadas monitoring_server_graph. Não se limita à CPU. A mesma ferramenta abrange também a memória e outras métricas, e aceita qualquer intervalo de tempo que lhe definires. “Mostrar a utilização da memória nos últimos 7 dias” funciona exatamente da mesma forma. Também podes combinar os dois parâmetros numa única instrução

Para uma verificação mais abrangente, «quanta largura de banda e espaço em disco é que já usei?” chama monitoring_server_summary. Esta é a orientação a que deves recorrer quando um cliente perguntar sobre os limites de utilização, ou quando estiveres a decidir se já é mesmo altura de expandir.

Padrões de tráfego

“Mostrar os principais endereços IP que visitaram a minha loja na última hora” chama analytics_app_traffic. Esta é a resposta direta ao cenário de comércio eletrónico do Artigo 1: distinguir um pico de vendas real de um ataque de bots, usando dados reais de tráfego em vez de adivinhar.

Para uma visão mais abrangente, «mostra-me o tráfego dos últimos 30 dias, dividido por dia” chama analytics_app_traffic_details. Usa esta opção quando quiseres analisar uma tendência ao longo do tempo e usa a opção mais simples de tráfego quando estiveres a avaliar algo que está a acontecer neste preciso momento.

Páginas e consultas lentas

“Quais são as páginas PHP mais lentas na minha aplicação?” chama analytics_app_php. “Mostrar as consultas lentas do MySQL da minha aplicação“chamadas analytics_app_mysql. Ambas apontam diretamente para o verdadeiro gargalo, em vez de te deixar a adivinhar se o problema está no teu código ou na tua base de dados.

Da mesma forma, «como estão a correr as minhas tarefas cron?” chama analytics_app_cron. As tarefas Cron que falham sem dar sinal, seja um backup que não foi feito ou um e-mail agendado que não foi enviado, estão entre os problemas invisíveis mais comuns na hospedagem web, e este aviso revela-os sem teres de vasculhar os registos.

Noções básicas de segurança: Detetar problemas logo no início

Análise de vulnerabilidades

“Verifica o meu site do WordPress em busca de vulnerabilidades“não chama apenas uma ferramenta. Encha duas: app_vulnerabilities_refresh inicia uma nova verificação, e app_vulnerabilities_list recupera os resultados assim que terminar. É o mesmo comportamento de encadeamento que apresentámos no Artigo 1, agora com um exemplo concreto. Nem precisas de saber que são duas chamadas separadas. Recebes simplesmente os resultados.

Complementos: Ativar e desativar funcionalidades

O que está disponível

“Que complementos tenho à minha disposição?” chamadas addon_list, mostrando o estado e os preços de tudo o que podes ativar. Vale a pena fazeres isto antes de recomendares um complemento pago a um cliente, para que possas indicar o preço com precisão, em vez de teres de adivinhar.

 

Ativar e remover

“Ativar [complemento] no servidor [ID]” chamadas addon_activate_on_server, com o âmbito limitado a esse servidor específico.

Desligar algo requer mais cuidado. “Desativa o [complemento]” chama addon_deactivate ao nível da conta, enquanto addon_deactivate_on_server aplica a mesma ação a um servidor. Se escolheres a versão para toda a conta quando querias a específica do servidor, isso pode afetar servidores que não pretendias alterar.

Algumas regras que se aplicam a todas as categorias

Os comandos só de leitura, ou seja, tudo o que lista, obtém, verifica o estado ou resume, são sempre seguros para explorares à vontade. Experimenta variações para além dos exemplos exatos acima. Aqui, não há nada que se possa estragar só por fazeres uma pergunta.

Tudo o que altera o estado merece uma segunda olhadela antes de o enviares. Isso inclui o dimensionamento, o reinício, a eliminação e a clonagem. Duas ferramentas mencionadas neste artigo são, de longe, as que envolvem os maiores riscos: server_delete e app_delete. Ambas são permanentes e nenhuma delas requer uma etapa de confirmação além daquela que tu próprio fazes.

A especificidade ganha sempre à concisão. Compara « verifica o meu servidor” contra “mostra o uso da CPU e da memória do servidor 12345 nos últimos 7 dias.” A segunda opção dá-te uma resposta precisa e útil logo à primeira tentativa. A primeira deixa a IA a tentar adivinhar qual o servidor, qual a métrica e qual o intervalo de tempo a que te referias realmente.

Transformar a gestão da frota de servidores numa conversa natural

O MCP da Cloudways transforma radicalmente a forma como os programadores e as agências gerem a infraestrutura de alojamento. Ao disponibilizar 65 ferramentas essenciais diretamente através da linguagem natural, o MCP elimina o incómodo de ter de navegar por painéis com várias etapas, cruzar informações entre ecrãs de servidor e memorizar a sintaxe da CLI.

Quer estejas a fazer verificações de rotina, a dimensionar recursos durante picos de tráfego ou a identificar pontos de estrangulamento no desempenho de consultas lentas à base de dados, o fluxo de trabalho resume-se a um único princípio: sê específico, protege as alterações no estado do servidor/aplicação com cópias de segurançae descreve o que precisas. À medida que vais integrando estas sugestões nas tuas operações diárias, o Cloudways MCP transforma a gestão complexa de servidores num processo simples e intuitivo, poupando tempo, reduzindo os erros humanos e mantendo o teu foco onde deve estar: na criação e expansão das tuas aplicações.

E o mesmo lembrete do Artigo 1.º continua a aplicar-se aqui: se quiseres algo que ainda não esteja listado em lado nenhum, pergunta diretamente. A funcionalidade «O que podes fazer com a minha conta Cloudways» apresenta essa informação através do mesmo mecanismo de descoberta de conjuntos de ferramentas que está na base de todas as operações do MCP da Cloudways.