El hilo sobre DevOps: automatízame ésta

Wei-Yu

#120 claro, a ver, yo digo que el proceso a seguir sería

  1. refactor de recurso para el nuevo id + moved para mantener un link id viejo->id nuevo
  2. apply a entornos
  3. refactor en consumidores para utilizar el id nuevo y dejar de usar el viejo
  4. apply a entornos
  5. eliminar el bloque moved
  6. apply a entornos

y me están diciendo que 5 y 6 no dependen de 3 y 4 porque terraform "mantiene una referencia en el estado", que me parece una cosa rara del copón teniendo en cuenta que la gracia de usar algo como TF es que sea declarativo, y si no hay declaración de algo ese algo no debería existir, sea lo que sea

pero lo pregunto porque leyendo la docu no me queda claro 100% (o bueno supongo que sí pero como me dicen lo contrario me están liando xd)

https://developer.hashicorp.com/terraform/language/modules/develop/refactoring#removing-moved-blocks

1 respuesta
sasher

#121 o sea te están diciendo que puedes hacer el paso 5 después del paso 2 sin problemas? Pienso como tú, tampoco lo veo. Las veces que he hecho algo de esto primero me he asegurado de que todo esté funcionando antes de eliminar nada... De hecho en la documentación que referencias te da la razón a ti.

En cualquier caso, si lo que te comentan es verdad, después de hacer el paso 2 si haces un terraform state list debería salirte esa "referencia en el estado" que te dicen si fuera cierto.

1
7 días después
draz1c

Jeff Geerling ha puesto su libro Ansible for DevOps gratis (¿temporalmente?):

https://leanpub.com/ansible-for-devops/c/CTVMPCbEeXd3

9 1 respuesta
GaN2

#123 Buen libro, mejor persona

3
aren-pulid0

https://dagger.io/

CI/CD como código, lo hace portable y testeable en local porque funciona con contenedores

¿Cómo lo veis? Yo personalmente veo interesante la idea

1 1 respuesta
wdaoajw

#125 ni idea de dagger, pero te diría que tekton tiene más recorrido

9 días después
aren-pulid0

Tal vez ya lo conozcas @wdaoajw, pero he descubierto esto:

https://www.telepresence.io/

