Ir al contenido
Todos los artículos

Imágenes Docker para Windchill: qué entra y qué no

Una imagen que se construye una vez y se promociona sin cambios es la base de un Windchill en contenedores. Así decidimos qué debe ir dentro.

2 min de lecturaDockerKubernetes

La primera pregunta de cualquier proyecto Windchill en contenedores no es qué clúster usar, sino qué debe contener la imagen. Si se acierta, todo lo demás, de los pipelines a los rollbacks, se simplifica. Si no, se acaba con una imagen por entorno y las mismas desviaciones que había en las máquinas virtuales.

La regla: construir una vez, configurar al desplegar

Una imagen debe ser idéntica en pruebas y en producción. Todo lo que difiere entre entornos se inyecta al arrancar el contenedor, nunca se incluye en la imagen.

Dentro de la imagen:

  • La instalación de Windchill en una versión y un nivel de parches conocidos
  • Sus personalizaciones compiladas, generadas por el pipeline a partir de un commit etiquetado
  • El runtime que requiere la versión, y nada más
  • Un script de arranque que lee la configuración del entorno y espera a sus dependencias

Fuera de la imagen:

  • Nombres de host, URL y propiedades específicas de cada sitio, aportados como variables de entorno o ficheros montados
  • Contraseñas, claves y certificados, leídos de un almacén de secretos como Azure Key Vault
  • Vaults, logs y demás datos que deben sobrevivir a un contenedor, en volúmenes persistentes
  • La base de datos, que se ejecuta como servicio gestionado o en servidores dedicados

Una imagen, varios roles

Windchill no es un único proceso. Los front ends web, los method servers, las colas en segundo plano y la búsqueda tienen funciones y necesidades de escalado distintas. Construimos una sola imagen y la arrancamos con roles diferentes, de modo que todos los componentes ejecutan con garantía el mismo código.

Health checks que dicen la verdad

Kubernetes solo puede sustituir un contenedor averiado si sabe que lo está. Que el proceso esté en marcha no basta: nuestras readiness probes llaman a la aplicación y confirman que puede atender una petición, para que el tráfico solo llegue a los pods realmente preparados.

Etiquetar las imágenes como releases

Cada imagen se etiqueta con la versión de la release y el commit del que se construyó, nunca solo con latest. Cuando algo falla a las tres de la madrugada, la primera pregunta es qué se está ejecutando, y la etiqueta debe responderla.

Antes de empezar

Compruebe la postura de soporte de PTC sobre los despliegues en contenedores para su versión, y planifique cómo se harán las copias de seguridad y la restauración de la base de datos y del almacenamiento de los vaults. Los contenedores cambian la forma de desplegar Windchill; no cambian lo que necesita para estar a salvo.

Siguiente paso

Muéstrenos su Windchill. Le mostraremos el pipeline.

Cuéntenos su versión, su arquitectura y ese cambio que siempre se aplaza. En una semana recibirá un plan por escrito con alcance, equipo y calendario.