Débuter avec cegedim.cloud

Apprenez les principes fondamentaux et commencez à construire avec cegedim.cloud. Trouvez le produit qui répond à vos besoins pour vous aider à lancer votre prochaine application et maitrisez ITCare, la plateforme de gestion cloud de cegedim.cloud.

Afin de vous aider à appréhender et maitriser chaque aspect de la plateforme ITCare, nous proposons un ensemble de démos interactives spécifiques à des fonctionnalités disponible dans notre Cloud Management Platform.

Ressources

Gérer une ressource

Différentes actions sont possibles pour gérer les ressources sur notre plateforme ITCare. Nous vous les présentons ci-dessous !

Filtres dynamiques

En fonction des ressources sélectionnées dans la fenêtre de filtrage, des filtres dynamiques seront désormais disponibles pour afficher plus efficacement ce qui vous intéresse.

Notifications

Vos notifications sont configurables et personnalisables via des abonnements. Nous vous montrons cela ci-dessous !

Créer un abonnement

La première étape incontournable : créer un abonnement selon vos critères personnalisés.

Gérer les abonnements

Maintenant que vous savez comment créer un abonnement, voyons comment le gérer.

Gérer les groupes de diffusion

Les abonnements tirent partie de groupes de diffusions. Nous vous montrons comment les gérer.

Superviser les notifications

Lorsque vos notifications sont paramétrées, il est essentiel de savoir comment les superviser.

Qu'est-ce que ITCare ?

ITCare est la plateforme de gestion Cloud de cegedim.cloud.

Elle intègre une interface d'administration web et une API qui offrent une vue à 360° de vos ressources Cloud hébergées et gérées par cegedim.cloud.

Conçue comme un service web unifié, elle régit les points clés suivants :

Vous pouvez explorer les spécifications de l'API et utiliser la fonctionnalité Test it afin d'exécuter et de tester les points de terminaison.

Deux types d'authentifications sont disponibles : Bearer ou Oauth.

Lorsque vous utilisez l'option Test it en Oauth, veuillez :

• Sélectionner les scopes : openid et email

Certaines méthodes renvoient des résultats paginés. Le formatage d'un résultat paginé presente la structure suivante :

{
    "content": [
        ...
    ],
    "totalElements": ...,
    "last": false,
    "totalPages": ...,
    "sort": {
        "empty": true,
        "sorted": false,
        "unsorted": true
    },
    "first": true,
    "size": ...,
    "number": ...,
    "numberOfElements": ...,
    "empty": false
}

Les valeurs page et size peuvent être ajoutées aux paramètres de la requête afin d'obtenir la page suivante ou précédente.

Example

Pour obtenir les 50 premiers éléments d'une requête GET pour un endpoint paginé : https://api.cegedim.cloud/foo/bar?page=1&size=50

cegedim.cloud fournit dans ITCare une rubrique dédiée à son empreinte carbone.

Cette rubrique permet d'identifier l'impact environnemental des applications de façon détaillée, en affichant à la fois l'émission de CO2 des Services Globaux ainsi que celle des instances associées.

Le calcul de l'empreinte carbone fait partie intégrante du projet Enercare, en se basant sur la répartition de la consommation énergétique des services. Elle prend en compte les équipements IT (serveurs, baies de stockage, réseaux ...) mais également tous les éléments nécessaires à leur bon fonctionnement (climatisation, groupes électrogènes, onduleurs ...). Ces derniers sont associés à l'indicateur de performance énergétique par datacenters calculé par le Power Usage Effectiveness (PUE).

Le périmètre inclut les Datacenters propres à Cegedim ainsi que ceux en colocation.

Principe

cegedim.cloud a travaillé sur des outils internes et une méthodologie pour répartir les consommations des services utilisant des instances mutualisées. Etant en démarche d’amélioration continue, elle sera amenée à évoluer avec la fiabilisation et la précision des données remontées.

Le calcul de l’empreinte carbone de nos services cloud suit les règles du . Nous incluons les éléments suivants dans la fonctionnalité Enercare :

• Les émissions directes du scope 1 des datacenters : combustions fossiles des groupes électrogènes, émissions fugitives liées aux fluides frigorigènes des systèmes de refroidissement.

• Les émissions indirectes du scope 2 : consommation d’électricité des équipements, incluant le PUE.

• Les émissions indirectes du scope 3 : émissions amont liées aux combustibles et à la production d’électricité, produits et services achetés pour le fonctionnement de nos services, tenant compte de leur fabrication à leur fin de vie, déplacements des collaborateurs.

Les données retranscrites dans Enercare correspondent aux activités de cegedim.cloud, indépendamment de celles des autres filiales et du groupe Cegedim. Le bilan carbone étant réalisé et audité annuellement, nous ne pouvons pas corréler en temps réel les coefficients de calcul à l’utilisation des services.

