Repos with recipes to deploy some infrastructure services
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
jdongmo bc1aa07b43 Update readme, license and some minors changes 3 years ago
inventory Update readme, license and some minors changes 3 years ago
roles Update readme, license and some minors changes 3 years ago
.gitignore Add pattern to ignore 3 years ago
LICENSE Update readme, license and some minors changes 3 years ago
README.md Update readme, license and some minors changes 3 years ago
ansible.cfg Update readme, license and some minors changes 3 years ago
playbook_crowdstrike.yml Add existing development 5 years ago
playbook_disk.yml Add existing development 5 years ago
playbook_dynatrace.yml Add existing development 5 years ago
playbook_jumpbox.yml Add existing development 5 years ago
playbook_ntp.yml Add existing development 5 years ago
playbook_powerdns.yml Add existing development 5 years ago
playbook_rapid7.yml Add existing development 5 years ago
playbook_ssh_known_host.yml Update readme, license and some minors changes 3 years ago
run.sh Update readme, license and some minors changes 3 years ago

README.md

ansible.infra.services

License

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

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