Nuestro invitado, Pantheon, creador de herramientas para desarrolladores, nos habla sobre cómo automatizar las implementaciones. WordPress Utilizando GitLab CI/CD.
В Trabajo en el área de relaciones con desarrolladores, así que siempre estoy buscando nuevas formas de ayudarlos. WordPress и Drupal Resuelvo problemas de automatización en los flujos de trabajo. Para ello, me encanta experimentar con nuevas herramientas y combinarlas para lograr una mayor eficiencia.
A menudo veo desarrolladores que luchan con un único servidor provisional.
Es un placer esperar tu turno para usar un servidor intermedio o enviar a los clientes una URL con la nota: "Mira aquí, pero no mires aquí todavía".
- una de las herramientas geniales de Pantheon - resuelve este problema, porque con ella puedes crear entornos para ramas de Git bajo demanda. Cada entorno multidev tiene su propia URL y base de datos, por lo que los desarrolladores pueden trabajar tranquilamente, comprobar la calidad y obtener aprobación sin pisarse unos a otros.
Pero Pantheon no tiene herramientas para el control de versiones o la integración e implementación continuas (CI/CD). Pero es una plataforma flexible con la que puedes integrar cualquier herramienta.
También noté que los equipos usan ciertas herramientas para el desarrollo y otras diferentes para el ensamblaje y la implementación.
Por ejemplo, tienen diferentes herramientas para control de versiones y CI/CD. Tienes que trastear y cambiar entre herramientas para editar código y diagnosticar problemas.
En hay un conjunto completo de herramientas de desarrollo: para control de versiones, tickets, solicitudes de fusión, el mejor canal de CI/CD de su clase, un registro de contenedores y todo eso. Todavía no me he encontrado con una aplicación que ofrezca tanto para gestionar su flujo de trabajo de desarrollo.
Me encanta la automatización, así que aprendí a conectar Pantheon a GitLab para que los compromisos con la rama principal de GitLab se implementen en el entorno de desarrollo principal de Pantheon. Y las solicitudes de fusión en GitLab pueden crear e implementar código en entornos multidev en Pantheon.
En esta guía, te mostraré cómo configurar una conexión entre GitLab y Pantheon y optimizar tu flujo de trabajo. WordPress и Drupal.
Por supuesto que es posible , pero haremos todo lo posible con las manos para profundizar en y en el futuro utilizar esta herramienta no sólo para la implementación.
introducción
Para esta publicación, debes comprender que Pantheon divide cada sitio en tres elementos: código, base de datos y archivos.
El código incluye archivos CMS como el núcleo, los complementos y los temas. WordPressEstos archivos se gestionan en , alojado en Pantheon, lo que significa que podemos implementar código de GitLab en Pantheon con Git.
Los archivos en Pantheon son archivos multimedia, es decir, imágenes del sitio. Normalmente los suben los usuarios y Git los ignora.
, encuentra mas sobre o en pantheon.io.
Suposiciones
Mi proyecto en Pantheon y GitLab se llama pantheon-gitlab-blog-demoEl nombre del proyecto debe ser único. Trabajaremos con un sitio web. WordPressTú también puedes tomarlo Drupalpero habrá que cambiar algunas cosas.
usaré y puedes trabajar en , si quieres.
crear un proyecto
Primero, creemos (volveremos a esto más adelante).
Ahora Luego lo instalamos. WordPress para el panel de control del sitio web.
Si tiene ganas de cambiar algo, por ejemplo, eliminar o agregar complementos, tenga paciencia. El sitio aún no está conectado a GitLab y queremos que todos los cambios de código se realicen a través de GitLab.
¿Cuándo lo instalaremos? WordPress, regresa al panel de control del sitio web de Pantheon y cambia el modo de desarrollo a Git.
Compromiso inicial en GitLab
Ahora debes transferir el código inicial. WordPress Desde el sitio web de Pantheon a GitLab. Para ello, clonamos el código del repositorio Git del sitio web de Pantheon localmente y luego lo subimos al repositorio de GitLab.
Para hacerlo más fácil y seguro, y no tendremos que introducir una contraseña cada vez que clonemos un repositorio Pantheon Git. Al mismo tiempo ya .
Para hacer esto, clone el sitio de Pantheon localmente copiando el comando del campo Clonar con Git en el panel del sitio.
Si necesitas ayuda, lee la documentación. .
ahora cambiemos git remote originpara apuntar a GitLab en lugar de Pantheon. Se puede hacer .
Vayamos al proyecto GitLab y copiemos la URL del repositorio del menú desplegable Clonar en la página de detalles del proyecto. Elijamos la opción Clonar con SSH, porque ya hemos configurado la clave SSH.
Por defecto git remote para una copia local del repositorio de código - origin. Esto se puede cambiar c git remote set-url origin [URL репозитория GitLab], donde en lugar de corchetes ingresamos la URL real.
Finalmente, lanzamos git push origin master --forcepara enviar el código WordPress del sitio Pantheon en GitLab.
La opción –force sólo se necesita una vez. Luego en equipos
git pushno estará en GitLab.
Configurar credenciales y variables
¿Recuerdas cómo agregamos una clave SSH localmente para iniciar sesión en Pantheon y GitLab? El token SSH se puede utilizar para autorizar GitLab y Pantheon.
GitLab tiene una excelente documentación. Vamos a ver .
Ahora completaremos los dos primeros pasos: Creemos un nuevo par de claves SSH localmente con ssh-keygen y agreguemos la clave privada como una variable al proyecto..
Entonces preguntaremos SSH_PRIVATE_KEY cómo en la configuración del proyecto.
En el tercer y cuarto paso crearemos un archivo. .gitlab-ci.yml con contenido como este:
before_script:
# See https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
- mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
- git config --global user.email "$GITLAB_USER_EMAIL"
- git config --global user.name "Gitlab CI"No confirmemos el archivo todavía. .gitlab-ci.yml, entonces tendrás que agregarle algo más.
Ahora realizamos el quinto paso y agregue la clave pública que creó en el primer paso a los servicios a los que necesita acceder en el entorno de compilación.
En nuestro caso, queremos acceder a Pantheon desde GitLab. Seguimos las instrucciones del documento del Panteón sobre y realice este paso.
Recuerde: el SSH privado está en GitLab, el SSH abierto está en Pantheon.
Configuremos algunas variables de entorno más. El primero se llama PANTHEON_SITE. Su valor es el nombre del sitio Pantheon en su máquina.
El nombre de la máquina aparece al final del comando Clonar con Git. Ya has clonado el sitio localmente, por lo que este será el nombre del directorio del repositorio local.
A continuación, configuremos la variable de entorno. PANTHEON_GIT_URL. Esta es la URL del repositorio de Git para el sitio Pantheon que ya hemos utilizado.
Ingrese solo la URL del repositorio SSH, sin
git cloney el nombre del sitio en la máquina al final.
Uf. Eso está hecho, ahora podemos terminar nuestro archivo. .gitlab-ci.yml.
Crear una tarea de implementación
Lo que haremos inicialmente con GitLab CI es muy similar a lo que hemos hecho con los repositorios de Git en el pasado. Pero esta vez, agreguemos el repositorio de Pantheon como una segunda fuente remota de Git y luego enviemos el código de GitLab a Pantheon.
Para hacer esto, configuremos deploy и deploy:dev, porque lo implementaremos en el entorno de desarrollo de Pantheon. El archivo resultante .gitlab-ci.yml Se parece a esto:
stages:
- deploy
before_script:
# See https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
- mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
- git config --global user.email "$GITLAB_USER_EMAIL"
- git config --global user.name "Gitlab CI"
deploy:dev:
stage: deploy
environment:
name: dev
url: https://dev-$PANTHEON_SITE.pantheonsite.io/
script:
- git remote add pantheon $PANTHEON_GIT_URL
- git push pantheon master --force
only:
- masterVariables SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL debería parecer familiar: configuramos estas variables de entorno anteriormente. Con estas variables podremos utilizar los valores del archivo. .gitlab-ci.yml muchas veces y solo será necesario actualizarlos en un solo lugar.
Finalmente, agregue, confirme y envíe el archivo. .gitlab-ci.yml en GitLab.
Comprobando el despliegue
Si hicimos todo correctamente, la tarea deploy:dev se ejecutará correctamente en GitLab CI/CD y enviará una confirmación .gitlab-ci.yml en el Panteón. Echemos un vistazo.
Envío de hilos de solicitud de fusión a Pantheon
Aquí usaremos mi función favorita de Pantheon: , donde puede crear entornos Pantheon adicionales para sucursales de Git a pedido.
, por lo que esta sección se puede omitir. Pero si tiene acceso, puede aumentar seriamente la productividad configurando la creación automática de entornos multidev en Pantheon a partir de solicitudes de fusión de GitLab.
Primero, creemos una nueva rama de Git localmente usando git checkout -b multidev-support. Ahora cambiemos algo nuevamente en .gitlab-ci.yml.
Me gusta incluir el número de solicitud de fusión en el nombre del entorno de Pantheon. Por ejemplo, la primera solicitud de fusión es mr-1, segundo - mr-2 etc
La solicitud de fusión cambia, por lo que debemos determinar dinámicamente los nombres de las sucursales de Pantheon. Es fácil en GitLab: solo necesitas usar .
Podemos tomar $CI_MERGE_REQUEST_IIDpara especificar el número de solicitud de fusión. Apliquemos todo esto junto con las variables de entorno global que especificamos anteriormente y agreguemos una nueva tarea de implementación:multidev al final del archivo. .gitlab-ci.yml.
deploy:multidev:
stage: deploy
environment:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Checkout the merge request source branch
- git checkout $CI_COMMIT_REF_NAME
# Add the Pantheon git repository as an additional remote
- git remote add pantheon $PANTHEON_GIT_URL
# Push the merge request source branch to Pantheon
- git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
only:
- merge_requestsSerá similar a nuestra tarea. deploy:dev, sólo la sucursal se envía a Pantheon, no a master.
Hemos agregado y confirmado el archivo actualizado. .gitlab-ci.yml, y ahora impulsemos una nueva rama a GitLab con git push -u origin multidev-support.
Ahora creemos una nueva solicitud de fusión desde la rama. multidev-supporthaciendo click Crear solicitud de fusión.
Después de crear una solicitud de fusión, observamos cómo se ejecuta la tarea CI/CD. deploy:multidev.
Mira, se ha enviado un nuevo hilo a Pantheon. Pero si vamos a la sección multidev en el panel del sitio de Pantheon, no veremos el nuevo entorno allí.
Veamos la sección Ramas de Git.
Como resultado, nuestro hilo mr-1 Llegó al Panteón. Creemos un entorno desde una sucursal. mr-1.
Hemos creado un entorno multidev, ahora volvamos a GitLab y veamos la sección Operaciones > Entornos. Veremos entradas para dev и mr-1.
Esto se debe a que agregamos una entrada. environment Con nombre name и url en tareas de CI/CD. Si hacemos clic en el icono de entorno abierto, se nos dirigirá a la URL del entorno multidev en Pantheon.
Automatizar la creación de multidev
En principio, puede detenerse aquí y simplemente recordar crear un entorno multidev para cada solicitud de fusión, pero este proceso se puede automatizar.
Pantheon tiene una herramienta de línea de comando , donde podrás trabajar con la plataforma de forma automática. Terminus le permite crear entornos multidev desde la línea de comandos, ideal para .
Necesitamos una nueva solicitud de fusión para probar esto. Creemos una nueva rama usando git checkout -b auto-multidev-creation.
Para usar Terminus en tareas de GitLab CI/CD, necesita un token de máquina para la autenticación con Terminus y una imagen de contenedor con Terminus.
, guárdelo en un lugar seguro y agréguelo como una variable de entorno global en GitLab con el nombre PANTHEON_MACHINE_TOKEN.
Si olvidó cómo agregar variables de entorno de GitLab, regrese a donde definimos
PANTHEON_SITE.
Creando un Dockerfile con Terminus
Si no usas Docker o no te gustan los archivos Dockerfile, toma mi imagen registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest y omita esta sección.
, donde podemos construir y colocar el Dockerfile para nuestro proyecto. Creemos un Dockerfile con Terminus para trabajar con Pantheon.
Terminus es una herramienta de línea de comandos de PHP, así que comencemos con la imagen de PHP. Estoy instalando Terminus a través de Composer, así que usaré . Nosotros creamos Dockerfile en el directorio del repositorio local con el siguiente contenido:
# Use the official Composer image as a parent image
FROM composer:1.8
# Update/upgrade apk
RUN apk update
RUN apk upgrade
# Make the Terminus directory
RUN mkdir -p /usr/local/share/terminus
# Install Terminus 2.x with Composer
RUN /usr/bin/env COMPOSER_BIN_DIR=/usr/local/bin composer -n --working-dir=/usr/local/share/terminus require pantheon-systems/terminus:"^2"Sigue las instrucciones de montaje y envío de imágenes del apartado Crear y enviar imágenes в para recopilar una imagen de Dockerfile y envíelo a GitLab.
Abriendo la sección Registro en el proyecto GitLab. Si todo salió según lo previsto, nuestra imagen estará ahí. Escriba un enlace a la etiqueta de la imagen; lo necesitamos para el archivo .gitlab-ci.yml.
Sección script en el problema deploy:multidev está empezando a crecer, así que movámoslo a un archivo separado. Crear un nuevo archivo private/multidev-deploy.sh:
#!/bin/bash
# Store the mr- environment name
export PANTHEON_ENV=mr-$CI_MERGE_REQUEST_IID
# Authenticate with Terminus
terminus auth:login --machine-token=$PANTHEON_MACHINE_TOKEN
# Checkout the merge request source branch
git checkout $CI_COMMIT_REF_NAME
# Add the Pantheon Git repository as an additional remote
git remote add pantheon $PANTHEON_GIT_URL
# Push the merge request source branch to Pantheon
git push pantheon $CI_COMMIT_REF_NAME:$PANTHEON_ENV --force
# Create a function for determining if a multidev exists
TERMINUS_DOES_MULTIDEV_EXIST()
{
# Stash a list of Pantheon multidev environments
PANTHEON_MULTIDEV_LIST="$(terminus multidev:list ${PANTHEON_SITE} --format=list --field=id)"
while read -r multiDev; do
if [[ "${multiDev}" == "$1" ]]
then
return 0;
fi
done <<< "$PANTHEON_MULTIDEV_LIST"
return 1;
}
# If the mutltidev doesn't exist
if ! TERMINUS_DOES_MULTIDEV_EXIST $PANTHEON_ENV
then
# Create it with Terminus
echo "No multidev for $PANTHEON_ENV found, creating one..."
terminus multidev:create $PANTHEON_SITE.dev $PANTHEON_ENV
else
echo "The multidev $PANTHEON_ENV already exists, skipping creating it..."
fiEl script está en un directorio privado y . Tenemos un script para nuestra lógica multidev. Ahora actualicemos la sección. deploy:multidev expediente .gitlab-ci.ymlpara que quede así:
deploy:multidev:
stage: deploy
environment:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Run the multidev deploy script
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsNecesitamos asegurarnos de que nuestras tareas se realicen en la imagen personalizada creada, así que agreguemos una definición. image desde la URL del registro hasta .gitlab-ci.yml. Como resultado, terminamos con un archivo como este. .gitlab-ci.yml:
image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest
stages:
- deploy
before_script:
# See https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
- mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
- git config --global user.email "$GITLAB_USER_EMAIL"
- git config --global user.name "Gitlab CI"
deploy:dev:
stage: deploy
environment:
name: dev
url: https://dev-$PANTHEON_SITE.pantheonsite.io/
script:
- git remote add pantheon $PANTHEON_GIT_URL
- git push pantheon master --force
only:
- master
deploy:multidev:
stage: deploy
environment:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Run the multidev deploy script
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsAgregar, confirmar y enviar private/multidev-deploy.sh и .gitlab-ci.yml. Ahora regresamos a GitLab y esperamos a que se complete la tarea de CI/CD. Tenga paciencia: la creación de multidev puede tardar varios minutos.
Luego vamos a mirar la lista multidev en Pantheon. ¡Oh milagro! Entorno multidesarrollo mr-2 ya está aquí.
Conclusión
Mi equipo se divirtió mucho más cuando comenzamos a abrir solicitudes de fusión y a crear entornos automáticamente.
Con las potentes herramientas de GitLab y Pantheon, puedes conectar GitLab a Pantheon automáticamente.
Dado que utilizamos GitLab CI/CD, nuestro flujo de trabajo tendrá espacio para crecer. Aquí hay un par de ideas para comenzar:
- Agregue un paso de compilación.
- Agregue pruebas automatizadas.
- Agregue una tarea para garantizar que se cumplan los estándares del código.
- Añadir .
Háganos saber lo que piensa sobre GitLab, Pantheon y la automatización.
PD: ¿Sabías que Terminus, la herramienta de línea de comandos de Pantheon, ?
Nosotros en Pantheon hemos hecho un buen trabajo en la versión 2 de nuestro con soporte de GitLab. Si no quiere molestarse con la configuración de cada proyecto, pruebe este complemento y ayúdenos a probar la versión 2 beta. Para el equipo de Terminus build:project:create Sólo necesitas un token Pantheon y un token GitLab. Implementará uno de los proyectos de muestra con Composer y pruebas automatizadas, creará un nuevo proyecto en GitLab, un nuevo sitio de Pantheon y los conectará mediante variables de entorno y claves SSH.
Acerca del Autor
Andrew Taylor crea herramientas para desarrolladores en .
Fuente: habr.com
