Les exemples de cette page décrivent des scénarios hypothétiques dans lesquels des parcs illustrent certains concepts et bonnes pratiques présentés dans nos guides. Avant de lire ce guide, vous devez connaître les concepts abordés sur les pages Présentation des parcs et Conditions requises et bonnes pratiques pour les parcs.
Exemple 1 : Parcs avec des ressources de production, de préproduction et de développement
Ce premier exemple porte sur quatre clusters. Deux clusters sont destinés à la production (dans deux régions pour la redondance), un à la préproduction et aux tests, et le dernier au développement. Une équipe en charge de la plate-forme détient et gère l'ensemble des clusters de manière centralisée. Deux services sont présentés dans cet exemple simple : frontend et backend. En revanche, les scénarios plus complexes peuvent nécessiter un plus grand nombre de services et de clusters.
Approche 1 : Séparer les parcs de production, de préproduction et de développement
Pour exploiter des parcs, vous pouvez en créer des distincts pour les ressources de production, de préproduction et de développement.
Pour ce faire, vous créez trois projets hôtes de parc et vous y placez les ressources, ou dans le cas du cluster de développement sur site, vous l'enregistrez dans le projet example-dev. Nous n'avons pas eu à répondre à beaucoup de préoccupations concernant l'uniformité des espaces de noms et des services en raison de la précision de cet exemple. Nous nous sommes néanmoins assurés que les espaces de noms des clusters prod-east et prod-west étaient bien normalisés.
L'avantage de cette approche est que nous disposons d'une isolation très forte entre chacun des parcs. Son principal inconvénient est que nous devons gérer trois parcs différents. Il est donc plus difficile d'assurer la cohérence entre la production, la préproduction et le développement. Pour les équipes de développement, il est également plus difficile de développer des services en préproduction.
Approche 2 : Un parc pour toutes les ressources
Dans cette approche, nous créons un seul parc pour toutes les ressources.
Pour ce faire, nous pouvons laisser les ressources dans le projet example et créer le parc dans ce projet. Nous aurions pu séparer les ressources de production et de préproduction en les plaçant dans d'autres projets hôtes de parc et en utilisant un VPC partagé. Cependant, nous avons choisi de ne pas le faire par souci de simplicité dans cet exemple.
Avec cette approche, nous devons nous assurer que les espaces de noms et les services sont normalisés dans tout le parc. Par exemple, nous avons respectivement renommé le service générique frontend en frontend-prod et frontend-staging dans les clusters de production et de préproduction. Enfin, bien que nous puissions conserver les noms d'origine des espaces de noms de développement, nous les renommons de manière plus claire (par exemple, frontend-dev-alice) pour indiquer qu'il s'agit d'espaces de noms de développement.
Cette approche nous permet de ne pas compromettre l'isolation pour faciliter la gestion. Nous comptons sur l'autorisation du maillage de services pour empêcher les communications indésirables de service à service, mais nous pouvons facilement gérer le système global avec un seul parc. Cette configuration permet d'appliquer des règles à toutes les ressources, ce qui peut donner l'impression que le développement est très semblable à la production.
Approche 3 : Distinguer les parcs de production des parcs hors production
Dans cette approche, nous optons pour une alternative qui associe les ressources de préproduction et de développement à un parc hors production, tout en plaçant la production dans un parc distinct.
Pour ce faire, nous créons deux projets hôtes de parc : l'un pour l'environnement de production, l'autre pour l'environnement hors production. Nous plaçons également les ressources directement dans ces projets, en enregistrant le cluster dev sur site dans le parc hors production. Nous devons normaliser les espaces de noms et les services entre nos ressources de préproduction et de développement pour plus de clarté. Par exemple, nous avons renommé frontend en frontend-staging dans le cluster de préproduction.
L'avantage réside dans le fait que l'environnement de production est isolé de celui hors production. Par exemple, nous pouvons autoriser les services de développement à communiquer avec des services de préproduction, de sorte que le frontend de la développeuse Alice puisse communiquer avec le backend de préproduction pendant le développement de son service.
Résumé
Toutes les approches présentées dans l'exemple 1 sont valides. La méthode choisie par votre organisation dépend de l'isolation et de la cohérence (et de la facilité de gestion), autrement dit du degré d'isolation nécessaire entre les différents types de ressources par rapport au niveau de cohérence requis. Il est plus facile d'assurer la cohérence en utilisant moins de parcs. La troisième approche est proposée en guise de compromis. Elle permet d'isoler complètement la production, tout en permettant aux développeurs de travailler avec des services en préproduction.
Exemple 2 : parcs avec des propriétaires de ressources différents
Dans cet exemple, nous avons deux équipes : l'équipe A (team-a) et l'équipe B (team-b). Ces équipes possèdent et gèrent leurs propres clusters. Toutes deux ont utilisé les espaces de noms frontend et backend pour les services qu'elles produisent. Cependant, les espaces de noms frontend et backend de l'équipe A sont différents de ceux de l'équipe B. Les deux équipes souhaitent créer un maillage de services afin que leurs services puissent interagir.
Sans aucune intervention, il n'existe aucun moyen d'intégrer ces clusters au même maillage. Un bon point de départ consiste à transférer la propriété des clusters à une équipe de plate-forme centralisée afin d'établir une relation de confiance entre les équipes. Si les équipes A et B se font confiance, elles peuvent également se coordonner pour établir cette confiance.
L'étape suivante consiste à normaliser l'utilisation de l'espace de noms de sorte que frontend et backend ne soient plus surchargés dans les clusters de ces deux équipes. Une fois cette opération terminée, les équipes peuvent configurer un seul parc pour toutes les ressources et créer leur maillage de services.
Si ce niveau de confiance ne peut pas être établi, les équipes A et B doivent créer deux parcs distincts utilisant deux projets hôtes de parc. L'inconvénient de cette approche est qu'elles doivent désormais exploiter la fédération de maillage, qui est plus difficile à gérer qu'un seul maillage. L'avantage est qu'aucune équipe n'a besoin de normaliser ses espaces de noms et services déployés. Seules les communications explicites et spécifiquement autorisées sont possibles.
