-
Notifications
You must be signed in to change notification settings - Fork 131
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #72 from fredpena/main
[Translation] Spanish - Chapter 3
- Loading branch information
Showing
7 changed files
with
745 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,61 @@ | ||
| # Capitulo 3: Pipelines de servicios: Construcción de aplicaciones nativas en la nube | ||
|
|
||
| — | ||
| _🌍 Disponible | ||
| en_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md) | [Español](README-es.md) | ||
| > **Nota:** Presentado por la fantástica comunidad | ||
| > de [ 🌟 contribuidores](https://github.com/salaboy/platforms-on-k8s/graphs/contributors) cloud-native! | ||
| --- | ||
|
|
||
| Estos breves tutoriales cubren tanto Tekton como Dagger para pipelines de servicios. Con Tekton, extendemos las API de | ||
| Kubernetes para definir nuestros Pipelines y tareas. Con Dagger, definimos programáticamente los Pipelines que pueden | ||
| ejecutarse de forma remota en Kubernetes o localmente en nuestras laptops de desarrollo. Finalmente, se proporciona un | ||
| enlace a un conjunto de GitHub Actions para poder comparar entre estos diferentes enfoques. | ||
|
|
||
| - [Tutorial de Tekton para pipelines de servicios](tekton/README-es.md) | ||
| - [Tutorial de Dagger para pipelines de servicios](dagger/README-es.md) | ||
| - [GitHub Actions](github-actions/README-es.md) | ||
|
|
||
| ## Limpiar | ||
|
|
||
| Si desea deshacerse del KinD Cluster creado para estos tutoriales, puede ejecutar: | ||
|
|
||
| ```shell | ||
| kind delete clusters dev | ||
| ``` | ||
|
|
||
| ## Próximos pasos | ||
|
|
||
| Recomiendo encarecidamente seguir los tutoriales listados para Tekton y Dagger en tus entornos locales. Si tienes | ||
| experiencia en desarrollo, puedes extender los pipelines de Dagger con tus propios pasos personalizados. | ||
|
|
||
| Si no eres un desarrollador de Go, ¿te atreverías a construir un pipeline para tu stack tecnológico usando Tekton y | ||
| Dagger? | ||
|
|
||
| Si tienes una cuenta en un registro de contenedores, como una cuenta de Docker Hub, puedes intentar configurar las | ||
| credenciales para que los pipelines puedan enviar las imágenes de contenedores al registro. Luego puedes usar el Helm | ||
| Chart `values.yaml` para consumir las imágenes desde tu cuenta en lugar de las oficiales alojadas | ||
| en `docker.io/salaboy`. | ||
|
|
||
| Finalmente, puedes hacer un fork del repositorio `salaboy/platforms-on-k8s` en tu propio usuario (organización) de | ||
| GitHub para probar con la ejecución de los GitHub Actions ubicadas en este | ||
| directorio. [../../.github/workflows/](../../.github/workflows/). | ||
|
|
||
| ## Resumir y contribuir | ||
|
|
||
| En estos tutoriales, experimentamos con dos enfoques completamente diferentes para pipelines de servicios. Comenzamos | ||
| con [Tekton](https://tekton.dev), un motor de pipelines sin opiniones que fue diseñado para ser nativo de Kubernetes, | ||
| aprovechando el | ||
| poder declarativo de las API de Kubernetes y los bucles de reconciliación de Kubernetes. Luego | ||
| probamos [Dagger](https://dagger.io), un motor | ||
| de pipelines diseñado para orquestar contenedores y que se puede configurar utilizando tu stack tecnológico favorito a | ||
| través de sus SDKs. | ||
|
|
||
| Una cosa es segura, no importa qué motor de pipelines elija tu organización, los equipos de desarrollo se beneficiarán | ||
| enormemente al poder consumir pipelines de servicios sin la necesidad de definir cada paso, credenciales y detalles de | ||
| configuración. Si el equipo de plataforma puede crear pasos/tareas compartidos o incluso pipelines predeterminados para | ||
| tus servicios, los desarrolladores pueden centrarse en escribir código de aplicación. | ||
|
|
||
| ¿Quieres mejorar este tutorial? Crea un issue, envíame un mensaje en [Twitter](https://twitter.com/salaboy) o envía un | ||
| Pull Request. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,147 @@ | ||
| # Dagger en Acción | ||
|
|
||
| En este breve tutorial, examinaremos los Pipelines de Servicios de Dagger proporcionados para construir, probar, | ||
| empaquetar y publicar cada servicio. Estos pipelines están implementados en Go utilizando el SDK de Dagger para Go y se | ||
| encargan de construir cada servicio y crear un contenedor. Se proporciona un pipeline separado para construir y publicar | ||
| el Helm Chart de la aplicación. | ||
|
|
||
| ## Requisitos | ||
|
|
||
| Para ejecutar estos pipelines localmente, necesitarás: | ||
|
|
||
| - [Instalando Go](https://go.dev/doc/install) | ||
| - [Un runtime de contenedores como (Docker) ejecutándose localmente](https://docs.docker.com/get-docker/) | ||
|
|
||
| Para ejecutar los pipelines de forma remota en un clúster de Kubernetes, puedes usar [KinD](https://kind.sigs.k8s.io/) o | ||
| cualquier clúster de Kubernetes que tengas disponible. | ||
|
|
||
| ## Vamos a ejecutar algunos pipelines | ||
|
|
||
| Dado que todos los servicios son muy similares, la misma definición de pipeline se puede usar y parametrizar para | ||
| construir cada servicio por separado. | ||
|
|
||
| Puedes clonar este repositorio y, desde el [directorio de la Aplicación de Conferencia](../../conference-application/), | ||
| ejecutar los pipelines localmente. | ||
|
|
||
| Puedes ejecutar cualquier tarea definida dentro del archivo `service-pipeline.go`: | ||
|
|
||
| ```shell | ||
| go mod tidy | ||
| go run service-pipeline.go build <SERVICE DIRECTORY> | ||
| ``` | ||
|
|
||
| Las siguientes tareas están definidas para todos los servicios: | ||
|
|
||
| - `build`: Construye el código fuente del servicio y crea un contenedor para él. Este espera como argumento el | ||
| directorio del servicio que queremos construir. | ||
| - `test`: Prueba el servicio, pero primero iniciará todas las dependencias del servicio (contenedores necesarios para | ||
| ejecutar la prueba). Este espera como argumento el directorio del servicio que queremos probar. | ||
| - `publish`: Publica la imagen de contenedor creada en un registro de contenedores. Esto requiere que estés autenticado | ||
| en el registro de contenedores y que proporciones el nombre de la etiqueta utilizada para la imagen del contenedor. | ||
| Este espera como argumentos el directorio del servicio que queremos construir y publicar, así como la etiqueta | ||
| utilizada para marcar el contenedor antes de enviarlo. | ||
|
|
||
| Si ejecutas `go run service-pipeline.go all notifications-service v1.0.0-dagger`, todas las tareas se ejecutarán. Antes | ||
| de poder ejecutar todas las tareas, deberás asegurarte de que tienes todos los requisitos previos establecidos, ya que | ||
| para publicar en un Registro de Contenedores necesitarás proporcionar credenciales apropiadas. | ||
|
|
||
| Puedes ejecutar de manera segura `go run service-pipeline.go build notifications-service`, lo cual no requiere que | ||
| configures ninguna credencial. Puedes configurar tu registro de contenedores y nombre de usuario utilizando variables de | ||
| entorno, por ejemplo: | ||
|
|
||
| ```shell | ||
| CONTAINER_REGISTRY=<YOUR_REGISTRY> CONTAINER_REGISTRY_USER=<YOUR_USER> go run service-pipeline.go publish notifications-service v1.0.0-dagger | ||
| ``` | ||
|
|
||
| Esto requiere que estés autenticado en el registro donde deseas publicar tus imágenes de contenedor. | ||
|
|
||
| Ahora, para fines de desarrollo, esto es bastante conveniente, ya que puedes construir el código de tu servicio de la | ||
| misma manera en que lo hará tu sistema de CI (Integración Continua). Pero no quiere ejecutar en producción imágenes de | ||
| contenedor que se crearon en la laptop de un desarrollador, ¿verdad? | ||
|
|
||
| La siguiente sección muestra una configuración simple para ejecutar pipelines de Dagger de forma remota dentro de un | ||
| clúster de Kubernetes. | ||
|
|
||
| ## Ejecutando tus pipelines de forma remota en Kubernetes | ||
|
|
||
| El Motor de Pipelines de Dagger puede ejecutarse en cualquier lugar donde puedas ejecutar contenedores, lo que significa | ||
| que puede funcionar en Kubernetes sin la necesidad de configuraciones complicadas. | ||
|
|
||
| Para este tutorial, necesitas tener un clúster de Kubernetes. Puedes crear uno | ||
| usando [KinD, como hicimos en el Capítulo 2](../../chapter-2/README-es.md#creando-un-clúster-local-con-kubernetes-kind). | ||
|
|
||
| En este breve tutorial, ejecutaremos los pipelines que estábamos ejecutando localmente con nuestro runtime de | ||
| contenedores local, ahora de forma remota contra un Motor de Pipelines de Dagger que se ejecuta dentro de un Pod de | ||
| Kubernetes. Esta es una característica experimental y no es la forma recomendada de ejecutar Dagger, pero nos ayuda a | ||
| demostrar el concepto. | ||
|
|
||
| Ejecutemos el Motor de Pipelines de Dagger dentro de Kubernetes creando un Pod con Dagger: | ||
|
|
||
| ```shell | ||
| kubectl run dagger --image=registry.dagger.io/engine:v0.3.13 --privileged=true | ||
| ``` | ||
|
|
||
| Alternativamente, puedes aplicar `chapter-3/dagger/k8s/pod.yaml` utilizando el manifiesto | ||
|
|
||
| ```shell | ||
| kubectl apply -f chapter-3/dagger/k8s/pod.yaml | ||
| ``` | ||
|
|
||
| Verifica que el pod `dagger` esté en ejecución: | ||
|
|
||
| ```shell | ||
| kubectl get pods | ||
| ``` | ||
|
|
||
| Deberías ver algo como esto: | ||
|
|
||
| ```shell | ||
| NAME READY STATUS RESTARTS AGE | ||
| dagger 1/1 Running 0 49s | ||
| ``` | ||
|
|
||
| **Nota**: Esto está lejos de ser ideal porque no estamos configurando ningún mecanismo de persistencia o replicación | ||
| para Dagger | ||
| en sí; todos los mecanismos de caché son volátiles en este caso. Consulta la documentación oficial para obtener más | ||
| información al respecto. | ||
|
|
||
| Ahora, para ejecutar los pipelines de tus proyectos contra este servicio remoto, solo necesitas exportar la siguiente | ||
| variable de entorno: | ||
|
|
||
| ```shell | ||
| export _EXPERIMENTAL_DAGGER_RUNNER_HOST=kube-pod://<podname>?context=<context>&namespace=<namespace>&container=<container> | ||
| ``` | ||
|
|
||
| Donde `<podname>` es `dagger` (porque creamos el pod manualmente), `<context>` es el contexto de tu clúster de | ||
| Kubernetes. Si estás ejecutando contra un clúster KinD, este podría ser `kind-dev`. Puedes encontrar el nombre de tu | ||
| contexto actual ejecutando `kubectl config current-context`. Finalmente, `<namespace>` es el namespace en el que | ||
| ejecutas el contenedor de Dagger, y `<container>` es nuevamente dagger. Para mi configuración contra KinD, esto se vería | ||
| así: | ||
|
|
||
| ```shell | ||
| export _EXPERIMENTAL_DAGGER_RUNNER_HOST="kube-pod://dagger?context=kind-dev&namespace=default&container=dagger" | ||
| ``` | ||
|
|
||
| Nota también que mi clúster KinD (llamado `kind-dev`) no tenía nada relacionado con Pipelines. | ||
|
|
||
| Ahora, si ejecutas en cualquiera de los proyectos: | ||
|
|
||
| ```shell | ||
| go run service-pipeline.go build notifications-service | ||
| ``` | ||
|
|
||
| O para probar tu servicio de forma remota: | ||
|
|
||
| ```shell | ||
| go run service-pipeline.go test notifications-service | ||
| ``` | ||
|
|
||
| En una pestaña separada, puedes seguir los logs del motor de Dagger ejecutando: | ||
|
|
||
| ```shell | ||
| kubectl logs -f dagger | ||
| ``` | ||
|
|
||
| La construcción ocurrirá de forma remota dentro del clúster. Si estuvieras ejecutando esto contra un clúster de | ||
| Kubernetes remoto (no KinD), no necesitarías tener un runtime de contenedores local para construir tus servicios y sus | ||
| contenedores. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| # GitHub Actions en Acción | ||
|
|
||
| Utilizando GitHub Actions, podemos automatizar nuestros Pipelines de Servicio sin necesidad de ejecutar ninguna | ||
| infraestructura. Todos los pipelines/workflows se ejecutarán en la infraestructura de GitHub.com, lo que, a gran | ||
| escala (cuando comiencen a cobrar), puede volverse muy costoso. | ||
|
|
||
| Puedes encontrar los Pipelines de Servicio para la Aplicación de Conferencia definidos aquí: | ||
|
|
||
| - [Pipeline de Servicio para el Servicio de Agenda en GH](../../.github/workflows/agenda-service-service-pipeline.yaml) | ||
| - [Pipeline de Servicio para el Servicio C4P en GH](../../.github/workflows/c4p-service-service-pipeline.yaml) | ||
| - [Pipeline de Servicio para el Servicio de Notificaciones en GH](../../.github/workflows/notifications-service-service-pipeline.yaml) | ||
|
|
||
| Estos pipelines utilizan un filtro para activarse únicamente si el código fuente del servicio | ||
| cambia [paths-filter](https://github.com/dorny/paths-filter). | ||
|
|
||
| Para construir y publicar los contenedores de cada servicio, estos pipelines | ||
| utilizan `ko-build` [setup-ko](https://github.com/ko-build/setup-ko) para generar | ||
| contenedores multiplataforma para nuestras aplicaciones Go. | ||
|
|
||
| Para publicar en Docker Hub, se utiliza la acción `docker/login-action@v2`, la cual requiere la configuración de dos | ||
| `Secrets` (`secrets.DOCKERHUB_USERNAME`, `secrets.DOCKERHUB_TOKEN`), que permiten a los pipelines realizar el push | ||
| de los contenedores a mi cuenta de Docker Hub. |
Oops, something went wrong.