Repos with recipes to deploy some infrastructure services
Ви не можете вибрати більше 25 тем Теми мають розпочинатися з літери або цифри, можуть містити дефіси (-) і не повинні перевищувати 35 символів.
jdongmo bc1aa07b43 Update readme, license and some minors changes 3 роки тому
inventory Update readme, license and some minors changes 3 роки тому
roles Update readme, license and some minors changes 3 роки тому
.gitignore Add pattern to ignore 3 роки тому
LICENSE Update readme, license and some minors changes 3 роки тому
README.md Update readme, license and some minors changes 3 роки тому
ansible.cfg Update readme, license and some minors changes 3 роки тому
playbook_crowdstrike.yml Add existing development 5 роки тому
playbook_disk.yml Add existing development 5 роки тому
playbook_dynatrace.yml Add existing development 5 роки тому
playbook_jumpbox.yml Add existing development 5 роки тому
playbook_ntp.yml Add existing development 5 роки тому
playbook_powerdns.yml Add existing development 5 роки тому
playbook_rapid7.yml Add existing development 5 роки тому
playbook_ssh_known_host.yml Update readme, license and some minors changes 3 роки тому
run.sh Update readme, license and some minors changes 3 роки тому

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.