Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Guía de incorporación e implementación

Los desarrolladores recurren a docker pull. Es rápido, funciona y la cuestión de seguridad puede esperar. Los equipos de operaciones recurren a helm install con contenido verificado de registros de confianza, porque desplegar de forma segura en Kubernetes es su trabajo. Entre estos dos flujos de trabajo hay una brecha que genera fricción, deuda de seguridad y sorpresas de última hora.

El Acceso para Desarrolladores de SUSE Rancher cierra esta brecha. Trae Kubernetes y contenido de confianza directamente al entorno local del desarrollador, con una sobrecarga cognitiva mínima. El clúster local está impulsado por Rancher Desktop y su motor K3s, una distribución de Kubernetes ligera y de calidad de producción que también sirve como el motor embebido en RKE2. Desde la primera línea de código, el desarrollo local se ejecuta en el mismo entorno de ejecución y el mismo contenido que la producción.

1. Activación de la suscripción

La activación de su suscripción de Acceso para Desarrolladores de SUSE Rancher es necesaria antes de que pueda acceder al registro OCI de confianza en dp.apps.rancher.io.

1.1. Activando su suscripción

Después de comprar una suscripción o iniciar una prueba gratuita, su contacto principal recibirá un correo electrónico de cumplimiento que contiene un Código de Registro de 14 caracteres.

Procedimiento: Activando su acceso

  1. Inicie sesión en el SUSE Customer Center.

  2. En la barra lateral, navegue a Mis Herramientas y seleccione Activar Suscripciones.

  3. Introduzca su Código de Registro en el campo proporcionado.

  4. Asocie la suscripción con su organización y haga clic en Activar.

  5. Una vez completado, verifique que SUSE Rancher Developer Access aparezca como activo en la pestaña Suscripciones.

1.2. Cuentas de usuario y tokens de acceso

El acceso de desarrollador de SUSE Rancher se asigna a cuentas de usuario individuales.

  • Ámbito: Estas cuentas son estrictamente para desarrollo, pruebas y prototipos. No están autorizadas para cargas de trabajo en producción. Para requisitos de producción, contacte con el equipo de ventas de SUSE o consulte la documentación de SUSE Rancher Prime.

  • Tokens de acceso: La autenticación en el registro se gestiona a través de tokens de acceso. Puede crear múltiples tokens para diferentes entornos (por ejemplo, una estación de trabajo local y un entorno de desarrollo remoto), pero todos los tokens están vinculados a su única cuenta de usuario autorizada.

  • Cuentas de servicio: Este nivel de suscripción no incluye cuentas de servicio, que son necesarias para herramientas automatizadas como pipelines de CI/CD. Si su flujo de trabajo requiere automatización, contacte a SUSE para obtener detalles sobre Rancher Prime.

Procedimiento: Generando un token

  1. Inicie sesión en apps.rancher.io utilizando sus credenciales de SCC.

  2. Navegue a la sección Tokens de acceso de su perfil.

  3. Haga clic en Crear, proporcione una descripción y copie el token inmediatamente. No se mostrará de nuevo.

2. Entorno local: Rancher Desktop

Rancher Desktop proporciona un clúster de Kubernetes local y un motor de contenedores. Es una aplicación independiente, y la que esta guía utiliza para ejecutar contenido de confianza de SUSE Rancher Developer Access.

2.1. Selección del motor de contenedores

Durante la configuración, debe seleccionar un motor de contenedores. Independientemente de su elección, el comportamiento de sus aplicaciones y del clúster de Kubernetes permanece idéntico, haciendo que ambas opciones sean una base sólida para la paridad en producción. K3s, el motor que impulsa el clúster local, es una distribución de Kubernetes ligera de calidad de producción y el motor embebido en el núcleo de RKE2. El clúster que se ejecuta localmente se comporta igual que cualquier distribución de Kubernetes basada en containerd en producción.

