jonaspammer.apache2

// Ce fichier est généré par .github/workflows/gh-pages.yml - toutes les modifications locales seront perdues à terme !
= ansible-role-apache2
Jonas Pammer <[email protected]>;
:toc: gauche
:toclevels: 2
:toc-placement!:
:source-highlighter: rouge


https://galaxy.ansible.com/jonaspammer/apache2[image:https://img.shields.io/badge/disponible%20sur%20ansible%20galaxy-jonaspammer.apache2-brightgreen[Version sur Galaxy]]
// Badges d'état très pertinents
https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/ci.yml[image:https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/ci.yml/badge.svg[Tests CI]]


Un rôle Ansible pour installer Apache2, activer/désactiver des modules, configurer ses paramètres par défaut et créer des hôtes virtuels.


toc::[]

[[meta]]
== 🔎 Métadonnées
Ici, vous pouvez trouver des informations sur…

* la version Ansible requise pour le rôle
* les plateformes prises en charge par le rôle
* les https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[dépendances de rôle]

.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
  role_name: "apache2"
  description:
    "Un rôle Ansible pour installer Apache2, activer/désactiver des modules,
    configurer ses paramètres par défaut et créer des hôtes virtuels.
    Basé sur le rôle apache2 de geerlingguy."

  author: "jonaspammer"
  license: "MIT"

  min_ansible_version: "2.11"
  platforms:
    - name: EL # (Enterprise Linux)
      versions:
        - "9" # testé activement : rockylinux9
    - name: Fedora
      versions:
        - "38" # testé activement : fedora38
        - "39" # testé activement : fedora39
    - name: Debian
      versions:
        - bullseye # testé activement : debian11
        - bookworm # testé activement : debian12
    - name: Ubuntu
      versions:
        - focal # testé activement : ubuntu2004
        - jammy # testé activement : ubuntu2204

  galaxy_tags:
    - web
    - apache
    - serveur web
    - html
    - httpd

dependencies: []

allow_duplicates: true
----


[[requirements]]
== 📌 Exigences
// Toute condition préalable qui pourrait ne pas être couverte par ce rôle ou par Ansible lui-même doit être mentionnée ici.
L'utilisateur Ansible doit pouvoir `devenir`.

Si vous utilisez SSL/TLS (<<apache_vhosts_ssl>>), vous devrez fournir vos propres fichiers de certificat et de clé.

Si vous utilisez Apache avec PHP, je recommande le rôle 
https://github.com/geerlingguy/ansible-role-php/[geerlingguy.php]
pour installer PHP, et vous pouvez utiliser `mod_php`
(en ajoutant le paquet approprié, par exemple `libapache2-mod-php5` pour Ubuntu, à `php_packages`),
ou en utilisant également
https://github.com/geerlingguy/ansible-role-apache-php-fpm[`geerlingguy.apache-php-fpm`]
pour connecter Apache à PHP via FPM.
Veuillez consulter les README des rôles liés pour plus d'informations spécifiques.

Lors de la cible des systèmes basés sur Solaris,
la collection https://galaxy.ansible.com/community/general[`community.general`]
(contenant le module `pkg5`) doit être installée sur le contrôleur Ansible.

Lors de la cible des systèmes basés sur Suse,
la collection https://galaxy.ansible.com/community/general[`community.general`]
(contenant le module `zypper`) doit être installée sur le contrôleur Ansible.


[[variables]]
== 📜 Variables du rôle
// Une description des variables configurables pour ce rôle devrait être ici
// et toute variable qui peut/doit être définie par des paramètres au rôle.
// Toute variable lue à partir d'autres rôles et/ou de l'espace global (c'est-à-dire hostvars, vars de groupe, etc.)
// devrait également être mentionnée ici.

[source,yaml]
----
apache_mods_enabled:
  - rewrite
  - ssl