La section Règles de Calcul ci-dessous explicite la collecte de la consommation énergétique des équipements physiques et la méthode de calcul de l'empreinte carbone pour les services et instances.

Pour en savoir plus sur les actions de diminution de l’impact environnemental entreprises par cegedim.cloud, vous pouvez consulter la de notre site internet.

Catégories d'équipement et calcul des émissions de CO2

Catégories d'équipement

Un Datacenter utilise trois grandes catégories d'équipement :

Les distributions Linux suivantes peuvent être durcies lors de leur provisionnement :

• Debian à partir de la version 11 et 12

• Ubuntu à partir de la version 22.04 et 24.04

• Oracle Linux à partir de la version 9

Demander un replica MariaDB en lecture seule

Pour demander l'ajout d'une réplique en lecture seule de MariaDB, il est nécessaire de créer un ticket requête via ITCare.

Dans la section Support du menu latéral gauche, cliquer sur le bouton Formuler une demande.

Dans la catégorie Base de données puis MariaDB, sélectionner et remplir le formulaire : Mise en place d'une réplication passive MariaDB

Un ticket d'assistance sera créé à la soumission.

L'API ITCare utilise les codes de réponse HTTP conventionnels pour indiquer le succès ou l'échec d'une demande API.

En règle générale :

• Les codes 2xx indiquent un succès.

• Les codes 4xx indiquent des paramètres incorrects ou incomplets (par exemple, un paramètre requis a été omis, ou une opération a échoué avec une tierce partie, etc.)

• Les codes de l'ordre de 5xx indiquent une erreur avec les serveurs d'ITCare.

Ce tableau présente d'autres exemples de codes de réponse HTTP.

ITCare produit également un message d'erreur et un code d'erreur formaté en JSON :

Comment s'authentifier auprès de l'API ITCare ?

L'API ITCare utilise le protocole OAuth 2.0 pour l'authentification et les autorisations. Elle supporte les scénarios OAuth 2.0 habituels tels que ceux utilisés pour les serveurs web et les applications clientes. Cela signifie que chaque requête API doit contenir un header "Authorization" embarquant un token d'accès précédemment obtenu grâce à des identifiants.

curl -X GET "https://itcare.cegedim.cloud/itcare/{api-definition}/{api-endpoint}" -H "Authorization: Bearer {token}"

Comment obtenir un compte API ?

Pour interroger l'API ITCare, un compte API est requis afin de pouvoir obtenir le token d'accès obligatoire. Pour obtenir ce compte API, une requête doit être soumise aux équipes support cegedim.cloud en fournissant les informations suivantes :

• L'organisation cible

• Une description simple de l'usage cible de l'API

Comment obtenir un token d'accès ?

Pour obtenir un token d'accès, le client doit soumettre une requête au endpoint . Le serveur d'autorisation exige l'authentification (base64-encodé) du client pour délivrer un access_token. Voici un exemple de demande d'access_token :

En général, on peut utiliser la commande base64 pour encoder une chaîne de caractères. L'utilisation d'outils en ligne de commande sous Linux, par exemple :

Si la demande d'access_token est autorisée et valide, voici un exemple de réponse :

Lorsque le token expire, il est possible de :

• Demander un nouvel access_token

• Rafraîchir le token en interrogeant le endpoint /token

Qu'est-ce qu'une Patch Party ?

cegedim.cloud s'assure que tous les serveurs sont patchés lors d'événements appelés Patch Party. Ces événements ont lieu tous les trimestres un dimanche, soit 4 fois par an.

Lors d'une Patch Party, les patchs sont installés sur tous les serveurs non exclus de l'événement puis suivis d'un redémarrage.

Quel est le calendrier ?

Les Patch Parties ont lieu tous les trimestres, soit 4 fois par an. Deux Patch Parties sont programmées chaque trimestre :

• Patch Party de QA : elle a lieu en premier pendant les heures ouvrées, le jeudi, et ne concerne que les environnements de non-production.

• Patch Party de Production : elle a lieu 3 semaines après la Patch Party de QA, le dimanche, et ne s'applique qu'aux environnements de production.

Que puis-je faire ?

Consulter les informations sur les correctifs

Sur chaque page de détails d'une ressource, un panneau intitulé Patch status vous permet de consulter les informations suivantes :

• La dernière fois que la ressource a été mise à jour avec succès

  • Le timestamp de la mise à jour

  • Le tag du correctif de la mise à jour avec ce format : YYYY-QQ (par exemple 2022-Q4)

Inclure ou exclure

Sur chaque page de détails d'une ressource, un bouton Patch Party vous permet d'inclure ou d'exclure définitivement la ressource des Patch Party.

L'exclusion d'une ressource doit être motivée par une raison. Inclure vous permet de sélectionner le Patch Group qui affectera le moment où votre ressource sera effectivement mise à jour au cours de la journée de correctifs.

