[{"content":" TL;DR: Kubernetes (K8s) es un orquestador de contenedores que automatiza el despliegue, escalado y gestión de aplicaciones en contenedores. Esta guía ofrece visión general, arquitectura, YAMLs listos para usar, comandos de uso diario y un mini-proyecto para levantar un servicio web con Ingress en minutos.\n¿Qué es Kubernetes? # Kubernetes es una plataforma de código abierto (“open source”) para orquestar contenedores (generalmente Docker) en clústeres. Se encarga de:\nEscalado automático (HPA, VPA, Cluster Autoscaler) Alta disponibilidad y autorrecuperación (ReplicaSet, probes) Despliegues predecibles (rolling update, canary / blue-green) Red, DNS interno y balanceo de carga (Services / Ingress) Configuración y secretos (ConfigMaps / Secrets) Almacenamiento persistente (PV / PVC / StorageClass) Arquitectura (Visión Rápida) # Plano de Control (Control Plane):\nkube-apiserver: puerta de entrada para toda interacción con el clúster. etcd: base de datos clave-valor que mantiene el estado del clúster. scheduler: decide en qué nodo debe ejecutarse un Pod. controller-manager / cloud-controller-manager: reconcilia el estado deseado vs. el estado actual; integra con proveedores de nube. Nodos de Trabajo (Workers):\nkubelet: agente en el nodo; garantiza que los Pods estén en ejecución. kube-proxy: aplica las reglas de red y el balanceo de carga por Service. Container runtime: p.ej. containerd. Objetos Fundamentales # Pod: unidad mínima desplegable (uno o varios contenedores). ReplicaSet / Deployment: réplicas + estrategia de actualización. StatefulSet: estado estable / identidad fija (bases de datos, colas, etc.). DaemonSet: un Pod por nodo (por ej.: agentes de logs / monitorización). Job / CronJob: tareas puntuales o programadas. Service: expone un conjunto de Pods (ClusterIP / NodePort / LoadBalancer). Ingress: enrutamiento HTTP/HTTPS externo hacia Services. ConfigMap / Secret: configuración y credenciales. Namespace / RBAC: aislamiento lógico y permisos. PV / PVC / StorageClass: almacenamiento persistente y aprovisionamiento dinámico. Manos a la obra: desplegando una aplicación web # A continuación, una aplicación NGINX con Deployment, Service e Ingress.\nPre-requisitos locales: kubectl + un clúster (p.ej.: minikube o kind) y un Ingress Controller (en minikube: minikube addons enable ingress).\n1) Deployment + Service (archivo deploy.yaml) # apiVersion: apps/v1 kind: Deployment metadata: name: web-deploy labels: app: web spec: replicas: 3 selector: matchLabels: app: web strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.27-alpine ports: - containerPort: 80 resources: requests: cpu: \u0026#34;100m\u0026#34; memory: \u0026#34;64Mi\u0026#34; limits: cpu: \u0026#34;250m\u0026#34; memory: \u0026#34;128Mi\u0026#34; readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 15 periodSeconds: 10 --- apiVersion: v1 kind: Service metadata: name: web-svc spec: selector: app: web ports: - port: 80 targetPort: 80 protocol: TCP type: ClusterIP ### **2) Ingress (archivo ingress.yaml)** \u0026gt; Para clústeres locales, usa el addon de minikube o instala un Ingress Controller NGINX. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: web.local http: paths: - path: / pathType: Prefix backend: service: name: web-svc port: number: 80 3) Aplicando y probando # kubectl apply -f deploy.yaml kubectl apply -f ingress.yaml kubectl get pods -w kubectl get svc,ingress Minikube:\nminikube addons enable ingress # Mapear host local echo \u0026#34;$(minikube ip) web.local\u0026#34; | sudo tee -a /etc/hosts # Prueba curl -I http://web.local kind:\nCrea el clúster con puertos mapeados (ej.: 80/443) e instala un ingress controller (NGINX). Consulta el manifiesto del proyecto ingress-nginx. Configuración y Secretos # ConfigMap + Secret (ejemplo) # apiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_MESSAGE: \u0026#34;Hello from ConfigMap\u0026#34; --- apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque stringData: DB_PASSWORD: supersecreta Uso en el Pod (fragmento de Deployment):\nspec: containers: - name: app image: nginx:1.27-alpine env: - name: APP_MESSAGE valueFrom: configMapKeyRef: name: app-config key: APP_MESSAGE - name: DB_PASSWORD valueFrom: secretKeyRef: name: app-secret key: DB_PASSWORD Almacenamiento Persistente # PVC genérico (StorageClass por defecto) # apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data-pvc spec: accessModes: [\u0026#34;ReadWriteOnce\u0026#34;] resources: requests: storage: 1Gi Uso en el Pod:\nvolumes: - name: data persistentVolumeClaim: claimName: data-pvc containers: - name: app volumeMounts: - name: data mountPath: /var/lib/data Consejo: en la nube, usa StorageClass del proveedor (EBS/GCE PD/Azure Disk). En local, minikube ya ofrece una clase por defecto.\nAutoscaling # Horizontal Pod Autoscaler (HPA) # Requiere metrics-server instalado.\nkubectl autoscale deployment web-deploy --cpu-percent=70 --min=3 --max=10 kubectl get hpa VPA (Vertical) y Cluster Autoscaler (nodos) complementan el HPA.\nEstrategias de Despliegue # RollingUpdate (por defecto): actualiza gradualmente, con maxSurge/maxUnavailable.\nRecreate: elimina todo y despliega la nueva versión (downtime).\nBlue/Green / Canary: enrutamiento gradual mediante Ingress/Service + etiquetas/selectores.\nEjemplo: Ajuste de estrategia en el Deployment (ya incluido arriba):\nstrategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 Observabilidad \u0026amp; Debug (Hoja-resumen) # # Explorar recursos kubectl get nodes kubectl get ns kubectl get all -n default # Descrever e inspecionar kubectl describe pod \u0026lt;pod\u0026gt; kubectl logs \u0026lt;pod\u0026gt; # logs do contêiner principal kubectl logs -f \u0026lt;pod\u0026gt; -c \u0026lt;container\u0026gt; # Acesso a um Pod kubectl exec -it \u0026lt;pod\u0026gt; -- sh kubectl port-forward svc/web-svc 8080:80 # Deploys e rollouts kubectl rollout status deploy/web-deploy kubectl rollout history deploy/web-deploy kubectl rollout undo deploy/web-deploy # Aplicar/Validar YAML kubectl apply -f arquivo.yaml kubectl diff -f arquivo.yaml kubectl delete -f arquivo.yaml Seguridad (Buenas Prácticas) # RBAC mínimo necesario; usa ServiceAccount específica por aplicación.\nNamespaces por equipo/producto para aislamiento + ResourceQuota / LimitRange.\nRequests/Limits siempre definidos para cada contenedor.\nSecrets para credenciales; evita secretos en ConfigMap / variables de entorno en claro.\nNetworkPolicies para restringir tráfico L3/L4 entre Pods.\nPSA/PSS (Pod Security Standards) para políticas de ejecución más estrictas.\nImágenes confiables y escaneo (Trivy/Grype) + pull siempre con digest cuando sea posible.\nChecklist de Producción\nIngress** con TLS (Let’s Encrypt/ACME) + redirección HTTP→HTTPS metrics-server + HPA Logs centralizados (Loki/ELK) y métricas (Prometheus/Grafana) Backups de etcd y volúmenes Alertas (Alertmanager) y dashboards Políticas: NetworkPolicy, RBAC, PSS Cotas por namespace; revisión de requests/limits CI/CD con manifiestos versionados (Kustomize/Helm/GitOps) Errores Comunes y Soluciones # Pods en CrashLoopBackOff: verifica kubectl logs y probes (tal vez initialDelaySeconds sea muy corto). ImagePullBackOff: revisa nombre/tag/registry/credenciales (imagePullSecret). Servicio no responde: revisa selector y etiquetas del Pod; puertos correctos. Ingress 404: regla/host incorrectos o Ingress Controller no instalado. Sin métricas en el HPA: instala/configura metrics-server. Próximos Pasos # Convierte los YAMLs en Helm charts o Kustomize. Añade canary vía Ingress + peso de tráfico. Crea pipelines CI/CD con validación (lint), kubectl diff y despliegue automático. Referencias útiles: Documentación oficial de Kubernetes; proyectos ingress-nginx, metrics-server, Prometheus, Grafana, Loki, Kustomize y Helm.\nApéndice — Creando un clúster local rápidamente # minikube:\nminikube start --driver=docker minikube addons enable ingress kind: (ejemplo de configuración mínima kind-config.yaml)\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane kubeadmConfigPatches: - | kind: ClusterConfiguration apiServer: extraArgs: enable-admission-plugins: NodeRestriction extraPortMappings: - containerPort: 80 hostPort: 80 protocol: TCP - containerPort: 443 hostPort: 443 protocol: TCP kind create cluster --name k8s-lab --config kind-config.yaml # instala el Ingress Controller NGINX según la documentación del proyecto Nota final: Este post fue escrito para el tema Hugo Relearn. Las secciones, TOC y navegación lateral se generan automáticamente por el tema. Si tu versión de Hugo está desactualizada, actualiza a una versión ≥ 0.126.3 para evitar advertencias de compatibilidad.\n","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/blog/kubernetes/kubernetes-guia-completa/","section":"Blog","summary":"","title":"Kubernetes (K8s) — De cero a la implementación en minutos","type":"blog"},{"content":" TL;DR: Kubernetes (K8s) es un orquestador de contenedores que automatiza el despliegue, escalado y gestión de aplicaciones en contenedores. Esta guía ofrece visión general, arquitectura, YAMLs listos para usar, comandos de uso diario y un mini-proyecto para levantar un servicio web con Ingress en minutos.\n¿Qué es Kubernetes? # Kubernetes es una plataforma de código abierto (“open source”) para orquestar contenedores (generalmente Docker) en clústeres. Se encarga de:\nEscalado automático (HPA, VPA, Cluster Autoscaler) Alta disponibilidad y autorrecuperación (ReplicaSet, probes) Despliegues predecibles (rolling update, canary / blue-green) Red, DNS interno y balanceo de carga (Services / Ingress) Configuración y secretos (ConfigMaps / Secrets) Almacenamiento persistente (PV / PVC / StorageClass) Arquitectura (Visión Rápida) # Plano de Control (Control Plane):\nkube-apiserver: puerta de entrada para toda interacción con el clúster. etcd: base de datos clave-valor que mantiene el estado del clúster. scheduler: decide en qué nodo debe ejecutarse un Pod. controller-manager / cloud-controller-manager: reconcilia el estado deseado vs. el estado actual; integra con proveedores de nube. Nodos de Trabajo (Workers):\nkubelet: agente en el nodo; garantiza que los Pods estén en ejecución. kube-proxy: aplica las reglas de red y el balanceo de carga por Service. Container runtime: p.ej. containerd. Objetos Fundamentales # Pod: unidad mínima desplegable (uno o varios contenedores). ReplicaSet / Deployment: réplicas + estrategia de actualización. StatefulSet: estado estable / identidad fija (bases de datos, colas, etc.). DaemonSet: un Pod por nodo (por ej.: agentes de logs / monitorización). Job / CronJob: tareas puntuales o programadas. Service: expone un conjunto de Pods (ClusterIP / NodePort / LoadBalancer). Ingress: enrutamiento HTTP/HTTPS externo hacia Services. ConfigMap / Secret: configuración y credenciales. Namespace / RBAC: aislamiento lógico y permisos. PV / PVC / StorageClass: almacenamiento persistente y aprovisionamiento dinámico. Manos a la obra: desplegando una aplicación web # A continuación, una aplicación NGINX con Deployment, Service e Ingress.\nPre-requisitos locales: kubectl + un clúster (p.ej.: minikube o kind) y un Ingress Controller (en minikube: minikube addons enable ingress).\n1) Deployment + Service (archivo deploy.yaml) # apiVersion: apps/v1 kind: Deployment metadata: name: web-deploy labels: app: web spec: replicas: 3 selector: matchLabels: app: web strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.27-alpine ports: - containerPort: 80 resources: requests: cpu: \u0026#34;100m\u0026#34; memory: \u0026#34;64Mi\u0026#34; limits: cpu: \u0026#34;250m\u0026#34; memory: \u0026#34;128Mi\u0026#34; readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 15 periodSeconds: 10 --- apiVersion: v1 kind: Service metadata: name: web-svc spec: selector: app: web ports: - port: 80 targetPort: 80 protocol: TCP type: ClusterIP ### **2) Ingress (archivo ingress.yaml)** \u0026gt; Para clústeres locales, usa el addon de minikube o instala un Ingress Controller NGINX. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: web.local http: paths: - path: / pathType: Prefix backend: service: name: web-svc port: number: 80 3) Aplicando y probando # kubectl apply -f deploy.yaml kubectl apply -f ingress.yaml kubectl get pods -w kubectl get svc,ingress Minikube:\nminikube addons enable ingress # Mapear host local echo \u0026#34;$(minikube ip) web.local\u0026#34; | sudo tee -a /etc/hosts # Prueba curl -I http://web.local kind:\nCrea el clúster con puertos mapeados (ej.: 80/443) e instala un ingress controller (NGINX). Consulta el manifiesto del proyecto ingress-nginx. Configuración y Secretos # ConfigMap + Secret (ejemplo) # apiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_MESSAGE: \u0026#34;Hello from ConfigMap\u0026#34; --- apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque stringData: DB_PASSWORD: supersecreta Uso en el Pod (fragmento de Deployment):\nspec: containers: - name: app image: nginx:1.27-alpine env: - name: APP_MESSAGE valueFrom: configMapKeyRef: name: app-config key: APP_MESSAGE - name: DB_PASSWORD valueFrom: secretKeyRef: name: app-secret key: DB_PASSWORD Almacenamiento Persistente # PVC genérico (StorageClass por defecto) # apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data-pvc spec: accessModes: [\u0026#34;ReadWriteOnce\u0026#34;] resources: requests: storage: 1Gi Uso en el Pod:\nvolumes: - name: data persistentVolumeClaim: claimName: data-pvc containers: - name: app volumeMounts: - name: data mountPath: /var/lib/data Consejo: en la nube, usa StorageClass del proveedor (EBS/GCE PD/Azure Disk). En local, minikube ya ofrece una clase por defecto.\nAutoscaling # Horizontal Pod Autoscaler (HPA) # Requiere metrics-server instalado.\nkubectl autoscale deployment web-deploy --cpu-percent=70 --min=3 --max=10 kubectl get hpa VPA (Vertical) y Cluster Autoscaler (nodos) complementan el HPA.\nEstrategias de Despliegue # RollingUpdate (por defecto): actualiza gradualmente, con maxSurge/maxUnavailable.\nRecreate: elimina todo y despliega la nueva versión (downtime).\nBlue/Green / Canary: enrutamiento gradual mediante Ingress/Service + etiquetas/selectores.\nEjemplo: Ajuste de estrategia en el Deployment (ya incluido arriba):\nstrategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 Observabilidad \u0026amp; Debug (Hoja-resumen) # # Explorar recursos kubectl get nodes kubectl get ns kubectl get all -n default # Descrever e inspecionar kubectl describe pod \u0026lt;pod\u0026gt; kubectl logs \u0026lt;pod\u0026gt; # logs do contêiner principal kubectl logs -f \u0026lt;pod\u0026gt; -c \u0026lt;container\u0026gt; # Acesso a um Pod kubectl exec -it \u0026lt;pod\u0026gt; -- sh kubectl port-forward svc/web-svc 8080:80 # Deploys e rollouts kubectl rollout status deploy/web-deploy kubectl rollout history deploy/web-deploy kubectl rollout undo deploy/web-deploy # Aplicar/Validar YAML kubectl apply -f arquivo.yaml kubectl diff -f arquivo.yaml kubectl delete -f arquivo.yaml Seguridad (Buenas Prácticas) # RBAC mínimo necesario; usa ServiceAccount específica por aplicación.\nNamespaces por equipo/producto para aislamiento + ResourceQuota / LimitRange.\nRequests/Limits siempre definidos para cada contenedor.\nSecrets para credenciales; evita secretos en ConfigMap / variables de entorno en claro.\nNetworkPolicies para restringir tráfico L3/L4 entre Pods.\nPSA/PSS (Pod Security Standards) para políticas de ejecución más estrictas.\nImágenes confiables y escaneo (Trivy/Grype) + pull siempre con digest cuando sea posible.\nChecklist de Producción\nIngress** con TLS (Let’s Encrypt/ACME) + redirección HTTP→HTTPS metrics-server + HPA Logs centralizados (Loki/ELK) y métricas (Prometheus/Grafana) Backups de etcd y volúmenes Alertas (Alertmanager) y dashboards Políticas: NetworkPolicy, RBAC, PSS Cotas por namespace; revisión de requests/limits CI/CD con manifiestos versionados (Kustomize/Helm/GitOps) Errores Comunes y Soluciones # Pods en CrashLoopBackOff: verifica kubectl logs y probes (tal vez initialDelaySeconds sea muy corto). ImagePullBackOff: revisa nombre/tag/registry/credenciales (imagePullSecret). Servicio no responde: revisa selector y etiquetas del Pod; puertos correctos. Ingress 404: regla/host incorrectos o Ingress Controller no instalado. Sin métricas en el HPA: instala/configura metrics-server. Próximos Pasos # Convierte los YAMLs en Helm charts o Kustomize. Añade canary vía Ingress + peso de tráfico. Crea pipelines CI/CD con validación (lint), kubectl diff y despliegue automático. Referencias útiles: Documentación oficial de Kubernetes; proyectos ingress-nginx, metrics-server, Prometheus, Grafana, Loki, Kustomize y Helm.\nApéndice — Creando un clúster local rápidamente # minikube:\nminikube start --driver=docker minikube addons enable ingress kind: (ejemplo de configuración mínima kind-config.yaml)\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane kubeadmConfigPatches: - | kind: ClusterConfiguration apiServer: extraArgs: enable-admission-plugins: NodeRestriction extraPortMappings: - containerPort: 80 hostPort: 80 protocol: TCP - containerPort: 443 hostPort: 443 protocol: TCP kind create cluster --name k8s-lab --config kind-config.yaml # instala el Ingress Controller NGINX según la documentación del proyecto Nota final: Este post fue escrito para el tema Hugo Relearn. Las secciones, TOC y navegación lateral se generan automáticamente por el tema. Si tu versión de Hugo está desactualizada, actualiza a una versión ≥ 0.126.3 para evitar advertencias de compatibilidad.\n","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/posts/kubernetes/kubernetes-guia-completa/","section":"Posts","summary":"","title":"Kubernetes (K8s) — De cero a la implementación en minutos","type":"posts"},{"content":" TL;DR: Kubernetes (K8s) is a container orchestrator that automates deployment, scaling, and management of containerized apps. This guide covers the big picture, architecture, ready-to-use YAMLs, day-to-day commands, and a mini-project to bring up a web service with Ingress in minutes.\nWhat is Kubernetes?| # Kubernetes is an open-source platform for orchestrating containers (usually Docker) across clusters. It handles:\nAuto scaling (HPA, VPA, Cluster Autoscaler) High availability and self-healing (ReplicaSet, probes) Predictable deploys (rolling update, canary/blue-green) Networking, internal DNS, and load balancing (Services/Ingress) Configuration and secrets (ConfigMaps/Secrets) Persistent storage (PV/PVC/StorageClass) Architecture (Quick View) # Control Plane:\nkube-apiserver: entry point for all cluster interactions. etcd: key-value store that persists cluster state. scheduler: decides which node should run a Pod. controller-manager / cloud-controller-manager: reconciles desired vs. current state; cloud integrations. Worker Nodes:\nkubelet: node agent; ensures Pods are running. kube-proxy: networking rules and Service load balancing. Container runtime: e.g., containerd. Core Objects # Pod: smallest deployable unit (one or more containers). ReplicaSet/Deployment: replicas + update strategy. StatefulSet: stable identity/state (databases, queues, etc.). DaemonSet: one Pod per node (e.g., log/monitoring agents). Job/CronJob: one-off tasks or scheduled jobs. Service: exposes a set of Pods (ClusterIP/NodePort/LoadBalancer). Ingress: external HTTP/HTTPS routing to Services. ConfigMap/Secret: configuration and credentials. Namespace/RBAC: logical isolation and permissions. PV/PVC/StorageClass: persistent storage and dynamic provisioning. Hands-on: bring up a web app # Below is an NGINX app with Deployment, Service, and Ingress.\nLocal prerequisites: kubectl + a cluster (e.g., minikube or kind) and an Ingress Controller (for minikube: minikube addons enable ingress).\n##1) Deployment + Service (deploy.yaml)** # apiVersion: apps/v1 kind: Deployment metadata: name: web-deploy labels: app: web spec: replicas: 3 selector: matchLabels: app: web strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.27-alpine ports: - containerPort: 80 resources: requests: cpu: \u0026#34;100m\u0026#34; memory: \u0026#34;64Mi\u0026#34; limits: cpu: \u0026#34;250m\u0026#34; memory: \u0026#34;128Mi\u0026#34; readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 15 periodSeconds: 10 --- apiVersion: v1 kind: Service metadata: name: web-svc spec: selector: app: web ports: - port: 80 targetPort: 80 protocol: TCP type: ClusterIP ### **2) Ingress (`ingress.yaml` file)** \u0026gt; For local clusters, use the Minikube addon or install the NGINX Ingress Controller. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: web.local http: paths: - path: / pathType: Prefix backend: service: name: web-svc port: number: 80 ### **3) Applying and Testing** ```bash kubectl apply -f deploy.yaml kubectl apply -f ingress.yaml kubectl get pods -w kubectl get svc,ingress Minikube:\nminikube addons enable ingress # Map local host echo \u0026#34;$(minikube ip) web.local\u0026#34; | sudo tee -a /etc/hosts # Test curl -I http://web.local kind:\nCreate the cluster with mapped ports (e.g., 80/443) and install an ingress controller (NGINX). Refer to the ingress-nginx project documentation. Configuration and Secrets # ConfigMap + Secret (example) # apiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_MESSAGE: \u0026#34;Hello from ConfigMap\u0026#34; --- apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque stringData: DB_PASSWORD: supersecreta Usage in Pod (Deployment snippet):\napiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_MESSAGE: \u0026#34;Hello from ConfigMap\u0026#34; --- apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque stringData: DB_PASSWORD: supersecreta Persistent Storage # Generic PVC (default StorageClass) # apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data-pvc spec: accessModes: [\u0026#34;ReadWriteOnce\u0026#34;] resources: requests: storage: 1Gi Usage in Pod:\nvolumes: - name: data persistentVolumeClaim: claimName: data-pvc containers: - name: app volumeMounts: - name: data mountPath: /var/lib/data Tip: In cloud environments, use the provider\u0026rsquo;s StorageClass (EBS/GCE PD/Azure Disk). Locally, Minikube provides a default class.\nAutoscaling # Horizontal Pod Autoscaler (HPA) # Requires metrics-server installed.\nkubectl autoscale deployment web-deploy --cpu-percent=70 --min=3 --max=10 kubectl get hpa VPA (Vertical) and Cluster Autoscaler (nodes) complement HPA.\nDeployment Strategies # RollingUpdate (default): gradual updates with maxSurge/maxUnavailable.\nRecreate: shuts down all pods before starting the new version (downtime).\nBlue/Green / Canary: gradual routing via Ingress/Service + labels/selectors.\nExample: Strategy adjustment in Deployment:\nstrategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 Observability \u0026amp; Debug (Cheat Sheet) # # Explore resources kubectl get nodes kubectl get ns kubectl get all -n default # Describe and inspect kubectl describe pod \u0026lt;pod\u0026gt; kubectl logs \u0026lt;pod\u0026gt; kubectl logs -f \u0026lt;pod\u0026gt; -c \u0026lt;container\u0026gt; # Pod access kubectl exec -it \u0026lt;pod\u0026gt; -- sh kubectl port-forward svc/web-svc 8080:80 # Deploys and rollouts kubectl rollout status deploy/web-deploy kubectl rollout history deploy/web-deploy kubectl rollout undo deploy/web-deploy # Apply/Validate YAML kubectl apply -f file.yaml kubectl diff -f file.yaml kubectl delete -f file.yaml Security Best Practices # Use minimal RBAC; assign a dedicated ServiceAccount per app. Create namespaces per team/product for isolation + ResourceQuota/LimitRange. Always define Requests/Limits for each container. Use Secrets for credentials; avoid exposing them in ConfigMap/envs in light. Apply NetworkPolicies to restrict L3/L4 traffic between Pods. Enforce PSA/PSS (Pod Security Standards) for stricter execution policies. Use trusted images and scan them (Trivy/Grype) + prefer digest-based pulls. Production Checklist # Ingress with TLS (LetsEncrypt/ACME) + HTTP→HTTPS redirect metrics-server + HPA Centralized logs (Loki/ELK) and metrics (Prometheus/Grafana) Backups for etcd and volumes Alerts (Alertmanager) and dashboards Policies: NetworkPolicy, RBAC, PSS Namespace quotas; reviewed requests/limits CI/CD with versioned manifests (Kustomize/Helm/GitOps) Common Errors and Solutions # Pods in CrashLoopBackOff: check kubectl logs and probes (possibly short initialDelaySeconds). ImagePullBackOff: check image name/tag/registry/credentials (imagePullSecret). Service not responding: verify Pod selector and labels; check port mappings. Ingress 404: incorrect rule/host or missing Ingress Controller. No metrics in HPA: install/configure metrics-server. Next Steps # Convert YAMLs into Helm charts or Kustomize. Add canary deployments via Ingress + traffic weight. Create CI/CD pipelines with linting, kubectl diff, and automated deployment. Useful references: Kubernetes official documentation; ingress-nginx, metrics-server, Prometheus, Grafana, Loki, Kustomize, and Helm projects.\nAppendix — Creating a Local Cluster Quickly # minikube:\nminikube start --driver=docker minikube addons enable ingress kind: (minimal config example kind-config.yaml)\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane kubeadmConfigPatches: - | kind: ClusterConfiguration apiServer: extraArgs: enable-admission-plugins: NodeRestriction extraPortMappings: - containerPort: 80 hostPort: 80 protocol: TCP - containerPort: 443 hostPort: 443 protocol: TCP kind create cluster --name k8s-lab --config kind-config.yaml # install the NGINX Ingress Controller as per the project documentation Final Note: This post was written for the Hugo Relearn theme. Sections, TOC, and sidebar navigation are automatically generated by the theme. If your Hugo version is outdated, upgrade to ≥ 0.126.3 to avoid compatibility warnings.\n","date":"octubre 10, 2025","externalUrl":null,"permalink":"/blog/en/blog/kubernetes/kubernetes-complete-guide/","section":"Blog","summary":"","title":"Kubernetes (K8s) — From Zero to Deployment in Minutes","type":"blog"},{"content":" TL;DR: Kubernetes (K8s) is a container orchestrator that automates deployment, scaling, and management of containerized apps. This guide covers the big picture, architecture, ready-to-use YAMLs, day-to-day commands, and a mini-project to bring up a web service with Ingress in minutes.\nWhat is Kubernetes?| # Kubernetes is an open-source platform for orchestrating containers (usually Docker) across clusters. It handles:\nAuto scaling (HPA, VPA, Cluster Autoscaler) High availability and self-healing (ReplicaSet, probes) Predictable deploys (rolling update, canary/blue-green) Networking, internal DNS, and load balancing (Services/Ingress) Configuration and secrets (ConfigMaps/Secrets) Persistent storage (PV/PVC/StorageClass) Architecture (Quick View) # Control Plane:\nkube-apiserver: entry point for all cluster interactions. etcd: key-value store that persists cluster state. scheduler: decides which node should run a Pod. controller-manager / cloud-controller-manager: reconciles desired vs. current state; cloud integrations. Worker Nodes:\nkubelet: node agent; ensures Pods are running. kube-proxy: networking rules and Service load balancing. Container runtime: e.g., containerd. Core Objects # Pod: smallest deployable unit (one or more containers). ReplicaSet/Deployment: replicas + update strategy. StatefulSet: stable identity/state (databases, queues, etc.). DaemonSet: one Pod per node (e.g., log/monitoring agents). Job/CronJob: one-off tasks or scheduled jobs. Service: exposes a set of Pods (ClusterIP/NodePort/LoadBalancer). Ingress: external HTTP/HTTPS routing to Services. ConfigMap/Secret: configuration and credentials. Namespace/RBAC: logical isolation and permissions. PV/PVC/StorageClass: persistent storage and dynamic provisioning. Hands-on: bring up a web app # Below is an NGINX app with Deployment, Service, and Ingress.\nLocal prerequisites: kubectl + a cluster (e.g., minikube or kind) and an Ingress Controller (for minikube: minikube addons enable ingress).\n##1) Deployment + Service (deploy.yaml)** # apiVersion: apps/v1 kind: Deployment metadata: name: web-deploy labels: app: web spec: replicas: 3 selector: matchLabels: app: web strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.27-alpine ports: - containerPort: 80 resources: requests: cpu: \u0026#34;100m\u0026#34; memory: \u0026#34;64Mi\u0026#34; limits: cpu: \u0026#34;250m\u0026#34; memory: \u0026#34;128Mi\u0026#34; readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 15 periodSeconds: 10 --- apiVersion: v1 kind: Service metadata: name: web-svc spec: selector: app: web ports: - port: 80 targetPort: 80 protocol: TCP type: ClusterIP ### **2) Ingress (`ingress.yaml` file)** \u0026gt; For local clusters, use the Minikube addon or install the NGINX Ingress Controller. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: web.local http: paths: - path: / pathType: Prefix backend: service: name: web-svc port: number: 80 ### **3) Applying and Testing** ```bash kubectl apply -f deploy.yaml kubectl apply -f ingress.yaml kubectl get pods -w kubectl get svc,ingress Minikube:\nminikube addons enable ingress # Map local host echo \u0026#34;$(minikube ip) web.local\u0026#34; | sudo tee -a /etc/hosts # Test curl -I http://web.local kind:\nCreate the cluster with mapped ports (e.g., 80/443) and install an ingress controller (NGINX). Refer to the ingress-nginx project documentation. Configuration and Secrets # ConfigMap + Secret (example) # apiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_MESSAGE: \u0026#34;Hello from ConfigMap\u0026#34; --- apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque stringData: DB_PASSWORD: supersecreta Usage in Pod (Deployment snippet):\napiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_MESSAGE: \u0026#34;Hello from ConfigMap\u0026#34; --- apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque stringData: DB_PASSWORD: supersecreta Persistent Storage # Generic PVC (default StorageClass) # apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data-pvc spec: accessModes: [\u0026#34;ReadWriteOnce\u0026#34;] resources: requests: storage: 1Gi Usage in Pod:\nvolumes: - name: data persistentVolumeClaim: claimName: data-pvc containers: - name: app volumeMounts: - name: data mountPath: /var/lib/data Tip: In cloud environments, use the provider\u0026rsquo;s StorageClass (EBS/GCE PD/Azure Disk). Locally, Minikube provides a default class.\nAutoscaling # Horizontal Pod Autoscaler (HPA) # Requires metrics-server installed.\nkubectl autoscale deployment web-deploy --cpu-percent=70 --min=3 --max=10 kubectl get hpa VPA (Vertical) and Cluster Autoscaler (nodes) complement HPA.\nDeployment Strategies # RollingUpdate (default): gradual updates with maxSurge/maxUnavailable.\nRecreate: shuts down all pods before starting the new version (downtime).\nBlue/Green / Canary: gradual routing via Ingress/Service + labels/selectors.\nExample: Strategy adjustment in Deployment:\nstrategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 Observability \u0026amp; Debug (Cheat Sheet) # # Explore resources kubectl get nodes kubectl get ns kubectl get all -n default # Describe and inspect kubectl describe pod \u0026lt;pod\u0026gt; kubectl logs \u0026lt;pod\u0026gt; kubectl logs -f \u0026lt;pod\u0026gt; -c \u0026lt;container\u0026gt; # Pod access kubectl exec -it \u0026lt;pod\u0026gt; -- sh kubectl port-forward svc/web-svc 8080:80 # Deploys and rollouts kubectl rollout status deploy/web-deploy kubectl rollout history deploy/web-deploy kubectl rollout undo deploy/web-deploy # Apply/Validate YAML kubectl apply -f file.yaml kubectl diff -f file.yaml kubectl delete -f file.yaml Security Best Practices # Use minimal RBAC; assign a dedicated ServiceAccount per app. Create namespaces per team/product for isolation + ResourceQuota/LimitRange. Always define Requests/Limits for each container. Use Secrets for credentials; avoid exposing them in ConfigMap/envs in light. Apply NetworkPolicies to restrict L3/L4 traffic between Pods. Enforce PSA/PSS (Pod Security Standards) for stricter execution policies. Use trusted images and scan them (Trivy/Grype) + prefer digest-based pulls. Production Checklist # Ingress with TLS (LetsEncrypt/ACME) + HTTP→HTTPS redirect metrics-server + HPA Centralized logs (Loki/ELK) and metrics (Prometheus/Grafana) Backups for etcd and volumes Alerts (Alertmanager) and dashboards Policies: NetworkPolicy, RBAC, PSS Namespace quotas; reviewed requests/limits CI/CD with versioned manifests (Kustomize/Helm/GitOps) Common Errors and Solutions # Pods in CrashLoopBackOff: check kubectl logs and probes (possibly short initialDelaySeconds). ImagePullBackOff: check image name/tag/registry/credentials (imagePullSecret). Service not responding: verify Pod selector and labels; check port mappings. Ingress 404: incorrect rule/host or missing Ingress Controller. No metrics in HPA: install/configure metrics-server. Next Steps # Convert YAMLs into Helm charts or Kustomize. Add canary deployments via Ingress + traffic weight. Create CI/CD pipelines with linting, kubectl diff, and automated deployment. Useful references: Kubernetes official documentation; ingress-nginx, metrics-server, Prometheus, Grafana, Loki, Kustomize, and Helm projects.\nAppendix — Creating a Local Cluster Quickly # minikube:\nminikube start --driver=docker minikube addons enable ingress kind: (minimal config example kind-config.yaml)\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane kubeadmConfigPatches: - | kind: ClusterConfiguration apiServer: extraArgs: enable-admission-plugins: NodeRestriction extraPortMappings: - containerPort: 80 hostPort: 80 protocol: TCP - containerPort: 443 hostPort: 443 protocol: TCP kind create cluster --name k8s-lab --config kind-config.yaml # install the NGINX Ingress Controller as per the project documentation Final Note: This post was written for the Hugo Relearn theme. Sections, TOC, and sidebar navigation are automatically generated by the theme. If your Hugo version is outdated, upgrade to ≥ 0.126.3 to avoid compatibility warnings.\n","date":"octubre 10, 2025","externalUrl":null,"permalink":"/blog/en/posts/kubernetes/kubernetes-complete-guide/","section":"Posts","summary":"","title":"Kubernetes (K8s) — From Zero to Deployment in Minutes","type":"posts"},{"content":" Introduction # Did you know that every GPU in your environment can generate valuable data? When properly analyzed, these metrics can optimize performance, reduce costs, and accelerate strategic decisions.\nNVIDIA’s DCGM-Exporter allows you to extract detailed GPU metrics, seamlessly integrating with Prometheus and Grafana for smart dashboards and real-time visualizations.\nWhy GPU Monitoring Matters # Many companies miss opportunities by not properly tracking their GPU resources. With strategic monitoring, you can:\nDetect performance bottlenecks before they impact production. Optimize resource usage and reduce costs. Make data-driven decisions instead of relying on assumptions. Monitor multiple clusters in a centralized way. The real value comes when you can centralize metrics and turn them into actionable insights.\nWhat You’ll Learn in This Post # Here you’ll learn, step by step:\nQuickly set up DCGM-Exporter in Docker Deploy in Kubernetes using Helm Chart Integrate metrics into central Prometheus Visualize powerful dashboards in Grafana All with a focus on turning raw metrics into strategic information for your business.\nRunning DCGM-Exporter in Docker # To quickly run DCGM-Exporter on a GPU-enabled machine:\ndocker run -d --gpus all --cap-add SYS_ADMIN --rm -p 9400:9400 \\ nvcr.io/nvidia/k8s/dcgm-exporter:4.4.1-4.5.2-ubuntu22.04 Test the metrics endpoint:\ncurl localhost:9400/metrics Test the metrics endpoint:\n# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz). # TYPE DCGM_FI_DEV_SM_CLOCK gauge DCGM_FI_DEV_SM_CLOCK{gpu=\u0026#34;0\u0026#34;,UUID=\u0026#34;GPU-604ac76c-d9cf-xxx\u0026#34;} 139 Deploying DCGM-Exporter in Kubernetes # NVIDIA maintains an official Helm Chart to install DCGM-Exporter in Kubernetes clusters:\nhelm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helm repo update helm install --generate-name gpu-helm-charts/dcgm-exporter Check the pod:\nkubectl get pods -l \u0026#34;app.kubernetes.io/name=dcgm-exporter\u0026#34; -n default Access metrics locally:\nkubectl port-forward svc/dcgm-exporter 8080:9400 curl http://127.0.0.1:8080/metrics Setting up Local Prometheus in Docker # Add a scrape job to collect DCGM-Exporter metrics in prometheus.yml:\nscrape_configs: - job_name: \u0026#34;dcgm-exporter\u0026#34; static_configs: - targets: [\u0026#34;host.docker.internal:9400\u0026#34;] Use host.docker.internal in Docker Desktop (Windows/Mac). On Linux, replace it with the host machine IP.\nRestart Prometheus:\ndocker run -d --name prometheus --network=host \\ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \\ prom/prometheus Now your DCGM-Exporter metrics will be collected properly.\nGrafana Integration # NVIDIA provides an official dashboard for metric visualization:\nDashboard: Dashboard: DCGM Exporter Grafana Dashboard #12239 JSON for import: grafana/dcgm-exporter-dashboard.json Just import the JSON into Grafana and start exploring real-time insights.\nTo fully leverage your data, send local Prometheus metrics to a central Prometheus, which connects directly with Grafana, enabling:\nAccurate, real-time visualizations. Actionable insights for strategic decisions. Actionable insights for strategic decisions. Want to know more or implement this integration in your environment? Get in touch and turn your metrics into smart decisions!\nConclusion # With DCGM-Exporter, you can monitor GPUs in on-premise environments or Kubernetes clusters, seamlessly integrating with Prometheus and Grafana.\n","date":"septiembre 18, 2025","externalUrl":null,"permalink":"/blog/en/blog/dcgm-exporter/dcgm-exporter/","section":"Blog","summary":"","title":"Advanced GPU Monitoring with DCGM-Exporter, Prometheus, and Grafana","type":"blog"},{"content":" Introduction # Did you know that every GPU in your environment can generate valuable data? When properly analyzed, these metrics can optimize performance, reduce costs, and accelerate strategic decisions.\nNVIDIA’s DCGM-Exporter allows you to extract detailed GPU metrics, seamlessly integrating with Prometheus and Grafana for smart dashboards and real-time visualizations.\nWhy GPU Monitoring Matters # Many companies miss opportunities by not properly tracking their GPU resources. With strategic monitoring, you can:\nDetect performance bottlenecks before they impact production. Optimize resource usage and reduce costs. Make data-driven decisions instead of relying on assumptions. Monitor multiple clusters in a centralized way. The real value comes when you can centralize metrics and turn them into actionable insights.\nWhat You’ll Learn in This Post # Here you’ll learn, step by step:\nQuickly set up DCGM-Exporter in Docker Deploy in Kubernetes using Helm Chart Integrate metrics into central Prometheus Visualize powerful dashboards in Grafana All with a focus on turning raw metrics into strategic information for your business.\nRunning DCGM-Exporter in Docker # To quickly run DCGM-Exporter on a GPU-enabled machine:\ndocker run -d --gpus all --cap-add SYS_ADMIN --rm -p 9400:9400 \\ nvcr.io/nvidia/k8s/dcgm-exporter:4.4.1-4.5.2-ubuntu22.04 Test the metrics endpoint:\ncurl localhost:9400/metrics Test the metrics endpoint:\n# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz). # TYPE DCGM_FI_DEV_SM_CLOCK gauge DCGM_FI_DEV_SM_CLOCK{gpu=\u0026#34;0\u0026#34;,UUID=\u0026#34;GPU-604ac76c-d9cf-xxx\u0026#34;} 139 Deploying DCGM-Exporter in Kubernetes # NVIDIA maintains an official Helm Chart to install DCGM-Exporter in Kubernetes clusters:\nhelm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helm repo update helm install --generate-name gpu-helm-charts/dcgm-exporter Check the pod:\nkubectl get pods -l \u0026#34;app.kubernetes.io/name=dcgm-exporter\u0026#34; -n default Access metrics locally:\nkubectl port-forward svc/dcgm-exporter 8080:9400 curl http://127.0.0.1:8080/metrics Setting up Local Prometheus in Docker # Add a scrape job to collect DCGM-Exporter metrics in prometheus.yml:\nscrape_configs: - job_name: \u0026#34;dcgm-exporter\u0026#34; static_configs: - targets: [\u0026#34;host.docker.internal:9400\u0026#34;] Use host.docker.internal in Docker Desktop (Windows/Mac). On Linux, replace it with the host machine IP.\nRestart Prometheus:\ndocker run -d --name prometheus --network=host \\ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \\ prom/prometheus Now your DCGM-Exporter metrics will be collected properly.\nGrafana Integration # NVIDIA provides an official dashboard for metric visualization:\nDashboard: Dashboard: DCGM Exporter Grafana Dashboard #12239 JSON for import: grafana/dcgm-exporter-dashboard.json Just import the JSON into Grafana and start exploring real-time insights.\nTo fully leverage your data, send local Prometheus metrics to a central Prometheus, which connects directly with Grafana, enabling:\nAccurate, real-time visualizations. Actionable insights for strategic decisions. Actionable insights for strategic decisions. Want to know more or implement this integration in your environment? Get in touch and turn your metrics into smart decisions!\nConclusion # With DCGM-Exporter, you can monitor GPUs in on-premise environments or Kubernetes clusters, seamlessly integrating with Prometheus and Grafana.\n","date":"septiembre 18, 2025","externalUrl":null,"permalink":"/blog/en/posts/dcgm-exporter/dcgm-exporter/","section":"Posts","summary":"","title":"Advanced GPU Monitoring with DCGM-Exporter, Prometheus, and Grafana","type":"posts"},{"content":" What is a WAF? # The term WAF stands for Web Application Firewall.\nA traditional firewall mainly operates at the network layer, filtering packets based on source IP, destination IP, source port, destination port, and protocol (TCP/UDP/ICMP). In other words, it ensures that only authorized connections reach the server, but it does not understand the content of the traffic.\nThe WAF, however, goes further: it is specifically designed to protect web applications. Instead of only analyzing addresses and ports, the WAF inspects the content of HTTP/HTTPS requests. This allows it to identify and block malicious access attempts that a traditional firewall would miss.\nExamples of threats a WAF helps mitigate # SQL Injection – when malicious SQL commands are sent to manipulate databases. Cross-Site Scripting (XSS) – injection of scripts that can steal user data. Malicious bots – attempting to exploit vulnerabilities or overload the application. Brute force – automated attempts to guess usernames and passwords. In summary # Traditional firewall = focuses on network → controls who can connect (based on IP, ports, and protocols). WAF = focuses on web applications → analyzes what’s inside the request and protects against attacks targeting site functionality. In other words, the WAF acts as a shield between the internet and your web application, blocking threats before they can cause damage.\nWhat is CrowdSec? # CrowdSec is the WAF we use here at Gole.\nIt is an open-source, collaborative, and modern solution that not only protects your application in real time but also learns from attacks occurring elsewhere in the world.\nThat means: when a malicious IP is detected in one environment, the entire CrowdSec community can benefit and block that same IP.\nHow does CrowdSec work? # The process is simple to understand:\nMonitors logs from services such as Nginx, Traefik, SSH, web applications. Detects suspicious behavior (brute force, scans, abuses). Automatically blocks malicious IPs. Shares this information anonymously, strengthening the protection network. CrowdSec\nKey Features # Real-time monitoring: captures logs from services like Nginx, Traefik, SSH, and more. Attack and abuse detection: identifies brute force, scans, and anomalous behavior. Automatic IP blocking: applies local or remote sanctions, protecting your applications. Step by Step: Configuring CrowdSec in Kubernetes # 1. Add the Helm repository and get default values** # helm repo add crowdsec https://crowdsecurity.github.io/helm-charts helm repo update helm show values crowdsec/crowdsec \u0026gt; crowdsec-default-values.yaml 2. Edit the crowdsec-default-values.yaml file # a) Configure log acquisition (Traefik) # agent: acquisition: - namespace: traefik podName: traefik-* program: traefik b) Instance registration (LAPI) # lapi: env: - name: ENROLL_KEY value: \u0026#34;YOUR_ENROLL_KEY\u0026#34; - name: ENROLL_INSTANCE_NAME value: \u0026#34;my-k8s-cluster\u0026#34; - name: ENROLL_TAGS value: \u0026#34;k8s linux production\u0026#34; c) Persistent volumes # persistentVolume: data: enabled: true storageClassName: \u0026#34;your-storage-class-name\u0026#34; size: 1Gi config: enabled: true storageClassName: \u0026#34;your-storage-class-name\u0026#34; size: 100Mi 3. Create namespace # kubectl create ns crowdsec 4. Install CrowdSec # helm install crowdsec crowdsec/crowdsec -n crowdsec -f crowdsec-default-values.yaml 5. Configure bouncers (Traefik and Nginx) # a) Create API Key # kubectl -n crowdsec exec -it crowdsec-lapi-* -- sh cscli bouncers add traefik b) Configure middleware in Traefik # apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: bouncer namespace: traefik spec: plugin: bouncer: CrowdsecLapiKey: \u0026lt;YOUR_API_KEY\u0026gt; crowdsecLapiHost: \u0026#34;crowdsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecLapiPort: \u0026#34;8080\u0026#34; crowdsecAppsecHost: \u0026#34;crowdsec-appsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecAppsecPort: \u0026#34;7422\u0026#34; crowdsecAppsecScheme: http Enabled: true logLevel: DEBUG crowdsecMode: appsec c) Configure bouncer in Nginx # controller: extraInitContainers: - name: init-clone-crowdsec-bouncer image: crowdsecurity/lua-bouncer-plugin env: - name: API_URL value: \u0026#34;http://crowdsec-service.crowdsec.svc.cluster.local:8080\u0026#34; - name: API_KEY value: \u0026#34;\u0026lt;API KEY\u0026gt;\u0026#34; - name: BOUNCER_CONFIG value: \u0026#34;/crowdsec/crowdsec-bouncer.conf\u0026#34; 6. Enable AppSec (WAF) # appsec: enabled: true acquisitions: - source: appsec listen_addr: \u0026#34;0.0.0.0:7422\u0026#34; path: / appsec_config: crowdsecurity/crs-vpatch labels: type: appsec env: - name: COLLECTIONS value: \u0026#34;crowdsecurity/appsec-wordpress\u0026#34; Advanced Monitoring with Grafana # The CrowdSec console has a limit of 500 alerts, which can restrict the visibility of events in high-traffic environments. For a complete and detailed monitoring, we created a Grafana dashboard that allows you to observe IP blocks, attacks, and security decisions in real-time.\nThis dashboard includes:\nBlock Total for Pods: Number of blocked attempts per pod, helping to identify which pods are under the most attacks. Attacks by Scenarios: Distribution of attacks based on CrowdSec detection scenarios, showing the most frequent threat types. Total Ban by IP: List of blocked IPs, the scenario, and total occurrences, allowing easy tracking of malicious sources. Decisions Log: Detailed decision logs with timestamps and request data, providing full transparency of CrowdSec actions. Access the dashboard: CrowdSec Monitoring on Grafana\nThis feature is essential for security teams to monitor, analyze, and respond quickly to threats in the infrastructure.\nConclusion # With these configurations, CrowdSec is integrated into your Kubernetes cluster, monitoring logs, registering instances, and protecting your applications with Traefik, Nginx, and WAF AppSec.\nAccess the console: https://app.crowdsec.net/security-engines\n","date":"agosto 29, 2025","externalUrl":null,"permalink":"/blog/en/blog/crowdsec/crowdsec/","section":"Blog","summary":"","title":"CrowdSec - What is a WAF and how to configure it in Kubernetes","type":"blog"},{"content":" What is a WAF? # The term WAF stands for Web Application Firewall.\nA traditional firewall mainly operates at the network layer, filtering packets based on source IP, destination IP, source port, destination port, and protocol (TCP/UDP/ICMP). In other words, it ensures that only authorized connections reach the server, but it does not understand the content of the traffic.\nThe WAF, however, goes further: it is specifically designed to protect web applications. Instead of only analyzing addresses and ports, the WAF inspects the content of HTTP/HTTPS requests. This allows it to identify and block malicious access attempts that a traditional firewall would miss.\nExamples of threats a WAF helps mitigate # SQL Injection – when malicious SQL commands are sent to manipulate databases. Cross-Site Scripting (XSS) – injection of scripts that can steal user data. Malicious bots – attempting to exploit vulnerabilities or overload the application. Brute force – automated attempts to guess usernames and passwords. In summary # Traditional firewall = focuses on network → controls who can connect (based on IP, ports, and protocols). WAF = focuses on web applications → analyzes what’s inside the request and protects against attacks targeting site functionality. In other words, the WAF acts as a shield between the internet and your web application, blocking threats before they can cause damage.\nWhat is CrowdSec? # CrowdSec is the WAF we use here at Gole.\nIt is an open-source, collaborative, and modern solution that not only protects your application in real time but also learns from attacks occurring elsewhere in the world.\nThat means: when a malicious IP is detected in one environment, the entire CrowdSec community can benefit and block that same IP.\nHow does CrowdSec work? # The process is simple to understand:\nMonitors logs from services such as Nginx, Traefik, SSH, web applications. Detects suspicious behavior (brute force, scans, abuses). Automatically blocks malicious IPs. Shares this information anonymously, strengthening the protection network. CrowdSec\nKey Features # Real-time monitoring: captures logs from services like Nginx, Traefik, SSH, and more. Attack and abuse detection: identifies brute force, scans, and anomalous behavior. Automatic IP blocking: applies local or remote sanctions, protecting your applications. Step by Step: Configuring CrowdSec in Kubernetes # 1. Add the Helm repository and get default values** # helm repo add crowdsec https://crowdsecurity.github.io/helm-charts helm repo update helm show values crowdsec/crowdsec \u0026gt; crowdsec-default-values.yaml 2. Edit the crowdsec-default-values.yaml file # a) Configure log acquisition (Traefik) # agent: acquisition: - namespace: traefik podName: traefik-* program: traefik b) Instance registration (LAPI) # lapi: env: - name: ENROLL_KEY value: \u0026#34;YOUR_ENROLL_KEY\u0026#34; - name: ENROLL_INSTANCE_NAME value: \u0026#34;my-k8s-cluster\u0026#34; - name: ENROLL_TAGS value: \u0026#34;k8s linux production\u0026#34; c) Persistent volumes # persistentVolume: data: enabled: true storageClassName: \u0026#34;your-storage-class-name\u0026#34; size: 1Gi config: enabled: true storageClassName: \u0026#34;your-storage-class-name\u0026#34; size: 100Mi 3. Create namespace # kubectl create ns crowdsec 4. Install CrowdSec # helm install crowdsec crowdsec/crowdsec -n crowdsec -f crowdsec-default-values.yaml 5. Configure bouncers (Traefik and Nginx) # a) Create API Key # kubectl -n crowdsec exec -it crowdsec-lapi-* -- sh cscli bouncers add traefik b) Configure middleware in Traefik # apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: bouncer namespace: traefik spec: plugin: bouncer: CrowdsecLapiKey: \u0026lt;YOUR_API_KEY\u0026gt; crowdsecLapiHost: \u0026#34;crowdsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecLapiPort: \u0026#34;8080\u0026#34; crowdsecAppsecHost: \u0026#34;crowdsec-appsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecAppsecPort: \u0026#34;7422\u0026#34; crowdsecAppsecScheme: http Enabled: true logLevel: DEBUG crowdsecMode: appsec c) Configure bouncer in Nginx # controller: extraInitContainers: - name: init-clone-crowdsec-bouncer image: crowdsecurity/lua-bouncer-plugin env: - name: API_URL value: \u0026#34;http://crowdsec-service.crowdsec.svc.cluster.local:8080\u0026#34; - name: API_KEY value: \u0026#34;\u0026lt;API KEY\u0026gt;\u0026#34; - name: BOUNCER_CONFIG value: \u0026#34;/crowdsec/crowdsec-bouncer.conf\u0026#34; 6. Enable AppSec (WAF) # appsec: enabled: true acquisitions: - source: appsec listen_addr: \u0026#34;0.0.0.0:7422\u0026#34; path: / appsec_config: crowdsecurity/crs-vpatch labels: type: appsec env: - name: COLLECTIONS value: \u0026#34;crowdsecurity/appsec-wordpress\u0026#34; Advanced Monitoring with Grafana # The CrowdSec console has a limit of 500 alerts, which can restrict the visibility of events in high-traffic environments. For a complete and detailed monitoring, we created a Grafana dashboard that allows you to observe IP blocks, attacks, and security decisions in real-time.\nThis dashboard includes:\nBlock Total for Pods: Number of blocked attempts per pod, helping to identify which pods are under the most attacks. Attacks by Scenarios: Distribution of attacks based on CrowdSec detection scenarios, showing the most frequent threat types. Total Ban by IP: List of blocked IPs, the scenario, and total occurrences, allowing easy tracking of malicious sources. Decisions Log: Detailed decision logs with timestamps and request data, providing full transparency of CrowdSec actions. Access the dashboard: CrowdSec Monitoring on Grafana\nThis feature is essential for security teams to monitor, analyze, and respond quickly to threats in the infrastructure.\nConclusion # With these configurations, CrowdSec is integrated into your Kubernetes cluster, monitoring logs, registering instances, and protecting your applications with Traefik, Nginx, and WAF AppSec.\nAccess the console: https://app.crowdsec.net/security-engines\n","date":"agosto 29, 2025","externalUrl":null,"permalink":"/blog/en/posts/crowdsec/crowdsec/","section":"Posts","summary":"","title":"CrowdSec - What is a WAF and how to configure it in Kubernetes","type":"posts"},{"content":" How to extract the certificate and key from a PFX file # First, use the command below to extract only the key from the .pfx file:\nopenssl pkcs12 -in [yourfile.pfx] -nocerts -out [drlive.key] After executing the command, you will be prompted for the password used to generate the .pfx file. You will need to enter it three times.\nOnce the key has been extracted and saved to a file, we can now extract the certificate from the .pfx file using the following command:\nopenssl pkcs12 -in [yourfile.pfx] -clcerts -nokeys -out [drlive.crt] After execution, you will be prompted again for the password used during the creation of the .pfx file.\nNow, with the .key and .crt files in hand, let’s decrypt the .key file using the following command:\nopenssl rsa -in [drlive.key] -out [drlive-decrypted.key] As in the previous steps, the password will be requested.\nAfter this process, you will have the following files: file.key, file.crt, and file-decrypted.key.\nHow to create a PFX file from a certificate # With all the necessary components ready, we can now generate a .pfx file.\nFirst, concatenate all your .crt files into a single file, since the creation of a .pfx file only accepts one certificate. Use the following command:\ncat \u0026lt;hostname_certificate\u0026gt;.crt \u0026lt;arquivo CA\u0026gt;.crt \u0026lt;arquivo USER\u0026gt;.crt \u0026lt;arquivo AAA\u0026gt;.crt \u0026gt;\u0026gt; arquivo-full.crt After concatenating all the certificates into one file, we can proceed to create the .pfx file.\nTo generate it, use the following OpenSSL command:\nopenssl pkcs12 -export -out \u0026lt;name_do_arquivo\u0026gt;.pfx -inkey \u0026lt;arquivo-decrypted\u0026gt;.key -in \u0026lt;arquivo-full\u0026gt;.crt During the execution of the command, you will be prompted to set a password. Then, you will be asked to confirm it — simply enter the same password again.\nReference: https://www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file.\n","date":"noviembre 3, 2023","externalUrl":null,"permalink":"/blog/en/blog/pfx-certification/pfx-certificate/","section":"Blog","summary":"","title":"PFX Certification","type":"blog"},{"content":" How to extract the certificate and key from a PFX file # First, use the command below to extract only the key from the .pfx file:\nopenssl pkcs12 -in [yourfile.pfx] -nocerts -out [drlive.key] After executing the command, you will be prompted for the password used to generate the .pfx file. You will need to enter it three times.\nOnce the key has been extracted and saved to a file, we can now extract the certificate from the .pfx file using the following command:\nopenssl pkcs12 -in [yourfile.pfx] -clcerts -nokeys -out [drlive.crt] After execution, you will be prompted again for the password used during the creation of the .pfx file.\nNow, with the .key and .crt files in hand, let’s decrypt the .key file using the following command:\nopenssl rsa -in [drlive.key] -out [drlive-decrypted.key] As in the previous steps, the password will be requested.\nAfter this process, you will have the following files: file.key, file.crt, and file-decrypted.key.\nHow to create a PFX file from a certificate # With all the necessary components ready, we can now generate a .pfx file.\nFirst, concatenate all your .crt files into a single file, since the creation of a .pfx file only accepts one certificate. Use the following command:\ncat \u0026lt;hostname_certificate\u0026gt;.crt \u0026lt;arquivo CA\u0026gt;.crt \u0026lt;arquivo USER\u0026gt;.crt \u0026lt;arquivo AAA\u0026gt;.crt \u0026gt;\u0026gt; arquivo-full.crt After concatenating all the certificates into one file, we can proceed to create the .pfx file.\nTo generate it, use the following OpenSSL command:\nopenssl pkcs12 -export -out \u0026lt;name_do_arquivo\u0026gt;.pfx -inkey \u0026lt;arquivo-decrypted\u0026gt;.key -in \u0026lt;arquivo-full\u0026gt;.crt During the execution of the command, you will be prompted to set a password. Then, you will be asked to confirm it — simply enter the same password again.\nReference: https://www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file.\n","date":"noviembre 3, 2023","externalUrl":null,"permalink":"/blog/en/posts/pfx-certification/pfx-certificate/","section":"Posts","summary":"","title":"PFX Certification","type":"posts"},{"content":" Running self-hosted bitbucket runners on Kubernetes # Runners allow you to run pipelines from your repositories. Bitbucket allows you to host these runners in your own infrastructure, the so-called self-hosted runners.\nIn this article, we\u0026rsquo;ll walk you through how to create a workspace-level self-hosted runner and run it on Kubernetes.\nCreating a runner in bitbucket # The first step is to create a new runner. Let\u0026rsquo;s create it at workspace level:\nNavigate to your profile and click on the workspace you want.\nClick on settings and select workspace runners.\nAdd runner.\nDefine the name for the runner and a label. The labels self.hosted and linux are defaults, we need to add a new label so we can identify in the pipeline which runner the build should be executed in, if there are other runners created.\nClick on next. Output will be generated with the following docker command:\ndocker container run -it -v /tmp:/tmp -v /var/run/docker.sock:/var/run/docker.sock \\ -v /var/lib/docker/containers:/var/lib/docker/containers:ro \\ -e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ --name runner-87c1a9ae-c216-5512-a92d-12fb95f77f0b \\ docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1 Copy this command, as we are going to use the values of the variables presented for the configuration of our self-hosted runner and click on finish.\nNotice that the runner was created in the workspace, but its status is set to UNREGISTRED. After configuring the runner and running it in the Kubernetes environment, its status will change to ONLINE.\nKubernetes Configuration # The next step is to build the kubernetes files to host runner.\nFirst let\u0026rsquo;s handle the variables given by the command:\n-e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ Copy the value of the variables ACCOUNT_UUID RUNNER_UUID* without the { }.\nThe variables OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET must be converted to base64\necho -n OAUTH_CLIENT_ID | base64 echo -n OAUTH_CLIENT_SECRET | base64 Once this is done, we move on to the stage of building the Kubernetes files:\nsecret.yaml\njob.yaml\nAdd variable values:\nsecret.yaml # apiVersion: v1 kind: Secret metadata: name: runner-01-oauth-credentials labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} data: oauthClientId: {OAUTH_CLIENT_ID} oauthClientSecret: {OAUTH_CLIENT_SECRET} job.yaml # Important: In the job.yaml file the accountUuid and runnerUuid variables, in the \u0026lsquo;container variables\u0026rsquo; section, must be added between “ ” and { }, in this way “{ACCOUNT_UUID}”\napiVersion: batch/v1 kind: Job metadata: name: runner-01 spec: template: metadata: labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} spec: containers: - name: bitbucket-runner-01 image: docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner env: - name: ACCOUNT_UUID value: “{${ACCOUNT_UUID}}” - name: RUNNER_UUID value: “{${RUNNER_UUID}}” - name: RUNTIME_PREREQUISITES_ENABLED value: true - name: WORKING_DIRECTORY value: \u0026#34;/tmp\u0026#34; - name: OAUTH_CLIENT_ID valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientId - name: OAUTH_CLIENT_SECRET valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientSecret volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers readOnly: true - name: var-run mountPath: /var/run - name: docker-in-docker image: docker:20.10.7-dind securityContext: privileged: true volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers - name: var-run mountPath: /var/run restartPolicy: OnFailure volumes: - name: tmp - name: docker-containers - name: var-run backoffLimit: 6 completions: 1 parallelism: 1 Now let\u0026rsquo;s apply the configurations built above.\nkubectl -n namespace apply -f secrets.yaml kubectl -n namespace apply -f job.yaml Testing the new runner # pipelines: branches: \u0026#39;main\u0026#39;: - step: runs-on: my.custom.label script: - echo \u0026#34;Hello world\u0026#34; Your self-hosted runner is ready!\nFor more information about runners visit the bitbucket documentation runners.\nNeed help? # Access our page Contact and chat with us.\nSuccess!\nAdditional reading: # Pipelines runners frequently asked questions\n","date":"julio 29, 2022","externalUrl":null,"permalink":"/blog/en/blog/bitbucket-runner/kubernetes-bitbucket-guide/","section":"Blog","summary":"","title":"Bitbucket 'self-hosted' runner in Kubernetes environment","type":"blog"},{"content":" Running self-hosted bitbucket runners on Kubernetes # Runners allow you to run pipelines from your repositories. Bitbucket allows you to host these runners in your own infrastructure, the so-called self-hosted runners.\nIn this article, we\u0026rsquo;ll walk you through how to create a workspace-level self-hosted runner and run it on Kubernetes.\nCreating a runner in bitbucket # The first step is to create a new runner. Let\u0026rsquo;s create it at workspace level:\nNavigate to your profile and click on the workspace you want.\nClick on settings and select workspace runners.\nAdd runner.\nDefine the name for the runner and a label. The labels self.hosted and linux are defaults, we need to add a new label so we can identify in the pipeline which runner the build should be executed in, if there are other runners created.\nClick on next. Output will be generated with the following docker command:\ndocker container run -it -v /tmp:/tmp -v /var/run/docker.sock:/var/run/docker.sock \\ -v /var/lib/docker/containers:/var/lib/docker/containers:ro \\ -e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ --name runner-87c1a9ae-c216-5512-a92d-12fb95f77f0b \\ docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1 Copy this command, as we are going to use the values of the variables presented for the configuration of our self-hosted runner and click on finish.\nNotice that the runner was created in the workspace, but its status is set to UNREGISTRED. After configuring the runner and running it in the Kubernetes environment, its status will change to ONLINE.\nKubernetes Configuration # The next step is to build the kubernetes files to host runner.\nFirst let\u0026rsquo;s handle the variables given by the command:\n-e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ Copy the value of the variables ACCOUNT_UUID RUNNER_UUID* without the { }.\nThe variables OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET must be converted to base64\necho -n OAUTH_CLIENT_ID | base64 echo -n OAUTH_CLIENT_SECRET | base64 Once this is done, we move on to the stage of building the Kubernetes files:\nsecret.yaml\njob.yaml\nAdd variable values:\nsecret.yaml # apiVersion: v1 kind: Secret metadata: name: runner-01-oauth-credentials labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} data: oauthClientId: {OAUTH_CLIENT_ID} oauthClientSecret: {OAUTH_CLIENT_SECRET} job.yaml # Important: In the job.yaml file the accountUuid and runnerUuid variables, in the \u0026lsquo;container variables\u0026rsquo; section, must be added between “ ” and { }, in this way “{ACCOUNT_UUID}”\napiVersion: batch/v1 kind: Job metadata: name: runner-01 spec: template: metadata: labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} spec: containers: - name: bitbucket-runner-01 image: docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner env: - name: ACCOUNT_UUID value: “{${ACCOUNT_UUID}}” - name: RUNNER_UUID value: “{${RUNNER_UUID}}” - name: RUNTIME_PREREQUISITES_ENABLED value: true - name: WORKING_DIRECTORY value: \u0026#34;/tmp\u0026#34; - name: OAUTH_CLIENT_ID valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientId - name: OAUTH_CLIENT_SECRET valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientSecret volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers readOnly: true - name: var-run mountPath: /var/run - name: docker-in-docker image: docker:20.10.7-dind securityContext: privileged: true volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers - name: var-run mountPath: /var/run restartPolicy: OnFailure volumes: - name: tmp - name: docker-containers - name: var-run backoffLimit: 6 completions: 1 parallelism: 1 Now let\u0026rsquo;s apply the configurations built above.\nkubectl -n namespace apply -f secrets.yaml kubectl -n namespace apply -f job.yaml Testing the new runner # pipelines: branches: \u0026#39;main\u0026#39;: - step: runs-on: my.custom.label script: - echo \u0026#34;Hello world\u0026#34; Your self-hosted runner is ready!\nFor more information about runners visit the bitbucket documentation runners.\nNeed help? # Access our page Contact and chat with us.\nSuccess!\nAdditional reading: # Pipelines runners frequently asked questions\n","date":"julio 29, 2022","externalUrl":null,"permalink":"/blog/en/posts/bitbucket-runner/kubernetes-bitbucket-guide/","section":"Posts","summary":"","title":"Bitbucket 'self-hosted' runner in Kubernetes environment","type":"posts"},{"content":" Operational intelligence is an IT area responsible for defining the solutions, tools and methodology that will be adopted in order to create a monitoring standard, and consequently a standard for SLA consultation, reports and access to metrics and logs from the business platforms.\nAmong the functions of operational intelligence are:\n1- Contemplate all layers of the business: Everything that is important for the functioning of the business must be mapped;\n2- Define the appropriate tools for each area;\n3- Creation and propagation of methodologies, procedures and technical actions;\n4- Documentation for the implementation and use of the adopted tools.\nThe importance of monitoring\nMetrics and logs collected by monitoring tools form the basis for a platform to evolve and have its incidents resolved.\nThe \u0026ldquo;real evidence\u0026rdquo; of the results of IT decisions. are taken from the dashboards provided by these tools.\nMonitoring works 24x7 and when properly configured it is able to predict incidents and support the team.\nIn case of unavailability, it is able to alert the group responsible for the solution, and when mature, it can perform routine procedures, executing actions and interacting with the environment.\nIt is also the one that validates the SLA and feeds Management\u0026rsquo;s availability reports.\nThe main phases of monitoring # Implementation # The implementation process consists of ensuring that all layers and applications are monitored and reporting correctly:\nServers and Services;\nSystems and applications;\nSimulation of the real flow of data (business monitoring).\nWhether cloud or on-premises, dashboards and reports must consider all the layers above.\nOnce this structure is set up, we must ensure that the monitoring is integrated with the other systems of the company. Examples: backup systems and systems, authentication systems and access groups.\nValidations of the other teams # This is an important moment, where the support of the main stakeholders, as well as a good relationship between areas count positively.\nUsing good tools, simple and automated implementation flows are important to ensure long-term success.\nIn this step, the main mission is to ensure that all areas know the importance of keeping this implemented base standardized, enabling standardized and centralized reports and dashboards.\nValidation of reports # When less is more. Management levels know what they need, and not bringing unnecessary information means agility and clarity.\nOne meeting is enough in order to find out what information is needed to help populate the KPIs.\nThe important thing is to ensure that, in the event of an incident, the data needed to investigate the problem will be present without delay.\nFeedback # The beginning and end of the cycle.\nAt this moment we take all the considerations, errors, improvements and new needs to our backlog. Defining times and priorities and we go back to step 1, then to step 2 and so on and on and on.\nFinal considerations # We hope that the reading was fruitful and that the benefits and importance of monitoring and an operational intelligence team became clear.\nGole relies on the Operational Intelligence service and has experience participating in and implementing monitoring systems both for operations that have an in-house or outsourced NOC (Network Operations Center), as well as companies that do not have a 24x7 team, although in both In the scenarios there are applications that are 24x7 and need an SLA greater than 99.8%.\n","date":"mayo 30, 2022","externalUrl":null,"permalink":"/blog/en/blog/operational-intelligence/operational-intelligence/","section":"Blog","summary":"","title":"Operational intelligence","type":"blog"},{"content":" Operational intelligence is an IT area responsible for defining the solutions, tools and methodology that will be adopted in order to create a monitoring standard, and consequently a standard for SLA consultation, reports and access to metrics and logs from the business platforms.\nAmong the functions of operational intelligence are:\n1- Contemplate all layers of the business: Everything that is important for the functioning of the business must be mapped;\n2- Define the appropriate tools for each area;\n3- Creation and propagation of methodologies, procedures and technical actions;\n4- Documentation for the implementation and use of the adopted tools.\nThe importance of monitoring\nMetrics and logs collected by monitoring tools form the basis for a platform to evolve and have its incidents resolved.\nThe \u0026ldquo;real evidence\u0026rdquo; of the results of IT decisions. are taken from the dashboards provided by these tools.\nMonitoring works 24x7 and when properly configured it is able to predict incidents and support the team.\nIn case of unavailability, it is able to alert the group responsible for the solution, and when mature, it can perform routine procedures, executing actions and interacting with the environment.\nIt is also the one that validates the SLA and feeds Management\u0026rsquo;s availability reports.\nThe main phases of monitoring # Implementation # The implementation process consists of ensuring that all layers and applications are monitored and reporting correctly:\nServers and Services;\nSystems and applications;\nSimulation of the real flow of data (business monitoring).\nWhether cloud or on-premises, dashboards and reports must consider all the layers above.\nOnce this structure is set up, we must ensure that the monitoring is integrated with the other systems of the company. Examples: backup systems and systems, authentication systems and access groups.\nValidations of the other teams # This is an important moment, where the support of the main stakeholders, as well as a good relationship between areas count positively.\nUsing good tools, simple and automated implementation flows are important to ensure long-term success.\nIn this step, the main mission is to ensure that all areas know the importance of keeping this implemented base standardized, enabling standardized and centralized reports and dashboards.\nValidation of reports # When less is more. Management levels know what they need, and not bringing unnecessary information means agility and clarity.\nOne meeting is enough in order to find out what information is needed to help populate the KPIs.\nThe important thing is to ensure that, in the event of an incident, the data needed to investigate the problem will be present without delay.\nFeedback # The beginning and end of the cycle.\nAt this moment we take all the considerations, errors, improvements and new needs to our backlog. Defining times and priorities and we go back to step 1, then to step 2 and so on and on and on.\nFinal considerations # We hope that the reading was fruitful and that the benefits and importance of monitoring and an operational intelligence team became clear.\nGole relies on the Operational Intelligence service and has experience participating in and implementing monitoring systems both for operations that have an in-house or outsourced NOC (Network Operations Center), as well as companies that do not have a 24x7 team, although in both In the scenarios there are applications that are 24x7 and need an SLA greater than 99.8%.\n","date":"mayo 30, 2022","externalUrl":null,"permalink":"/blog/en/posts/operational-intelligence/operational-intelligence/","section":"Posts","summary":"","title":"Operational intelligence","type":"posts"},{"content":" How to lower the cost of kubernetes GKE by killing nodes in specific time windows without using any external tool or API.\nThe problem # Our problem arises when we have a test environment (QA) that is only used during business hours and being connected 24x7 generates an unnecessary cost.\nProposed solution # Shutting down the test environment outside office hours, eliminating nodes from our cluster. Arriving close to the start of business hours, these nodes must be created and the test environment must return to operation.\nDependencies for this solution # For this to be possible we need to have three configuration points:\n1- A separate “node pool” that can be eliminated without affecting production. To make this configuration more effective you can include Taints and Tolerantios.\n2- A common label for all deploys/sts that may be shut down at this time. Example: \u0026ldquo;scheduler=comercial\u0026rdquo;\n3- Know the list of namespaces that contain the deploys/sts that will be deactivated.\nPrevious implementation steps # We need to make sure the nodes and deploys are configured correctly.\nNode-pool and deployments and/or statefulsets validation # Let\u0026rsquo;s first list our node pools and validate that our environment is prepared:\n\u0026gt; gcloud container node-pools list --cluster us-gole-01 NAME MACHINE_TYPE DISK_SIZE_GB NODE_VERSION pool-main c2-standard-8 100 1.20.10-gke.1600 pool-qa e2-standard-8 80 1.20.10-gke.1600 If the node-pool does not exist, it is necessary to create this node pool with the corresponding number of nodes, which can only be one, and add the taint:\nCreating node pool with taint If the node-pool already exists but does not have the necessary taint, then use the gcloud feature still in beta to add the taint:\n\u0026gt; gcloud beta container node-pools update pool-qa --node-taints=\u0026#39;scheduler=comercial:NoSchedule\u0026#39; Now let\u0026rsquo;s validate that all the deploys we want contain the necessary labels.\nIn this example we won\u0026rsquo;t have statefulset in our list, but logically it fits perfectly.\n\u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-a deployment.apps/gole-sonarcube 1/1 1 1 34d namespace-a deployment.apps/gole-redis 1/1 1 1 34d namespace-a deployment.apps/gole-nodejs-app 1/1 1 1 34d \u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-b deployment.apps/gole-netbox-worker 1/1 1 1 34d namespace-b deployment.apps/gole-netbox 1/1 1 1 7d18h Adding tolerations in deploy # We need to make sure the deploys are configured correctly\n❯ kubectl -n namespace-a get deploy -l scheduler=comercial -o=jsonpath=\u0026#39;{.spec.template.spec.tolerations}\u0026#39; The output should be an object like this below times the number of existing deploys. They will all be within the same list, but looking at the list it is possible to observe easily.\n{\u0026#34;effect\u0026#34;:\u0026#34;PreferNoSchedule\u0026#34;,\u0026#34;key\u0026#34;:\u0026#34;scheduler\u0026#34;,\u0026#34;operator\u0026#34;:\u0026#34;Equal\u0026#34;,\u0026#34;value\u0026#34;:\u0026#34;comercial\u0026#34;} Here is an example of where tolerations should be configured:\napiVersion: apps/v1 kind: Deployment metadata: name: gole-app labels: scheduler: comercial app: gole-app tier: api-extended spec: progressDeadlineSeconds: 600 replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: scheduler: comercial app: gole-app tier: api-extended strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: labels: scheduler: comercial app: gole-app tier: api-extended spec: tolerations: - key: \u0026#34;scheduler\u0026#34; operator: \u0026#34;Equal\u0026#34; value: \u0026#34;comercial\u0026#34; effect: \u0026#34;PreferNoSchedule\u0026#34; containers: Final validation # we have labels on deployments? yes\nDo we have a node pool with a taint configured? yes\nDo we have tolerances set in our deployments? yes\nSo now we can get started.\nImplementation # For the implementation of the solution we will need to create some resources:\nSecrets\nCronjob\nSecret key.json # Our secret will be the file renamed to key.json generated in service account, keys inside IAM.\nLogically this system user should have permission to administer the kubernetes cluster using the gcloud sdk.\nkey.json \u0026gt; cat key.json { \u0026#34;type\u0026#34;: \u0026#34;service_account\u0026#34;, \u0026#34;project_id\u0026#34;: \u0026#34;gole-autoscaling-sample\u0026#34;, \u0026#34;private_key_id\u0026#34;: \u0026#34;asdfasdfasdfasdasdfasdasdf....\u0026#34;, \u0026#34;private_key\u0026#34;: \u0026#34;-----BEGIN PRIVATE KEY-----\\ndasdfasdf393993..asdfsf.aksdflksjdflksjfkjafljasdjkf....Ijr7ZCBgpbQrDH\\nvNUw/JxaVbLtpvy3KSmYpjGfKnHFs+wPQi+NFmwrdOZHvKjdtRNxHvPqgWNxCSAh\\nMwEB8cKs0dzif1Hbg7EtYrZOR8g7LZrTD3c4lTsahMyI9x3kN0aCe5QXDXvtPEJ1\\n3s5XFBriQc1tmHwMEV4VW8s=CONTINUA....\\n-----END PRIVATE KEY-----\\n\u0026#34;, \u0026#34;client_email\u0026#34;: \u0026#34;infra@golesuite.com\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;11223344556677889900\u0026#34;, \u0026#34;auth_uri\u0026#34;: \u0026#34;https://accounts.google.com/o/oauth2/auth\u0026#34;, \u0026#34;token_uri\u0026#34;: \u0026#34;https://oauth2.googleapis.com/token\u0026#34;, \u0026#34;auth_provider_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/oauth2/v1/certs\u0026#34;, \u0026#34;client_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/robot/v1/metadata/x509/blablabla\u0026#34; } Let\u0026rsquo;s then add this file as a secret in a specific namespace for our automation.\n\u0026gt; kubectl -n devops create secret generic gcloud-key --from-file=./key.json Checking the created key:\n\u0026gt; kubectl -n devops get secret gcloud-key -o=jsonpath=\u0026#39;{.data.key\\.json}\u0026#39; | base64 -d Note: Ensure that only administrators can view the content of the used namespace. In this case we will use the devops namespace\nCreating our Cronjob # Let\u0026rsquo;s now create a yaml file that uses kind Cronjob.\nOur cronjob is set to:\nStart at 07:30h from Monday to Friday.\nShut down at 19:00 from Monday to Friday.\napiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-shutdown namespace: devops spec: schedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;0\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;sheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key --- apiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-startup namespace: devops spec: schedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key You can see that our cronjob uses two external mount points:\ntz-config\ngcloud-key\nOur tz-config is a pointer to the zoneinfo file found on any OS. Linux, in this case we are communicating to our cronjob that your time zone is America/Sao_Paulo.\nOur gcloud-key uses the secret model, and this is where we will link to the secret created in the previous step.\nCronjob ENV Variables # ENV Variables Required example value SCALE_DEPLOY_NUMBER X 0 SCALE_STS_NUMBER X 0 SCALE_NODES_NUMBER X 0 PROJECT_ID X gole CLUSTER_NAME X br-gole-01 GCLOUD_ZONE X southamerica-east1-a SCHEDULER_LABEL X scheduler=comercial SCHEDULER_POOL X pool-qa Before creating and applying the cronjob file we must change the value of the variables.\nThis is located within env:\nenv: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; Once all the steps have been followed, we are ready to apply our cronjob.\nI would just like to tell you where the commands are that actually do the work of bringing down and uploading the environment, since all we\u0026rsquo;ve done so far is just preparing the infrastructure.\nWhat commands are we going to run? # The commands that will be executed to perform the autoscaling task are described in this git project (it\u0026rsquo;s the same project):\nhttps://github.com/golesuite/gcloud-gke-scheduling\nhttps://gitlab.com/gole-group/community/gcloud-gke-scheduling\nThe alpine-gcloud.sh file is being called within Cronjob in the commands session.\nThe content of the file contains the sequence of commands that will do our job.\nThere are two main steps:\n1- shutdown.\nScale the deploys that contain the declared labels to 0;\nScale node pool nodes containing taints to 0.\n2- startup\nScale deploys containing declared labels to 1 or more;\nScale node pool nodes containing taints to 1 or more.\nEverything else that we create contains the structure that we will use so that these commands can be executed from within our cluster.\nApplying the cronjob. # Since we\u0026rsquo;ve already saved our cronjob file locally, and we\u0026rsquo;ve already modified the variables, times and namespaces, let\u0026rsquo;s apply them.\nNote that the cronjob execution times point to 3h more, this is because the control APIs of the GKE nodes use UTC time. Since TZ values for cronjobs are still in beta, the safest thing is to add an extra 3h and we\u0026rsquo;ll arrive at the correct time.\nThat is, if you want 8h and you are in a city GMT -3, then 8 + 3 = 11.\nTo start we will have (07:30h):\nschedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; To turn off (19:00h):\nschedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; \u0026gt; kubectl apply -f cronjob.yaml \u0026gt; kubectl -n devops get cronjob When it runs we will have a job running:\n\u0026gt; kubectl -n devops get job Logically, the job starts a pod and with that we can follow the logs.\nTests # Change the times so that they run at times when you are working, in order to validate that the processes run correctly.\nFinal considerations # This article includes:\nkubernetes Google GKE\ngcloud\nnode-pools\ntaints\nauto-scaling\nCronjobs\ncontainer commands\ncontainer env variables\nThere are many ways to create and administer a Kubernetes cluster, so don\u0026rsquo;t limit yourself to creating different solutions or ways to apply your solutions.\nUse and abuse the resources of the APIs.\nNeed help? # Access our page Contact and chat with us. We will be happy to serve you.\nSuccess!\n","date":"enero 3, 2022","externalUrl":null,"permalink":"/blog/en/blog/automatic-scheduler-gke/","section":"Blog","summary":"","title":"GKE Scheduler Autoscaling","type":"blog"},{"content":" How to lower the cost of kubernetes GKE by killing nodes in specific time windows without using any external tool or API.\nThe problem # Our problem arises when we have a test environment (QA) that is only used during business hours and being connected 24x7 generates an unnecessary cost.\nProposed solution # Shutting down the test environment outside office hours, eliminating nodes from our cluster. Arriving close to the start of business hours, these nodes must be created and the test environment must return to operation.\nDependencies for this solution # For this to be possible we need to have three configuration points:\n1- A separate “node pool” that can be eliminated without affecting production. To make this configuration more effective you can include Taints and Tolerantios.\n2- A common label for all deploys/sts that may be shut down at this time. Example: \u0026ldquo;scheduler=comercial\u0026rdquo;\n3- Know the list of namespaces that contain the deploys/sts that will be deactivated.\nPrevious implementation steps # We need to make sure the nodes and deploys are configured correctly.\nNode-pool and deployments and/or statefulsets validation # Let\u0026rsquo;s first list our node pools and validate that our environment is prepared:\n\u0026gt; gcloud container node-pools list --cluster us-gole-01 NAME MACHINE_TYPE DISK_SIZE_GB NODE_VERSION pool-main c2-standard-8 100 1.20.10-gke.1600 pool-qa e2-standard-8 80 1.20.10-gke.1600 If the node-pool does not exist, it is necessary to create this node pool with the corresponding number of nodes, which can only be one, and add the taint:\nCreating node pool with taint If the node-pool already exists but does not have the necessary taint, then use the gcloud feature still in beta to add the taint:\n\u0026gt; gcloud beta container node-pools update pool-qa --node-taints=\u0026#39;scheduler=comercial:NoSchedule\u0026#39; Now let\u0026rsquo;s validate that all the deploys we want contain the necessary labels.\nIn this example we won\u0026rsquo;t have statefulset in our list, but logically it fits perfectly.\n\u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-a deployment.apps/gole-sonarcube 1/1 1 1 34d namespace-a deployment.apps/gole-redis 1/1 1 1 34d namespace-a deployment.apps/gole-nodejs-app 1/1 1 1 34d \u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-b deployment.apps/gole-netbox-worker 1/1 1 1 34d namespace-b deployment.apps/gole-netbox 1/1 1 1 7d18h Adding tolerations in deploy # We need to make sure the deploys are configured correctly\n❯ kubectl -n namespace-a get deploy -l scheduler=comercial -o=jsonpath=\u0026#39;{.spec.template.spec.tolerations}\u0026#39; The output should be an object like this below times the number of existing deploys. They will all be within the same list, but looking at the list it is possible to observe easily.\n{\u0026#34;effect\u0026#34;:\u0026#34;PreferNoSchedule\u0026#34;,\u0026#34;key\u0026#34;:\u0026#34;scheduler\u0026#34;,\u0026#34;operator\u0026#34;:\u0026#34;Equal\u0026#34;,\u0026#34;value\u0026#34;:\u0026#34;comercial\u0026#34;} Here is an example of where tolerations should be configured:\napiVersion: apps/v1 kind: Deployment metadata: name: gole-app labels: scheduler: comercial app: gole-app tier: api-extended spec: progressDeadlineSeconds: 600 replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: scheduler: comercial app: gole-app tier: api-extended strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: labels: scheduler: comercial app: gole-app tier: api-extended spec: tolerations: - key: \u0026#34;scheduler\u0026#34; operator: \u0026#34;Equal\u0026#34; value: \u0026#34;comercial\u0026#34; effect: \u0026#34;PreferNoSchedule\u0026#34; containers: Final validation # we have labels on deployments? yes\nDo we have a node pool with a taint configured? yes\nDo we have tolerances set in our deployments? yes\nSo now we can get started.\nImplementation # For the implementation of the solution we will need to create some resources:\nSecrets\nCronjob\nSecret key.json # Our secret will be the file renamed to key.json generated in service account, keys inside IAM.\nLogically this system user should have permission to administer the kubernetes cluster using the gcloud sdk.\nkey.json \u0026gt; cat key.json { \u0026#34;type\u0026#34;: \u0026#34;service_account\u0026#34;, \u0026#34;project_id\u0026#34;: \u0026#34;gole-autoscaling-sample\u0026#34;, \u0026#34;private_key_id\u0026#34;: \u0026#34;asdfasdfasdfasdasdfasdasdf....\u0026#34;, \u0026#34;private_key\u0026#34;: \u0026#34;-----BEGIN PRIVATE KEY-----\\ndasdfasdf393993..asdfsf.aksdflksjdflksjfkjafljasdjkf....Ijr7ZCBgpbQrDH\\nvNUw/JxaVbLtpvy3KSmYpjGfKnHFs+wPQi+NFmwrdOZHvKjdtRNxHvPqgWNxCSAh\\nMwEB8cKs0dzif1Hbg7EtYrZOR8g7LZrTD3c4lTsahMyI9x3kN0aCe5QXDXvtPEJ1\\n3s5XFBriQc1tmHwMEV4VW8s=CONTINUA....\\n-----END PRIVATE KEY-----\\n\u0026#34;, \u0026#34;client_email\u0026#34;: \u0026#34;infra@golesuite.com\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;11223344556677889900\u0026#34;, \u0026#34;auth_uri\u0026#34;: \u0026#34;https://accounts.google.com/o/oauth2/auth\u0026#34;, \u0026#34;token_uri\u0026#34;: \u0026#34;https://oauth2.googleapis.com/token\u0026#34;, \u0026#34;auth_provider_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/oauth2/v1/certs\u0026#34;, \u0026#34;client_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/robot/v1/metadata/x509/blablabla\u0026#34; } Let\u0026rsquo;s then add this file as a secret in a specific namespace for our automation.\n\u0026gt; kubectl -n devops create secret generic gcloud-key --from-file=./key.json Checking the created key:\n\u0026gt; kubectl -n devops get secret gcloud-key -o=jsonpath=\u0026#39;{.data.key\\.json}\u0026#39; | base64 -d Note: Ensure that only administrators can view the content of the used namespace. In this case we will use the devops namespace\nCreating our Cronjob # Let\u0026rsquo;s now create a yaml file that uses kind Cronjob.\nOur cronjob is set to:\nStart at 07:30h from Monday to Friday.\nShut down at 19:00 from Monday to Friday.\napiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-shutdown namespace: devops spec: schedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;0\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;sheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key --- apiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-startup namespace: devops spec: schedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key You can see that our cronjob uses two external mount points:\ntz-config\ngcloud-key\nOur tz-config is a pointer to the zoneinfo file found on any OS. Linux, in this case we are communicating to our cronjob that your time zone is America/Sao_Paulo.\nOur gcloud-key uses the secret model, and this is where we will link to the secret created in the previous step.\nCronjob ENV Variables # ENV Variables Required example value SCALE_DEPLOY_NUMBER X 0 SCALE_STS_NUMBER X 0 SCALE_NODES_NUMBER X 0 PROJECT_ID X gole CLUSTER_NAME X br-gole-01 GCLOUD_ZONE X southamerica-east1-a SCHEDULER_LABEL X scheduler=comercial SCHEDULER_POOL X pool-qa Before creating and applying the cronjob file we must change the value of the variables.\nThis is located within env:\nenv: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; Once all the steps have been followed, we are ready to apply our cronjob.\nI would just like to tell you where the commands are that actually do the work of bringing down and uploading the environment, since all we\u0026rsquo;ve done so far is just preparing the infrastructure.\nWhat commands are we going to run? # The commands that will be executed to perform the autoscaling task are described in this git project (it\u0026rsquo;s the same project):\nhttps://github.com/golesuite/gcloud-gke-scheduling\nhttps://gitlab.com/gole-group/community/gcloud-gke-scheduling\nThe alpine-gcloud.sh file is being called within Cronjob in the commands session.\nThe content of the file contains the sequence of commands that will do our job.\nThere are two main steps:\n1- shutdown.\nScale the deploys that contain the declared labels to 0;\nScale node pool nodes containing taints to 0.\n2- startup\nScale deploys containing declared labels to 1 or more;\nScale node pool nodes containing taints to 1 or more.\nEverything else that we create contains the structure that we will use so that these commands can be executed from within our cluster.\nApplying the cronjob. # Since we\u0026rsquo;ve already saved our cronjob file locally, and we\u0026rsquo;ve already modified the variables, times and namespaces, let\u0026rsquo;s apply them.\nNote that the cronjob execution times point to 3h more, this is because the control APIs of the GKE nodes use UTC time. Since TZ values for cronjobs are still in beta, the safest thing is to add an extra 3h and we\u0026rsquo;ll arrive at the correct time.\nThat is, if you want 8h and you are in a city GMT -3, then 8 + 3 = 11.\nTo start we will have (07:30h):\nschedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; To turn off (19:00h):\nschedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; \u0026gt; kubectl apply -f cronjob.yaml \u0026gt; kubectl -n devops get cronjob When it runs we will have a job running:\n\u0026gt; kubectl -n devops get job Logically, the job starts a pod and with that we can follow the logs.\nTests # Change the times so that they run at times when you are working, in order to validate that the processes run correctly.\nFinal considerations # This article includes:\nkubernetes Google GKE\ngcloud\nnode-pools\ntaints\nauto-scaling\nCronjobs\ncontainer commands\ncontainer env variables\nThere are many ways to create and administer a Kubernetes cluster, so don\u0026rsquo;t limit yourself to creating different solutions or ways to apply your solutions.\nUse and abuse the resources of the APIs.\nNeed help? # Access our page Contact and chat with us. We will be happy to serve you.\nSuccess!\n","date":"enero 3, 2022","externalUrl":null,"permalink":"/blog/en/posts/automatic-scheduler-gke/","section":"Posts","summary":"","title":"GKE Scheduler Autoscaling","type":"posts"},{"content":" A super tool for managing your infrastructure.\nNetbox is much more than what we are going to talk about in this blog article.\nOur idea is to index content in Portuguese about this wonderful tool that helps us a lot in organizing both the logical and physical part of IT.\nNetbox IPAM/DCIM group link - BR: https://t.me/netboxbr\nIf you want Gole consulting for the implementation, automation and integration of Netbox with different services of your company, contact us. contact us.\nWhat is IPAM? # IP address management (IPAM) is the methodology that allows us to manage everything related to IP. Everything that encompasses the logical universe of the TCP/IP model. With an IPAM you can manage IPv4, IPv6, VLANs, Subnets, IPs. And for each of these options, you can assign tags, roles, and many other things. This may seem unnecessary, but when you have a network with more than 512 hosts, administering and maintaining the security of this network without an IPAM can be a very complicated task. In this Wikipedia link, we have a very complete table of many IPAM tools.\nWhat is a DCIM? # Data center-infrastructure management (DCIM) is the methodology whose mission is to integrate infrastructure equipment with the team that provides services to the company. Provide IT people with all the information on the equipment and hosts that represent their infrastructure.\nThe virtualization team needs to know which port of the enclosure the SAN switch is connected to, it needs to know which racks have available space. Meanwhile, the network team needs to know which rack contains the MPLS routers, and which switches have the XPTO firmware version.\nThis information is an example of where DCIM makes all the difference.\nWhen it comes time to build capacity plain, DCIM is also an indispensable tool.\nWhat is Netbox? # Netbox is an open source tool that uses the license Apache 2.0. Your official documentation is available on the portal Read the Docs, portal which contains documentation of several other open source projects. The project was created by Jeremy Stretch, who worked as a network developer (Network Developer) at Digital Ocean.\nWith the evolution of Netbox, many people started to collaborate with the codes. Among these people is John Anderson, who, participating in several validations and important contributions in the back-end, also helped to improve the web interface, which has always been built with the Django framework.\nAfter a few years Jeremy Stretch and John Anderson, along with other engineers and developers, created the company called Network to code.\nAbout installation # There are basically two ways to install Netbox: # Netbox is Docker\nNetbox instalado directly in S.O.\nIt is possible to merge part of the installation in the S.O. and another part with Docker, it only depends on knowledge in docker.\nThe installation process is well described, so we don\u0026rsquo;t need to go into it. Our intention is only to present the existence of the tool.\nOnce we have Netbox running and we have created the user in /admin, we can access its web interface.\nUser interface # When we access Netbox through the web interface, we can visualize the menu that is above the entire site.\nThe topics organization, devices, IPAM, virtualization, circuits, Power, secrets and others, represent the first concept that we should pay attention to.\nEach topic can target a different group of people. That is, a person who takes care of the physical structures and racks may not have access to the device configuration, and the people who take care of the devices may not have access to the virtualization menu. And we can also define the profile levels, that is, it is possible that the team that has access to the devices has read-only access to the entire universe that is within IPAM, or even more, that it can create IPs and cannot register subnets or VLANs.\nThese are examples, since it is possible to customize accesses as we see fit.\nWe can also authenticate Netbox against LDAP, Active Directory and other forms of authentication.\nWe can see the wealth of detail and care that Netbox brings. In this example we can visualize the link between the physical location, with the tenant, with the rack and with the devices.\nWe can also see that it is possible to define colors for each type of device, in addition to many other things.\nIn the prefixes menu, we can see the integration between roles, VLANs, IPs, percentage of network utilization.\nWe can also observe on the right, that we always have the possibility to search the different options with a filter. It\u0026rsquo;s very powerful!\nOn this screen we are inside a device.\nIn this example, we can see that the device has an associated primary_ipv4, it has a status of planned, it has the role of network, since the attached image shows us that it is a switch. We also have the switch platform, and support for comments and tags.\nIn the interfaces part, we can connect these interfaces with the other registered devices. We can define if the interface uses LAG, if it is a bond, if it is virtual, the MTU, the connection type, MAC Address, in short, everything we need.\nAPI # Anyone who is used to working with APIs knows how good it is when we find an API that is documented using Swagger.\nNetbox has the most complete and beautifully documented API, evidently occupying swagger. It is possible to do all the action via the Web or via API, so it is possible to automate all the insertion and obtaining of information!\nThat\u0026rsquo;s it! # The truth is that this is a quick summary of what you can do with Netbox.\nWe participate in implementations in multinational companies with more than 3,000 physical sites, and more than 5 Data Centers. The organization and transparency, the integration between the internal teams, it was incredible to see the positive points of this tool.\nNetbox also allows native integration with Ansible, Salt, Stack Storm, and many others, not limited to these tools, you can develop your own integrations.\nLong live Netbox!\n","date":"junio 30, 2020","externalUrl":null,"permalink":"/blog/en/blog/what-is-netbox/netbox/","section":"Blog","summary":"","title":"What is Netbox and what is it for","type":"blog"},{"content":" A super tool for managing your infrastructure.\nNetbox is much more than what we are going to talk about in this blog article.\nOur idea is to index content in Portuguese about this wonderful tool that helps us a lot in organizing both the logical and physical part of IT.\nNetbox IPAM/DCIM group link - BR: https://t.me/netboxbr\nIf you want Gole consulting for the implementation, automation and integration of Netbox with different services of your company, contact us. contact us.\nWhat is IPAM? # IP address management (IPAM) is the methodology that allows us to manage everything related to IP. Everything that encompasses the logical universe of the TCP/IP model. With an IPAM you can manage IPv4, IPv6, VLANs, Subnets, IPs. And for each of these options, you can assign tags, roles, and many other things. This may seem unnecessary, but when you have a network with more than 512 hosts, administering and maintaining the security of this network without an IPAM can be a very complicated task. In this Wikipedia link, we have a very complete table of many IPAM tools.\nWhat is a DCIM? # Data center-infrastructure management (DCIM) is the methodology whose mission is to integrate infrastructure equipment with the team that provides services to the company. Provide IT people with all the information on the equipment and hosts that represent their infrastructure.\nThe virtualization team needs to know which port of the enclosure the SAN switch is connected to, it needs to know which racks have available space. Meanwhile, the network team needs to know which rack contains the MPLS routers, and which switches have the XPTO firmware version.\nThis information is an example of where DCIM makes all the difference.\nWhen it comes time to build capacity plain, DCIM is also an indispensable tool.\nWhat is Netbox? # Netbox is an open source tool that uses the license Apache 2.0. Your official documentation is available on the portal Read the Docs, portal which contains documentation of several other open source projects. The project was created by Jeremy Stretch, who worked as a network developer (Network Developer) at Digital Ocean.\nWith the evolution of Netbox, many people started to collaborate with the codes. Among these people is John Anderson, who, participating in several validations and important contributions in the back-end, also helped to improve the web interface, which has always been built with the Django framework.\nAfter a few years Jeremy Stretch and John Anderson, along with other engineers and developers, created the company called Network to code.\nAbout installation # There are basically two ways to install Netbox: # Netbox is Docker\nNetbox instalado directly in S.O.\nIt is possible to merge part of the installation in the S.O. and another part with Docker, it only depends on knowledge in docker.\nThe installation process is well described, so we don\u0026rsquo;t need to go into it. Our intention is only to present the existence of the tool.\nOnce we have Netbox running and we have created the user in /admin, we can access its web interface.\nUser interface # When we access Netbox through the web interface, we can visualize the menu that is above the entire site.\nThe topics organization, devices, IPAM, virtualization, circuits, Power, secrets and others, represent the first concept that we should pay attention to.\nEach topic can target a different group of people. That is, a person who takes care of the physical structures and racks may not have access to the device configuration, and the people who take care of the devices may not have access to the virtualization menu. And we can also define the profile levels, that is, it is possible that the team that has access to the devices has read-only access to the entire universe that is within IPAM, or even more, that it can create IPs and cannot register subnets or VLANs.\nThese are examples, since it is possible to customize accesses as we see fit.\nWe can also authenticate Netbox against LDAP, Active Directory and other forms of authentication.\nWe can see the wealth of detail and care that Netbox brings. In this example we can visualize the link between the physical location, with the tenant, with the rack and with the devices.\nWe can also see that it is possible to define colors for each type of device, in addition to many other things.\nIn the prefixes menu, we can see the integration between roles, VLANs, IPs, percentage of network utilization.\nWe can also observe on the right, that we always have the possibility to search the different options with a filter. It\u0026rsquo;s very powerful!\nOn this screen we are inside a device.\nIn this example, we can see that the device has an associated primary_ipv4, it has a status of planned, it has the role of network, since the attached image shows us that it is a switch. We also have the switch platform, and support for comments and tags.\nIn the interfaces part, we can connect these interfaces with the other registered devices. We can define if the interface uses LAG, if it is a bond, if it is virtual, the MTU, the connection type, MAC Address, in short, everything we need.\nAPI # Anyone who is used to working with APIs knows how good it is when we find an API that is documented using Swagger.\nNetbox has the most complete and beautifully documented API, evidently occupying swagger. It is possible to do all the action via the Web or via API, so it is possible to automate all the insertion and obtaining of information!\nThat\u0026rsquo;s it! # The truth is that this is a quick summary of what you can do with Netbox.\nWe participate in implementations in multinational companies with more than 3,000 physical sites, and more than 5 Data Centers. The organization and transparency, the integration between the internal teams, it was incredible to see the positive points of this tool.\nNetbox also allows native integration with Ansible, Salt, Stack Storm, and many others, not limited to these tools, you can develop your own integrations.\nLong live Netbox!\n","date":"junio 30, 2020","externalUrl":null,"permalink":"/blog/en/posts/what-is-netbox/netbox/","section":"Posts","summary":"","title":"What is Netbox and what is it for","type":"posts"},{"content":" Cloud init is a package used to initialize a cloud instance. Widely used to customize Linux virtual machines, where it executes custom configurations that you want for a VM on its first startup. It can be used to configure users, install packages, generate and configure SSH keys.\nDo you want to create VMs, setting the server name, IP, vlan, user, etc… without even having to turn them on? cloud-init is for you! # Project home: https://cloud-init.io\nOfficial document: https://cloudinit.readthedocs.io/en/latest/\nCloud-init is a highly used resource when we talk about virtual servers provided by the big “players” of clouds.\nIt\u0026rsquo;s interesting for clouds and VMs because its custom kernel doesn\u0026rsquo;t support anything a VM doesn\u0026rsquo;t need to work. That is, it will not support the soundblaster sound card. =).\nWas created by Canonical which is the same company that created Ubuntu, and which has an overwhelming share of operating systems in the cloud market.\nGoogle and AWS (among others) are examples of companies that use cloud-init to make VMs available to their customers.\nWhen we use kubernetes or VMs at Google, for example, it is possible to visualize the cloud-init config used by them, which between us, is a tremendous cloud-init config!\nSome examples of why use cloud-init in Proxmox? # Speed in creating new VMs\nControl VM IPs as if they were an LXC container\nAutomation possibilities\nCompatibility with Ansible and other automation tools\nAs this article is being created as a simple documentation of the process, let\u0026rsquo;s get straight to the point and so we can better validate what this cloud-init does.\nDeploying cloud-init on proxmox! Get to work! # The first, read the official Proxmox + cloud-init documentation:\nhttps://pve.proxmox.com/wiki/Cloud-Init_Support\nSecond, read at least the introduction to the https://cloudinit.readthedocs.io/en/latest/\nHeads up!! Heads up!! # The official documentation of proxmox starts with a topic: Preparing Cloud-Init Templates and this confuses the crowd!\nThe cloud-init images are ready and we can use them without having to prepare anything. This is only for people who need to create their cloud-init templates from scratch.\nImage download # I chose the ubuntu image in honor of Canonical who made the project available, so the credit goes to them: https://cloud-images.ubuntu.com/groovy/current/\nNote that both the “img” format and the “amd64” architecture are compatible with Proxmox. Now choose any node of your proxmox cluster to host the template and access it by ssh:\n# wget https://cloud-images.ubuntu.com/groovy/current/groovy-server-cloudimg-amd64.img # qm create 9002 --memory 2048 --net0 virtio,bridge=vmbr1 Now look at/etc/pve/storage.cfg what is the storage you want to save this image. In this case I will use local storage:\n# qm importdisk 9002 groovy-server-cloudimg-amd64.img local Successfully imported disk as ‘unused0:local:9002/vm-9002-disk-0.raw’ # qm set 9002 --scsihw virtio-scsi-pci --scsi0 local:9002/vm-9002-disk-0.raw update VM 9002: -scsi0 local:9002/vm-9002-disk-0.raw -scsihw virtio-scsi-pci We\u0026rsquo;re almost done. We now have to add a 2 disk which is where we will store the custom configs (roughly speaking).\n# qm set 9002 --ide2 local:cloudinit update VM 9002: -ide2 local:cloudinit Formatting ‘/var/lib/vz/images/9002/vm-9002-cloudinit.qcow2’, fmt=qcow2 cluster_size=65536 preallocation=metadata compression_type=zlib size=4194304 lazy_refcounts=off refcount_bits=16 Fixing the boot order:\n# qm set 9002 --boot c --bootdisk scsi0 Some amd64 cloud-init images are made with openstack compatibility in mind. So we have to add serial0 so that it starts. In case you\u0026rsquo;re curious, remove serial0 and try the restart, if it doesn\u0026rsquo;t boot add it again and everything will work:\n# qm set 9002 --serial0 socket --vga serial0 update VM 9002: -serial0 socket -vga serial0 Copy your public ssh key to the proxmox server, so we can add this key to the cloud-init template:\n[user_machine ~$] scp ~/.ssh/id_rsa.pub root@PROXMOX_NODE:/tmp Going back to proxmox server:\n# qm set 9002 --sshkey /tmp/id_rsa.pub update VM 9002: -sshkeys ssh-rsa%20AAAAB3NzaC1yc2EAAAADAQABAAABgQC4LX1HAmPWW4qzmqUBsIvgbdlfDS5MKEVK5cpXRxmUErezgVfvodbGlqqnO0T61Dry3KRg1owq62wpH1z8d%2Bh6vZCsJKoyoklC55xlbJgGDSxEB0%2FbUMiwqWkFdjRwQ1V2HOYNJKttoBUFIQvG8V3XSDtw%2Fw3W0aNOAfnheZX10zMJ%2BCuisMkvGGCBRDwnxxi%2BJoeTGrx85yLYfdD6Ca6yba6KeTMcu5PoI1BH5%2Bvt2Ta90BGjyHpLUOZpoqV0AurTEJIO3n5J0z2OH9WhC77Kwz6mG3MSNueA1BcgRUVvaXvJB65ce2azSVcKbXNkTbeBFlc7FhocEAhXrycRR0L6xgo3acvoCBOx4EijtF0itjzqfvNhH9tN9oLj8Qxiz6ttGivzucfWBsc30pUDopWGaJ0syNFE0Wyvs03cDMHb%2F5Vmb8ixE%2BK2nDJe3OXyn%2Bp4GzkWNyVZjYxutg%2FLAFP6bwe6Oe1jSob4I0bA4xT7guHLp93zEqWHRjDFGhXewhk%3D%20USER%40MACHINE%0 Set the user who will have sudo permission:\n# qm set 9002 --ciuser gole update VM 9002: -ciuser gole Set the machine type. Valuable tip from Tomas 2w-consultoria.\n# qm set 9002 --machine q35 update VM 9002: -machine q35 Finally, turn it into a template:\n# qm template 9002 Making a clone and using the new VM # Finally clone the template to a new machine:\n# qm clone 9002 139 --name VMNAME --full Configure the IP it will use:\n# qm set 139 --ipconfig0 ip=172..xxx.xxx.5/24,gw=172.xxx.xxx.1 Resize the disk to a size it will take up on this VM:\n# qm resize 139 scsi0 +45G Image resized. Turn on the VM:\n# qm start 139 Wait for it to start and run ssh from the machine that had the public key:\n$ ssh -l gole 172.xxx.xxx.5 Bingo! Inside the server without doing any installation!\nYou can set vlans, DNSs and everything your new VM needs to work. You can also customize cloud-init with cicustom. Take a look at the official documentation.\nWhen cloud-init first goes up, it will install some packages, so 1st boot takes a little longer to release apt.\nSuccess!\n","date":"julio 6, 2019","externalUrl":null,"permalink":"/blog/en/blog/cloud-init-without-proxmox-6/cloud-init-in-proxmox-virtual-environment/","section":"Blog","summary":"","title":"Cloud-init in Proxmox Virtual Environment 6","type":"blog"},{"content":" Cloud init is a package used to initialize a cloud instance. Widely used to customize Linux virtual machines, where it executes custom configurations that you want for a VM on its first startup. It can be used to configure users, install packages, generate and configure SSH keys.\nDo you want to create VMs, setting the server name, IP, vlan, user, etc… without even having to turn them on? cloud-init is for you! # Project home: https://cloud-init.io\nOfficial document: https://cloudinit.readthedocs.io/en/latest/\nCloud-init is a highly used resource when we talk about virtual servers provided by the big “players” of clouds.\nIt\u0026rsquo;s interesting for clouds and VMs because its custom kernel doesn\u0026rsquo;t support anything a VM doesn\u0026rsquo;t need to work. That is, it will not support the soundblaster sound card. =).\nWas created by Canonical which is the same company that created Ubuntu, and which has an overwhelming share of operating systems in the cloud market.\nGoogle and AWS (among others) are examples of companies that use cloud-init to make VMs available to their customers.\nWhen we use kubernetes or VMs at Google, for example, it is possible to visualize the cloud-init config used by them, which between us, is a tremendous cloud-init config!\nSome examples of why use cloud-init in Proxmox? # Speed in creating new VMs\nControl VM IPs as if they were an LXC container\nAutomation possibilities\nCompatibility with Ansible and other automation tools\nAs this article is being created as a simple documentation of the process, let\u0026rsquo;s get straight to the point and so we can better validate what this cloud-init does.\nDeploying cloud-init on proxmox! Get to work! # The first, read the official Proxmox + cloud-init documentation:\nhttps://pve.proxmox.com/wiki/Cloud-Init_Support\nSecond, read at least the introduction to the https://cloudinit.readthedocs.io/en/latest/\nHeads up!! Heads up!! # The official documentation of proxmox starts with a topic: Preparing Cloud-Init Templates and this confuses the crowd!\nThe cloud-init images are ready and we can use them without having to prepare anything. This is only for people who need to create their cloud-init templates from scratch.\nImage download # I chose the ubuntu image in honor of Canonical who made the project available, so the credit goes to them: https://cloud-images.ubuntu.com/groovy/current/\nNote that both the “img” format and the “amd64” architecture are compatible with Proxmox. Now choose any node of your proxmox cluster to host the template and access it by ssh:\n# wget https://cloud-images.ubuntu.com/groovy/current/groovy-server-cloudimg-amd64.img # qm create 9002 --memory 2048 --net0 virtio,bridge=vmbr1 Now look at/etc/pve/storage.cfg what is the storage you want to save this image. In this case I will use local storage:\n# qm importdisk 9002 groovy-server-cloudimg-amd64.img local Successfully imported disk as ‘unused0:local:9002/vm-9002-disk-0.raw’ # qm set 9002 --scsihw virtio-scsi-pci --scsi0 local:9002/vm-9002-disk-0.raw update VM 9002: -scsi0 local:9002/vm-9002-disk-0.raw -scsihw virtio-scsi-pci We\u0026rsquo;re almost done. We now have to add a 2 disk which is where we will store the custom configs (roughly speaking).\n# qm set 9002 --ide2 local:cloudinit update VM 9002: -ide2 local:cloudinit Formatting ‘/var/lib/vz/images/9002/vm-9002-cloudinit.qcow2’, fmt=qcow2 cluster_size=65536 preallocation=metadata compression_type=zlib size=4194304 lazy_refcounts=off refcount_bits=16 Fixing the boot order:\n# qm set 9002 --boot c --bootdisk scsi0 Some amd64 cloud-init images are made with openstack compatibility in mind. So we have to add serial0 so that it starts. In case you\u0026rsquo;re curious, remove serial0 and try the restart, if it doesn\u0026rsquo;t boot add it again and everything will work:\n# qm set 9002 --serial0 socket --vga serial0 update VM 9002: -serial0 socket -vga serial0 Copy your public ssh key to the proxmox server, so we can add this key to the cloud-init template:\n[user_machine ~$] scp ~/.ssh/id_rsa.pub root@PROXMOX_NODE:/tmp Going back to proxmox server:\n# qm set 9002 --sshkey /tmp/id_rsa.pub update VM 9002: -sshkeys ssh-rsa%20AAAAB3NzaC1yc2EAAAADAQABAAABgQC4LX1HAmPWW4qzmqUBsIvgbdlfDS5MKEVK5cpXRxmUErezgVfvodbGlqqnO0T61Dry3KRg1owq62wpH1z8d%2Bh6vZCsJKoyoklC55xlbJgGDSxEB0%2FbUMiwqWkFdjRwQ1V2HOYNJKttoBUFIQvG8V3XSDtw%2Fw3W0aNOAfnheZX10zMJ%2BCuisMkvGGCBRDwnxxi%2BJoeTGrx85yLYfdD6Ca6yba6KeTMcu5PoI1BH5%2Bvt2Ta90BGjyHpLUOZpoqV0AurTEJIO3n5J0z2OH9WhC77Kwz6mG3MSNueA1BcgRUVvaXvJB65ce2azSVcKbXNkTbeBFlc7FhocEAhXrycRR0L6xgo3acvoCBOx4EijtF0itjzqfvNhH9tN9oLj8Qxiz6ttGivzucfWBsc30pUDopWGaJ0syNFE0Wyvs03cDMHb%2F5Vmb8ixE%2BK2nDJe3OXyn%2Bp4GzkWNyVZjYxutg%2FLAFP6bwe6Oe1jSob4I0bA4xT7guHLp93zEqWHRjDFGhXewhk%3D%20USER%40MACHINE%0 Set the user who will have sudo permission:\n# qm set 9002 --ciuser gole update VM 9002: -ciuser gole Set the machine type. Valuable tip from Tomas 2w-consultoria.\n# qm set 9002 --machine q35 update VM 9002: -machine q35 Finally, turn it into a template:\n# qm template 9002 Making a clone and using the new VM # Finally clone the template to a new machine:\n# qm clone 9002 139 --name VMNAME --full Configure the IP it will use:\n# qm set 139 --ipconfig0 ip=172..xxx.xxx.5/24,gw=172.xxx.xxx.1 Resize the disk to a size it will take up on this VM:\n# qm resize 139 scsi0 +45G Image resized. Turn on the VM:\n# qm start 139 Wait for it to start and run ssh from the machine that had the public key:\n$ ssh -l gole 172.xxx.xxx.5 Bingo! Inside the server without doing any installation!\nYou can set vlans, DNSs and everything your new VM needs to work. You can also customize cloud-init with cicustom. Take a look at the official documentation.\nWhen cloud-init first goes up, it will install some packages, so 1st boot takes a little longer to release apt.\nSuccess!\n","date":"julio 6, 2019","externalUrl":null,"permalink":"/blog/en/posts/cloud-init-without-proxmox-6/cloud-init-in-proxmox-virtual-environment/","section":"Posts","summary":"","title":"Cloud-init in Proxmox Virtual Environment 6","type":"posts"},{"content":"How I built a complete automation system to manage DevOps requests using a Telegram bot, Artificial Intelligence, and a modern web platform.\nIntroduction # This article presents my first project using Artificial Intelligence in a practical, applied way. The solution was born from a combination of what I learned in an Alura course, a real need for task automation and organization, and a lot of curiosity about building bots.\nThe Problem # In DevOps environments, it’s common for customers and users to report issues through multiple communication channels, such as Telegram groups. These requests can include:\nServers down\nBroken Kubernetes pods\nAWS infrastructure issues\nQuestions related to compute resources (CPU, memory)\nThe challenge was to centralize, organize, and manage these requests efficiently—ensuring no demand was lost and that the DevOps team had full visibility into pending work.\nThe Proposed Solution # I developed a complete, decoupled system that automates the entire workflow:\nCapture: A Telegram bot monitors messages in specific groups\nProcessing: OpenAI’s AI interprets the message and extracts relevant information\nStorage: The backend processes and stores tasks in the database\nVisualization: A web platform displays tasks in an organized way for the team\nDecoupled Architecture # One of the project’s key differentiators is its modular, independent architecture. This means:\nThe bot can be replaced with another one (Discord, Slack, WhatsApp) without affecting the system\nThe AI can be swapped (Claude, Gemini, local models) while keeping the functionality\nThe backend is independent and can be consumed by different frontends\nEach component can evolve separately\nKey Features # Telegram Bot # Built in Python\nMonitors messages in real time\nIdentifies support requests\nSends an automatic confirmation to the user\nOpenAI Integration # Intelligent message interpretation\nExtraction of key information (issue type, urgency, affected resources)\nGeneration of contextual replies for the customer\nAutomatic creation of structured descriptions for the DevOps team\nLogging and Monitoring System # Tokenizer to track API usage\nDetailed logs of all interactions\nUsage and performance metrics\nDatabase Management # Django ORM for efficient data manipulation\nOptimized relational structure\nComplete request history\nWeb Platform # Modern, responsive interface\nDashboard with metrics (Total Tasks, In Progress, Completed)\nDetailed view of each task\nTagging and categorization system\nAdvanced filters and search\nTech Stack # Backend # Python: Primary language for the bot and business logic\nDjango: Web framework and ORM for database management\nPostgreSQL: Robust, scalable relational database\nFrontend # Next.js: React framework for modern web applications\nTypeScript: Static typing for safer code\nTailwind CSS: Utility-first CSS framework for responsive design\nArtificial Intelligence # OpenAI API: Natural language processing and response generation Infrastructure # Telegram Bot API: Telegram integration\nRESTful API: Communication between components\nDevelopment Tools # PyCharm: IDE for Python development\nDataGrip: Database management and visualization\nWebStorm: IDE for frontend development\nHow It Works # 1. Request Intake # When a customer sends a message in a Telegram group:\n\u0026#34;Hi everyone, We have an issue here and need help. The system went down about 20 minutes ago and isn’t coming back. Users are complaining that they can’t access the platform. Can you check what’s going on? Could it be something related to Kubernetes? Are the pods running normally? And what about AWS resources—did we hit any CPU or memory limits on the instances? We need this back as soon as possible. Do you have any idea what might be happening? Thanks!\u0026#34; 2. Bot Processing # The bot captures the message and sends it to the OpenAI API, which:\nIdentifies it as a support request\nExtracts relevant information (issue: system down; possible cause: Kubernetes/AWS)\nClassifies urgency (high, due to user impact)\nGenerates a reply for the customer\n3. Automated Response # The bot replies immediately:\n\u0026#34;Hello! We’ve received your request and we’re investigating what happened. Thank you for your patience—we’ll get back to you shortly with more information.\u0026#34; 4. Task Creation # The system automatically creates a structured task:\n\\[Incident\\] - System outage with potential impact on Kubernetes and AWS resources\nDescription: Investigate the system outage and analyze potential issues in Kubernetes and AWS resources related to CPU and memory limits\nCustomer: Infra EmpresaABC\nTags: #infra #aws #kubernetes\nStatus: Triage → Complex\nCreated At: 22/01/2026\n5. Platform View # The DevOps team accesses the web platform and sees:\nA dashboard with all tasks\nFull request details\nInteraction history\nThe ability to update status and add comments\nBenefits of the Solution # For the Customer # Immediate, automated response\nConfirmation that the request was received\nTransparency in the process\nFor the DevOps Team # Centralization of all requests\nEasier organization and prioritization\nFewer lost or forgotten tasks\nComplete support history\nPerformance metrics and indicators\nFor the Organization # Automation of manual processes\nReduced response time\nImproved support quality\nStructured data for analysis and continuous improvement\nChallenges and Learnings # API Integration # Working with the OpenAI API required a deep understanding of:\nToken management\nPrompt optimization\nError handling and fallbacks\nCost control\nDecoupled Architecture # Designing a modular system from the start was essential to:\nMake maintenance easier\nAllow independent evolution of components\nEnable isolated testing\nEnsure scalability\nNatural Language Processing # Creating effective prompts to extract relevant information from messages was an iterative process of:\nTesting different scenarios\nTweaking prompts\nValidating response quality\nNext Steps # The project is constantly evolving. Some planned improvements include:\nIntegration with other platforms (Slack, Discord, WhatsApp)\nNotification system for the DevOps team\nAdvanced metrics dashboard with charts and reports\nResponse automation for recurring issues\nSmart prioritization system based on history\nIntegration with monitoring tools (Grafana, Prometheus)\nPublic API for external integrations\nFinal Thoughts # This project was an excellent opportunity to apply knowledge in:\nPython and bot development\nArtificial Intelligence applied to real problems\nSoftware architecture that is decoupled and scalable\nDevOps and process automation\nFull-stack development with modern technologies\nMore than a technical project, it was a learning experience on how AI can be applied to solve real problems and improve day-to-day processes.\nI’m excited to keep evolving this solution and exploring new possibilities for automation and artificial intelligence in the DevOps context!\nWant to Learn More? # If you’re interested in:\nImplementing a similar solution\nContributing to the project\nDiscussing architecture and best practices\nSharing experiences with automation and AI\nGet in touch!\n","date":"enero 26, 2026","externalUrl":null,"permalink":"/blog/en/blog/devops-task-automation-bot/devops-task-automation-bot/","section":"Blog","summary":"","title":"AI Bot for DevOps Task Automation via Telegram","type":"blog"},{"content":"","date":"enero 26, 2026","externalUrl":null,"permalink":"/blog/en/categories/artificial-intelligence/","section":"Categories","summary":"","title":"Artificial Intelligence","type":"categories"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"26 enero 2026","externalUrl":null,"permalink":"/blog/pt/categories/automa%C3%A7%C3%A3o/","section":"Categories","summary":"","title":"Automação","type":"categories"},{"content":"","date":"26 enero 2026","externalUrl":null,"permalink":"/blog/pt/tags/automa%C3%A7%C3%A3o/","section":"Tags","summary":"","title":"Automação","type":"tags"},{"content":"","date":"enero 26, 2026","externalUrl":null,"permalink":"/blog/en/categories/automation/","section":"Categories","summary":"","title":"Automation","type":"categories"},{"content":"","date":"enero 26, 2026","externalUrl":null,"permalink":"/blog/en/tags/automation/","section":"Tags","summary":"","title":"Automation","type":"tags"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/categories/automatizaci%C3%B3n/","section":"Categories","summary":"","title":"Automatización","type":"categories"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/tags/automatizaci%C3%B3n/","section":"Tags","summary":"","title":"Automatización","type":"tags"},{"content":"Como desenvolvi um sistema completo de automação para gerenciamento de solicitações DevOps utilizando bot Telegram, Inteligência Artificial e uma plataforma web moderna.\nIntrodução # Este artigo apresenta meu primeiro projeto utilizando Inteligência Artificial de forma prática e aplicada. A solução nasceu da combinação entre o aprendizado obtido no curso da Alura, uma necessidade real de automação e organização de tarefas, e muita curiosidade sobre o desenvolvimento de bots.\nO Problema # Em ambientes de DevOps, é comum que clientes e usuários reportem problemas através de diversos canais de comunicação, como grupos do Telegram. Essas solicitações podem incluir:\nServidores fora do ar\nPods quebrados no Kubernetes\nProblemas de infraestrutura na AWS\nQuestões relacionadas a recursos computacionais (CPU, memória)\nO desafio estava em centralizar, organizar e gerenciar essas solicitações de forma eficiente, garantindo que nenhuma demanda fosse perdida e que o time de DevOps tivesse visibilidade completa das tarefas pendentes.\nA Solução Proposta # Desenvolvi um sistema completo e desacoplado que automatiza todo o fluxo de trabalho:\nCaptura: Bot do Telegram monitora mensagens em grupos específicos\nProcessamento: IA da OpenAI interpreta a mensagem e extrai informações relevantes\nArmazenamento: Backend processa e armazena as tarefas no banco de dados\nVisualização: Plataforma web exibe as tarefas de forma organizada para o time\nArquitetura Desacoplada # Um dos principais diferenciais do projeto é sua arquitetura modular e independente. Isso significa que:\nO bot pode ser substituído por outro (Discord, Slack, WhatsApp) sem afetar o sistema\nA IA pode ser trocada (Claude, Gemini, modelos locais) mantendo a funcionalidade\nO backend é independente e pode ser consumido por diferentes frontends\nCada componente pode evoluir separadamente\nFuncionalidades Principais # Bot de Telegram # Desenvolvido em Python\nMonitora mensagens em tempo real\nIdentifica solicitações de suporte\nEnvia confirmação automática ao usuário\nIntegração com OpenAI # Interpretação inteligente de mensagens\nExtração de informações-chave (tipo de problema, urgência, recursos afetados)\nGeração de respostas contextualizadas para o cliente\nCriação automática de descrições estruturadas para o time de DevOps\nSistema de Logs e Monitoramento # Tokenizer para controle de consumo da API\nLogs detalhados de todas as interações\nMétricas de uso e performance\nGestão de Banco de Dados # ORM Django para manipulação eficiente dos dados\nEstrutura relacional otimizada\nHistórico completo de solicitações\nPlataforma Web # Interface moderna e responsiva\nDashboard com métricas (Total de Tarefas, Em Progresso, Concluídas)\nVisualização detalhada de cada tarefa\nSistema de tags e categorização\nFiltros e busca avançada\nStack Tecnológica # Backend # Python: Linguagem principal para o bot e lógica de negócio\nDjango: Framework web e ORM para gestão do banco de dados\nPostgreSQL: Banco de dados relacional robusto e escalável\nFrontend # Next.js: Framework React para aplicações web modernas\nTypeScript: Tipagem estática para código mais seguro\nTailwind CSS: Framework CSS utilitário para design responsivo\nInteligência Artificial # OpenAI API: Processamento de linguagem natural e geração de respostas Infraestrutura # Telegram Bot API: Integração com o Telegram\nRESTful API: Comunicação entre componentes\nFerramentas de Desenvolvimento # PyCharm: IDE para desenvolvimento Python\nDataGrip: Gerenciamento e visualização do banco de dados\nWebStorm: IDE para desenvolvimento frontend\nFluxo de Funcionamento # 1. Recebimento da Solicitação # Quando um cliente envia uma mensagem no grupo do Telegram:\n\u0026#34;Oi pessoal, Estamos com um problema aqui e precisamos de ajuda. O sistema caiu há uns 20 minutos e não está voltando. Os usuários estão reclamando que não conseguem acessar a plataforma. Vocês conseguem verificar o que está acontecendo? Pode ser algo relacionado ao Kubernetes? Os pods estão rodando normalmente? E quanto aos recursos na AWS - será que estourou algum limite de CPU ou memória nas instâncias? Precisamos que isso volte o mais rápido possível. Vocês têm alguma ideia do que pode estar acontecendo? Obrigado!\u0026#34; 2. Processamento pelo Bot # O bot captura a mensagem e envia para a API da OpenAI, que:\nIdentifica que é uma solicitação de suporte\nExtrai informações relevantes (problema: sistema fora do ar, possível causa: Kubernetes/AWS)\nClassifica a urgência (alta, devido ao impacto nos usuários)\nGera uma resposta para o cliente\n3. Resposta Automática # O bot responde imediatamente:\n\u0026#34;Olá! Recebemos sua solicitação e estamos verificando o ocorrido. Agradecemos a sua paciência e entraremos em contato em breve com mais informações.\u0026#34; 4. Criação da Tarefa # O sistema cria automaticamente uma tarefa estruturada:\n\\[Incidente\\] - Problema de queda do sistema com possíveis impactos em Kubernetes e recursos AWS\nDescrição: Investigar queda do sistema e analisar possíveis problemas no Kubernetes e recursos na AWS em relação a limites de CPU e memória\nCliente: Infra EmpresaABC\nTags: #infra #aws #kubernetes\nStatus: Estimativa → Complexo\nData de Criação: 22/01/2026\n5. Visualização na Plataforma # O time de DevOps acessa a plataforma web e visualiza:\nDashboard com todas as tarefas\nDetalhes completos da solicitação\nHistórico de interações\nPossibilidade de atualizar status e adicionar comentários\nBenefícios da Solução # Para o Cliente # Resposta imediata e automática\nConfirmação de que a solicitação foi recebida\nTransparência no processo\nPara o Time de DevOps # Centralização de todas as solicitações\nOrganização e priorização facilitadas\nRedução de tarefas perdidas ou esquecidas\nHistórico completo de atendimentos\nMétricas e indicadores de performance\nPara a Organização # Automação de processos manuais\nRedução de tempo de resposta\nMelhoria na qualidade do atendimento\nDados estruturados para análise e melhoria contínua\nDesafios e Aprendizados # Integração com APIs # Trabalhar com a API da OpenAI exigiu compreensão profunda de:\nGerenciamento de tokens\nOtimização de prompts\nTratamento de erros e fallbacks\nControle de custos\nArquitetura Desacoplada # Projetar um sistema modular desde o início foi fundamental para:\nFacilitar manutenção\nPermitir evolução independente dos componentes\nPossibilitar testes isolados\nGarantir escalabilidade\nProcessamento de Linguagem Natural # Criar prompts eficientes para extrair informações relevantes das mensagens foi um processo iterativo de:\nTestes com diferentes cenários\nAjustes nos prompts\nValidação da qualidade das respostas\nConsiderações Finais # Este projeto foi uma excelente oportunidade para aplicar conhecimentos de:\nPython e desenvolvimento de bots\nInteligência Artificial aplicada a problemas reais\nArquitetura de software desacoplada e escalável\nDevOps e automação de processos\nDesenvolvimento full-stack com tecnologias modernas\nMais do que um projeto técnico, foi uma experiência de aprendizado sobre como a IA pode ser aplicada para resolver problemas reais e melhorar processos do dia a dia.\nEstou animado para continuar evoluindo essa solução e explorando novas possibilidades de automação e inteligência artificial no contexto de DevOps!\nQuer Saber Mais? # Se você tem interesse em:\nImplementar uma solução similar\nContribuir com o projeto\nDiscutir arquitetura e boas práticas\nCompartilhar experiências com automação e IA\nEntre em contato!\n","date":"26 enero 2026","externalUrl":null,"permalink":"/blog/pt/blog/bot-automatizador-de-tarefas-devops/bot-automatizador-de-tarefas-devops/","section":"Blog","summary":"","title":"Bot de IA para Automação de Tarefas DevOps via Telegram","type":"blog"},{"content":"Cómo desarrollé un sistema completo de automatización para la gestión de solicitudes DevOps utilizando un bot de Telegram, Inteligencia Artificial y una plataforma web moderna.\nIntroducción # Este artículo presenta mi primer proyecto utilizando Inteligencia Artificial de forma práctica y aplicada. La solución nació de la combinación entre el aprendizaje obtenido en el curso de Alura, una necesidad real de automatización y organización de tareas, y mucha curiosidad sobre el desarrollo de bots.\nEl Problema # En entornos de DevOps, es común que clientes y usuarios reporten problemas a través de diversos canales de comunicación, como grupos de Telegram. Estas solicitudes pueden incluir:\nServidores fuera de servicio\nPods caídos en Kubernetes\nProblemas de infraestructura en AWS\nCuestiones relacionadas con recursos computacionales (CPU, memoria)\nEl desafío consistía en centralizar, organizar y gestionar estas solicitudes de forma eficiente, garantizando que ninguna demanda se perdiera y que el equipo de DevOps tuviera visibilidad completa de las tareas pendientes.\nLa Solución Propuesta # Desarrollé un sistema completo y desacoplado que automatiza todo el flujo de trabajo:\nCaptura: Un bot de Telegram monitorea mensajes en grupos específicos.\nProcesamiento: La IA de OpenAI interpreta el mensaje y extrae información relevante.\nAlmacenamiento: El backend procesa y almacena las tareas en la base de datos.\nVisualización: Una plataforma web muestra las tareas de forma organizada para el equipo.\nArquitectura Desacoplada # Uno de los principales diferenciales del proyecto es su arquitectura modular e independiente. Esto significa que:\nEl bot puede ser sustituido por otro (Discord, Slack, WhatsApp) sin afectar al sistema.\nLa IA puede cambiarse (Claude, Gemini, modelos locales) manteniendo la funcionalidad.\nEl backend es independiente y puede ser consumido por diferentes frontends.\nCada componente puede evolucionar por separado.\nFuncionalidades Principales # Bot de Telegram # Desarrollado en Python.\nMonitorea mensajes en tiempo real.\nIdentifica solicitudes de soporte.\nEnvía confirmación automática al usuario.\nIntegración con OpenAI # Interpretación inteligente de mensajes.\nExtracción de información clave (tipo de problema, urgencia, recursos afectados).\nGeneración de respuestas contextualizadas para el cliente.\nCreación automática de descripciones estructuradas para el equipo de DevOps.\nSistema de Logs y Monitoreo # Tokenizer para el control de consumo de la API.\nLogs detallados de todas las interacciones.\nMétricas de uso y rendimiento.\nGestión de Base de Datos # ORM Django para la manipulación eficiente de los datos.\nEstructura relacional optimizada.\nHistorial completo de solicitudes.\nPlataforma Web # Interfaz moderna y responsiva.\nDashboard con métricas (Total de Tareas, En Progreso, Completadas).\nVisualización detallada de cada tarea.\nSistema de etiquetas (tags) y categorización.\nFiltros y búsqueda avanzada.\nStack Tecnológico # Backend # Python: Lenguaje principal para el bot y la lógica de negocio.\nDjango: Framework web y ORM para la gestión de la base de datos.\nPostgreSQL: Base de datos relacional robusta y escalable.\nFrontend # Next.js: Framework de React para aplicaciones web modernas.\nTypeScript: Tipado estático para un código más seguro.\nTailwind CSS: Framework de CSS utilitario para diseño responsivo.\nInteligencia Artificial # OpenAI API: Procesamiento de lenguaje natural y generación de respuestas. Infraestructura # Telegram Bot API: Integración con Telegram.\nRESTful API: Comunicación entre componentes.\nHerramientas de Desarrollo # PyCharm: IDE para desarrollo en Python.\nDataGrip: Gestión y visualización de la base de datos.\nWebStorm: IDE para desarrollo frontend.\nFlujo de Funcionamiento # 1. Recepción de la Solicitud # Cuando un cliente envía un mensaje en el grupo de Telegram:\n\u0026#34;Hola a todos, Estamos teniendo un problema aquí y necesitamos ayuda. El sistema se cayó hace unos 20 minutos y no vuelve a estar en línea. Los usuarios se quejan de que no pueden acceder a la plataforma. ¿Pueden verificar qué está pasando? ¿Podría ser algo relacionado con Kubernetes? ¿Los pods están funcionando normalmente? ¿Y qué hay de los recursos en AWS? ¿Se habrá superado algún límite de CPU o memoria en las instancias? Necesitamos que esto vuelva a funcionar lo antes posible. ¿Tienen alguna idea de lo que puede estar ocurriendo? ¡Gracias!\u0026#34; 2. Procesamiento por el Bot # El bot captura el mensaje y lo envía a la API de OpenAI, que:\nIdentifica que es una solicitud de soporte.\nExtrae información relevante (problema: sistema caído, causa posible: Kubernetes/AWS).\nClasifica la urgencia (alta, debido al impacto en los usuarios).\nGenera una respuesta para el cliente.\n3. Respuesta Automática # El bot responde inmediatamente:\n\u0026#34;¡Hola! Hemos recibido tu solicitud y estamos verificando lo ocurrido. Agradecemos tu paciencia y nos pondremos en contacto pronto con más información.\u0026#34; 4. Creación de la Tarea # El sistema crea automáticamente una tarea estructurada:\n\\[Incidente\\] - Problema de caída del sistema con posibles impactos en Kubernetes y recursos AWS.\nDescripción: Investigar caída del sistema y analizar posibles problemas en Kubernetes y recursos en AWS en relación a límites de CPU y memoria.\nCliente: Infra EmpresaABC.\nTags: #infra #aws #kubernetes.\nEstado: Estimación → Complejo.\nFecha de Creación: 22/01/2026.\n5. Visualización en la Plataforma # El equipo de DevOps accede a la plataforma web y visualiza:\nDashboard con todas las tareas.\nDetalles completos de la solicitud.\nHistorial de interacciones.\nPosibilidad de actualizar estados y añadir comentarios.\nBeneficios de la Solución # Para el Cliente # Respuesta inmediata y automática.\nConfirmación de que la solicitud fue recibida.\nTransparencia en el proceso.\nPara el Equipo de DevOps # Centralización de todas las solicitudes.\nOrganización y priorización facilitadas.\nReducción de tareas perdidas u olvidadas.\nHistorial completo de atenciones.\nMétricas e indicadores de rendimiento.\nPara la Organización # Automatización de procesos manuales.\nReducción del tiempo de respuesta.\nMejora en la calidad de la atención.\nDatos estructurados para análisis y mejora continua.\nDesafíos y Aprendizajes # Integración con APIs # Trabajar con la API de OpenAI exigió una comprensión profunda de:\nGestión de tokens.\nOptimización de prompts.\nTratamiento de errores y fallbacks.\nControl de costes.\nArquitectura Desacoplada # Diseñar un sistema modular desde el inicio fue fundamental para:\nFacilitar el mantenimiento.\nPermitir la evolución independiente de los componentes.\nPosibilitar pruebas aisladas.\nGarantizar la escalabilidad.\nProcesamiento de Lenguaje Natural # Crear prompts eficientes para extraer información relevante de los mensajes fue un proceso iterativo de:\nPruebas con diferentes escenarios.\nAjustes en los prompts.\nValidación de la calidad de las respuestas.\nEste proyecto fue una excelente oportunidad para aplicar conocimientos de:\nPython y desarrollo de bots.\nInteligencia Artificial aplicada a problemas reales.\nArquitectura de software desacoplada y escalable.\nDevOps y automatización de procesos.\nDesarrollo full-stack con tecnologías modernas.\nMás que un proyecto técnico, fue una experiencia de aprendizaje sobre cómo la IA puede aplicarse para resolver problemas reales y mejorar los procesos del día a día.\n¡Estoy emocionado por seguir evolucionando esta solución y explorando nuevas posibilidades de automatización e inteligencia artificial en el contexto de DevOps!\n¿Quieres Saber Más? # Si tienes interés en:\nImplementar una solución similar.\nContribuir con el proyecto.\nDiscutir arquitectura y buenas prácticas.\nCompartir experiencias con automatización e IA.\n¡Ponte en contacto!\n","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/blog/bot-automatizador-de-tareas-devops/bot-automatizador-de-tareas-devops/","section":"Blog","summary":"","title":"Bot de IA para Automatización de Tareas DevOps vía Telegram","type":"blog"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/categories/develop/","section":"Categories","summary":"","title":"Develop","type":"categories"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/tags/django/","section":"Tags","summary":"","title":"Django","type":"tags"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/categories/inteligencia-artificial/","section":"Categories","summary":"","title":"Inteligencia Artificial","type":"categories"},{"content":"","date":"26 enero 2026","externalUrl":null,"permalink":"/blog/pt/categories/intelig%C3%AAncia-artificial/","section":"Categories","summary":"","title":"Inteligência Artificial","type":"categories"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/tags/next.js/","section":"Tags","summary":"","title":"Next.js","type":"tags"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/tags/openai/","section":"Tags","summary":"","title":"OpenAI","type":"tags"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/tags/python/","section":"Tags","summary":"","title":"Python","type":"tags"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/authors/samuel-maximo/","section":"Authors","summary":"","title":"Samuel-Maximo","type":"authors"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/tags/telegram/","section":"Tags","summary":"","title":"Telegram","type":"tags"},{"content":"El Blog de Gole es un espacio creado para compartir experiencias, soluciones y lecciones aprendidas por nuestro equipo en las áreas de DevOps, Desarrollo y Redes.\nFormamos parte de Gole Suite, una plataforma que ofrece soluciones innovadoras para la gestión de infraestructura, automatización e integración de sistemas. Nuestra misión es conectar la tecnología y las personas mediante herramientas inteligentes y prácticas eficientes.\nSigue nuestras publicaciones para mantenerte al día con las mejores prácticas, tutoriales y conocimientos que impulsan la innovación diaria en tecnología.\n","date":"26 de enero de 2026","externalUrl":null,"permalink":"/blog/es/","section":"Últimas publicaciones","summary":"","title":"Últimas publicaciones","type":"page"},{"content":"","date":"22 diciembre 2025","externalUrl":null,"permalink":"/blog/pt/tags/kafka/","section":"Tags","summary":"","title":"Kafka","type":"tags"},{"content":" KEDA autoscaling baseado nas filas do Kafka # O que é o KEDA e o que ele faz? # O KEDA (Kubernetes Event-Driven Autoscaling) é uma ferramenta desenvolvida para ajudar no escalonamento automático de réplicas de containers com base em eventos reais.\nEle permite aumentar ou diminuir as réplicas da aplicação com base, por exemplo, na quantidade de mensagens recebidas em uma fila Kafka ou RabbitMQ, ou ainda em um alto número de requisições HTTP.\nEsse modelo de autoscaling é mais eficiente do que o tradicional baseado apenas em CPU ou memória, pois reflete melhor a carga real da aplicação.\nQuais são as principais peças do KEDA? # KEDA Operator # Responsável por consultar as fontes de dados externas e alterar automaticamente o número de réplicas das aplicações.\nKEDA Metrics Server # É o componente que fornece ao HPA (Horizontal Pod Autoscaler) métricas adicionais para a tomada de decisão sobre o autoscaling.\nKEDA Scalers # Traduzem métricas externas (Kafka, RabbitMQ, Prometheus, etc.) em valores numéricos que o HPA consegue utilizar.\nCRDs (Custom Resource Definitions) # Armazenam os parâmetros que definem quando o autoscaling deve começar.\nScaledObject\nDefine os gatilhos (triggers) e as regras que indicam quando o processo de autoscaling deve ser iniciado. Como funciona o fluxo de autoscaling do KEDA? # Quando existe um aumento de mensagens em uma fila Kafka, o fluxo ocorre da seguinte forma:\nOs gatilhos definidos no ScaledObject são ativados As regras configuradas são processadas pelo KEDA Controller O Metrics Adapter fornece as métricas externas ao HPA O HPA decide aumentar ou diminuir o número de réplicas O Admission Webhook valida a configuração aplicada, evitando erros Instalação do KEDA com Helm # A instalação do KEDA pode ser feita de forma simples utilizando o Helm.\nObs: foi realizado o export do arquivo values.yaml para ajustar tolerations, affinity e configurações adicionais.\nkubectl create namespace keda helm repo add kedacore https://kedacore.github.io/charts helm repo update helm show values kedacore/keda \u0026gt; values.yaml helm install -n keda keda kedacore/keda -f values.yaml Arquitetura do exemplo # Para este exemplo, criamos dois microsserviços simples, executando no mesmo namespace:\nProdutor de mensagens: responsável por enviar mensagens para um tópico Kafka. Consumidor de mensagens: responsável por consumir as mensagens e que será escalado automaticamente pelo KEDA. Obs: Caso queira realizar um teste utilizando as imagens docker que construimos: Produtor: gole/kafka-producer-keda:1.0 Consumidor: gole/kafka-consumer-keda:1.0\nServiço produtor de mensagens (Kafka Producer) # ConfigMap\nObs: como estamos utilizando o mesmo namespace para os dois serviços, usamos o mesmo ConfigMap.\napiVersion: v1 kind: ConfigMap metadata: name: kafka-config data: KAFKA_BOOTSTRAP_SERVERS: \u0026#34;kafka:9092\u0026#34; KAFKA_TOPIC: \u0026#34;demo-topic\u0026#34; MESSAGE_INTERVAL_SECONDS: \u0026#34;10\u0026#34; MESSAGE_BATCH_SIZE: \u0026#34;100\u0026#34; Deployment do Producer\napiVersion: apps/v1 kind: Deployment metadata: name: kafka-producer spec: replicas: 1 selector: matchLabels: app: kafka-producer template: metadata: labels: app: kafka-producer spec: containers: - name: producer image: gole/kafka-producer-keda:1.0 envFrom: - configMapRef: name: kafka-config Serviço consumidor de mensagens (Kafka Consumer) # Deployment do Consumer\napiVersion: apps/v1 kind: Deployment metadata: name: kafka-consumer spec: replicas: 1 selector: matchLabels: app: kafka-consumer template: metadata: labels: app: kafka-consumer spec: containers: - name: consumer image: gole/kafka-consumer-keda:1.0 envFrom: - configMapRef: name: kafka-config resources: requests: cpu: \u0026#34;100m\u0026#34; memory: \u0026#34;128Mi\u0026#34; limits: cpu: \u0026#34;500m\u0026#34; memory: \u0026#34;256Mi\u0026#34; ScaledObject para autoscaling com Kafka\nObs: O valor de maxReplicaCount deve ser igual ou inferior à quantidade de partições do tópico Kafka. Outro ponto é que nós estamos configurando este exemplo sem autenticação.\napiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default labels: deploymentName: kafka-consumer spec: scaleTargetRef: name: kafka-consumer pollingInterval: 5 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: kafka metadata: consumerGroup: demo-consumer-group bootstrapServers: kafka:9092 topic: demo-topic lagThreshold: \u0026#34;1000\u0026#34; offsetResetPolicy: \u0026#34;latest\u0026#34; authMode: \u0026#34;none\u0026#34; Teste de estresse # Vemos na imagem abaixo que o lag ainda não atingiu o valor que definimos.\nE para validar se o autoscaling está funcionando, ajustamos as variáveis no ConfigMap para os seguintes valores:\nMESSAGE_INTERVAL_SECONDS: \u0026#34;2\u0026#34; MESSAGE_BATCH_SIZE: \u0026#34;10000\u0026#34; Isso significa que, a cada 2 segundos, o produtor enviará 10.000 mensagens para o Kafka. Esse volume irá gerar lag no consumer e, como definido no lagThreshold do ScaledObject, ao ultrapassar 1.000 mensagens pendentes, o autoscaling será acionado automaticamente\nLogo após ajustarmos o configmap os lags começaram como vimos na imagem acima e o scaling começa acontecer.\nApoś uns 2 minutos de lag, o maximo de replicas já é atingido para consumir as mensagens. Uma vez consumida todas as mensagens. As replicas vão baixando: E por fim volta ao minimo de replicas: Conclusão # Finalizamos este conteúdo mostrando como o KEDA trabalha o autoscaling de aplicações Kubernetes se baseando em eventos reais, utilizando como no exemplo o lag de um tópico Kafka como métrica principal. Com isso vemos que o autoscaling baseado em eventos se torna mais eficiente do que métricas como CPU e memória, uma vez que os eventos aumentem gradativamente sem alterar o consumo dos serviços. Autoscaling baseado em eventos é mais eficiente do que métricas tradicionais como CPU e memória\nLições aprendidas # O maxReplicaCount deve respeitar o número de partições do tópico Kafka Após o consumo das mensagens, o KEDA realiza o scale down automaticamente O KEDA se integra de forma simples ao Kubernetes e ao HPA, sem complexidade adicional ","date":"22 diciembre 2025","externalUrl":null,"permalink":"/blog/pt/blog/keda-lag-kafka/keda-lag-kafka/","section":"Blog","summary":"","title":"Keda e as filas do Kafka","type":"blog"},{"content":"","date":"22 diciembre 2025","externalUrl":null,"permalink":"/blog/pt/categories/tecnologia/","section":"Categories","summary":"","title":"Tecnologia","type":"categories"},{"content":"Aquí encontrará una visión clara y objetiva sobre tres modelos esenciales para las organizaciones modernas: entorno físico, entorno híbrido y entorno virtual. Cada uno ofrece características únicas que ayudan a las empresas a operar con eficiencia, seguridad y flexibilidad.\nExplore los artículos a continuación para entender cómo funciona cada modelo:\n","date":"8 de enero de 2025","externalUrl":null,"permalink":"/blog/es/alojamiento/","section":"Alojamiento","summary":"","title":"Alojamiento","type":"alojamiento"},{"content":" Laboratorio GOLE: El conocimiento técnico de nuestro equipo # El Laboratorio GOLE es el espacio donde nuestro equipo comparte sus experiencias diarias: instalaciones, configuraciones, mejores prácticas, tutoriales y soluciones prácticas aplicadas a proyectos. Aquí encontrarás contenido producido por expertos en DevOps, SRE, infraestructura, Kubernetes, redes, nube y mucho más.\nNuestro objetivo es crear un entorno donde el aprendizaje sea continuo y accesible. Cada publicación refleja la experiencia de quienes están en primera línea, resolviendo problemas, probando tecnologías y proponiendo mejoras.\nExplora, aprende e implementa: el Laboratorio GOLE está diseñado para ayudarte a evolucionar tu stack, tus operaciones y tu forma de pensar sobre la tecnología.\n","date":"8 de enero de 2025","externalUrl":null,"permalink":"/blog/es/blog/","section":"Blog","summary":"","title":"Blog","type":"blog"},{"content":"Nuestra suscripción mensual pone a su disposición un amplio portafolio de soluciones. Si la solución que busca no está en nuestro catálogo, contacte con nuestro equipo. Con gusto la pondremos a su disposición.\n","date":"8 de enero de 2025","externalUrl":null,"permalink":"/blog/es/gole-como-servicio/","section":"Gole como servicio","summary":"","title":"Gole como servicio","type":"gole-como-servicio"},{"content":" Físico # Servidores Físicos # Flexibilidad para alojar tus servidores físicos en nuestro entorno seguro o mediante servidores físicos dedicados.\nServidores Físicos para IA # Servidores físicos de alto rendimiento, optimizados para cargas intensivas de Inteligencia Artificial.\n","date":"5 de enero de 2025","externalUrl":null,"permalink":"/blog/es/alojamiento/fisic/","section":"Alojamiento","summary":"","title":"Hosting Físico","type":"alojamiento"},{"content":" Híbrido # Hosting Híbrido # La robustez de servidores físicos dedicados integrada con la flexibilidad y escalabilidad de entornos virtuales privados completos.\nEn este modelo, las configuraciones de redes virtuales, entornos preproductivos y productivos, VLANs y servicios se integran cuidadosamente entre los servidores físicos y su entorno virtual, de forma transparente para los servicios y aplicaciones.\n","date":"5 de enero de 2025","externalUrl":null,"permalink":"/blog/es/alojamiento/hibrido/","section":"Alojamiento","summary":"","title":"Hosting Híbrido","type":"alojamiento"},{"content":" Virtual # Hosting de Sitios # Entrega de alto rendimiento, baja latencia y seguridad, garantizando rapidez y disponibilidad.\nClusters de Kubernetes # La mejor relación costo-beneficio de Brasil, integrado con repositorios de código y con rendimiento superior a regiones fuera de América Latina.\nEntornos Virtuales Privados # Redes privadas segmentadas según tu necesidad. Instancias, servidores, sistemas operativos y servicios para tu empresa.\nEntornos Virtuales de IA # Entornos completos, preparados para entrenamiento, inferencia y experimentación con alto rendimiento.\n","date":"5 de enero de 2025","externalUrl":null,"permalink":"/blog/es/alojamiento/virtual/","section":"Alojamiento","summary":"","title":"Hosting Virtual","type":"alojamiento"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/cloud/","section":"Tags","summary":"","title":"Cloud","type":"tags"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/containers/","section":"Tags","summary":"","title":"Containers","type":"tags"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/categories/devops/","section":"Categories","summary":"","title":"DevOps","type":"categories"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/devops/","section":"Tags","summary":"","title":"DevOps","type":"tags"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/categories/infraestructura/","section":"Categories","summary":"","title":"Infraestructura","type":"categories"},{"content":"","date":"10 octubre 2025","externalUrl":null,"permalink":"/blog/pt/categories/infraestrutura/","section":"Categories","summary":"","title":"Infraestrutura","type":"categories"},{"content":"","date":"octubre 10, 2025","externalUrl":null,"permalink":"/blog/en/categories/infrastructure/","section":"Categories","summary":"","title":"Infrastructure","type":"categories"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/k8s/","section":"Tags","summary":"","title":"K8s","type":"tags"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/kubernetes/","section":"Tags","summary":"","title":"Kubernetes","type":"tags"},{"content":"","date":"octubre 10, 2025","externalUrl":null,"permalink":"/blog/en/tags/orchestration/","section":"Tags","summary":"","title":"Orchestration","type":"tags"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/orquestaci%C3%B3n/","section":"Tags","summary":"","title":"Orquestación","type":"tags"},{"content":"","date":"10 octubre 2025","externalUrl":null,"permalink":"/blog/pt/tags/orquestra%C3%A7%C3%A3o/","section":"Tags","summary":"","title":"Orquestração","type":"tags"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"10 de enero de 2025","externalUrl":null,"permalink":"/blog/es/authors/samuelmaximo/","section":"Authors","summary":"","title":"Samuelmaximo","type":"authors"},{"content":"","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/authors/alfredo/","section":"Authors","summary":"","title":"Alfredo","type":"authors"},{"content":"","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/authors/alfredo-borges/","section":"Authors","summary":"","title":"Alfredo-Borges","type":"authors"},{"content":"","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/dcgm-exporter/","section":"Tags","summary":"","title":"DCGM-Exporter","type":"tags"},{"content":"","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/grafana/","section":"Tags","summary":"","title":"Grafana","type":"tags"},{"content":" Introdução # Você sabia que cada GPU do seu ambiente pode gerar dados valiosos? Se analisadas corretamente, essas métricas podem otimizar o desempenho, reduzir custos e acelerar decisões estratégicas.\nO DCGM-Exporter da NVIDIA permite extrair métricas detalhadas de GPUs, integrando-se facilmente com Prometheus e Grafana para dashboards inteligentes e visualizações em tempo real.\nPor que é importante monitorar suas GPUs # Muitas empresas perdem oportunidades por não acompanharem corretamente seus recursos de GPU. Com um monitoramento estratégico, você pode:\nDetectar gargalos de desempenho antes que afetem a produção. Otimizar o uso de recursos e reduzir custos. Tomar decisões baseadas em dados, não em suposições. Monitorar múltiplos clusters de forma centralizada. O verdadeiro valor surge quando você consegue centralizar métricas e transformá-las em insights acionáveis.\nO que você vai descobrir neste post # Aqui você aprenderá, passo a passo:\nConfigurar rapidamente o DCGM-Exporter no Docker Fazer deploy no Kubernetes usando Helm Chart Integrar métricas ao Prometheus central Visualizar dashboards poderosos no Grafana Tudo isso com foco em transformar métricas brutas em informações estratégicas para o seu negócio.\nExecutando DCGM-Exporter no Docker # Para rodar o DCGM-Exporter rapidamente em uma máquina com GPU:\ndocker run -d --gpus all --cap-add SYS_ADMIN --rm -p 9400:9400 nvcr.io/nvidia/k8s/dcgm-exporter:4.4.1-4.5.2-ubuntu22.04 Testar o endpoint de métricas:\ncurl localhost:9400/metrics Saída esperada:\n# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz). # TYPE DCGM_FI_DEV_SM_CLOCK gauge DCGM_FI_DEV_SM_CLOCK{gpu=\u0026#34;0\u0026#34;,UUID=\u0026#34;GPU-604ac76c-d9cf-xxx\u0026#34;} 139 Deploy do DCGM-Exporter no Kubernetes # A NVIDIA mantém um Helm Chart oficial para instalar o DCGM-Exporter em clusters Kubernetes:\nhelm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helm repo update helm install --generate-name gpu-helm-charts/dcgm-exporter Verificar o pod:\nkubectl get pods -l \u0026#34;app.kubernetes.io/name=dcgm-exporter\u0026#34; -n default Acessar métricas localmente:\nkubectl port-forward svc/dcgm-exporter 8080:9400 curl http://127.0.0.1:8080/metrics Configurando Prometheus Local no Docker # Adicione um job de scrape para coletar métricas do DCGM-Exporter em prometheus.yml:\nscrape_configs: - job_name: \u0026#34;dcgm-exporter\u0026#34; static_configs: - targets: [\u0026#34;host.docker.internal:9400\u0026#34;] Use host.docker.internal no Docker Desktop (Windows/Mac). No Linux, substitua pelo IP da máquina host.\nReinicie o Prometheus:\ndocker run -d --name prometheus --network=host -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus Agora suas métricas do DCGM-Exporter serão coletadas corretamente.\nIntegração com Grafana # A NVIDIA oferece um dashboard oficial para visualizar as métricas:\nDashboard: DCGM Exporter Grafana Dashboard #12239 JSON para importar: grafana/dcgm-exporter-dashboard.json Basta importar o JSON no Grafana e começar a explorar insights em tempo real.\nPara aproveitar todo o potencial dos seus dados, envie as métricas do Prometheus local para um Prometheus central, que se comunica diretamente com o Grafana, permitindo:\nVisualizações precisas e em tempo real. Insights acionáveis para decisões estratégicas. Monitoramento simplificado de múltiplos clusters. Quer saber mais ou implementar essa integração no seu ambiente? Entre em contato e transforme suas métricas em decisões inteligentes!\nConclusão # Com o DCGM-Exporter, é possível monitorar GPUs em ambientes on-premise ou clusters Kubernetes, integrando de forma simples com Prometheus e Grafana.\n","date":"18 septiembre 2025","externalUrl":null,"permalink":"/blog/pt/blog/xportador-dcgm/exportador-dcgm/","section":"Blog","summary":"","title":"Monitoramento Avançado de GPUs com DCGM-Exporter, Prometheus e Grafana","type":"blog"},{"content":" Introdução # Você sabia que cada GPU do seu ambiente pode gerar dados valiosos? Se analisadas corretamente, essas métricas podem otimizar o desempenho, reduzir custos e acelerar decisões estratégicas.\nO DCGM-Exporter da NVIDIA permite extrair métricas detalhadas de GPUs, integrando-se facilmente com Prometheus e Grafana para dashboards inteligentes e visualizações em tempo real.\nPor que é importante monitorar suas GPUs # Muitas empresas perdem oportunidades por não acompanharem corretamente seus recursos de GPU. Com um monitoramento estratégico, você pode:\nDetectar gargalos de desempenho antes que afetem a produção. Otimizar o uso de recursos e reduzir custos. Tomar decisões baseadas em dados, não em suposições. Monitorar múltiplos clusters de forma centralizada. O verdadeiro valor surge quando você consegue centralizar métricas e transformá-las em insights acionáveis.\nO que você vai descobrir neste post # Aqui você aprenderá, passo a passo:\nConfigurar rapidamente o DCGM-Exporter no Docker Fazer deploy no Kubernetes usando Helm Chart Integrar métricas ao Prometheus central Visualizar dashboards poderosos no Grafana Tudo isso com foco em transformar métricas brutas em informações estratégicas para o seu negócio.\nExecutando DCGM-Exporter no Docker # Para rodar o DCGM-Exporter rapidamente em uma máquina com GPU:\ndocker run -d --gpus all --cap-add SYS_ADMIN --rm -p 9400:9400 nvcr.io/nvidia/k8s/dcgm-exporter:4.4.1-4.5.2-ubuntu22.04 Testar o endpoint de métricas:\ncurl localhost:9400/metrics Saída esperada:\n# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz). # TYPE DCGM_FI_DEV_SM_CLOCK gauge DCGM_FI_DEV_SM_CLOCK{gpu=\u0026#34;0\u0026#34;,UUID=\u0026#34;GPU-604ac76c-d9cf-xxx\u0026#34;} 139 Deploy do DCGM-Exporter no Kubernetes # A NVIDIA mantém um Helm Chart oficial para instalar o DCGM-Exporter em clusters Kubernetes:\nhelm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helm repo update helm install --generate-name gpu-helm-charts/dcgm-exporter Verificar o pod:\nkubectl get pods -l \u0026#34;app.kubernetes.io/name=dcgm-exporter\u0026#34; -n default Acessar métricas localmente:\nkubectl port-forward svc/dcgm-exporter 8080:9400 curl http://127.0.0.1:8080/metrics Configurando Prometheus Local no Docker # Adicione um job de scrape para coletar métricas do DCGM-Exporter em prometheus.yml:\nscrape_configs: - job_name: \u0026#34;dcgm-exporter\u0026#34; static_configs: - targets: [\u0026#34;host.docker.internal:9400\u0026#34;] Use host.docker.internal no Docker Desktop (Windows/Mac). No Linux, substitua pelo IP da máquina host.\nReinicie o Prometheus:\ndocker run -d --name prometheus --network=host -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus Agora suas métricas do DCGM-Exporter serão coletadas corretamente.\nIntegração com Grafana # A NVIDIA oferece um dashboard oficial para visualizar as métricas:\nDashboard: DCGM Exporter Grafana Dashboard #12239 JSON para importar: grafana/dcgm-exporter-dashboard.json Basta importar o JSON no Grafana e começar a explorar insights em tempo real.\nPara aproveitar todo o potencial dos seus dados, envie as métricas do Prometheus local para um Prometheus central, que se comunica diretamente com o Grafana, permitindo:\nVisualizações precisas e em tempo real. Insights acionáveis para decisões estratégicas. Monitoramento simplificado de múltiplos clusters. Quer saber mais ou implementar essa integração no seu ambiente? Entre em contato e transforme suas métricas em decisões inteligentes!\nConclusão # Com o DCGM-Exporter, é possível monitorar GPUs em ambientes on-premise ou clusters Kubernetes, integrando de forma simples com Prometheus e Grafana.\n","date":"18 septiembre 2025","externalUrl":null,"permalink":"/blog/pt/posts/xportador-dcgm/exportador-dcgm/","section":"Posts","summary":"","title":"Monitoramento Avançado de GPUs com DCGM-Exporter, Prometheus e Grafana","type":"posts"},{"content":" Introducción # ¿Sabías que cada GPU de tu entorno puede generar datos valiosos? Si se analizan correctamente, estas métricas pueden optimizar el rendimiento, reducir costos y acelerar decisiones estratégicas.\nEl DCGM-Exporter de NVIDIA permite extraer métricas detalladas de GPUs, integrándose fácilmente con Prometheus y Grafana para dashboards inteligentes y visualizaciones en tiempo real.\nPor qué importa monitorear tus GPUs # Muchas empresas pierden oportunidades por no seguir correctamente sus recursos de GPU. Con un monitoreo estratégico, puedes:\nDetectar cuellos de botella de rendimiento antes de que afecten la producción. Optimizar el uso de recursos y reducir costos. Tomar decisiones basadas en datos, no en suposiciones. Monitorear múltiples clusters de forma centralizada. El verdadero valor surge cuando logras centralizar métricas y transformarlas en insights accionables.\nLo que descubrirás en este post # Aquí aprenderás, paso a paso:\nConfigurar rápidamente el DCGM-Exporter en Docker Hacer deploy en Kubernetes usando Helm Chart Integrar métricas al Prometheus central Visualizar dashboards poderosos en Grafana Todo esto con enfoque en transformar métricas crudas en información estratégica para tu negocio.\nEjecutando DCGM-Exporter en Docker # Para correr el DCGM-Exporter rápidamente en una máquina con GPU:\ndocker run -d --gpus all --cap-add SYS_ADMIN --rm -p 9400:9400 \\ nvcr.io/nvidia/k8s/dcgm-exporter:4.4.1-4.5.2-ubuntu22.04 Probar el endpoint de métricas:\ncurl localhost:9400/metrics Salida esperada:\n# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz). # TYPE DCGM_FI_DEV_SM_CLOCK gauge DCGM_FI_DEV_SM_CLOCK{gpu=\u0026#34;0\u0026#34;,UUID=\u0026#34;GPU-604ac76c-d9cf-xxx\u0026#34;} 139 Deploy de DCGM-Exporter en Kubernetes # NVIDIA mantiene un Helm Chart oficial para instalar el DCGM-Exporter en clusters Kubernetes:\nhelm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helm repo update helm install --generate-name gpu-helm-charts/dcgm-exporter Verificar el pod:\nkubectl get pods -l \u0026#34;app.kubernetes.io/name=dcgm-exporter\u0026#34; -n default Acceder a métricas localmente:\nkubectl port-forward svc/dcgm-exporter 8080:9400 curl http://127.0.0.1:8080/metrics Configurando Prometheus Local en Docker # Agrega un job de scrape para recolectar métricas de DCGM-Exporter en prometheus.yml:\nscrape_configs: - job_name: \u0026#34;dcgm-exporter\u0026#34; static_configs: - targets: [\u0026#34;host.docker.internal:9400\u0026#34;] Usa host.docker.internal en Docker Desktop (Windows/Mac). En Linux, reemplaza con la IP de la máquina host.\nReinicia Prometheus:\ndocker run -d --name prometheus --network=host \\ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \\ prom/prometheus Ahora tus métricas de DCGM-Exporter serán recolectadas correctamente.\nIntegración con Grafana # NVIDIA ofrece un dashboard oficial para visualizar las métricas:\nDashboard: DCGM Exporter Grafana Dashboard #12239 JSON para importar: grafana/dcgm-exporter-dashboard.json Solo importa el JSON en Grafana y empieza a explorar insights en tiempo real.\nPara aprovechar todo el potencial de tus datos, envía las métricas de Prometheus local a un Prometheus central, que se comunica directamente con Grafana, permitiendo:\nVisualizaciones precisas y en tiempo real. Insights accionables para decisiones estratégicas. Monitoreo simplificado de múltiples clusters. ¿Quieres saber más o implementar esta integración en tu entorno? ¡Contáctanos y transforma tus métricas en decisiones inteligentes!\nConclusión # Con DCGM-Exporter, es posible monitorear GPUs en entornos on-premise o clusters Kubernetes, integrando de forma sencilla con Prometheus y Grafana.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/blog/exportador-dcgm/exportador-de-dcgm/","section":"Blog","summary":"","title":"Monitoreo Avanzado de GPUs con DCGM-Exporter, Prometheus y Grafana","type":"post"},{"content":" Introducción # ¿Sabías que cada GPU de tu entorno puede generar datos valiosos? Si se analizan correctamente, estas métricas pueden optimizar el rendimiento, reducir costos y acelerar decisiones estratégicas.\nEl DCGM-Exporter de NVIDIA permite extraer métricas detalladas de GPUs, integrándose fácilmente con Prometheus y Grafana para dashboards inteligentes y visualizaciones en tiempo real.\nPor qué importa monitorear tus GPUs # Muchas empresas pierden oportunidades por no seguir correctamente sus recursos de GPU. Con un monitoreo estratégico, puedes:\nDetectar cuellos de botella de rendimiento antes de que afecten la producción. Optimizar el uso de recursos y reducir costos. Tomar decisiones basadas en datos, no en suposiciones. Monitorear múltiples clusters de forma centralizada. El verdadero valor surge cuando logras centralizar métricas y transformarlas en insights accionables.\nLo que descubrirás en este post # Aquí aprenderás, paso a paso:\nConfigurar rápidamente el DCGM-Exporter en Docker Hacer deploy en Kubernetes usando Helm Chart Integrar métricas al Prometheus central Visualizar dashboards poderosos en Grafana Todo esto con enfoque en transformar métricas crudas en información estratégica para tu negocio.\nEjecutando DCGM-Exporter en Docker # Para correr el DCGM-Exporter rápidamente en una máquina con GPU:\ndocker run -d --gpus all --cap-add SYS_ADMIN --rm -p 9400:9400 \\ nvcr.io/nvidia/k8s/dcgm-exporter:4.4.1-4.5.2-ubuntu22.04 Probar el endpoint de métricas:\ncurl localhost:9400/metrics Salida esperada:\n# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz). # TYPE DCGM_FI_DEV_SM_CLOCK gauge DCGM_FI_DEV_SM_CLOCK{gpu=\u0026#34;0\u0026#34;,UUID=\u0026#34;GPU-604ac76c-d9cf-xxx\u0026#34;} 139 Deploy de DCGM-Exporter en Kubernetes # NVIDIA mantiene un Helm Chart oficial para instalar el DCGM-Exporter en clusters Kubernetes:\nhelm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helm repo update helm install --generate-name gpu-helm-charts/dcgm-exporter Verificar el pod:\nkubectl get pods -l \u0026#34;app.kubernetes.io/name=dcgm-exporter\u0026#34; -n default Acceder a métricas localmente:\nkubectl port-forward svc/dcgm-exporter 8080:9400 curl http://127.0.0.1:8080/metrics Configurando Prometheus Local en Docker # Agrega un job de scrape para recolectar métricas de DCGM-Exporter en prometheus.yml:\nscrape_configs: - job_name: \u0026#34;dcgm-exporter\u0026#34; static_configs: - targets: [\u0026#34;host.docker.internal:9400\u0026#34;] Usa host.docker.internal en Docker Desktop (Windows/Mac). En Linux, reemplaza con la IP de la máquina host.\nReinicia Prometheus:\ndocker run -d --name prometheus --network=host \\ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \\ prom/prometheus Ahora tus métricas de DCGM-Exporter serán recolectadas correctamente.\nIntegración con Grafana # NVIDIA ofrece un dashboard oficial para visualizar las métricas:\nDashboard: DCGM Exporter Grafana Dashboard #12239 JSON para importar: grafana/dcgm-exporter-dashboard.json Solo importa el JSON en Grafana y empieza a explorar insights en tiempo real.\nPara aprovechar todo el potencial de tus datos, envía las métricas de Prometheus local a un Prometheus central, que se comunica directamente con Grafana, permitiendo:\nVisualizaciones precisas y en tiempo real. Insights accionables para decisiones estratégicas. Monitoreo simplificado de múltiples clusters. ¿Quieres saber más o implementar esta integración en tu entorno? ¡Contáctanos y transforma tus métricas en decisiones inteligentes!\nConclusión # Con DCGM-Exporter, es posible monitorear GPUs en entornos on-premise o clusters Kubernetes, integrando de forma sencilla con Prometheus y Grafana.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/posts/exportador-dcgm/exportador-de-dcgm/","section":"Posts","summary":"","title":"Monitoreo Avanzado de GPUs con DCGM-Exporter, Prometheus y Grafana","type":"post"},{"content":"","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/nvidia/","section":"Tags","summary":"","title":"NVIDIA","type":"tags"},{"content":"","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/categories/observabilidad/","section":"Categories","summary":"","title":"Observabilidad","type":"categories"},{"content":"","date":"18 septiembre 2025","externalUrl":null,"permalink":"/blog/pt/categories/observabilidade/","section":"Categories","summary":"","title":"Observabilidade","type":"categories"},{"content":"","date":"septiembre 18, 2025","externalUrl":null,"permalink":"/blog/en/categories/observability/","section":"Categories","summary":"","title":"Observability","type":"categories"},{"content":"","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/prometheus/","section":"Tags","summary":"","title":"Prometheus","type":"tags"},{"content":"","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/crowdsec/","section":"Tags","summary":"","title":"Crowdsec","type":"tags"},{"content":"","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/categories/crowdsec/","section":"Categories","summary":"","title":"CrowdSec","type":"categories"},{"content":" ¿Qué es un WAF? # El término WAF proviene de Web Application Firewall – o firewall de aplicaciones web.\nUn firewall tradicional actúa principalmente en la capa de red, filtrando paquetes en función de IP de origen, IP de destino, puerto de origen, puerto de destino y protocolo (TCP/UDP/ICMP). Es decir, garantiza que solo las conexiones autorizadas lleguen al servidor, pero no entiende el contenido del tráfico.\nEl WAF, en cambio, va más allá: está diseñado específicamente para proteger aplicaciones web. En lugar de analizar solo direcciones y puertos, el WAF inspecciona el contenido de las solicitudes HTTP/HTTPS. Esto le permite identificar y bloquear accesos maliciosos que pasarían inadvertidos para un firewall común.\nEjemplos de amenazas que el WAF ayuda a mitigar # Inyección SQL – cuando se envían comandos SQL maliciosos para manipular bases de datos. Cross-Site Scripting (XSS) – inyección de scripts que pueden robar datos de los usuarios. Bots maliciosos – que intentan explotar fallas o sobrecargar la aplicación. Fuerza bruta – intentos automáticos de adivinar contraseñas e inicios de sesión. En resumen # Firewall tradicional = se enfoca en la red → controla quién puede conectarse (en función de IP, puertos y protocolos). WAF = se enfoca en la aplicación web → analiza lo que hay dentro de la solicitud y protege contra ataques dirigidos al funcionamiento del sitio. En otras palabras, el WAF actúa como un escudo entre internet y su aplicación web, bloqueando amenazas antes de que causen impacto.\n¿Qué es CrowdSec? # CrowdSec es el WAF que usamos aquí en Gole.\nEs una solución open-source, colaborativa y moderna que no solo protege tu aplicación en tiempo real, sino que también aprende de los ataques ocurridos en otras partes del mundo.\nEs decir: cuando se detecta una IP maliciosa en un entorno, toda la comunidad CrowdSec puede beneficiarse y bloquear esa misma IP.\n¿Cómo funciona CrowdSec? # El funcionamiento es fácil de entender:\nMonitorea los logs de servicios como Nginx, Traefik, SSH, aplicaciones web. Detecta comportamientos sospechosos (fuerza bruta, escaneos, abusos). Bloquea automáticamente las IPs maliciosas. Comparte esta información de forma anónima, fortaleciendo la red de protección. CrowdSec\nFuncionalidades principales # Monitoreo en tiempo real: captura logs de servicios como Nginx, Traefik, SSH, entre otros. Detección de ataques y abusos: identifica fuerza bruta, escaneos y comportamientos anómalos. Bloqueo automático de IPs: aplica sanciones locales o remotas, protegiendo tus aplicaciones. Paso a Paso: Configurando CrowdSec en Kubernetes # 1. Agregar el repositorio Helm y obtener los valores por defecto # helm repo add crowdsec https://crowdsecurity.github.io/helm-charts helm repo update helm show values crowdsec/crowdsec \u0026gt; crowdsec-default-values.yaml 2. Editar el archivo crowdsec-default-values.yaml # a) Configurar adquisición de logs (Traefik) # agent: acquisition: - namespace: traefik podName: traefik-* program: traefik b) Registro de la instancia (LAPI) # lapi: env: - name: ENROLL_KEY value: \u0026#34;TU_ENROLL_KEY\u0026#34; - name: ENROLL_INSTANCE_NAME value: \u0026#34;mi-cluster-k8s\u0026#34; - name: ENROLL_TAGS value: \u0026#34;k8s linux producción\u0026#34; c) Volúmenes persistentes # persistentVolume: data: enabled: true storageClassName: \u0026#34;tu-storage-class-name\u0026#34; size: 1Gi config: enabled: true storageClassName: \u0026#34;tu-storage-class-name\u0026#34; size: 100Mi 3. Crear namespace # kubectl create ns crowdsec 4. Instalar CrowdSec # helm install crowdsec crowdsec/crowdsec -n crowdsec -f crowdsec-default-values.yaml 5. Configurar bouncers (Traefik y Nginx) # a) Crear API Key # kubectl -n crowdsec exec -it crowdsec-lapi-* -- sh cscli bouncers add traefik b) Configurar middleware en Traefik # apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: bouncer namespace: traefik spec: plugin: bouncer: CrowdsecLapiKey: \u0026lt;TU_API_KEY\u0026gt; crowdsecLapiHost: \u0026#34;crowdsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecLapiPort: \u0026#34;8080\u0026#34; crowdsecAppsecHost: \u0026#34;crowdsec-appsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecAppsecPort: \u0026#34;7422\u0026#34; crowdsecAppsecScheme: http Enabled: true logLevel: DEBUG crowdsecMode: appsec c) Configurar bouncer en Nginx # controller: extraInitContainers: - name: init-clone-crowdsec-bouncer image: crowdsecurity/lua-bouncer-plugin env: - name: API_URL value: \u0026#34;http://crowdsec-service.crowdsec.svc.cluster.local:8080\u0026#34; - name: API_KEY value: \u0026#34;\u0026lt;API KEY\u0026gt;\u0026#34; - name: BOUNCER_CONFIG value: \u0026#34;/crowdsec/crowdsec-bouncer.conf\u0026#34; 6. Activar AppSec (WAF) # appsec: enabled: true acquisitions: - source: appsec listen_addr: \u0026#34;0.0.0.0:7422\u0026#34; path: / appsec_config: crowdsecurity/crs-vpatch labels: type: appsec env: - name: COLLECTIONS value: \u0026#34;crowdsecurity/appsec-wordpress\u0026#34; Monitoreo Avanzado con Grafana # El panel de CrowdSec tiene un límite de 500 alertas, lo que puede restringir la visibilidad de los eventos en entornos con alto tráfico. Para un monitoreo completo y detallado, creamos un dashboard en Grafana que permite observar bloqueos de IP, ataques y decisiones de seguridad en tiempo real.\nEste dashboard incluye:\nBloqueos Totales por Pods: Número de intentos bloqueados por pod, ayudando a identificar cuáles están más atacados. Ataques por Escenarios: Distribución de ataques según los escenarios de detección de CrowdSec, mostrando los tipos de amenaza más frecuentes. Bloqueos Totales por IP: Lista de IPs bloqueadas, el escenario y el total de ocurrencias, permitiendo un seguimiento fácil de las fuentes maliciosas. Registro de Decisiones: Registros detallados de decisiones con marcas de tiempo y datos de las solicitudes, proporcionando total transparencia de las acciones de CrowdSec. Accede al dashboard: Monitoreo CrowdSec en Grafana\nEsta función es esencial para que los equipos de seguridad monitoreen, analicen y respondan rápidamente a las amenazas en la infraestructura.\nConclusión # Con estas configuraciones, CrowdSec está integrado en tu clúster de Kubernetes, monitoreando logs, registrando instancias y protegiendo tus aplicaciones con Traefik, Nginx y WAF AppSec.\nAccede a la consola: https://app.crowdsec.net/security-engines\n","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/blog/crowdsec/crowdsec-que-es/","section":"Blog","summary":"","title":"CrowdSec - Qué es un WAF y cómo configurarlo en Kubernetes","type":"blog"},{"content":" ¿Qué es un WAF? # El término WAF proviene de Web Application Firewall – o firewall de aplicaciones web.\nUn firewall tradicional actúa principalmente en la capa de red, filtrando paquetes en función de IP de origen, IP de destino, puerto de origen, puerto de destino y protocolo (TCP/UDP/ICMP). Es decir, garantiza que solo las conexiones autorizadas lleguen al servidor, pero no entiende el contenido del tráfico.\nEl WAF, en cambio, va más allá: está diseñado específicamente para proteger aplicaciones web. En lugar de analizar solo direcciones y puertos, el WAF inspecciona el contenido de las solicitudes HTTP/HTTPS. Esto le permite identificar y bloquear accesos maliciosos que pasarían inadvertidos para un firewall común.\nEjemplos de amenazas que el WAF ayuda a mitigar # Inyección SQL – cuando se envían comandos SQL maliciosos para manipular bases de datos. Cross-Site Scripting (XSS) – inyección de scripts que pueden robar datos de los usuarios. Bots maliciosos – que intentan explotar fallas o sobrecargar la aplicación. Fuerza bruta – intentos automáticos de adivinar contraseñas e inicios de sesión. En resumen # Firewall tradicional = se enfoca en la red → controla quién puede conectarse (en función de IP, puertos y protocolos). WAF = se enfoca en la aplicación web → analiza lo que hay dentro de la solicitud y protege contra ataques dirigidos al funcionamiento del sitio. En otras palabras, el WAF actúa como un escudo entre internet y su aplicación web, bloqueando amenazas antes de que causen impacto.\n¿Qué es CrowdSec? # CrowdSec es el WAF que usamos aquí en Gole.\nEs una solución open-source, colaborativa y moderna que no solo protege tu aplicación en tiempo real, sino que también aprende de los ataques ocurridos en otras partes del mundo.\nEs decir: cuando se detecta una IP maliciosa en un entorno, toda la comunidad CrowdSec puede beneficiarse y bloquear esa misma IP.\n¿Cómo funciona CrowdSec? # El funcionamiento es fácil de entender:\nMonitorea los logs de servicios como Nginx, Traefik, SSH, aplicaciones web. Detecta comportamientos sospechosos (fuerza bruta, escaneos, abusos). Bloquea automáticamente las IPs maliciosas. Comparte esta información de forma anónima, fortaleciendo la red de protección. CrowdSec\nFuncionalidades principales # Monitoreo en tiempo real: captura logs de servicios como Nginx, Traefik, SSH, entre otros. Detección de ataques y abusos: identifica fuerza bruta, escaneos y comportamientos anómalos. Bloqueo automático de IPs: aplica sanciones locales o remotas, protegiendo tus aplicaciones. Paso a Paso: Configurando CrowdSec en Kubernetes # 1. Agregar el repositorio Helm y obtener los valores por defecto # helm repo add crowdsec https://crowdsecurity.github.io/helm-charts helm repo update helm show values crowdsec/crowdsec \u0026gt; crowdsec-default-values.yaml 2. Editar el archivo crowdsec-default-values.yaml # a) Configurar adquisición de logs (Traefik) # agent: acquisition: - namespace: traefik podName: traefik-* program: traefik b) Registro de la instancia (LAPI) # lapi: env: - name: ENROLL_KEY value: \u0026#34;TU_ENROLL_KEY\u0026#34; - name: ENROLL_INSTANCE_NAME value: \u0026#34;mi-cluster-k8s\u0026#34; - name: ENROLL_TAGS value: \u0026#34;k8s linux producción\u0026#34; c) Volúmenes persistentes # persistentVolume: data: enabled: true storageClassName: \u0026#34;tu-storage-class-name\u0026#34; size: 1Gi config: enabled: true storageClassName: \u0026#34;tu-storage-class-name\u0026#34; size: 100Mi 3. Crear namespace # kubectl create ns crowdsec 4. Instalar CrowdSec # helm install crowdsec crowdsec/crowdsec -n crowdsec -f crowdsec-default-values.yaml 5. Configurar bouncers (Traefik y Nginx) # a) Crear API Key # kubectl -n crowdsec exec -it crowdsec-lapi-* -- sh cscli bouncers add traefik b) Configurar middleware en Traefik # apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: bouncer namespace: traefik spec: plugin: bouncer: CrowdsecLapiKey: \u0026lt;TU_API_KEY\u0026gt; crowdsecLapiHost: \u0026#34;crowdsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecLapiPort: \u0026#34;8080\u0026#34; crowdsecAppsecHost: \u0026#34;crowdsec-appsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecAppsecPort: \u0026#34;7422\u0026#34; crowdsecAppsecScheme: http Enabled: true logLevel: DEBUG crowdsecMode: appsec c) Configurar bouncer en Nginx # controller: extraInitContainers: - name: init-clone-crowdsec-bouncer image: crowdsecurity/lua-bouncer-plugin env: - name: API_URL value: \u0026#34;http://crowdsec-service.crowdsec.svc.cluster.local:8080\u0026#34; - name: API_KEY value: \u0026#34;\u0026lt;API KEY\u0026gt;\u0026#34; - name: BOUNCER_CONFIG value: \u0026#34;/crowdsec/crowdsec-bouncer.conf\u0026#34; 6. Activar AppSec (WAF) # appsec: enabled: true acquisitions: - source: appsec listen_addr: \u0026#34;0.0.0.0:7422\u0026#34; path: / appsec_config: crowdsecurity/crs-vpatch labels: type: appsec env: - name: COLLECTIONS value: \u0026#34;crowdsecurity/appsec-wordpress\u0026#34; Monitoreo Avanzado con Grafana # El panel de CrowdSec tiene un límite de 500 alertas, lo que puede restringir la visibilidad de los eventos en entornos con alto tráfico. Para un monitoreo completo y detallado, creamos un dashboard en Grafana que permite observar bloqueos de IP, ataques y decisiones de seguridad en tiempo real.\nEste dashboard incluye:\nBloqueos Totales por Pods: Número de intentos bloqueados por pod, ayudando a identificar cuáles están más atacados. Ataques por Escenarios: Distribución de ataques según los escenarios de detección de CrowdSec, mostrando los tipos de amenaza más frecuentes. Bloqueos Totales por IP: Lista de IPs bloqueadas, el escenario y el total de ocurrencias, permitiendo un seguimiento fácil de las fuentes maliciosas. Registro de Decisiones: Registros detallados de decisiones con marcas de tiempo y datos de las solicitudes, proporcionando total transparencia de las acciones de CrowdSec. Accede al dashboard: Monitoreo CrowdSec en Grafana\nEsta función es esencial para que los equipos de seguridad monitoreen, analicen y respondan rápidamente a las amenazas en la infraestructura.\nConclusión # Con estas configuraciones, CrowdSec está integrado en tu clúster de Kubernetes, monitoreando logs, registrando instancias y protegiendo tus aplicaciones con Traefik, Nginx y WAF AppSec.\nAccede a la consola: https://app.crowdsec.net/security-engines\n","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/posts/crowdsec/crowdsec-que-es/","section":"Posts","summary":"","title":"CrowdSec - Qué es un WAF y cómo configurarlo en Kubernetes","type":"posts"},{"content":"","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/categories/kubernetes/","section":"Categories","summary":"","title":"Kubernetes","type":"categories"},{"content":"","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/nginx/","section":"Tags","summary":"","title":"Nginx","type":"tags"},{"content":"","date":"agosto 29, 2025","externalUrl":null,"permalink":"/blog/en/categories/security/","section":"Categories","summary":"","title":"Security","type":"categories"},{"content":"","date":"agosto 29, 2025","externalUrl":null,"permalink":"/blog/en/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/categories/seguridad/","section":"Categories","summary":"","title":"Seguridad","type":"categories"},{"content":"","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/seguridad/","section":"Tags","summary":"","title":"Seguridad","type":"tags"},{"content":"","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/traefik/","section":"Tags","summary":"","title":"Traefik","type":"tags"},{"content":"","date":"29 de enero de 2025","externalUrl":null,"permalink":"/blog/es/tags/waf/","section":"Tags","summary":"","title":"Waf","type":"tags"},{"content":" O que é um WAF? # O termo WAF vem de Web Application Firewall – ou firewall de aplicação web.\nUm firewall tradicional atua principalmente na camada de rede, filtrando pacotes com base em informações como IP de origem, IP de destino, porta de origem, porta de destino e protocolo (TCP/UDP/ICMP). Ou seja, ele garante que apenas conexões autorizadas cheguem ao servidor, mas não entende o conteúdo do tráfego.\nJá o WAF vai além: ele é projetado especificamente para proteger aplicações web. Em vez de analisar só endereços e portas, o WAF inspeciona o conteúdo das requisições HTTP/HTTPS. Isso permite identificar e bloquear acessos maliciosos que passam despercebidos por um firewall comum.\nExemplos de ameaças que o WAF ajuda a mitigar # SQL Injection – quando comandos SQL maliciosos são enviados para manipular bancos de dados. Cross-Site Scripting (XSS) – injeção de scripts que podem roubar dados de usuários. Bots maliciosos – que tentam explorar falhas ou sobrecarregar a aplicação. Brute force – tentativas automáticas de adivinhar senhas e logins. Resumindo # Firewall tradicional = foca em rede → controla quem pode se conectar (baseado em IP, portas e protocolos). WAF = foca em aplicação web → analisa o que está dentro da requisição e protege contra ataques direcionados ao funcionamento do site. Em outras palavras, o WAF funciona como um escudo entre a internet e sua aplicação web, bloqueando ameaças antes que causem impacto.\nO que é o CrowdSec? # O CrowdSec é o WAF que usamos aqui na Gole.\nEle é uma solução open-source, colaborativa e moderna, que além de proteger sua aplicação em tempo real, também aprende com ataques sofridos em outros lugares do mundo.\nOu seja: quando um IP malicioso é detectado em um ambiente, toda a comunidade CrowdSec pode se beneficiar e bloquear esse mesmo IP.\nComo o CrowdSec funciona? # O funcionamento é simples de entender:\nMonitora os logs de serviços como Nginx, Traefik, SSH, aplicações web. Detecta comportamentos suspeitos (força bruta, scans, abusos). Bloqueia automaticamente os IPs maliciosos. Compartilha de forma anônima essas informações, fortalecendo a rede de proteção. CrowdSec\nPrincipais Funcionalidades # Monitoramento em tempo real: captura logs de serviços como Nginx, Traefik, SSH, entre outros. Detecção de ataques e abusos: identifica brute force, scans e comportamentos anômalos. Bloqueio automático de IPs: aplica sanções locais ou remotas, protegendo suas aplicações. Passo a Passo: Configurando o CrowdSec no Kubernetes # 1. Adicionar o repositório Helm e obter valores padrão # helm repo add crowdsec https://crowdsecurity.github.io/helm-charts helm repo update helm show values crowdsec/crowdsec \u0026gt; crowdsec-default-values.yaml 2. Editar o arquivo crowdsec-default-values.yaml # a) Configurar aquisição de logs (Traefik) # agent: acquisition: - namespace: traefik podName: traefik-* program: traefik b) Registro da instância (LAPI) # lapi: env: - name: ENROLL_KEY value: \u0026#34;SEU_ENROLL_KEY\u0026#34; - name: ENROLL_INSTANCE_NAME value: \u0026#34;meu-cluster-k8s\u0026#34; - name: ENROLL_TAGS value: \u0026#34;k8s linux producao\u0026#34; c) Volumes persistentes # persistentVolume: data: enabled: true storageClassName: \u0026#34;you-storage-class-name\u0026#34; size: 1Gi config: enabled: true storageClassName: \u0026#34;you-storage-class-name\u0026#34; size: 100Mi 3. Criar namespace # kubectl create ns crowdsec 4. Instalar o CrowdSec # helm install crowdsec crowdsec/crowdsec -n crowdsec -f crowdsec-default-values.yaml 5. Configurar bouncers (Traefik e Nginx) # a) Criar API Key # kubectl -n crowdsec exec -it crowdsec-lapi-* -- sh cscli bouncers add traefik b) Configurar middleware no Traefik # apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: bouncer namespace: traefik spec: plugin: bouncer: CrowdsecLapiKey: \u0026lt;SUA_API_KEY\u0026gt; crowdsecLapiHost: \u0026#34;crowdsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecLapiPort: \u0026#34;8080\u0026#34; crowdsecAppsecHost: \u0026#34;crowdsec-appsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecAppsecPort: \u0026#34;7422\u0026#34; crowdsecAppsecScheme: http Enabled: true logLevel: DEBUG crowdsecMode: appsec c) Configurar bouncer no Nginx # controller: extraInitContainers: - name: init-clone-crowdsec-bouncer image: crowdsecurity/lua-bouncer-plugin env: - name: API_URL value: \u0026#34;http://crowdsec-service.crowdsec.svc.cluster.local:8080\u0026#34; - name: API_KEY value: \u0026#34;\u0026lt;API KEY\u0026gt;\u0026#34; - name: BOUNCER_CONFIG value: \u0026#34;/crowdsec/crowdsec-bouncer.conf\u0026#34; 6. Ativar o AppSec (WAF) # appsec: enabled: true acquisitions: - source: appsec listen_addr: \u0026#34;0.0.0.0:7422\u0026#34; path: / appsec_config: crowdsecurity/crs-vpatch labels: type: appsec env: - name: COLLECTIONS value: \u0026#34;crowdsecurity/appsec-wordpress\u0026#34; Monitoramento Avançado com Grafana # O console do CrowdSec possui um limite de 500 alertas, o que pode restringir a visualização de eventos em ambientes com tráfego intenso. Para um monitoramento completo e detalhado, criamos um dashboard no Grafana que permite observar bloqueios de IP, ataques e decisões de segurança em tempo real.\nEste dashboard inclui:\nBlock Total for Pods: Número de tentativas bloqueadas por pod, ajudando a identificar quais estão mais atacados. Attacks by Scenarios: Distribuição de ataques por cenários de detecção do CrowdSec, mostrando os tipos de ameaça mais frequentes. Total Ban by IP: Lista de IPs bloqueados, o cenário e o total de ocorrências, permitindo acompanhar fontes maliciosas. Decisions Log: Logs detalhados de decisões com timestamps e dados das requisições, garantindo total transparência das ações do CrowdSec. Acesse o dashboard: Monitoramento CrowdSec no Grafana\nEste recurso é essencial para equipes de segurança que precisam monitorar, analisar e responder rapidamente a ameaças na infraestrutura.\nConclusão # Com essas configurações, o CrowdSec está integrado ao seu cluster Kubernetes, monitorando logs, registrando instâncias e protegendo suas aplicações com Traefik, Nginx e WAF AppSec.\nAcesse o console: https://app.crowdsec.net/security-engines\n","date":"26 agosto 2025","externalUrl":null,"permalink":"/blog/pt/blog/crowdsec/crowdsec-o-que-e/","section":"Blog","summary":"","title":"CrowdSec - O que é um WAF e como configurar no Kubernetes","type":"blog"},{"content":" O que é um WAF? # O termo WAF vem de Web Application Firewall – ou firewall de aplicação web.\nUm firewall tradicional atua principalmente na camada de rede, filtrando pacotes com base em informações como IP de origem, IP de destino, porta de origem, porta de destino e protocolo (TCP/UDP/ICMP). Ou seja, ele garante que apenas conexões autorizadas cheguem ao servidor, mas não entende o conteúdo do tráfego.\nJá o WAF vai além: ele é projetado especificamente para proteger aplicações web. Em vez de analisar só endereços e portas, o WAF inspeciona o conteúdo das requisições HTTP/HTTPS. Isso permite identificar e bloquear acessos maliciosos que passam despercebidos por um firewall comum.\nExemplos de ameaças que o WAF ajuda a mitigar # SQL Injection – quando comandos SQL maliciosos são enviados para manipular bancos de dados. Cross-Site Scripting (XSS) – injeção de scripts que podem roubar dados de usuários. Bots maliciosos – que tentam explorar falhas ou sobrecarregar a aplicação. Brute force – tentativas automáticas de adivinhar senhas e logins. Resumindo # Firewall tradicional = foca em rede → controla quem pode se conectar (baseado em IP, portas e protocolos). WAF = foca em aplicação web → analisa o que está dentro da requisição e protege contra ataques direcionados ao funcionamento do site. Em outras palavras, o WAF funciona como um escudo entre a internet e sua aplicação web, bloqueando ameaças antes que causem impacto.\nO que é o CrowdSec? # O CrowdSec é o WAF que usamos aqui na Gole.\nEle é uma solução open-source, colaborativa e moderna, que além de proteger sua aplicação em tempo real, também aprende com ataques sofridos em outros lugares do mundo.\nOu seja: quando um IP malicioso é detectado em um ambiente, toda a comunidade CrowdSec pode se beneficiar e bloquear esse mesmo IP.\nComo o CrowdSec funciona? # O funcionamento é simples de entender:\nMonitora os logs de serviços como Nginx, Traefik, SSH, aplicações web. Detecta comportamentos suspeitos (força bruta, scans, abusos). Bloqueia automaticamente os IPs maliciosos. Compartilha de forma anônima essas informações, fortalecendo a rede de proteção. CrowdSec\nPrincipais Funcionalidades # Monitoramento em tempo real: captura logs de serviços como Nginx, Traefik, SSH, entre outros. Detecção de ataques e abusos: identifica brute force, scans e comportamentos anômalos. Bloqueio automático de IPs: aplica sanções locais ou remotas, protegendo suas aplicações. Passo a Passo: Configurando o CrowdSec no Kubernetes # 1. Adicionar o repositório Helm e obter valores padrão # helm repo add crowdsec https://crowdsecurity.github.io/helm-charts helm repo update helm show values crowdsec/crowdsec \u0026gt; crowdsec-default-values.yaml 2. Editar o arquivo crowdsec-default-values.yaml # a) Configurar aquisição de logs (Traefik) # agent: acquisition: - namespace: traefik podName: traefik-* program: traefik b) Registro da instância (LAPI) # lapi: env: - name: ENROLL_KEY value: \u0026#34;SEU_ENROLL_KEY\u0026#34; - name: ENROLL_INSTANCE_NAME value: \u0026#34;meu-cluster-k8s\u0026#34; - name: ENROLL_TAGS value: \u0026#34;k8s linux producao\u0026#34; c) Volumes persistentes # persistentVolume: data: enabled: true storageClassName: \u0026#34;you-storage-class-name\u0026#34; size: 1Gi config: enabled: true storageClassName: \u0026#34;you-storage-class-name\u0026#34; size: 100Mi 3. Criar namespace # kubectl create ns crowdsec 4. Instalar o CrowdSec # helm install crowdsec crowdsec/crowdsec -n crowdsec -f crowdsec-default-values.yaml 5. Configurar bouncers (Traefik e Nginx) # a) Criar API Key # kubectl -n crowdsec exec -it crowdsec-lapi-* -- sh cscli bouncers add traefik b) Configurar middleware no Traefik # apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: bouncer namespace: traefik spec: plugin: bouncer: CrowdsecLapiKey: \u0026lt;SUA_API_KEY\u0026gt; crowdsecLapiHost: \u0026#34;crowdsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecLapiPort: \u0026#34;8080\u0026#34; crowdsecAppsecHost: \u0026#34;crowdsec-appsec-service.crowdsec.svc.cluster.local\u0026#34; crowdsecAppsecPort: \u0026#34;7422\u0026#34; crowdsecAppsecScheme: http Enabled: true logLevel: DEBUG crowdsecMode: appsec c) Configurar bouncer no Nginx # controller: extraInitContainers: - name: init-clone-crowdsec-bouncer image: crowdsecurity/lua-bouncer-plugin env: - name: API_URL value: \u0026#34;http://crowdsec-service.crowdsec.svc.cluster.local:8080\u0026#34; - name: API_KEY value: \u0026#34;\u0026lt;API KEY\u0026gt;\u0026#34; - name: BOUNCER_CONFIG value: \u0026#34;/crowdsec/crowdsec-bouncer.conf\u0026#34; 6. Ativar o AppSec (WAF) # appsec: enabled: true acquisitions: - source: appsec listen_addr: \u0026#34;0.0.0.0:7422\u0026#34; path: / appsec_config: crowdsecurity/crs-vpatch labels: type: appsec env: - name: COLLECTIONS value: \u0026#34;crowdsecurity/appsec-wordpress\u0026#34; Monitoramento Avançado com Grafana # O console do CrowdSec possui um limite de 500 alertas, o que pode restringir a visualização de eventos em ambientes com tráfego intenso. Para um monitoramento completo e detalhado, criamos um dashboard no Grafana que permite observar bloqueios de IP, ataques e decisões de segurança em tempo real.\nEste dashboard inclui:\nBlock Total for Pods: Número de tentativas bloqueadas por pod, ajudando a identificar quais estão mais atacados. Attacks by Scenarios: Distribuição de ataques por cenários de detecção do CrowdSec, mostrando os tipos de ameaça mais frequentes. Total Ban by IP: Lista de IPs bloqueados, o cenário e o total de ocorrências, permitindo acompanhar fontes maliciosas. Decisions Log: Logs detalhados de decisões com timestamps e dados das requisições, garantindo total transparência das ações do CrowdSec. Acesse o dashboard: Monitoramento CrowdSec no Grafana\nEste recurso é essencial para equipes de segurança que precisam monitorar, analisar e responder rapidamente a ameaças na infraestrutura.\nConclusão # Com essas configurações, o CrowdSec está integrado ao seu cluster Kubernetes, monitorando logs, registrando instâncias e protegendo suas aplicações com Traefik, Nginx e WAF AppSec.\nAcesse o console: https://app.crowdsec.net/security-engines\n","date":"26 agosto 2025","externalUrl":null,"permalink":"/blog/pt/posts/crowdsec/crowdsec-o-que-e/","section":"Posts","summary":"","title":"CrowdSec - O que é um WAF e como configurar no Kubernetes","type":"posts"},{"content":"","date":"26 agosto 2025","externalUrl":null,"permalink":"/blog/pt/categories/seguran%C3%A7a/","section":"Categories","summary":"","title":"Segurança","type":"categories"},{"content":"","date":"26 agosto 2025","externalUrl":null,"permalink":"/blog/pt/tags/seguran%C3%A7a/","section":"Tags","summary":"","title":"Segurança","type":"tags"},{"content":"Nosso API Gateway é a porta de entrada segura e inteligente para suas aplicações. Ele organiza, autentica, controla e monitora o tráfego entre sistemas, garantindo performance, segurança e confiabilidade. Contamos com rate limiting, circuit breaker, logs centralizados, auditoria, autenticação e políticas por rota. Sua empresa ganha controle total sobre a comunicação entre serviços, com governança centralizada e alto desempenho.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/gole-as-a-service/api-gateway/","section":"Gole as a Services ","summary":"","title":"Api Gateways","type":"gole-as-a-service"},{"content":"Nuestra API Gateway es el punto de entrada seguro e inteligente para sus aplicaciones. Organiza, autentica, controla y monitoriza el tráfico entre sistemas, garantizando el rendimiento, la seguridad y la fiabilidad. Ofrecemos limitación de velocidad, disyuntor, registros centralizados, auditoría, autenticación y políticas basadas en rutas.\nSu empresa obtiene control total sobre la comunicación entre servicios, con gobernanza centralizada y alto rendimiento.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/gole-como-servicio/api-gateway/","section":"Gole como servicio","summary":"","title":"Api Gateways","type":"gole-como-servicio"},{"content":"We design resilient, scalable, and secure architectures aligned with business needs and application lifecycle. We work with microservices, APIs, containers, and hybrid environments, ensuring standardization and governance. Our team supports you from conception to operation, backing strategic decisions and reducing technical complexity.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/arquitetura-de-solucoes/","section":"Consulting","summary":"","title":"Arquitetura de Soluções","type":"consulting"},{"content":"Diseñamos arquitecturas resilientes, escalables y seguras, alineadas con las necesidades del negocio y el ciclo de vida de las aplicaciones. Trabajamos con microservicios, APIs, contenedores y entornos híbridos, garantizando estandarización y gobernanza. Nuestro equipo acompaña desde la concepción hasta la operación, apoyando decisiones estratégicas y reduciendo complejidad técnica.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/arquitectura-de-soluciones/","section":"Consultoría","summary":"","title":"Arquitetura de Soluções","type":"consultoria"},{"content":"Desenhamos arquiteturas resilientes, escaláveis e seguras, alinhadas às necessidades do negócio e ao ciclo de vida das aplicações. Trabalhamos com microsserviços, APIs, containers e ambientes híbridos, garantindo padronização e governança. Nossa equipe acompanha desde a concepção até a operação, apoiando decisões estratégicas e reduzindo complexidade técnica.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/consultoria/arquitetura-de-solucoes/","section":"Consultoria","summary":"","title":"Arquitetura de Soluções","type":"consultoria"},{"content":"Usamos nossa infraestrutura para armazenar e proteger o backup completo da sua empresa, incluindo aplicações, bancos de dados e sistemas internos. Aplicamos políticas de retenção, versionamento e criptografia ponta-a-ponta para garantir integridade e segurança de dados. O backup é totalmente automatizado, com restauração rápida e suporte 24x7, reduzindo o impacto de incidentes e garantindo continuidade operacional. Sua empresa pode evoluir com segurança mesmo em momentos críticos.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/gole-as-a-service/backup/","section":"Gole as a Services ","summary":"","title":"Backup","type":"gole-as-a-service"},{"content":"Utilizamos nuestra infraestructura para almacenar y proteger las copias de seguridad completas de su empresa, incluyendo aplicaciones, bases de datos y sistemas internos. Aplicamos políticas de retención, control de versiones y cifrado de extremo a extremo para garantizar la integridad y seguridad de los datos.\nLas copias de seguridad están totalmente automatizadas, con restauración rápida y soporte 24/7, lo que reduce el impacto de los incidentes y garantiza la continuidad operativa. Su empresa puede evolucionar con seguridad incluso en momentos críticos.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/gole-como-servicio/backup/","section":"Gole como servicio","summary":"","title":"Backup","type":"gole-como-servicio"},{"content":"Disponibilizamos, hospedamos e mantemos qualquer tipo de banco de dados para sua empresa, seja SQL ou NoSQL. Nossos clusters garantem baixa latência, alta performance e segurança com criptografia de dados. Realizamos tuning avançado, ajustes de queries, replicação e rotinas de backup para garantir consistência e performance das suas aplicações. Nossos tempos de resposta são baixos e estáveis, eliminando gargalos e garantindo experiência fluida para seus usuários. Sua empresa recebe um ambiente de banco otimizado, monitorado e pronto para escalar.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/gole-as-a-service/base-de-dados/","section":"Gole as a Services ","summary":"","title":"Base de dados","type":"gole-as-a-service"},{"content":"Proporcionamos, alojamos y mantenemos cualquier tipo de base de datos para su empresa, ya sea SQL o NoSQL. Nuestros clústeres garantizan baja latencia, alto rendimiento y seguridad con cifrado de datos. Realizamos ajustes avanzados de tuning, consultas, replicación y copias de seguridad para garantizar la consistencia y el rendimiento de sus aplicaciones. Nuestros tiempos de respuesta son bajos y estables, eliminando cuellos de botella y garantizando una experiencia fluida para sus usuarios. Su empresa recibe un entorno de base de datos optimizado, monitorizado y escalable.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/gole-como-servicio/base-de-dados/","section":"Gole como servicio","summary":"","title":"Base de dados","type":"gole-como-servicio"},{"content":"Creamos soluciones escalables, fáciles de integrar y enfocadas en el rendimiento. Trabajamos con arquitectura limpia, pruebas automatizadas y canalizaciones completas, permitiendo entregas rápidas con calidad. Diseñamos APIs y servicios listos para entornos distribuidos, con autenticación, seguridad y monitoreo integrado.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/desarrollo/","section":"Consultoría","summary":"","title":"Desarrollo","type":"consultoria"},{"content":"Criamos soluções escaláveis, fáceis de integrar e com foco em performance. Trabalhamos com arquitetura limpa, testes automatizados e pipelines completos, permitindo entregas rápidas com qualidade. Projetamos APIs e serviços prontos para ambientes distribuídos, com autenticação, segurança e monitoramento integrado.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/consultoria/desenvolvimento/","section":"Consultoria","summary":"","title":"Desenvolvimento","type":"consultoria"},{"content":"We create scalable, easy-to-integrate solutions with a focus on performance. We work with clean architecture, automated testing, and complete pipelines, enabling fast deliveries with quality. We design APIs and services ready for distributed environments, with integrated authentication, security, and monitoring.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/desenvolvimento/","section":"Consulting","summary":"","title":"Development","type":"consulting"},{"content":"We build automated pipelines for hybrid and multicloud networks, with auditable policies, governance, and standardization. Network infrastructure gains speed, consistency, and predictability, reducing human errors and strengthening security. The enterprise operates networks as software.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/devnetops/","section":"Consulting","summary":"","title":"DevNetOps","type":"consulting"},{"content":"Construimos pipelines automatizados para redes híbridas y multicloud, con políticas auditables, gobernanza y estandarización. La infraestructura de red gana velocidad, consistencia y previsibilidad, reduciendo errores humanos y fortaleciendo la seguridad. La empresa opera las redes como software.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/devnetops/","section":"Consultoría","summary":"","title":"DevNetOps","type":"consultoria"},{"content":"We unite teams, automation, and agile methodologies to accelerate releases with less risk. We implement pipelines, continuous testing, observability, and rapid feedback, enabling short cycles and constant improvement. DevOps reduces rework, increases efficiency, and strengthens a culture of collaboration.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/devops/","section":"Consulting","summary":"","title":"DevOps","type":"consulting"},{"content":"Unimos equipos, automatización y metodologías ágiles para acelerar releases con menor riesgo. Implementamos pipelines, pruebas continuas, observabilidad y retroalimentación rápida, permitiendo ciclos cortos y mejora constante. DevOps reduce retrabajo, aumenta eficiencia y fortalece la cultura de colaboración.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/devops/","section":"Consultoría","summary":"","title":"DevOps","type":"consultoria"},{"content":"We integrate security from the start of development, with code analysis, dependency validation, vulnerability scanning, and automated policies. This reduces risk, accelerates audits, and creates a secure environment without compromising delivery speed. Security becomes a natural part of the process.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/devsecops/","section":"Consulting","summary":"","title":"DevSecOps","type":"consulting"},{"content":"Integramos seguridad desde el inicio del desarrollo, con análisis de código, validación de dependencias, escaneo de vulnerabilidades y políticas automatizadas. Esto reduce riesgos, acelera auditorías y crea un entorno seguro sin comprometer la velocidad de entrega. La seguridad se convierte en parte natural del proceso.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/devsecops/","section":"Consultoría","summary":"","title":"DevSecOps","type":"consultoria"},{"content":"Utilize nossa infraestrutura para criar o Plano de Recuperação de Desastre da sua empresa. Estruturamos procedimentos de resposta, replicação de dados, failover e rollback seguros, garantindo retomada rápida após incidentes. Planejamos cenários de desastre real, testamos o processo e documentamos cada etapa, assegurando que o ambiente esteja sempre preparado — reduzindo impacto financeiro e operacional.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/gole-as-a-service/drp/","section":"Gole as a Services ","summary":"","title":"DRP","type":"gole-as-a-service"},{"content":"Utilice nuestra infraestructura para crear el Plan de Recuperación ante Desastres de su empresa. Estructuramos procedimientos seguros de respuesta, replicación de datos, conmutación por error y reversión, garantizando una rápida recuperación tras incidentes.\nPlanificamos escenarios de desastre reales, probamos el proceso y documentamos cada paso, garantizando que el entorno esté siempre preparado, reduciendo así el impacto financiero y operativo.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/gole-como-servicio/drp/","section":"Gole como servicio","summary":"","title":"DRP","type":"gole-como-servicio"},{"content":"We apply clear consumption metrics, optimization policies, and financial planning to accelerate results with smart investment. We integrate FinOps into the delivery cycle, avoiding waste and ensuring cost predictability. Your company gains autonomy to scale with financial security.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/finops/","section":"Consulting","summary":"","title":"FinOps","type":"consulting"},{"content":"Aplicamos métricas claras de consumo, políticas de optimización y planificación financiera para acelerar resultados con inversión inteligente. Integramos FinOps en el ciclo de entrega, evitando desperdicios y garantizando previsibilidad de costos. La empresa gana autonomía para escalar con seguridad financiera.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/finops/","section":"Consultoría","summary":"","title":"FinOps","type":"consultoria"},{"content":"Sus contenedores pueden ejecutarse en nuestros clústeres de Kubernetes, con una infraestructura escalable y lista para usar, integrada con sus repositorios de código. Ofrecemos una infraestructura moderna con escalado automático, malla de servicios, implementación automatizada y monitorización nativa. El entorno es ideal para pipelines de CI/CD, microservicios y aplicaciones distribuidas. Su empresa ahorra tiempo, reduce costes y agiliza la entrega al ejecutar contenedores con nosotros.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/gole-como-servicio/kubernetes/","section":"Gole como servicio","summary":"","title":"kubernetes","type":"gole-como-servicio"},{"content":"Seus containers podem rodar em nossos clusters Kubernetes, com infra pronta, escalável e integrada aos seus repositórios de código. Entregamos infraestrutura moderna com autoscaling, service mesh, deploy automatizado e monitoramento nativo. O ambiente é ideal para pipelines de CI/CD, microserviços e aplicações distribuídas. Sua empresa economiza tempo, reduz custos e ganha velocidade de entrega rodando containers conosco.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/gole-as-a-service/kubernetes/","section":"Gole as a Services ","summary":"","title":"Kubernetes","type":"gole-as-a-service"},{"content":"Planificamos y ejecutamos migraciones completas de aplicaciones, datos e infraestructura mediante metodologías probadas. Trabajamos con enfoques de lift \u0026amp; shift, modernización y reestructuración de plataformas, garantizando la integridad, el rendimiento y la seguridad durante todo el proceso. Nos centramos en reducir el riesgo, evitar la repetición de tareas y acelerar la generación de valor con la nube.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/migraciones/","section":"Consultoría","summary":"","title":"Migrações","type":"consultoria"},{"content":"Planejamos e executamos migrações completas de aplicações, dados e infraestrutura com metodologia comprovada. Trabalhamos com abordagens lift \u0026amp; shift, modernização e replatforming, garantindo integridade, desempenho e segurança em todo o processo. Nosso foco é reduzir risco, evitar retrabalho e acelerar o ganho de valor com cloud.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/consultoria/migracoes/","section":"Consultoria","summary":"","title":"Migrações","type":"consultoria"},{"content":"We plan and execute complete migrations of applications, data, and infrastructure using proven methodology. We work with lift \u0026amp; shift approaches, modernization, and replatforming, ensuring integrity, performance, and security throughout the process. Our focus is to reduce risk, avoid rework, and accelerate value realization with cloud.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/migracoes/","section":"Consulting","summary":"","title":"Migrations","type":"consulting"},{"content":"Entregamos soluções completas de monitoramento, observabilidade e inteligência operacional para sua empresa. Monitoramos equipamentos físicos, ambientes virtuais, serviços de rede e aplicações distribuídas. Também executamos simulações reais de usuário para identificar falhas antes que impactem o negócio. É o monitoramento ideal para operações 24x7 que dependem de múltiplos módulos e integrações críticas. Inclui alertas inteligentes, relatórios de SLA e SLO, dashboards modernos e acompanhamento contínuo com nossa equipe técnica. Assim, você tem visibilidade total do ambiente e segurança para crescer com eficiência.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/gole-as-a-service/monitoramento-e-inteligencia-operacional/","section":"Gole as a Services ","summary":"","title":"Monitoramento e inteligência operacional","type":"gole-as-a-service"},{"content":"Ofrecemos soluciones completas de monitoreo, observabilidad e inteligencia operativa para su empresa. Monitoreamos equipos físicos, entornos virtuales, servicios de red y aplicaciones distribuidas. También realizamos simulaciones de usuarios reales para identificar fallas antes de que afecten al negocio. Es la solución de monitoreo ideal para operaciones 24/7 que dependen de múltiples módulos e integraciones críticas.\nIncluye alertas inteligentes, informes de SLA y SLO, paneles de control modernos y soporte continuo de nuestro equipo técnico. Esto le brinda visibilidad completa de su entorno y la seguridad para crecer eficientemente.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/gole-como-servicio/monitoreo-e-inteligencia-operacional/","section":"Gole como servicio","summary":"","title":"Monitoramento e inteligência operacional","type":"gole-como-servicio"},{"content":"Os projetos open source transformaram a tecnologia moderna. Existe uma variedade enorme de ferramentas, linguagens e metodologias maduras e confiáveis — e a Gole domina e acredita profundamente nesse ecossistema. Temos prazer em selecionar, implementar e manter soluções open source que trazem inovação, segurança e eficiência para a sua empresa.\n","date":"18 enero 2025","externalUrl":null,"permalink":"/blog/pt/gole-as-a-service/programa-open-source/","section":"Gole as a Services ","summary":"","title":"Programas Open Source","type":"gole-as-a-service"},{"content":"Los proyectos de código abierto han transformado la tecnología moderna. Existe una gran variedad de herramientas, lenguajes y metodologías consolidadas y fiables, y Gole comprende y cree firmemente en este ecosistema.\nNos complace seleccionar, implementar y mantener soluciones de código abierto que aportan innovación, seguridad y eficiencia a su empresa.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/gole-como-servicio/programas-open-source/","section":"Gole como servicio","summary":"","title":"Programas Open Source","type":"gole-como-servicio"},{"content":"We apply Reliability Engineering practices with a focus on SLIs, SLOs, SLAs, and incident management. We automate repetitive tasks, identify failure points, and drive structural improvements. The result is a predictable, resilient environment with superior experience for end users.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/sre/","section":"Consulting","summary":"","title":"SRE","type":"consulting"},{"content":"Aplicamos prácticas de Ingeniería de Confiabilidad, centrándonos en los SLI, los SLO, los SLA y la gestión de incidentes. Automatizamos tareas repetitivas, identificamos puntos de fallo y promovemos mejoras estructurales. El resultado es un entorno predecible y resiliente con una experiencia de usuario final superior.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/sre/","section":"Consultoría","summary":"","title":"SRE","type":"consultoria"},{"content":"We monitor critical resources, apply patches, optimize performance, and manage incidents with defined SLA and SLO. Our operations are guided by best practices, automation, and clear documentation, reducing risks and increasing predictability. You have a team ready to support growth with security.\n","date":"enero 18, 2025","externalUrl":null,"permalink":"/blog/en/consulting/sysadmin/","section":"Consulting","summary":"","title":"Sysadmin","type":"consulting"},{"content":"Monitoreamos recursos críticos, aplicamos parches, optimizamos el rendimiento y gestionamos incidentes con SLA y SLO definidos. Nuestras operaciones se rigen por las mejores prácticas, la automatización y una documentación clara, lo que reduce los riesgos y aumenta la previsibilidad. Puede contar con un equipo preparado para impulsar su crecimiento de forma segura.\n","date":"18 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/sysadmin/","section":"Consultoría","summary":"","title":"Sysadmin","type":"consultoria"},{"content":"We implement optimized Kubernetes clusters with CI/CD, observability, and native automation. We build environments ready for microservices, horizontal scalability, and high availability. Our experience reduces operational costs and accelerates continuous delivery, enabling your team to focus on the product.\n","date":"enero 11, 2025","externalUrl":null,"permalink":"/blog/en/consulting/kubernetes/","section":"Consulting","summary":"","title":"Kubernetes","type":"consulting"},{"content":"Implementamos clusters Kubernetes optimizados, con CI/CD, observabilidad y automatización nativa. Construimos entornos listos para microservicios, escalabilidad horizontal y alta disponibilidad. Nuestra experiencia reduce costos operacionales y acelera la entrega continua, permitiendo que tu equipo se concentre en el producto.\n","date":"11 de enero de 2025","externalUrl":null,"permalink":"/blog/es/consultoria/kubernetes/","section":"Consultoría","summary":"","title":"Kubernetes","type":"consultoria"},{"content":"","date":"3 de enero de 2023","externalUrl":null,"permalink":"/blog/es/tags/certificado/","section":"Tags","summary":"","title":"Certificado","type":"tags"},{"content":" Cómo extraer el certificado y la clave de un archivo PFX # Primero, utilizamos el siguiente comando para extraer únicamente la key del archivo .pfx:\nopenssl pkcs12 -in [yourfile.pfx] -nocerts -out [drlive.key] Después de ejecutar el comando, se solicitará la password utilizada para generar el archivo .pfx, será necesario ingresarla tres veces.\nUna vez que hayamos extraído la clave (.key) y la hayamos guardado en un archivo, procederemos a extraer el certificado (.crt) del mismo archivo .pfx, usando el siguiente comando:\nopenssl rsa -in [drlive.key] -out [drlive-decrypted.key] Al igual que en los pasos anteriores, se solicitará la password.\nCon esto, tendremos los siguientes archivos: archivo.key, archivo.crt y archivo-decrypted.key.\nCómo crear un archivo PFX a partir de un certificado # Con todos los componentes listos, ahora generaremos el archivo .pfx.\nPrimero, debemos concatenar los archivos .crt en un solo archivo, ya que la creación del .pfx solo acepta un certificado. Utilizaremos el siguiente comando:\ncat \u0026lt;hostname_certificate\u0026gt;.crt \u0026lt;arquivo CA\u0026gt;.crt \u0026lt;arquivo USER\u0026gt;.crt \u0026lt;arquivo AAA\u0026gt;.crt \u0026gt;\u0026gt; arquivo-full.crt Después de concatenar todos los certificados en un solo archivo, procederemos a crear el archivo .pfx.\nPara generarlo, utilizaremos el siguiente comando de OpenSSL abajo:\nopenssl pkcs12 -export -out \u0026lt;name_do_arquivo\u0026gt;.pfx -inkey \u0026lt;arquivo-decrypted\u0026gt;.key -in \u0026lt;arquivo-full\u0026gt;.crt Durante la ejecución del comando, se solicitará una password y luego se pedirá confirmarla. Deberás repetir la misma password.\nReferencia: https://www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file.\n","date":"3 de enero de 2023","externalUrl":null,"permalink":"/blog/es/blog/certificacion-pfx/certificado-pfx/","section":"Blog","summary":"","title":"Certificado PFX","type":"blog"},{"content":" Cómo extraer el certificado y la clave de un archivo PFX # Primero, utilizamos el siguiente comando para extraer únicamente la key del archivo .pfx:\nopenssl pkcs12 -in [yourfile.pfx] -nocerts -out [drlive.key] Después de ejecutar el comando, se solicitará la password utilizada para generar el archivo .pfx, será necesario ingresarla tres veces.\nUna vez que hayamos extraído la clave (.key) y la hayamos guardado en un archivo, procederemos a extraer el certificado (.crt) del mismo archivo .pfx, usando el siguiente comando:\nopenssl rsa -in [drlive.key] -out [drlive-decrypted.key] Al igual que en los pasos anteriores, se solicitará la password.\nCon esto, tendremos los siguientes archivos: archivo.key, archivo.crt y archivo-decrypted.key.\nCómo crear un archivo PFX a partir de un certificado # Con todos los componentes listos, ahora generaremos el archivo .pfx.\nPrimero, debemos concatenar los archivos .crt en un solo archivo, ya que la creación del .pfx solo acepta un certificado. Utilizaremos el siguiente comando:\ncat \u0026lt;hostname_certificate\u0026gt;.crt \u0026lt;arquivo CA\u0026gt;.crt \u0026lt;arquivo USER\u0026gt;.crt \u0026lt;arquivo AAA\u0026gt;.crt \u0026gt;\u0026gt; arquivo-full.crt Después de concatenar todos los certificados en un solo archivo, procederemos a crear el archivo .pfx.\nPara generarlo, utilizaremos el siguiente comando de OpenSSL abajo:\nopenssl pkcs12 -export -out \u0026lt;name_do_arquivo\u0026gt;.pfx -inkey \u0026lt;arquivo-decrypted\u0026gt;.key -in \u0026lt;arquivo-full\u0026gt;.crt Durante la ejecución del comando, se solicitará una password y luego se pedirá confirmarla. Deberás repetir la misma password.\nReferencia: https://www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file.\n","date":"3 de enero de 2023","externalUrl":null,"permalink":"/blog/es/posts/certificacion-pfx/certificado-pfx/","section":"Posts","summary":"","title":"Certificado PFX","type":"posts"},{"content":"","date":"noviembre 3, 2023","externalUrl":null,"permalink":"/blog/en/tags/certificate/","section":"Tags","summary":"","title":"Certificate","type":"tags"},{"content":" Como extrair o certificado # Primeiramente utilizamos o comando abaixo para extrair somente a \u0026ldquo;key\u0026rdquo; do arquivo .pfx\nopenssl pkcs12 -in [yourfile.pfx] -nocerts -out [drlive.key] Após executado o comando será pedido o password utilizado para gerar o arquivo .pfx, será necessário repetir três vezes.\nDepois que extraímos a \u0026ldquo;key\u0026rdquo; e deixamos em um arquivo, vamos agora extrair o cert do arquivo .pfx, usando esse comando:\nopenssl pkcs12 -in [yourfile.pfx] -clcerts -nokeys -out [drlive.crt] Após a execução será pedido novamente o password utilizado na geração do arquivo .pfx\nAgora com o arquivo .key e o .crt em mãos vamos fazer a decriptação do arquivo .key, com o seguinte comando:\nopenssl rsa -in [drlive.key] -out [drlive-decrypted.key] Assim como os passos anteriores e solicitado o password\nCom isso temos: arquivo.key , arquivo.crt e o arquivo-decrypted.key.\nComo criar um arquivo PFX a partir de um Certificado # Com todas as peça em mãos vamos agora gerar um arquivo .pfx\nPrimeiramente vamos concatenar nossos arquivo .crt em um só, pois a criação do .pfx só aceita apenas um arquivo .crt, utilizaremos este comando:\ncat \u0026lt;hostname_certificate\u0026gt;.crt \u0026lt;arquivo CA\u0026gt;.crt \u0026lt;arquivo USER\u0026gt;.crt \u0026lt;arquivo AAA\u0026gt;.crt \u0026gt;\u0026gt; arquivo-full.crt Após concatenarmos todos arquivo em um só vamos a criação do arquivo.pfx\nPara gerarmos esse arquivo vamos usar o comando openssl abaixo:\nopenssl pkcs12 -export -out \u0026lt;name_do_arquivo\u0026gt;.pfx -inkey \u0026lt;arquivo-decrypted\u0026gt;.key -in \u0026lt;arquivo-full\u0026gt;.crt Após a execução do comando será pedido um password e depois pedirá para verificar o password terá que repetir o mesmo password.\nReferencia: https://www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file.\n","date":"3 noviembre 2023","externalUrl":null,"permalink":"/blog/pt/blog/certificacao-pfx/certificacao-pfx/","section":"Blog","summary":"","title":"Como extrair o certificado e a chave de um arquivo PFX","type":"blog"},{"content":" Como extrair o certificado # Primeiramente utilizamos o comando abaixo para extrair somente a \u0026ldquo;key\u0026rdquo; do arquivo .pfx\nopenssl pkcs12 -in [yourfile.pfx] -nocerts -out [drlive.key] Após executado o comando será pedido o password utilizado para gerar o arquivo .pfx, será necessário repetir três vezes.\nDepois que extraímos a \u0026ldquo;key\u0026rdquo; e deixamos em um arquivo, vamos agora extrair o cert do arquivo .pfx, usando esse comando:\nopenssl pkcs12 -in [yourfile.pfx] -clcerts -nokeys -out [drlive.crt] Após a execução será pedido novamente o password utilizado na geração do arquivo .pfx\nAgora com o arquivo .key e o .crt em mãos vamos fazer a decriptação do arquivo .key, com o seguinte comando:\nopenssl rsa -in [drlive.key] -out [drlive-decrypted.key] Assim como os passos anteriores e solicitado o password\nCom isso temos: arquivo.key , arquivo.crt e o arquivo-decrypted.key.\nComo criar um arquivo PFX a partir de um Certificado # Com todas as peça em mãos vamos agora gerar um arquivo .pfx\nPrimeiramente vamos concatenar nossos arquivo .crt em um só, pois a criação do .pfx só aceita apenas um arquivo .crt, utilizaremos este comando:\ncat \u0026lt;hostname_certificate\u0026gt;.crt \u0026lt;arquivo CA\u0026gt;.crt \u0026lt;arquivo USER\u0026gt;.crt \u0026lt;arquivo AAA\u0026gt;.crt \u0026gt;\u0026gt; arquivo-full.crt Após concatenarmos todos arquivo em um só vamos a criação do arquivo.pfx\nPara gerarmos esse arquivo vamos usar o comando openssl abaixo:\nopenssl pkcs12 -export -out \u0026lt;name_do_arquivo\u0026gt;.pfx -inkey \u0026lt;arquivo-decrypted\u0026gt;.key -in \u0026lt;arquivo-full\u0026gt;.crt Após a execução do comando será pedido um password e depois pedirá para verificar o password terá que repetir o mesmo password.\nReferencia: https://www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file.\n","date":"3 noviembre 2023","externalUrl":null,"permalink":"/blog/pt/posts/certificacao-pfx/certificacao-pfx/","section":"Posts","summary":"","title":"Como extrair o certificado e a chave de um arquivo PFX","type":"posts"},{"content":"","date":"3 de enero de 2023","externalUrl":null,"permalink":"/blog/es/authors/ian/","section":"Authors","summary":"","title":"Ian","type":"authors"},{"content":"","date":"3 de enero de 2023","externalUrl":null,"permalink":"/blog/es/authors/ian-dias/","section":"Authors","summary":"","title":"Ian-Dias","type":"authors"},{"content":"","date":"3 de enero de 2023","externalUrl":null,"permalink":"/blog/es/tags/openssl/","section":"Tags","summary":"","title":"OpenSSL","type":"tags"},{"content":"","date":"3 noviembre 2023","externalUrl":null,"permalink":"/blog/pt/tags/opnssl/","section":"Tags","summary":"","title":"OPNSSL","type":"tags"},{"content":"","date":"3 de enero de 2023","externalUrl":null,"permalink":"/blog/es/tags/pfx/","section":"Tags","summary":"","title":"PFX","type":"tags"},{"content":"","date":"3 noviembre 2023","externalUrl":null,"permalink":"/blog/pt/categories/sys-admin/","section":"Categories","summary":"","title":"Sys Admin","type":"categories"},{"content":"","date":"3 de enero de 2023","externalUrl":null,"permalink":"/blog/es/categories/sysadmin/","section":"Categories","summary":"","title":"Sysadmin","type":"categories"},{"content":"","date":"29 de enero de 2022","externalUrl":null,"permalink":"/blog/es/tags/bitbucket/","section":"Tags","summary":"","title":"Bitbucket","type":"tags"},{"content":" Executando bitbucket runners auto-hospedados em Kubernetes # Os runners permitem que você execute pipelines a partir de seus repositórios. O bitbucket permite que hospede esses runners em sua própria infraestrutura, os chamados self-hosted runners.\nNesse artigo vamos ver o passo a passo de como criar um runner auto-hospedado em nível de workspace e executá-lo em Kubernetes.\nCriando um runner no bitbucket # O primeiro passo é a criação de um novo runner. Vamos criá-lo em nível de workspace:\nNavegue até seu perfil e clique no workspace que deseja.\nClique em configurações e selecione workspace runners.\nAdicionar runner.\nDefina o nome para o runner e uma label. As labels self.hosted e linux são padrões, precisamos adicionar uma nova label para podermos identificar no pipeline em qual runner o build deve ser executado, caso existam outros runners criados.\nClique em next. Será gerada uma saída com o seguinte comando docker:\ndocker container run -it -v /tmp:/tmp -v /var/run/docker.sock:/var/run/docker.sock \\ -v /var/lib/docker/containers:/var/lib/docker/containers:ro \\ -e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ --name runner-87c1a9ae-c216-5512-a92d-12fb95f77f0b \\ docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1 Copie esse comando, pois vamos utilizar os valores das variáveis apresentadas para a configuração do nosso runner auto-hospedado e clique em finish.\nObserve que o runner foi criado no workspace, mas seu status está como UNREGISTRED. Após configurarmos o runner e executá-lo no ambiente Kubernetes seu status irá mudar para ONLINE.\nConfiguração Kubernetes # O próximo passo é a construção dos arquivos kubernetes para hospedarmos o runner.\nPrimeiro vamos tratar as variáveis dadas pelo comando:\n-e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ Copie o valor das variáveis ACCOUNT_UUID e RUNNER_UUID sem as { }.\nAs variáveis OAUTH_CLIENT_ID e OAUTH_CLIENT_SECRET devem ser transformadas em base64.\necho -n OAUTH_CLIENT_ID | base64 echo -n OAUTH_CLIENT_SECRET | base64 Feito isso passamos para a etapa de construção dos arquivos Kubernetes:\nsecret.yaml\njob.yaml\nAdicione os valores das variáveis:\nsecret.yaml # apiVersion: v1 kind: Secret metadata: name: runner-01-oauth-credentials labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} data: oauthClientId: {OAUTH_CLIENT_ID} oauthClientSecret: {OAUTH_CLIENT_SECRET} job.yaml # Importante: No arquivo job.yaml as variáveis de accountUuid e runnerUuid, na seção de \u0026lsquo;container variables\u0026rsquo;, devem ser adicionadas entre “ ” e { }, dessa forma “{ACCOUNT_UUID}”\napiVersion: batch/v1 kind: Job metadata: name: runner-01 spec: template: metadata: labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} spec: containers: - name: bitbucket-runner-01 image: docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner env: - name: ACCOUNT_UUID value: “{${ACCOUNT_UUID}}” - name: RUNNER_UUID value: “{${RUNNER_UUID}}” - name: RUNTIME_PREREQUISITES_ENABLED value: true - name: WORKING_DIRECTORY value: \u0026#34;/tmp\u0026#34; - name: OAUTH_CLIENT_ID valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientId - name: OAUTH_CLIENT_SECRET valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientSecret volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers readOnly: true - name: var-run mountPath: /var/run - name: docker-in-docker image: docker:20.10.7-dind securityContext: privileged: true volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers - name: var-run mountPath: /var/run restartPolicy: OnFailure volumes: - name: tmp - name: docker-containers - name: var-run backoffLimit: 6 completions: 1 parallelism: 1 Agora vamos aplicar as configurações construídas acima.\nkubectl -n namespace apply -f secrets.yaml kubectl -n namespace apply -f job.yaml Testando o novo runner # pipelines: branches: \u0026#39;main\u0026#39;: - step: runs-on: my.custom.label script: - echo \u0026#34;Hello world\u0026#34; Seu runner auto-hospedado está pronto!\nPara mais informações sobre runners visite a documentação bitbucket runners.\nPrecisa de ajuda? # Acesse nossa página de Contato e converse conosco.\nSucesso!\nLeitura complementar: # Pipelines runners frequently asked questions\n","date":"29 julio 2022","externalUrl":null,"permalink":"/blog/pt/blog/corredor-bitbukect/corredor-bitbukect/","section":"Blog","summary":"","title":"Bitbucket 'self-hosted' runner em ambiente Kubernetes","type":"blog"},{"content":" Executando bitbucket runners auto-hospedados em Kubernetes # Os runners permitem que você execute pipelines a partir de seus repositórios. O bitbucket permite que hospede esses runners em sua própria infraestrutura, os chamados self-hosted runners.\nNesse artigo vamos ver o passo a passo de como criar um runner auto-hospedado em nível de workspace e executá-lo em Kubernetes.\nCriando um runner no bitbucket # O primeiro passo é a criação de um novo runner. Vamos criá-lo em nível de workspace:\nNavegue até seu perfil e clique no workspace que deseja.\nClique em configurações e selecione workspace runners.\nAdicionar runner.\nDefina o nome para o runner e uma label. As labels self.hosted e linux são padrões, precisamos adicionar uma nova label para podermos identificar no pipeline em qual runner o build deve ser executado, caso existam outros runners criados.\nClique em next. Será gerada uma saída com o seguinte comando docker:\ndocker container run -it -v /tmp:/tmp -v /var/run/docker.sock:/var/run/docker.sock \\ -v /var/lib/docker/containers:/var/lib/docker/containers:ro \\ -e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ --name runner-87c1a9ae-c216-5512-a92d-12fb95f77f0b \\ docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1 Copie esse comando, pois vamos utilizar os valores das variáveis apresentadas para a configuração do nosso runner auto-hospedado e clique em finish.\nObserve que o runner foi criado no workspace, mas seu status está como UNREGISTRED. Após configurarmos o runner e executá-lo no ambiente Kubernetes seu status irá mudar para ONLINE.\nConfiguração Kubernetes # O próximo passo é a construção dos arquivos kubernetes para hospedarmos o runner.\nPrimeiro vamos tratar as variáveis dadas pelo comando:\n-e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ Copie o valor das variáveis ACCOUNT_UUID e RUNNER_UUID sem as { }.\nAs variáveis OAUTH_CLIENT_ID e OAUTH_CLIENT_SECRET devem ser transformadas em base64.\necho -n OAUTH_CLIENT_ID | base64 echo -n OAUTH_CLIENT_SECRET | base64 Feito isso passamos para a etapa de construção dos arquivos Kubernetes:\nsecret.yaml\njob.yaml\nAdicione os valores das variáveis:\nsecret.yaml # apiVersion: v1 kind: Secret metadata: name: runner-01-oauth-credentials labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} data: oauthClientId: {OAUTH_CLIENT_ID} oauthClientSecret: {OAUTH_CLIENT_SECRET} job.yaml # Importante: No arquivo job.yaml as variáveis de accountUuid e runnerUuid, na seção de \u0026lsquo;container variables\u0026rsquo;, devem ser adicionadas entre “ ” e { }, dessa forma “{ACCOUNT_UUID}”\napiVersion: batch/v1 kind: Job metadata: name: runner-01 spec: template: metadata: labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} spec: containers: - name: bitbucket-runner-01 image: docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner env: - name: ACCOUNT_UUID value: “{${ACCOUNT_UUID}}” - name: RUNNER_UUID value: “{${RUNNER_UUID}}” - name: RUNTIME_PREREQUISITES_ENABLED value: true - name: WORKING_DIRECTORY value: \u0026#34;/tmp\u0026#34; - name: OAUTH_CLIENT_ID valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientId - name: OAUTH_CLIENT_SECRET valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientSecret volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers readOnly: true - name: var-run mountPath: /var/run - name: docker-in-docker image: docker:20.10.7-dind securityContext: privileged: true volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers - name: var-run mountPath: /var/run restartPolicy: OnFailure volumes: - name: tmp - name: docker-containers - name: var-run backoffLimit: 6 completions: 1 parallelism: 1 Agora vamos aplicar as configurações construídas acima.\nkubectl -n namespace apply -f secrets.yaml kubectl -n namespace apply -f job.yaml Testando o novo runner # pipelines: branches: \u0026#39;main\u0026#39;: - step: runs-on: my.custom.label script: - echo \u0026#34;Hello world\u0026#34; Seu runner auto-hospedado está pronto!\nPara mais informações sobre runners visite a documentação bitbucket runners.\nPrecisa de ajuda? # Acesse nossa página de Contato e converse conosco.\nSucesso!\nLeitura complementar: # Pipelines runners frequently asked questions\n","date":"29 julio 2022","externalUrl":null,"permalink":"/blog/pt/posts/corredor-bitbukect/corredor-bitbukect/","section":"Posts","summary":"","title":"Bitbucket 'self-hosted' runner em ambiente Kubernetes","type":"posts"},{"content":" Ejecución de bitbucket runners autohospedados en Kubernetes # Los runners le permiten ejecutar pipelines desde sus repositorios. Bitbucket le permite alojar estos runners en su propia infraestructura, los llamados self-hosted runners.\nEn este artículo, lo guiaremos a través de cómo crear un runner autohospedado a nivel de workspace y ejecutarlo en Kubernetes.\nCreando un runner en bitbucket # El primer paso es crear un nuevo runner. Vamos a crearlo a nivel del workspace:\nVaya a su perfil y haga clic en el workspace que desee.\nHaga clic en configuración y seleccione workspace runners.\nAñadir runner.\nDefina el nombre para el runner y una label. Las labels self.hosted y linux son valores predeterminados, debemos agregar una nueva label para poder identificar en el pipeline en qué runner se debe ejecutar el build, si hay otros runners creados.\nClickea en next. Se generará una salida con el siguiente comando docker:\ndocker container run -it -v /tmp:/tmp -v /var/run/docker.sock:/var/run/docker.sock \\ -v /var/lib/docker/containers:/var/lib/docker/containers:ro \\ -e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ --name runner-87c1a9ae-c216-5512-a92d-12fb95f77f0b \\ docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1 Copie este comando, ya que vamos a utilizar los valores de las variables presentadas para la configuración de nuestro runner autohospedado y haga clic en finish.\nObserve que el runner se creó en el workspace, pero su estado es UNREGISTRED. Después de configurar el runner y ejecutarlo en el entorno de Kubernetes, su estado cambiará a ONLINE.\nConfiguración de Kubernetes # El siguiente paso es compilar los archivos de Kubernetes para alojar el runner.\nPrimero manejemos las variables dadas por el comando:\n-e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ Copiar el valor de las variables ACCOUNT_UUID y RUNNER_UUID sin las { }.\nLas variables OAUTH_CLIENT_ID y OAUTH_CLIENT_SECRET debe convertirse a base64.\necho -n OAUTH_CLIENT_ID | base64 echo -n OAUTH_CLIENT_SECRET | base64 Una vez hecho esto, pasamos a la etapa de construcción de los archivos de Kubernetes:\nsecret.yaml\njob.yaml\nAgregue los valores de las variables:\nsecret.yaml # apiVersion: v1 kind: Secret metadata: name: runner-01-oauth-credentials labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} data: oauthClientId: {OAUTH_CLIENT_ID} oauthClientSecret: {OAUTH_CLIENT_SECRET} job.yaml # Importante: En el archivo job.yaml, las variables accountUuid y runnerUuid, en la sección \u0026lsquo;container variables\u0026rsquo;, deben agregarse entre “ ” y { }, de esa forma “{ACCOUNT_UUID}”\napiVersion: batch/v1 kind: Job metadata: name: runner-01 spec: template: metadata: labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} spec: containers: - name: bitbucket-runner-01 image: docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner env: - name: ACCOUNT_UUID value: “{${ACCOUNT_UUID}}” - name: RUNNER_UUID value: “{${RUNNER_UUID}}” - name: RUNTIME_PREREQUISITES_ENABLED value: true - name: WORKING_DIRECTORY value: \u0026#34;/tmp\u0026#34; - name: OAUTH_CLIENT_ID valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientId - name: OAUTH_CLIENT_SECRET valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientSecret volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers readOnly: true - name: var-run mountPath: /var/run - name: docker-in-docker image: docker:20.10.7-dind securityContext: privileged: true volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers - name: var-run mountPath: /var/run restartPolicy: OnFailure volumes: - name: tmp - name: docker-containers - name: var-run backoffLimit: 6 completions: 1 parallelism: 1 Ahora apliquemos las configuraciones creadas anteriormente.\nkubectl -n namespace apply -f secrets.yaml kubectl -n namespace apply -f job.yaml Probando el nuevo runner # pipelines: branches: \u0026#39;main\u0026#39;: - step: runs-on: my.custom.label script: - echo \u0026#34;Hello world\u0026#34; ¡Su runner autohospedado está listo!\nPara obtener más información acerca de los runners, visite la documentación de bitbucket runners.\n¿Necesita ayuda? # Accede a nuestra página de Contacto y chatea con nosotros.\n¡Éxito!\nLectura adicional: # Pipelines runners frequently asked questions\n","date":"29 de enero de 2022","externalUrl":null,"permalink":"/blog/es/blog/corredor-bitbucket/bitbucket-en-el-entorno-kubernetes/","section":"Blog","summary":"","title":"Bitbucket 'self-hosted' runner en el entorno Kubernetes","type":"blog"},{"content":" Ejecución de bitbucket runners autohospedados en Kubernetes # Los runners le permiten ejecutar pipelines desde sus repositorios. Bitbucket le permite alojar estos runners en su propia infraestructura, los llamados self-hosted runners.\nEn este artículo, lo guiaremos a través de cómo crear un runner autohospedado a nivel de workspace y ejecutarlo en Kubernetes.\nCreando un runner en bitbucket # El primer paso es crear un nuevo runner. Vamos a crearlo a nivel del workspace:\nVaya a su perfil y haga clic en el workspace que desee.\nHaga clic en configuración y seleccione workspace runners.\nAñadir runner.\nDefina el nombre para el runner y una label. Las labels self.hosted y linux son valores predeterminados, debemos agregar una nueva label para poder identificar en el pipeline en qué runner se debe ejecutar el build, si hay otros runners creados.\nClickea en next. Se generará una salida con el siguiente comando docker:\ndocker container run -it -v /tmp:/tmp -v /var/run/docker.sock:/var/run/docker.sock \\ -v /var/lib/docker/containers:/var/lib/docker/containers:ro \\ -e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ --name runner-87c1a9ae-c216-5512-a92d-12fb95f77f0b \\ docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1 Copie este comando, ya que vamos a utilizar los valores de las variables presentadas para la configuración de nuestro runner autohospedado y haga clic en finish.\nObserve que el runner se creó en el workspace, pero su estado es UNREGISTRED. Después de configurar el runner y ejecutarlo en el entorno de Kubernetes, su estado cambiará a ONLINE.\nConfiguración de Kubernetes # El siguiente paso es compilar los archivos de Kubernetes para alojar el runner.\nPrimero manejemos las variables dadas por el comando:\n-e ACCOUNT_UUID={ACCOUNT_UUID} \\ -e RUNNER_UUID={RUNNER_UUID} \\ -e RUNTIME_PREREQUISITES_ENABLED=true \\ -e OAUTH_CLIENT_ID=OAUTH_CLIENT_ID \\ -e OAUTH_CLIENT_SECRET=OAUTH_CLIENT_SECRET \\ -e WORKING_DIRECTORY=/tmp \\ Copiar el valor de las variables ACCOUNT_UUID y RUNNER_UUID sin las { }.\nLas variables OAUTH_CLIENT_ID y OAUTH_CLIENT_SECRET debe convertirse a base64.\necho -n OAUTH_CLIENT_ID | base64 echo -n OAUTH_CLIENT_SECRET | base64 Una vez hecho esto, pasamos a la etapa de construcción de los archivos de Kubernetes:\nsecret.yaml\njob.yaml\nAgregue los valores de las variables:\nsecret.yaml # apiVersion: v1 kind: Secret metadata: name: runner-01-oauth-credentials labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} data: oauthClientId: {OAUTH_CLIENT_ID} oauthClientSecret: {OAUTH_CLIENT_SECRET} job.yaml # Importante: En el archivo job.yaml, las variables accountUuid y runnerUuid, en la sección \u0026lsquo;container variables\u0026rsquo;, deben agregarse entre “ ” y { }, de esa forma “{ACCOUNT_UUID}”\napiVersion: batch/v1 kind: Job metadata: name: runner-01 spec: template: metadata: labels: accountUuid: {ACCOUNT_UUID} runnerUuid: {RUNNER_UUID} spec: containers: - name: bitbucket-runner-01 image: docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner env: - name: ACCOUNT_UUID value: “{${ACCOUNT_UUID}}” - name: RUNNER_UUID value: “{${RUNNER_UUID}}” - name: RUNTIME_PREREQUISITES_ENABLED value: true - name: WORKING_DIRECTORY value: \u0026#34;/tmp\u0026#34; - name: OAUTH_CLIENT_ID valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientId - name: OAUTH_CLIENT_SECRET valueFrom: secretKeyRef: name: runner-01-oauth-credentials key: oauthClientSecret volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers readOnly: true - name: var-run mountPath: /var/run - name: docker-in-docker image: docker:20.10.7-dind securityContext: privileged: true volumeMounts: - name: tmp mountPath: /tmp - name: docker-containers mountPath: /var/lib/docker/containers - name: var-run mountPath: /var/run restartPolicy: OnFailure volumes: - name: tmp - name: docker-containers - name: var-run backoffLimit: 6 completions: 1 parallelism: 1 Ahora apliquemos las configuraciones creadas anteriormente.\nkubectl -n namespace apply -f secrets.yaml kubectl -n namespace apply -f job.yaml Probando el nuevo runner # pipelines: branches: \u0026#39;main\u0026#39;: - step: runs-on: my.custom.label script: - echo \u0026#34;Hello world\u0026#34; ¡Su runner autohospedado está listo!\nPara obtener más información acerca de los runners, visite la documentación de bitbucket runners.\n¿Necesita ayuda? # Accede a nuestra página de Contacto y chatea con nosotros.\n¡Éxito!\nLectura adicional: # Pipelines runners frequently asked questions\n","date":"29 de enero de 2022","externalUrl":null,"permalink":"/blog/es/posts/corredor-bitbucket/bitbucket-en-el-entorno-kubernetes/","section":"Posts","summary":"","title":"Bitbucket 'self-hosted' runner en el entorno Kubernetes","type":"posts"},{"content":"","date":"29 de enero de 2022","externalUrl":null,"permalink":"/blog/es/tags/kuberenetes/","section":"Tags","summary":"","title":"Kuberenetes","type":"tags"},{"content":"","date":"29 de enero de 2022","externalUrl":null,"permalink":"/blog/es/authors/maria/","section":"Authors","summary":"","title":"Maria","type":"authors"},{"content":"","date":"29 de enero de 2022","externalUrl":null,"permalink":"/blog/es/authors/maria-aline/","section":"Authors","summary":"","title":"Maria-Aline","type":"authors"},{"content":"","date":"29 de enero de 2022","externalUrl":null,"permalink":"/blog/es/tags/pipilines/","section":"Tags","summary":"","title":"Pipilines","type":"tags"},{"content":"","date":"29 de enero de 2022","externalUrl":null,"permalink":"/blog/es/tags/runners/","section":"Tags","summary":"","title":"Runners","type":"tags"},{"content":"","date":"30 mayo 2022","externalUrl":null,"permalink":"/blog/pt/tags/automacao/","section":"Tags","summary":"","title":"Automacao","type":"tags"},{"content":"","date":"mayo 30, 2022","externalUrl":null,"permalink":"/blog/en/categories/automation-system/","section":"Categories","summary":"","title":"Automation System","type":"categories"},{"content":"","date":"30 de enero de 2022","externalUrl":null,"permalink":"/blog/es/tags/automatizacion/","section":"Tags","summary":"","title":"Automatizacion","type":"tags"},{"content":"","date":"30 de enero de 2022","externalUrl":null,"permalink":"/blog/es/tags/dcim/","section":"Tags","summary":"","title":"DCIM","type":"tags"},{"content":"Inteligência operacional é uma área da TI responsável por definir as soluções, as ferramentas e a metodologia que serão adotadas a fim de criar um padrão de monitoramento, e consequentemente um padrão de consulta de SLA, relatórios e acesso a métricas e logs das plataformas do negócio.\nDentre as funções da inteligência operacional estão:\n1- Contemplar todas as camadas do negócio: Tudo o que é importante para o funcionamento do negócio deve estar mapeado;\n2- Definir as ferramentas adequadas para cada área;\n3- Criação e propagação das metodologias, procedimentos e ações técnicas;\n4- Documentação para a implementação e para a utilização das ferramentas adotadas.\nA importância do monitoramento\nAs métricas e os logs coletados pelas ferramentas de monitoramento formam a base para que uma plataforma possa sofrer evoluções e ter seus incidentes solucionados.\nAs \u0026ldquo;provas reais\u0026rdquo; dos resultados das decisões de T.I. são retiradas dos dashboards providos por estas ferramentas.\nO monitoramento trabalha 24x7 e quando bem configurado é capaz de prever incidentes e apoiar a equipe.\nEm caso de indisponibilidade ele é capaz de alertar o grupo responsável pela solução, e quando maduro, pode realizar procedimentos de rotina, executando ações e interagindo com o ambiente.\nÉ ele também que válida o SLA e alimenta os relatórios de disponibilidade da Gerencia.\nAs fases principais do monitoramento # Implementação # O processo de implementação consiste em garantir que todas as camadas e aplicações estejam monitoradas e reportando corretamente:\nServidores e serviços;\nSistemas e aplicações;\nSimulação do fluxo real dos dados (monitoramento do negocio).\nSejam cloud ou on-premises, os dashboards e os relatórios devem considerar todas as camadas acima.\nUma vez armada esta estrutura devemos garantir que o monitoramento esteja integrado com os demais sistemas da empresa. Exemplos: sistemas e sistemas de backup, sistemas de autenticação e grupos de acesso.\nValidações das demais equipes # Esse é um momento importante, onde o apoio dos principais stakeholders, assim como um bom relacionamento entre áreas contam positivamente.\nA utilização de boas ferramentas, fluxos de implementação simples e automatizados são importantes para garantir o sucesso a longo prazo.\nNeste passo a missão principal é garantir que todas as áreas saibam a importância de manter padronizada esta base implementada, possibilitando os relatórios e dashboards padronizados e centralizados.\nValidação dos relatórios # Quando o menos é mais. Os níveis gerenciais sabem o que precisam, e não levar informação desnecessária significa agilidade e clareza.\nUma reunião é suficiente, a fim de descobrir quais informações são necessárias para ajudar a popular os KPIs.\nO importante é garantir que, em caso de incidente, os dados necessários para averiguar o problema estarão presentes sem demora.\nRetroalimentação # O inicio e o fim do ciclo.\nNeste momento levamos todas as considerações, erros, melhorias e novas necessidades para nosso backlog. Definindo tempos e prioridades e voltamos ao passo 1, logo ao passo 2 e assim sucessivamente e constantemente.\nConsiderações finais # Esperamos que tenha sido proveitosa a leitura e que tenha ficado claro os benefícios e a importância de um monitoramento e de uma equipe de inteligência operacional.\nA Gole conta com o serviço de Inteligência Operacional e conta com experiência participando e implementando sistemas de monitoramento tanto para operações que possuem NOC (Centro de Operações de Redes) internalizado como terceirizado, assim como empresas que não possuem um time 24x7, ainda que em ambos os cenários existam aplicações que são 24x7 e necessitam um SLA maior que 99.8%.\n","date":"30 mayo 2022","externalUrl":null,"permalink":"/blog/pt/blog/inteligencia-operacional/inteligencia-operacional/","section":"Blog","summary":"","title":"Inteligência operacional","type":"blog"},{"content":"Inteligência operacional é uma área da TI responsável por definir as soluções, as ferramentas e a metodologia que serão adotadas a fim de criar um padrão de monitoramento, e consequentemente um padrão de consulta de SLA, relatórios e acesso a métricas e logs das plataformas do negócio.\nDentre as funções da inteligência operacional estão:\n1- Contemplar todas as camadas do negócio: Tudo o que é importante para o funcionamento do negócio deve estar mapeado;\n2- Definir as ferramentas adequadas para cada área;\n3- Criação e propagação das metodologias, procedimentos e ações técnicas;\n4- Documentação para a implementação e para a utilização das ferramentas adotadas.\nA importância do monitoramento\nAs métricas e os logs coletados pelas ferramentas de monitoramento formam a base para que uma plataforma possa sofrer evoluções e ter seus incidentes solucionados.\nAs \u0026ldquo;provas reais\u0026rdquo; dos resultados das decisões de T.I. são retiradas dos dashboards providos por estas ferramentas.\nO monitoramento trabalha 24x7 e quando bem configurado é capaz de prever incidentes e apoiar a equipe.\nEm caso de indisponibilidade ele é capaz de alertar o grupo responsável pela solução, e quando maduro, pode realizar procedimentos de rotina, executando ações e interagindo com o ambiente.\nÉ ele também que válida o SLA e alimenta os relatórios de disponibilidade da Gerencia.\nAs fases principais do monitoramento # Implementação # O processo de implementação consiste em garantir que todas as camadas e aplicações estejam monitoradas e reportando corretamente:\nServidores e serviços;\nSistemas e aplicações;\nSimulação do fluxo real dos dados (monitoramento do negocio).\nSejam cloud ou on-premises, os dashboards e os relatórios devem considerar todas as camadas acima.\nUma vez armada esta estrutura devemos garantir que o monitoramento esteja integrado com os demais sistemas da empresa. Exemplos: sistemas e sistemas de backup, sistemas de autenticação e grupos de acesso.\nValidações das demais equipes # Esse é um momento importante, onde o apoio dos principais stakeholders, assim como um bom relacionamento entre áreas contam positivamente.\nA utilização de boas ferramentas, fluxos de implementação simples e automatizados são importantes para garantir o sucesso a longo prazo.\nNeste passo a missão principal é garantir que todas as áreas saibam a importância de manter padronizada esta base implementada, possibilitando os relatórios e dashboards padronizados e centralizados.\nValidação dos relatórios # Quando o menos é mais. Os níveis gerenciais sabem o que precisam, e não levar informação desnecessária significa agilidade e clareza.\nUma reunião é suficiente, a fim de descobrir quais informações são necessárias para ajudar a popular os KPIs.\nO importante é garantir que, em caso de incidente, os dados necessários para averiguar o problema estarão presentes sem demora.\nRetroalimentação # O inicio e o fim do ciclo.\nNeste momento levamos todas as considerações, erros, melhorias e novas necessidades para nosso backlog. Definindo tempos e prioridades e voltamos ao passo 1, logo ao passo 2 e assim sucessivamente e constantemente.\nConsiderações finais # Esperamos que tenha sido proveitosa a leitura e que tenha ficado claro os benefícios e a importância de um monitoramento e de uma equipe de inteligência operacional.\nA Gole conta com o serviço de Inteligência Operacional e conta com experiência participando e implementando sistemas de monitoramento tanto para operações que possuem NOC (Centro de Operações de Redes) internalizado como terceirizado, assim como empresas que não possuem um time 24x7, ainda que em ambos os cenários existam aplicações que são 24x7 e necessitam um SLA maior que 99.8%.\n","date":"30 mayo 2022","externalUrl":null,"permalink":"/blog/pt/posts/inteligencia-operacional/inteligencia-operacional/","section":"Posts","summary":"","title":"Inteligência operacional","type":"posts"},{"content":" La inteligencia operativa es un área de TI responsable de definir las soluciones, herramientas y metodología que se adoptarán para crear un estándar de monitoreo y, en consecuencia, un estándar de consulta de SLA, informes y acceso a métricas y registros de las plataformas del negocio.\nEntre las funciones de la inteligencia operativa se encuentran:\n1- Contemplar todas las capas del negocio: Todo lo que es importante para el funcionamiento del negocio debe ser mapeado;\n2- Definir las herramientas adecuadas para cada área;\n3- Creación y difusión de metodologías, procedimientos y acciones técnicas;\n4- Documentación para la implementación y uso de las herramientas adoptadas.\nLa importancia del monitoreo\nLas métricas y los registros recopilados por las herramientas de monitoreo forman la base para que una plataforma evolucione y resuelva sus incidentes.\nLa \u0026ldquo;evidencia real\u0026rdquo; de los resultados de las decisiones de TI. se toman de los dashboards proporcionados por estas herramientas.\nEl monitoreo funciona las 24 horas del día, los 7 días de la semana y, cuando está configurado correctamente, puede predecir incidentes y brindar soporte al equipo.\nEn caso de indisponibilidad, es capaz de alertar al grupo responsable de la solución y, cuando está maduro, puede realizar procedimientos de rutina, ejecutar acciones e interactuar con el entorno.\nTambién es el que valida el SLA y alimenta los reportes de disponibilidad de la Gerencia.\nLas principales fases del monitoreo # Implementación # El proceso de implementación consiste en asegurar que todas las capas y aplicaciones sean monitoreadas y reportando correctamente:\nServidores y servicios;\nSistemas y aplicaciones;\nSimulación del flujo real de datos (monitoreo del negocio).\nYa sea en la nube o en on-premises, los dashboards y los informes deben considerar todas las capas arriba.\nUma vez armada esta estrutura devemos garantir que o monitoramento esteja integrado com os demais sistemas da empresa. Exemplos são sistemas de backup e sistemas, sistemas de autenticação e grupos de acesso.\nUna vez configurada esta estructura, debemos asegurarnos de que el monitoreo esté integrado con los demás sistemas de la empresa. Algunos ejemplos: los sistemas y sistemas de respaldo, los sistemas de autenticación y los grupos de acceso.\nValidaciones de los otros equipos # Este es un momento importante, donde cuenta positivamente el apoyo de los principales stakeholders, así como una buena relación entre áreas.\nEl uso de buenas herramientas, los flujos de implementación simples y automatizados son importantes para garantizar el éxito a largo plazo.\nEn este paso, la misión principal es lograr que todas las áreas conozcan la importancia de mantener esta base implementada estandarizada, permitiendo reportes y dashboards estandarizados y centralizados.\nValidación de informes # Cuando menos es más. Los niveles gerenciales saben lo que necesitan, y no traer información innecesaria significa agilidad y claridad.\nUna reunión es suficiente para averiguar qué información se necesita para ayudar a completar los KPI.\nLo importante es asegurarse de que, en caso de incidente, los datos necesarios para investigar el problema estarán disponibles sin demora.\nRetroalimentación # El principio y el final del ciclo.\nEn este punto llevamos todas las consideraciones, errores, mejoras y nuevas necesidades a nuestro backlog. Definiendo tiempos y prioridades y volvemos al paso 1, luego al paso 2 y así sucesivamente.\nConsideraciones finales # Esperamos que la lectura haya sido fructífera y quede claro los beneficios e importancia del monitoreo y de un equipo de inteligencia operativa.\nGole dispone de un servicio de Inteligencia Operacional y tiene experiencia participando e implantando sistemas de monitorización tanto para operaciones que cuentan con un NOC (Centro de Operaciones de Red) propio o externo, como para empresas que no cuentan con un equipo 24x7, aunque en ambas escenarios hay aplicaciones que son 24x7 y necesitan un SLA superior al 99,8%.\n","date":"30 de enero de 2022","externalUrl":null,"permalink":"/blog/es/blog/inteligencia-operacional/inteligencia-operativa/","section":"Blog","summary":"","title":"Inteligencia operativa","type":"blog"},{"content":" La inteligencia operativa es un área de TI responsable de definir las soluciones, herramientas y metodología que se adoptarán para crear un estándar de monitoreo y, en consecuencia, un estándar de consulta de SLA, informes y acceso a métricas y registros de las plataformas del negocio.\nEntre las funciones de la inteligencia operativa se encuentran:\n1- Contemplar todas las capas del negocio: Todo lo que es importante para el funcionamiento del negocio debe ser mapeado;\n2- Definir las herramientas adecuadas para cada área;\n3- Creación y difusión de metodologías, procedimientos y acciones técnicas;\n4- Documentación para la implementación y uso de las herramientas adoptadas.\nLa importancia del monitoreo\nLas métricas y los registros recopilados por las herramientas de monitoreo forman la base para que una plataforma evolucione y resuelva sus incidentes.\nLa \u0026ldquo;evidencia real\u0026rdquo; de los resultados de las decisiones de TI. se toman de los dashboards proporcionados por estas herramientas.\nEl monitoreo funciona las 24 horas del día, los 7 días de la semana y, cuando está configurado correctamente, puede predecir incidentes y brindar soporte al equipo.\nEn caso de indisponibilidad, es capaz de alertar al grupo responsable de la solución y, cuando está maduro, puede realizar procedimientos de rutina, ejecutar acciones e interactuar con el entorno.\nTambién es el que valida el SLA y alimenta los reportes de disponibilidad de la Gerencia.\nLas principales fases del monitoreo # Implementación # El proceso de implementación consiste en asegurar que todas las capas y aplicaciones sean monitoreadas y reportando correctamente:\nServidores y servicios;\nSistemas y aplicaciones;\nSimulación del flujo real de datos (monitoreo del negocio).\nYa sea en la nube o en on-premises, los dashboards y los informes deben considerar todas las capas arriba.\nUma vez armada esta estrutura devemos garantir que o monitoramento esteja integrado com os demais sistemas da empresa. Exemplos são sistemas de backup e sistemas, sistemas de autenticação e grupos de acesso.\nUna vez configurada esta estructura, debemos asegurarnos de que el monitoreo esté integrado con los demás sistemas de la empresa. Algunos ejemplos: los sistemas y sistemas de respaldo, los sistemas de autenticación y los grupos de acceso.\nValidaciones de los otros equipos # Este es un momento importante, donde cuenta positivamente el apoyo de los principales stakeholders, así como una buena relación entre áreas.\nEl uso de buenas herramientas, los flujos de implementación simples y automatizados son importantes para garantizar el éxito a largo plazo.\nEn este paso, la misión principal es lograr que todas las áreas conozcan la importancia de mantener esta base implementada estandarizada, permitiendo reportes y dashboards estandarizados y centralizados.\nValidación de informes # Cuando menos es más. Los niveles gerenciales saben lo que necesitan, y no traer información innecesaria significa agilidad y claridad.\nUna reunión es suficiente para averiguar qué información se necesita para ayudar a completar los KPI.\nLo importante es asegurarse de que, en caso de incidente, los datos necesarios para investigar el problema estarán disponibles sin demora.\nRetroalimentación # El principio y el final del ciclo.\nEn este punto llevamos todas las consideraciones, errores, mejoras y nuevas necesidades a nuestro backlog. Definiendo tiempos y prioridades y volvemos al paso 1, luego al paso 2 y así sucesivamente.\nConsideraciones finales # Esperamos que la lectura haya sido fructífera y quede claro los beneficios e importancia del monitoreo y de un equipo de inteligencia operativa.\nGole dispone de un servicio de Inteligencia Operacional y tiene experiencia participando e implantando sistemas de monitorización tanto para operaciones que cuentan con un NOC (Centro de Operaciones de Red) propio o externo, como para empresas que no cuentan con un equipo 24x7, aunque en ambas escenarios hay aplicaciones que son 24x7 y necesitan un SLA superior al 99,8%.\n","date":"30 de enero de 2022","externalUrl":null,"permalink":"/blog/es/posts/inteligencia-operacional/inteligencia-operativa/","section":"Posts","summary":"","title":"Inteligencia operativa","type":"posts"},{"content":"","date":"30 de enero de 2022","externalUrl":null,"permalink":"/blog/es/tags/ipam/","section":"Tags","summary":"","title":"IPAM","type":"tags"},{"content":"","date":"30 de enero de 2022","externalUrl":null,"permalink":"/blog/es/authors/mauricio/","section":"Authors","summary":"","title":"Mauricio","type":"authors"},{"content":"","date":"30 de enero de 2022","externalUrl":null,"permalink":"/blog/es/authors/mauricio-santana/","section":"Authors","summary":"","title":"Mauricio-Santana","type":"authors"},{"content":"","date":"30 mayo 2022","externalUrl":null,"permalink":"/blog/pt/categories/sistema-de-automacao/","section":"Categories","summary":"","title":"Sistema De Automacao","type":"categories"},{"content":"","date":"30 de enero de 2022","externalUrl":null,"permalink":"/blog/es/categories/sistema-de-automatizacion/","section":"Categories","summary":"","title":"Sistema De Automatizacion","type":"categories"},{"content":"","date":"3 de enero de 2022","externalUrl":null,"permalink":"/blog/es/tags/educacion/","section":"Tags","summary":"","title":"Educacion","type":"tags"},{"content":"","date":"enero 3, 2022","externalUrl":null,"permalink":"/blog/en/tags/education/","section":"Tags","summary":"","title":"Education","type":"tags"},{"content":" Cómo reducir el costo de kubernetes GKE mediante la eliminación de nodos en ventanas de tiempo específicos sin usar herramientas externas o API.\nEl problema # Nuestro problema surge cuando tenemos un ambiente de prueba (QA) que solo se usa en horario comercial y estar 24x7 genera un costo innecesario.\nSolución propuesta # Apagar el ambiente de prueba fuera del horario laboral, eliminando nodos de nuestro clúster. Al acercarse el comienzo de la jornada laboral, estos nodos deben crearse y el ambiente de prueba debe comenzar a operar nuevamente.\nDependencias para esta solución # Para que esto sea posible necesitamos tener tres puntos de configuración:\n1- Un \u0026ldquo;grupo de nodos\u0026rdquo; separado que se puede descartar sin afectar la producción. Para que esta configuración sea más efectiva, puede incluir Taints and Tolerantios.\n2- Un label común para todos los deploys/sts que se pueden desactivar en este horario. Ejemplo: “scheduler=comercial”\n3- Conozca la lista de namespaces que contienen los deployments/sts que se desactivarán.\nPasos previos de implementación # Necesitamos asegurarnos de que los nodos y las implementaciones estén configurados correctamente.\nValidación de node-pool e deployments y/o statefulsets # Primero enumeremos nuestros nodes pools y validemos que nuestro ambiente esté listo:\n\u0026gt; gcloud container node-pools list --cluster us-gole-01 NAME MACHINE_TYPE DISK_SIZE_GB NODE_VERSION pool-main c2-standard-8 100 1.20.10-gke.1600 pool-qa e2-standard-8 80 1.20.10-gke.1600 Si el node-pool no existe, es necesario crear este node-pool con la cantidad correspondiente de nodos, que puede ser solo uno, y agregar el taint:\nCreando node pool con taint Si el node-pool ya existe, pero no tiene el taint necesario, entonces usa el recurso de gcloud aún en versión beta para agregar el taint:\n\u0026gt; gcloud beta container node-pools update pool-qa --node-taints=\u0026#39;scheduler=comercial:NoSchedule\u0026#39; Ahora vamos a validar que todos los deployments que queramos contengan los labels necesarios. En este ejemplo no tendremos statefulset en nuestra lista, pero lógicamente encaja perfectamente.\n\u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-a deployment.apps/gole-sonarcube 1/1 1 1 34d namespace-a deployment.apps/gole-redis 1/1 1 1 34d namespace-a deployment.apps/gole-nodejs-app 1/1 1 1 34d \u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-b deployment.apps/gole-netbox-worker 1/1 1 1 34d namespace-b deployment.apps/gole-netbox 1/1 1 1 7d18h Adición del tolerations en el deploy # Necesitamos asegurarnos de que los deploys estén configuradas correctamente.\n❯ kubectl -n namespace-a get deploy -l scheduler=comercial -o=jsonpath=\u0026#39;{.spec.template.spec.tolerations}\u0026#39; El resultado debe ser un objeto como este multiplicado por el número de deploys existentes. Todos estarán en la misma lista, pero mirando la lista se puede ver fácilmente.\n{\u0026#34;effect\u0026#34;:\u0026#34;PreferNoSchedule\u0026#34;,\u0026#34;key\u0026#34;:\u0026#34;scheduler\u0026#34;,\u0026#34;operator\u0026#34;:\u0026#34;Equal\u0026#34;,\u0026#34;value\u0026#34;:\u0026#34;comercial\u0026#34;} Aquí hay un ejemplo de dónde se deben configurar los tolerations:\napiVersion: apps/v1 kind: Deployment metadata: name: gole-app labels: scheduler: comercial app: gole-app tier: api-extended spec: progressDeadlineSeconds: 600 replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: scheduler: comercial app: gole-app tier: api-extended strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: labels: scheduler: comercial app: gole-app tier: api-extended spec: tolerations: - key: \u0026#34;scheduler\u0026#34; operator: \u0026#34;Equal\u0026#34; value: \u0026#34;comercial\u0026#34; effect: \u0026#34;PreferNoSchedule\u0026#34; containers: Validación final # ¿Tenemos labels en los deployments? Sí\n¿Tenemos un node pool con un taint configurado? Sí\n¿Tenemos tolerations establecidas en nuestros deployments? Sí\nAsí que ahora podemos empezar.\nImplementación # Para la implementación de la solución necesitaremos crear algunos recursos:\nSecrets\nCronjob\nSecret key.json # Nuestro secret será el archivo renombrado como key.json generado en service account, keys dentro de IAM.\nLógicamente, este usuario del sistema debe tener permiso para administrar el clúster de kubernetes mediante el sdk del gcloud.\nkey.json \u0026gt; cat key.json { \u0026#34;type\u0026#34;: \u0026#34;service_account\u0026#34;, \u0026#34;project_id\u0026#34;: \u0026#34;gole-autoscaling-sample\u0026#34;, \u0026#34;private_key_id\u0026#34;: \u0026#34;asdfasdfasdfasdasdfasdasdf....\u0026#34;, \u0026#34;private_key\u0026#34;: \u0026#34;-----BEGIN PRIVATE KEY-----\\ndasdfasdf393993..asdfsf.aksdflksjdflksjfkjafljasdjkf....Ijr7ZCBgpbQrDH\\nvNUw/JxaVbLtpvy3KSmYpjGfKnHFs+wPQi+NFmwrdOZHvKjdtRNxHvPqgWNxCSAh\\nMwEB8cKs0dzif1Hbg7EtYrZOR8g7LZrTD3c4lTsahMyI9x3kN0aCe5QXDXvtPEJ1\\n3s5XFBriQc1tmHwMEV4VW8s=CONTINUA....\\n-----END PRIVATE KEY-----\\n\u0026#34;, \u0026#34;client_email\u0026#34;: \u0026#34;infra@golesuite.com\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;11223344556677889900\u0026#34;, \u0026#34;auth_uri\u0026#34;: \u0026#34;https://accounts.google.com/o/oauth2/auth\u0026#34;, \u0026#34;token_uri\u0026#34;: \u0026#34;https://oauth2.googleapis.com/token\u0026#34;, \u0026#34;auth_provider_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/oauth2/v1/certs\u0026#34;, \u0026#34;client_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/robot/v1/metadata/x509/blablabla\u0026#34; } Luego agreguemos este archivo como un secret en un namespace específico para nuestra automatización.\n\u0026gt; kubectl -n devops create secret generic gcloud-key --from-file=./key.json Comprobando la clave creada:\n\u0026gt; kubectl -n devops get secret gcloud-key -o=jsonpath=\u0026#39;{.data.key\\.json}\u0026#39; | base64 -d Nota: Asegúrese de que solo los administradores puedan ver el contenido del namespace utilizado. En este caso usaremos el namespace devops\nCreando nuestro Cronjob # Ahora vamos a crear un archivo yaml que use el kind Cronjob.\nNuestro cronjob está configurado para:\nInicio a las 7:30 am de lunes a viernes.\nApagado a las 19:00 de lunes a viernes.\napiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-shutdown namespace: devops spec: schedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;0\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;sheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key --- apiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-startup namespace: devops spec: schedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key Puede ver que nuestro cronjob usa dos puntos de montaje externos:\ntz-config\ngcloud-key\nNuestro tz-config es un apunte al archivo zoneinfo que se encuentra en cualquier sistema operativo. Linux, en este caso le estamos comunicando a nuestro cronjob que su zona horaria es America/Sao_Paulo.\nNuestro gcloud-key usa el modelo de secret, y aquí es donde haremos el link con el secret creado en el paso anterior.\ncronjob ENV Variables # ENV Variables Required example value SCALE_DEPLOY_NUMBER X 0 SCALE_STS_NUMBER X 0 SCALE_NODES_NUMBER X 0 PROJECT_ID X gole CLUSTER_NAME X br-gole-01 GCLOUD_ZONE X southamerica-east1-a SCHEDULER_LABEL X scheduler=comercial SCHEDULER_POOL X pool-qa Antes de crear y aplicar el archivo cronjob debemos cambiar el valor de las variables.\nEste se encuentra dentro de env:\nenv: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; Una vez que se han seguido todos los pasos, estamos listos para aplicar nuestro cronjob.\nSolo me gustaría decirles dónde están los comandos que realmente hacen el trabajo de bajar y subir el ambiente, ya que todo lo que hemos hecho hasta ahora ha sido preparar la infraestructura.\n¿Qué comandos vamos a ejecutar? # Los comandos que se ejecutarán para realizar la tarea de autoscaling se describen en este proyecto de git (es el mismo proyecto):\nhttps://github.com/golesuite/gcloud-gke-scheduling\nhttps://gitlab.com/gole-group/community/gcloud-gke-scheduling\nEl archivo alpine-gcloud.sh se llama dentro de Cronjob en la sesión de commands.\nEl contenido del archivo contiene la secuencia de comandos que harán nuestro trabajo.\nHay dos pasos principales:\n1- shutdown.\nEscalar los deploys que contienen las labels declaradas a 0\nEscalar los nodes del node pool que contienen los taints a 0\n2- startup\nEscalar los deploys que contienen las labels declaradas a 1 o más\nEscalar los nodes del node pool que contienen los taints a 1 o más\nTodo lo demás que creamos contiene la estructura que usaremos para que estos comandos se puedan ejecutar desde dentro de nuestro clúster.\nAplicando el cronjob. # Una vez que hayamos guardado nuestro archivo cronjob localmente y ya hayamos modificado las variables, los tiempos y los namespaces, apliquémoslos. Tenga en cuenta que los tiempos de ejecución de cronjob apuntan a 3 horas más, eso se debe a que las API de control de los nodos de GKE usan la hora UTC. Dado que los valores de TZ para cronjobs aún están en beta, lo más seguro es agregar 3 horas más y llegaremos en la hora correcta.\nEs decir, si quieres 8h y estás en una ciudad GMT -3, entonces 8+3=11.\nPara empezar tendremos (07:30h):\nschedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; Para apagar (19:00h):\nschedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; \u0026gt; kubectl apply -f cronjob.yaml \u0026gt; kubectl -n devops get cronjob Cuando se ejecute tendremos un job ejecutándose:\n\u0026gt; kubectl -n devops get job Lógicamente, el job inicia un pod y con eso podemos seguir los logs.\nPruebas # Cambie las horas para que se ejecuten en los momentos en los que usted está trabajando, con el fin de validar que los procesos se ejecutan correctamente.\nConsideraciones finales # Este artículo incluye:\nkubernetes Google GKE\ngcloud\nnode-pools\ntaints\nauto-scaling\nCronjobs\ncontainer commands\ncontainer env variables\nHay muchas formas de crear y administrar un clúster de Kubernetes, así que no se limite a crear soluciones o diferentes formas de aplicar sus soluciones.\nUse y abuse de las funciones de las API.\n¿Necesita ayuda? # Ve a nuestra página de Contacto y chatea con nosotros. Estaremos encantados de servirle.\n¡Éxito!\n","date":"3 de enero de 2022","externalUrl":null,"permalink":"/blog/es/blog/programador-automatico-gke/autom%C3%A1tico-del-planificador-de-gke/","section":"Blog","summary":"","title":"Escalado automático del planificador de GKE","type":"blog"},{"content":" Cómo reducir el costo de kubernetes GKE mediante la eliminación de nodos en ventanas de tiempo específicos sin usar herramientas externas o API.\nEl problema # Nuestro problema surge cuando tenemos un ambiente de prueba (QA) que solo se usa en horario comercial y estar 24x7 genera un costo innecesario.\nSolución propuesta # Apagar el ambiente de prueba fuera del horario laboral, eliminando nodos de nuestro clúster. Al acercarse el comienzo de la jornada laboral, estos nodos deben crearse y el ambiente de prueba debe comenzar a operar nuevamente.\nDependencias para esta solución # Para que esto sea posible necesitamos tener tres puntos de configuración:\n1- Un \u0026ldquo;grupo de nodos\u0026rdquo; separado que se puede descartar sin afectar la producción. Para que esta configuración sea más efectiva, puede incluir Taints and Tolerantios.\n2- Un label común para todos los deploys/sts que se pueden desactivar en este horario. Ejemplo: “scheduler=comercial”\n3- Conozca la lista de namespaces que contienen los deployments/sts que se desactivarán.\nPasos previos de implementación # Necesitamos asegurarnos de que los nodos y las implementaciones estén configurados correctamente.\nValidación de node-pool e deployments y/o statefulsets # Primero enumeremos nuestros nodes pools y validemos que nuestro ambiente esté listo:\n\u0026gt; gcloud container node-pools list --cluster us-gole-01 NAME MACHINE_TYPE DISK_SIZE_GB NODE_VERSION pool-main c2-standard-8 100 1.20.10-gke.1600 pool-qa e2-standard-8 80 1.20.10-gke.1600 Si el node-pool no existe, es necesario crear este node-pool con la cantidad correspondiente de nodos, que puede ser solo uno, y agregar el taint:\nCreando node pool con taint Si el node-pool ya existe, pero no tiene el taint necesario, entonces usa el recurso de gcloud aún en versión beta para agregar el taint:\n\u0026gt; gcloud beta container node-pools update pool-qa --node-taints=\u0026#39;scheduler=comercial:NoSchedule\u0026#39; Ahora vamos a validar que todos los deployments que queramos contengan los labels necesarios. En este ejemplo no tendremos statefulset en nuestra lista, pero lógicamente encaja perfectamente.\n\u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-a deployment.apps/gole-sonarcube 1/1 1 1 34d namespace-a deployment.apps/gole-redis 1/1 1 1 34d namespace-a deployment.apps/gole-nodejs-app 1/1 1 1 34d \u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-b deployment.apps/gole-netbox-worker 1/1 1 1 34d namespace-b deployment.apps/gole-netbox 1/1 1 1 7d18h Adición del tolerations en el deploy # Necesitamos asegurarnos de que los deploys estén configuradas correctamente.\n❯ kubectl -n namespace-a get deploy -l scheduler=comercial -o=jsonpath=\u0026#39;{.spec.template.spec.tolerations}\u0026#39; El resultado debe ser un objeto como este multiplicado por el número de deploys existentes. Todos estarán en la misma lista, pero mirando la lista se puede ver fácilmente.\n{\u0026#34;effect\u0026#34;:\u0026#34;PreferNoSchedule\u0026#34;,\u0026#34;key\u0026#34;:\u0026#34;scheduler\u0026#34;,\u0026#34;operator\u0026#34;:\u0026#34;Equal\u0026#34;,\u0026#34;value\u0026#34;:\u0026#34;comercial\u0026#34;} Aquí hay un ejemplo de dónde se deben configurar los tolerations:\napiVersion: apps/v1 kind: Deployment metadata: name: gole-app labels: scheduler: comercial app: gole-app tier: api-extended spec: progressDeadlineSeconds: 600 replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: scheduler: comercial app: gole-app tier: api-extended strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: labels: scheduler: comercial app: gole-app tier: api-extended spec: tolerations: - key: \u0026#34;scheduler\u0026#34; operator: \u0026#34;Equal\u0026#34; value: \u0026#34;comercial\u0026#34; effect: \u0026#34;PreferNoSchedule\u0026#34; containers: Validación final # ¿Tenemos labels en los deployments? Sí\n¿Tenemos un node pool con un taint configurado? Sí\n¿Tenemos tolerations establecidas en nuestros deployments? Sí\nAsí que ahora podemos empezar.\nImplementación # Para la implementación de la solución necesitaremos crear algunos recursos:\nSecrets\nCronjob\nSecret key.json # Nuestro secret será el archivo renombrado como key.json generado en service account, keys dentro de IAM.\nLógicamente, este usuario del sistema debe tener permiso para administrar el clúster de kubernetes mediante el sdk del gcloud.\nkey.json \u0026gt; cat key.json { \u0026#34;type\u0026#34;: \u0026#34;service_account\u0026#34;, \u0026#34;project_id\u0026#34;: \u0026#34;gole-autoscaling-sample\u0026#34;, \u0026#34;private_key_id\u0026#34;: \u0026#34;asdfasdfasdfasdasdfasdasdf....\u0026#34;, \u0026#34;private_key\u0026#34;: \u0026#34;-----BEGIN PRIVATE KEY-----\\ndasdfasdf393993..asdfsf.aksdflksjdflksjfkjafljasdjkf....Ijr7ZCBgpbQrDH\\nvNUw/JxaVbLtpvy3KSmYpjGfKnHFs+wPQi+NFmwrdOZHvKjdtRNxHvPqgWNxCSAh\\nMwEB8cKs0dzif1Hbg7EtYrZOR8g7LZrTD3c4lTsahMyI9x3kN0aCe5QXDXvtPEJ1\\n3s5XFBriQc1tmHwMEV4VW8s=CONTINUA....\\n-----END PRIVATE KEY-----\\n\u0026#34;, \u0026#34;client_email\u0026#34;: \u0026#34;infra@golesuite.com\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;11223344556677889900\u0026#34;, \u0026#34;auth_uri\u0026#34;: \u0026#34;https://accounts.google.com/o/oauth2/auth\u0026#34;, \u0026#34;token_uri\u0026#34;: \u0026#34;https://oauth2.googleapis.com/token\u0026#34;, \u0026#34;auth_provider_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/oauth2/v1/certs\u0026#34;, \u0026#34;client_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/robot/v1/metadata/x509/blablabla\u0026#34; } Luego agreguemos este archivo como un secret en un namespace específico para nuestra automatización.\n\u0026gt; kubectl -n devops create secret generic gcloud-key --from-file=./key.json Comprobando la clave creada:\n\u0026gt; kubectl -n devops get secret gcloud-key -o=jsonpath=\u0026#39;{.data.key\\.json}\u0026#39; | base64 -d Nota: Asegúrese de que solo los administradores puedan ver el contenido del namespace utilizado. En este caso usaremos el namespace devops\nCreando nuestro Cronjob # Ahora vamos a crear un archivo yaml que use el kind Cronjob.\nNuestro cronjob está configurado para:\nInicio a las 7:30 am de lunes a viernes.\nApagado a las 19:00 de lunes a viernes.\napiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-shutdown namespace: devops spec: schedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;0\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;sheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key --- apiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-startup namespace: devops spec: schedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key Puede ver que nuestro cronjob usa dos puntos de montaje externos:\ntz-config\ngcloud-key\nNuestro tz-config es un apunte al archivo zoneinfo que se encuentra en cualquier sistema operativo. Linux, en este caso le estamos comunicando a nuestro cronjob que su zona horaria es America/Sao_Paulo.\nNuestro gcloud-key usa el modelo de secret, y aquí es donde haremos el link con el secret creado en el paso anterior.\ncronjob ENV Variables # ENV Variables Required example value SCALE_DEPLOY_NUMBER X 0 SCALE_STS_NUMBER X 0 SCALE_NODES_NUMBER X 0 PROJECT_ID X gole CLUSTER_NAME X br-gole-01 GCLOUD_ZONE X southamerica-east1-a SCHEDULER_LABEL X scheduler=comercial SCHEDULER_POOL X pool-qa Antes de crear y aplicar el archivo cronjob debemos cambiar el valor de las variables.\nEste se encuentra dentro de env:\nenv: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; Una vez que se han seguido todos los pasos, estamos listos para aplicar nuestro cronjob.\nSolo me gustaría decirles dónde están los comandos que realmente hacen el trabajo de bajar y subir el ambiente, ya que todo lo que hemos hecho hasta ahora ha sido preparar la infraestructura.\n¿Qué comandos vamos a ejecutar? # Los comandos que se ejecutarán para realizar la tarea de autoscaling se describen en este proyecto de git (es el mismo proyecto):\nhttps://github.com/golesuite/gcloud-gke-scheduling\nhttps://gitlab.com/gole-group/community/gcloud-gke-scheduling\nEl archivo alpine-gcloud.sh se llama dentro de Cronjob en la sesión de commands.\nEl contenido del archivo contiene la secuencia de comandos que harán nuestro trabajo.\nHay dos pasos principales:\n1- shutdown.\nEscalar los deploys que contienen las labels declaradas a 0\nEscalar los nodes del node pool que contienen los taints a 0\n2- startup\nEscalar los deploys que contienen las labels declaradas a 1 o más\nEscalar los nodes del node pool que contienen los taints a 1 o más\nTodo lo demás que creamos contiene la estructura que usaremos para que estos comandos se puedan ejecutar desde dentro de nuestro clúster.\nAplicando el cronjob. # Una vez que hayamos guardado nuestro archivo cronjob localmente y ya hayamos modificado las variables, los tiempos y los namespaces, apliquémoslos. Tenga en cuenta que los tiempos de ejecución de cronjob apuntan a 3 horas más, eso se debe a que las API de control de los nodos de GKE usan la hora UTC. Dado que los valores de TZ para cronjobs aún están en beta, lo más seguro es agregar 3 horas más y llegaremos en la hora correcta.\nEs decir, si quieres 8h y estás en una ciudad GMT -3, entonces 8+3=11.\nPara empezar tendremos (07:30h):\nschedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; Para apagar (19:00h):\nschedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; \u0026gt; kubectl apply -f cronjob.yaml \u0026gt; kubectl -n devops get cronjob Cuando se ejecute tendremos un job ejecutándose:\n\u0026gt; kubectl -n devops get job Lógicamente, el job inicia un pod y con eso podemos seguir los logs.\nPruebas # Cambie las horas para que se ejecuten en los momentos en los que usted está trabajando, con el fin de validar que los procesos se ejecutan correctamente.\nConsideraciones finales # Este artículo incluye:\nkubernetes Google GKE\ngcloud\nnode-pools\ntaints\nauto-scaling\nCronjobs\ncontainer commands\ncontainer env variables\nHay muchas formas de crear y administrar un clúster de Kubernetes, así que no se limite a crear soluciones o diferentes formas de aplicar sus soluciones.\nUse y abuse de las funciones de las API.\n¿Necesita ayuda? # Ve a nuestra página de Contacto y chatea con nosotros. Estaremos encantados de servirle.\n¡Éxito!\n","date":"3 de enero de 2022","externalUrl":null,"permalink":"/blog/es/posts/programador-automatico-gke/autom%C3%A1tico-del-planificador-de-gke/","section":"Posts","summary":"","title":"Escalado automático del planificador de GKE","type":"posts"},{"content":"","date":"3 de enero de 2022","externalUrl":null,"permalink":"/blog/es/categories/virtualizacion/","section":"Categories","summary":"","title":"Virtualizacion","type":"categories"},{"content":"","date":"enero 3, 2022","externalUrl":null,"permalink":"/blog/en/categories/virtualization/","section":"Categories","summary":"","title":"Virtualization","type":"categories"},{"content":"","date":"3 enero 2022","externalUrl":null,"permalink":"/blog/pt/tags/educacao/","section":"Tags","summary":"","title":"Educacao","type":"tags"},{"content":"Como diminuir o custo do kubernetes GKE eliminando nodes em janelas específicas de tempo sem utilizar nenhuma ferramenta ou API externa.\nO problema # Nosso problema se apresenta quando temos um ambiente de testes (QA) que é utilizado somente em horário comercial e ficando ligado 24x7 gera um custo desnecessário.\nSolução proposta # Desligar o ambiente de testes fora do horário do expediente, eliminando nodes de nosso cluster. Chegando perto do horário de início do expediente estes nodes devem ser criados e o ambiente de teste deve voltar a operar.\nDependências para esta solução # Para que isso seja possível precisamos ter três pontos de configuração:\n1- Um “node pool” separado que possa ser eliminado sem afetar a produção. Para deixar esta configuração mais eficaz pode incluir Taints and Tolerantios.\n2- Um label em comum para todos os deploys/sts que poderão ser desligados neste horário. Exemplo: \u0026ldquo;scheduler=comercial\u0026rdquo;\n3- Conhecer a lista de namespaces que contenham os deploys/sts que serão desativados.\nPassos prévios da implementação # Precisamos ter certeza de que os nodes e os deploys estão configurados corretamente.\nValidação do node-pool e dos deployments e/ou statefulsets # Vamos primeiro listar nossos nodes pools e validar que nosso ambiente está preparado:\n\u0026gt; gcloud container node-pools list --cluster us-gole-01 NAME MACHINE_TYPE DISK_SIZE_GB NODE_VERSION pool-main c2-standard-8 100 1.20.10-gke.1600 pool-qa e2-standard-8 80 1.20.10-gke.1600 Caso o node-pool não exista é necessário criar este node pool com o número correspondente de nodes, podendo ser apenas um, e adicionar o taint:\nCriando node pool com taint Caso o node-pool já exista mas não tenha o taint necessário, então utilize o recurso do gcloud ainda em beta para adicionar o taint:\n\u0026gt; gcloud beta container node-pools update pool-qa --node-taints=\u0026#39;scheduler=comercial:NoSchedule\u0026#39; Agora vamos validar se todos os deploys que desejamos contém os labels necessários.\nNeste exemplo não teremos statefulset em nossa lista, mas logicamente que se encaixa perfeitamente.\n\u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-a deployment.apps/gole-sonarcube 1/1 1 1 34d namespace-a deployment.apps/gole-redis 1/1 1 1 34d namespace-a deployment.apps/gole-nodejs-app 1/1 1 1 34d \u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-b deployment.apps/gole-netbox-worker 1/1 1 1 34d namespace-b deployment.apps/gole-netbox 1/1 1 1 7d18h Adicionando o tolerations no deploy # Precisamos ter certeza de que os deploys estão configurados corretamente\n❯ kubectl -n namespace-a get deploy -l scheduler=comercial -o=jsonpath=\u0026#39;{.spec.template.spec.tolerations}\u0026#39; A saída deve ser um objeto deste abaixo vezes o número de deploys existentes. Vão estar todos dentro da mesma lista, mas olhando a lista é possível observar facilmente.\n{\u0026#34;effect\u0026#34;:\u0026#34;PreferNoSchedule\u0026#34;,\u0026#34;key\u0026#34;:\u0026#34;scheduler\u0026#34;,\u0026#34;operator\u0026#34;:\u0026#34;Equal\u0026#34;,\u0026#34;value\u0026#34;:\u0026#34;comercial\u0026#34;} Temos aqui um exemplo de onde deve estar configurado o tolerations:\napiVersion: apps/v1 kind: Deployment metadata: name: gole-app labels: scheduler: comercial app: gole-app tier: api-extended spec: progressDeadlineSeconds: 600 replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: scheduler: comercial app: gole-app tier: api-extended strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: labels: scheduler: comercial app: gole-app tier: api-extended spec: tolerations: - key: \u0026#34;scheduler\u0026#34; operator: \u0026#34;Equal\u0026#34; value: \u0026#34;comercial\u0026#34; effect: \u0026#34;PreferNoSchedule\u0026#34; containers: Validação final # Temos labels nos deployments? sim\nTemos um node pool com um taint configurado? sim\nTemos tolerations setados em nossos deployments? sim\nEntão agora podemos começar.\nImplementação # Para a implementação da solução precisaremos criar alguns recursos:\nSecrets Cronjob Secret key.json # Nosso secret será o arquivo renomeado para key.json gerada em service account, keys dentro de IAM.\nLogicamente este usuário de sistema deverá ter permissão para administrar o cluster kubernetes utilizando o sdk do gcloud.\nkey.json \u0026gt; cat key.json { \u0026#34;type\u0026#34;: \u0026#34;service_account\u0026#34;, \u0026#34;project_id\u0026#34;: \u0026#34;gole-autoscaling-sample\u0026#34;, \u0026#34;private_key_id\u0026#34;: \u0026#34;asdfasdfasdfasdasdfasdasdf....\u0026#34;, \u0026#34;private_key\u0026#34;: \u0026#34;-----BEGIN PRIVATE KEY-----\\ndasdfasdf393993..asdfsf.aksdflksjdflksjfkjafljasdjkf....Ijr7ZCBgpbQrDH\\nvNUw/JxaVbLtpvy3KSmYpjGfKnHFs+wPQi+NFmwrdOZHvKjdtRNxHvPqgWNxCSAh\\nMwEB8cKs0dzif1Hbg7EtYrZOR8g7LZrTD3c4lTsahMyI9x3kN0aCe5QXDXvtPEJ1\\n3s5XFBriQc1tmHwMEV4VW8s=CONTINUA....\\n-----END PRIVATE KEY-----\\n\u0026#34;, \u0026#34;client_email\u0026#34;: \u0026#34;infra@golesuite.com\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;11223344556677889900\u0026#34;, \u0026#34;auth_uri\u0026#34;: \u0026#34;https://accounts.google.com/o/oauth2/auth\u0026#34;, \u0026#34;token_uri\u0026#34;: \u0026#34;https://oauth2.googleapis.com/token\u0026#34;, \u0026#34;auth_provider_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/oauth2/v1/certs\u0026#34;, \u0026#34;client_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/robot/v1/metadata/x509/blablabla\u0026#34; } Vamos então adicionar este arquivo como um secret em um namespace específico para nossa automação.\n\u0026gt; kubectl -n devops create secret generic gcloud-key --from-file=./key.json Verificando a chave criada:\n\u0026gt; kubectl -n devops get secret gcloud-key -o=jsonpath=\u0026#39;{.data.key\\.json}\u0026#39; | base64 -d Obs: Garanta que somente administradores possam visualizar o conteúdo do namespace utilizado. No caso utilizaremos o namespace devops\nCriando nosso Cronjob # Vamos agora criar um arquivo yaml que utiliza o kind Cronjob.\nNosso cronjob está configurado para:\nIniciar às 07:30h de segunda-feira a sexta-feira.\nDesligar às 19:00h de segunda-feira a sexta-feira.\napiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-shutdown namespace: devops spec: schedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;0\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;sheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key --- apiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-startup namespace: devops spec: schedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key É possível notar que nosso cronjob utiliza dois pontos de montagem externos:\ntz-config\ngcloud-key\nNosso tz-config é um apontamento para o arquivo de zoneinfo encontrado em qualquer S.O. Linux, no caso estamos comunicando a nosso cronjob que seu fuso-horário é America/Sao_Paulo.\nNosso gcloud-key utiliza o modelo de secret, e é aqui onde faremos o link com o secret criado no passo anterior.\nCronjob ENV Variables # ENV Variables Required example value SCALE_DEPLOY_NUMBER X 0 SCALE_STS_NUMBER X 0 SCALE_NODES_NUMBER X 0 PROJECT_ID X gole CLUSTER_NAME X br-gole-01 GCLOUD_ZONE X southamerica-east1-a SCHEDULER_LABEL X scheduler=comercial SCHEDULER_POOL X pool-qa Antes de criar e aplicar o arquivo de cronjob devemos alterar o valor das variáveis.\nIsso está localizado dentro de env:\nenv: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; Uma vez que todos os passos foram seguidos, estamos prontos para aplicar nosso cronjob.\nGostaria somente de lhes comentar onde estão os comandos que realmente realizam o trabalho de baixar e subir o ambiente, uma vez que tudo o que fizemos até agora foi somente preparar a infraestrutura.\nQuais são os comandos que vamos executar? # Os comandos que serão executados para efetuar a tarefa do autoscaling estão descritos neste projeto git (é o mesmo projeto):\nhttps://github.com/golesuite/gcloud-gke-scheduling https://gitlab.com/gole-group/community/gcloud-gke-scheduling O arquivo alpine-gcloud.sh está sendo chamado dentro do Cronjob na sessão commands.\nO conteúdo do arquivo contém a sequência de comandos que fará nosso trabalho.\nSão dois os passos principais:\n1- shutdown. Escalar os deploys que contém as labels declaradas para 0\nEscalar os nodes do node pool que contém os taints para 0\n2- startup Escalar os deploys que contém as labels declaradas para 1 ou mais\nEscalar os nodes do node pool que contém os taints para 1 ou mais\nTodo resto que criamos contém a estrutura que utilizaremos para que estes comandos possam ser executados de dentro de nosso cluster.\nAplicando o cronjob. # Uma vez que já salvamos localmente nosso arquivo de cronjob, e já modificamos as variáveis, horários e namespaces, vamos então aplicá-los.\nNotem que os horários de execução do cronjob apontam 3h a mais, isso porque as APIs de controle dos nodes GKE utilizam horário UTC. Uma vez que os valores de TZ para cronjobs ainda estão em beta, o mais seguro é adicionar 3h a mais e chegaremos no horário correto.\nOu seja, se deseja 8h e está em uma cidade GMT -3, logo 8 + 3 = 11.\nPara iniciar teremos (07:30h):\nschedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; Para desligar (19:00h):\nschedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; \u0026gt; kubectl apply -f cronjob.yaml \u0026gt; kubectl -n devops get cronjob Quando ele executar teremos um job correndo:\n\u0026gt; kubectl -n devops get job Logicamente o job inicia um pod e com isso podemos acompanhar os logs.\nTestes # Altere os horários para que corram em momentos que está trabalhando, a fim de validar que os processos corram corretamente.\nConsiderações finais # Este artigo contempla:\nKubernetes Google GKE;\nGcloud;\nNode-pool;\nTaints;\nAuto-scaling;\nCronjobs\nContainer commands\nContainer env variables\nExistem diversas formas de criar e administrar um cluster kubernetes, por isso não se limite a criar soluções ou modos diferentes para aplicar suas soluções.\nUse e abuse dos recursos das APIs.\nPrecisa de ajuda? # Acesse nossa página de Contato e converse conosco. Teremos prazer em servi-los.\nSucesso!\n","date":"3 enero 2022","externalUrl":null,"permalink":"/blog/pt/blog/automatico-do-agendador-gke/automatico-do-agendador-gke/","section":"Blog","summary":"","title":"GKE Scheduler Autoscaling","type":"blog"},{"content":"Como diminuir o custo do kubernetes GKE eliminando nodes em janelas específicas de tempo sem utilizar nenhuma ferramenta ou API externa.\nO problema # Nosso problema se apresenta quando temos um ambiente de testes (QA) que é utilizado somente em horário comercial e ficando ligado 24x7 gera um custo desnecessário.\nSolução proposta # Desligar o ambiente de testes fora do horário do expediente, eliminando nodes de nosso cluster. Chegando perto do horário de início do expediente estes nodes devem ser criados e o ambiente de teste deve voltar a operar.\nDependências para esta solução # Para que isso seja possível precisamos ter três pontos de configuração:\n1- Um “node pool” separado que possa ser eliminado sem afetar a produção. Para deixar esta configuração mais eficaz pode incluir Taints and Tolerantios.\n2- Um label em comum para todos os deploys/sts que poderão ser desligados neste horário. Exemplo: \u0026ldquo;scheduler=comercial\u0026rdquo;\n3- Conhecer a lista de namespaces que contenham os deploys/sts que serão desativados.\nPassos prévios da implementação # Precisamos ter certeza de que os nodes e os deploys estão configurados corretamente.\nValidação do node-pool e dos deployments e/ou statefulsets # Vamos primeiro listar nossos nodes pools e validar que nosso ambiente está preparado:\n\u0026gt; gcloud container node-pools list --cluster us-gole-01 NAME MACHINE_TYPE DISK_SIZE_GB NODE_VERSION pool-main c2-standard-8 100 1.20.10-gke.1600 pool-qa e2-standard-8 80 1.20.10-gke.1600 Caso o node-pool não exista é necessário criar este node pool com o número correspondente de nodes, podendo ser apenas um, e adicionar o taint:\nCriando node pool com taint Caso o node-pool já exista mas não tenha o taint necessário, então utilize o recurso do gcloud ainda em beta para adicionar o taint:\n\u0026gt; gcloud beta container node-pools update pool-qa --node-taints=\u0026#39;scheduler=comercial:NoSchedule\u0026#39; Agora vamos validar se todos os deploys que desejamos contém os labels necessários.\nNeste exemplo não teremos statefulset em nossa lista, mas logicamente que se encaixa perfeitamente.\n\u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-a deployment.apps/gole-sonarcube 1/1 1 1 34d namespace-a deployment.apps/gole-redis 1/1 1 1 34d namespace-a deployment.apps/gole-nodejs-app 1/1 1 1 34d \u0026gt; kubectl -n namespace-a get,sts deploy -l scheduler=comercial NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE namespace-b deployment.apps/gole-netbox-worker 1/1 1 1 34d namespace-b deployment.apps/gole-netbox 1/1 1 1 7d18h Adicionando o tolerations no deploy # Precisamos ter certeza de que os deploys estão configurados corretamente\n❯ kubectl -n namespace-a get deploy -l scheduler=comercial -o=jsonpath=\u0026#39;{.spec.template.spec.tolerations}\u0026#39; A saída deve ser um objeto deste abaixo vezes o número de deploys existentes. Vão estar todos dentro da mesma lista, mas olhando a lista é possível observar facilmente.\n{\u0026#34;effect\u0026#34;:\u0026#34;PreferNoSchedule\u0026#34;,\u0026#34;key\u0026#34;:\u0026#34;scheduler\u0026#34;,\u0026#34;operator\u0026#34;:\u0026#34;Equal\u0026#34;,\u0026#34;value\u0026#34;:\u0026#34;comercial\u0026#34;} Temos aqui um exemplo de onde deve estar configurado o tolerations:\napiVersion: apps/v1 kind: Deployment metadata: name: gole-app labels: scheduler: comercial app: gole-app tier: api-extended spec: progressDeadlineSeconds: 600 replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: scheduler: comercial app: gole-app tier: api-extended strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: labels: scheduler: comercial app: gole-app tier: api-extended spec: tolerations: - key: \u0026#34;scheduler\u0026#34; operator: \u0026#34;Equal\u0026#34; value: \u0026#34;comercial\u0026#34; effect: \u0026#34;PreferNoSchedule\u0026#34; containers: Validação final # Temos labels nos deployments? sim\nTemos um node pool com um taint configurado? sim\nTemos tolerations setados em nossos deployments? sim\nEntão agora podemos começar.\nImplementação # Para a implementação da solução precisaremos criar alguns recursos:\nSecrets Cronjob Secret key.json # Nosso secret será o arquivo renomeado para key.json gerada em service account, keys dentro de IAM.\nLogicamente este usuário de sistema deverá ter permissão para administrar o cluster kubernetes utilizando o sdk do gcloud.\nkey.json \u0026gt; cat key.json { \u0026#34;type\u0026#34;: \u0026#34;service_account\u0026#34;, \u0026#34;project_id\u0026#34;: \u0026#34;gole-autoscaling-sample\u0026#34;, \u0026#34;private_key_id\u0026#34;: \u0026#34;asdfasdfasdfasdasdfasdasdf....\u0026#34;, \u0026#34;private_key\u0026#34;: \u0026#34;-----BEGIN PRIVATE KEY-----\\ndasdfasdf393993..asdfsf.aksdflksjdflksjfkjafljasdjkf....Ijr7ZCBgpbQrDH\\nvNUw/JxaVbLtpvy3KSmYpjGfKnHFs+wPQi+NFmwrdOZHvKjdtRNxHvPqgWNxCSAh\\nMwEB8cKs0dzif1Hbg7EtYrZOR8g7LZrTD3c4lTsahMyI9x3kN0aCe5QXDXvtPEJ1\\n3s5XFBriQc1tmHwMEV4VW8s=CONTINUA....\\n-----END PRIVATE KEY-----\\n\u0026#34;, \u0026#34;client_email\u0026#34;: \u0026#34;infra@golesuite.com\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;11223344556677889900\u0026#34;, \u0026#34;auth_uri\u0026#34;: \u0026#34;https://accounts.google.com/o/oauth2/auth\u0026#34;, \u0026#34;token_uri\u0026#34;: \u0026#34;https://oauth2.googleapis.com/token\u0026#34;, \u0026#34;auth_provider_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/oauth2/v1/certs\u0026#34;, \u0026#34;client_x509_cert_url\u0026#34;: \u0026#34;https://www.googleapis.com/robot/v1/metadata/x509/blablabla\u0026#34; } Vamos então adicionar este arquivo como um secret em um namespace específico para nossa automação.\n\u0026gt; kubectl -n devops create secret generic gcloud-key --from-file=./key.json Verificando a chave criada:\n\u0026gt; kubectl -n devops get secret gcloud-key -o=jsonpath=\u0026#39;{.data.key\\.json}\u0026#39; | base64 -d Obs: Garanta que somente administradores possam visualizar o conteúdo do namespace utilizado. No caso utilizaremos o namespace devops\nCriando nosso Cronjob # Vamos agora criar um arquivo yaml que utiliza o kind Cronjob.\nNosso cronjob está configurado para:\nIniciar às 07:30h de segunda-feira a sexta-feira.\nDesligar às 19:00h de segunda-feira a sexta-feira.\napiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-shutdown namespace: devops spec: schedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;0\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;0\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;sheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key --- apiVersion: batch/v1beta1 kind: CronJob metadata: labels: role: devops owner: gole name: qa-env-startup namespace: devops spec: schedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; concurrencyPolicy: Forbid jobTemplate: metadata: labels: role: devops owner: gole spec: template: spec: restartPolicy: Never containers: - name: gke-operator image: alpine command: - \u0026#34;/bin/sh\u0026#34; args: - -c - \u0026#34;apk add --no-cache curl bash ; \\ curl -O https://raw.githubusercontent.com/golesuite/gcloud-gke-scheduling/main/alpine-gcloud.sh ; \\ chmod +x ./alpine-gcloud.sh ; \\ ./alpine-gcloud.sh\u0026#34; imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /etc/localtime name: tz-config - name: gcloud-key mountPath: /etc/gcloud/ terminationMessagePath: /dev/termination-log terminationMessagePolicy: File env: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; volumes: - name: tz-config hostPath: path: /usr/share/zoneinfo/America/Sao_Paulo - name: gcloud-key secret: secretName: gcloud-key É possível notar que nosso cronjob utiliza dois pontos de montagem externos:\ntz-config\ngcloud-key\nNosso tz-config é um apontamento para o arquivo de zoneinfo encontrado em qualquer S.O. Linux, no caso estamos comunicando a nosso cronjob que seu fuso-horário é America/Sao_Paulo.\nNosso gcloud-key utiliza o modelo de secret, e é aqui onde faremos o link com o secret criado no passo anterior.\nCronjob ENV Variables # ENV Variables Required example value SCALE_DEPLOY_NUMBER X 0 SCALE_STS_NUMBER X 0 SCALE_NODES_NUMBER X 0 PROJECT_ID X gole CLUSTER_NAME X br-gole-01 GCLOUD_ZONE X southamerica-east1-a SCHEDULER_LABEL X scheduler=comercial SCHEDULER_POOL X pool-qa Antes de criar e aplicar o arquivo de cronjob devemos alterar o valor das variáveis.\nIsso está localizado dentro de env:\nenv: - name: SCALE_DEPLOY_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_STS_NUMBER value: \u0026#34;1\u0026#34; - name: SCALE_NODES_NUMBER value: \u0026#34;1\u0026#34; - name: GCLOUD_ZONE value: \u0026#34;southamerica-east1-a\u0026#34; - name: CLUSTER_NAME value: \u0026#34;br-gole-01\u0026#34; - name: SCHEDULER_LABEL value: \u0026#34;scheduler=comercial\u0026#34;\u0026#34; - name: SCHEDULER_POOL value: \u0026#34;pool-qa\u0026#34; - name: PROJECT_ID value: \u0026#34;gole\u0026#34; Uma vez que todos os passos foram seguidos, estamos prontos para aplicar nosso cronjob.\nGostaria somente de lhes comentar onde estão os comandos que realmente realizam o trabalho de baixar e subir o ambiente, uma vez que tudo o que fizemos até agora foi somente preparar a infraestrutura.\nQuais são os comandos que vamos executar? # Os comandos que serão executados para efetuar a tarefa do autoscaling estão descritos neste projeto git (é o mesmo projeto):\nhttps://github.com/golesuite/gcloud-gke-scheduling https://gitlab.com/gole-group/community/gcloud-gke-scheduling O arquivo alpine-gcloud.sh está sendo chamado dentro do Cronjob na sessão commands.\nO conteúdo do arquivo contém a sequência de comandos que fará nosso trabalho.\nSão dois os passos principais:\n1- shutdown. Escalar os deploys que contém as labels declaradas para 0\nEscalar os nodes do node pool que contém os taints para 0\n2- startup Escalar os deploys que contém as labels declaradas para 1 ou mais\nEscalar os nodes do node pool que contém os taints para 1 ou mais\nTodo resto que criamos contém a estrutura que utilizaremos para que estes comandos possam ser executados de dentro de nosso cluster.\nAplicando o cronjob. # Uma vez que já salvamos localmente nosso arquivo de cronjob, e já modificamos as variáveis, horários e namespaces, vamos então aplicá-los.\nNotem que os horários de execução do cronjob apontam 3h a mais, isso porque as APIs de controle dos nodes GKE utilizam horário UTC. Uma vez que os valores de TZ para cronjobs ainda estão em beta, o mais seguro é adicionar 3h a mais e chegaremos no horário correto.\nOu seja, se deseja 8h e está em uma cidade GMT -3, logo 8 + 3 = 11.\nPara iniciar teremos (07:30h):\nschedule: \u0026#34;30 10 * * 1,2,3,4,5\u0026#34; Para desligar (19:00h):\nschedule: \u0026#34;00 22 * * 1,2,3,4,5\u0026#34; \u0026gt; kubectl apply -f cronjob.yaml \u0026gt; kubectl -n devops get cronjob Quando ele executar teremos um job correndo:\n\u0026gt; kubectl -n devops get job Logicamente o job inicia um pod e com isso podemos acompanhar os logs.\nTestes # Altere os horários para que corram em momentos que está trabalhando, a fim de validar que os processos corram corretamente.\nConsiderações finais # Este artigo contempla:\nKubernetes Google GKE;\nGcloud;\nNode-pool;\nTaints;\nAuto-scaling;\nCronjobs\nContainer commands\nContainer env variables\nExistem diversas formas de criar e administrar um cluster kubernetes, por isso não se limite a criar soluções ou modos diferentes para aplicar suas soluções.\nUse e abuse dos recursos das APIs.\nPrecisa de ajuda? # Acesse nossa página de Contato e converse conosco. Teremos prazer em servi-los.\nSucesso!\n","date":"3 enero 2022","externalUrl":null,"permalink":"/blog/pt/posts/automatico-do-agendador-gke/automatico-do-agendador-gke/","section":"Posts","summary":"","title":"GKE Scheduler Autoscaling","type":"posts"},{"content":"","date":"3 enero 2022","externalUrl":null,"permalink":"/blog/pt/categories/virtualizacao/","section":"Categories","summary":"","title":"Virtualizacao","type":"categories"},{"content":" Una súper herramienta para administrar su infraestructura.\nNetbox es mucho más de lo que vamos a hablar en este artículo de blog.\nNuestra idea es indexar contenido en español sobre esta maravillosa herramienta que nos ayuda mucho a organizar tanto la parte lógica como la física de TI.\nLink do grupo Netbox IPAM/DCIM - BR: https://t.me/netboxbr\nSi desea contar con la asesoría de Gole para la implementación, automatización e integración de Netbox con los diferentes servicios de su empresa, por favor contáctenos.\n¿Qué es IPAM? # La gestión de direcciones IP (IPAM) es la metodología que nos permite gestionar todo lo relacionado con IP. Todo lo que engloba el universo lógico del modelo TCP/IP. Con un IPAM puede administrar IPv4, IPv6, VLAN, Subredes, IP. Y para cada una de estas opciones, puede asignar tags, roles y muchas otras cosas. Esto puede parecer innecesario, pero cuando se tiene una red con más de 512 hosts, administrar y mantener la seguridad de esta red sin IPAM puede ser una tarea muy complicada. En este enlace de Wikipedia, tenemos una tabla muy completa de muchas herramientas de IPAM.\n¿Qué es un DCIM? # Data center-infrastructure management (DCIM) es la metodología que tiene como misión integrar los equipos de infraestructura con el equipo que presta servicios a la empresa. Proporcionar al personal de TI toda la información sobre los equipos y hosts que representan su infraestructura.\nEl equipo de virtualización necesita saber a qué puerto del enclosure está conectado el switch SAN y qué racks tienen espacio disponible. Mientras tanto, el equipo de red necesita saber qué rack contiene los reteadores MPLS y cúales switches que tienen la versión de firmware XPTO.\nEsta información es un ejemplo de dónde DCIM marca la diferencia.\nCuando llega el momento de crear el capacity plain, DCIM también es una herramienta indispensable.\n¿Qué es Netbox? # Netbox es una herramienta de código abierto que utiliza la licencia Apache 2.0. Su documentación oficial está disponible en el portal Read the Docs, que contiene documentación de varios otros proyectos código abierto.\nEl proyecto fue creado por Jeremy Stretch, quien trabajó como desarrollador de redes en Digital Ocean.\nCon la evolución de Netbox, muchas personas comenzaron a colaborar con los códigos. Entre estas personas se encuentra John Anderson, quien, participando en varias validaciones e importantes aportes en el back-end, también ayudó a mejorar la interfaz web, que siempre ha sido construida con el framework Django.\nDespués de unos años, Jeremy Stretch y John Anderson, junto con otros ingenieros y desarrolladores, crearon la empresa llamada Network to code.\nSobre la instalación # Existem basicamente duas formas de instalação do Netbox: # Netbox en Docker\nNetbox instalado directamente en el S.O.N\nEs posible fusionar parte de la instalación en el sistema operativo y parte con Docker, esto solo depende del conocimiento en Docker.\nEl proceso de instalación está bien descrito, por lo que no es necesario entrar en él. Nuestra intención es solo presentar la existencia de la herramienta.\nUna vez tengamos Netbox funcionando y hayamos creado el usuario en /admin, podremos acceder a su interfaz web.\nInterfaz de usuario # Cuando accedemos a Netbox a través de la interfaz web, podemos visualizar el menú que se encuentra arriba de todo el sitio.\nLos temas organización, dispositivos, IPAM, virtualización, circuitos, power, secretos y otros, representan el primer concepto al que debemos prestar atención.\nCada tema puede dirigirse a un grupo diferente de personas. Es decir, una persona que se ocupa de las estructuras físicas y los racks puede no tener acceso a la configuración del dispositivo, y las personas que se encargan de los dispositivos pueden no tener acceso al menú de virtualización. Y también podemos definir los niveles de perfil, es decir, es posible que el equipo que tiene acceso a los dispositivos tenga acceso de solo lectura a todo el universo que está dentro de IPAM, o más aún, que pueda crear IPs y no pueda registrar subredes o VLANs.\nEstos son ejemplos, ya que es posible personalizar los accesos como mejor nos parezca.\nTambién podemos autenticar Netbox contra LDAP, Active Directory y otras formas de autenticación.\nPodemos ver la riqueza de detalles y el cuidado que aporta Netbox. En este ejemplo podemos visualizar el vínculo entre la ubicación física, con el tenant, con el rack y con los dispositivos.\nTambién podemos ver que es posible definir colores para cada tipo de dispositivo, además de otras muchas cosas.\nEn el menú de prefijos podemos ver la integración entre roles, VLANs, IPs, porcentaje de utilización de la red.\nTambién podemos ver a la derecha que siempre tenemos la posibilidad de buscar con filtros las diferentes opciones. ¡Es muy poderoso!\nEn esta pantalla estamos dentro de un dispositivo.\nEn este ejemplo podemos ver que el dispositivo tiene asociado un primary_ipv4, tiene un estado de planned, tiene el rol de network, ya que la imagen adjunta nos muestra que es un switch. También tenemos la plataforma Switch y soporte para comentarios y tags.\nEn la parte de interfaces, podemos conectar estas interfaces con los otros dispositivos registrados. Podemos definir si la interfaz usa LAG, si es un bond, si es virtual, la MTU, el tipo de conexión, MAC Address, en fin, todo lo que necesitemos.\nAPI # Cualquiera que esté acostumbrado a trabajar con API sabe lo bueno que es encontrar una API documentada con Swagger.\nNetbox tiene la API más completa y bellamente documentada, evidentemente adoptando swagger. ¡Es posible realizar toda la acción vía Web o vía API, por lo que es posible automatizar toda la inserción y obtención de información!\n¡Es eso! # Lo cierto es que este es un breve resumen de lo que puedes hacer con Netbox. Participamos en implementaciones en empresas multinacionales con más de 3.000 sitios físicos, y más de 5 Data Centers. La organización y transparencia, la integración entre los equipos internos, fue increíble ver los puntos positivos de esta herramienta.\nNetbox también permite la integración nativa con Ansible, Salt, Stack Storm, y muchas otras, sin limitarse a estas herramientas, puede desarrollar sus propias integraciones.\n¡Viva Netbox!\n","date":"30 de enero de 2020","externalUrl":null,"permalink":"/blog/es/blog/que-es-netbox/que-es-netbox-/","section":"Blog","summary":"","title":"¿Qué es Netbox y para qué sirve Netbox?","type":"blog"},{"content":" Una súper herramienta para administrar su infraestructura.\nNetbox es mucho más de lo que vamos a hablar en este artículo de blog.\nNuestra idea es indexar contenido en español sobre esta maravillosa herramienta que nos ayuda mucho a organizar tanto la parte lógica como la física de TI.\nLink do grupo Netbox IPAM/DCIM - BR: https://t.me/netboxbr\nSi desea contar con la asesoría de Gole para la implementación, automatización e integración de Netbox con los diferentes servicios de su empresa, por favor contáctenos.\n¿Qué es IPAM? # La gestión de direcciones IP (IPAM) es la metodología que nos permite gestionar todo lo relacionado con IP. Todo lo que engloba el universo lógico del modelo TCP/IP. Con un IPAM puede administrar IPv4, IPv6, VLAN, Subredes, IP. Y para cada una de estas opciones, puede asignar tags, roles y muchas otras cosas. Esto puede parecer innecesario, pero cuando se tiene una red con más de 512 hosts, administrar y mantener la seguridad de esta red sin IPAM puede ser una tarea muy complicada. En este enlace de Wikipedia, tenemos una tabla muy completa de muchas herramientas de IPAM.\n¿Qué es un DCIM? # Data center-infrastructure management (DCIM) es la metodología que tiene como misión integrar los equipos de infraestructura con el equipo que presta servicios a la empresa. Proporcionar al personal de TI toda la información sobre los equipos y hosts que representan su infraestructura.\nEl equipo de virtualización necesita saber a qué puerto del enclosure está conectado el switch SAN y qué racks tienen espacio disponible. Mientras tanto, el equipo de red necesita saber qué rack contiene los reteadores MPLS y cúales switches que tienen la versión de firmware XPTO.\nEsta información es un ejemplo de dónde DCIM marca la diferencia.\nCuando llega el momento de crear el capacity plain, DCIM también es una herramienta indispensable.\n¿Qué es Netbox? # Netbox es una herramienta de código abierto que utiliza la licencia Apache 2.0. Su documentación oficial está disponible en el portal Read the Docs, que contiene documentación de varios otros proyectos código abierto.\nEl proyecto fue creado por Jeremy Stretch, quien trabajó como desarrollador de redes en Digital Ocean.\nCon la evolución de Netbox, muchas personas comenzaron a colaborar con los códigos. Entre estas personas se encuentra John Anderson, quien, participando en varias validaciones e importantes aportes en el back-end, también ayudó a mejorar la interfaz web, que siempre ha sido construida con el framework Django.\nDespués de unos años, Jeremy Stretch y John Anderson, junto con otros ingenieros y desarrolladores, crearon la empresa llamada Network to code.\nSobre la instalación # Existem basicamente duas formas de instalação do Netbox: # Netbox en Docker\nNetbox instalado directamente en el S.O.N\nEs posible fusionar parte de la instalación en el sistema operativo y parte con Docker, esto solo depende del conocimiento en Docker.\nEl proceso de instalación está bien descrito, por lo que no es necesario entrar en él. Nuestra intención es solo presentar la existencia de la herramienta.\nUna vez tengamos Netbox funcionando y hayamos creado el usuario en /admin, podremos acceder a su interfaz web.\nInterfaz de usuario # Cuando accedemos a Netbox a través de la interfaz web, podemos visualizar el menú que se encuentra arriba de todo el sitio.\nLos temas organización, dispositivos, IPAM, virtualización, circuitos, power, secretos y otros, representan el primer concepto al que debemos prestar atención.\nCada tema puede dirigirse a un grupo diferente de personas. Es decir, una persona que se ocupa de las estructuras físicas y los racks puede no tener acceso a la configuración del dispositivo, y las personas que se encargan de los dispositivos pueden no tener acceso al menú de virtualización. Y también podemos definir los niveles de perfil, es decir, es posible que el equipo que tiene acceso a los dispositivos tenga acceso de solo lectura a todo el universo que está dentro de IPAM, o más aún, que pueda crear IPs y no pueda registrar subredes o VLANs.\nEstos son ejemplos, ya que es posible personalizar los accesos como mejor nos parezca.\nTambién podemos autenticar Netbox contra LDAP, Active Directory y otras formas de autenticación.\nPodemos ver la riqueza de detalles y el cuidado que aporta Netbox. En este ejemplo podemos visualizar el vínculo entre la ubicación física, con el tenant, con el rack y con los dispositivos.\nTambién podemos ver que es posible definir colores para cada tipo de dispositivo, además de otras muchas cosas.\nEn el menú de prefijos podemos ver la integración entre roles, VLANs, IPs, porcentaje de utilización de la red.\nTambién podemos ver a la derecha que siempre tenemos la posibilidad de buscar con filtros las diferentes opciones. ¡Es muy poderoso!\nEn esta pantalla estamos dentro de un dispositivo.\nEn este ejemplo podemos ver que el dispositivo tiene asociado un primary_ipv4, tiene un estado de planned, tiene el rol de network, ya que la imagen adjunta nos muestra que es un switch. También tenemos la plataforma Switch y soporte para comentarios y tags.\nEn la parte de interfaces, podemos conectar estas interfaces con los otros dispositivos registrados. Podemos definir si la interfaz usa LAG, si es un bond, si es virtual, la MTU, el tipo de conexión, MAC Address, en fin, todo lo que necesitemos.\nAPI # Cualquiera que esté acostumbrado a trabajar con API sabe lo bueno que es encontrar una API documentada con Swagger.\nNetbox tiene la API más completa y bellamente documentada, evidentemente adoptando swagger. ¡Es posible realizar toda la acción vía Web o vía API, por lo que es posible automatizar toda la inserción y obtención de información!\n¡Es eso! # Lo cierto es que este es un breve resumen de lo que puedes hacer con Netbox. Participamos en implementaciones en empresas multinacionales con más de 3.000 sitios físicos, y más de 5 Data Centers. La organización y transparencia, la integración entre los equipos internos, fue increíble ver los puntos positivos de esta herramienta.\nNetbox también permite la integración nativa con Ansible, Salt, Stack Storm, y muchas otras, sin limitarse a estas herramientas, puede desarrollar sus propias integraciones.\n¡Viva Netbox!\n","date":"30 de enero de 2020","externalUrl":null,"permalink":"/blog/es/posts/que-es-netbox/que-es-netbox-/","section":"Posts","summary":"","title":"¿Qué es Netbox y para qué sirve Netbox?","type":"posts"},{"content":"","date":"30 de enero de 2020","externalUrl":null,"permalink":"/blog/es/tags/netops/","section":"Tags","summary":"","title":"NetOps","type":"tags"},{"content":"Uma super ferramenta para gerência de sua infraestrutura.\nNetbox é muito mais do que vamos comentar neste artigo de blog.\nNossa ideia é indexar conteúdo em português sobre essa ferramenta maravilhosa que muito nos ajuda na organização tanto da parte lógica como da parte física da TI.\nLink do grupo Netbox IPAM/DCIM - BR: https://t.me/netboxbr\nCaso deseje consultoria Gole para implantação, automatização e integração do Netbox com distintos serviços de sua empresa, por favor entre em contato conosco.\nO que é IPAM? # IP address management (IPAM) é a metodologia que nos permite gerenciar tudo que é relacionado a IP. Tudo que engloba o universo lógico do modelo TCP/IP. Com uma IPAM você pode gerenciar IPv4, IPv6, VLANs, Sub-redes, IPs. E para cada uma destas opções, pode atribuir tags, roles, e muitas outras coisas. Isso pode parecer desnecessário, mas quando se tem uma rede com mais de 512 hosts, realizar a administração e manter a segurança desta rede sem um IPAM pode ser uma tarefa bem complicada. Neste link da Wikipédia, temos uma tabela bem completa de muitas ferramentas IPAM.\nO que é um DCIM? # Data center-infrastructure management (DCIM) é a metodologia que tem como missão integrar os equipamentos da infraestrutura com o time que presta serviço a empresa. Facilitar para as pessoas da TI todas as informações dos equipamentos e hosts que representam sua infraestrutura.\nA equipe de virtualização necessita saber qual é a porta da enclosure que está conectado o switch SAN, precisa saber quais são os racks que dispõem de espaço disponível. Enquanto isso a equipe de redes precisa saber qual rack contém os router MPLS, e quais os switchs que estão com a versão XPTO de firmware.\nEssas informações são exemplos de casos em que o DCIM faz toda a diferença.\nQuando chega o momento de montar o capacity plain, o DCIM também é uma ferramenta indispensável.\nO que é Netbox? # Netbox é uma ferramenta de código aberto que utiliza a licença Apache 2.0. Sua documentação oficial está disponível no portal Read the Docs, portal esse que contém documentações de diversos outros projetos de código aberto.\nO projeto foi criado por Jeremy Stretch, que trabalhava como desenvolvedor de redes (Network Developer) na Digital Ocean.\nCom a evolução do Netbox, muitas pessoas começaram a colaborar com os códigos. Entre estas pessoas esta John Anderson, que participando em diversas validações e contribuições importantes no back-end, também ajudou a melhorar a interface web, que sempre foi construída com Django framework.\nPassando alguns anos Jeremy Stretch e John Anderson, junto com outros engenheiros e desenvolvedores, criaram a empresa chamada Network to code.\nSobre a instalação # Existem basicamente duas formas de instalação do Netbox: # Netbox em Docker Netbox instalado diretamente no S.O. É possível mesclar parte da instalação no S.O. e outra parte com Docker, isso depende somente de conhecimento em docker.\nO processo de instalação está bem descrito, logo não é necessário que abordemos isso. Nossa intenção é somente apresentar a existência da ferramenta.\nUma vez que tenha Netbox correndo e já tenha criado o usuário em /admin, podemos acessar sua interface web.\nInterface do usuário # Quando acessamos o Netbox pela interface web, podemos visualizar o menu que está acima de todo o site.\nOs tópicos organização, dispositivos, IPAM, virtualização, circuitos, Power, segredos e outros, representam o primeiro conceito que devemos nos atentar.\nCada tópico pode ser direcionado a um grupo diferente de pessoas. Ou seja, uma pessoa que cuida das estruturas físicas e dos racks pode não ter acesso a configuração dos dispositivos, e as pessoas que cuidam dos dispositivos, podem não ter acesso ao menu virtualização. E podemos ainda definir quais os níveis de perfil, ou seja, é possível que a equipe que tem acesso aos devices, tenha acesso somente leitura para todo o universo que está dentro de IPAM, ou ainda mais, que possa criar IPs e não possa cadastrar sub-redes ou VLANs.\nIsso são exemplos, uma vez que é possível personalizar os acessos como bem entendemos.\nTambém podemos autenticar o Netbox em LDAP, Active Directory e outras formas de autenticação.\nPodemos ver a riqueza em detalhes e os cuidados que Netbox traz. Neste exemplo podemos visualizar o link entre o local físico, com o tenant, com o rack e com os devices.\nTambém podemos ver que é possível definir cores para cada tipo de device, além de muitas outras coisas.\nJá no menu de prefixes, podemos ver a integração entre roles, VLANs, IPs, porcentagem de utilização das redes.\nPodemos também observar na direita, que sempre temos a possibilidade de buscar com filtro as diversas opções. É muito poderoso!\nNessa tela estamos dentro de um device.\nNesse exemplo, podemos ver que o device tem um primary_ipv4 associado, tem um status de planned, tem o role de network, uma vez que a imagem em anexo nos mostra que é um switch. Temos também a plataforma do switch, e suporte a comentários e tags.\nNa parte de interfaces, podemos conectar estas interfaces com os outros dispositivos cadastrados. Podemos definir se a interface utiliza LAG, se é uma bond, se é virtual, o MTU, o tipo da conexão, MAC Address, enfim, tudo que precisamos.\nAPI # Quem já está acostumado em trabalhar com API’s sabe como é bom quando encontramos uma API que está documentada utilizando Swagger.\nNetbox tem a API mais completa e lindamente documentada, evidentemente, ocupando swagger. É possível fazer toda a ação via Web ou via API, logo é possível automatizar toda a inserção e obtenção de informação!\nÉ isso ai! # A verdade é que isso é um resumo rápido sobre o que se pode fazer com Netbox.\nParticipamos de implementações em empresas multinacionais com mais de 3.000 sites físicos, e mais de 5 Data Centers. A organização e a transparência, a integração entre as equipes internas, foi incrível visualizar os pontos positivos desta ferramenta.\nNetbox também permite integração nativa com Ansible, Salt, Stack Storm, e muitas outras, não se limitando a essas ferramentas, é possível desenvolver as próprias integrações.\nVida longa ao Netbox!\n","date":"30 junio 2020","externalUrl":null,"permalink":"/blog/pt/blog/o-que-e-netbox/o-que-e-netbox/","section":"Blog","summary":"","title":"O que é e para que serve o Netbox","type":"blog"},{"content":"Uma super ferramenta para gerência de sua infraestrutura.\nNetbox é muito mais do que vamos comentar neste artigo de blog.\nNossa ideia é indexar conteúdo em português sobre essa ferramenta maravilhosa que muito nos ajuda na organização tanto da parte lógica como da parte física da TI.\nLink do grupo Netbox IPAM/DCIM - BR: https://t.me/netboxbr\nCaso deseje consultoria Gole para implantação, automatização e integração do Netbox com distintos serviços de sua empresa, por favor entre em contato conosco.\nO que é IPAM? # IP address management (IPAM) é a metodologia que nos permite gerenciar tudo que é relacionado a IP. Tudo que engloba o universo lógico do modelo TCP/IP. Com uma IPAM você pode gerenciar IPv4, IPv6, VLANs, Sub-redes, IPs. E para cada uma destas opções, pode atribuir tags, roles, e muitas outras coisas. Isso pode parecer desnecessário, mas quando se tem uma rede com mais de 512 hosts, realizar a administração e manter a segurança desta rede sem um IPAM pode ser uma tarefa bem complicada. Neste link da Wikipédia, temos uma tabela bem completa de muitas ferramentas IPAM.\nO que é um DCIM? # Data center-infrastructure management (DCIM) é a metodologia que tem como missão integrar os equipamentos da infraestrutura com o time que presta serviço a empresa. Facilitar para as pessoas da TI todas as informações dos equipamentos e hosts que representam sua infraestrutura.\nA equipe de virtualização necessita saber qual é a porta da enclosure que está conectado o switch SAN, precisa saber quais são os racks que dispõem de espaço disponível. Enquanto isso a equipe de redes precisa saber qual rack contém os router MPLS, e quais os switchs que estão com a versão XPTO de firmware.\nEssas informações são exemplos de casos em que o DCIM faz toda a diferença.\nQuando chega o momento de montar o capacity plain, o DCIM também é uma ferramenta indispensável.\nO que é Netbox? # Netbox é uma ferramenta de código aberto que utiliza a licença Apache 2.0. Sua documentação oficial está disponível no portal Read the Docs, portal esse que contém documentações de diversos outros projetos de código aberto.\nO projeto foi criado por Jeremy Stretch, que trabalhava como desenvolvedor de redes (Network Developer) na Digital Ocean.\nCom a evolução do Netbox, muitas pessoas começaram a colaborar com os códigos. Entre estas pessoas esta John Anderson, que participando em diversas validações e contribuições importantes no back-end, também ajudou a melhorar a interface web, que sempre foi construída com Django framework.\nPassando alguns anos Jeremy Stretch e John Anderson, junto com outros engenheiros e desenvolvedores, criaram a empresa chamada Network to code.\nSobre a instalação # Existem basicamente duas formas de instalação do Netbox: # Netbox em Docker Netbox instalado diretamente no S.O. É possível mesclar parte da instalação no S.O. e outra parte com Docker, isso depende somente de conhecimento em docker.\nO processo de instalação está bem descrito, logo não é necessário que abordemos isso. Nossa intenção é somente apresentar a existência da ferramenta.\nUma vez que tenha Netbox correndo e já tenha criado o usuário em /admin, podemos acessar sua interface web.\nInterface do usuário # Quando acessamos o Netbox pela interface web, podemos visualizar o menu que está acima de todo o site.\nOs tópicos organização, dispositivos, IPAM, virtualização, circuitos, Power, segredos e outros, representam o primeiro conceito que devemos nos atentar.\nCada tópico pode ser direcionado a um grupo diferente de pessoas. Ou seja, uma pessoa que cuida das estruturas físicas e dos racks pode não ter acesso a configuração dos dispositivos, e as pessoas que cuidam dos dispositivos, podem não ter acesso ao menu virtualização. E podemos ainda definir quais os níveis de perfil, ou seja, é possível que a equipe que tem acesso aos devices, tenha acesso somente leitura para todo o universo que está dentro de IPAM, ou ainda mais, que possa criar IPs e não possa cadastrar sub-redes ou VLANs.\nIsso são exemplos, uma vez que é possível personalizar os acessos como bem entendemos.\nTambém podemos autenticar o Netbox em LDAP, Active Directory e outras formas de autenticação.\nPodemos ver a riqueza em detalhes e os cuidados que Netbox traz. Neste exemplo podemos visualizar o link entre o local físico, com o tenant, com o rack e com os devices.\nTambém podemos ver que é possível definir cores para cada tipo de device, além de muitas outras coisas.\nJá no menu de prefixes, podemos ver a integração entre roles, VLANs, IPs, porcentagem de utilização das redes.\nPodemos também observar na direita, que sempre temos a possibilidade de buscar com filtro as diversas opções. É muito poderoso!\nNessa tela estamos dentro de um device.\nNesse exemplo, podemos ver que o device tem um primary_ipv4 associado, tem um status de planned, tem o role de network, uma vez que a imagem em anexo nos mostra que é um switch. Temos também a plataforma do switch, e suporte a comentários e tags.\nNa parte de interfaces, podemos conectar estas interfaces com os outros dispositivos cadastrados. Podemos definir se a interface utiliza LAG, se é uma bond, se é virtual, o MTU, o tipo da conexão, MAC Address, enfim, tudo que precisamos.\nAPI # Quem já está acostumado em trabalhar com API’s sabe como é bom quando encontramos uma API que está documentada utilizando Swagger.\nNetbox tem a API mais completa e lindamente documentada, evidentemente, ocupando swagger. É possível fazer toda a ação via Web ou via API, logo é possível automatizar toda a inserção e obtenção de informação!\nÉ isso ai! # A verdade é que isso é um resumo rápido sobre o que se pode fazer com Netbox.\nParticipamos de implementações em empresas multinacionais com mais de 3.000 sites físicos, e mais de 5 Data Centers. A organização e a transparência, a integração entre as equipes internas, foi incrível visualizar os pontos positivos desta ferramenta.\nNetbox também permite integração nativa com Ansible, Salt, Stack Storm, e muitas outras, não se limitando a essas ferramentas, é possível desenvolver as próprias integrações.\nVida longa ao Netbox!\n","date":"30 junio 2020","externalUrl":null,"permalink":"/blog/pt/posts/o-que-e-netbox/o-que-e-netbox/","section":"Posts","summary":"","title":"O que é e para que serve o Netbox","type":"posts"},{"content":"Cloud init é um pacote utilizado para inicializar uma instância de nuvem. Muito utilizado para personalizar máquinas virtuais Linux, onde executa configurações personalizadas que se deseja para a uma VM na sua primeira inicialização. Pode ser utilizado para a configuração de usuários, instalação de pacotes, geração e configuração de chaves SSH.\nQuer criar VMs, setando o nome do servidor, IP, vlan, usuario, etc… sem nem se quer ter que Liga-las? cloud-init é para você! # Home do projeto: https://cloud-init.io Documento oficial: https://cloudinit.readthedocs.io/en/latest/ Cloud-init é um recurso altamente utilizado quando falamos de servidores virtuais fornecido pelos grandes “players” das clouds.\nEle é interessante para clouds e VMs porque seu kernel personalizado não traz suporte a nada que uma VM não precisa para trabalhar. Ou seja, ele não vai trazer suporte a placa de som soundblaster =).\nFoi criado pela Canonical que é a mesma empresa criadora do Ubuntu, e que tem uma gigante esmagadora parte dos Sistemas Operacionais no mercado de clouds.\nGoogle e AWS (entre outros) são exemplos de empresas que utilizam cloud-init para disponibilizar as VMs para seus clientes.\nQuando utilizamos kubernetes ou VMs na Google, por exemplo, é possível visualizar o cloud-init config utilizado por eles, que cá entre nós, é um tremendo de um cloud-init config!\nAlguns exemplos de porque utilizar cloud-init no Proxmox? # Velocidade em criação de novas VMs;\nControle dos IPs das VMs como se fossem um container LXC;\nPossibilidades de automatização;\nCompatibilidades com Ansible e outras ferramentas de automações.\nComo este artigo está sendo criado como uma simples documentação do processo, vamos direto ao assunto e assim podemos validar melhor o que esse tal cloud-init faz.\nDeployando cloud-init em proxmox! Mãos a obra! # O primeiro, leia a documentação oficial Proxmox + cloud-init:\nhttps://pve.proxmox.com/wiki/Cloud-Init_Support\nO segundo, leia pelo menos a introdução do https://cloudinit.readthedocs.io/en/latest/\nAtenção!! Atenção!! # A documentação oficial do proxmox parte com um tópico: Preparing Cloud-Init Templates e isso confunde a galera!\nAs imagens de cloud-init já estão prontas e podemos utilizar sem ter que preparar nada. Isso é somente para as pessoas que necessitam criar seu cloud-init templates from scratch.\nDownload da imagem # Eu escolhi a imagem do ubuntu em homenagem a Canonical que disponibilizou o projeto, logo o mérito é deles: https://cloud-images.ubuntu.com/groovy/current/\nPerceba que tanto o formato “img” como a arquitetura “amd64” são compatíveis com Proxmox. Agora escolha algum node do seu cluster proxmox para hospedar o template e acesse ele por ssh:\n# wget https://cloud-images.ubuntu.com/groovy/current/groovy-server-cloudimg-amd64.img # qm create 9002 --memory 2048 --net0 virtio,bridge=vmbr1 Agora veja em /etc/pve/storage.cfg qual é a storage que você deseja guardar essa imagem. Neste caso vou utilizar a storage local:\n# qm importdisk 9002 groovy-server-cloudimg-amd64.img local Successfully imported disk as ‘unused0:local:9002/vm-9002-disk-0.raw’ # qm set 9002 --scsihw virtio-scsi-pci --scsi0 local:9002/vm-9002-disk-0.raw update VM 9002: -scsi0 local:9002/vm-9002-disk-0.raw -scsihw virtio-scsi-pci Estamos quase prontos. Temos que adicionar agora um 2 discos que é onde vamos armazenar as configs personalizadas (a grosso modo falando).\n# qm set 9002 --ide2 local:cloudinit update VM 9002: -ide2 local:cloudinit Formatting ‘/var/lib/vz/images/9002/vm-9002-cloudinit.qcow2’, fmt=qcow2 cluster_size=65536 preallocation=metadata compression_type=zlib size=4194304 lazy_refcounts=off refcount_bits=16 Arrumando a ordem de boot:\n# qm set 9002 --boot c --bootdisk scsi0 Algumas imagens de amd64 cloud-init são feitas pensadas em compatibilidades com openstack. Por isso temos que adicionar a serial0 para que ela inicie. Caso tenha curiosidade, remova a serial0 e tente o reinício, se não bootar adicione novamente e tudo vai funcionar:\n# qm set 9002 --serial0 socket --vga serial0 update VM 9002: -serial0 socket -vga serial0 Copie a sua chave ssh publica para o servidor do proxmox, para que possamos adicionar esta chave no template do cloud-init:\n[user_machine ~$] scp ~/.ssh/id_rsa.pub root@PROXMOX_NODE:/tmp Voltando ao proxmox server:\n# qm set 9002 --sshkey /tmp/id_rsa.pub update VM 9002: -sshkeys ssh-rsa%20AAAAB3NzaC1yc2EAAAADAQABAAABgQC4LX1HAmPWW4qzmqUBsIvgbdlfDS5MKEVK5cpXRxmUErezgVfvodbGlqqnO0T61Dry3KRg1owq62wpH1z8d%2Bh6vZCsJKoyoklC55xlbJgGDSxEB0%2FbUMiwqWkFdjRwQ1V2HOYNJKttoBUFIQvG8V3XSDtw%2Fw3W0aNOAfnheZX10zMJ%2BCuisMkvGGCBRDwnxxi%2BJoeTGrx85yLYfdD6Ca6yba6KeTMcu5PoI1BH5%2Bvt2Ta90BGjyHpLUOZpoqV0AurTEJIO3n5J0z2OH9WhC77Kwz6mG3MSNueA1BcgRUVvaXvJB65ce2azSVcKbXNkTbeBFlc7FhocEAhXrycRR0L6xgo3acvoCBOx4EijtF0itjzqfvNhH9tN9oLj8Qxiz6ttGivzucfWBsc30pUDopWGaJ0syNFE0Wyvs03cDMHb%2F5Vmb8ixE%2BK2nDJe3OXyn%2Bp4GzkWNyVZjYxutg%2FLAFP6bwe6Oe1jSob4I0bA4xT7guHLp93zEqWHRjDFGhXewhk%3D%20USER%40MACHINE%0 Defina o usuário que vai ter permissão de sudo:\n# qm set 9002 --ciuser gole update VM 9002: -ciuser gole Defina o tipo de máquina. Dica valiosa do Tomas 2w-consultoria.\n# qm set 9002 --machine q35 update VM 9002: -machine q35 Por fim, transforme ela em um template:\n# qm template 9002 Realizando um clone e utilizando a nova VM # Por fim clone o template para uma nova máquina:\n# qm clone 9002 139 --name VMNAME --full Configure o ip que ela vai utilizar:\n# qm set 139 --ipconfig0 ip=172..xxx.xxx.5/24,gw=172.xxx.xxx.1 Redimensione o disco para um tamanho que vai ocupar nesta VM:\n# qm resize 139 scsi0 +45G Image resized. Ligue a VM:\n# qm start 139 Espere ela iniciar e execute o ssh desde a máquina que tinha a chave publica:\n$ ssh -l gole 172.xxx.xxx.5 Bingo! Dentro do servidor sem fazer nenhuma instalação!\nVocê pode definir vlans, DNSs e tudo o que sua nova VM precisa para funcionar. Pode também personalizar o cloud-init com os cicustom. De uma olhada na documentação oficial.\nQuando o cloud-init sobe pela primeira vez, ele vai instalar alguns pacotes, por isso o 1o boot é um pouco mais demorado para liberar o apt.\nSucesso!\n","date":"6 julio 2019","externalUrl":null,"permalink":"/blog/pt/blog/cloud-init-sem-virtual-proxmox-6/cloud-init-sem-virtual-proxmox-6/","section":"Blog","summary":"","title":"Cloud-init no Proxmox Virtual Environment 6","type":"blog"},{"content":" Cloud init es un paquete que se utiliza para inicializar una instancia en la nube. Ampliamente utilizado para personalizar máquinas virtuales Linux, donde ejecuta configuraciones personalizadas que desea para una VM en su primer inicio. Se puede utilizar para configurar usuarios, instalar paquetes, generar y configurar claves SSH.\n¿Quieres crear máquinas virtuales, configurando el nombre del servidor, IP, vlan, usuario, etc… sin siquiera tener que encenderlas? ¡cloud-init es para ti! # Home del projeto: https://cloud-init.io\nDocumento oficial: https://cloudinit.readthedocs.io/en/latest/\nCloud-init es un recurso muy utilizado cuando hablamos de servidores virtuales proporcionados por los grandes “players” de clouds.\nEs interesante para clouds y VMs porque su kernel personalizado no admite nada que una máquina virtual no necesite para funcionar. Es decir, no soportará tarjeta de sonido soundblaster =).\nFue creado por Canonical, que es la misma empresa que creó Ubuntu y que tiene una participación abrumadora de sistemas operativos en el mercado de la nube.\nGoogle y AWS (entre otros) son ejemplos de empresas que utilizan cloud-init para que las máquinas virtuales estén disponibles para sus clientes.\nCuando usamos kubernetes o máquinas virtuales en Google, por ejemplo, es posible visualizar el cloud-init config utilizado por ellos, que entre nosotros, ¡es una tremenda de cloud-init config!\n¿Algunos ejemplos de por qué usar cloud-init en Proxmox? # VRapidez en la creación de nuevas VM\nControl de IPs de VM como si fueran un contenedor LXC\nPosibilidades de automatización\nCompatibilidad con Ansible y otras herramientas de automatización\nComo este artículo se está creando como una documentación simple del proceso, vayamos directamente al grano para que podamos validar mejor lo que hace este cloud-init.\n¡Desplegando cloud-init en proxmox! ¡Manos a la obra! # Lo primero, lee la documentación oficial de Proxmox + cloud-init:\nhttps://pve.proxmox.com/wiki/Cloud-Init_Support\nEn segundo lugar, lea al menos la introducción a la https://cloudinit.readthedocs.io/en/latest/\n¡¡Atención!! ¡¡Atención!! # La documentación oficial de proxmox comienza con un tema: Preparación de plantillas Cloud-Init y esto confunde a la multitud.\nLas imágenes de cloud-init están listas y podemos usarlas sin tener que preparar nada. Esto es solo para personas que necesitan crear sus cloud-init templates from scratch.\nDownload de imagen # Elegí la imagen de ubuntu en honor a Canonical, que puso a disposición el proyecto, por lo que el crédito es para ellos: https://cloud-images.ubuntu.com/groovy/current/\nTenga en cuenta que tanto el formato \u0026ldquo;img\u0026rdquo; como la arquitectura \u0026ldquo;amd64\u0026rdquo; son compatibles con Proxmox. Ahora elija cualquier node de su clúster proxmox para hospedar el template y acceda a el a través de ssh:\n# wget https://cloud-images.ubuntu.com/groovy/current/groovy-server-cloudimg-amd64.img # qm create 9002 --memory 2048 --net0 virtio,bridge=vmbr1 Ahora vea en /etc/pve/storage.cfg en qué storage desea almacenar esta imagen. En este caso usaré el storage local:\n# qm importdisk 9002 groovy-server-cloudimg-amd64.img local Successfully imported disk as ‘unused0:local:9002/vm-9002-disk-0.raw’ # qm set 9002 --scsihw virtio-scsi-pci --scsi0 local:9002/vm-9002-disk-0.raw update VM 9002: -scsi0 local:9002/vm-9002-disk-0.raw -scsihw virtio-scsi-pci Ya casi hemos terminado. Ahora tenemos que agregar e discos que es donde almacenaremos las configs personalizadas (en términos generales).\n# qm set 9002 --ide2 local:cloudinit update VM 9002: -ide2 local:cloudinit Formatting ‘/var/lib/vz/images/9002/vm-9002-cloudinit.qcow2’, fmt=qcow2 cluster_size=65536 preallocation=metadata compression_type=zlib size=4194304 lazy_refcounts=off refcount_bits=16 Arreglando el orden de boot:\n# qm set 9002 --boot c --bootdisk scsi0 Algunas imágenes amd64 cloud-init se crean teniendo en cuenta la compatibilidad con openstack. Entonces tenemos que agregar serial0 para que comience. En caso de que tenga curiosidad, elimine serial0 e intente reiniciar, si no arranca, agréguelo nuevamente y todo funcionará:\n# qm set 9002 --serial0 socket --vga serial0 update VM 9002: -serial0 socket -vga serial0 Copie su clave ssh pública en el servidor proxmox, para que podamos agregar esta clave al template del cloud-init:\n[user_machine ~$] scp ~/.ssh/id_rsa.pub root@PROXMOX_NODE:/tmp Volviendo al servidor proxmox:\n# qm set 9002 --sshkey /tmp/id_rsa.pub update VM 9002: -sshkeys ssh-rsa%20AAAAB3NzaC1yc2EAAAADAQABAAABgQC4LX1HAmPWW4qzmqUBsIvgbdlfDS5MKEVK5cpXRxmUErezgVfvodbGlqqnO0T61Dry3KRg1owq62wpH1z8d%2Bh6vZCsJKoyoklC55xlbJgGDSxEB0%2FbUMiwqWkFdjRwQ1V2HOYNJKttoBUFIQvG8V3XSDtw%2Fw3W0aNOAfnheZX10zMJ%2BCuisMkvGGCBRDwnxxi%2BJoeTGrx85yLYfdD6Ca6yba6KeTMcu5PoI1BH5%2Bvt2Ta90BGjyHpLUOZpoqV0AurTEJIO3n5J0z2OH9WhC77Kwz6mG3MSNueA1BcgRUVvaXvJB65ce2azSVcKbXNkTbeBFlc7FhocEAhXrycRR0L6xgo3acvoCBOx4EijtF0itjzqfvNhH9tN9oLj8Qxiz6ttGivzucfWBsc30pUDopWGaJ0syNFE0Wyvs03cDMHb%2F5Vmb8ixE%2BK2nDJe3OXyn%2Bp4GzkWNyVZjYxutg%2FLAFP6bwe6Oe1jSob4I0bA4xT7guHLp93zEqWHRjDFGhXewhk%3D%20USER%40MACHINE%0 Establezca el usuario que tendrá permiso sudo:\n# qm set 9002 --ciuser gole update VM 9002: -ciuser gole Configure el tipo de máquina. Valioso consejo de Tomas 2w-consultoria.\n# qm set 9002 --machine q35 update VM 9002: -machine q35 Finalmente, conviértelo en un template:\n# qm template 9002 Haciendo un clon y usando la nueva VM # Finalmente, clone el template en una nueva máquina:\n# qm clone 9002 139 --name VMNAME --full Configure la ip que usará:\n# qm set 139 --ipconfig0 ip=172..xxx.xxx.5/24,gw=172.xxx.xxx.1 Cambie el tamaño del disco a un tamaño que ocupará en esta máquina virtual:\n# qm resize 139 scsi0 +45G Image resized. Encienda la VM:\n# qm start 139 Espere a que se inicie y ejecute ssh desde la máquina que tenía la clave pública:\n$ ssh -l gole 172.xxx.xxx.5 ¡Bingo! ¡Dentro del servidor sin hacer ninguna instalación!\nPuede configurar vlans, DNS y todo lo que su nueva VM necesita para funcionar. También puede personalizar cloud-init con cicustom. Echa un vistazo a la documentación oficial.\nCuando cloud-init sube por primera vez, instalará algunos paquetes, por lo que el primer arranque tarda un poco más en liberar apt.\n¡Éxito!\n","date":"6 de enero de 2019","externalUrl":null,"permalink":"/blog/es/blog/cloud-init-sin-virtual-proxmox-6/cloud-init-sin-entorno-virtual-proxmox-6/","section":"Blog","summary":"","title":"Cloud-init no Proxmox Virtual Environment 6","type":"blog"},{"content":"Cloud init é um pacote utilizado para inicializar uma instância de nuvem. Muito utilizado para personalizar máquinas virtuais Linux, onde executa configurações personalizadas que se deseja para a uma VM na sua primeira inicialização. Pode ser utilizado para a configuração de usuários, instalação de pacotes, geração e configuração de chaves SSH.\nQuer criar VMs, setando o nome do servidor, IP, vlan, usuario, etc… sem nem se quer ter que Liga-las? cloud-init é para você! # Home do projeto: https://cloud-init.io Documento oficial: https://cloudinit.readthedocs.io/en/latest/ Cloud-init é um recurso altamente utilizado quando falamos de servidores virtuais fornecido pelos grandes “players” das clouds.\nEle é interessante para clouds e VMs porque seu kernel personalizado não traz suporte a nada que uma VM não precisa para trabalhar. Ou seja, ele não vai trazer suporte a placa de som soundblaster =).\nFoi criado pela Canonical que é a mesma empresa criadora do Ubuntu, e que tem uma gigante esmagadora parte dos Sistemas Operacionais no mercado de clouds.\nGoogle e AWS (entre outros) são exemplos de empresas que utilizam cloud-init para disponibilizar as VMs para seus clientes.\nQuando utilizamos kubernetes ou VMs na Google, por exemplo, é possível visualizar o cloud-init config utilizado por eles, que cá entre nós, é um tremendo de um cloud-init config!\nAlguns exemplos de porque utilizar cloud-init no Proxmox? # Velocidade em criação de novas VMs;\nControle dos IPs das VMs como se fossem um container LXC;\nPossibilidades de automatização;\nCompatibilidades com Ansible e outras ferramentas de automações.\nComo este artigo está sendo criado como uma simples documentação do processo, vamos direto ao assunto e assim podemos validar melhor o que esse tal cloud-init faz.\nDeployando cloud-init em proxmox! Mãos a obra! # O primeiro, leia a documentação oficial Proxmox + cloud-init:\nhttps://pve.proxmox.com/wiki/Cloud-Init_Support\nO segundo, leia pelo menos a introdução do https://cloudinit.readthedocs.io/en/latest/\nAtenção!! Atenção!! # A documentação oficial do proxmox parte com um tópico: Preparing Cloud-Init Templates e isso confunde a galera!\nAs imagens de cloud-init já estão prontas e podemos utilizar sem ter que preparar nada. Isso é somente para as pessoas que necessitam criar seu cloud-init templates from scratch.\nDownload da imagem # Eu escolhi a imagem do ubuntu em homenagem a Canonical que disponibilizou o projeto, logo o mérito é deles: https://cloud-images.ubuntu.com/groovy/current/\nPerceba que tanto o formato “img” como a arquitetura “amd64” são compatíveis com Proxmox. Agora escolha algum node do seu cluster proxmox para hospedar o template e acesse ele por ssh:\n# wget https://cloud-images.ubuntu.com/groovy/current/groovy-server-cloudimg-amd64.img # qm create 9002 --memory 2048 --net0 virtio,bridge=vmbr1 Agora veja em /etc/pve/storage.cfg qual é a storage que você deseja guardar essa imagem. Neste caso vou utilizar a storage local:\n# qm importdisk 9002 groovy-server-cloudimg-amd64.img local Successfully imported disk as ‘unused0:local:9002/vm-9002-disk-0.raw’ # qm set 9002 --scsihw virtio-scsi-pci --scsi0 local:9002/vm-9002-disk-0.raw update VM 9002: -scsi0 local:9002/vm-9002-disk-0.raw -scsihw virtio-scsi-pci Estamos quase prontos. Temos que adicionar agora um 2 discos que é onde vamos armazenar as configs personalizadas (a grosso modo falando).\n# qm set 9002 --ide2 local:cloudinit update VM 9002: -ide2 local:cloudinit Formatting ‘/var/lib/vz/images/9002/vm-9002-cloudinit.qcow2’, fmt=qcow2 cluster_size=65536 preallocation=metadata compression_type=zlib size=4194304 lazy_refcounts=off refcount_bits=16 Arrumando a ordem de boot:\n# qm set 9002 --boot c --bootdisk scsi0 Algumas imagens de amd64 cloud-init são feitas pensadas em compatibilidades com openstack. Por isso temos que adicionar a serial0 para que ela inicie. Caso tenha curiosidade, remova a serial0 e tente o reinício, se não bootar adicione novamente e tudo vai funcionar:\n# qm set 9002 --serial0 socket --vga serial0 update VM 9002: -serial0 socket -vga serial0 Copie a sua chave ssh publica para o servidor do proxmox, para que possamos adicionar esta chave no template do cloud-init:\n[user_machine ~$] scp ~/.ssh/id_rsa.pub root@PROXMOX_NODE:/tmp Voltando ao proxmox server:\n# qm set 9002 --sshkey /tmp/id_rsa.pub update VM 9002: -sshkeys ssh-rsa%20AAAAB3NzaC1yc2EAAAADAQABAAABgQC4LX1HAmPWW4qzmqUBsIvgbdlfDS5MKEVK5cpXRxmUErezgVfvodbGlqqnO0T61Dry3KRg1owq62wpH1z8d%2Bh6vZCsJKoyoklC55xlbJgGDSxEB0%2FbUMiwqWkFdjRwQ1V2HOYNJKttoBUFIQvG8V3XSDtw%2Fw3W0aNOAfnheZX10zMJ%2BCuisMkvGGCBRDwnxxi%2BJoeTGrx85yLYfdD6Ca6yba6KeTMcu5PoI1BH5%2Bvt2Ta90BGjyHpLUOZpoqV0AurTEJIO3n5J0z2OH9WhC77Kwz6mG3MSNueA1BcgRUVvaXvJB65ce2azSVcKbXNkTbeBFlc7FhocEAhXrycRR0L6xgo3acvoCBOx4EijtF0itjzqfvNhH9tN9oLj8Qxiz6ttGivzucfWBsc30pUDopWGaJ0syNFE0Wyvs03cDMHb%2F5Vmb8ixE%2BK2nDJe3OXyn%2Bp4GzkWNyVZjYxutg%2FLAFP6bwe6Oe1jSob4I0bA4xT7guHLp93zEqWHRjDFGhXewhk%3D%20USER%40MACHINE%0 Defina o usuário que vai ter permissão de sudo:\n# qm set 9002 --ciuser gole update VM 9002: -ciuser gole Defina o tipo de máquina. Dica valiosa do Tomas 2w-consultoria.\n# qm set 9002 --machine q35 update VM 9002: -machine q35 Por fim, transforme ela em um template:\n# qm template 9002 Realizando um clone e utilizando a nova VM # Por fim clone o template para uma nova máquina:\n# qm clone 9002 139 --name VMNAME --full Configure o ip que ela vai utilizar:\n# qm set 139 --ipconfig0 ip=172..xxx.xxx.5/24,gw=172.xxx.xxx.1 Redimensione o disco para um tamanho que vai ocupar nesta VM:\n# qm resize 139 scsi0 +45G Image resized. Ligue a VM:\n# qm start 139 Espere ela iniciar e execute o ssh desde a máquina que tinha a chave publica:\n$ ssh -l gole 172.xxx.xxx.5 Bingo! Dentro do servidor sem fazer nenhuma instalação!\nVocê pode definir vlans, DNSs e tudo o que sua nova VM precisa para funcionar. Pode também personalizar o cloud-init com os cicustom. De uma olhada na documentação oficial.\nQuando o cloud-init sobe pela primeira vez, ele vai instalar alguns pacotes, por isso o 1o boot é um pouco mais demorado para liberar o apt.\nSucesso!\n","date":"6 julio 2019","externalUrl":null,"permalink":"/blog/pt/posts/cloud-init-sem-virtual-proxmox-6/cloud-init-sem-virtual-proxmox-6/","section":"Posts","summary":"","title":"Cloud-init no Proxmox Virtual Environment 6","type":"posts"},{"content":" Cloud init es un paquete que se utiliza para inicializar una instancia en la nube. Ampliamente utilizado para personalizar máquinas virtuales Linux, donde ejecuta configuraciones personalizadas que desea para una VM en su primer inicio. Se puede utilizar para configurar usuarios, instalar paquetes, generar y configurar claves SSH.\n¿Quieres crear máquinas virtuales, configurando el nombre del servidor, IP, vlan, usuario, etc… sin siquiera tener que encenderlas? ¡cloud-init es para ti! # Home del projeto: https://cloud-init.io\nDocumento oficial: https://cloudinit.readthedocs.io/en/latest/\nCloud-init es un recurso muy utilizado cuando hablamos de servidores virtuales proporcionados por los grandes “players” de clouds.\nEs interesante para clouds y VMs porque su kernel personalizado no admite nada que una máquina virtual no necesite para funcionar. Es decir, no soportará tarjeta de sonido soundblaster =).\nFue creado por Canonical, que es la misma empresa que creó Ubuntu y que tiene una participación abrumadora de sistemas operativos en el mercado de la nube.\nGoogle y AWS (entre otros) son ejemplos de empresas que utilizan cloud-init para que las máquinas virtuales estén disponibles para sus clientes.\nCuando usamos kubernetes o máquinas virtuales en Google, por ejemplo, es posible visualizar el cloud-init config utilizado por ellos, que entre nosotros, ¡es una tremenda de cloud-init config!\n¿Algunos ejemplos de por qué usar cloud-init en Proxmox? # VRapidez en la creación de nuevas VM\nControl de IPs de VM como si fueran un contenedor LXC\nPosibilidades de automatización\nCompatibilidad con Ansible y otras herramientas de automatización\nComo este artículo se está creando como una documentación simple del proceso, vayamos directamente al grano para que podamos validar mejor lo que hace este cloud-init.\n¡Desplegando cloud-init en proxmox! ¡Manos a la obra! # Lo primero, lee la documentación oficial de Proxmox + cloud-init:\nhttps://pve.proxmox.com/wiki/Cloud-Init_Support\nEn segundo lugar, lea al menos la introducción a la https://cloudinit.readthedocs.io/en/latest/\n¡¡Atención!! ¡¡Atención!! # La documentación oficial de proxmox comienza con un tema: Preparación de plantillas Cloud-Init y esto confunde a la multitud.\nLas imágenes de cloud-init están listas y podemos usarlas sin tener que preparar nada. Esto es solo para personas que necesitan crear sus cloud-init templates from scratch.\nDownload de imagen # Elegí la imagen de ubuntu en honor a Canonical, que puso a disposición el proyecto, por lo que el crédito es para ellos: https://cloud-images.ubuntu.com/groovy/current/\nTenga en cuenta que tanto el formato \u0026ldquo;img\u0026rdquo; como la arquitectura \u0026ldquo;amd64\u0026rdquo; son compatibles con Proxmox. Ahora elija cualquier node de su clúster proxmox para hospedar el template y acceda a el a través de ssh:\n# wget https://cloud-images.ubuntu.com/groovy/current/groovy-server-cloudimg-amd64.img # qm create 9002 --memory 2048 --net0 virtio,bridge=vmbr1 Ahora vea en /etc/pve/storage.cfg en qué storage desea almacenar esta imagen. En este caso usaré el storage local:\n# qm importdisk 9002 groovy-server-cloudimg-amd64.img local Successfully imported disk as ‘unused0:local:9002/vm-9002-disk-0.raw’ # qm set 9002 --scsihw virtio-scsi-pci --scsi0 local:9002/vm-9002-disk-0.raw update VM 9002: -scsi0 local:9002/vm-9002-disk-0.raw -scsihw virtio-scsi-pci Ya casi hemos terminado. Ahora tenemos que agregar e discos que es donde almacenaremos las configs personalizadas (en términos generales).\n# qm set 9002 --ide2 local:cloudinit update VM 9002: -ide2 local:cloudinit Formatting ‘/var/lib/vz/images/9002/vm-9002-cloudinit.qcow2’, fmt=qcow2 cluster_size=65536 preallocation=metadata compression_type=zlib size=4194304 lazy_refcounts=off refcount_bits=16 Arreglando el orden de boot:\n# qm set 9002 --boot c --bootdisk scsi0 Algunas imágenes amd64 cloud-init se crean teniendo en cuenta la compatibilidad con openstack. Entonces tenemos que agregar serial0 para que comience. En caso de que tenga curiosidad, elimine serial0 e intente reiniciar, si no arranca, agréguelo nuevamente y todo funcionará:\n# qm set 9002 --serial0 socket --vga serial0 update VM 9002: -serial0 socket -vga serial0 Copie su clave ssh pública en el servidor proxmox, para que podamos agregar esta clave al template del cloud-init:\n[user_machine ~$] scp ~/.ssh/id_rsa.pub root@PROXMOX_NODE:/tmp Volviendo al servidor proxmox:\n# qm set 9002 --sshkey /tmp/id_rsa.pub update VM 9002: -sshkeys ssh-rsa%20AAAAB3NzaC1yc2EAAAADAQABAAABgQC4LX1HAmPWW4qzmqUBsIvgbdlfDS5MKEVK5cpXRxmUErezgVfvodbGlqqnO0T61Dry3KRg1owq62wpH1z8d%2Bh6vZCsJKoyoklC55xlbJgGDSxEB0%2FbUMiwqWkFdjRwQ1V2HOYNJKttoBUFIQvG8V3XSDtw%2Fw3W0aNOAfnheZX10zMJ%2BCuisMkvGGCBRDwnxxi%2BJoeTGrx85yLYfdD6Ca6yba6KeTMcu5PoI1BH5%2Bvt2Ta90BGjyHpLUOZpoqV0AurTEJIO3n5J0z2OH9WhC77Kwz6mG3MSNueA1BcgRUVvaXvJB65ce2azSVcKbXNkTbeBFlc7FhocEAhXrycRR0L6xgo3acvoCBOx4EijtF0itjzqfvNhH9tN9oLj8Qxiz6ttGivzucfWBsc30pUDopWGaJ0syNFE0Wyvs03cDMHb%2F5Vmb8ixE%2BK2nDJe3OXyn%2Bp4GzkWNyVZjYxutg%2FLAFP6bwe6Oe1jSob4I0bA4xT7guHLp93zEqWHRjDFGhXewhk%3D%20USER%40MACHINE%0 Establezca el usuario que tendrá permiso sudo:\n# qm set 9002 --ciuser gole update VM 9002: -ciuser gole Configure el tipo de máquina. Valioso consejo de Tomas 2w-consultoria.\n# qm set 9002 --machine q35 update VM 9002: -machine q35 Finalmente, conviértelo en un template:\n# qm template 9002 Haciendo un clon y usando la nueva VM # Finalmente, clone el template en una nueva máquina:\n# qm clone 9002 139 --name VMNAME --full Configure la ip que usará:\n# qm set 139 --ipconfig0 ip=172..xxx.xxx.5/24,gw=172.xxx.xxx.1 Cambie el tamaño del disco a un tamaño que ocupará en esta máquina virtual:\n# qm resize 139 scsi0 +45G Image resized. Encienda la VM:\n# qm start 139 Espere a que se inicie y ejecute ssh desde la máquina que tenía la clave pública:\n$ ssh -l gole 172.xxx.xxx.5 ¡Bingo! ¡Dentro del servidor sin hacer ninguna instalación!\nPuede configurar vlans, DNS y todo lo que su nueva VM necesita para funcionar. También puede personalizar cloud-init con cicustom. Echa un vistazo a la documentación oficial.\nCuando cloud-init sube por primera vez, instalará algunos paquetes, por lo que el primer arranque tarda un poco más en liberar apt.\n¡Éxito!\n","date":"6 de enero de 2019","externalUrl":null,"permalink":"/blog/es/posts/cloud-init-sin-virtual-proxmox-6/cloud-init-sin-entorno-virtual-proxmox-6/","section":"Posts","summary":"","title":"Cloud-init no Proxmox Virtual Environment 6","type":"posts"},{"content":"","date":"julio 6, 2019","externalUrl":null,"permalink":"/blog/en/authors/mauricio-santan/","section":"Authors","summary":"","title":"Mauricio-Santan","type":"authors"},{"content":"","externalUrl":null,"permalink":"/blog/es/series/","section":"Series","summary":"","title":"Series","type":"series"}]