Snapshots periódicos de un PVC en GCP con Google SDK + Bash + CronJob
Pues ahí va la historia de este script:
Resulta que queremos mover una base de datos, la típica postgresql, de una maquina virtual a un pod de kubernetes. Hay muchos factores a tener en cuenta: Si se va a hacer subida de versión, como importar una copia de la base de datos, persistencia de discos… Aunque el que más me preocupaba era el disaster recovery.
Con una VM era sencillo. Script sacado de un blog de google y adaptado al entorno GCP, cambiando el almacenamiento local por un bucket de Storage. Pero claro, la mayoría de imágenes de postgresql vienen sobre alpine, que viene con las funcionalidades más que justas para que su consumo sea mínimo.
Se me ocurrieron un par de soluciones para abordar el problema:
- Instalar cron en el archivo Dockerfile de la imagen. Importar también los scripts actuales de la VM a dicha imágen. En definitiva, emular la VM en el entorno GKE.
- Levantar una imagen google/cloud-sdk, copiar un script .sh que trabajara con snapshots de Kubernetes y ejecutarlo desde un CronJob.
Al final, la que me pareció más adecuada fue la segunda. Y es que hace poco, intentando implementar ELK, descubrí «nuevos» tipos de carga de trabajo más allá de los deployments: Los CronJobs.
Un CronJob es un tipo de carga de trabajo que permite ejecutar trabajos en una programación basada en el tiempo. Estos trabajos automatizados se ejecutan como tareas Cron en un sistema Linux o UNIX.
Este tipo de carga de trabajo, junto a la potencia del SDK de Google, que permite trabajar con cuentas de servicio de permisos limitados, hacen posible que este script funcione. Eh aquí mis archivos «mágicos»:
Dockerfile
FROM google/cloud-sdk:latest
RUN mkdir /scripts
COPY ./[service-account-key].json /scripts
COPY ./snapshot_creation.sh /scripts
RUN chmod +x /scripts/snapshot_creation.sh
CMD tail -f /dev/nullPara poder utilizar GKE de forma desatendida, es necesario utilizar una cuenta de servicio. Os dejó aquí un enlace de como activar y empezar a usar una cuenta de servicio con GCP.
Script en Bash
#VAR definition
account_service_email="[account-service-email]"
account_service_json_dir="/scripts/.[service-account-key].json"
cluster_name="[cluster-name]"
cluster_zone="[cluster-zone]"
date=$(date +%Y%m%d-%H%M)
gcp_project_name="[gcp-project-name]"
pvc_name="pvc-[id]"
snapshot_name=$date-prod-psql-snapshot
snapshot_namespace="[kubernetes-namespace]"
#Create YAML
printf "apiVersion: snapshot.storage.k8s.io/v1beta1 \n" > snapshot.yaml
printf "kind: VolumeSnapshot \n" >> snapshot.yaml
printf "metadata: \n" >> snapshot.yaml
printf " name: $snapshot_name \n" >> snapshot.yaml
printf " namespace: $snapshot_namespace \n" >> snapshot.yaml
printf "spec: \n" >> snapshot.yaml
printf " source: \n" >> snapshot.yaml
printf " persistentVolumeClaimName: $pvc_name" >> snapshot.yaml
#Create snapshot
gcloud auth activate-service-account $account_service_email --key-file=$account_service_json_dir --project=$gcp_project_name
gcloud container clusters get-credentials $cluster_name --zone $cluster_zone --project $gcp_project_name
kubectl create -f snapshot.yaml --save-config
#Remove old versions
snapshot_count=`kubectl get volumesnapshot | grep prod-psql-snapshot | wc -l`
digest_array=(`kubectl get volumesnapshot | grep prod-psql-snapshot | awk '{print $1}'`)
if [ $snapshot_count -gt 14 ]
then
oldest_snapshot=`echo ${digest_array[0]}`
kubectl delete volumesnapshot $oldest_snapshot
fiLo que hago con este script es generar el YAML de un VolumeSnapshot, me autentico con la cuenta de servicio y creo ese snapshot. Para dejarlo todo limpio, cuento el número de copias al finalizar, y si pasan de 14, borro las últimas. Para más info acerca de como trabajar con los VolumeSnapshots en GCP, podéis consultarlo aquí.
CronJob
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: snapshot
spec:
schedule: "01 0 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: backup
image: gcr.io/[project-name]/[image_name]
args:
- /bin/sh
- -c
- sh /scripts/snapshot_creation.sh
restartPolicy: NeverY ya estaría! Problema resuelto!
Pipeline en Jenkins para Rollback en Función del Entorno
La entrada de hoy es algo de lo que me siento realmente orgullosa. Llevo pocos meses trabajando con Jenkins y familiarizándome con su lenguaje, y hacer un script que te permita el rollback es una herramienta que pienso guardar en mi cajón de sastre.
Las necesidades que tenía eran:
- Elegir la imagen del container registry para un deployment y un container dado de Kubernetes, en función del entornos, en mi caso prod y dev.
- Necesitaba que me generara una lista de las etiquetas de la imagen del Container Registry de GCP en función del entorno.
- Necesitaba que fuera interactivo, y que el usuario que lo lanza pudiera decidir que versión restaurar.
En mi caso, he elegido el objeto de Jenkins pipeline, que me da un poco más de manga ancha para «programar». Y este es el resultado:
pipeline {
agent any
environment {
ENVIRONMENT = ""
IMAGE = gcr.io/[PROJECT_ID]/[IMAGE_NAME]
CMD=""
TAGS=""
K8_OBJ="deployment/[deployment-name]"
CONTAINER="[container_name]"
}
stages {
stage("Select Environment") {
steps {
script {
// Variables for input
// Get the environment
def envInput = input(
id: 'envInput', message: 'Enter path of test reports:?',
parameters: [
choice(name: 'ENVIRONMENT',
choices: ['prod','dev'].join('\n'),
description: 'Please select the Environment')
])
// Save to variables. Default to empty string if not found.
ENVIRONMENT = envInput?:''
}
}
}
stage("Select IMAGE f(x) env") {
steps {
script {
if (ENVIRONMENT == 'prod') {
//Image si prod
IMAGE = "gcr.io/[PROJECT_ID]/[IMAGE_NAME]"
} else {
//Image si dev
IMAGE = "gcr.io/[PROJECT_ID]/[IMAGE_NAME]"
}
}
}
}
stage("Select available tag") {
steps {
script {
//Generar la lista de etiquetas disponibles para la imagen dada
CMD="gcloud container images list-tags $IMAGE | awk 'NR==2,NR==12' | awk '{print \$2}' | awk -F, '{print \$1}'"
TAGS=sh (returnStdout: true, script: CMD ).trim()
//Recoger la etiqueta seleccionada por el usuario
def tagInput = input(
id: 'tagInput', message: 'Enter path of test reports:?',
parameters: [
choice(name: 'TAGS',
choices: [TAGS].join('\n'),
description: 'Please select the Environment')
])
//Guardar la etiqueta seleccionada por el usuario.
TAG = tagInput?:''
}
}
}
stage("Rollback To Selected Version"){
steps {
sh "kubectl set image ${K8_OBJ} ${CONTAINER}=${IMAGE}:${TAG} --record -n ${ENVIRONMENT}"
}
}
}
}Y ya estaría. Problema resuelto!
Script en bash para eliminar imágenes del Container Registry de GCP
Hoy una entrada sencilla pero efectiva. Al venir de sistemas, me cuesta más que a un desarrollador elaborar código. Y por eso es que me siento tan orgullosa de mis scripts.
En esta ocasión, utilizo la herramienta de comandos en linea de GCP, glcoud.
Para listar:
gcloud container images list-tags [HOSTNAME]/[PROJECT-ID]/[IMAGE_NAME]Para eliminar:
gcloud container images delete [HOSTNAME]/[PROJECT-ID]/[IMAGE_NAME]@sha256:DIGEST --quietEl script quedaría tal que así:
#!/bin/bash
declare -a digest_array
#Recoger todas imágenes del repositorio pasado en la llamada al script. Con awk recogemos solo la primera columna que corresponde con el DIGEST.
digest_array=(`gcloud container images list-tags "$1" | awk '{print $1}'`)
#En nuestro caso, queremos conservar las 3 imágenes más recientes. Por ello, el contador es 4 (columna del encabezado + 3 imágenes).
for i in "${digest_array[@]:4}"
do `gcloud container images delete "$1"@sha256:"$i" --quiet --force-delete-tags`
done
La llamada por terminal, sería:
./delete_old_images.sh "[HOSTNAME]/[PROJECT-ID]/[IMAGE_NAME]"Problema resuelto!
Mis claves para gestionar la mente cuando realizas tareas de helpdesk
Los helpdesk somos todas aquellas personas en la sombra, haciendo de parapeto entre los clientes finales y el equipo IT. Las funciones principales, bien sean helpdesk puros o sysadmin que asumimos esas funciones, es intentar solucionar lo más prontamente posible los problemas de clientes o compañeros.
Es un trabajo mal pagado -unos 18k brutos si tienes suerte-, con una alta carga de estrés, cuya importancia no se reconoce lo suficiente. Son la cara visible cuando el cliente tiene un problema, fundamentales para no sobrecargar la estructura y hacer que todos los mecanismos funcionen correctamente.
Los helpdesk son indiscutiblemente necesarios en cualquier entorno empresarial, tanto si la empresa tiene 10 empleados como si tiene 500. Un buen servicio de helpdesk ayuda a que los clientes no se sientan frustrados, agiliza y resuelve la problemática diaria, e incluso, según el entorno, aumenta la productividad.
Dicho todo esto, trabajar de helpdesk implica altos niveles de empatía, paciencia, flexibilidad, proactividad y mejora continua. Debemos tener en cuenta que debido a la pandemia ese trabajo se ha vuelto aún más complicado. Muchas trabajadoras optamos por la modalidad teletrabajo, que tiene sus ventajas y sus inconvenientes.
Uno de esos problemas que experimentamos es la comunicación. Y es que esta se ha tornado bastante difícil, porque ahora abusamos de herramientas de comunicación escrita, como el chat o el email. Esto da lugar a una serie de situaciones habituales que antes no lo eran, como:
- Información incompleta. Una coma, un signo de interrogación… Cambia el sentido completo de la frase, lo cual me lleva al siguiente punto.
- Necesidad de una definición minuciosa de las problemáticas. Siempre es importante, pero con teletrabajo, aún más. Una captura bien tomada puede ser diferencial para una resolución temprana.
- Malos entendidos. Ocurren por muchos factores, aunque lo que he acusado más sensiblemente es el salto generacional. La forma de escribir de un boomer y de un milenial, por lo general, da cambios bastante bruscos.
- Grado de sensibilidad alto. Los clientes se sienten indefensos, cuando se ven obligados a utilizar herramientas tipo helpdesk, o dependen de que su problemática se resuelva por email o chat. Su grado de confianza en la efectividad de estas herramientas les hace sentirse vulnerables.
Me encanta todo lo que tenga que ver con sistemas, desde un Jenkins, pasando por Kubernetes, monitorización, seguridad… Pero trabajar de sistemas, está muy ligado a las labores de helpdesk, en mayor o menor porcentaje de tiempo. Y por desgracia se me da mejor comunicarme con las máquinas que con los seres humanos.
Al final, trabajar con personas es lo más difícil. A veces tenemos días buenos, y otros, no lo son tanto. A veces explicar las cosas es difícil, las cosas no salen como esperabas, o te puedes tomar las afrentas como algo personal, cuando no lo son. Y a pesar de todo esto, tienes que tener temple y sangre fría y nunca perder la sonrisa ni las buenas maneras
Mis Claves Para Afrontarlo
1. Respeto
Un aspecto fundamental que tiene que estar presente en los dos sentidos. Tanto del cliente hacia ti, como de ti hacia el cliente.
El helpdesk no deberá jamás faltar al respeto, ni gritar, ni insultar, ni dejar en ridículo… Pero lo mismo se le supone a la parte cliente.
En caso de que esta premisa no se cumpla, lo primero sería tratarlo con el cliente de la manera mas educada posible. En caso de persistencia, se debería tratar con el supervisor o responsable correspondiente, para tomar las medidas que sean oportunas.
Por supuesto, si un usuario entra de malas maneras, nunca, repito nunca, se le tiene que devolver con la misma manera. Si te grita, no le grites. Si te dirige una queja que escapa a tu paraguas de responsabilidad, le rediriges a la persona que puede solventarlo.
Respeto, respeto y más respeto.
Tenemos que hacer focus en que nuestra labor es ayudar, e intentar concentrarnos en el apartado técnico. Dejar de lado el aspecto emocional, los adjetivos peyorativos, las frases de desdén… Es un poco frío, pero al final es lo que es: un trabajo.
Empatía
Es una de las cosas más difíciles de cualquier trabajo de atención al cliente: Ponerse en el lugar del otro. Cómo piensa, como actúa, porque se comunica de la manera que lo hace…
Es un clásico las incidencias «urgentes». Para un cliente, las prioridades son muy distintas a las de alguien de sistemas. El cliente siempre va a querer ser el primero, intentar que se lo soluciones para ayer.
Algunas de mis frases de bolsillo que siempre me funcionan son:
- Estoy con una incidencia super urgente. Pero tan pronto como lo solucione, eres el primero en ser atendido.
- Ahora mismo me pillas acabando [TAREA]. Dame 10 minutos que lo cierre y me pongo enseguida.
- Avísame cuando tengas un momento y lo revisamos junt@s.
A veces es un poco frustrante, pero la interrupción y el separarse del contexto es algo normal y natural en sistemas y helpdesk. Por experiencia propia, es preferible atender el telefono y decir «no puedo ahora» a dejarlo sonar.
Es importante, que aunque la atención no pueda ser inmediata, la persona reciba un feedback de que su petición ha sido tramitada correctamente y que se le atenderá a la mayor brevedad posible. Eso hará que el resto del proceso sea más ágil y más agradable por ambas partes.
Por supuesto, ser conscientes de que si alguien reclama la ayuda de un helpdesk, no lo hace por gusto, sino que no le queda más remedio. Eso puede ocasionar en algunas personas sentimiento de debilidad y vulnerabilidad. Es por eso que hay que ser especialmente amables, comprensivos, empáticos y siempre medir nuestras palabras.
Protocolo
Realizar labores de helpdesk es mucho más fácil cuando hay protocolos definidos. Qué hacer cuando hay que dar un alta nueva, o cómo funciona el flujo de compras. Si se sale del protocolo, es muy fácil indicar cual es el cauce a seguir.
En caso de que no haya protocolo, tenemos que ser flexibles.
A veces pasa. Las empresas son jóvenes y no los han definido, o no tan jóvenes pero no se ha visto necesidad de controlar ciertos aspectos. Tenemos que tener en cuenta también que cada caso es diferente. A veces se soluciona con preguntar al responsable, en otras ocasiones hay que parar la incidencia y a veces hay que actuar sin analizar mucho los riesgos.
En cualquier situación, la mejor opción es siempre mantener al usuario informado. Y en caso de que sea necesario, definir nuevas metodologías y acciones a ejecutar.
Herramientas para el control y la gestión de incidencias
No se puede realizar labores de helpdesk sin un software adecuado. Da igual como se llame la herramienta: Remedy, ManageEngine, SpiceWorks, Jira…
Con este tipo de software podemos definir:
- Tiempos empleados en las incidencias.
- Asignación por técnico. Es útil repartir la carga entre los miembros del equipo.
- Registro de las actuaciones llevadas a cabo. Tanto para nosotros mismos, como para otros compañeros si nos toman el relevo.
- Categoría y subcategoría. Muy útil si se quieren localizar los ladrones de tiempo
- Definición de tiempos de respuesta y de resolución.
- Establecer prioridades
Canales
Esto va muy ligado al tema de protocolos y a las herramientas de helpdesk. Hay muchas formas de recibir las incidencias, pero es necesario concienciar a la organización de la necesidad de unificar los canales para ofrecer un mejor servicio.
Lo recomendado siempre es recibir las peticiones por la misma vía, de la misma manera, y a veces que desde el mismo interlocutor. Pero seamos sinceros: no es lo habitual. Por eso, hay que ser flexibles e indicar como es la manera correcta de proceder para próximas ocasiones.
El tener unos canales establecidos y trabajar siempre de la misma manera, nos ayuda a ser más ágiles y prestar mejor servicio.
Prioridades
Cuando todo es urgente, nada es urgente.
Anónimo
Si bien ITIL nos ayuda con el tema de prioridades, en función del impacto en la organización, numero de usuarios afectados, urgencia de la petición… Es algo bastante teórico. Hay muchos factores que influyen, como el apellido y el cargo, los plazos, la duración de cada incidencia, si esta ha sido previamente resuelta o no, si requiere investigación…
Al final, son todos estos factores los que ha de definirnos la prioridad a asignar a cada caso. Pero una vez definidas las prioridades, siempre en la medida de lo posible, hay que intentar respetarlas.
No agobiarse – Buena organización
A veces es necesario parar. Vamos a 100 por hora, y a veces algo sencillo se nos hace una montaña.
En mi caso, suelo utilizar técnicas de yoga, como el pranayama, para controlar la respiración. Eso junto a una buena organización, hace que hagamos más por menos.
Y si necesitas un descanso, descansa. Sal a la calle, da una vuelta, ve a tomar un café… El mecanismo que prefieras. Trabajar con estrés de más no va a ayudar a que las cosas salgan antes ni mejor.
No es personal
Si recibes ataques, sea cual sea la incidencia a la que te enfrentes, no va contra tu persona.
En mi caso me cuesta separar el ámbito personal y el profesional. Me encanta mi trabajo, así que es mi trabajo y mi hobby. Pero si con los años he aprendido algo, es que, pase lo que pase, no es contra ti. Por supuesto, dejar de lado las disputas o tensiones que pueden surgir con los clientes. No aportan valor y entorpecen nuestras funciones.
Volvemos al punto de la empatía. Quizás la persona ha tenido un mal día, o está nerviosa, o necesita algún punto de fuga. Es común que se pague con el eslabón más débil de la cadena. Pero a pesar de todo esto, si estás convencido de que has hecho tu trabajo lo mejor posible, hay que repetirse: Esto no es personal.
Base de datos de conocimiento
Poco a poco el trabajo en oficina va evolucionando. Y es el mismo usuario el que te pide la manera de hacer las cosas. Os aseguro que lo último que quiere un usuario a la hora de renovar su contraseña, es tener que pasar por el departamento IT para hacer ese cambio. Por otra parte, muchas veces las cosas se «hacen mal» porque no se saben hacer de otra manera.
Una base de datos de problemas habituales, un buen FAQ, y todo este tipo de herramientas con las que se trasmite la información, ayuda a un mejor funcionamiento, agiliza el servicio y reduce el tiempo de inactividad.
Pero ojo, todo sin abusar. Me gusta mucho utilizar ciertas frases cuando envío documentación de una solución a clientes:
- Si a pesar de la documentación tienes dudas, quedo a tu disposición.
- Si esto que te adjunto no lo resuelve, lo vemos en detalle tan pronto pueda.
- Si esto no funciona, tendremos que remitir el caso al soporte del producto.
Pero como siempre, equilibrio. Ni todo manuales ni todo conexiones remotas.
Aprender de las críticas y comentarios
Siempre seguir aprendiendo.
Toda la información que nos puedan trasmitir clientes y usuarios es altamente valiosa. Para automatizar, para mejorar, para hacer las cosas de una manera diferente… Tengámoslo siempre en cuenta.
Estos puntos están basados en mi experiencia. Y como todos somos diferentes, habrán cosas que nos funcionen y otras que no.
¿Qué técnicas usáis vosotros para gestionar vuestra cabeza cuando tenéis que hacer helpdesk?