Déployer Jenkins en mode maître/agent
Architecture
Cette architecture de référence montre comment déployer Jenkins en mode contrôleur/agent à l'aide du module d'extension Oracle Cloud Infrastructure Compute de Jenkins. Lorsqu'il est installé sur une instance de contrôleur Jenkins, le module d'extension vous permet de créer des instances d'agent à la demande dans Oracle Cloud Infrastructure et d'enlever automatiquement des instances ou des ressources libres une fois le travail de build terminé.
Cette architecture contient une instance de contrôleur et deux instances d'agent comme point de départ d'un déploiement. Vous pouvez ajuster le nombre d'instances d'agent ou la taille de l'instance de contrôleur selon vos besoins. L'instance de contrôleur Jenkins doit être installée avec le code de module d'extension Oracle Cloud Infrastructure.
Cette architecture utilise une région avec un domaine de disponibilité et un sous-réseau régional. La même architecture de référence peut être utilisée dans une région avec plusieurs domaines de disponibilité. Nous vous recommandons d'utiliser un sous-réseau régional pour votre déploiement, quel que soit le nombre de domaines de disponibilité.
Cette architecture contient également un équilibreur de charge et une passerelle NAT pour fournir un accès sécurisé à Internet.
Le diagramme suivant illustre cette architecture de référence.

