Repos with recipes to deploy some infrastructure services

jdongmo bc1aa07b43 Update readme, license and some minors changes		3 lat temu
inventory	Update readme, license and some minors changes	3 lat temu
roles	Update readme, license and some minors changes	3 lat temu
.gitignore	Add pattern to ignore	3 lat temu
LICENSE	Update readme, license and some minors changes	3 lat temu
README.md	Update readme, license and some minors changes	3 lat temu
ansible.cfg	Update readme, license and some minors changes	3 lat temu
playbook_crowdstrike.yml	Add existing development	5 lat temu
playbook_disk.yml	Add existing development	5 lat temu
playbook_dynatrace.yml	Add existing development	5 lat temu
playbook_jumpbox.yml	Add existing development	5 lat temu
playbook_ntp.yml	Add existing development	5 lat temu
playbook_powerdns.yml	Add existing development	5 lat temu
playbook_rapid7.yml	Add existing development	5 lat temu
playbook_ssh_known_host.yml	Update readme, license and some minors changes	3 lat temu
run.sh	Update readme, license and some minors changes	3 lat temu

README.md

ansible.infra.services

Repos with recipes to deploy some infrastructure services

Pourquoi? | Organisation du code | Utilisation | Guide de contribution |

Pourquoi?

Afin d’accelerer l’adoption du deploiement d’infrastructure par le code, il est important de fournir un catalogue permettant rapidement de creer ou supprimer les ressources les plus utilisees dans une organisation. Les avantages de l’infrastructure as code:

tracabilite des changement
repetabilite, acceleration des deploiements
standardisation des ressources et des deploiements

Organisation du Code

├── ansible.cfg
├── Dockerfile
├── files
│   ├── check_jinja_syntax.py
│   └── Readme.md
├── infra.yml
├── inventory
│   ├── azure_rm.yml
│   ├── group_vars/
│   ├── host_vars/
│   └── inventory.py
├── LICENSE
├── playbook_crowdstrike.yml
├── playbook_dynatrace.yml
├── ...
├── playbook_ssh_known_host.yml
├── playbook_...yml
├── README.md
├── requirements.txt
├── roles
│   ├── iptables
│   ├── known_hosts
│   └── ...
├── run.sh

Tout le contenue du depot se veut publique, sans secrets ni configurations d’equipes.

Nous avons a la racine les playbooks qui sont appeles pour creer les ressources. Ces playbooks peuvent importer des playbooks ou appeler des roles du dossier roles

Le dossier inventory permet de configurer sur quel(s) cloud(s) interagir - Azure, AWS, GCP

Le dossier vars contient la definition des ressources a gerer. Il doit etre utiliser uniquement si le depot est unique a une seule equipe. Dans le cas d’un depot partage -Ce qui est souhaite- les fichiers de variables (definissant les ressources a gerer) doivent etre dans un depot separe, restreint a chaque equipe.

Utilisation

Generer l’image docker pour avoir un environnement uniforme entre les executions et avec toutes les librairies necessaires.

docker build --rm --compress -t <image-name> .

Le fichier Dockerfile se trouve a la racine du depot.

Execution dans le conteneur

docker run -v </dossier/de/variables/sur/le/host>:/opt/ansible/vars -ti --rm --env-file <fichier/de/credentials> <image-name> 
ansible-playbook -e @vars/<var-file.yml> playbook_adds.yml

Le fichier de credentials permet de definir dans les variables d’environnement du conteneur les elements de connexion au cloud. Par exemple pour Azure

AZURE_CLIENT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
AZURE_SECRET=xxxxx~xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AZURE_SUBSCRIPTION_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
AZURE_TENANT=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Guide de Contribution

Cloner le depot et creer votre branche de travail
Faites vos modifications et tester leur impact sur l’existant.
Soumettre une pull-request et fusionner vos modifications une fois qu’elles sont validees.