Modifier le groupe de correctifs

Dans le même bouton Patch Party que celui décrit ci-dessus, vous pouvez changer le Patch Group souhaité à tout moment.

3 groupes de patches sont disponibles pour diviser vos ressources. Chaque groupe sera traité à des moments différents.

Ceci est utile si vous ne voulez pas que plusieurs ressources soient patchées (et interrompues) en même temps, améliorant ainsi la résilience de votre application.

Description

Matomo (anciennement appelé Piwik) est un logiciel de mesure open source qui fournit des statistiques de données sur l'utilisation d'une page web, telles que les visites, les pages vues, l'origine des visites et bien plus encore.

Matomo offre la possibilité d'avoir une analyse complète sur certains aspects de vos sites web avec des informations concernant : vos visiteurs, leur comportement, leurs habitudes et plus encore.

Pourquoi Matomo ?

Matomo est un excellent substitut à Google Analytics pour les raisons suivantes :

• Pleine propriété des données

• Protection de la vie privée

• Pas d'échantillonnage de données

• Conformité RGPD (recommandé par la CNIL)

Plateforme en tant que Service

Matomo est déployé sur site dans les centres de données de cegedim.cloud et est fourni en tant que service.

cegedim.cloud garantit le niveau de service managé suivant : le déploiement des instances, le maintien en condition opérationnelle, la flexibilité, la sécurité et le monitoring sont ainsi assurés par nos experts.

Pour plus d'information, veuillez consulter la page .

Facturation

La facturation est mensuelle et varie en fonction de la taille choisie. Veuillez contacter votre Service Delivery Manager pour plus d'informations concernant la tarification.

Politique de support des produits

Les offres managées de cegedim.cloud incluent du support. Ce support se découpe en 4 phases :

• Phase standard : cegedim.cloud offre un support complet du produit.

• Phase fin de vente : phase secondaire indiquant qu'une nouvelle version a été élue en phase de support Standard. Il est fortement conseillé d'effectuer une migration vers une version plus récente.

• Phase support étendu : troisième phase qui débute à la date de fin de vie (EOL) annoncée par l'éditeur pour le produit. Cela signifie que plusieurs services ne sont plus garantis et passent en meilleurs efforts.

• Phase fin de Support : phase terminale activée quand cegedim.cloud n'est plus en mesure de fournir du support. Des frais peuvent s'appliquer si le système est considéré comme un risque pour la sécurité (violation, compromission des données, nécessité d'isolation).

Voici un listing détaillé des fonctionnalités selon les phases de support :

Comment formuler une demande ?

Depuis de notre gestionnaire de plateforme cloud ITCare, vous pouvez créer un ticket de demande d'assistance.

Depuis la page d'accueil ou bien depuis la section Support dans le menu latéral gauche, cliquez sur le bouton Formuler une demande.

Recherchez d'abord le formulaire correspondant au produit pour lequel vous avez besoin d'aide en tapant le nom du produit dans la barre de recherche. Sélectionnez le formulaire et fournissez les informations requises.

Un ticket d'assistance sera créé lors de la soumission.

Comment déclarer un incident ?

Les ressources gérées sont surveillées par cegedim.cloud si la surveillance a été activée.

Cependant, un formulaire d'incident est disponible dans notre gestionnaire de plateforme cloud ITCare si vous avez besoin de nous faire part d'un problème que nous aurions manqué.

Depuis la page d'accueil ou la section Support du menu latéral gauche, cliquez sur le bouton Déclarer un incident.

Pour mieux traiter votre incident, un niveau de gravité est requis :

• Pas d'impact

• Dégradation

• Interruption de service

Recherchez le formulaire approprié en recherchant le nom du produit avec lequel vous avez un problème, puis fournissez les informations requises.

Un ticket d'incident sera créé et notre équipe de support vous contactera dès que possible.

Contexte et motivation

Kubernetes dispose de fonctionnalités et de mécanismes intégrés pour maintenir en bonne santé les nœuds et les workoads kubernetes :

• kube-scheduler décide sur quels nœuds placer les pods en fonction des ressources demandées par les pods et des ressources non réservées des nœuds.

• kubelet Out-Of-Memory tue les pods qui consomment plus de ressources que les valeurs limitées définies dans la spécification (OOM killed).

• Pour quelque raison que ce soit, si le nœud est à court de ressources, kubelet expulse les pods afin d'alléger la pression sur les nœuds (éviction des pods). La décision d'éviction des pods est basée sur la qualité de service des pods.

Gardez à l'esprit que cegedim.cloud fournit des clusters Kubernetes standard avec ces fonctionnalités et a qualifié les documentations officielles de Kubernetes ci-dessous :

Le problème se situe au niveau de l'application dans la vie réelle :

• toutes les technologies ne sont pas nativement compatibles avec les conteneurs

• les mesures d'utilisation des ressources collectées par le kubelet (ou l'exportateur de nœuds, etc.) ne sont pas en temps réel

