@wilmouths wilmouths authored 6 days ago
etc config: add envvar-prod file 18 days ago
schema create orphan branch for deployment template 20 days ago
scripts.d create orphan branch for deployment template 20 days ago
.env create orphan branch for deployment template 20 days ago
README.md create orphan branch for deployment template 20 days ago
docker-compose-dev.yml update deployment 18 days ago
docker-compose-intg.yml update deployment 18 days ago
docker-compose-prod.yml update deployment 18 days ago
docker-compose.yml fix: add default port 6 days ago
README.md

999_templates_applis_docker

arborescence normalisée à utiliser dans la création d'application avec docker-compose

on parle de $appname ou $gitrepo pour désigner le répertoire où s'actionne le git des développeurs. Ce dernier est créé à partir du git 999_templates_applis_docker

La philosophie de fonctionnement est : un environement applicatif (/applis/toto/home) = une arborescence et un lanceur docker-compose unique S'il devait y avoir besoin d'autres docker-compose pour constituer l'ensemble de l'application, il faudra faire un second environement applicatif Il contiendra les différents services et la configuration des volumes et network Ce Fichier de base sera override selon le type de machines (vd/vi/vp) par les fichiers docker-compose-dev/-intg/-prod.yml Il y a également un système de profiles, qui selectionnera tel ou tel service à lancer sur la VM. le nom à ajouter à profile sera le nom/hostname de la machine (pas fqdn, ex. vdtotoche)

Ce qui sera lancé par systemd en tant que service sur la machine : Ex. VM hostname vdototoche, application toto à environement applicatif unique :

docker-compose -up -d --project-directory /applis/toto/home/$appname/ -f /applis/toto/home/$appname/docker-compose.yml -f /applis/toto/home/$appname/docker-compose-dev.yml --profile vdtotoche

Les variables d'environnement seront passées à docker compose selon le même mécanisme vd/vi/vp Il y a deux systèmes de variables, celles apportées par les devs via le repo git et celles d'iProd (secret/password/iprod) ON NORMALISE LE NOMMAGE, CE QUI VIENT DU GITREPO (devops) EST PREFIXE GITREPO_ ou GITREPOCOMPOSESERVICENAME si dédiée à un service particulier. CE QUI VIENT D'IPROD SERA PREFIXE IPROD_ ou IPRODCOMPOSESERVICENAME si dédiée à un service particulier.

La constitution des variables à injecter dans systemd se fait au passage lancement du service. /!\ Avant l'injection de ces variables le nommage est validé par un regex.

En Integratiuon/Production les containers ne DOIVENT PAS être build mais importé depuis la registry INIST (ou Autre mais bon...)

Normalisation dans le docker-compose : Noms des Services, Noms des containers et exemple d'utilisation des profiles (ici seul elastic1 est lancé sur trois machines, les trois elastic sont lancé sur une machine d'integration unique, et un cluster de trois elastic sur trois machines est configuré en production )

 services:
  NOMAPPLIS_NOMCOMPOSANT:
    image: url.path.to.image.frontend
    profiles: ["vdtotoche,vitotoche,vptotoche"]
    container_name: NOMAPPLIS_NOMCOMPOSANT
  NOMAPPLIS_elastic1:
    image: elastic
    profiles: ["vdtotoche,vitotoche-es,vptotoche-es1"]
    container_name: NOMAPPLIS_elastic1    
  NOMAPPLIS_elastic2:
    image: elastic
    profiles: ["vitotoche-es,vptotoche-es2"]
    container_name: NOMAPPLIS_elastic2    
  NOMAPPLIS_elastic3:
    image: elastic
    profiles: ["vitotoche-es,vptotoche-es3"]
    container_name: NOMAPPLIS_elastic3

Normalisation de l'arborescence :

/applis/
└── $appname
    ├── home
    │   ├── data
    │   │   ├── dockerServiceName1 --> NORMALISATION NOMMAGE ET PLACEMENT A RESPECTER
    │   │   └── dockerServiceName2
    │   ├── $appname ou gitrepo
    │   │   ├── dockerServiceName1
    │   │   │   └── exemple.conf --> Fichiers montés dans compose (ex .conf, template build etc..)
    │   │   ├── dockerServiceName2 --> NORMALISATION DU NOM, ON UTILISE LE NOM DU SERVICE DANS COMPOSE
    │   │   │   └── DockerFile --> Fichier DockerFile pour le service compose dockerServiceName
    │   │   ├── etc
    │   │   │   ├── env.d
    │   │   │   │   ├── envvar --> surchargé par un des trois fichiers ci-dessous  
    │   │   │   │   ├── envvar-dev --> selon type machine
    │   │   │   │   ├── envvar-intg --> selon type machine
    │   │   │   │   └── envvar-prod --> selon type machine
    │   │   │   ├── cleantmp.d
    │   │   │   │   └── clean_example.sh --> surchargé par un des trois fichiers ci-dessous          
    │   │   │   └── logrotate.d
    │   │   │       └── les fichiers de config logrotate de l'applis
    │   │   ├── docker-compose.yml
    │   │   ├── docker-compose-dev.yml
    │   │   ├── docker-compose-intg.yml
    │   │   ├── docker-compose-prod.yml
    │   │   ├── .env --> variable lues par défaut par docker /!\ NE PAS UTILISER    
    │   │   └── scripts.d
    │   │       └── scriptFile --> scripts maisons, appelés par cron ou logrotate veiller aux droits execution & user/group
    │   ├── etc 
    │   │   ├── certif (module SISR)
    │   │   ├── env.d 
    │   │   │   ├── appcod
    │   │   │   ├── 0setproxy
    │   │   │   └── $appname(.dev) --> var d'env. secret/password/iprod
    │   │   ├── env.sh  --> A STANDARDISE AUTOMATION
    │   │   ├── logrotate.conf --> CONTIENT include logrotate.d 
    │   │   └── logrotate.d --> A STANDARDISE AUTOMATION
    │   ├── tools  --> A STANDARDISE AUTOMATION / contient des clean tmp / scripts sauvegardes/restau
    │   │   ├── cleantmp.d
    │   │   └── cleantmp.sh
    │   └── var 
    │       ├── backups
    │       │   ├── dockerServiceName1 --> NORMALISATION NOMMAGE ET PLACEMENT A RESPECTER
    │       │   └── dockerServiceName2
    │       ├── cache
    │       │   ├── dockerServiceName1 --> NORMALISATION NOMMAGE ET PLACEMENT A RESPECTER
    │       │   └── dockerServiceName2    
    │       ├── lib 
    │       ├── log  --> DEMANDERA UNE STANDARDISATION jusque dans la config applicative
    │       │   ├── collect  --> beat sur un carctère wildcard *.log dans l'arbo + nom des service récup via puppet facter
    │       │   │   ├── dockerServiceName1 --> NORMALISATION NOMMAGE ET PLACEMENT A RESPECTER
    │       │   │   │   ├── dockerServiceName1_apache_access.log
    │       │   │   │   ├── dockerServiceName1apache_error.log
    │       │   │   │   └── dockerServiceName1shibboleth_auth.log
    │       │   │   ├── dockerServiceName2
    │       │   │   │   └── dockerServiceName2_mysql_syslog.log
    │       │   │   ├── dockerServiceName3
    │       │   │   │   └── dockerServiceName3_api_syslog.log
    │       │   ├── local  --> les logs locaux par ex. ceux d'un pgsql, log erreurs applis
    │       ├── run  --> contenait PID, a delete avec docker
    │       └── tmp 
    │    
    $appname2
    ├── home