apache_mods_disabled: []
----
(Debian/RHEL uniquement)
Modules Apache à activer ou désactiver (ceux-ci seront liés à l'emplacement approprié).
Consultez le répertoire `mods-available` (Debian) / `conf.modules.d` (RHEL) à l'intérieur de <<apache__server_root_dir, du répertoire racine d'apache>> pour tous les modules disponibles.

[source,yaml]
----
apache_listen_ip: "*"
apache_listen_port: 80
apache_listen_port_ssl: 443
----
L'adresse IP et les ports sur lesquels Apache doit écouter.
Utile si vous avez un autre service (comme un proxy inverse) écoutant
sur le port 80 ou 443 et que vous devez changer les valeurs par défaut.

[source,yaml]
----
apache_remove_default_vhost: false
----
Sur Debian/Ubuntu, un hôte virtuel par défaut est inclus dans la configuration d'Apache.
Définissez ceci sur `true` pour supprimer ce défaut.

[source,yaml]
----
apache_state: started
----
Définissez l'état initial d'Apache.
Valeurs recommandées : `started` ou `stopped`

[source,yaml]
----
apache_enabled: true
----
Définissez l'état initial du service Apache.
Valeurs recommandées : `true` ou `false`

[source,yaml]
----
apache_restart_state: restarted
----
Définit l'état dans lequel mettre Apache lorsque des modifications de configuration ont été apportées
(c'est-à-dire lorsque le gestionnaire `restart apache` a été appelé).
Valeurs recommandées : `restarted` ou `reloaded`

[[apache_default_favicon]]
[source,yaml]
----
apache_default_favicon: favicon.ico
----
Chemin vers un fichier sur le contrôleur Ansible local à copier sur le serveur
et utilisé par Apache comme favicon par défaut.

=== Variables du rôle utilisées pour l'installation

[source,yaml]
----
apache_packages: [spécifique au système d'exploitation par défaut, voir le répertoire /defaults]
----
Une liste de noms de paquets pour installer Apache2 et les utilitaires les plus nécessaires.

[source,yaml]
----
apache_packages_state: present
----
Si vous avez activé des dépôts supplémentaires tels que
https://launchpad.net/~ondrej/+archive/ubuntu/apache2[`ondrej/apache2`],
https://fedoraproject.org/wiki/EPEL[`EPEL`], ou
http://rpms.remirepo.net/[`remi`],
vous voudrez peut-être un moyen facile de mettre à niveau les versions.
Pour vous assurer que c'est le cas, définissez ceci sur `latest`.

[source,yaml]
----
apache_enablerepo: ""
----
(RHEL/CentOS uniquement)
Le https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_module.html#parameter-enablerepo[dépôt]
à utiliser lors de l'installation d'Apache.
Si vous souhaitez des versions ultérieures d'Apache que celles disponibles dans les dépôts de base de l'OS,
utilisez un dépôt comme
https://fedoraproject.org/wiki/EPEL[EPEL]
(qui peut être installé avec le rôle `repo-epel`).

=== Variables du rôle utilisées pour créer des hôtes virtuels

[TIP]
Rendez-vous dans la section <<example_playbooks>> pour
des exemples montrant à quoi peut ressembler le fichier VirtualHost généré.

[NOTE]
====
Ce rôle essaie d'assurer une configuration Apache *fonctionnelle* en exécutant
https://httpd.apache.org/docs/2.4/programs/httpd.html[tests de syntaxe pour tous les fichiers de configuration (`-t`)]
et en annulant l'hôte virtuel généré si une erreur s'est produite.
====

[source,yaml]
----
apache_create_vhosts: true
apache_vhosts_filename: "vhosts.conf"
apache_vhosts_template: "vhosts.conf.j2"
----
Si défini sur `true`, un fichier vhosts géré par les variables de ce rôle (voir ci-dessous)
est créé et placé dans le dossier de configuration d'Apache.
Si défini sur `false`, vous pouvez placer votre propre fichier vhosts dans le dossier de configuration d'Apache et ignorer le fichier basique (mais plus pratique) ajouté par ce rôle.

Vous pouvez également remplacer le modèle utilisé et définir un chemin vers votre propre modèle,
si vous devez personnaliser davantage la mise en page de votre VirtualHost.

[source,yaml]
----
apache_global_vhost_settings: |
  DirectoryIndex index.php index.html
----
Cette variable est utilisée *_en dehors de toute directive <VirtualHost>_*
dans le fichier d'hôte virtuel généré.

[WARNING]
=====
Vous changez ainsi les configurations qui s'appliquent au contexte général d'Apache
(au lieu de changer les configurations s'appliquant, par exemple, à un `<VirtualHost>`/`<Directory>`/…).

Une chose à comprendre avec cette valeur par défaut est que
*le `DirectoryIndex` ne _définit pas_ mais plutôt _ajoute_*
(cela signifie que nous ne remplaçons aucune autre configuration faite),
comme noté dans sa page de documentation :

[quote,https://httpd.apache.org/docs/2.4/mod/mod_dir.html]
____
Plusieurs directives `DirectoryIndex` dans le même contexte ajouteront
à la liste des ressources à rechercher plutôt que de les remplacer.
____
=====

[source,yaml]
----
apache_vhosts:
  - servername: "local.dev"
    documentroot: "/var/www/html"
----
Pour chaque entrée de cette liste,
une directive `<VirtualHost>` écoutant
`{{ apache_listen_ip }}:{{ apache_listen_port }}`
sera générée.

Chaque entrée de la liste peut avoir les propriétés suivantes
(Consultez la section <<example_playbooks>> pour les exemples.
Consultez les pages de documentation officielles liées pour la documentation
des directives Apache réelles qu'elles représentent).

`https://httpd.apache.org/docs/2.4/mod/core.html#servername[servername]` (obligatoire)::

`https://httpd.apache.org/docs/2.4/mod/core.html#serveralias[serveralias]`::

`https://httpd.apache.org/docs/2.4/mod/core.html#serveradmin[serveradmin]`::

`https://httpd.apache.org/docs/2.4/mod/core.html#documentroot[documentroot]`::

`documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#servername[allowoverride]`::
Directive `AllowOverride` utilisée à l'intérieur de `<Directory>` du `DocumentRoot`. +
Par défaut, c'est la valeur de `apache_vhosts_default_documentroot__allowoverride`.

`documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#options[options]`::
Directive `Options` utilisée à l'intérieur de `<Directory>` du `DocumentRoot`. +
Par défaut, c'est la valeur de `apache_vhosts_default_documentroot__options`.

https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#logformat[`logformat`]::

`https://httpd.apache.org/docs/2.4/mod/core.html#loglevel[loglevel]`::

[[apache_vhosts__errorlog]]
`https://httpd.apache.org/docs/2.4/mod/core.html#errorlog[errorlog]`::
Soit une chaîne (représentant le chemin. ne sera pas automatiquement mis entre guillemets)
ou un type de données complexe:
+
====
`path`::
Chemin.
Sera mis entre guillemets en `"`.

`extra`::
Chaîne supplémentaire à ajouter après `path`.

`extra_parameters`::
Cette variable est insérée telle quelle *avant* la véritable déclaration `ErrorLog`
(avec une indentation de 2).
+
L'utilisation de ce paramètre peut être d'activer des journaux conditionnels en utilisant
`SetEnvIf` / `SetEnv` ou de définir un `LogFormat` personnalisé pour ce ErrorLog
https://httpd.apache.org/docs/2.4/logs.html[Documentation principale d'Apache].
====

[[apache_vhosts__customlogs]]
`https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#customlog[customlogs]`::
Tableau de CustomLogs.
Chaque entrée peut être soit une chaîne (ne sera pas automatiquement mise entre guillemets)
ou un type de données complexe:
+
====
`path`::
Chemin.
Sera mis entre guillemets en `"`.

`extra`::
Chaîne supplémentaire à ajouter après `path`.
Ne sera pas mis entre guillemets
(pour permettre les paramètres supplémentaires complexes optionnels de CustomLog que l'on peut vouloir fournir).

`extra_parameters`::
Cette variable est insérée telle quelle à la fin de la boucle `<VirtualHost>` (avec une indentation de 2).


[[apache_vhosts_ssl]]
[source,yaml]
----
apache_vhosts_ssl: []
----

Pour chaque entrée de cette liste,
une directive `<VirtualHost>` écoutant
`{{ apache_listen_ip }}:{{ apache_listen_port_ssl }}`
sera générée.

Chaque entrée de la liste peut avoir les propriétés suivantes
(Consultez la section <<example_playbooks>> pour des exemples)
(Consultez les pages de documentation officielles liées pour la documentation
des directives Apache réelles qu'elles représentent).

`https://httpd.apache.org/docs/2.4/mod/core.html#servername[servername]` (obligatoire)::

`https://httpd.apache.org/docs/2.4/mod/core.html#serveralias[serveralias]`::

`https://httpd.apache.org/docs/2.4/mod/core.html#serveradmin[serveradmin]`::

`https://httpd.apache.org/docs/2.4/mod/core.html#documentroot[documentroot]`::

`documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#servername[allowoverride]`::
Directive `AllowOverride` utilisée à l'intérieur de `<Directory>` du `DocumentRoot`. +
Par défaut, c'est la valeur de `apache_vhosts_default_documentroot__allowoverride`.

`documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#options[options]`::
Directive `Options` utilisée à l'intérieur de `<Directory>` du `DocumentRoot`.
Par défaut, c'est la valeur de `apache_vhosts_default_documentroot__options`.

`no_actual_ssl`::
Si défini sur True, le `<VirtualHost>` n'aura pas d'options SSL*.
Utilisé uniquement lorsque vous souhaitez une redirection http-vers-https que vous avez définie dans `extra_parameters`.

https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile[ssl_certificate_file] (obligatoire)::
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatekeyfile[ssl_certificate_key_file] (obligatoire)::
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatechainfile[ssl_certificate_chain_file]::
_Veuillez noter que ceci est obsolète._

https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#logformat[`logformat`]::

`https://httpd.apache.org/docs/2.4/mod/core.html#loglevel[loglevel]`::

`https://httpd.apache.org/docs/2.4/mod/core.html#errorlog[errorlog]`::
Équivalent de <<apache_vhosts__errorlog,apache_vhosts.errorlog>>.

`https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#customlog[customlogs]`::
Tableau de CustomLogs.
Équivalent de <<apache_vhosts__customlogs,apache_vhosts.customlogs>>.


`extra_parameters`::
Cette variable est insérée telle quelle à la fin de la boucle `<VirtualHost>` (avec une indentation de 2).


[source,yaml]
----
apache_ignore_missing_ssl_certificate: true
----
Si défini sur `false`, une entrée donnée de `apache_vhosts_ssl`
ne sera générée que si son `sslcertificatefile` existe.

[source,yaml]
----
apache_ssl_protocol: "All -SSLv2 -SSLv3"
apache_ssl_cipher_suite: "AES256+EECDH:AES256+EDH"
----
Ces variables sont utilisées par défaut pour chaque `apache_vhosts_ssl`.
Elles sont nommées de la même manière que celles utilisées dans ces variables de rôle
(sauf pour leur préfixe bien sûr).
Consultez https://httpd.apache.org/docs/current/mod/mod_ssl.html[
Documentation d'Apache]
pour la documentation des directives Apache réelles qu'elles représentent.


[source,yaml]
----
apache_vhosts_default_documentroot__allowoverride: "All"
apache_vhosts_default_documentroot__options: "-Indexes +FollowSymLinks"
----


[[public_vars]]
== 📜 Faits/Variables définies par ce rôle

Chaque variable énumérée dans cette section
est définie dynamiquement lors de l'exécution de ce rôle (et ne peut être écrasée qu'en utilisant `ansible.builtin.set_facts`) _et_
est destinée à être utilisée non seulement en interne.


[[apache__service]]
.`pass:[apache__service]`
****
.Exemple d'utilisation en dehors de ce rôle :
[source,yaml]
----
# fichier des gestionnaires pour les rôles.xyz
- name: redémarrer apache2
  ansible.builtin.service:
    name: "{{ apache__service | default('apache2') }}"
    state: restarted
----
****


[[apache__daemon]]
.`pass:[apache__daemon_dir]`, `pass:[apache__daemon]`
****
Nom et répertoire exécutables de la commande `apache2`.
****


[[apache__server_root_dir]]
.`pass:[apache__server_root_dir]`
****
Répertoire contenant toute la configuration d'Apache2 (dans `/etc`).
****

[[debian_is_different_note]]
[NOTE]
====
Lors de l'utilisation de n'importe laquelle des valeurs de configuration ci-dessous, vous devez vous rappeler :

[quote, commentaire trouvé dans un /etc/apache2/apache2.conf de Debian 10]
______
La configuration du serveur web Apache 2 dans *Debian est très différente de
la manière suggérée par les développeurs pour configurer le serveur web. Cela est dû au fait que l'installation par défaut d'Apache2 sur Debian tente de rendre l'ajout et la suppression des modules,
des hôtes virtuels et des directives de configuration supplémentaires aussi flexibles que possible, afin de rendre l'automatisation des modifications et l'administration du serveur aussi facile que possible.
______

Cela signifie que le `pass:[apache__server_root_dir]`
*sur Debian* ressemble à ceci :

.`tree /etc/apache2` d'une machine Debian 10 fraîche après l'installation d'apache2
----
.
├── apache2.conf
├── conf-available
│   ├── charset.conf
│   ├── localized-error-pages.conf
│   ├── other-vhosts-access-log.conf
│   ├── php7.4-fpm.conf
│   ├── security.conf
│   └── serve-cgi-bin.conf
├── conf-enabled
│   ├── charset.conf -> ../conf-available/charset.conf
│   └── …
├── envvars
├── magic
├── mods-available
│   ├── access_compat.load
│   ├── alias.load
│   ├── alias.conf
│   └── …
├── mods-enabled
│   ├── access_compat.load -> ../mods-available/access_compat.load
│   ├── alias.conf -> ../mods-available/alias.conf
│   ├── alias.load -> ../mods-available/alias.load
│   └── …
├── ports.conf
├── sites-available
│   ├── 000-default.conf
│   └── default-ssl.conf
└── sites-enabled
    └── 000-default.conf -> ../sites-available/000-default.conf
----

Alors que #sur d'autres systèmes, cela ressemble à cela# :

.`tree /etc/apache2` d'une machine CentOS 8 fraîche après l'installation d'apache2
----
.
├── conf
│   ├── httpd.conf
│   └── magic
├── conf.d
│   ├── autoindex.conf
│   ├── ssl.conf
│   ├── userdir.conf
│   └── welcome.conf
├── conf.modules.d
│   ├── 00-base.conf
│   ├── 00-dav.conf
│   ├── 00-lua.conf
│   ├── 00-mpm.conf
│   ├── 00-optional.conf
│   ├── 00-proxy.conf
│   ├── 00-ssl.conf
│   ├── 00-systemd.conf
│   ├── 01-cgi.conf
│   ├── 10-h2.conf
│   ├── 10-proxy_h2.conf
│   └── README
├── logs -> ../../var/log/httpd
│   └── …
└── modules -> ../../usr/lib64/httpd/modules
    ├── mod_access_compat.so
    ├── mod_actions.so
    ├── mod_alias.so
    └── …
----
====


[[apache__primary_configuration_file_path]]
.`pass:[apache__primary_configuration_file_path]`
****
Fichier de configuration principal d'Apache2,
qui http://httpd.apache.org/docs/2.4/mod/core.html#include
'inclut' tous les autres fichiers et contient quelques autres directives.

.Tous les regardent dans ce qui est inclus
[TIP]
====
Directives Include d'Apache2 de Debian trouvées dans `pass:[apache__primary_configuration_file_path]` :

[source,ini]
----
# Inclure la configuration des modules :
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf

# Inclure la liste des ports à écouter
Include ports.conf

# Inclure des répertoires ignore les fichiers de sauvegarde des éditeurs et dpkg,
# Inclure des extraits de déclarations

IncludeOptional conf-enabled/*.conf
# Inclure les configurations des hôtes virtuels :
IncludeOptional sites-enabled/*.conf
----

Directives Include d'Apache2 de RHEL trouvées dans `pass:[apache__primary_configuration_file_path]` sur une machine CentOS 8 :

[source,ini]
----
# Support pour Objets Dynamiques Partagés (DSO)
#
# Pour pouvoir utiliser la fonctionnalité d'un module qui a été construit en tant que DSO, vous
# devez placer les lignes de `LoadModule` correspondantes à cet endroit afin que les
# directives qu'il contient soient réellement disponibles _avant_ qu'elles ne soient utilisées.
# Les modules compilés statiquement (ceux listés par `httpd -l') n'ont pas besoin d'être
# chargés ici.
#
# Exemple :
# LoadModule foo_module modules/mod_foo.so
Include conf.modules.d/*.conf

# Configuration supplémentaire :
IncludeOptional conf.d/*.conf
----
====
****


[[apache__ports_configuration_file]]
.`pass:[apache__ports_configuration_file]`
*****
Fichier de configuration Apache2 qui contient les directives utilisées
pour déterminer les ports d'écoute pour les connexions entrantes.

Sur certains systèmes, cela est le même que `pass:[apache__primary_configuration_file_path]`,
mais sur d'autres, c'est un fichier propre qui est
http://httpd.apache.org/docs/2.4/mod/core.html#include
'inclut' par ce `pass:[apache__primary_configuration_file_path]`.
*****


[[apache__server_conf_dir]]
.`pass:[apache__server_conf_dir]`
****
Répertoire qui contient tous les fichiers http://httpd.apache.org/docs/2.4/mod/core.html#include
'inclus'.

Ce répertoire ne peut pas être `inclus` lui-même mais avoir des sous-répertoires qui sont inclus.
Consultez la NOTE/TIP trouvée dans <<apache__primary_configuration_file_path>>
pour savoir quels répertoires sont inclus par défaut sur différents OS.
****

[[apache__default_log_dir]]
.`pass:[apache__default_log_dir]`
****
Répertoire dans `/var` utilisé par défaut pour tous les hôtes virtuels.

La sortie ci-dessous montre le contenu de fichier par défaut typique
de ce dossier pour les principales distributions :

.RedHat
----
[root@instance-py3-ansible-5 /]# ls -l /var/log/httpd/
total 8
-rw-r--r-- 1 root root   0 Jun 11 11:16 access_log
-rw-r--r-- 1 root root 980 Jun 11 11:16 error_log
-rw-r--r-- 1 root root   0 Jun 11 11:16 ssl_access_log
-rw-r--r-- 1 root root 328 Jun 11 11:16 ssl_error_log
-rw-r--r-- 1 root root   0 Jun 11 11:16 ssl_request_log
----

.Debian
----
root@instance-py3-ansible-5-debian10:/# ls -l /var/log/apache2
total 4
-rw-r----- 1 root adm     0 Aug 29 10:17 access.log
-rw-r----- 1 root adm  2133 Aug 29 10:18 error.log
-rw-r--r-- 1 root root    0 Aug 29 10:18 local2-error.log
-rw-r----- 1 root adm     0 Aug 29 10:17 other_vhosts_access.log
----
****


[[tags]]
== 🏷️ Étiquettes

// Consultez https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags
// pour un excellent exemple de regroupement des tâches à l'aide d'étiquettes

Les tâches sont étiquetées avec les
https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[tags] suivantes :

[cols="1,1"]
|===
|Étiquette | But

2+| Ce rôle n'a pas encore d'étiquettes officiellement documentées.

// | download-xyz
// |
// | install-prerequisites
// |
// | install
// |
// | create-xyz
// |
|===

Vous pouvez utiliser Ansible pour ignorer des tâches, ou ne lancer que certaines tâches en utilisant ces étiquettes. Par défaut, toutes les tâches sont exécutées lorsque aucune étiquette n'est spécifiée.


[[dependencies]]
== 👫 Dépendances
// Une liste d'autres rôles devrait être ici,
// ainsi que tous les détails concernant les paramètres qui peuvent devoir être définis pour d'autres rôles,
// ou les variables utilisées provenant d'autres rôles.



[[example_playbooks]]
== 📚 Exemples d'utilisation de Playbook
// Inclure des exemples de la façon d'utiliser ce rôle dans un playbook pour des scénarios courants est toujours apprécié par les utilisateurs.

[NOTE]
====
Ce rôle fait partie de https://github.com/JonasPammer/ansible-roles[
de nombreux rôles compatibles à des fins spécifiques créés par mes soins].

La machine doit être préparée.
Dans CI, cela se fait dans `molecule/resources/prepare.yml`
qui source ses dépendances douces à partir de `requirements.yml` :

.link:molecule/resources/prepare.yml[]
[source,yaml]
----
---
- name: préparé
  hosts: all
  become: true
  gather_facts: false

  roles:
    - role: jonaspammer.bootstrap
    #    - name: jonaspammer.core_dependencies
----

Le diagramme suivant est une compilation des "dépendances douces" de ce rôle
ainsi que de l'arbre récursif de leurs dépendances douces.

image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_apache2.svg[
graph de dépendances de requirements.yml de jonaspammer.apache2]
====


.Installation Standard (sans variables)
====
* Le yaml suivant :
+
[source,yaml]
----
roles:
  - role: jonaspammer.apache2
----
+
génère le VirtualHost suivant :
+
[source]
-----
# Géré par Ansible
DirectoryIndex index.php index.html
<VirtualHost *:80>
    ServerName local.dev
    DocumentRoot "/var/www/html"

    <Directory "/var/www/html">
        AllowOverride All
        Options -Indexes +FollowSymLinks
        Require all granted
    </Directory>
</VirtualHost>
-----
+
Pour référence, c'est l'hôte virtuel par défaut expédié avec les systèmes Debian/Ubuntu
(qui peut être supprimé en définissant `apache_remove_default_vhost` sur true)
+
[source]
-----
<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
-----

Étant donné qu'aucune configuration de rôle n'est fournie, les écarts par rapport à une installation d'Apache2 traditionnelle sont

* certains modules sont activés par défaut (`<<apache_mods_enabled>>`).
* le système aura l'hôte virtuel démontré ci-dessus
* Lors de l'installation initiale, un fichier nommé `favicon.ico` (provenant de <<apache_default_favicon>>) sera placé dans `/var/www/html`
s'il n'y avait pas déjà un fichier portant ce nom. Ce favicon, par défaut, ressemble au logo Ansible tel que trouvé sur Wikimedia.

_Veuillez noter que ce rôle ne supprime *pas* le contenu de `/var/www/html`
(même s'il a été créé par/après l'installation initiale d'apache2)._
====


.Logging
====
* Le yaml suivant :
+
[source,yaml]
----
roles:
  - role: jonaspammer.apache2

vars:
  apache_vhost_filename: "local2.dev.conf"
  apache_vhosts:
    - servername: "wwww.local2.dev"
      loglevel: info
      errorlog: "{{ apache__default_log_dir }}/local2-error.log"
      customlog:
        path: "${{ apache__default_log_dir }}/local2-access.log"
        extra: "combined"
----
+
génère le VirtualHost suivant :
+
[source]
-----
# Géré par Ansible.

TODO
-----
====


.Usage of `extra_parameters`
====
[TIP]
======
Le symbole pipe à la fin d'une ligne dans YAML signifie que tout texte indenté qui suit
doit être interprété comme une valeur scalaire multi-lignes.
Voir https://yaml-multiline.info/[yaml-multiline.info] pour une explication interactive.
======

* Le yaml suivant :
+
[source,yaml]
----
roles:
  - role: jonaspammer.apache2

vars:
  apache_vhost_filename: "myvhost.conf"
  apache_vhosts:
    - servername: "www.local.dev"
      serveralias: "local.dev"
      documentroot: "/var/www/html"
      extra_parameters: |
          # Rediriger toutes les demandes vers le sous-domaine 'www'. Apache 2.4+
          RewriteEngine On
          RewriteCond %{HTTP_HOST} !^www\. [NC]
          RewriteRule ^(.*)$ %{REQUEST_SCHEME}://www.%{HTTP_HOST}%{REQUEST_URI} [R=302,L]
----
+
génère le VirtualHost suivant :
+
[source]
-----
# Géré par Ansible.

TODO
-----


* Le yaml suivant :
+
[source,yaml]
----
roles:
  - role: jonaspammer.apache2

vars:
  apache_vhost_filename: "myvhost.conf"
  apache_vhosts:
    - servername: "srvcmk.intra.jonaspammer.com"
      extra_parameters: |
        Redirect / {{ checkmk_site_url }}

----
+
génère le VirtualHost suivant :
+
[source]
-----
# Géré par Ansible.
DirectoryIndex index.php index.html
<VirtualHost *:80>
    ServerName srvcmk.intra.jonaspammer.com

    Redirect / http://srvcmk.intra.jonaspammer.at/master
</VirtualHost>
-----
====

.Créer votre propre fichier d'hôte virtuel / Intégrer dans un rôle
====
_Le rôle apache2 peut être exécuté plusieurs fois dans un play, avec l'objectif principal de
https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#using-allow-duplicates-true[cette autorisation]
étant de pouvoir créer des hôtes virtuels._

[source,yaml,subs="+quotes,macros"]
----
- tasks:
    pass:[#]...
    - name: Générer l'hôte virtuel Apache2.
      ansible.builtin.#include_role#: "apache2"
      vars:
        #apache_vhost_filename: "myapp.conf"#
        apache_vhosts:
          - servername: "www.myapp.dev"
            serveralias: "myapp.dev"
            DocumentRoot: "/opt/myapp"
    pass:[#]...
----
====


[[tested-distributions]]
== 🧪 Distributions testées

Un rôle peut fonctionner sur différentes *distributions*, comme Red Hat Enterprise Linux (RHEL),
même s'il n'y a pas de tests pour cette distribution exacte.

// une bonne référence à suivre -- le projet le plus étoilé et épinglé de geerlingguy :
// https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml
|===
| Famille OS | Distribution | Date de publication de la distribution | Fin de vie de la distribution | Image Docker accompagnante

// https://endoflife.date/rocky-linux
| Rocky
| Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 déguisé])
| 2021-06
| 2029-05
| https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux8-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Rocky
| Rocky Linux 9
| 2022-07
| 2032-05
| https://github.com/geerlingguy/docker-rockylinux9-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://endoflife.date/fedora (13 Mois)
| RedHat
| Fedora 39
| 2023-11
| 2024-12
| https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-fedora39-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://ubuntu.com/about/release-cycle
| Debian
| Ubuntu 20.04 LTS
| 2021-04
| 2025-04
| https://github.com/geerlingguy/docker-ubuntu2004-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2004-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian
| Ubuntu 22.04 LTS
| 2022-04
| 2027-04
| https://github.com/geerlingguy/docker-ubuntu2204-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2204-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://wiki.debian.org/DebianReleases
// https://wiki.debian.org/LTS
| Debian
| Debian 11
| 2021-08
| 2024-06 (2026-06 LTS)
| https://github.com/geerlingguy/docker-debian11-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian11-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian
| Debian 12
| 2023-06
| 2026-06 (2028-06 LTS)
| https://github.com/geerlingguy/docker-debian12-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]]
|===


[[tested-ansible-versions]]
== 🧪 Versions d'Ansible testées

Les versions d’ansible testées tentent de rester équivalentes au
https://github.com/ansible-collections/community.general#tested-with-ansible[
modèle de support de la collection `community.general` d’Ansible].
Au moment de l'écriture, ceci est :

* 2.13 (Ansible 6)
* 2.14 (Ansible 7)
* 2.15 (Ansible 8)
* 2.16 (Ansible 9)


[[development]]
== 📝 Développement
// Badges concernant les conventions dans ce projet
https://conventionalcommits.org[image:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Conventional Commits]]
https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-apache2/master[image:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-apache2/master.svg[statut pré-commit]]
// image:https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white[pre-commit, link=https://github.com/pre-commit/pre-commit]

[[development-system-dependencies]]
=== 📌 Dépendances de la machine de développement

* Python 3.10 ou supérieur
* Docker

[[development-dependencies]]
=== 📌 Dépendances de développement
Les dépendances de développement sont définies dans un
https://pip.pypa.io/en/stable/user_guide/#requirements-files[fichier de requirements pip]
nommé `requirements-dev.txt`.
Des instructions d'installation d'exemple pour Linux sont montrées ci-dessous :

----
# "optionnel" : créez un environnement virtuel python et activez-le pour la session de shell actuelle
$ python3 -m venv venv
$ source venv/bin/activate

$ python3 -m pip install -r requirements-dev.txt
----

[[development-guidelines]]
=== ℹ️ Directives de développement de rôle Ansible

Veuillez consulter mes https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[
Directives de développement de rôle Ansible].

Si vous êtes intéressé, j'ai également noté quelques
https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[
Meilleures pratiques de développement de rôle Ansible].
  
[[versioning]]
=== 🔢 Versionnage

Les versions sont définies à l'aide de https://git-scm.com/book/en/v2/Git-Basics-Tagging[Tags],
qui à leur tour sont https://galaxy.ansible.com/docs/contributing/version.html[reconnues et utilisées] par Ansible Galaxy.

*Les versions ne doivent pas commencer par `v`.*

Lorsqu'une nouvelle étiquette est poussée, https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/release-to-galaxy.yml[
un workflow CI GitHub]
(image:https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/release-to-galaxy.yml/badge.svg[CI de publication])
s'occupe d'importer le rôle dans mon compte Ansible Galaxy.

[[testing]]
=== 🧪 Tests
Des tests automatiques sont exécutés à chaque contribution à l'aide des workflows GitHub.

Les tests se concentrent principalement sur l’exécution de https://molecule.readthedocs.io/en/latest/[Molecule]
sur un <<tested-distributions,ensemble varié de distributions linux>>
et en utilisant <<tested-ansible-versions,various ansible versions>>.

Le test de molécule inclut également une étape qui vérifie tous les playbooks ansible utilisant
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
pour vérifier les meilleures pratiques et le comportement qui pourrait être amélioré.

Pour exécuter les tests, il suffit d'exécuter `tox` dans la ligne de commande.
Vous pouvez passer une variable d'environnement optionnelle pour définir la distribution du
conteneur Docker qui sera lancé par la molécule :

----
$ MOLECULE_DISTRO=ubuntu2204 tox
----

Pour une liste des valeurs possibles à fournir à `MOLECULE_DISTRO`,
jetez un œil à la matrice définie dans link:.github/workflows/ci.yml[].

==== 🐛 Débogage d'un conteneur Molecule

1. Exécutez vos tests de molécule avec l'option `MOLECULE_DESTROY=never`, par exemple :
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
  TÂCHE [ansible-role-pip : (raclé).] pass:[************************]
  échoué : [instance-py3-ansible-9] => changed=false
...
 pass:[___________________________________ résumé ____________________________________]
  pre-commit : les commandes ont réussi
ERREUR :   py3-ansible-9 : les commandes ont échoué
----

2. Trouvez le nom du conteneur docker provisionné par la molécule :
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf#   geerlingguy/docker-debian12-ansible:latest   "/lib/systemd/systemd"   8 minutes ago   Up 8 minutes                                                                                                    instance-py3-ansible-9
----

3. Accédez à un shell bash du conteneur et effectuez votre débogage :
+
[subs="quotes"]
----
$ *docker exec -it #30e9b8d59cdf# /bin/bash*

root@instance-py3-ansible-2:/#
----
+
[TIP]
====
Si l'échec que vous essayez de déboguer fait partie de votre étape `verify.yml` et non de la véritable `converge.yml`,
vous souhaiterez peut-être savoir que la sortie des modules Ansible (`vars`), des hôtes (`hostvars`) et
des variables d'environnement a été stockée dans des fichiers sur le provisionneur et à l'intérieur de la machine docker sous :
* `/var/tmp/vars.yml` (contient des variables hôtes sous la clé `hostvars`)
* `/var/tmp/environment.yml`
`grep`, `cat` ou transférez-les comme bon vous semble !
====
+
[TIP]
=====
Vous pouvez aussi vouloir savoir que les fichiers mentionnés dans l'avertissement ci-dessus
sont joints aux *Artifacts CI de GitHub* d'un exécution donnée. +
Cela permet de vérifier la différence entre les exécutions
et ainsi aider au débogage de ce qui a causé la défaillance ou les problèmes généraux.

image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]
=====

4. Après avoir terminé votre débogage, quittez et détruisez le conteneur :
+
[subs="quotes"]
----
root@instance-py3-ansible-2:/# *exit*

$ *docker stop #30e9b8d59cdf#*

$ *docker container rm #30e9b8d59cdf#*
_ou_
$ *docker container prune*
----

==== 🐛 Débogage des versions de paquets installés localement

Bien que cela soit une fonctionnalité standard dans tox 3, cela https://github.com/tox-dev/tox/pull/2794[ne se produit maintenant que lorsque tox reconnaît la présence d'une variable CI].
Par exemple :

----
$ CI=true tox
----


[[development-container-extra]]
=== 🧃 CONSEIL : Environnement de développement idéal conteneurisé

Ce projet offre une définition pour un "Environnement de développement conteneurisé en 1 clic".

Ce conteneur permet même d'exécuter des conteneurs docker à l'intérieur (Docker-In-Docker, dind),
permettant une exécution de molécule.

Pour l'utiliser :

1. Assurez-vous de respecter les link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
   exigences système des conteneurs de développement Visual Studio Code],
   en suivant éventuellement la section __Installation__ de la page liée. +
   Cela inclut : Installer Docker, Installer Visual Studio Code lui-même, et Installer l'extension nécessaire.
2. Clonez le projet sur votre machine
3. Ouvrez le dossier du dépôt dans Visual Studio Code (_Fichier - Ouvrir le dossier…_).
4. Si vous recevez une invite dans le coin inférieur droit vous informant de la présence de la définition du conteneur de développement,
vous pouvez appuyer sur le bouton associé pour y entrer.
*Sinon,* vous pouvez aussi exécuter la commande Visual Studio `Remote-Containers: Ouvrir le dossier dans le conteneur` vous-même (_Afficher - Palette de commandes_ -> _taper la commande mentionnée_).

[TIP]
====
Je recommande d'utiliser `Remote-Containers: Rebuild Without Cache and Reopen in Container`
de temps en temps, car la fonctionnalité de conteneur de développement rencontre parfois des problèmes pour reconnaître correctement
les changements apportés à sa définition.
====

[NOTE]
=====
Vous devrez peut-être configurer votre système hôte pour permettre au conteneur d'utiliser vos clés SSH/GPG.

La procédure est décrite https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[
dans la documentation officielle des conteneurs de développement sous "Partage des informations d'identification Git avec votre conteneur"].
=====


[[cookiecutter]]
=== 🍪 CookieCutter

Ce projet doit être maintenu en synchronisation avec
https://github.com/JonasPammer/cookiecutter-ansible-role[le cookiecutter dont il a été initialement modélisé]
en utilisant https://github.com/cruft/cruft[cruft] (si possible) ou par modifications manuelles (si nécessaire)
dans la mesure du possible.

.Exemple d'utilisation officielle de `cruft update`
____
image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Exemple officiel d'utilisation de `cruft update`]
____

==== 🕗 Journal des modifications
Lorsqu'une nouvelle étiquette est poussée, un GitHub Release approprié sera créé
par le mainteneur du dépôt pour fournir un journal de modifications humain avec un titre et une description.


[[pre-commit]]
=== ℹ️ Conventions générales de linting et de style
Les conventions générales de linting et de style sont
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*automatiquement* respectées]
par divers https://pre-commit.com/[hooks `pre-commit`], au moins dans une certaine mesure.

L'exécution automatique de pre-commit est effectuée à chaque contribution utilisant
https://pre-commit.ci[`pre-commit.ci`]<<note_pre-commit-ci,*>>.
Les demandes de tirage sont même automatiquement corrigées par le même outil,
au moins par des hooks qui modifient automatiquement les fichiers.

[NOTE]
====
Pour ne pas confondre :
Bien que certains hooks de pré-commit puissent être en mesure de vous avertir des fautes analysées dans la syntaxe ou même le code dans une certaine mesure (pour cette raison, les hooks de pré-commit font *partie de* la suite de tests),
le pré-commit lui-même n'exécute aucune suite de tests réelle.
Pour des informations sur les tests, voir <<testing>>.
====

[TIP]
====
[[note_pre-commit-ci]]
Néanmoins, je vous recommande d'intégrer le pré-commit dans votre propre flux de développement local.

Cela peut être fait en se rendant dans le répertoire de votre projet cloné et en exécutant `pre-commit install`.
Cela rendra git exécutera les vérifications de pré-commit à chaque commit que vous effectuez,
abrogeant les commits eux-mêmes si un hook a déclenché une alerte.

Vous pouvez également, par exemple, exécuter les hooks de pré-commit à tout moment en exécutant `pre-commit run --all-files`.
====


[[contributing]]
== 💪 Contribuer
image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[PRs Bienvenues]
https://open.vscode.dev/JonasPammer/ansible-role-apache2[image:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Ouvrir%20dans%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Ouvrir dans Visual Studio Code]]

// Inclus dans README.adoc
:toc:
:toclevels: 3

Les sections suivantes sont de nature générique et sont utilisées pour aider les nouveaux contributeurs.
La véritable "Documentation de développement" de ce projet se trouve sous <<development>>.

=== 🤝 Préambule
Tout d'abord, merci de prendre en considération la possibilité de contribuer à ce projet.

Suivre ces directives aide à communiquer que vous respectez le temps des développeurs gérant et développant ce projet open source.
En retour, ils devraient réciproquer ce respect en répondant à votre problème, en évaluant les changements et en vous aidant à finaliser vos demandes de tirage.

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Ce projet doit de nombreux fichiers à
https://github.com/JonasPammer/cookiecutter-ansible-role[le cookiecutter dont il a été initialement modélisé].

Veuillez vérifier si la modification que vous envisagez est réellement applicable au modèle
et si oui faites un changement approprié là-bas au lieu de cela.
Votre changement peut également être applicable en partie au modèle
et en partie à quelque chose de spécifique à ce projet,
dans quel cas vous créeriez plusieurs PRs.

=== 💬 Commits conventionnels

Un contributeur occasionnel n'a pas à se soucier de suivre
https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__le spécifié__]
https://www.conventionalcommits.org/en/v1.0.0/[__par définition__],
puisque les demandes de tirage sont fusionnées en un seul commit dans le projet.
Seuls les contributeurs principaux, c'est-à-dire ceux ayant le droit de pousser dans les branches de ce projet, doivent le suivre
(par exemple pour permettre à la détermination automatique de la version et à la génération de journal des modifications de fonctionner).

=== 🚀 Premiers pas

Les contributions à ce dépôt se font par le biais de problèmes et de demandes de tirage (PRs).
Voici quelques directives générales qui couvrent les deux :

* Recherchez les problèmes et PRs existants avant de créer le vôtre.
* Si vous n'avez jamais contribué auparavant, consultez https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
  le guide pour les débutants sur le blog d'Auth0] pour des ressources et des conseils sur la façon de commencer.

==== Problèmes

Les problèmes devraient être utilisés pour signaler des problèmes, demander une nouvelle fonctionnalité, ou discuter de changements potentiels *avant* qu'une PR soit créée.
Lorsque vous https://github.com/JonasPammer/ansible-role-apache2/issues/new[
créez un nouveau problème], un modèle sera chargé qui vous guidera à travers la collecte et la fourniture des informations dont nous avons besoin pour enquêter.

Si vous trouvez un problème qui concerne le problème que vous rencontrez,
ajoutez vos propres informations de reproduction au problème existant *plutôt que d'en créer un nouveau*.
Ajouter une https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[réaction]
peut également aider à indiquer à nos mainteneurs qu'un problème particulier affecte plus que juste le rapporteur.

==== Demandes de tirage

Les PRs pour ce projet sont toujours les bienvenues et peuvent être un moyen rapide de faire figurer votre correction ou amélioration dans la prochaine version.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[En général], les PRs devraient :

* Corriger/ajouter uniquement la fonctionnalité en question *OU* traiter des problèmes de style/espace à large échelle, pas les deux.
* Ajouter des tests unitaires ou d'intégration pour la fonctionnalité corrigée ou modifiée (si une suite de tests existe déjà).
* *Traiter d'une seule préoccupation*
* *Inclure de la documentation* dans le dépôt
* Être accompagnée d'un modèle de demande de tirage complet (chargé automatiquement lors de la création d'une PR).

Pour les changements qui touchent à la fonctionnalité de base ou nécessiteraient des changements majeurs (par exemple une version majeure),
il est préférable d'ouvrir un problème pour discuter de votre proposition d'abord.

En général, nous suivons le flux de travail "fork-and-pull" de Git

1. Forkez le dépôt sur votre propre compte Github
2. Clonez le projet sur votre machine
3. Créez une branche localement avec un nom succinct mais descriptif
4. Engagez les changements dans la branche
5. Suivez toutes les lignes directrices de formatage et de test spécifiques à ce dépôt
6. Poussez les changements vers votre fork
7. Ouvrez une PR dans notre dépôt et suivez le modèle de PR afin que nous puissions examiner efficacement les changements.


[[changelog]]
== 🗒 Journal des modifications
Veuillez vous référer à la
https://github.com/JonasPammer/ansible-role-apache2/releases[Page des versions de ce dépôt]
pour un journal des modifications humain correspondant aux
https://github.com/JonasPammer/ansible-role-apache2/tags[Tags (Versions) de ce projet].

Notez que ce projet adhère à la Version Sémantique.
Veuillez signaler tout changement accidentel provoquant un bris de compatibilité lors de la mise à jour d'une version mineure.


[[license]]
== ⚖️ Licence

.link:LICENSE[]
----
Licence MIT

Copyright (c) 2022, Jonas Pammer

Par la présente, il est accordé, sans frais, à toute personne obtenant une copie
de ce logiciel et des fichiers de documentation associés (le "Logiciel"), de traiter
dans le Logiciel sans restriction, y compris sans limitation les droits
d'utiliser, de copier, de modifier, de fusionner, de publier, de distribuer, de sous-licencier et/ou de vendre
des copies du Logiciel, et de permettre à des personnes auxquelles le Logiciel est fourni de le faire, sous réserve des conditions suivantes :

L'avis de droit d'auteur ci-dessus et cet avis de permission doivent être inclus dans toutes
copies ou parties substantielles du Logiciel.

LE LOGICIEL EST FOURNI "EN L'ÉTAT", SANS GARANTIE D'AUCUNE SORTE, EXPRESSE OU
IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER AUX GARANTIES DE COMMERCIALITÉ,
D'ADÉQUATION À UN OBJECTIF PARTICULIER ET DE NON-VIOLATION. EN AUCUN CAS, LES
AUTEURS OU TITULAIRES DE DROIT D'AUTEUR NE PEUVENT ÊTRE TENUS RESPONSABLES DE TOUTE RÉCLAMATION, DOMMAGE OU AUTRE
RESPONSABILITÉ, QUE CE SOIT EN ACTION DE CONTRAT, DELIT OU AUTRE, DÉCOULANT DE,
HORS DE OU EN LIEN AVEC LE LOGICIEL OU L'UTILISATION OU AUTRES UTILISATIONS DU LOGICIEL.
----