El hilo sobre DevOps: automatízame ésta

Wei-Yu #121 Jun '23

#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 Jun '23

#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 Jun '23

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

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

9 1 respuesta

GaN2 #124 Jun '23 Inocente

#123 Buen libro, mejor persona

3

aren-pulid0 #125 Jul '23

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 Jul '23

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

aren-pulid0 #127 Jul '23

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

DiSKuN #128 Jul '23

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 Jul '23

#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

DiSKuN #130 Jul '23

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 Jul '23

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

Rinkes #132 Jul '23

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

2 2 respuestas

Gigi_men #133 Jul '23

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 Jul '23

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

1 respuesta

wdaoajw #135 Jul '23

#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

DiSKuN #136 Jul '23

#135 idem

1

Gigi_men #137 Jul '23

#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 Jul '23

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 Ago '23

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 Ago '23

#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 Sep '23

¿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 Sep '23

#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 Sep '23

#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 Sep '23

#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 Sep '23

#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 Sep '23

#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 Sep '23

#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 Sep '23

#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