Skip to content
All insights

Containers for Windchill: what goes in, what stays out

A package that is built once and promoted unchanged is the foundation of a containerized Windchill. Here is how we decide what belongs inside it.

2 min readContainersCloud

The first question in any Windchill container project is not which platform to use. It is what the container image should contain. Get that right and everything downstream, from pipelines to rollbacks, becomes simple. Get it wrong and you end up with a different image per environment and the same drift you had on virtual machines.

The rule: build once, configure at deploy time

An image should be identical in test and production. Anything that differs between environments is supplied when the container starts, never built in.

Inside the image:

  • The Windchill installation at a known release and patch level
  • Your compiled customizations, built by the pipeline from a tagged version
  • The runtime the release requires, and nothing else
  • A start script that reads its settings from the environment and waits for the services it depends on

Outside the image:

  • Hostnames, addresses and site-specific settings, supplied when the container starts
  • Passwords, keys and certificates, read from a secure secret store
  • File vaults, logs and other data that must outlive a container, on persistent storage
  • The database, which runs as a managed service or on dedicated servers

One image, several roles

Windchill is not one process. Web front ends, background services, queues and search have different jobs and different scaling needs. We build one image and start it in different roles, so every component is guaranteed to run the same code.

Health checks that tell the truth

A platform can only replace a broken container if it knows it is broken. A process that is running is not enough: our checks call the application and confirm it can serve a request, so traffic only reaches instances that are actually ready.

Label images like releases

Every image is labelled with the release version and the exact source it was built from, never just “latest”. When something goes wrong at 3 a.m., the first question is what is running, and the label should answer it.

Before you start

Check PTC’s support position for containerized deployments of your release, and plan how the database and vault storage will be backed up and restored. Containers change how Windchill is deployed; they do not change what it needs to stay safe.

Next step

Show us your Windchill. We will show you the pipeline.

Send us your release, your landscape and the change that keeps getting postponed. Within a week you get a written plan with scope, team and timeline.