Si administras muchos sitios de WordPress, probablemente siempre estés buscando formas de simplificar y acelerar tus flujos de trabajo.
Ahora, imagina esto: con un solo comando en tu terminal, puedes activar copias de seguridad manuales para todos tus sitios, incluso si gestionas docenas de ellos. Ese es el poder de combinar scripts de shell con la API de Kinsta.
Esta guía te enseña a utilizar scripts de shell para configurar comandos personalizados que hagan más eficiente la gestión de tus sitios.
Requisitos previos
Antes de empezar, esto es lo que necesitas:
- Un terminal: Todos los sistemas operativos modernos vienen con software de terminal, por lo que puedes empezar a crear scripts desde el primer momento.
- Un IDE o editor de texto: Utiliza una herramienta con la que te sientas cómodo, ya sea VS Code, Sublime Text o incluso un editor sencillo como Nano para ediciones rápidas en el terminal.
- Una clave API de Kinsta: Es esencial para interactuar con la API de Kinsta. Para generar la tuya:
- Accede a tu panel MyKinsta.
- Ve a Tu nombre > Configuración de la empresa > Claves API.
- Haz clic en Crear Clave API y guárdala de forma segura.
curlyjq: Imprescindibles para hacer peticiones a la API y manejar datos JSON. Comprueba que están instalados, o instálalos.- Familiaridad básica con la programación: No necesitas ser un experto, pero te será útil comprender los fundamentos de la programación y la sintaxis de los scripts de shell.
Escribir tu primer script
Crear tu primer script de shell para interactuar con la API de Kinsta es más sencillo de lo que imaginas. Empecemos con un sencillo script que enumere todos los sitios de WordPress administrados bajo tu cuenta de Kinsta.
Paso 1: Configura tu entorno
Empieza creando una carpeta para tu proyecto y un nuevo archivo de script. La extensión .sh se utiliza para los scripts de shell. Por ejemplo, puedes crear una carpeta, navegar hasta ella, y crear y abrir un archivo de script en VS Code utilizando estos comandos:
mkdir my-first-shell-scripts
cd my-first-shell-scripts
touch script.sh
code script.shPaso 2: Define tus variables de entorno
Para mantener segura tu clave API, guárdala en un archivo .env en lugar de codificarla en el script. Esto te permite añadir el archivo .env a .gitignore, evitando que se envíe al control de versiones.
En tu archivo .env, añade:
API_KEY=your_kinsta_api_keyA continuación, añade la clave API del archivo .env a tu script añadiendo lo siguiente en la parte superior de tu script:
#!/bin/bash
source .envEl comando#!/bin/bash garantiza que el script se ejecute utilizando Bash, mientras que source .env importa las variables de entorno.
Paso 3: Escribe la solicitud de API
En primer lugar, guarda el ID de tu empresa (que encontrarás en MyKinsta en Configuración de la empresa > Detalles de facturación) en una variable:
COMPANY_ID="<your_company_id>"A continuación, añade el comando curl para realizar una solicitud GET al endpoint /sites, pasando el ID de la empresa como parámetro de consulta. Utiliza jq para dar formato a la salida para que sea legible:
curl -s -X GET
"https://api.kinsta.com/v2/sites?company=$COMPANY_ID"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json" | jqEsta petición recupera detalles sobre todos los sitios asociados a tu empresa, incluidos sus ID, nombres y estados.
Paso 4: Haz ejecutable el script
Guarda el script y hazlo ejecutable iniciando:
chmod +x script.shPaso 5: Ejecuta el script
Ejecuta el script para ver una lista formateada de tus sitios:
./list_sites.shCuando ejecutes el script, obtendrás una respuesta similar a ésta:
{
"company": {
"sites": [
{
"id": "a8f39e7e-d9cf-4bb4-9006-ddeda7d8b3af",
"name": "bitbuckettest",
"display_name": "bitbucket-test",
"status": "live",
"site_labels": []
},
{
"id": "277b92f8-4014-45f7-a4d6-caba8f9f153f",
"name": "duketest",
"display_name": "zivas Signature",
"status": "live",
"site_labels": []
}
]
}
}Aunque esto funciona, vamos a mejorarlo configurando una función para recuperar y formatear los detalles del sitio para facilitar la lectura.
Paso 6: Refactorizar con una función
Sustituye la solicitud curl por una función reutilizable que se encargue de obtener y formatear la lista de sitios:
list_sites() {
echo "Fetching all sites for company ID: $COMPANY_ID..."
RESPONSE=$(curl -s -X GET "https://api.kinsta.com/v2/sites?company=$COMPANY_ID"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json")
# Check for errors
if [ -z "$RESPONSE" ]; then
echo "Error: No response from the API."
exit 1
fi
echo "Company Sites:"
echo "--------------"
echo "$RESPONSE" | jq -r '.company.sites[] | "(.display_name) ((.name)) - Status: (.status)"'
}
# Run the function
list_sitesCuando vuelvas a ejecutar el script, obtendrás una salida con un formato ordenado:
Fetching all sites for company ID: b383b4c-****-****-a47f-83999c5d2...
Company Sites:
--------------
bitbucket-test (bitbuckettest) - Status: live
zivas Signature (duketest) - Status: liveCon este script, habrás dado tu primer paso hacia el uso de scripts de shell y la API de Kinsta para automatizar la gestión del sitio de WordPress. En las siguientes secciones, exploraremos la creación de scripts más avanzados para interactuar con la API de forma potente.
Caso de uso avanzado 1: Crear copias de seguridad
Crear copias de seguridad es un aspecto crucial de la gestión de un sitio web. Te permiten restaurar tu sitio en caso de problemas imprevistos. Con la API de Kinsta y los scripts de shell, este proceso puede automatizarse, ahorrando tiempo y esfuerzo.
En esta sección, creamos copias de seguridad y nos ocupamos del límite de Kinsta de cinco copias de seguridad manuales por entorno. Para ello, implementaremos un proceso para:
- Comprobar el número actual de copias de seguridad manuales.
- Identificar y eliminar la copia de seguridad más antigua (con confirmación del usuario) si se alcanza el límite.
- Proceder a crear una nueva copia de seguridad.
Vamos a entrar en detalles.
El flujo de trabajo de las copias de seguridad
Para crear copias de seguridad utilizando la API de Kinsta, utilizarás el siguiente endpoint:
POST /sites/environments/{env_id}/manual-backupsEsto requiere:
- ID del entorno: Identifica el entorno (como staging o producción) donde se creará la copia de seguridad.
- Etiqueta de copia de seguridad: Una etiqueta para identificar la copia de seguridad (opcional).
Recuperar manualmente el ID del entorno y ejecutar un comando como backup <environment ID> puede ser engorroso. En su lugar, crearemos un script fácil de usar en el que simplemente especifiques el nombre del sitio, y el script lo hará:
- Obtendrá la lista de entornos del sitio.
- Te pedirá que elijas el entorno del que quieres hacer una copia de seguridad.
- Se encargará del proceso de creación de la copia de seguridad.
Funciones reutilizables para un código limpio
Para mantener nuestro script modular y reutilizable, definiremos funciones para tareas específicas. Repasemos la configuración paso a paso.
1. Configurar variables base
Puedes prescindir del primer script que creaste o crear un nuevo archivo de script para esto. Empieza declarando la URL base de la API Kinsta y el ID de tu empresa en el script:
BASE_URL="https://api.kinsta.com/v2"
COMPANY_ID="<your_company_id>"Estas variables te permiten construir endpoints de la API de forma dinámica a lo largo del script.
2. Obtener todos los sitios
Define una función para obtener la lista de todos los sitios de la empresa. Esto te permite recuperar detalles sobre cada sitio más adelante.
get_sites_list() {
API_URL="$BASE_URL/sites?company=$COMPANY_ID"
echo "Fetching all sites for company ID: $COMPANY_ID..."
RESPONSE=$(curl -s -X GET "$API_URL"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json")
# Check for errors
if [ -z "$RESPONSE" ]; then
echo "Error: No response from the API."
exit 1
fi
echo "$RESPONSE"
}Verás que esta función devuelve una respuesta sin formato de la API. Para obtener una respuesta formateada. Puedes añadir otra función que se encargue de ello (aunque no es lo que nos ocupa en esta sección):
list_sites() {
RESPONSE=$(get_sites_list)
if [ -z "$RESPONSE" ]; then
echo "Error: No response from the API while fetching sites."
exit 1
fi
echo "Company Sites:"
echo "--------------"
# Clean the RESPONSE before passing it to jq
CLEAN_RESPONSE=$(echo "$RESPONSE" | tr -d 'r' | sed 's/^[^{]*//') # Removes extra characters before the JSON starts
echo "$CLEAN_RESPONSE" | jq -r '.company.sites[] | "(.display_name) ((.name)) - Status: (.status)"'
}Al llamar a la función list_sites se muestran tus sitios como se ha mostrado anteriormente. El objetivo principal, sin embargo, es acceder a cada sitio y a su ID, lo que te permitirá recuperar información detallada sobre cada sitio.
3. Obtener detalles de un sitio
Para obtener detalles sobre un sitio concreto, utiliza la siguiente función, que recupera el ID del sitio basándose en el nombre del sitio y obtiene detalles adicionales, como los entornos:
get_site_details_by_name() {
SITE_NAME=$1
if [ -z "$SITE_NAME" ]; then
echo "Error: No site name provided. Usage: $0 details-name "
return 1
fi
RESPONSE=$(get_sites_list)
echo "Searching for site with name: $SITE_NAME..."
# Clean the RESPONSE before parsing
CLEAN_RESPONSE=$(echo "$RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')
# Extract the site ID for the given site name
SITE_ID=$(echo "$CLEAN_RESPONSE" | jq -r --arg SITE_NAME "$SITE_NAME" '.company.sites[] | select(.name == $SITE_NAME) | .id')
if [ -z "$SITE_ID" ]; then
echo "Error: Site with name "$SITE_NAME" not found."
return 1
fi
echo "Found site ID: $SITE_ID for site name: $SITE_NAME"
# Fetch site details using the site ID
API_URL="$BASE_URL/sites/$SITE_ID"
SITE_RESPONSE=$(curl -s -X GET "$API_URL"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json")
echo "$SITE_RESPONSE"
}La función anterior filtra el sitio utilizando el nombre del sitio y luego recupera detalles adicionales sobre el sitio utilizando el endpoint /sites/<site-id>. Estos detalles incluyen los entornos del sitio, que es lo que necesitamos para activar las copias de seguridad.
Crear copias de seguridad
Ahora que has configurado funciones reutilizables para obtener detalles del sitio y listar entornos, puedes centrarte en automatizar el proceso de creación de copias de seguridad. El objetivo es ejecutar un comando sencillo con sólo el nombre del sitio y luego elegir interactivamente el entorno del que hacer la copia de seguridad.
Empieza creando una función (la llamaremos trigger_manual_backup). Dentro de la función, define dos variables: la primera para aceptar el nombre del sitio como entrada y la segunda para establecer una etiqueta por defecto (default-backup) para la copia de seguridad. Esta etiqueta por defecto se aplicará a menos que decidas especificar una etiqueta personalizada más adelante.
trigger_manual_backup() {
SITE_NAME=$1
DEFAULT_TAG="default-backup"
# Ensure a site name is provided
if [ -z "$SITE_NAME" ]; then
echo "Error: Site name is required."
echo "Usage: $0 trigger-backup "
return 1
fi
# Add the code here
}Este SITE_NAME es el identificador del sitio que quieres gestionar. También estableces una condición para que el script salga con un mensaje de error si no se proporciona el identificador. Esto garantiza que el script no proceda sin la información necesaria, evitando posibles errores de la API.
A continuación, utiliza la función reutilizable get_site_details_by_name para obtener información detallada sobre el sitio, incluidos sus entornos. Acto seguido, se limpia la respuesta para eliminar cualquier problema de formato inesperado que pueda surgir durante el procesamiento.
SITE_RESPONSE=$(get_site_details_by_name "$SITE_NAME")
if [ $? -ne 0 ]; then
echo "Error: Failed to fetch site details for site "$SITE_NAME"."
return 1
fi
CLEAN_RESPONSE=$(echo "$SITE_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')Una vez que tenemos los detalles del sitio, el script que aparece a continuación extrae todos los entornos disponibles y los muestra en un formato legible. Esto te ayuda a visualizar qué entornos están vinculados al sitio.
A continuación, el script te pide que selecciones un entorno por su nombre. Este paso interactivo facilita el proceso al eliminar la necesidad de recordar o introducir los ID de los entornos.
ENVIRONMENTS=$(echo "$CLEAN_RESPONSE" | jq -r '.site.environments[] | "(.name): (.id)"')
echo "Available Environments for "$SITE_NAME":"
echo "$ENVIRONMENTS"
read -p "Enter the environment name to back up (e.g., staging, live): " ENV_NAMEEl nombre del entorno seleccionado se utiliza para buscar su ID de entorno correspondiente en los detalles del sitio. Este ID es necesario para las solicitudes de API para crear una copia de seguridad.
ENV_ID=$(echo "$CLEAN_RESPONSE" | jq -r --arg ENV_NAME "$ENV_NAME" '.site.environments[] | select(.name == $ENV_NAME) | .id')
if [ -z "$ENV_ID" ]; then
echo "Error: Environment "$ENV_NAME" not found for site "$SITE_NAME"."
return 1
fi
echo "Found environment ID: $ENV_ID for environment name: $ENV_NAME"En el código anterior, se crea una condición para que el script salga con un mensaje de error si no coincide el nombre de entorno proporcionado.
Ahora que tienes el ID del entorno, puedes proceder a comprobar el número actual de copias de seguridad manuales para el entorno seleccionado. El límite de Kinsta de cinco copias de seguridad manuales por entorno significa que este paso es crucial para evitar errores.
Empecemos por obtener la lista de copias de seguridad utilizando el endpoint /backups de la API.
API_URL="$BASE_URL/sites/environments/$ENV_ID/backups"
BACKUPS_RESPONSE=$(curl -s -X GET "$API_URL"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json")
CLEAN_RESPONSE=$(echo "$BACKUPS_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')
MANUAL_BACKUPS=$(echo "$CLEAN_RESPONSE" | jq '[.environment.backups[] | select(.type == "manual")]')
BACKUP_COUNT=$(echo "$MANUAL_BACKUPS" | jq 'length')A continuación, el script anterior filtra las copias de seguridad manuales y las cuenta. Si el recuento alcanza el límite, tenemos que gestionar las copias de seguridad existentes:
if [ "$BACKUP_COUNT" -ge 5 ]; then
echo "Manual backup limit reached (5 backups)."
# Find the oldest backup
OLDEST_BACKUP=$(echo "$MANUAL_BACKUPS" | jq -r 'sort_by(.created_at) | .[0]')
OLDEST_BACKUP_NAME=$(echo "$OLDEST_BACKUP" | jq -r '.note')
OLDEST_BACKUP_ID=$(echo "$OLDEST_BACKUP" | jq -r '.id')
echo "The oldest manual backup is "$OLDEST_BACKUP_NAME"."
read -p "Do you want to delete this backup to create a new one? (yes/no): " CONFIRM
if [ "$CONFIRM" != "yes" ]; then
echo "Aborting backup creation."
return 1
fi
# Delete the oldest backup
DELETE_URL="$BASE_URL/sites/environments/backups/$OLDEST_BACKUP_ID"
DELETE_RESPONSE=$(curl -s -X DELETE "$DELETE_URL"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json")
echo "Delete Response:"
echo "$DELETE_RESPONSE" | jq -r '[
"Operation ID: (.operation_id)",
"Message: (.message)",
"Status: (.status)"
] | join("n")'
fiLa condición anterior identifica la copia de seguridad más antigua ordenando la lista en función de la marca de tiempo created_at. A continuación, te pide que confirmes si deseas eliminarla.
Si aceptas, el script elimina la copia de seguridad más antigua utilizando su ID, liberando espacio para la nueva. Esto garantiza que siempre se puedan crear copias de seguridad sin tener que gestionar manualmente los límites.
Ahora que hay espacio, procedamos con el código para activar la copia de seguridad del entorno. Puedes omitir este código, pero para una mejor experiencia, te pide que especifiques una etiqueta personalizada, que por defecto es «default-backup» si no se proporciona ninguna.
read -p "Enter a backup tag (or press Enter to use "$DEFAULT_TAG"): " BACKUP_TAG
if [ -z "$BACKUP_TAG" ]; then
BACKUP_TAG="$DEFAULT_TAG"
fi
echo "Using backup tag: $BACKUP_TAG"Por último, el script que aparece a continuación es donde tiene lugar la acción de copia de seguridad. Envía una solicitud POST al endpoint /manual-backups con el ID de entorno y la etiqueta de copia de seguridad seleccionados. Si la solicitud tiene éxito, la API devuelve una respuesta confirmando la creación de la copia de seguridad.
API_URL="$BASE_URL/sites/environments/$ENV_ID/manual-backups"
RESPONSE=$(curl -s -X POST "$API_URL"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json"
-d "{"tag": "$BACKUP_TAG"}")
if [ -z "$RESPONSE" ]; then
echo "Error: No response from the API while triggering the manual backup."
return 1
fi
echo "Backup Trigger Response:"
echo "$RESPONSE" | jq -r '[
"Operation ID: (.operation_id)",
"Message: (.message)",
"Status: (.status)"
] | join("n")'Ya está. La respuesta obtenida de la solicitud anterior está formateada para mostrar el ID de la operación, el mensaje y el estado para mayor claridad. Si llamas a la función y ejecutas el script, verás una salida similar a ésta:
Available Environments for "example-site":
staging: 12345
live: 67890
Enter the environment name to back up (e.g., staging, live): live
Found environment ID: 67890 for environment name: live
Manual backup limit reached (5 backups).
The oldest manual backup is "staging-backup-2023-12-31".
Do you want to delete this backup to create a new one? (yes/no): yes
Oldest backup deleted.
Enter a backup tag (or press Enter to use "default-backup"): weekly-live-backup
Using backup tag: weekly-live-backup
Triggering manual backup for environment ID: 67890 with tag: weekly-live-backup...
Backup Trigger Response:
Operation ID: backups:add-manual-abc123
Message: Adding a manual backup to environment in progress.
Status: 202Crear comandos para tu script
Los comandos simplifican el uso de tu script. En lugar de editar el script o comentar el código manualmente, los usuarios pueden ejecutarlo con un comando específico como:
./script.sh list-sites
./script.sh backup Al final de tu script (aparte de todas las funciones), incluye un bloque condicional que compruebe los argumentos pasados al script:
if [ "$1" == "list-sites" ]; then
list_sites
elif [ "$1" == "backup" ]; then
SITE_NAME="$2"
if [ -z "$SITE_NAME" ]; then
echo "Usage: $0 trigger-backup "
exit 1
fi
trigger_manual_backup "$SITE_NAME"
else
echo "Usage: $0 {list-sites|trigger-backup }"
exit 1
fiLa variable $1 representa el primer argumento pasado al script (por ejemplo, en ./script.sh list-sites, $1 es list-sites). El script utiliza comprobaciones condicionales para hacer coincidir $1 con comandos específicos como list-sites o backup. Si el comando es backup, también espera un segundo argumento ($2), que es el nombre del sitio. Si no se proporciona un comando válido, el script muestra por defecto las instrucciones de uso.
Ahora puedes activar una copia de seguridad manual para un sitio concreto ejecutando el comando
./script.sh backupCaso de uso avanzado 2: Actualizar plugins en varios sitios
Gestionar los plugins de WordPress en varios sitios puede ser tedioso, sobre todo cuando hay actualizaciones disponibles. Kinsta hace un gran trabajo gestionando esto a través del panel de control MyKinsta, mediante la funcionalidad de acciones en lote que introdujimos el año pasado.
Pero si no te gusta trabajar con interfaces de usuario, la API de Kinsta te ofrece otra oportunidad de crear un script shell para automatizar el proceso de identificar plugins obsoletos y actualizarlos en múltiples sitios o entornos específicos.
Desglosando el flujo de trabajo
1. Identifica los sitios con plugins obsoletos: El script itera a través de todos los sitios y entornos, buscando el plugin especificado con una actualización disponible. El siguiente endpoint se utiliza para obtener la lista de plugins de un entorno de sitio específico:
GET /sites/environments/{env_id}/pluginsA partir de la respuesta, filtramos los plugins donde "update": "available".
2. Pregunta al usuario las opciones de actualización: Muestra los sitios y entornos con el plugin desactualizado, permitiendo al usuario seleccionar instancias específicas o actualizarlas todas.
3. Activa la actualización del plugin: Para actualizar el plugin en un entorno específico, el script utiliza este endpoint:
PUT /sites/environments/{env_id}/pluginsEl nombre del plugin y su versión actualizada se pasan en el cuerpo de la petición.
El script
Como el script es largo, la función completa está alojada en GitHub para facilitar el acceso. Aquí explicaremos la lógica central utilizada para identificar los plugins obsoletos en múltiples sitios y entornos.
El script comienza aceptando el nombre del plugin desde el comando. Este nombre especifica el plugin que quieres actualizar.
PLUGIN_NAME=$1
if [ -z "$PLUGIN_NAME" ]; then
echo "Error: Plugin name is required."
echo "Usage: $0 update-plugin "
return 1
fiA continuación, el script utiliza la función reutilizable get_sites_list (explicada anteriormente) para obtener todos los sitios de la empresa:
echo "Fetching all sites in the company..."
# Fetch all sites in the company
SITES_RESPONSE=$(get_sites_list)
if [ $? -ne 0 ]; then
echo "Error: Failed to fetch sites."
return 1
fi
# Clean the response
CLEAN_SITES_RESPONSE=$(echo "$SITES_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')A continuación viene la parte central del script: recorrer la lista de sitios para comprobar si hay plugins obsoletos. El CLEAN_SITES_RESPONSE, que es un objeto JSON que contiene todos los sitios, se pasa a un bucle while para realizar las operaciones de cada sitio uno por uno.
Comienza extrayendo algunos datos importantes como el ID del sitio, el nombre y el nombre para mostrar en variables:
while IFS= read -r SITE; do
SITE_ID=$(echo "$SITE" | jq -r '.id')
SITE_NAME=$(echo "$SITE" | jq -r '.name')
SITE_DISPLAY_NAME=$(echo "$SITE" | jq -r '.display_name')
echo "Checking environments for site "$SITE_DISPLAY_NAME"..."A continuación, se utiliza el nombre del sitio junto con la función get_site_details_by_name definida anteriormente para obtener información detallada sobre el sitio, incluidos todos sus entornos.
SITE_DETAILS=$(get_site_details_by_name "$SITE_NAME")
CLEAN_SITE_DETAILS=$(echo "$SITE_DETAILS" | tr -d 'r' | sed 's/^[^{]*//')
ENVIRONMENTS=$(echo "$CLEAN_SITE_DETAILS" | jq -r '.site.environments[] | "(.id):(.name):(.display_name)"')A continuación, se realiza un bucle sobre los entornos para extraer detalles de cada uno de ellos, como el ID, el nombre y el nombre para mostrar:
while IFS= read -r ENV; do
ENV_ID=$(echo "$ENV" | cut -d: -f1)
ENV_NAME=$(echo "$ENV" | cut -d: -f2)
ENV_DISPLAY_NAME=$(echo "$ENV" | cut -d: -f3)
echo "Checking plugins for environment "$ENV_DISPLAY_NAME"..."Para cada entorno, el script obtiene ahora su lista de plugins utilizando la API de Kinsta.
PLUGINS_RESPONSE=$(curl -s -X GET "$BASE_URL/sites/environments/$ENV_ID/plugins"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json")
CLEAN_PLUGINS_RESPONSE=$(echo "$PLUGINS_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')A continuación, el script comprueba si el plugin especificado existe en el entorno y tiene una actualización disponible:
OUTDATED_PLUGIN=$(echo "$CLEAN_PLUGINS_RESPONSE" | jq -r --arg PLUGIN_NAME "$PLUGIN_NAME" '.environment.container_info.wp_plugins.data[] | select(.name == $PLUGIN_NAME and .update == "available")')Si se encuentra un plugin desactualizado, el script registra sus detalles y los añade al array SITES_WITH_OUTDATED_PLUGIN:
if [ ! -z "$OUTDATED_PLUGIN" ]; then
CURRENT_VERSION=$(echo "$OUTDATED_PLUGIN" | jq -r '.version')
UPDATE_VERSION=$(echo "$OUTDATED_PLUGIN" | jq -r '.update_version')
echo "Outdated plugin "$PLUGIN_NAME" found in "$SITE_DISPLAY_NAME" (Environment: $ENV_DISPLAY_NAME)"
echo " Current Version: $CURRENT_VERSION"
echo " Update Version: $UPDATE_VERSION"
SITES_WITH_OUTDATED_PLUGIN+=("$SITE_DISPLAY_NAME:$ENV_DISPLAY_NAME:$ENV_ID:$UPDATE_VERSION")
fiEste es el aspecto que tendrían los detalles registrados de los plugins obsoletos:
Outdated plugin "example-plugin" found in "Site ABC" (Environment: Production)
Current Version: 1.0.0
Update Version: 1.2.0
Outdated plugin "example-plugin" found in "Site XYZ" (Environment: Staging)
Current Version: 1.3.0
Update Version: 1.4.0A partir de aquí, realizamos actualizaciones de plugins para cada plugin utilizando su endpoint. El script completo está en este repositorio de GitHub.
Resumen
Este artículo te ha guiado en la creación de un script de shell para interactuar con la API de Kinsta.
Tómate un tiempo para explorar más a fondo la API de Kinsta — descubrirás funcionalidades adicionales que puedes automatizar para gestionar tareas adaptadas a tus necesidades específicas. Puedes plantearte integrar la API con otras APIs para mejorar la toma de decisiones y la eficacia.
Por último, consulta regularmente el panel de control de MyKinsta para conocer las nuevas funcionalidades diseñadas para que la gestión del sitio web sea aún más sencilla gracias a su intuitiva interfaz.
