FAQ

Preguntas sobre cómo gestionar Jenkins X

¿Cómo agrego un usuario a mi instalación de Jenkins X?

Jenkins X asume que cada usuario tiene acceso al mismo clúster de desarrollo kubernetes en el que se está ejecutando Jenkins X.

Si su usuario no tiene acceso al clúster de kubernetes, debemos configurar su archivo ~/.kube/config para que pueda acceder a él.

Si está utilizando el GKE de Google, puede navegar por la Consola GKE para ver todos los clústeres y hacer clic en el botón Connect al lado de su clúster de desarrollo y eso le permite copiar/pegar el comando para conectarse al clúster.

Para otros clústeres, estamos planeando escribir algunos comandos CLI para exportar e importar la configuración de kube.

Además, CloudBees está trabajando en una distribución de Jenkins X que incluirá un inicio de sesión único junto con una increíble interfaz de usuario web para visualizar equipos, pipelines, registros, entornos, aplicaciones, versiones e infraestructura. La interfaz de usuario de CloudBees proporciona una manera fácil para que cualquier persona de su equipo inicie sesión en Jenkins X desde la línea de comandos con el botón Connect en la página Teams que utiliza jx login.

Una vez que el usuario tiene acceso al clúster de Kubernetes

Una vez que el usuario tiene acceso al clúster de Kubernetes:

Si Jenkins X fue instalado en el namespace jx, entonces lo siguientes debe ser cambiar su contexto al namespace jx:

$  jx ns jx

Para probar, debe poder escribir:

$  jx get env
$  jx open

Para ver los entornos y cualquier herramienta de desarrollo como las consolas de Jenkins o Nexus.

¿Cómo funciona el control de acceso y la seguridad?

Vea la documentación de control de acceso.

¿Cómo actualizo mi instalación de Jenkins X?

Nuestra estrategia para la instalación, configuración y actualización de Jenkins X es jx boot.

Si está utilizando jx boot puede habilitar las actualizaciones automáticas o hacerlas manualmente.

Si algo va mal durante la actualización (p.ej, si es borrado el clúster, el namespace o Tekton), puede volver a ejecutar el cmando jx boot en su laptop para restaurar el estado del clúster.

De lo contrario, el enfoque anterior es el siguiente:

Si no utiliza boot

Puede actualizar Jenkins X a través del comando jx upgrade. Comience por:

$ jx upgrade cli

para que obtenga la última versión de la sistema CLI, luego actualice la plataforma:

$ jx upgrade platform

¿Cómo actualizo el binario jx usado dentro de las compilaciones cuando uso jenkins sin servidor?

Utilizamos BuildTemplates específicos para diferentes lenguajes de programación. Estas BuildTemplates describen los pasos que se ejecutarán como parte del trabajo, que en el caso de Jenkins X BuildTemplates, todos ejecutan JenkinsfileRunner para ejecutar el Jenkinsfile del proyecto.

$ kubectl get buildtemplates
NAME                        AGE
environment-apply           9d
environment-build           9d
jenkins-base                9d
jenkins-csharp              9d
jenkins-cwp                 9d
jenkins-elixir              9d
jenkins-filerunner          9d
jenkins-go                  9d
jenkins-go-nodocker         9d
jenkins-go-script-bdd       1d
jenkins-go-script-ci        1d
jenkins-go-script-release   1d
jenkins-gradle              9d
jenkins-javascript          9d
jenkins-jenkins             9d
jenkins-maven               9d
jenkins-python              9d
jenkins-rust                9d
jenkins-scala               9d
jenkins-test                9d
knative-chart-ci            9d
knative-chart-release       9d
knative-deploy              9d
knative-maven-ci            9d
knative-maven-release       9d

La imagen Docker que tiene el proceso Jenkinsfile también tiene otras herramientas instaladas, como el binario jx. Si necesita actualizar jx a una versión más nueva, debe modificar el Dockerfile base utilizado para el paso del proceso Jenkinsfile de BuildTemplate, para que use la versión jx que desee. Aunque esto normalmente se hace automáticamente.

