Como seguimiento del blog. https://blogs.sap.com/2023/02/02/sap-cpi-ci-cd-from-from-zero-to-hero/, Recibí comentarios muy valiosos de que debería probar el proyecto Piper.

Quería probar piper en Kyma, dado que ya tenemos nuestras canalizaciones y bibliotecas compartidas personalizadas, así que seguí esta opción con la esperanza de poder tener tanto a piper como a nuestras canalizaciones trabajando en el mismo contenedor, por lo que creo que es lo más valioso. escenario para nuestro equipo.

Piper documentación (https://www.project-piper.io/infraestructura/overview/) cataloga la implementación en kubernetes como experimental, así que asegúrese de probarla correctamente si está usando esto como su entorno productivo. También un descargo de responsabilidad: no soy ningún experto en Kyma o Piper (fue mi primera exposición a ambos), así que tal vez tuve un mal viaje debido a la falta de conocimiento, lo cual es justo. Sin embargo, creo que todo el proceso podría documentarse mejor, así que espero que este blog llame la atención para que alguien pueda contribuir a mejorar la documentación en un procedimiento paso a paso.

1.er intento: usar un gráfico de timón en desuso

Verificó la documentación oficial que apunta al uso de gráficos de timón para instalarlo en Kyma. Según tengo entendido, los gráficos de timón son solo recetas altamente configurables para importar todos los recursos de kyma/kubernetes a través de archivos yaml. Luego puede anular los valores durante la instalación desde gráficos a través de la línea de comandos o mediante un archivo de anulación adicional.

Instalación oficial de piper en la documentación de kubernetes

Si sigue el enlace para el gráfico de timón, accederá a una página con un repositorio de github en desuso. El gráfico de helm obsoleto tiene un valor Master.Image que puede proporcionar, pero no pude determinar la URL de este repositorio obsoleto para agregarlo a través de «helm add repo piperofficial «. Si sabes la respuesta déjamelo saber en los comentarios. No me concentré mucho en esto ya que el gráfico de timón estaba marcado como obsoleto de todos modos, así que me mudé al nuevo.

2do intento: usar la nueva tabla de timón oficial

Si sigue el enlace al nuevo gráfico de timón, llegará aquí (https://github.com/jenkinsci/helm-charts). Pude agregar el repositorio con comando

helm repo add jenkins https://charts.jenkins.io

luego para instalarlo a través de

 .\helm.exe install devops jenkins/jenkins --set namespaceOverride=piper

Luego, tuve que crear una regla API para exponer el servicio que se generó pero que pude autenticar. Problema: La imagen es la imagen estándar de jenkins/jenkins sin piper lib instalada. Si además de esto tuviera que instalar todos los complementos de jenkins y piper lib manualmente, sería demasiado esfuerzo, así que eliminé todo y lo intenté de nuevo, pero esta vez anulando la imagen y la etiqueta del gráfico de helm a la de piper.

 .\helm.exe install devops jenkins/jenkins --set namespaceOverride=piper --set controller.image=ppiper/jenkins-master --set controller.tag=latest

Todo se desplegó pero la cápsula no arrancó… ¿Por qué?

Registro de pod de Jenkins

Los registros del pod mencionan problemas con las dependencias del complemento jenkins… Lo último que quiero tratar es con las discrepancias de la versión de las dependencias. Por lo que entiendo, la imagen de la ventana acoplable ppiper/jenkins-master y jenkins/jenkins (para los que se preparó el gráfico de helm) usan diferentes versiones de tiempo de ejecución de Jenkins y tienen diferentes complementos instalados, lo cual es normal, pero me llevó a concluir que esto no funcionaría sin una más profunda busque resolver estos problemas de dependencias/versiones/compatibilidad. Si ha encontrado una manera sencilla de hacerlo a través de este enfoque, hágame saber qué pasos ha seguido en los comentarios.

3er intento: créalo desde cero

Renuncié a usar la documentación oficial y la única solución que me funcionó fue crearla desde cero en Kyma. A continuación, puede encontrar los artefactos que he creado (he usado una implementación con un ReplicaSet que tiene un volumen en el hogar de jenkins que apunta a PersistentVolumeClaims en lugar de usar el enfoque StatefulSet que usa el gráfico de timón).

apiVersion: v1
kind: Namespace
metadata:
    name: piper
    labels:
        app.kubernetes.io/name: piper
        istio-injection: enabled
        kubernetes.io/metadata.name: piper
spec:
  finalizers:
    - kubernetes
status:
  phase: Active
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: piperpvc
  namespace: piper
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
    name: piperapp
    namespace: piper
    labels:
        app: piperapp
spec:
  replicas: 1
  selector:
    matchLabels:
      templatename: piperapp
  template:
    metadata:
      labels:
        templatename: piperapp
        app: piperapp
    spec:
      containers:
        - name: pipercontainer
          image: ppiper/jenkins-master
          resources: {}
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: Always
          volumeMounts:
           - name: jenkins-volume
             mountPath: /var/jenkins_home
      volumes:
        - name: jenkins-volume
          persistentVolumeClaim:
             claimName: piperpvc
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst
      schedulerName: default-scheduler
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600
---
kind: Service
apiVersion: v1
metadata:
  name: piperappserv
  namespace: piper
  labels:
    app: piperapp
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  selector:
    app: piperapp
  type: ClusterIP
  sessionAffinity: None
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  internalTrafficPolicy: Cluster
status:
  loadBalancer: {}
---
apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
  finalizers:
    - gateway.kyma-project.io/subresources
  labels:
    app: piperapp
  name: piperapirule
  namespace: piper
spec:
  gateway: kyma-gateway.kyma-system.svc.cluster.local
  host: piperapihost
  rules:
    - accessStrategies:
        - config: {}
          handler: noop
      methods:
        - GET
        - POST
        - PUT
        - DELETE
        - OPTIONS
        - PATCH
      path: /.*
  service:
    name: piperappserv
    port: 80

Para aplicarlo, suponiendo que tiene un archivo llamado fullaml.yaml con el contenido anterior, simplemente ejecute:

kubectl apply -f fullyaml.yaml

Probé esta imagen y pude ejecutar comandos piper y forzar la terminación de los pods para garantizar que se guardó el estado.

Jenkins con Piper trabajando en Kyma

Pude ejecutar Piper IntegrationArtifactDeploy y funcionó sin problemas. Ahora, si quiero usar nuestras bibliotecas compartidas actuales con el enfoque de acciones de github, necesitaría:

1. Divida nuestras bibliotecas compartidas en pequeñas piezas individuales que se pueden ejecutar por separado (esto sería mucho trabajo y tendría como resultado al menos 10 veces más archivos de los que tengo ahora). Problema: nuestras bibliotecas compartidas realizan muchas operaciones (leer, escribir y comprimir archivos, analizar jsons o tablas de delegación, crear copias de seguridad en el sistema operativo). No estoy seguro de cómo juntar todo esto a través de la canalización de github sin convertirme en un archivo monstruo. Tendría que ser escupido de una manera muy inteligente para encapsular muchos de estos comandos de bajo nivel.
2. Déjalos como están (haciendo toda la lógica dentro de ellos). Esto sería más fácil ya que la acción de github solo haría referencia a cada biblioteca compartida (una para respaldo, otra para documentación, otra para prueba, etc.). El archivo de tubería de github sería más limpio, por otro lado, el potencial de reutilización podría disminuir (no todos quieren sincronizar con crisol, por ejemplo).

Próximos pasos

• Dele una oportunidad al servicio CI/CD BTP y vea qué tan bien podemos integrarlo con nuestras propias canalizaciones en un uso avanzado de este servicio
• Continúe evaluando el beneficio potencial de usar piper en lugar de las canalizaciones regulares de jenkins que ya tenemos (en este momento tengo serias dudas de que valdría la pena el esfuerzo de migración)
• Estaba pensando que sería genial si pudiera aprovisionar todo de forma automatizada, lo que significa habilitar el tiempo de ejecución de Kyma, obtener el archivo kubeconfig y aplicar un gráfico de timón o un archivo yaml (como el de arriba) en un proceso completamente automatizado sin intervención del usuario. He comprobado el automatizador de configuración de BTP (https://github.com/SAP-samples/btp-setup-automator). En las preguntas frecuentes, puede encontrar una referencia a Kyma (https://github.com/SAP-samples/btp-setup-automator/blob/main/docs/FAQ.md) donde se menciona que debido a kubelogin, necesitaría abrir un navegador, por lo que lo más probable es que necesite dividirlo en dos procesos y hacer este paso manualmente en el medio, lo cual no es tan bueno. Si tuviste alguna historia de éxito tratando de hacer esto, házmelo saber.

Conclusión

Como puede ver, mi viaje de instalación no fue fácil, no estoy seguro si se debió a mi falta de conocimiento sobre Kyma, a la documentación que no era tan buena o a ambos. Para ser justos, pude usarlo en las instalaciones con el servidor cx, que también es el enfoque recomendado, pero estaba pensando que si invertimos en migrar a piper, también deberíamos deshacernos de los costos de mantenimiento de nuestro servidor en las instalaciones. No estoy seguro de si hay una forma de usar el servidor cx en Kyma. Si tienes experiencia con eso por favor comenta.