muppy.io
  • ⛏️Qu'est ce que muppy.io ?
  • ⚒️Concepts Muppy
  • Quickstarts
    • ✏️Introduction
  • Guides
    • ⛏️Muppy Core
      • Hosts
        • Création et enrôlement d'un Host
          • ✏️Server Types
          • ✏️Configuration réseaux spécifiques
        • ⚒️Host's Users
        • ⚒️Host's Network information
        • ⚒️Host's Metrics
      • Tasks et Fact Collectors
        • ⚒️Exécution des Tasks (Task Runs)
          • ⚒️Exécution asynchrone des Tasks (Launch as Job)
        • ⚒️Synchronisation des Tasks et Scripts
        • ⚒️Liste des Scripts
        • ⚒️Liste des Tasks
        • ⚒️Création de Task "Shell Script"
        • ⚒️Liste des Fact Definitions
      • ⛏️Firewall UFW
        • Désactiver UFW globalement
        • ✏️Page 1
      • SSH Keys
        • Gestion des SSH Keys
        • Gestion des "authorized_keys"
        • Extraction Clef Privée d'un User User
      • ⚒️Systemd Service Units
        • ⚙️Liste des Systemd Units
        • ➕Création de Systemd Units
        • 📰Systemctl status et log
        • ✏️Edition des Systemd Units
    • 🐘PostgreSQL
      • PostgreSQL Base
        • Installation de PostgreSQL
        • Gestion des Clusters
          • Création
          • Configuration
          • Contrôle
          • Administration (basique)
        • Backup, Restore et Copy de Databases
          • Databases Backups (pg_dump)
          • PostgreSQL Backup
          • pg_dump Restore
          • Database Copy
          • pg_restore Callback Task
        • Backups Planifiés
        • Gestion rétention des Backups
      • PostgreSQL Replication
        • Créer un RCS
        • Visualiser un RCS
        • Suivre la Replication
        • Ajouter des Standbys
        • Restructurer un RCS
        • Intégration d'un RCS
        • Reconfigurer un RCS
      • PostgreSQL HA
        • Configuration
        • Activation et Désactivation
        • Monitoring
        • pglookout Heartbeat
      • PostgreSQL PITR
        • Configuration de WAL-G
        • Lancement des Clusters Backups
        • Liste des Clusters Backups (WAL-G)
        • Purge des fichiers de Backup PITR
        • Monitoring du PITR
        • Objets S3 stockés par WAL-G
        • Restauration PITR
      • PostgreSQL Tools
        • pgBadger - log analysis
    • Muppy Pack
      • ⛏️Packs
      • Concepts
      • ⛏️Muppy Cluster
        • Cluster Security
        • PostgreSQL Cluster Resources
      • ⛏️Reverse Proxy
    • ✏️Configuration
      • 👫Gestion des Users Muppy
      • 🏬S3 Buckets
      • 💬Notifications Teams
      • ✏️Notifications Slack
    • ⛏️Odizy
      • Odizy Workflow
        • Test Servers
      • Accéder à vos serveurs
      • Restaurer un backup sur le serveur de staging
      • Activer un serveur Standby
      • ⛏️Configuration LXC CI/CD
      • Activate and Launch remote Code-Server (VS Code from coder.com)
    • ⚒️Kubernetes
      • ⚒️Installer Tailscale
      • ⚒️Installer un cluster microk8s
      • ⚒️Installer PostgrSQL
      • ⚒️Installer les packages d'infrastructures
  • 📡Muppy Enterprise
    • Introduction
    • ⛏️Configuer une Instance Muppy Enterprise
    • 🌡️Monitoring Muppy Enterprise
  • ⛏️Work in progress
    • ⛏️Code Server
    • ⛏️Muppy Development Servers
      • Move Development Server
Powered by GitBook
On this page
  1. Guides

Odizy

Retrouvez içi la description des fonctionnalités relatives à la gestion de vos serveurs Odoo dans le cadre de l'offre Muppy Odizy.

Présentation générale

L'objet de base de Odizy est l' Application Definition ou AppDef. Une AppDef définit comment construire une application Odoo et comment configurer la CI/CD.

Une AppDef est "connectée" à un repository Git (Gitlab est recommandé) et définit une Default Branch. On peut considérer la Default Branch comme une branch de Staging ou Pré-Production.

Les branches de travail sont définies comme les Feature branches.

Muppy utilise les WebHooks Gitlab pour construire automatiquement des serveurs de tests lors des commits.

Odizy gère 4 types de serveurs:

  • Serveur de Développement: Il s'agit en fait de serveurs de Remote Développement. Muppy vous permet de développer dans des serveurs Linux depuis votre poste de travail. Pour cela vous utiliser un navigateur web ou VSCode ou encore un des IDE de l'éditeur Jetbrains. Ce type de serveur est idéal pour le développer dans un environnement strictement identique à vos serveur de production et permet de travailler correctement si vosu devez manipuler de grosses bases de données.

  • Serveur de test: Ils sont créés automatiquement par Muppy lorsque vous commitez du code sur une feature branche. Ils sont accessibles pour que d'autre utilisateurs puissent tester et valider vos développement avant qu'il ne soient mergés dans votre branch de production.

  • Serveurs de taging: C'est un serveur dans lequel la branche principale et déployé. Il utilise une copie de la base de données de production. Si vous le souhaitez il peut être dimensionné à l'identique du serveur de production pour permettre des tests de charge et d'intrusion. Il est possible d'avoir plusieurs serveurs de staging. Les serveurs de staging sont mis à jour manuellement ou automatiquement à chaque commit sur la branche par defaut.

  • Serveurs de production: Odizy permet d'avoir un ou plusieurs serveurs de production en Haute Disponibilité. En haute diponibilité, Odizy déploie l'applicatif dans tous les serveurs.

PreviousNotifications SlackNextOdizy Workflow

Last updated 6 months ago

⛏️