• les mesures d'utilisation des ressources ne sont pas prises en compte par le planificateur kube

• kubelet, en tant que processus Linux, n'est pas toujours le processus le plus prioritaire, en particulier lorsque les nœuds n'ont plus de CPU.

L'incapacité à gérer les contraintes de ressources sur les nœuds par kubelet conduit à des défaillances de nœuds et au redéploiement de toutes les charges de travail correspondantes. Dans le pire des cas, un effet domino sur la défaillance des nœuds peut se produire.

La solution cegedim.cloud

cegedim.cloud fournit une solution de hardening appelée cgdm-hardening :

• Un esclave de hardening de pods par nœuds de travail : écrit la consommation de CPU et de RAM dans une base de données centralisée.

• Un pod de hardening-maître déployé sur les nœuds maîtres : il lit les métriques dans la base de données et prend des mesures en cas de crise.

• L'empreinte de la pile de hardening sur les ressources est très faible

Le pod Hardening-master peut agir selon deux modes :

• Mode préventif (en tant qu'assistant du planificateur kube, mode par défaut) :

  • Place le taint cegedim.io/overload=true:NoSchedule pour éviter de placer plus de pods sur des nœuds sous pression (85% RAM ou 90% CPU). Lorsque le CPU est inférieur à 85% et que la RAM est inférieure à 80%, l'altération est supprimée.

• Mode de protection (en tant qu'assistant du contrôleur de kube) :

Comment désactiver / activer le hardening

Le nouveau cluster Kubernetes sera provisionné avec le hardeing préventif activé.

Si les charges de travail déployées par les clients entraînent un grand nombre de défaillances de nœuds (TLS_K8_NODES), le mode de protection sera activé.

Le client peut désactiver ce hardening en créant un ticket requête dans ITCare.

Par conséquent, la vérification TLS_K8_NODES de centreon au niveau du cluster et la vérification de l'état de santé de centreon sur les nœuds de travail seront désactivées.

Cela signifie que les clients doivent redémarrer eux-mêmes les nœuds en cas de crise.

Le client peut réactiver ce hardening en faisant un ticket requête ITCare à tout moment.

Description

OpenSearch est une suite de recherche et d'analyse open source pilotée par la communauté et dérivée d'Elasticsearch 7.10.2 & Kibana 7.10.2 sous licence Apache 2.0.

Il se compose d'un démon de moteur de recherche, OpenSearch, et d'une interface de visualisation et d'utilisation, OpenSearch Dashboards. Il permet d'ingérer, de sécuriser, de rechercher, d'agréger, de visualiser et d'analyser facilement les données.

Ces capacités sont populaires pour des cas d'utilisation tels que la recherche d'applications, l'analyse des journaux, etc.

Plateforme en tant que Service

Les serveurs OpenSearch Cluster et la configuration des services sont gérés par cegedim.cloud. Le produit est disponible en libre-service dans ITCare.

Les utilisateurs ont un accès complet à la base de données et aux tableaux de bord d'OpenSearch. Il est de la responsabilité des utilisateurs de gérer la sécurité des index et de leur cycle de vie.

OpenSearch est déployé en tant que cluster sur site dans nos centres de données.

Le même niveau de service que l'offre Compute est garanti : déploiement d'instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.

Le dimensionnement peut être configuré en fonction de vos besoins.

Le nombre minimum de nœuds pour un cluster est de 3 serveurs mais n'est pas recommandé pour la production. Il est conseillé de déployer au moins 5 nœuds ou plus pour une utilisation en production.

Pour plus d'information, veuillez consulter la page .

Facturation

La facturation est mensuelle et basée sur le nombre de nœuds, plus des coûts supplémentaires pour le stockage, la sauvegarde et la surveillance 24/7.

L'estimation du coût d'un cluster OpenSearch est disponible auprès de votre Responsable de compte Technique.

Processus de mise à niveau

Requête

La mise à jour d'un PaaS Redis est de la responsabilité de cegedim.cloud et peut être demandée via un ticket soumis depuis ITCare.

Merci de préciser un créneau de disponibilité pour l'opération et si l'opération doit être effectuée en heures non ouvrées.

Il est recommandé de procéder à la mise à jour de vos environnements de non production d'abord afin de pouvoir estimer le temps d'interruption généré par l'opération ainsi que de recetter vos applications dans la nouvelle version du moteur.

Déroulement

La mise à jour d'un déploiement Redis (mono-instance ou cluster en haute disponibilité) se déroule en deux étapes complètement automatisées :

• Mise à jour du système d'exploitation préalable

  • Plusieurs mises à jour selon le scénario: Debian 10 → Debian 11 → Debian 12

• Mise à jour du moteur Redis et Sentinel dans la version cible

Impacts

La durée d'une mise à jour est variable selon:

• La topologie

  • Topologie Standalone: Redis sera mise à jour.

  • Topologie Sentinel: Redis et Sentinel seront mis à jour sur chaque noeuds.

• Le nombre de mise à jour du système d'exploitation nécessaire

Temps de référence

• Mise à jour du système d'exploitation Debian: 10 minutes en moyenne

• Mise à jour des paquets Redis: 5 minutes en moyenne

• Mise à jour des paquets Sentinel: 5 minutes en moyenne

Matrice de support OS / Redis

Distribution Linux supportées par cegedim.cloud en fonction de la version de Redis:

Débuter avec l'API ITCare ?

L'API REST ITCare respecte les spécifications standard OpenAPI. La documentation en ligne est disponible à cette adresse :

Exemple:

Créer une instance Matomo

Connectez-vous à la plateforme ITCare, cliquez sur le bouton Statistiques dans le menu principal à gauche. Cliquez sur "Créer une instance Matomo" et suivez les instructions.

Indiquez le service global dans lequel vous souhaitez créer une instance Matomo.

Donnez le nom de l'instance que vous voulez créer. Un nom de site web et une URL par défaut peuvent être configurés pendant le provisionnement. Ils sont facultatifs. S'ils sont laissés vides, des valeurs fictives seront utilisées. Cliquez sur Suivant.

Description

cegedim.cloud fournit des clusters Kubernetes gérés, avec le plus haut niveau de sécurité et de résilience intégré.

En utilisant ces clusters, vous pouvez déployer vos workloads Kubernetes standards dans les centres de données cegedim.cloud afin de maximiser la disponibilité de vos applications.

cegedim.cloud fournit également une console Rancher, où vous pouvez gérer vos workloads, et configurer les capacités d'observabilité intégrées (Logging et Métrologie) pour la connecter à vos propres plateformes (Grafana, ElasticSearch...).

Description

MariaDB est un système de gestion de base de données open-source créé par les développeurs de MySQL. MariaDB utilise des tables pour stocker les données de manière organisée et il est possible d'interagir avec la base de données à l'aide de requêtes SQL.

Il prend en charge des concepts tels que les clés primaires, les index et les relations entre les tables. MariaDB est largement utilisé pour le stockage et la gestion des données dans diverses applications, des sites web aux systèmes d'entreprise. C'est un choix populaire en raison de sa fiabilité, de ses performances et de sa nature open-source.

OpenSearch amène plusieurs changements, vous devez donc vérifier la compatibilité de votre application avec ceux-ci.

Remove mapping type

Il s'agit du principal changement induisant une rupture et il n'est pas spécifique à OpenSearch car il était déjà prévu par ElasticSearch avant le fork.

Vous devez donc vous assurer que vos applications n'utilisent plus les paramètres "type".

Voici quelques solutions concernant les produits souvent utilisés avec les solutions élastiques et comment les configurer pour qu'ils fonctionnent avec OpenSearch 2.x

Description

L'instance virtuelle est un produit entièrement géré proposé par cegedim.cloud, conçu pour simplifier et améliorer votre expérience d'hébergement. Avec les instances virtuelles, vous n'avez plus à vous soucier de la complexité de la gestion de votre infrastructure d'hébergement - notre équipe d'experts s'occupe de tout.

Notre produit prend en charge une variété de systèmes d'exploitation tels que Linux, Windows et AIX, ce qui vous donne la liberté de choisir l'environnement qui répond le mieux à vos besoins. Il peut être déployé sans effort grâce à notre outil de gestion de plateforme cloud convivial appelé ITCare.

Cet outil vous donne la possibilité de démarrer l'instance souhaitée, de sélectionner le système d'exploitation de votre choix et de personnaliser les ressources pour répondre à vos besoins spécifiques en quelques clics, garantissant ainsi que vos instances sont adaptées aux exigences de votre entreprise.

Comment déployer une instance virtuelle ?

Pour créer une nouvelle instance virtuelle, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouvelle instance.

Recherchez votre service global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information. Une fois dans votre service global, cliquez sur le bouton Créer une ressource, sélectionnez Linux, Windows ou AIX et la version et/ou la distribution souhaitée.

Remplir les champs :

• Nom de la machine virtuelle

• Dimensionnement du CPU/RAM

• Disques et capacité de stockage pour chaque disque

• Emplacement de la cible

• Réseau cible

• Options de gestion (sauvegarde, surveillance, surveillance 24x7, réplication des données)

Cliquez sur Suivant une fois que tous les champs ont été remplis.

Lors de l'étape de personnalisation, vous pouvez :

• Formuler une requête spécifique (il est à noter que cela retardera la tâche automatisée car cela déclenchera une intervention humaine)

• Créer plusieurs instances avec la même configuration (noms et emplacement à fournir)

Cliquez ensuite sur Suivant.

Lisez le résumé avant de soumettre le formulaire.

Une fois que le déploiement est prêt, vous en serez informé par e-mail.

Comment puis-je me connecter à mon instance virtuelle ?

Quelle que soit l'instance ou le système d'exploitation auquel vous devez vous connecter, l'utilisation d'un Bastion est obligatoire. Vous devez d'abord vous connecter au Bastion assigné à votre locataire, à partir duquel vous pouvez ensuite initier une connexion SSH ou RDP à vos instances.

Linux

Connexion SSH en utilisant Putty ou mRemoteNG installé sur votre Bastion. Les identifiants à utiliser sont vos propres identifiants d'utilisateur adm.corp.

La connexion directe en tant qu'utilisateur root est désactivée sur toutes les instances virtuelles Linux. Vous devez vous connecter avec un utilisateur non root, puis utiliser les permissions sudoers pour effectuer des actions à haut privilège.

Comment s'authentifier ?

Deux méthodes d'authentification sont autorisées :

• LDAP

• Clé publique et privée

Pour se connecter via SSH en utilisant la méthode d'authentification LDAP, vous devez avoir un compte valide dans le même domaine LDAP que celui dans lequel votre instance virtuelle est inscrite.

Il n'est pas nécessaire de spécifier le nom du domaine LDAP dans votre login.

Lors de la première connexion, votre répertoire personnel sera automatiquement créé : /home/<yourlogin>/

Pour obtenir la liste des commandes autorisées, entrez la commande suivante : sudo -l

Pour se connecter à une instance virtuelle linux avec votre clé publique SSH, votre clé doit être ajoutée au fichier /home/<user>/.ssh/authorized_keys.

Où <user> est le nom du compte local sur le serveur cible et login spécifie le nom de l'utilisateur local : ssh user@host

Window

Connexion RDP en utilisant Remote Desktop de mRemoteNG ou Windows mstsc intégré sur votre Bastion. Les identifiants à utiliser sont ceux de l'utilisateur adm.corp.

AIX

Connexion SSH en utilisant Putty ou mRemoteNG installé sur votre Bastion. Un compte utilisateur local avec un accès sudo ou root sera fourni lors de la livraison de l'instance.

Comment autoriser l'accès à une instance virtuelle linux ?

Autorisation de connexion LDAP

our lister les utilisateurs et groupes LDAP autorisés à se connecter, utilisez la commande suivante :

• simple_allow_groups : groupes LDAP

• simple_allow_users : utilisateurs LDAP

Ajouter des utilisateurs

Pour autoriser la connexion d'un utilisateur LDAP, utilisez la commande suivante :

Ajouter des groupes

Pour autoriser la connexion à un groupe LDAP, utilisez la commande suivante :

Supprimer des accès

Pour supprimer l'accès à un utilisateur ou groupe LDAP, utilisez la commande suivante :

Comment gérer les permissions sous Linux ?

Pour accorder des droits sudo à des utilisateurs ou groupes LDAP (ainsi qu'à des utilisateurs ou groupes locaux), créez un nouveau fichier dans /etc/sudoers.d

Utilisez la commande visudo pour éditer votre fichier sudoers :

Processus de mise à niveau

Requête

La mise à jour d'un PaaS Kubernetes peut-être effectuée en self-service sur la page ressource du cluster Kubernetes depuis ITCare

Il est recommandé de procéder à la mise à jour de vos environnements de non-production dans un premier temps afin de pouvoir valider la nouvelle version ainsi que la compatibilité avec votre cluster.

Déroulement

L'upgrade du cluster Kubernetes suit ces étapes en mode Rolling Update :

1. Les pods sont redémarrés noeud par noeud : 10% des noeuds worker à la fois

2. Validation post-mise à jour (health check, monitoring).

Impacts

Les version api de ressources Kubernetes peuvent être obsolètes, voir supprimés lors de la mise à jour de version Kubernetes. Il y a une risque de cassure si vous avez des ressources avec une version api supprimé dans la nouvelle version de Kubernetes.

Pour éviter cela, une des solutions est d'utiliser l'outil "kubent" pour vérifier la compatibilité .

Kubent détecte les objets obsolètes du cluster Kubernetes. Vous devez migrer/modifier les ressources identifiés avant la mise à jour de version Kubernetes.

Vérification de compatibilité avant une mise à jour de version Kubernetes

Pour installer kubent :

Pour identifier les objets obsolètes qui vont être supprimés dans la prochain version Kubernetes :

Un exemple de l'output :

Dans ce tutoriel, si votre cluster est planifié pour une mise à jour vers version Kubernetes 1.22, vous devez migrer votre resource ingress nommé "toto" de version api networking.k8s.io/v1beta1 vers networking.k8s.io/v1 avant la mise à jour.

Cette migration peut impliquer une modification des champs supplémentaires de la ressource. Veillez consulter la documentation officielle :

Mettre à jour votre cluster

En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Mettre à jour. Un message d'information apparait, cliquez sur Soumettre.

Temps de référence

Une mise à jour d'un cluster Kubernetes prend environ 15 minutes en moyenne. Les noeuds sont mis à jour les un après les autres en respectant un maximum de 10% de noeud sur le cluster.

Ces temps sont indicatifs et peuvent varier selon les spécificités du cluster.

Matrice de support OS / Kubernetes

Distribution Linux supportées par cegedim.cloud en fonction de la version de Kubernetes :

Chemins de mises à jour Kubernetes supportés

Introduction

cegedim.cloud propose désormais une plateforme de stockage Ceph multi-locataires en tant que fournisseur de CSI avec les spécifications suivantes :

• Les données sont répliquées 4 fois et réparties uniformément (à l'aide de Ceph Crush Map) sur 2 centres de données afin de garantir que, dans les scénarios de catastrophe, 2 répliques de données sont toujours disponibles.

• Chaque cluster Kubernetes, en tant que client Ceph, dispose de son propre pool de données sur le serveur Ceph et consomme des services avec ses propres identifiants.

• Seul le RBD Ceph CSI est fourni pour le moment.

De plus amples informations sur le Ceph CSI sont disponibles via le lien ci-dessous

Versions

Classe de stockage

Haute disponibilité

Caractéristiques du CSI

Snapshot et restauration de PVC dans Kubernetes

cegedim.cloud utilise External Snapshotter pour prendre des clichés et restaurer le PVC de vos clusters Kubernetes.

Toutes les informations relatives à cette application sont disponibles à l'adresse suivante :

Comment savoir si j'ai un snapshotclass actif sur mon cluster ?

Il est recommandé de nommer la classe d'instantanés d'après la classe de stockage. Il suffit d'exécuter la commande ci-dessous pour vérifier :

Comment lister les CSI disponibles dans mon cluster ?

Pour répertorier tous les CSI disponibles dans un cluster Kubernetes, procédez comme suit :

Voici une correspondance entre la classe de stockage et le CSI :

Topologies

Le cluster OpenSearch est disponible en tant que :

• Cluster de 3 nœuds - non recommandé pour une utilisation en production

• Cluster de 5 nœuds ou plus - recommandé pour une utilisation en production

Topologie à 3 nœuds

Dans la topologie à 3 serveurs, tous les serveurs jouent le rôle de maître, deux d'entre eux sont également utilisés comme nœuds de données. Chaque index est répliqué par défaut sur ces deux nœuds de données.

Topologie d'au moins 5 nœuds

Avec 5 serveurs ou plus, trois nœuds sont utilisés comme nœuds maîtres et n'hébergent pas de données. En fonction de la zone, les nœuds maîtres sont répartis sur 2 ou 3 zones de disponibilité. Les nœuds restants n'hébergent que des données et sont répartis sur deux zones de disponibilité.

Résilience

Dans une Area avec 3 zones de disponibilité, le cluster est résilient face à une défaillance d'une zone de disponibilité.

Dans une Area avec 2 zones de disponibilité, le cluster peut tomber en panne si la zone de disponibilité contenant deux maîtres n'est pas disponible.

Fonctionnalités

Cette section énumère les fonctionnalités / capacités disponibles pour les utilisateurs, ainsi que la manière de les demander / de les exécuter :

Sécurité

Authentification

L'authentification utilise le système de sécurité interne d'OpenSearch. Il peut être configuré sur demande pour accepter Active Directory comme backend d'authentification.

Autorisations

Les autorisations sont effectuées à l'aide de RBAC. Il peut être configuré sur demande pour accepter Active Directory comme fournisseur de rôles.

Transport sécurisé

TLS/SSL est activé par défaut pour les flux réseau entrants et internes.

Mots de passe

Cette section explique comment est gérée la gestion des mots de passe :

Description

PostgreSQL est actuellement le principal SGBDR (système de gestion de base de données relationnelle) open source, avec une large gamme de fonctionnalités et une grande communauté qui le soutient.

cegedim.cloud fournit des instances de bases de données PostgreSQL entièrement gérées pour vous permettre de construire vos applications sans vous soucier de la disponibilité, la sécurité et la résilience des bases de données PostgreSQL.

Plateforme en tant que Service

PostgreSQL est déployé sur site dans les centres de données de cegedim.cloud.

cegedim.cloud garantit le même niveau de service que l'offre Compute & Database : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.

Deux types de déploiements PostgreSQL sont disponibles :

• Le mode Instance autonome fournit une instance PostgreSQL standard.

• Le mode Haute disponibilité fournit un déploiement PostgreSQL multi-instances avec des capacités de résilience et d'évolutivité améliorées.

Le dimensionnement peut être configuré en fonction de vos besoins.

Pour plus d'information, veuillez consulter la page .

Facturation

La facturation est mensuelle et basée sur le nombre de nœuds plus les coûts supplémentaires pour le stockage, la sauvegarde et le monitoring 24x7.

L'estimation du coût d'un nœud PostgreSQL est disponible via votre Service Delivery Manager.

Description

Matomo est disponible en libre-service dans ITCare pour tous les utilisateurs autorisés.

En fonction du dimensionnement choisi (voir les dimensionnements ci-dessous), plusieurs composants seront déployés avec un strict minimum de :

• 1 serveur web frontal

• 1 serveur de base de données

• 1 équilibreur de charge avec une adresse IP publique (certificat inclus)

Les tailles supérieures (pour suivre plus de pages vues par mois) peuvent inclure plus de serveurs web pour l'équilibrage de charge. Pour les tailles supérieures à XL, un ticket de demande sera nécessaire.

Une fois provisionnée, votre instance Matomo est accessible au public via l'URL fournie dans ITCare.

L'installation de plugins et les mises à jour de Matomo peuvent être effectuées par le client en toute autonomie.

Architecture

Régions

Matomo est disponible dans les régions suivantes :

• EMEA - France - Boulogne-Billancourt

• EMEA - France - Toulouse

Dimensions

Les tailles suivantes sont disponibles :

Redimensionner votre instance Matomo

Le redimensionnement est disponible dans le self-service ITCare mais ne permet que le redimensionnement vers le haut.

Le redimensionnement vers le bas n'est pas possible !

Versions supportées

La version de Matomo déployée dépend de la dernière mise à jour de nos repository lors de la dernière patch party.

La dernière version sera souvent disponible mais il peut arriver que la version déployée ne soit pas la dernière.

Dans ce cas, la mise à jour peut être déclenchée par le client en autonomie directement depuis l'interface web UI ou sur demande en créant un ticket de demande dans ITCare.

Fonctionnalités

Cette section énumère les fonctionnalités / capacités disponibles pour le client, ainsi que la manière de les demander / de les exécuter :

Sécurité

Authentification et autorisations

Le client dispose d'un compte local super utilisateur.

OpenOIDC est configuré pour ajouter et autoriser facilement d'autres utilisateurs à accéder à Matomo.

Transport sécurisé

L'accès à votre instance Matomo se fait de manière sécurisée via HTTPS.

Localisation des données

Toutes les données sont stockées dans les centres de données de cegedim.cloud sur des baies de stockage cryptées.

Mots de passe

Le mot de passe du compte super utilisateur fourni au client n'est pas stocké ni sauvegardé par cegedim.cloud.

Surveillance

Matomo et les composants associés sont surveillés par notre équipe de support. Un état de santé global est affiché dans ITCare pour votre confort.

Description

Redis qui signifie Remote Dictionary Server, est un magasin de données clé-valeur rapide, open source, en mémoire.

Il fournit une réplication intégrée, différents niveaux de persistance sur le disque, et offre une haute disponibilité avec Sentinel.

Il existe un large éventail d'outils de développement pour les langages les plus courants.

Plateforme en tant que Service

Redis est déployé sur site dans les centres de données cegedim.cloud.

cegedim.cloud garantit le même niveau de service que l'offre Compute : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.

Deux topologies sont disponibles :

• Instance autonome

• Cluster Sentinel de 3 instances

La topologie cluster Sentinel est prête pour la production avec 3 instances réparties sur toutes les Zones de Disponibilité d'une Area cible.

Chaque instance exécute les processus Redis et Sentinel. Une instance est primaire et les deux autres sont des répliques.

Le dimensionnement peut être configuré en fonction de vos besoins.

Pour plus d'information, veuillez consulter la page .

Facturation

L'estimation des coûts pour un PaaS Redis est disponible via votre Service Delivery Manager.

La facturation est basée sur le nombre de nœuds auquel s'ajoutent les frais supplémentaires de stockage, de sauvegarde, surveillance 24/7.

Systèmes d'exploitation supportés

Linux

Les distributions Linux suivantes sont disponibles lorsque vous sélectionnez Linux comme système d'exploitation pour votre Instance Virtuelle :

Microsoft SQL Server est un système de gestion de base de données relationnelle développé par Microsoft.

Il est conçu pour stocker et récupérer des données telles que demandées par d’autres applications logicielles. Les fonctionnalités principales de SQL Server incluent :

• Stockage et récupération de données : SQL Server offre une plateforme sécurisée et scalable pour stocker une grande quantité de données structurées et semi-structurées de manière efficace.

• Interrogation et manipulation de données : Il propose des capacités avancées d’interrogation, telles que la possibilité d’écrire des requêtes complexes en utilisant le langage SQL, de joindre des tables, de créer des vues et de récupérer des données en fonction de critères spécifiques.