La elección del motor de contenedores afecta cómo interactúa con el entorno local, no cómo opera el clúster en sí:

  • Moby (Docker Engine): Esta es la opción sugerida para la mayoría de los desarrolladores. Ofrece la máxima compatibilidad con herramientas de terceros populares como Tilt, Dev Containers y Testcontainers.

  • containerd (nerdctl): Esta opción está destinada a usuarios que deseen interactuar con el clúster local utilizando los mismos patrones que un administrador de clúster, mediante la CLI de nerdctl.

3. La extensión de interfaz de usuario de la Colección de Aplicaciones de SUSE para Rancher Desktop

La extensión de interfaz de usuario de la Colección de Aplicaciones de SUSE para Rancher Desktop automatiza la autenticación del registro, crea el secreto de extracción de Kubernetes requerido y proporciona una interfaz gráfica para explorar, instalar y configurar aplicaciones de la Colección de Aplicaciones de SUSE.[1]

3.1. Instalación y configuración de la extensión

  1. Instale la extensión a través de la pestaña de Extensiones en Rancher Desktop.

  2. Abra la extensión y acceda a Configuración.

  3. Introduzca su nombre de usuario de SCC y el token de acceso generado en la Sección 1.2.

  4. Haga clic en Guardar Credenciales.

Una vez configurada, la extensión realiza automáticamente las siguientes operaciones:

  • Inicio de sesión en el registro: Inicia sesión en dp.apps.rancher.io para su motor de contenedores seleccionado, permitiendo la descarga autenticada de imágenes desde la CLI.

  • Inyección de secreto de descarga: Crea un imagePullSecret de Kubernetes llamado application-collection en su espacio de nombres predeterminado. Un imagePullSecret almacena credenciales de registro como un objeto de Kubernetes, permitiendo que el clúster descargue imágenes de registros autenticados sin configuración manual.

  • Configuración de Helm: Configura el cliente local de Helm para resolver el repositorio OCI de confianza.

Todos los gráficos de Helm en la Colección de Aplicaciones de SUSE exponen un parámetro global estándar imagePullSecrets. Al instalar un gráfico manualmente, establezca este parámetro en [application-collection] para asegurar que todas las dependencias del gráfico se descarguen utilizando las credenciales correctas.

La extensión de la interfaz de usuario actualmente proporciona una interfaz para aplicaciones disponibles como gráficos de Helm. Su suscripción también otorga acceso a una vasta biblioteca de imágenes de contenedores independientes (imágenes base, pilas de lenguajes, herramientas de CLI, y más) que aún no se han mostrado en la extensión. Visite apps.rancher.io para explorar el catálogo completo.

[^1]: La extensión también es compatible con Docker Desktop.

4. Por qué el contenido de confianza es importante

Las imágenes de contenedores públicas no se mantienen con la exposición a CVE como prioridad. Utilizar la Colección de Aplicaciones de SUSE en su lugar puede reducir el conteo total de vulnerabilidades de un proyecto de pila completa de varios miles a menos de 50.

4.1. Pilas de lenguajes e imágenes base

Contenedores de lenguajes o base no verificados pueden introducir miles de vulnerabilidades en su proyecto antes de que haya escrito una sola línea de código. Las imágenes populares de registros públicos están construidas para conveniencia, no para seguridad. No se mantienen sistemáticamente para minimizar la exposición a CVE. Las pilas de lenguaje de la Colección de Aplicaciones de SUSE se construyen sobre SLE BCI, una capa base mínima que SUSE mantiene y parchea activamente. Las vulnerabilidades heredadas se reducen significativamente en todos los entornos de ejecución soportados, incluyendo Node.js, Go, OpenJDK y muchos otros. 4.2. Aplicaciones y Middleware Lo mismo se aplica a las aplicaciones de las que depende su pila. Una imagen de middleware ampliamente utilizada de un registro público puede llevar fácilmente cientos de CVEs, no porque el software en sí sea inseguro, sino porque la imagen se construye sobre una amplia capa base y rara vez se mantiene para seguir las actualizaciones de dependencias. Las imágenes de la Colección de Aplicaciones de SUSE utilizan dependencias mínimas y seleccionadas, y se parchean activamente — un enfoque diferente a la composición de imágenes, no al parcheo diferido — lo que reduce consistentemente el conteo de vulnerabilidades a una fracción de lo que llevan los equivalentes públicos.

