Créez un pipeline d'intégration continue et de déploiement continu pour les déploiements cloud à l'aide d'actions Github et d'Oracle Cloud Infrastructure DevOps Service
- Pour empêcher l'exposition de toutes les cibles de déploiement à un service qui réside en dehors de certaines de vos couches de sécurité.
- Les parties d'un processus de déploiement peuvent varier en fonction du moment où Infrastructure as Code (IaC) fait partie du processus de déploiement.
- Minimisez l'impact potentiel de la latence dans les processus de déploiement. L'exécution de l'étape finale est donc contrôlée localement avec uniquement les connexions locales et les dépendances impliquées.
- Possibilité de gérer et de libérer des ressources de contrôle qui couvrent plusieurs environnements au même endroit. Au lieu d'avoir des sources distribuées.
Cette architecture de référence répond à ces questions en faisant en sorte que certaines parties de son service soient hors d'Oracle Cloud (par exemple, GitHub et d'autres au sein d'OCI, comme DevOps). Cette architecture de référence examine le processus de déploiement vers les plates-formes Oracle Cloud Infrastructure (OCI) : instances Oracle Container Engine for Kubernetes (OKE), Functions et Compute. L'image de conteneur commune est créée à l'aide d'un service distinct (de sorte que l'élément est universel), puis déployée par DevOps afin qu'elle ne communique pas directement avec OKE.
L'automatisation des versions logicielles avec déploiement de pipeline augmente la productivité des développeurs et vous permet de publier des fonctionnalités plus fréquemment et avec moins d'erreurs. Il permet d'éviter les temps d'inactivité lors des déploiements et d'automatiser la complexité de la mise à jour des applications. Oracle DevOps peut être utilisé à la fois par les clients migrant des charges de travail depuis des clouds on-premise ou autres vers OCI et par les clients développant de nouvelles applications sur OCI.
Architecture
Dans cette architecture de référence, un exemple d'application est déployé à partir de GitHub à l'aide des actions GitHub et du service OCI DevOps. L'application est déployée vers le cluster OKE.
Le diagramme suivant illustre cette architecture de référence.
Description de l'illustration devops-arch.png
- Région
Une région OCI est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes d'autres régions et de grandes distances peuvent les séparer (entre les pays voire les continents).
L'architecture utilise une seule région.
- Système CI externe
Cette architecture utilise les actions GitHub comme système d'intégration continue externe. GitHub Les actions automatisent, personnalisent et exécutent les workflows de développement logiciel à partir du référentiel GitHub. Ici, les actions GitHub sont utilisées pour créer du code, puis pour le conteneuriser à l'aide de Docker. Lorsque l'image en conteneur est prête, GitHub Actions propage l'image vers un référentiel d'artefacts OCI (vous pouvez également placer l'artefact dans un emplacement central où les actions GitHub peuvent être configurées pour purger DevOps afin d'extraire l'artefact. Cela signifie que le contenu est extrait, non poussé). Une fois le transfert vers le référentiel d'artefacts terminé, il démarre le pipeline de déploiement OCI DevOps. Vous pouvez également utiliser d'autres systèmes d'intégration continue comme Jenkins ou Gitlab en fonction de vos besoins.
Si des techniques IaC sont utilisées, avant le déploiement, le pipeline peut utiliser des services tels que Resource Manager pour instancier un environnement et, une fois terminé, démonter ces ressources à l'aide de Resource Manager.
Le pipeline de déploiement Devops peut également stocker les résultats obtenus dans un emplacement sécurisé pour le reporting.
- DevOps project
Un projet DevOps est un regroupement logique de ressources nécessaires à l'implémentation de votre charge de travail d'intégration et de déploiement continus (CI/CD). Les ressources DevOps peuvent être des artefacts, des pipelines de déploiement et des environnements. Les projets DevOps facilitent la journalisation, la surveillance et les notifications pour toutes vos ressources DevOps.
- Pipeline de déploiement
Un pipeline de déploiement contient les exigences qui doivent être satisfaites pour fournir un ensemble d'artefacts à un environnement. Les pipelines contiennent des étapes, qui sont les blocs de construction d'un pipeline. Un pipeline peut comporter des phases qui s'exécutent en série ou en parallèle, de sorte que vous pouvez contrôler le flux et la logique de votre version logicielle.
- Etapes de déploiementLes étapes sont des actions individuelles qui ont lieu au cours d'une exécution d'un pipeline. Le pipeline de déploiement DevOps comprend les types d'étape prédéfinis suivants à utiliser dans votre processus de lancement :
- Déploiement non simultané : version incrémentielle vers OKE, Functions ou groupes d'instances.
- Wait : Wait N secondes.
- Approbation manuelle : Si une approbation est donnée, arrêtez-vous si une approbation est rejetée.
- Fonction Invoke : Effectuez des tâches personnalisées et une intégration en appelant une fonction et transmettez un artefact de paramètres de demande.
- DevOps artefact
Un artefact DevOps est une référence ou un pointeur vers n'importe quel fichier, binaire, package, manifeste ou image qui constitue votre application. Lorsque vous créez un artefact, vous devez indiquer à Oracle DevOps l'emplacement source de l'artefact réel. DevOps prend en charge les référentiels OCI Container Image Registry et OCI Artifact Registry.
- Référentiel d'artefacts
Le référentiel d'artefacts permet de créer des référentiels pour regrouper des artefacts similaires. Une fois le référentiel créé, les artefacts peuvent être téléchargés vers eux. Ces artefacts sont un ensemble de fichiers texte, de fichiers binaires et de manifestes de déploiement qui seront fournis à l'environnement de déploiement cible. Chaque artefact a un nom, qui est constitué de son chemin : version. Le chemin est une chaîne permettant d'organiser les artefacts.
- Services de journalisation et de notifications OCI
Le service de journalisation OCI stocke les journaux liés au déploiement. La sortie d'exécution du déploiement et les résultats finaux du déploiement sont affichés sous forme d'entrées de journal. Le service Notifications OCI fournit une visibilité sur l'état le plus récent du projet de déploiement et de ses ressources, et effectue les actions nécessaires. Par exemple, vous êtes averti lorsqu'un événement important, tel qu'une phase d'un pipeline de déploiement en attente d'approbation. Lorsque vous recevez le message de notification, vous pouvez accéder aux pipelines de déploiement DevOps et approuver la phase.
- Environnements de déploiement
Un environnement est un ensemble de ressources informatiques d'un client où des artefacts sont déployés. Les environnements peuvent être des fonctions, des machines virtuelles de calcul ou des instances Bare Metal ou un cluster OKE.
- Cluster Oracle Kubernetes (OKE) : Oracle Container Engine for Kubernetes est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications en conteneur vers le cloud.
- Instances de calcul : le service OCI Compute vous permet de provisionner et de gérer des hôtes de calcul dans le cloud. Vous pouvez lancer des instances Compute avec des formes qui répondent à vos besoins en ressources pour l'UC, la mémoire, la bande passante réseau et le stockage.
- Functions : Oracle Functions est une plate-forme Functions-as-a-Service entièrement gérée, colocative, hautement évolutive et à la demande. Elle repose sur OCI de niveau entreprise et sur le moteur open source Fn Project.
Recommandations
- 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 aux sous-réseaux du VCN. Utilisez des blocs CIDR compris dans l'espace d'adresse IP privée standard.
Une fois que vous avez créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.
Cette architecture utilise un VCN public pour héberger le cluster OKE. Vous pouvez également utiliser un VCN privé. Dans ce cas, utilisez une passerelle NAT pour accorder au cluster l'accès via le réseau Internet public.
- Formes de calcul
Cette architecture utilise une image de système d'exploitation Oracle Linux avec une forme flexible E3 ou E4 avec des ressources minimales pour héberger les hôtes de calcul dans les noeuds de cluster OKE. Si votre application a besoin de plus de mémoire ou de cœurs, vous pouvez choisir une forme différente.
- OKE
Cette architecture est déployée sur le cluster OKE en tant qu'adresse cible. Les noeuds de processus actifs sont déployés sur un système d'exploitation Oracle Linux E3 ou E4. Cette architecture utilise trois noeuds de processus actifs dans le cluster, mais vous pouvez créer jusqu'à 1,000 noeuds sur chaque cluster.
- Registre d'images du conteneur
Cette architecture déploie Registry en tant que registre Docker privé pour une utilisation interne. Les images Docker sont propagées vers le registre et extraites de celui-ci. Vous pouvez également utiliser Registry en tant que registre Docker public afin de permettre à tout utilisateur disposant d'un accès Internet et connaissant l'URL appropriée d'extraire des images à partir de référentiels publics dans Oracle Cloud.
- Registre d'artefacts
Cette architecture crée un artefact pour le logiciel et la configuration utilisés par un cluster OKE. L'architecture crée un référentiel de registre d'artefacts à usage interne. Les fichiers binaires logiciels, le texte et les configurations de déploiement sont téléchargés vers le référentiel de registre d'artefacts et téléchargés à partir de celui-ci.
Remarques
Tenez compte des points suivants lors du déploiement de cette architecture de référence.
- Déploiements pris en charge par DevOps
DevOps prend en charge les déploiements vers OKE, les hôtes de calcul et les fonctions. Cette architecture est déployée sur un cluster OKE. Envisagez le déploiement vers d'autres adresses en fonction des besoins.
- Prise en charge de Linux
Seuls les hôtes Linux sont pris en charge pour les déploiements de groupe d'instances sur des instances Compute.
- artefacts déployés
Les artefacts à déployer avec DevOps doivent se trouver dans un registre d'artefacts OCI ou un référentiel de registre d'images de conteneur.
- Regroupement d'applications
Il est recommandé de regrouper chaque application et tous ses microservices dans un seul projet. Assurez-vous que la proposition de valeur du fractionnement du processus est comprise et que les divisions sont maintenues.
déploiement
Pour déployer cette architecture, suivez les instructions pour le déploiement d'applications Java dans ce laboratoire en direct :