Description de l'illustration jenkins-oci.png
Au lieu de cette architecture, vous pouvez utiliser Oracle Container Engine for Kubernetes (OKE). Cette architecture est plus simple à configurer qu'OKE, mais OKE offre plus de flexibilité lors du redimensionnement du nombre d'agents que vous utilisez.
L'architecture comporte les composants suivants :
- Instance de contrôleur Jenkins
Cette instance de calcul virtuel agit en tant que noeud de contrôleur. Il surveille l'état des instances d'agent (hors ligne ou en ligne) et reçoit les réponses des résultats de tâche des agents.
- Instance d'agent Jenkins
Ces instances de calcul virtuelles agissent comme des noeuds d'agent. Le noeud de contrôleur les crée selon les besoins et effectue toutes les tâches conformément aux instructions du noeud de contrôleur.
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes des autres régions et de vastes distances peuvent les séparer (d'un pays à l'autre ou même d'un continent à l'autre).
- Réseau cloud virtuel (VCN) et sous-réseaux
Chaque instance Compute est déployée dans un VCN pouvant être segmentée en sous-réseaux.
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes et indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui permet de tolérer les pannes. Les domaines de disponibilité ne partagent pas d'infrastructure comme l'alimentation ou le refroidissement, ou le réseau de domaine de disponibilité interne. Il est donc peu probable qu'un échec dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.
- Domaines de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité dispose de trois domaines de pannes avec alimentation et matériel indépendants. Lorsque vous distribuez des ressources dans plusieurs domaines de pannes, vos applications peuvent tolérer les pannes de serveur physique, la maintenance du système et les pannes de courant dans un domaine de pannes.
- Balanceur de charge
L'équilibreur de charge distribue le trafic entrant vers le noeud de contrôleur Jenkins et fournit un accès Internet aux utilisateurs qui accèdent au noeud de contrôleur. Nous vous recommandons d'utiliser un équilibreur de charge de 100 Mbits/s, car il sera principalement utilisé pour la connexion au contrôleur Jenkins et le flux de trafic vers l'utilisateur ne sera pas lourd.
- Passerelle NAT
Une passerelle de traduction d'adresse réseau (NAT) fournit un service NAT. Vous n'avez pas à choisir la taille de la passerelle
- Hôte de bastion
Le bastion est une instance de calcul qui sert de point d'entrée sécurisé et contrôlé vers la topologie à partir de l'extérieur du cloud. Le bastion est généralement provisionné dans une zone démilitarisée (DMZ). Il vous permet de protéger les ressources sensibles en les plaçant dans des réseaux privés inaccessibles directement à partir de l'extérieur du cloud. La topologie comporte un seul point d'entrée connu que vous pouvez surveiller et auditer régulièrement. Vous pouvez donc éviter d'exposer les composants les plus sensibles de la topologie sans compromettre leur accès.
- Listes de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui spécifient la source, la destination et le type de trafic qui doivent être autorisés dans et hors du sous-réseau.
- Table de routage
Les tables de routage virtuelles contiennent des règles permettant d'acheminer le trafic de sous-réseaux vers des destinations en dehors d'un VCN, généralement via des passerelles.
Recommandations
Vos exigences peuvent différer de l'architecture décrite ici. Utilisez les recommandations suivantes comme point de départ.
- Formes de calcul (contrôleur Jenkins)
Cette architecture utilise deux formes de machine virtuelle principales pour le noeud de contrôleur Jenkins. Un noeud de contrôleur est chargé de distribuer les tâches, de collecter les résultats des noeuds d'agent et de surveiller la disponibilité des noeuds d'agent.
- Formes de calcul (agent Jenkins)
Cette architecture utilise quatre formes de machine virtuelle de base pour les noeuds d'agent Jenkins. Assurez-vous que la CPU des agents est supérieure à celle du noeud de contrôleur.
- Formes de calcul (hôte de bastion)
Un bastion est utilisé pour accéder à tous les noeuds du sous-réseau privé. Nous vous recommandons d'utiliser la forme VM.Standard.E2.1 ou VM.Standard.E2.2.
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher à des sous-réseaux dans VCN. Utilisez les blocs CIDR qui se trouvent dans l'espace d'adresse IP privé standard.
Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données on-premise ou un autre fournisseur cloud) sur lequel vous souhaitez configurer des connexions privées.
Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.
Lorsque vous concevez les sous-réseaux, tenez compte de vos besoins en matière de flux de trafic et de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, qui peut servir de limite de sécurité.
Utilisez un sous-réseau régional.
- Listes de sécurité
Utilisez des listes de sécurité pour définir des règles entrantes et sortantes qui s'appliquent à l'ensemble du sous-réseau.
Cette architecture autorise ICMP en interne pour l'ensemble du sous-réseau privé.
Remarques
- Performances
Pour obtenir les meilleures performances, assurez-vous que le noeud de contrôleur Jenkins dispose de suffisamment de coeurs et de mémoire. En fonction de la création ou d'autres tâches exécutées par les noeuds d'agent, créez des noeuds d'agent avec suffisamment de coeurs et de mémoire.
- Disponibilité
Le noeud de contrôleur Jenkins surveille la disponibilité des noeuds d'agent et génère un nouveau noeud selon les besoins. Dans une région comportant plusieurs domaines de disponibilité, vous pouvez créer un modèle de déploiement (sur le contrôleur Jenkins) pour les noeuds d'agent dans différents domaines de disponibilité.
- Coûts
Dimensionnez les CPU sur les noeuds de contrôleur et d'agent en fonction du déploiement de la charge de travail attendue. Vous pouvez modifier les formes de noeud dans la console. Par conséquent, commencez par un nombre plus faible d'UC (de préférence deux) et redimensionnez-les si nécessaire. Indiquez la forme du noeud d'agent avec le modèle d'instance dans le noeud de contrôleur.
- Surveillance et alertes
Configurez la surveillance et les alertes relatives à l'utilisation de l'UC et de la mémoire pour vos noeuds de contrôleur et d'agent afin de pouvoir augmenter ou réduire la forme de machine virtuelle selon vos besoins.
Déployer
Le code Terraform de cette architecture de référence est disponible dans GitHub. Vous pouvez extraire le code dans Oracle Cloud Infrastructure Resource Manager en un seul clic, créer la pile et le déployer. Vous pouvez également télécharger le code de GitHub sur votre ordinateur, personnaliser le code et déployer l'architecture à l'aide de la CLI Terraform.
- Déployer à l'aide d'Oracle Cloud Infrastructure Resource Manager :
- Cliquez sur
.
Si vous n'êtes pas déjà connecté, entrez les informations d'identification de location et d'utilisateur.
- Vérifiez et acceptez les conditions générales.
- Sélectionnez la région dans laquelle vous souhaitez déployer la pile.
- Suivez les invites à l'écran et les instructions pour créer la pile.
- Une fois la pile créée, cliquez sur Actions Terraform, puis sur Plan.
- Attendez que le travail soit terminé et vérifiez le plan.
Pour apporter des modifications, revenez à la page Détails de la pile, cliquez sur Modifier la pile et apportez les modifications requises. Exécutez ensuite à nouveau l'action Plan.
- Si aucune autre modification n'est nécessaire, revenez à la page Détails de la pile, cliquez sur Actions Terraform et sélectionnez Appliquer.
- Cliquez sur
- Déployer à l'aide de la CLI Terraform :
- Accédez à GitHub.
- Téléchargez ou clonez le code sur votre ordinateur local.
- Suivez les instructions du README.
Explorer plus
- Structure des meilleures pratiques pour Oracle Cloud Infrastructure
- Créer un pipeline d'intégration et de déploiement continu à l'aide du service Oracle DevOps
- Créer un pipeline d'intégration continue et de déploiement continu pour les déploiements cloud à l'aide des actions GitHub et du service Oracle Cloud Infrastructure DevOps
- Configurer un pipeline d'intégration continue et de déploiement continu pour les déploiements cloud
Journal des modifications
Ce journal répertorie uniquement les modifications importantes :
5 mai 2022 | Ajout de l'option permettant de télécharger des versions modifiables (. SVG et . DRAWIO) du diagramme d'architecture. |
10 novembre 2020 | Étapes ajoutées pour déployer l'architecture à l'aide d'Oracle Cloud Infrastructure Resource Manager. |