El hilo sobre DevOps: automatízame ésta

Wei-Yu #121 23 Jun

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

refactor de recurso para el nuevo id + moved para mantener un link id viejo->id nuevo
apply a entornos
refactor en consumidores para utilizar el id nuevo y dejar de usar el viejo
apply a entornos
eliminar el bloque moved
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 #122 23 Jun

#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

draz1c #123 30 Jun

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

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

9 1 respuesta

GaN2 #124 30 Jun Inocente

#123 Buen libro, mejor persona

3

aren-pulid0 #125 4 Jul

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 #126 4 Jul

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

aren-pulid0 #127 13 Jul

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

DiSKuN #128 13 Jul Gafe

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

1 respuesta

wdaoajw #129 13 Jul

#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

DiSKuN #130 13 Jul Gafe

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 #131 13 Jul

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

Rinkes #132 27 Jul

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

2 2 respuestas

Gigi_men #133 27 Jul

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 #134 27 Jul

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

1 respuesta

wdaoajw #135 28 Jul

#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

DiSKuN #136 28 Jul Gafe

#135 idem

1

Gigi_men #137 28 Jul

#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 #138 28 Jul

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
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 #139 2 Ago

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 #140 2 Ago

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

aren-pulid0 #141 1 Sep

¿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 #142 1 Sep

#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 #143 1 Sep

#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 #144 1 Sep

#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 #145 1 Sep

#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 #146 2 Sep

#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 #147 9 Sep

#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 #148 10 Sep

#147 Hecho!

1

draz1c #149 18 Nov

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

ApeLord #150 19 Feb

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

1

Usuarios habituales

Tags