Dans tout projet de conteneurisation de Windchill, la première question n’est pas de savoir quel cluster utiliser. C’est de savoir ce que l’image doit contenir. Si ce choix est bon, tout le reste, des pipelines aux rollbacks, devient simple. S’il est mauvais, vous vous retrouvez avec une image par environnement et la même dérive qu’avec les machines virtuelles.
La règle : builder une fois, configurer au déploiement
Une image doit être identique en recette et en production. Tout ce qui diffère d’un environnement à l’autre est injecté au démarrage du conteneur, jamais figé dans l’image.
Dans l’image :
- L’installation Windchill, à une version et un niveau de patch connus
- Vos personnalisations compilées, buildées par le pipeline à partir d’un commit tagué
- Le runtime requis par la version, et rien d’autre
- Un script de démarrage qui lit la configuration depuis l’environnement et attend ses dépendances
Hors de l’image :
- Noms d’hôtes, URL et propriétés propres au site, fournis en variables d’environnement ou en fichiers montés
- Mots de passe, clés et certificats, lus depuis un coffre de secrets comme Azure Key Vault
- Vaults, logs et autres données qui doivent survivre au conteneur, sur des volumes persistants
- La base de données, exécutée en service managé ou sur des serveurs dédiés
Une image, plusieurs rôles
Windchill n’est pas un processus unique. Front-ends web, method servers, files d’attente en arrière-plan et recherche ont des rôles et des besoins de montée en charge différents. Nous construisons une seule image et la démarrons dans différents rôles : chaque composant exécute ainsi forcément le même code.
Des health checks qui disent la vérité
Kubernetes ne peut remplacer un conteneur défaillant que s’il sait qu’il l’est. Un processus en cours d’exécution ne suffit pas : nos readiness checks appellent l’application et vérifient qu’elle peut servir une requête, pour que le trafic n’atteigne que les pods réellement prêts.
Taguer les images comme des releases
Chaque image est taguée avec le numéro de release et le commit dont elle est issue, jamais simplement latest. Quand quelque chose casse à 3 h du matin, la première question est de savoir ce qui tourne, et le tag doit y répondre.
Avant de commencer
Vérifiez la position de support de PTC pour les déploiements conteneurisés de votre version, et prévoyez comment la base de données et le stockage des vaults seront sauvegardés et restaurés. Les conteneurs changent la façon dont Windchill est déployé ; ils ne changent pas ce dont il a besoin pour rester sûr.