jonaspammer.apache2
// Este archivo se está generando por .github/workflows/gh-pages.yml - ¡todas las modificaciones locales se perderán eventualmente!
= ansible-role-apache2
Jonas Pammer <[email protected]>;
:toc: izquierda
:toclevels: 2
:toc-placement!:
:source-highlighter: rouge
https://galaxy.ansible.com/jonaspammer/apache2[imagen:https://img.shields.io/badge/disponible%20en%20ansible%20galaxy-jonaspammer.apache2-brightgreen[Versión en Galaxy]]
// Insignias de estado muy relevantes
https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/ci.yml[imagen:https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/ci.yml/badge.svg[Pruebas CI]]
Un rol de Ansible para instalar Apache2, habilitar/deshabilitar módulos, configurar sus valores predeterminados y crear hosts virtuales.
toc::[]
[[meta]]
== 🔎 Metadatos
A continuación, puedes encontrar información sobre…
* la versión de Ansible requerida por el rol
* las plataformas soportadas por el rol
* las https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[dependencias del rol]
.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
role_name: "apache2"
description:
"Un rol de ansible para instalar Apache2, habilitar/deshabilitar módulos,
configurar sus valores predeterminados y crear hosts virtuales.
Basado en el rol de apache2 de geerlingguy."
author: "jonaspammer"
license: "MIT"
min_ansible_version: "2.11"
platforms:
- name: EL # (Enterprise Linux)
versions:
- "9" # probado activamente: rockylinux9
- name: Fedora
versions:
- "38" # probado activamente: fedora38
- "39" # probado activamente: fedora39
- name: Debian
versions:
- bullseye # probado activamente: debian11
- bookworm # probado activamente: debian12
- name: Ubuntu
versions:
- focal # probado activamente: ubuntu2004
- jammy # probado activamente: ubuntu2204
galaxy_tags:
- web
- apache
- servidor web
- html
- httpd
dependencies: []
allow_duplicates: true
----
[[requirements]]
== 📌 Requisitos
// Cualquier requisito previo que puede no estar cubierto por este rol o por Ansible debería ser mencionado aquí.
El usuario de Ansible necesita poder `become`.
Si estás usando SSL/TLS (<<apache_vhosts_ssl>>), necesitarás proporcionar tus propios archivos de certificado y clave.
Si estás usando Apache con PHP, recomiendo usar el
https://github.com/geerlingguy/ansible-role-php/[rol geerlingguy.php]
para instalar PHP, y puedes usar `mod_php`
(adicionando el paquete apropiado, por ejemplo `libapache2-mod-php5` para Ubuntu, a `php_packages`),
o usando
https://github.com/geerlingguy/ansible-role-apache-php-fpm[`geerlingguy.apache-php-fpm`]
para conectar Apache a PHP a través de FPM.
Por favor consulta los README de los roles vinculados para más información específica.
Al dirigirse a sistemas basados en Solaris,
la https://galaxy.ansible.com/community/general[`colección community.general`]
(que contiene el módulo `pkg5`) debe estar instalada en el controlador de Ansible.
Al dirigirse a sistemas basados en Suse,
la https://galaxy.ansible.com/community/general[`colección community.general`]
(que contiene el módulo `zypper`) debe estar instalada en el controlador de Ansible.
[[variables]]
== 📜 Variables del rol
// Aquí debería ir una descripción de las variables que se pueden establecer para este rol
// y cualquier variable que se puede/debe establecer a través de parámetros al rol.
// Cualquier variable que se lea de otros roles y/o del ámbito global (es decir, hostvars, vars de grupo, etc.)
// también debe mencionarse aquí.
[source,yaml]
----
apache_mods_enabled:
- rewrite
- ssl
apache_mods_disabled: []
----
(Solo Debian/RHEL)
Módulos de Apache para habilitar o deshabilitar (se vincularán en la ubicación apropiada).
Consulta el directorio `mods-available` (Debian) / `conf.modules.d` (RHEL) dentro de <<apache__server_root_dir, directrio raíz de apache>> para todos los módulos disponibles.
[source,yaml]
----
apache_listen_ip: "*"
apache_listen_port: 80
apache_listen_port_ssl: 443
----
La dirección IP y los puertos en los que Apache debe estar escuchando.
Útil si tienes otro servicio (como un proxy inverso) escuchando
en el puerto 80 o 443 y necesitas cambiar los valores predeterminados.
[source,yaml]
----
apache_remove_default_vhost: false
----
En Debian/Ubuntu, un vhost predeterminado se incluye en la configuración de Apache.
Establece esto en `true` para eliminar ese predeterminado.
[source,yaml]
----
apache_state: started
----
Establece el estado inicial de Apache.
Valores recomendados: `started` o `stopped`
[source,yaml]
----
apache_enabled: true
----
Establece el estado inicial del servicio Apache.
Valores recomendados: `true` o `false`
[source,yaml]
----
apache_restart_state: restarted
----
Establece el estado en el que se pondrá Apache cuando se realice un cambio de configuración
(es decir, cuando se llame al controlador `restart apache`).
Valores recomendados: `restarted` o `reloaded`
[[apache_default_favicon]]
[source,yaml]
----
apache_default_favicon: favicon.ico
----
Ruta a un archivo en el controlador de Ansible local que se copiará al servidor
y se usará por Apache como un favicon predeterminado.
=== Variables del rol usadas para la instalación
[source,yaml]
----
apache_packages: [Específicas del SO por defecto, consulta el directorio /defaults]
----
Una lista de nombres de paquetes para instalar Apache2 y utilidades más necesarias.
[source,yaml]
----
apache_packages_state: present
----
Si has habilitado repositorios adicionales como
https://launchpad.net/~ondrej/+archive/ubuntu/apache2[`ondrej/apache2`],
https://fedoraproject.org/wiki/EPEL[`EPEL`], o
http://rpms.remirepo.net/[`remi`],
puedes querer una forma sencilla de actualizar versiones.
Para asegurarlo, establece esto a `latest`.
[source,yaml]
----
apache_enablerepo: ""
----
(Solo RHEL/CentOS)
El https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_module.html#parameter-enablerepo[repositorio]
a utilizar al instalar Apache.
Si deseas versiones posteriores de Apache que las disponibles en los repositorios principales del SO,
usa un repositorio como
https://fedoraproject.org/wiki/EPEL[EPEL]
(que puede instalarse con el rol `repo-epel`).
=== Variables del rol utilizadas para crear hosts virtuales
[TIP]
Dirígete a la sección <<example_playbooks>> para
ejemplos que muestran cómo puede lucir el archivo VirtualHost generado.
[NOTE]
====
Este rol intenta asegurar una configuración apache *funcionante* ejecutando
https://httpd.apache.org/docs/2.4/programs/httpd.html[pruebas de sintaxis para todos los archivos de configuración (`-t`)]
y revirtiendo el vhost generado si ocurrió un error.
====
[source,yaml]
----
apache_create_vhosts: true
apache_vhosts_filename: "vhosts.conf"
apache_vhosts_template: "vhosts.conf.j2"
----
Si se establece en `true`, se creará un archivo vhosts administrado por las variables de este rol (ver más abajo),
y se colocará en la carpeta de configuración de Apache.
Si se establece en `false`, puedes colocar tu propio archivo vhosts en la carpeta de configuración de Apache y omitir el conveniente (pero más básico) que agrega este rol.
También puedes sobrescribir la plantilla usada y establecer una ruta a tu propia plantilla,
si necesitas personalizar aún más el diseño de tu VirtualHost.
[source,yaml]
----
apache_global_vhost_settings: |
DirectoryIndex index.php index.html
----
Esta variable se utiliza *_fuera de cualquier Directiva <VirtualHost>_*
en el archivo vhost generado.
[WARNING]
=====
Aquí cambias las configuraciones aplicadas al contexto general de Apache
(en lugar de cambiar las configuraciones aplicadas a, por ejemplo, un `<VirtualHost>`/ `<Directory>`/…).
Una cosa a entender con este valor predeterminado es que
*el `DirectoryIndex` no _establece_ sino que _apende* (lo que significa que no revertimos ninguna otra configuración realizada),
como se indica en su página de documentación:
[quote,https://httpd.apache.org/docs/2.4/mod/mod_dir.html]
____
Múltiples directivas `DirectoryIndex` dentro del mismo contexto agregarán
a la lista de recursos a buscar en lugar de reemplazar.
____
=====
[source,yaml]
----
apache_vhosts:
- servername: "local.dev"
documentroot: "/var/www/html"
----
Para cada entrada en esta lista,
se generará una Directiva `<VirtualHost>` escuchando en
`{{ apache_listen_ip }}:{{ apache_listen_port }}`.
Cada entrada de una lista puede tener las siguientes propiedades
(Consulta la sección <<example_playbooks>> para Ejemplos.
Consulta las páginas de documentación oficiales vinculadas para la documentación
de las directivas de Apache que representan).
`https://httpd.apache.org/docs/2.4/mod/core.html#servername[servername]` (requerido)::
`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]`::
Directiva `AllowOverride` utilizada dentro del `<Directory>` del `DocumentRoot`. +
Predeterminado al valor de `apache_vhosts_default_documentroot__allowoverride`.
`documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#options[options]`::
Directiva `Options` utilizada dentro del `<Directory>` del `DocumentRoot`. +
Predeterminado al valor 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]`::
Ya sea una cadena (representando la ruta, no se cita automáticamente) o un tipo de dato complejo:
+
====
`path`::
Ruta. Se citará en `"`.
`extra`::
Cadena adicional para agregar después de `path`.
`extra_parameters`::
Esta variable se inserta tal cual *antes* de la declaración `ErrorLog`
(con una sangría de 2).
+
El caso de uso para este parámetro puede ser habilitar registros condicionales usando
`SetEnvIf` / `SetEnv` o establecer un `LogFormat` personalizado para este ErrorLog
https://httpd.apache.org/docs/2.4/logs.html[Documentación principal de Apache].
====
[[apache_vhosts__customlogs]]
`https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#customlog[customlogs]`::
Array de CustomLogs.
Cada entrada puede ser una cadena (no se cita automáticamente)
o un tipo de dato complejo:
+
====
`path`::
Ruta. Se citará en `"`.
`extra`::
Cadena adicional para agregar después de `path`.
No se cita
(para permitir los complejos parámetros opcionales adicionales de CustomLog que uno puede querer proporcionar).
`extra_parameters`::
Esta variable se inserta tal cual *antes* de la declaración `CustomLog`
(con una sangría de 2).
+
El caso de uso para este parámetro puede ser habilitar registros condicionales usando
`SetEnvIf` / `SetEnv` o establecer un `LogFormat` personalizado para este CustomLog específico
según https://httpd.apache.org/docs/2.4/logs.html[Documentación de mod_log_config de Apache].
====
`extra_parameters`::
Esta variable se inserta tal cual en el final del `<VirtualHost>` en bucle (con una sangría de 2).
[[apache_vhosts_ssl]]
[source,yaml]
----
apache_vhosts_ssl: []
----
Para cada entrada en esta lista,
se generará una Directiva `<VirtualHost>` escuchando en
`{{ apache_listen_ip }}:{{ apache_listen_port_ssl }}`.
Cada entrada de una lista puede tener las siguientes propiedades
(Consulta la sección <<example_playbooks>> para Ejemplos)
(Consulta las páginas de documentación oficiales vinculadas para la documentación
de las directivas de Apache que representan).
`https://httpd.apache.org/docs/2.4/mod/core.html#servername[servername]` (requerido)::
`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]`::
Directiva `AllowOverride` utilizada dentro del `<Directory>` del `DocumentRoot`. +
Predeterminado a `apache_vhosts_default_documentroot__allowoverride`.
`documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#options[options]`::
Directiva `Options` utilizada dentro del `<Directory>` del `DocumentRoot`.
Predeterminado a `apache_vhosts_default_documentroot__options`.
`no_actual_ssl`::
Si se establece en True, el `<VirtualHost>` no tendrá opciones SSL*.
Utilizado solo cuando deseas una redirección de http a https que has definido en `extra_parameters`.
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile[ssl_certificate_file] (requerido)::
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatekeyfile[ssl_certificate_key_file] (requerido)::
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatechainfile[ssl_certificate_chain_file]::
_Nota: Esto está en desuso._
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]`::
Equivalente a <<apache_vhosts__errorlog,apache_vhosts.errorlog>>.
`https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#customlog[customlogs]`::
Array de CustomLogs.
Equivalente a <<apache_vhosts__customlogs,apache_vhosts.customlogs>>.
`extra_parameters`::
Esta variable se inserta tal cual en el final del `<VirtualHost>` en bucle (con una sangría de 2).
[source,yaml]
----
apache_ignore_missing_ssl_certificate: true
----
Si se establece en `false`, una entrada dada de `apache_vhosts_ssl`
solo se generará si su `sslcertificatefile` existe.
[source,yaml]
----
apache_ssl_protocol: "All -SSLv2 -SSLv3"
apache_ssl_cipher_suite: "AES256+EECDH:AES256+EDH"
----
Estas variables se utilizan como predeterminadas para cada `apache_vhosts_ssl`.
Están nombradas de la misma manera que se utilizan en dichas variables del rol
(excepto por su prefijo, por supuesto).
Consulta https://httpd.apache.org/docs/current/mod/mod_ssl.html[
Documentación de Apache]
para la documentación de las directivas de Apache que representan.
[source,yaml]
----
apache_vhosts_default_documentroot__allowoverride: "All"
apache_vhosts_default_documentroot__options: "-Indexes +FollowSymLinks"
----
[[public_vars]]
== 📜 Hechos/Variables definidas por este rol
Cada variable listada en esta sección
se define dinámicamente al ejecutar este rol (y solo se puede sobrescribir utilizando `ansible.builtin.set_facts`) _y_
se destinan a ser utilizadas no solo internamente.
[[apache__service]]
.`pass:[apache__service]`
****
.Ejemplo de uso fuera de este rol:
[source,yaml]
----
# archivo de controladores para roles.xyz
- name: reiniciar apache2
ansible.builtin.service:
name: "{{ apache__service | default('apache2') }}"
state: restarted
----
****
[[apache__daemon]]
.`pass:[apache__daemon_dir]`, `pass:[apache__daemon]`
****
Nombre y directorio ejecutable del comando `apache2`.
****
[[apache__server_root_dir]]
.`pass:[apache__server_root_dir]`
****
Directorio que contiene toda la configuración de Apache2 (en `/etc`).
****
[[debian_is_different_note]]
[NOTE]
====
Cuando trabajes con cualquiera de los valores de configuración a continuación debes recordar:
[quote, Comentario encontrado en la /etc/apache2/apache2.conf de Debian 10]
______
La configuración del servidor web Apache 2 en *Debian es bastante diferente a
la forma recomendada por upstream* para configurar el servidor web. Esto se debe a que la
instalación predeterminada de Apache2 de Debian intenta hacer que agregar y quitar módulos,
hosts virtuales y directivas de configuración adicionales sea lo más flexible posible, con el fin de facilitar la automatización de los cambios y la administración del servidor.
______
Esto significa que la `pass:[apache__server_root_dir]`
*en Debian* se ve así:
.`tree /etc/apache2` de una máquina recién instalada de Debian 10 después de la instalación de 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
----
Mientras que #en otros sistemas se ve así#:
.`tree /etc/apache2` de una máquina recién instalada de CentOS 8 después de la instalación de 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]`
****
Archivo de configuración principal de Apache2,
que http://httpd.apache.org/docs/2.4/mod/core.html#include[
`Include`]'s todos los demás archivos y contiene algunas otras directivas por sí mismo.
.Viendo cómo se incluye lo que está incluido
[TIP]
====
Directivas de inclusión de Apache2 en Debian como se encuentran en `pass:[apache__primary_configuration_file_path]`:
[source,ini]
----
# Incluir configuración de módulo:
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
# Incluir lista de puertos a los que escuchar
Include ports.conf
# Incluir directorios ignora archivos de respaldo de editores y dpkg,
# Incluir fragmentos genéricos de declaraciones
IncludeOptional conf-enabled/*.conf
# Incluir las configuraciones de host virtual:
IncludeOptional sites-enabled/*.conf
----
Directivas de inclusión de Apache2 en RHEL según se encuentran en `pass:[apache__primary_configuration_file_path]` en una máquina CentOS 8:
[source,ini]
----
# Soporte para objetos compartidos dinámicos (DSO)
#
# Para poder utilizar la funcionalidad de un módulo que se construyó como DSO,
# debes colocar las líneas correspondientes `LoadModule` en esta ubicación para que
# las directivas contenidas en ella estén realmente disponibles _antes_ de que se utilicen.
# Los módulos compilados estáticamente (los listados por `httpd -l`) no necesitan ser cargados aquí.
#
# Ejemplo:
# LoadModule foo_module modules/mod_foo.so
Include conf.modules.d/*.conf
# Configuración supletoria:
IncludeOptional conf.d/*.conf
----
====
[[apache__ports_configuration_file]]
.`pass:[apache__ports_configuration_file]`
*****
Archivo de configuración de Apache2 que alberga las directivas utilizadas
para determinar los puertos de escucha para conexiones entrantes.
En algunos sistemas, este es el mismo que `pass:[apache__primary_configuration_file_path]`,
pero en algunos es un archivo propio que se está incluyendo
http://httpd.apache.org/docs/2.4/mod/core.html#include[
`Include`]-ed por dicho `pass:[apache__primary_configuration_file_path]`.
*****
[[apache__server_conf_dir]]
.`pass:[apache__server_conf_dir]`
****
Directorio que alberga todos los archivos http://httpd.apache.org/docs/2.4/mod/core.html#include[
`Include`]-ados.
Este directorio puede no ser `Include`-ado en sí, pero tener subdirectorios que son `Include`-ados.
Consulta la NOTA/TIP en <<apache__primary_configuration_file_path>>
para saber qué directorios se están `Include`-ados por defecto en diferentes OS.
****
[[apache__default_log_dir]]
.`pass:[apache__default_log_dir]`
****
Directorio en `/var` utilizado por defecto para todos los hosts virtuales.
El siguiente resumen muestra el contenido típico de archivo predeterminado
de esta carpeta para las principales distribuciones:
.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]]
== 🏷️ Etiquetas
// Consulta https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags
// para un ejemplo increíble de agrupación de tareas utilizando etiquetas
Las tareas están etiquetadas con las siguientes
https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[etiquetas]:
[cols="1,1"]
|===
|Etiqueta | Propósito
2+| Este rol aún no tiene etiquetas documentadas oficialmente.
// | descargar-xyz
// |
// | instalar-requisitos
// |
// | instalar
// |
// | crear-xyz
// |
|===
Puedes usar Ansible para omitir tareas, o solo ejecutar ciertas tareas utilizando estas etiquetas. Por defecto, se ejecutan todas las tareas cuando no se especifican etiquetas.
[[dependencies]]
== 👫 Dependencias
// Aquí debería ir una lista de otros roles,
// así como cualquier detalle en relación a los parámetros que pueden necesitar configurarse para otros roles,
// o variables que se utilizan de otros roles.
[[example_playbooks]]
== 📚 Ejemplos de uso de Playbooks
// Incluir ejemplos de cómo usar este rol en un playbook para escenarios comunes siempre es bueno para los usuarios.
[NOTE]
====
Este rol es parte de https://github.com/JonasPammer/ansible-roles[
muchos roles específicos de propósito compatibles que poseo].
La máquina necesita ser preparada.
En CI, esto se hace en `molecule/resources/prepare.yml`
que obtiene sus dependencias blandas de `requirements.yml`:
.link:molecule/resources/prepare.yml[]
[source,yaml]
----
---
- name: preparar
hosts: todos
become: true
gather_facts: false
roles:
- role: jonaspammer.bootstrap
# - name: jonaspammer.core_dependencies
----
El siguiente diagrama es una recopilación de las "dependencias blandas" de este rol
así como el árbol recursivo de sus dependencias blandas.
image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_apache2.svg[
gráfico de dependencias de requirements.yml para jonaspammer.apache2]
====
.Instalación estándar (sin variables)
====
* El siguiente yaml:
+
[source,yaml]
----
roles:
- role: jonaspammer.apache2
----
+
genera el siguiente VirtualHost:
+
[source]
-----
# Gestionado por 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>
-----
+
Para referencia, este es el vhost predeterminado entregado con sistemas Debian/Ubuntu
(que puede ser eliminado estableciendo `apache_remove_default_vhost` a verdadero)
+
[source]
-----
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
-----
Dados sin configuración de rol, las desviaciones de solo instalar Apache2 tú mismo son
* ciertos módulos se activan por defecto (`<<apache_mods_enabled>>`).
* el sistema tendrá el VirtualHost demostrado arriba
* Al instalar inicialmente, un archivo llamado `favicon.ico` (proveniente de <<apache_default_favicon>>) se colocará en `/var/www/html`
si no había un archivo con dicho nombre antes. Este favicon, por defecto, se asemeja al logotipo de Ansible encontrado en Wikimedia.
_Por favor, ten en cuenta que este rol no elimina el contenido de `/var/www/html`
(ni siquiera si fue creado por/después de la instalación inicial de apache2)._
====
.Logging
====
* El siguiente yaml:
+
[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"
----
+
genera el siguiente VirtualHost:
+
[source]
-----
# Gestionado por Ansible.
TODO
-----
====
.Uso de `extra_parameters`
====
[TIP]
======
El símbolo de tubería al final de una línea en YAML significa que cualquier texto sangrado que siga
debería ser interpretado como un valor escalar de múltiples líneas.
Consulta https://yaml-multiline.info/[yaml-multiline.info] para una explicación interactiva.
======
* El siguiente yaml:
+
[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: |
# Redirigir todas las solicitudes al subdominio 'www'. Apache 2.4+
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://www.%{HTTP_HOST}%{REQUEST_URI} [R=302,L]
----
+
genera el siguiente VirtualHost:
+
[source]
-----
# Gestionado por Ansible.
TODO
-----
* El siguiente yaml:
+
[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 }}
----
+
genera el siguiente VirtualHost:
+
[source]
-----
# Gestionado por Ansible.
DirectoryIndex index.php index.html
<VirtualHost *:80>
ServerName srvcmk.intra.jonaspammer.com
Redirect / http://srvcmk.intra.jonaspammer.at/master
</VirtualHost>
-----
====
.Creando tu propio archivo de virtualhost / Integrar en un rol
====
_El rol apache2 puede ejecutarse múltiples veces en un play, con el propósito principal de
https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#using-allow-duplicates-true[esta autorización]
para poder crear hosts virtuales._
[source,yaml,subs="+quotes,macros"]
----
- tasks:
pass:[#]...
- name: Generar VirtualHost de 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]]
== 🧪 Distribuciones probadas
Un rol puede funcionar en diferentes *distribuciones*, como Red Hat Enterprise Linux (RHEL),
aunque no haya pruebas para esta distribución exacta.
// buena referencia para seguir -- el proyecto más estrella y fijado de geerlingguy:
// https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml
|===
| Familia de OS | Distribución | Fecha de lanzamiento de la distribución | Fin de vida de la distribución | Imagen de Docker correspondiente
// https://endoflife.date/rocky-linux
| Rocky
| Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 disfrazado])
| 2021-06
| 2029-05
| https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[imagen: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[imagen:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]
// https://endoflife.date/fedora (13 meses)
| RedHat
| Fedora 39
| 2023-11
| 2024-12
| https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[imagen: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[imagen: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[imagen:https://github.com/geerlingguy/docker-ubuntu2204-ansible/workflows/Build/badge.svg?branch=master[CI]]
| Debian
| Debian 11
| 2021-08
| 2024-06 (2026-06 LTS)
| https://github.com/geerlingguy/docker-debian11-ansible/actions?query=workflow%3ABuild[imagen: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[imagen:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]]
|===
[[tested-ansible-versions]]
== 🧪 Versiones de Ansible probadas
Las versiones de Ansible probadas intentan mantenerse equivalentes al
https://github.com/ansible-collections/community.general#tested-with-ansible[
patrón de soporte de la colección `community.general` de Ansible].
A la fecha de esta escritura es:
* 2.13 (Ansible 6)
* 2.14 (Ansible 7)
* 2.15 (Ansible 8)
* 2.16 (Ansible 9)
[[development]]
== 📝 Desarrollo
// Insignias sobre convenciones en este proyecto
https://conventionalcommits.org[imagen:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Commits Convencionales]]
https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-apache2/master[imagen:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-apache2/master.svg[estado de pre-commit ci]]
// 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]]
=== 📌 Dependencias de la máquina de desarrollo
* Python 3.10 o mayor
* Docker
[[development-dependencies]]
=== 📌 Dependencias de desarrollo
Las dependencias de desarrollo se definen en un
https://pip.pypa.io/en/stable/user_guide/#requirements-files[archivo de requisitos de pip]
llamado `requirements-dev.txt`.
A continuación se muestran instrucciones de instalación de ejemplo para Linux:
----
# "opcional": crea un entorno virtual de python y actívalo para la sesión actual de terminal
$ python3 -m venv venv
$ source venv/bin/activate
$ python3 -m pip install -r requirements-dev.txt
----
[[development-guidelines]]
=== ℹ️ Directrices de desarrollo de roles de Ansible
Por favor, echa un vistazo a mis https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[
Directrices de desarrollo de roles de Ansible].
Si te interesa, también he escrito algunas
https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[
Mejores (prácticas) de desarrollo de roles de Ansible].
[[versioning]]
=== 🔢 Versionado
Las versiones se definen utilizando https://git-scm.com/book/en/v2/Git-Basics-Tagging[Etiquetas],
que a su vez son https://galaxy.ansible.com/docs/contributing/version.html[reconocidas y utilizadas] por Ansible Galaxy.
*Las versiones no deben comenzar con `v`.*
Cuando se pulsa una nueva etiqueta, https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/release-to-galaxy.yml[
un flujo de trabajo de CI de GitHub]
(imagen:https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/release-to-galaxy.yml/badge.svg[CI de lanzamiento])
se encarga de importar el rol a mi cuenta de Ansible Galaxy.
[[testing]]
=== 🧪 Pruebas
Las pruebas automáticas se ejecutan en cada contribución utilizando los flujos de trabajo de GitHub.
Las pruebas se centran principalmente en ejecutar https://molecule.readthedocs.io/en/latest/[Molecule]
en un <<tested-distributions, conjunto variable de distribuciones de linux>>
y utilizando <<tested-ansible-versions,varias versiones de ansible>>.
La prueba de molécula también incluye un paso que analiza todos los playbooks de ansible utilizando
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
para verificar las mejores prácticas y comportamientos que podrían mejorarse.
Para ejecutar las pruebas, simplemente ejecuta `tox` en la línea de comandos.
Puedes pasar una variable de entorno opcional para definir la distribución del
contenedor de Docker que se iniciará mediante la molécula:
----
$ MOLECULE_DISTRO=ubuntu2204 tox
----
Para obtener una lista de los posibles valores que se pasan a `MOLECULE_DISTRO`,
echa un vistazo a la matriz definida en link:.github/workflows/ci.yml[].
==== 🐛 Depuración de un contenedor de molécula
1. Ejecuta tus pruebas de molécula con la opción `MOLECULE_DESTROY=never`, por ejemplo:
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
TASK [ansible-role-pip : (redacted).] pass:[************************]
failed: [instance-py3-ansible-9] => changed=false
...
pass:[___________________________________ resumen ____________________________________]
pre-commit: los comandos tuvieron éxito
ERROR: py3-ansible-9: los comandos fallaron
----
2. Descubre el nombre del contenedor de docker provisionado por la molécula:
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf# geerlingguy/docker-debian12-ansible:latest "/lib/systemd/systemd" hace 8 minutos Arriba hace 8 minutos instance-py3-ansible-9
----
3. Entra en un shell de bash del contenedor y haz tu depuración:
+
[subs="quotes"]
----
$ *docker exec -it #30e9b8d59cdf# /bin/bash*
root@instance-py3-ansible-2:/#
----
+
[TIP]
====
Si el fallo que intentas depurar es parte de tu paso `verify.yml` y no del `converge.yml` real,
puede que desees saber que la salida de los módulos de ansible (`vars`), hosts (`hostvars`) y
variables de entorno se han guardado en archivos en ambos, el aprovisionador y dentro de la máquina docker en:
* `/var/tmp/vars.yml` (contiene las variables de host bajo la clave `hostvars`)
* `/var/tmp/environment.yml`
`grep`, `cat` o transfiere estos como desees!
====
+
[TIP]
=====
También puede que quieras saber que los archivos mencionados en la advertencia anterior
se adjuntan a los *Artefactos de CI de GitHub* de una ejecución de flujo de trabajo dada. +
Esto permite verificar la diferencia entre ejecuciones
y, por lo tanto, ayudar en la depuración de la causa del problemas o fallo en general.
image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]
=====
4. Después de que termines de depurar, sal y destruye el contenedor:
+
[subs="quotes"]
----
root@instance-py3-ansible-2:/# *exit*
$ *docker stop #30e9b8d59cdf#*
$ *docker container rm #30e9b8d59cdf#*
_o_
$ *docker container prune*
----
==== 🐛 Depuración de versiones de paquetes instalados localmente
Aunque es una característica estándar en tox 3, este https://github.com/tox-dev/tox/pull/2794[ahora] solo ocurre cuando tox reconoce la presencia de una variable de CI.
Por ejemplo:
----
$ CI=true tox
----
[[development-container-extra]]
=== 🧃 TIP: Entorno de desarrollo ideal en contenedor
Este proyecto ofrece una definición para un "Entorno de Desarrollo en Contenedor con un Clic".
Este contenedor incluso permite ejecutar contenedores de docker dentro de él (Docker-In-Docker, dind),
permitiendo así la ejecución de moléculas.
Para usarlo:
1. Asegúrate de cumplir con los link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
requisitos del sistema de los Contenedores de Desarrollo de Visual Studio Code],
siguiendo opcionalmente la sección __Instalación__ de la página vinculada. +
Esto incluye: Instalar Docker, Instalar Visual Studio Code y la extensión necesaria.
2. Clona el proyecto en tu máquina
3. Abre la carpeta del repositorio en Visual Studio Code (_Archivo - Abrir Carpeta..._).
4. Si recibes un aviso en la esquina inferior derecha informándote sobre la presencia de la definición de devcontainer,
puedes presionar el botón adjunto para ingresar a ella.
*De lo contrario,* también puedes ejecutar el comando de Visual Studio `Remote-Containers: Open Folder in Container` tú mismo (_Ver - Paleta de comandos_ -> _escribe el comando mencionado_).
[TIP]
====
Recomiendo usar `Remote-Containers: Rebuild Without Cache and Reopen in Container`
de vez en cuando, ya que la función devcontainer tiene algunos problemas para reconocer
cambios realizados en su definición de forma adecuada en ocasiones.
====
[NOTE]
=====
Quizás necesites configurar tu sistema host para permitir que el contenedor use tus claves SSH/GPG.
El procedimiento está descrito https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[
en la documentación oficial de devcontainer bajo "Compartir credenciales de Git con tu contenedor"].
=====
[[cookiecutter]]
=== 🍪 CookieCutter
Este proyecto debe mantenerse en sincronía con
https://github.com/JonasPammer/cookiecutter-ansible-role[CookieCutter del cual se plantó originalmente]
usando https://github.com/cruft/cruft[cruft] (si es posible) o alteraciones manuales (si es necesario)
a la mayor extensión posible.
.Ejemplo oficial del uso de `cruft update`
____
image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Ejemplo oficial del uso de `cruft update`]
____
==== 🕗 Changelog
Cuando se pulsa una nueva etiqueta, un apropiado lanzamiento de GitHub será creado
por el mantenedor del repositorio para proporcionar un registro de cambios humano adecuado con un título y una descripción.
[[pre-commit]]
=== ℹ️ Convenciones generales de linting y estilo
Las convenciones generales de linting y estilo son
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*automáticamente* mantenidas a estándares]
por varios ganchos https://pre-commit.com/[`pre-commit`], al menos hasta cierto punto.
La ejecución automática de pre-commit se realiza en cada contribución utilizando
https://pre-commit.ci/[`pre-commit.ci`]<<note_pre-commit-ci,*>>.
Las solicitudes de extracción incluso se corrigen automáticamente con la misma herramienta,
al menos por ganchos que alteran automáticamente archivos.
[NOTE]
====
No confundir:
Aunque algunos ganchos de pre-commit pueden ser capaces de advertir sobre fallas analizadas en la sintaxis o incluso en el código hasta cierto punto (razón por la cual los ganchos de pre-commit son *parte de* la suite de pruebas),
pre-commit no ejecuta ninguna suite de pruebas real.
Para información sobre pruebas, consulta <<testing>>.
====
[TIP]
====
[[note_pre-commit-ci]]
Sin embargo, te recomiendo integrar pre-commit en tu flujo de trabajo de desarrollo local tú mismo.
Esto se puede hacer navegando al directorio de tu proyecto clonado y ejecutando `pre-commit install`.
Haciendo esto permitirá que git ejecute verificaciones de pre-commit en cada commit que realices,
abortando el commit mismo si un gancho sonó la alarma.
También puedes, por ejemplo, ejecutar los ganchos de pre-commit en cualquier momento ejecutando `pre-commit run --all-files`.
====
[[contributing]]
== 💪 Contribuyendo
image:https://img.shields.io/badge/PRs-bienvenidos-brightgreen.svg?style=flat-square[PRs Bienvenidos]
https://open.vscode.dev/JonasPammer/ansible-role-apache2[image:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Abrir%20en%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Abrir en Visual Studio Code]
// Incluido en README.adoc
:toc:
:toclevels: 3
Las siguientes secciones son genéricas y se utilizan para ayudar a nuevos contribuyentes.
La "Documentación de Desarrollo" real de este proyecto se encuentra bajo <<development>>.
=== 🤝 Preámbulo
Primero que nada, gracias por considerar contribuir a este proyecto.
Seguir estas pautas ayuda a comunicar que respetas el tiempo de los desarrolladores que gestionan y desarrollan este proyecto de código abierto.
A cambio, deberían corresponder a ese respeto al abordar tu problema, evaluar cambios y ayudarte a finalizar tus solicitudes de extracción.
[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Este proyecto posee muchos de sus archivos en función de
https://github.com/JonasPammer/cookiecutter-ansible-role[el CookieCutter del que se plantó originalmente].
Por favor revisa si la edición que tienes en mente es realmente aplicable a la plantilla
y si es así realiza un cambio apropiado allí en su lugar.
Tu cambio también puede ser aplicable parcialmente a la plantilla
así como parcialmente a algo específico de este proyecto,
en cuyo caso estarías creando múltiples PRs.
=== 💬 Commits Convencionales
Un contribuyente ocasional no tiene que preocuparse por seguir
https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__la especificación__]
https://www.conventionalcommits.org/en/v1.0.0/[__por definición__],
ya que las solicitudes de extracción se están combinando en un solo commit en el proyecto.
Solo los contribuidores principales, es decir, aquellos con derechos para hacer push a las ramas de este proyecto, deben seguirlo
(por ejemplo, para permitir a la detección automática de versiones y la generación de changelog funcionar).
=== 🚀 Comenzando
Las contribuciones se realizan a este repositorio a través de Issues y Pull Requests (PRs).
Algunas pautas generales que cubren ambos:
* Busca Issues y PRs existentes antes de crear el tuyo.
* Si nunca has contribuido antes, consulta https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
la guía para principiantes en el blog de Auth0] para obtener recursos y consejos sobre cómo empezar.
==== Issues
Los Issues deben ser utilizados para informar problemas, solicitar una nueva función, o discutir cambios potenciales *antes* de que se cree una PR.
Cuando https://github.com/JonasPammer/ansible-role-apache2/issues/new[
creas un nuevo Issue], se cargará una plantilla que te guiará a través de la recopilación y provisión de la información que necesitamos para investigar.
Si encuentras un Issue que aborda el problema que tienes,
por favor agrega tu propia información de reproducción al Issue existente *en lugar de crear uno nuevo*.
Agregar una https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[reacción]
también puede ayudar a indicar a nuestros mantenedores que un problema particular está afectando a más que solo el reportero.
==== Pull Requests
Las PRs a este proyecto siempre son bienvenidas y pueden ser una forma rápida de hacer que tu solución o mejora esté programada para el próximo lanzamiento.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[En general], las PRs deben:
* Solo arreglar/agregar la funcionalidad en cuestión *O* abordar problemas de estilo/espaciado comunes, no ambos.
* Agregar pruebas unitarias o de integración para la funcionalidad corregida o cambiada (si ya existe una suite de pruebas).
* *Abordar una sola preocupación*
* *Incluir documentación* en el repositorio
* Estar acompañadas de una plantilla de Pull Request completa (cargada automáticamente al crear una PR).
Para cambios que abordan funcionalidades centrales o requerirían cambios disruptivos (por ejemplo, un lanzamiento importante),
es mejor abrir un Issue para discutir tu propuesta primero.
En general, seguimos el flujo de trabajo de git "fork-and-pull"
1. Haz fork del repositorio a tu propia cuenta de Github
2. Clona el proyecto en tu máquina
3. Crea una rama localmente con un nombre breve pero descriptivo
4. Realiza los cambios en la rama
5. Siguiendo cualquier guía de formato y pruebas específica para este repositorio
6. Sube los cambios a tu fork
7. Abre una PR en nuestro repositorio y sigue la plantilla de PR para que podamos revisar los cambios eficientemente.
[[changelog]]
== 🗒 Registro de cambios
Por favor, consulta la
https://github.com/JonasPammer/ansible-role-apache2/releases[Página de lanzamientos de este repositorio]
para un registro de cambios humano correspondiente a
https://github.com/JonasPammer/ansible-role-apache2/tags[Etiquetas (Versiones) de este proyecto].
Ten en cuenta que este proyecto se adhiere a un versionado semántico.
Por favor, informa sobre cualquier cambio accidental que rompa la funcionalidad en una actualización de versión menor.
[[license]]
== ⚖️ Licencia
.link:LICENSE[]
----
Licencia MIT
Copyright (c) 2022, Jonas Pammer
Se concede por la presente, sin cargo, a cualquier persona que obtenga una copia
de este software y sus archivos de documentación asociados (el "Software"), para tratar
en el Software sin restricción, incluyendo sin limitación los derechos
a usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y/o vender
copias del Software, y a permitir a las personas a las que se les proporcione el Software
hacerlo, sujeto a las siguientes condiciones:
El aviso de copyright anterior y este aviso de permiso se incluirán en todas
las copias o partes sustanciales del Software.
EL SOFTWARE SE PROPORCIONA "TAL CUAL", SIN GARANTÍA DE NINGÚN TIPO, EXPRESA O
IMPLÍCITA, INCLUYENDO PERO NO LIMITÁNDOSE A LAS GARANTÍAS DE COMERCIALIZACIÓN,
IDONEIDAD PARA UN PROPÓSITO PARTICULAR Y NO INFRACCIÓN. EN NINGÚN CASO DEBERÁN LOS
AUTORES O TITULARES DEL COPYRIGHT SER RESPONSABLES DE CUALQUIER RECLAMO, DAÑO U OTRA
RESPONSABILIDAD, YA SEA EN UNA ACCIÓN DE CONTRATO, AGRAVIO O DE OTRA MANERA, QUE SURJA DE,
DE O EN CONEXIÓN CON EL SOFTWARE O EL USO O CUALQUIER OTRA MANERA EN EL
SOFTWARE.
----
Acerca del proyecto
An ansible role for installing Apache2, enabling/disabling modules, configuring its defaults and creating virtual hosts.
Instalar
ansible-galaxy install jonaspammer.apache2
Licencia
mit
Descargas
21.3k
Propietario
DevOps is just FullStack with one additional layer