Desarrollo de servicios (k8's) en local, te trae el tráfico de pods desde el cluster de dev.

1 respuesta
D

Lo que permite es desarrollar en local contra el cluster de kubernetes de turno de forma remota, si no estoy equivocado.

1 respuesta
wdaoajw

#127 no lo conocía, pero puede estar interesante de cara a los devs

#128 parece más un agente que sirve para hacer port-forwards de servicios de kubernetes sin pasar por la API de k8s, puede estar bien para hacer desarrollo sin necesidad de dar permiso a los propios devs al cluster

1
D

Ya os diré, nos lo han pedido varios equipos y tengo un compañero haciendo algún PoC.
Todo lo que sea dar autonomía a los devs, bienvenido sea

1
aren-pulid0

Si vais conociendo herramientas y tal estaria guay que las traigais, nos hacemos los bleeding edge de los dev ops jajaja

13 días después
Rinkes

K9s es una puta maravilla para la gestión de contextos de kubernetes.

2 2 respuestas
Gigi_men

Relacionado con el tema de las herramientas, dejo por aquí un episodio de un podcast que me gusta bastante.

https://changelog.com/gotime/285

En las Notes tenéis el listado de herramientas directamente.

1
Ismelldrama

#132 La verdad que es comodisimo. Entre eso y Rancher todo cubierto!

1 respuesta
wdaoajw

#132 #134 para la gestión de contextos yo uso kubectx, kubens no me va tanto, soy un pureta poniendo siempre el -n

https://github.com/ahmetb/kubectx

1 2 respuestas
D

#135 idem

1
Gigi_men

#135 +1 y aparte lo compagino con los Alias. Hay varios conjuntos de alias, pero yo utilizo estos.

https://github.com/ahmetb/kubectl-aliases

Rinkes

kx y kn o kw los usaba yo... pero para que coño quieres kubectl si con k9s tienes una especie de vi para manejarlos.

Otra cosita guapa: integraciones de AZDevOps con Slack o kubeless como operador para lanzar tus propias lamdas en kubernetes vanilla.

Esto es de cosecha propia... hecho con chatgpt, acepto PRs :D
https://github.com/ccokee/AZDOprBot

Tengo alguna herramienta mas de automatización o para SREs. Un Operador de k8s que levanta CRDs tipo watch o publisher para elevar eventos del cluster de una lista de event types a Bot de Telegram o Pubsub de GCP

https://github.com/ccokee/eventd-operator

La idea es usarlo para notificación simple o para consumo de postprocesado y analisis de eventos.

1
aren-pulid0

Si alguna vez tenéis que crearos un cluster en local y no os vale minikube utilizad este repo:

https://github.com/techiescamp/vagrant-kubeadm-kubernetes

vagrant up

y tienes un cluster funcionando

1 respuesta
Gigi_men

#139 Por aqui normalmente uso KinD. Pero si que es verdad que si necesitas algo mas complejo como Storage, es un poco drama.

29 días después
aren-pulid0

¿Como organizáis los clusters de k8s en vuestra empresa? ¿Un mega cluster? ¿Un cluster por entorno? ¿Un cluster por app?

Como estoy en una empresa que no utiliza Kubernetes y me gustaría volver a utilizarlo cuando cambie de empresa he pensado en hacer un repo "bootstrap/template" que tenga lo siguiente:

  • Terraform para crear 3 clusters (manager, dev y pro)
  • ArgoCD con el patrón de App of Apps
    • Estará en el cluster manager
    • RBAC típicos para dev y pro.
    • ApplicationSets para manejar las aplicaciones.
  • Monitoring con Prometheus+Alertmanager y Grafana.
    • Me gustaría meter Thanos para tener más tiempo de visualización de logs en Grafana.
  • Autoescalado con AutoScaler/Karpenter
  • Cert-manager
  • External DNS

Como pegote me gustaría explorar un service mesh como Istio o LinkerD porque nunca lo usé.

¿Echáis en falta algo que sea un must have en vuestros clusters?

1 respuesta
Gigi_men

#141 Todo depende de como se tengan estructurados los entornos. En cualquier caso, si vas a utilizar Terraform te recomiendo hacer un único módulo y despues consumirlo para crear los clusters que necesites. (ya hay modulos publicos que puedes utilizar).

Respecto a ArgoCD, lo suyo es que tengas un ApplicationSet por cada aplicación y la definición de cada aplicación junto con los ficheros de values por cada entorno (en caso de que decidas utilizar formato de Helm) esté en un repo propio de "infraestructura". Lo comento por que en la empresa en la que estoy actualmente hay matado moscas a cañonazos y han decidido ir a una arquitectura Monorepo. Lo que termina provocando que el ArgoCD RepoServer se quiera pegar un tiro cada vez que hay algún cambio.

La parte de monitoring eso ya depende de cada uno, pero lo que has elegido está bien.

Respecto a Autoscaler o Karpenter, yo no lo consideraria prioritario de primeras ya que tienes que tener muy claro como quieres escalar y si lo juntas con HPA (que es lo suyo) puede dar muchos dolores de cabeza.

Cert-Manager y External-DNS son casi obligatorios para mi, al igual que External-Secrets.

Si todo esto lo quieres para trastear, te recomiendo varias cosas:

  • Olvidate de Terraform y en cualquier caso ve echando un ojo a OpenTF. Tras los cambios de licenciamiento habrá un cambio bastante gordo.
  • Echale un vistazo también a Crossplane, que parece que está pillando bastante fuerza, aunque por ahora la mayoría del soporte es para AWS y en mi opinión todavía no es production-ready.
  • Imagino que también querrás algún CI/CD. Recomendaría Github Actions o GitLab Pipelines, o en caso de querer algo mas agnóstico, tiraría por el stack de Argo (Workflows, Events, Rollouts)
2 respuestas
andoni013

#142

en cualquier caso ve echando un ojo a OpenTF

Ojo con esto, que parece que no está tan claro el futuro de OpenTF

2 respuestas
Gigi_men

#143 cierto, partiendo de que tiene que haber un futuro. Por ahora ni hay repo publicado. Pero aún así, parece bastante claro que habrá cambios en la industria.

aren-pulid0

#142 No sabía que había módulos de este estilo para Terraform (principalmente he usado CDK en mi empresa). Voy a usar Linode en este caso porque es más barato que AWS, no quiero fundirme el sueldo con 3 clusters ($75 x 3) + las instancias de EC2.

Para la estructura del repo tenía pensado algo así, un repo de infraestructura donde esta el propio Argo, el monitoring, cert-manager, external-dns... Todas las herramientas que necesita cada cluster y repositorios separados para cada app. En este repo de infraestructura también estarían los ApplicationSets y los values por entorno.

Al principio pensé en meterlo todo en un mismo repositorio pero vi que me iba a ser más difícil de manejar, lo que no me esperaba es que el RepoServer diera problemas cuando hay mucha tralla en un repo grande.

Lo del escalado automático me gustaría investigarlo, ¿da problemas juntar el Autoscaler/Karpenter con el HPA? Tenía entendido que era la combi perfecta, porque el HPA según las métricas que le configuraras te manejaba los pods y el Karpenter se ocupaba de ir creando y destruyendo nodos de forma inteligente según los pods que hay en cada nodo.

Y sí, GRACIAS, sabía que se me olvidaba algo imprescindible y es el External-Secrets jajajaja.

Al final este proyecto es tener un repo con todo lo necesario para tener un "Kubernetes production ready" y que me sirva como proyecto para tenerlo en el CV y que me ayude a conseguir un trabajo en el futuro.

Y de nuevo, gracias por tu respuesta.

1 respuesta
wdaoajw

#145 HPA solo es configurable con CPU/MEM, puedes probar a meterle KEDA junto al Prometheus y escalar en base a cualquier metrica del sistema

Si lo haces por aprender, metele tambien un fluentbit o algun daemonset de logging

Gigi_men

#143 Ya han hecho publico el repo de codigo. Aqui dejo un podcast en el que tratan el tema.

Por cierto, @draz1c puedes anyadir al primer post una seccion de podcast o fuentes para conseguir info? Dejo por aqui unos cuantos que yo sigo.

3 1 respuesta
draz1c

#147 Hecho!

1
2 meses después
draz1c

Pongo esto por aquí porque me ha parecido muy interesante:

https://sadservers.com/

Como pone en la propia página web, son una serie de ejercicios tipo capturar la bandera pero de debuggear una máquina Linux, separado por niveles fácil, medio y difícil, con situaciones típicas de un puesto de SysAdmin, SRE, etc...

Lo descubrí por este video de Pelado Nerd, cuyo canal está también puesto en #1

8
3 meses después
ApeLord

Pues el 1 de abril empiezo mis prácticas como Devops bastante contento y con muchas ganas, cualquier consejo es bienvenido 🫡

1