1. Antes de comenzar
Configuración del entorno de autoaprendizaje
- Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.
- El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una string de caracteres que no se utiliza en las API de Google y se puede actualizar en cualquier momento.
- El ID del proyecto debe ser único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). Cloud Console genera automáticamente una string única, que, por lo general, no importa cuál sea. En la mayoría de los codelabs, debes hacer referencia al ID del proyecto (suele ser
PROJECT_ID
). Por lo tanto, si no te gusta, genera otro aleatorio o prueba con uno propio y comprueba si está disponible. Después de crear el proyecto, este ID se “congela” y no se puede cambiar. - Además, hay un tercer valor, el Número de proyecto, que usan algunas API. Obtén más información sobre estos tres valores en la documentación.
- A continuación, deberás habilitar la facturación en Cloud Console para usar las API o los recursos de Cloud. Ejecutar este codelab no debería costar mucho, tal vez nada. Si quieres cerrar los recursos para no se te facture más allá de este instructivo, sigue las instrucciones de “limpieza” que se encuentran al final del codelab. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de USD 300.
2. Preparando tu espacio de trabajo
- Visita la siguiente URL para abrir el editor de Cloud Shell
https://ide.cloud.google.com
- Asegúrate de que el nombre de tu proyecto esté configurado en la CLI
gcloud config set project {{project-id}}
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
- Habilita las APIs
gcloud services enable \
cloudbuild.googleapis.com \
secretmanager.googleapis.com
- Proporcionar derechos a CloudDeploy
gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/clouddeploy.admin ${PROJECT_ID}
gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/container.developer ${PROJECT_ID}
gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/iam.serviceAccountUser ${PROJECT_ID}
gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/clouddeploy.jobRunner ${PROJECT_ID}
- En la ventana de la terminal, clona la fuente de la aplicación con el siguiente comando:
git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git
- Cambia al directorio y configura el lugar de trabajo del IDE en la raíz del repositorio.
cd software-delivery-workshop && rm -rf .git
cd delivery-platform && cloudshell workspace .
3. Usa plantillas de apps predefinidas y personalizadas
Los desarrolladores deben poder elegir entre un conjunto de plantillas que se usan comúnmente en la organización. El proceso de integración creará un conjunto centralizado de repositorios de plantillas almacenados en tu cuenta de GitHub. En pasos posteriores, estos repositorios de plantillas se copiarán y modificarán para usarlos como base de aplicaciones nuevas. En este lab, propagarás tu repositorio de plantillas con una estructura de muestra que se proporciona aquí. Para agregar tus propias plantillas, agrega carpetas adicionales basadas en el modelo del ejemplo.
En este paso, crearás tu propio repositorio para contener plantillas de apps a partir de los archivos de ejemplo proporcionados. Se proporciona una secuencia de comandos auxiliar para simplificar las interacciones con GitHub.
Estos son pasos únicos que se usan para propagar tus repositorios de plantillas. Los pasos futuros reutilizarán estos repositorios.
Configura el acceso a GitHub
Los pasos de este instructivo llaman a la API de GitHub para crear y configurar repositorios. En varios puntos a continuación, se requerirá tu nombre de usuario de GitHub y un token de acceso personal. La siguiente secuencia de comandos te ayudará a adquirir los valores y almacenarlos como variables locales para usarlos más adelante.
source ./onboard-env.sh
echo Git Username: $GIT_USERNAME
echo Git Base URL: $GIT_BASE_URL
Crea un repositorio de plantillas de apps
Junto con este lab, se proporcionan plantillas de aplicación de muestra para ejemplificar cómo podrías integrar tus propias plantillas base. En este paso, crearás tu propia copia de estos archivos en un repositorio llamado mcd-app-templates
en tu cuenta de GitHub.
- Copia la plantilla en el directorio de trabajo
cp -R $BASE_DIR/resources/repos/app-templates $WORK_DIR
cd $WORK_DIR/app-templates
- Crea un repositorio remoto vacío en tu cuenta de GitHub
$BASE_DIR/scripts/git/gh.sh create mcd-app-templates
- Envía el repositorio de plantillas a tu repositorio remoto
git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"
git remote add origin $GIT_BASE_URL/mcd-app-templates
git push origin main
- Limpia el directorio de trabajo
cd $BASE_DIR
rm -rf $WORK_DIR/app-templates
Crea un repositorio de configuraciones básicas compartidas
En este instructivo, se usa una herramienta llamada Kustomize que emplea archivos de configuración base que comparten varios equipos y, luego, superpone configuraciones específicas de la aplicación. Esto permite que los equipos de la plataforma se expandan a muchos equipos y entornos.
En este paso, crearás el repositorio de configuración compartido llamado mcd-shared_kustomize
a partir de las muestras proporcionadas.
- Copia la plantilla en el directorio de trabajo
cp -R $BASE_DIR/resources/repos/shared-kustomize $WORK_DIR
cd $WORK_DIR/shared-kustomize
- Crea un repositorio remoto vacío en tu cuenta de GitHub
$BASE_DIR/scripts/git/gh.sh create mcd-shared_kustomize
- Envía el repositorio de plantillas a tu repositorio remoto
git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"
git remote add origin $GIT_BASE_URL/mcd-shared_kustomize
git push origin main
- Limpia el directorio de trabajo
cd $BASE_DIR
rm -rf $WORK_DIR/shared-kustomize
Con los repositorios de plantillas creados, puedes usarlos para crear una instancia de app.
4. Cómo crear una instancia nueva de una aplicación
A menudo, crear una aplicación nueva a partir de una plantilla requiere que las variables de marcador de posición se cambien por valores reales en varios archivos de la estructura de la plantilla. Una vez que se completa la sustitución, se crea un repositorio nuevo para la nueva instancia de la app. Los desarrolladores clonarán este repositorio de instancias de la app y trabajarán con él en su desarrollo diario.
En este paso, sustituirás valores en una plantilla de app y publicarás los archivos resultantes en un repositorio nuevo.
Define un nombre para la aplicación nueva
export APP_NAME=my-app
Recupera el repositorio de plantillas de Golang
cd $WORK_DIR/
git clone -b main $GIT_BASE_URL/mcd-app-templates app-templates
rm -rf app-templates/.git
cd app-templates/golang
Sustituye valores de marcadores de posición
Una de las necesidades más comunes de la integración es reemplazar las variables en las plantillas por instancias reales que se usan en la aplicación. Por ejemplo, proporcionar el nombre de la aplicación. El siguiente comando crea instancias de todos los archivos .tmpl con los valores almacenados en las variables de entorno.
for template in $(find . -name '*.tmpl'); do envsubst < ${template} > ${template%.*}; done
Crea un repositorio nuevo y almacena los archivos actualizados
- Crea un repositorio remoto vacío en tu cuenta de GitHub
$BASE_DIR/scripts/git/gh.sh create ${APP_NAME}
- Envía el repositorio de plantillas a tu repositorio remoto
git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"
git remote add origin $GIT_BASE_URL/${APP_NAME}
git push origin main
Ahora que se creó la instancia de la app, es momento de implementar compilaciones continuas.
5. Cómo configurar la ejecución de canalización automatizada
La parte central de un sistema de integración continua es la capacidad de ejecutar la lógica de la canalización en función de los eventos que se originan en el sistema de control de código fuente. Cuando un desarrollador confirma código en su repositorio, se activan eventos que se pueden configurar para activar procesos en otros sistemas.
En este paso, configurarás GitHub para que llame a Google Cloud Build y ejecute tu canalización cada vez que los usuarios confirmen o etiqueten código en su repositorio.
Habilitar acceso seguro
Necesitarás 2 elementos para configurar el acceso seguro a tu canalización de aplicaciones. Una clave de API y un secreto únicos para la canalización
Clave de API
La clave de API se usa para identificar al cliente que llama a una API determinada. En este caso, el cliente será GitHub. Una práctica recomendada que no se aborda aquí es restringir el alcance de la clave de API solo a las APIs específicas a las que el cliente accederá. Creaste la clave en un paso anterior.
- Para revisar la clave, haz clic en este vínculo.
- Para asegurarte de que se haya establecido el valor, ejecuta el siguiente comando:
echo $API_KEY_VALUE
Secreto de la canalización
Los Secrets se usan para autorizar a un emisor y garantizar que tenga los derechos del trabajo de destino específico de Cloud Build. Es posible que tengas 2 repositorios diferentes en GitHub que solo deberían tener acceso a sus propias canalizaciones. Si bien API_KEY limita las APIs que puede usar GitHub (en este caso, se llama a la API de Cloud Build), los secretos limitan qué trabajo en la API de Cloud Build puede ejecutar el cliente.
- Define el nombre, la ubicación y el valor del secreto
SECRET_NAME=${APP_NAME}-webhook-trigger-cd-secret
SECRET_PATH=projects/${PROJECT_NUMBER}/secrets/${SECRET_NAME}/versions/1
SECRET_VALUE=$(sed "s/[^a-zA-Z0-9]//g" <<< $(openssl rand -base64 15))
- Crea el secreto
printf ${SECRET_VALUE} | gcloud secrets create ${SECRET_NAME} --data-file=-
- Permitir que Cloud Build lea el secreto
gcloud secrets add-iam-policy-binding ${SECRET_NAME} \
--member=serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com \
--role='roles/secretmanager.secretAccessor'
Crea un activador de Cloud Build
El activador de Cloud Build es la configuración que ejecutará los procesos de CI/CD.
El trabajo requiere que se proporcionen algunos valores clave en el momento de la creación para configurar el activador de manera correcta.
- Define el nombre del activador y dónde se puede encontrar el archivo de configuración
export TRIGGER_NAME=${APP_NAME}-clouddeploy-webhook-trigger
export BUILD_YAML_PATH=$WORK_DIR/app-templates/golang/build/cloudbuild-cd.yaml
- Define la ubicación del repositorio de configuración base compartido.
export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize
- Se estableció una variable en la secuencia de comandos onboard-env.sh que define el registro de contenedores del proyecto. Revisa el valor con el siguiente comando.
echo $IMAGE_REPO
- Crea el activador de webhook de CloudBuild con las variables que creaste antes. La ubicación del repositorio de la aplicación se extrae del cuerpo de la solicitud de GitHub. Un valor a continuación hace referencia a la ruta en el cuerpo de la solicitud en la que se encuentra
gcloud alpha builds triggers create webhook \
`--name=${TRIGGER_NAME} \` `--substitutions='_APP_NAME='${APP_NAME}',_APP_REPO=$(body.repository.git_url),_CONFIG_REPO='${GIT_BASE_URL}'/'${CLUSTER_CONFIG_REPO}',_DEFAULT_IMAGE_REPO='${IMAGE_REPO}',_KUSTOMIZE_REPO='${GIT_BASE_URL}'/'${SHARED_KUSTOMIZE_REPO}',_REF=$(body.ref)' \` `--inline-config=$BUILD_YAML_PATH \` `--secret=${SECRET_PATH}`
- Visita este vínculo para revisar el activador de Cloud Build que creaste recientemente en la consola.
- Define una variable para la URL del extremo que GitHub usará en el siguiente paso.
WEBHOOK_URL="https://cloudbuild.googleapis.com/v1/projects/${PROJECT_ID}/triggers/${TRIGGER_NAME}:webhook?key=${API_KEY_VALUE}&secret=${SECRET_VALUE}"
Configura el webhook de GitHub
- Configura el webhook en GitHub
$BASE_DIR/scripts/git/gh.sh create_webhook ${APP_NAME} $WEBHOOK_URL
- Ve al repositorio de la aplicación y revisa el webhook recién configurado.
REPO_URL=${GIT_BASE_URL}/${APP_NAME}/settings/hooks
echo $REPO_URL
Ahora que realizaste manualmente todos los pasos necesarios para crear una aplicación nueva, es hora de automatizarla en una secuencia de comandos.
6. Automatiza todos los pasos de integración
En la práctica, no es factible ejecutar cada uno de los pasos anteriores para cada aplicación nueva. En su lugar, la lógica debe incorporarse en una secuencia de comandos para facilitar la ejecución. Los pasos anteriores ya se incluyeron en un guion para que lo uses.
En este paso, usarás la secuencia de comandos proporcionada para crear una aplicación nueva.
Crear una nueva aplicación
- Asegúrate de estar en el directorio correcto
cd $BASE_DIR
- Crear una nueva aplicación
export APP_NAME=demo-app
./app.sh create ${APP_NAME}
Todos los pasos se ejecutan de forma automática.
Revisa el repositorio de GitHub
En este punto, podrás revisar el nuevo repositorio en GitHub.
- Ejecuta el siguiente comando para recuperar la URL del repositorio de GitHub:
echo ${GIT_BASE_URL}/demo-app
- Abre la URL con tu navegador web para revisar la nueva aplicación.
- Ten en cuenta los ejemplos en los que las variables de plantilla se reemplazaron por valores de instancia, como se muestra en la siguiente URL.
echo ${GIT_BASE_URL}/demo-app/blob/main/k8s/prod/deployment.yaml#L24
- Revisa el webhook configurado en la siguiente URL.
echo ${GIT_BASE_URL}/demo-app/settings/hooks
Revisa el activador de CloudBuild
La secuencia de comandos configuró automáticamente el activador
- Visita este vínculo para revisar el activador de Cloud Build en la consola.
- Revisa el historial de compilaciones en esta página.