Una vez hecho esto, debe cambiar BuildTemplate en su clúster para que comience a usar la nueva versión de la imagen de Docker. Por ejemplo, puede ver la versión actual de esta imagen para Go BuildTemplate en su clúster:

$ kubectl describe buildtemplate jenkins-go | grep Image
Image:       jenkinsxio/jenkins-go:256.0.44

Si desea utilizar una versión diferente que use una versión más nueva de jx, puede cambiar manualmente todas las BuildTemplates, pero en su lugar, vamos a ocuparnos de jx

jx upgrade addon jx-build-templates

Compruebe que se han realizado los cambios:

$ kubectl describe buildtemplate jenkins-go | grep Image
Image:       jenkinsxio/jenkins-go:256.0.50

¿Cómo difiere --prow de --gitops?

  • --prow usa jenkins sin servidor y usa prow para implementar ChatOps en los PRs.
  • --gitops todavía está en progreso, pero usará GitOps para administrar la instalación de Jenkins X (el entorno de desarrollo) para que la instalación de la plataforma se almacene en un repositorio de git y la actualización / adición de aplicaciones / cambio de configuración se cambie a través de PRs como cambios en la promoción de aplicaciones a los entornos de puesta en escena o producción.

¿Cómo reutilizo mi controlador Ingress existente?

De manera predeterminada, cuando instala Jenkins X en un clúster de Kubernetes existente, le pregunta si desea instalar un controlador Ingress. Jenkins X necesita un controlador Ingress de algún tipo para que podamos configurar los recursos Ingress para cada Service para que podamos acceder a las aplicaciones web a través de URL fuera del clúster de Kubernetes (por ejemplo, dentro de los navegadores web).

El comando jx install toma una serie de parámetros CLI que comienzan con --ingress donde puede apuntar el namespace, el deployment y el service del controlador de entrada que desea usar para la instalación.

Si puede, le recomendamos que use el controlador de entrada predeterminado, ya que sabemos que funciona muy bien y solo usa una sola IP de LoadBalancer para todo el clúster (su proveedor de la nube a menudo cobra por dirección IP). Sin embargo, si desea apuntar a un controlador de entrada diferente, simplemente especifique esos argumentos en la instalación:

$ jx install \
  --ingress-service=$(yoursvcname) \
  --ingress-deployment=$(yourdeployname) \
  --ingress-namespace=kube-system

¿Cómo habilito las URL HTTPS?

En general utilizamos el comando jx upgrade ingress.

Para más detalles vea los siguiente documentos:

¿Cómo cambio las URL en un entorno?

Utilizamos exposecontroller para automatizar la configuración de los recursos Ingress para los Servicios expuestos, lo que permite TLS y también inyecta URL externas para servicios en el código (por ejemplo, para que podamos registrar webhooks).

La plantilla UrlTemplate predeterminada para cada entorno tiene la forma: {{.Service}}.{{.Namespace}}.{{.Domain}} donde el Service es el nombre del servicio, Namespace es el espacio de nombres de Kubernetes y Domain está configurado el Dominio DNS

Si desea modificar los esquemas de URL de su servicio en un entorno, edite el fichero env/values.yaml en su repositorio Git de Entornos. Para encontrar las URL de cada repositorio de origen, use el comando jx get env.

Luego, modifique el contenido en env/values.yaml para incluir el valor urlTemplate: de la siguiente manera:

expose:
  config:
    urltemplate: "{{.Service}}-{{.Namespace}}.{{.Domain}}"

Hemos omitido los otros valores de expose: y config: por brevedad; lo importante es asegurarse de que especifique un valor personalizado de expose.config.urltemplate. El valor predeterminado es {{.Service}}.{{.Namespace}}.{{.Domain}} si no se especifica ninguno.

Cada vez que modifique el repositorio de git para un entorno, el pipeline de GitOps se ejecutará para actualizar sus recursos de Ingress para que coincidan con su UrlTemplate.


Preguntas sobre Boot

Preguntas sobre cómo utilizar ‘jx boot’

Problemas comunes

Preguntas sobre problemas comunes configurando Jenkins X.