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 vuotta sitten
inventory Update readme, license and some minors changes 3 vuotta sitten
roles Update readme, license and some minors changes 3 vuotta sitten
.gitignore Add pattern to ignore 3 vuotta sitten
LICENSE Update readme, license and some minors changes 3 vuotta sitten
README.md Update readme, license and some minors changes 3 vuotta sitten
ansible.cfg Update readme, license and some minors changes 3 vuotta sitten
playbook_crowdstrike.yml Add existing development 5 vuotta sitten
playbook_disk.yml Add existing development 5 vuotta sitten
playbook_dynatrace.yml Add existing development 5 vuotta sitten
playbook_jumpbox.yml Add existing development 5 vuotta sitten
playbook_ntp.yml Add existing development 5 vuotta sitten
playbook_powerdns.yml Add existing development 5 vuotta sitten
playbook_rapid7.yml Add existing development 5 vuotta sitten
playbook_ssh_known_host.yml Update readme, license and some minors changes 3 vuotta sitten
run.sh Update readme, license and some minors changes 3 vuotta sitten

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.