5. Ejemplo de Flujo de Trabajo del Desarrollador: Iteración Rápida en el Bucle Interno

5.1. Desarrollo en Vivo con Tilt y VS Code

Esta sección describe un patrón basado en Tilt y VS Code, dos herramientas de terceros populares, como un ejemplo práctico entre muchos.

El objetivo es un bucle interno ágil: edite el código localmente, y el cambio se refleja de inmediato en un contenedor en ejecución en su clúster local de Rancher Desktop, sin reconstrucción manual, sin envío a un registro remoto, sin re-desplegar desde cero.

Rancher Desktop permite esto a través de su Almacén de Imágenes Local. Cuando Tilt construye una imagen, la envía directamente al almacén utilizado por K3s, eludiendo completamente el registro remoto. Guardar un archivo en VS Code activa una sincronización de Tilt, que actualiza el contenedor en ejecución en segundos. La aplicación, construida sobre imágenes base de la Colección de Aplicaciones de SUSE, se comporta exactamente como lo hará en producción: mismo tiempo de ejecución containerd, mismo entorno de Kubernetes.

Las aplicaciones con estado se ajustan bien a este patrón. Dependencias como PostgreSQL o un intermediario de mensajes pueden desplegarse como charts de Helm de confianza en el clúster local una vez, mientras que el contenedor de la aplicación se actualiza continuamente. Toda la pila se ejecuta localmente y sin dependencias externas.

Para una guía completa de configuración y una implementación de referencia funcional, consulte el repositorio de demostración de Acceso para Desarrolladores de Rancher.

6. Mejores Prácticas y Consejos

6.1. Fijar Versiones y Usar Imágenes Base de Confianza

La colección de aplicaciones de SUSE no soporta la etiqueta :latest. Siempre fija tus Dockerfile y charts de Helm a las versiones y etiquetas de revisión específicas que se encuentran en apps.rancher.io. Esto asegura que tu entorno permanezca reproducible y elimina la desviación de versiones entre desarrollo y producción.

Siempre utiliza imágenes base del registro de confianza:

FROM dp.apps.rancher.io/containers/suse-bci-base:15.7

6.2. Consejos para desarrolladores nuevos en Kubernetes

Kubernetes introduce conceptos que no tienen un equivalente directo en un flujo de trabajo solo con Docker. Algunos ajustes facilitan la transición:

  • Reenvío de puertos a través de Ingress: Utiliza la interfaz de usuario de reenvío de puertos de Rancher Desktop para exponer servicios del clúster en host local con un solo clic. Configurar un controlador de Ingress para el desarrollo local es una sobrecarga innecesaria.

  • Espacios de nombres: El imagePullSecret creado por la extensión se inyecta en el espacio de nombres default. Si despliegas cargas de trabajo en otros espacios de nombres, también necesitarás crear el secreto allí o configurar tus charts para referenciarlo explícitamente.

  • Registros y estado: Utiliza kubectl logs <pod> y kubectl describe pod <pod> como tus primeras herramientas de diagnóstico. La mayoría de los problemas durante el desarrollo local (fallos en la extracción de imágenes, bucles de fallo, variables de entorno mal configuradas) son visibles de inmediato allí.

  • Conciencia del contexto: Rancher Desktop se registra como un contexto de kubectl. Si trabajas con múltiples clústeres, verifica tu contexto activo con kubectl config current-context antes de ejecutar comandos.

Conclusión

El acceso para desarrolladores de SUSE Rancher proporciona a los equipos de desarrollo el mismo tiempo de ejecución y el mismo contenido de confianza que se ejecutará en producción, disponible desde el primer día de un proyecto. Al automatizar la autenticación del registro y preconfigurar el entorno local, se elimina la fricción que típicamente se acumula entre el desarrollo y el despliegue, sin requerir que los desarrolladores se conviertan en expertos en Kubernetes.