Routine automated backups
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- google-cloud, kubernetes
- Área
- cloud, devops, infrastructure
Línea de trabajo
No se nombran archivos, pruebas ni puntos de entrada. Comienza comparando las copias de seguridad de discos a nivel de GKE, los plugins de Jenkins y Artifactory y los buckets de almacenamiento en la nube con la necesidad indicada de conservar el historial y los artefactos publicados manualmente. Se considera terminado cuando se haya seleccionado y documentado un enfoque de copias de seguridad rutinarias para al menos Jenkins y Artifactory.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
As part of the 2023 overhaul I aim to at least take GKE-level backups of the disks for the major tools after final deployment (Jenkins and Artifactory at least). There are a variety of options for routine backups - although the new IaC/CaC focus takes a huge bite out of just redeploying from scratch and being able to get up to speed fairly fast. Still, it would be unnecessary pain to lose all history in Jenkins and especially Artifactory, where we might also have a few manually published artifacts that snuck in over the years.
There are plugins for the individual apps as well as GKE-provided backups but I'm unsure about which options to pick.
Another related option would be to offload binaries to cloud-provided storage buckets rather than local / persistent disks, those are backed up at the cloud-provider level and may be secure enough to only worry about having the config in a good place.
- Lenguaje dominante
- Groovy
- Estrellas
- 0
- Forks
- 2
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de MovingBlocks/Logistics
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
MovingBlocks/Logistics#11 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
MovingBlocks/Logistics#5 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Todos los issues de MovingBlocks/Logistics
Issues similares
-
SSM GetParameter throttling during concurrent workflow launchesPosiblemente ocupada @alexiswl la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
-
service/s3files
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
hashicorp/terraform-provider-aws#50426 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[EC2] DescribeAvailabilityZones should return real AWS error for unknown zone namePosiblemente ocupada @omatheusmesmo la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
opentelekomcloud/terraform-provider-opentelekomcloud#3582 ·
Los mantenedores suelen responder en 1 día