jonaspammer.apache2
// Ten plik jest generowany przez .github/workflows/gh-pages.yml - wszystkie lokalne zmiany zostaną ostatecznie utracone!
= ansible-role-apache2
Jonas Pammer <[email protected]>;
:toc: left
:toclevels: 2
:toc-placement!:
:source-highlighter: rouge
https://galaxy.ansible.com/jonaspammer/apache2[obraz:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.apache2-brightgreen[Wersja na Galaxy]]
// Bardzo ważne wyróżnienia statusu
https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/ci.yml[obraz:https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/ci.yml/badge.svg[Testowanie CI]]
Rola Ansible do instalacji Apache2, włączania/wyłączania modułów, konfigurowania domyślnych ustawień i tworzenia wirtualnych hostów.
toc::[]
[[meta]]
== 🔎 Metadane
Poniżej możesz znaleźć informacje na temat…
* wymagana wersja Ansible dla tej roli
* obsługiwane platformy przez rolę
* https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[zależności roli]
.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
role_name: "apache2"
description:
"Rola Ansible do instalacji Apache2, włączania/wyłączania modułów,
konfigurowania domyślnych ustawień i tworzenia wirtualnych hostów.
Oparta na roli apache2 geerlingguya."
author: "jonaspammer"
license: "MIT"
min_ansible_version: "2.11"
platforms:
- name: EL # (Enterprise Linux)
versions:
- "9" # aktywnie testowane: rockylinux9
- name: Fedora
versions:
- "38" # aktywnie testowane: fedora38
- "39" # aktywnie testowane: fedora39
- name: Debian
versions:
- bullseye # aktywnie testowane: debian11
- bookworm # aktywnie testowane: debian12
- name: Ubuntu
versions:
- focal # aktywnie testowane: ubuntu2004
- jammy # aktywnie testowane: ubuntu2204
galaxy_tags:
- web
- apache
- webserver
- html
- httpd
dependencies: []
allow_duplicates: true
----
[[requirements]]
== 📌 Wymagania
// Jakiekolwiek wymagania wstępne, które mogą nie być objęte tą rolą lub samym Ansible, powinny być wymienione tutaj.
Użytkownik Ansible musi mieć możliwość `become`.
Jeśli używasz SSL/TLS (<<apache_vhosts_ssl>>), będziesz musiał dostarczyć własne pliki certyfikatu i klucza.
Jeśli używasz Apache z PHP, zalecam skorzystanie z
https://github.com/geerlingguy/ansible-role-php/[rol geerlingguy.php]
do zainstalowania PHP, i możesz używać `mod_php`
(dodając odpowiedni pakiet, np. `libapache2-mod-php5` dla Ubuntu, do `php_packages`),
lub korzystając z
https://github.com/geerlingguy/ansible-role-apache-php-fpm[`rol geerlingguy.apache-php-fpm` ]
do połączenia Apache z PHP poprzez FPM.
Konsultuj się z README powiązanych ról w celu uzyskania bardziej szczegółowych informacji.
Dla systemów opartych na Solaris,
kolekcja https://galaxy.ansible.com/community/general[`community.general`]
(zawierająca moduł `pkg5`) musi być zainstalowana na kontrolerze Ansible.
Dla systemów opartych na Suse,
kolekcja https://galaxy.ansible.com/community/general[`community.general`]
(zawierająca moduł `zypper`) musi być zainstalowana na kontrolerze Ansible.
[[variables]]
== 📜 Zmienne roli
// Opis konfigurowalnych zmiennych dla tej roli powinien znajdować się tutaj
// i wszelkie zmienne, które mogą/które powinny być ustawione za pomocą parametrów do roli.
// Wszelkie zmienne, które są odczytywane z innych ról i/lub z globalnego zakresu (tj. hostvars, grupy vars, itd.)
// powinny być również wymienione tutaj.
[source,yaml]
----
apache_mods_enabled:
- rewrite
- ssl
apache_mods_disabled: []
----
(Tylko Debian/RHEL)
Moduły Apache do włączenia lub wyłączenia (będą one tworzyły symlinki we właściwe miejsce).
Sprawdź katalog `mods-available` (Debian) / `conf.modules.d` (RHEL) w <<apache__server_root_dir, głównym katalogu apache'a>> dla wszystkich dostępnych modułów.
[source,yaml]
----
apache_listen_ip: "*"
apache_listen_port: 80
apache_listen_port_ssl: 443
----
Adres IP i porty, na których Apache powinien nasłuchiwać.
Przydatne, jeśli masz inny serwis (np. reverse proxy) nasłuchujący
na porcie 80 lub 443 i musisz zmienić domyślne ustawienia.
[source,yaml]
----
apache_remove_default_vhost: false
----
W systemach Debian/Ubuntu domyślny wirtualny host jest zawarty w konfiguracji Apache.
Ustaw to na `true`, aby usunąć ten domyślny.
[source,yaml]
----
apache_state: started
----
Ustaw początkowy stan Apache.
Zalecane wartości: `started` lub `stopped`
[source,yaml]
----
apache_enabled: true
----
Ustaw początkowy stan serwisu Apache.
Zalecane wartości: `true` lub `false`
[source,yaml]
----
apache_restart_state: restarted
----
Ustawia stan, w którym powinien być Apache, gdy dokonano zmiany w konfiguracji
(tj. gdy wywołano handler `restart apache`).
Zalecane wartości: `restarted` lub `reloaded`
[[apache_default_favicon]]
[source,yaml]
----
apache_default_favicon: favicon.ico
----
Ścieżka do pliku na lokalnym kontrolerze Ansible, który ma być skopiowany na serwer
i używany przez Apache jako domyślny favicon.
=== Zmienne roli używane do instalacji
[source,yaml]
----
apache_packages: [OS-specific by default, see /defaults directory]
----
Lista nazw pakietów do zainstalowania Apache2 i najpotrzebniejszych narzędzi.
[source,yaml]
----
apache_packages_state: present
----
Jeśli włączyłeś jakiekolwiek dodatkowe repozytoria takie jak
https://launchpad.net/~ondrej/+archive/ubuntu/apache2[`ondrej/apache2`],
https://fedoraproject.org/wiki/EPEL[`EPEL`], lub
http://rpms.remirepo.net/[`remi`],
możesz potrzebować łatwego sposobu na aktualizację wersji.
Aby to zapewnić, ustaw to na `latest`.
[source,yaml]
----
apache_enablerepo: ""
----
(Tylko RHEL/CentOS)
Repozytorium https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_module.html#parameter-enablerepo, które ma być używane podczas instalacji Apache.
Jeśli chcesz nowsze wersje Apache niż te dostępne w podstawowych repozytoriach systemu operacyjnego,
użyj repozytorium takiego jak
https://fedoraproject.org/wiki/EPEL[EPEL]
(które można zainstalować przy użyciu roli `repo-epel`).
=== Zmienne roli używane do tworzenia Wirtualnych Hostów
[TIP]
Sprawdź sekcję <<example_playbooks>> po
przykłady pokazujące, jak może wyglądać wygenerowany plik VirtualHost.
[NOTE]
====
Ta rola stara się zapewnić działającą konfigurację apache, przeprowadzając
https://httpd.apache.org/docs/2.4/programs/httpd.html[testy składni dla wszystkich plików konfiguracyjnych (`-t`)]
i przywracając wygenerowany wirtualny host, jeśli wystąpił błąd.
====
[source,yaml]
----
apache_create_vhosts: true
apache_vhosts_filename: "vhosts.conf"
apache_vhosts_template: "vhosts.conf.j2"
----
Jeśli ustawione na `true`, plik vhosts zarządzany przez zmienne tej roli (patrz poniżej)
jest tworzony i umieszczany w katalogu konfiguracyjnym Apache.
Jeśli ustawione na `false`, możesz umieścić własny plik vhosts w katalogu konfiguracyjnym Apache i pominąć ten wygodny (choć prostszy) plik dodany przez tę rolę.
Możesz także nadpisać używany szablon i ustawić ścieżkę do własnego szablonu,
jeśli potrzebujesz dodatkowo dostosować układ swojego VirtualHost.
[source,yaml]
----
apache_global_vhost_settings: |
DirectoryIndex index.php index.html
----
Ta zmienna jest używana *_poza jakąkolwiek dyrektywą <VirtualHost>_
w wygenerowanym pliku wirtualnego hosta.
[WARNING]
=====
W ten sposób zmieniasz konfiguracje stosowane w ogólnym kontekście Apache
(zamiast zmieniać konfiguracje stosowane na przykład w `<VirtualHost>`/ `<Directory>`/...).
Warto zrozumieć, że
*dyrektywa `DirectoryIndex` nie _ustawia_, lecz raczej _dodaje_*
(oznacza to, że nie odwracamy żadnej innej konfiguracji),
co zostało zauważone na jej stronie dokumentacji:
[cytat, https://httpd.apache.org/docs/2.4/mod/mod_dir.html]
____
Wielokrotne dyrektywy `DirectoryIndex` w tym samym kontekście będą dodawane
do listy zasobów do przeszukania, a nie wymieniać.
____
=====
[source,yaml]
----
apache_vhosts:
- servername: "local.dev"
documentroot: "/var/www/html"
----
Dla każdego wpisu na tej liście,
dyrektywa `<VirtualHost>` nasłuchująca
`{{ apache_listen_ip }}:{{ apache_listen_port }}`
zostanie wygenerowana.
Każdy wpis na liście może mieć następujące właściwości
(Konsultuj się z sekcją <<example_playbooks>> w celu uzyskania przykładów.
Konsultuj powiązane oficjalne strony dokumentacji, aby uzyskać dokumentacje rzeczywistych dyrektyw Apache, które reprezentują).
`https://httpd.apache.org/docs/2.4/mod/core.html#servername[servername]` (wymagane)::
`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]`::
Dyrektywa `AllowOverride` używana wewnątrz `<Directory>` katalogu `DocumentRoot`. +
Domyślnie ma wartość `apache_vhosts_default_documentroot__allowoverride`.
`documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#options[options]`::
Dyrektywa `Options` używana wewnątrz `<Directory>` katalogu `DocumentRoot`. +
Domyślnie ma wartość `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]`::
Może być albo ciągiem (reprezentującym ścieżkę, nie jest automatycznie cudzysłowiona)
lub złożonym typem danych:
+
====
`path`::
Ścieżka.
Zostaje cudzysłowiona w `"`.
`extra`::
Dodatkowy ciąg do dodania po `path`.
`extra_parameters`::
Ta zmienna jest wstawiana tak, jak jest *przed* rzeczywistym stwierdzeniem `ErrorLog`
(z wcięciem 2).
+
Wykorzystanie tej zmiennej może polegać na aktywowaniu warunkowych logów przy użyciu
`SetEnvIf` / `SetEnv` lub ustawieniu niestandardowego `LogFormat` dla tego ErrorLog
z https://httpd.apache.org/docs/2.4/logs.html[dokumentacji rdzeniowej Apache].
====
[[apache_vhosts__customlogs]]
`https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#customlog[customlogs]`::
Tablica CustomLogs.
Każdy wpis może być ciągiem (nie jest automatycznie cudzysłowiony)
lub złożonym typem danych:
+
====
`path`::
Ścieżka.
Zostaje cudzysłowiona w `"`.
`extra`::
Dodatkowy ciąg do dodania po `path`.
Nie jest cudzysłowiony
(aby umożliwić złożone dodatkowe parametry, które CustomLog można podać).
`extra_parameters`::
Ta zmienna jest wstawiana tak, jak jest *na końcu* pętli `<VirtualHost>` (z wcięciem 2).
[[apache_vhosts_ssl]]
[source,yaml]
----
apache_vhosts_ssl: []
----
Dla każdego wpisu na tej liście,
dyrektywa `<VirtualHost>` nasłuchująca
`{{ apache_listen_ip }}:{{ apache_listen_port_ssl }}`
zostanie wygenerowana.
Każdy wpis na liście może mieć następujące właściwości
(Konsultuj się z sekcją <<example_playbooks>> w celu uzyskania przykładów)
(Konsultuj powiązane oficjalne strony dokumentacji jak dyrektywy Apache, które one reprezentują).
`https://httpd.apache.org/docs/2.4/mod/core.html#servername[servername]` (wymagane)::
`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]`::
Dyrektywa `AllowOverride` używana wewnątrz `<Directory>` katalogu `DocumentRoot`. +
Domyślnie ma wartość `apache_vhosts_default_documentroot__allowoverride`.
`documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#options[options]`::
Dyrektywa `Options` używana wewnątrz `<Directory>` katalogu `DocumentRoot`.
Domyślnie ma wartość `apache_vhosts_default_documentroot__options`.
`no_actual_ssl`::
Jeśli ustawione na True, `<VirtualHost>` nie będzie miał opcji SSL*.
Używane tylko wtedy, gdy chcesz przekierować http do https, jak zdefiniowano w `extra_parameters`.
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile[ssl_certificate_file] (wymagane)::
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatekeyfile[ssl_certificate_key_file] (wymagane)::
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatechainfile[ssl_certificate_chain_file]::
_Uwaga, że to jest przestarzałe._
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]`::
Odpowiednik <<apache_vhosts__errorlog, apache_vhosts.errorlog>>.
`https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#customlog[customlogs]`::
Tablica CustomLogs.
Odpowiednik <<apache_vhosts__customlogs, apache_vhosts.customlogs>>.
`extra_parameters`::
Ta zmienna jest wstawiana tak, jak jest na końcu pętli `<VirtualHost>` (z wcięciem 2).
[source,yaml]
----
apache_ignore_missing_ssl_certificate: true
----
Jeśli ustawione na `false`, dany wpis z `apache_vhosts_ssl`
zostanie wygenerowany tylko wtedy, gdy jego `sslcertificatefile` istnieje.
[source,yaml]
----
apache_ssl_protocol: "All -SSLv2 -SSLv3"
apache_ssl_cipher_suite: "AES256+EECDH:AES256+EDH"
----
Te zmienne są używane jako domyślne dla każdego `apache_vhosts_ssl`.
Zostały nazwane w ten sam sposób, jak użycie w ww. zmiennych roli
(z wyjątkiem prefiksu, oczywiście).
Konsultuj https://httpd.apache.org/docs/current/mod/mod_ssl.html[
dokumentację Apache]
w celu zapoznania się z dyrektywami Apache, które one reprezentują.
[source,yaml]
----
apache_vhosts_default_documentroot__allowoverride: "All"
apache_vhosts_default_documentroot__options: "-Indexes +FollowSymLinks"
----
[[public_vars]]
== 📜 Fakty/Zmienne definiowane przez tę rolę
Każda zmienna wymieniona w tej sekcji
jest dynamicznie definiowana podczas wykonywania tej roli (i może być nadpisywana tylko za pomocą `ansible.builtin.set_facts`) _i_
ma być używana nie tylko wewnętrznie.
[[apache__service]]
.`pass:[apache__service]`
****
.Przykładowe użycie poza tą rolą:
[source,yaml]
----
# plik handlers dla roles.xyz
- name: restart apache2
ansible.builtin.service:
name: "{{ apache__service | default('apache2') }}"
state: restarted
----
****
[[apache__daemon]]
.`pass:[apache__daemon_dir]`, `pass:[apache__daemon]`
****
Nazwa i katalog wykonywalny polecenia `apache2`.
****
[[apache__server_root_dir]]
.`pass:[apache__server_root_dir]`
****
Katalog zawierający całą konfigurację Apache2 (w `/etc`).
****
[[debian_is_different_note]]
[NOTE]
====
Pracując z dowolnymi poniższymi wartościami konfiguracyjnymi musisz pamiętać:
[cytat, komentarz znaleziony w /etc/apache2/apache2.conf w Debianie 10]
______
Konfiguracja serwera Apache 2 w *Debianie jest znacznie inna niż
sugerowany sposób konfigurowania serwera webowego*. To dlatego,
że domyślna instalacja Apache2 w Debianie próbuje uczynić dodawanie i usuwanie modułów,
wirtualnych hostów i dodatkowych dyrektyw konfiguracyjnych tak elastycznymi, jak to możliwe,
aby ułatwić automatyzację zmian i zarządzanie serwerem.
______
To oznacza, że `pass:[apache__server_root_dir]`
*na Debianie* wygląda tak:
.`tree /etc/apache2` na świeżej maszynie Debian 10 po instalacji 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
----
Podczas #na innych systemach wygląda to tak#:
.`tree /etc/apache2` na świeżej maszynie CentOS 8 po instalacji 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]`
****
Główny plik konfiguracyjny Apache2,
który http://httpd.apache.org/docs/2.4/mod/core.html#include
`Include`'s wszystkie inne pliki i zawiera kilka innych dyrektyw.
.Rzucając okiem na to, co jest dołączane
[TIP]
====
Dyrektywy dołączające Apache2 w Debianie, jak znalezione w `pass:[apache__primary_configuration_file_path]`:
[source,ini]
----
# Dołącz konfigurację modułu:
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
# Dołącz listę portów do nasłuchu
Include ports.conf
# Dołączanie katalogów ignoruje pliki kopii zapasowych edytorów i dpkg,
# Dołącz ogólne części z instrukcji
IncludeOptional conf-enabled/*.conf
# Dołącz konfiguracje wirtualnych hostów:
IncludeOptional sites-enabled/*.conf
----
Dyrektywy dołączające Apache2 w RHEL, jak znalezione w `pass:[apache__primary_configuration_file_path]` na maszynie CentOS 8:
[source,ini]
----
# Wsparcie dla dynamicznych obiektów współdzielonych (DSO)
#
# Aby używać funkcjonalności modułu, który został zbudowany jako DSO, musisz umieścić
# odpowiednie linie `LoadModule` w tym miejscu, aby dyrektywy zawarte w nim były dostępne _przed_ ich użyciem.
# Statically compiled modules (te, które są wymienione za pomocą `httpd -l') nie muszą być ładowane tutaj.
#
# Przykład:
# LoadModule foo_module modules/mod_foo.so
Include conf.modules.d/*.conf
# Uzupełniająca konfiguracja:
IncludeOptional conf.d/*.conf
----
====
****
[[apache__ports_configuration_file]]
.`pass:[apache__ports_configuration_file]`
*****
Plik konfiguracyjny Apache2, który zawiera dyrektywy używane
do określenia portów nasłuchujących dla nadchodzących połączeń.
W niektórych systemach jest to to samo co `pass:[apache__primary_configuration_file_path]`,
ale w niektórych jest to własny plik, który jest
http://httpd.apache.org/docs/2.4/mod/core.html#include
`Include`-ed przez ten `pass:[apache__primary_configuration_file_path]`.
*****
[[apache__server_conf_dir]]
.`pass:[apache__server_conf_dir]`
****
Katalog, który zawiera wszystkie http://httpd.apache.org/docs/2.4/mod/core.html#include
`Include`-ed plików.
Ten katalog może nie być bezpośrednio dołączany, ale może mieć podkatalogi, które są dołączane.
Konsultuj się z NOTĄ/TIP-em znajdującym się w <<apache__primary_configuration_file_path>>
aby sprawdzić, jakie katalogi są domyślnie dołączane na różnych systemach operacyjnych.
****
[[apache__default_log_dir]]
.`pass:[apache__default_log_dir]`
****
Katalog w `/var` używany domyślnie dla wszystkich wirtualnych hostów.
Poniższy wynik pokazuje typowe domyślne zawartości tego folderu dla głównych dystrybucji:
.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]]
== 🏷️ Tag’i
// Zobacz https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags
// dla świetnego przykładu grupowania zadań przy użyciu tagów
Zadania są oznaczane następującymi
https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[tagami]:
[cols="1,1"]
|===
|Tag | Cel
2+| Ta rola nie ma jeszcze oficjalnie udokumentowanych tagów.
// | download-xyz
// |
// | install-prerequisites
// |
// | install
// |
// | create-xyz
// |
|===
Możesz użyć Ansible, aby pominąć zadania lub uruchomić tylko niektóre zadania, używając tych tagów. Domyślnie wszystkie zadania są uruchamiane, gdy żadne tagi nie są określone.
[[dependencies]]
== 👫 Zależności
// Lista innych ról powinna się tutaj znajdować,
// w tym wszelkie szczegóły dotyczące parametrów, które mogą wymagać ustawienia dla innych ról,
// lub zmiennych, które są używane z innych ról.
[[example_playbooks]]
== 📚 Przykłady użycia Playbooków
// Ujawnienie przykładów użycia tej roli w playbooku dla powszechnych scenariuszy zawsze jest miłym gestem dla użytkowników.
[NOTE]
====
Ta rola jest częścią https://github.com/JonasPammer/ansible-roles[
wielu moich zgodnych ról dedykowanych różnym celom].
Maszyna musi być przygotowana.
W CI odbywa się to w `molecule/resources/prepare.yml`
który źródła swoje zależności z `requirements.yml`:
.link:molecule/resources/prepare.yml[]
[source,yaml]
----
---
- name: prepare
hosts: all
become: true
gather_facts: false
roles:
- role: jonaspammer.bootstrap
# - name: jonaspammer.core_dependencies
----
Poniższy diagram przedstawia "miękkie zależności" tej roli
oraz rekursywną strukturę ich miękkich zależności.
image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_apache2.svg[
wykres zależności requirements.yml dla jonaspammer.apache2]
====
.Standardowa instalacja (bez zmiennych)
====
* Poniższy yaml:
+
[source,yaml]
----
roles:
- role: jonaspammer.apache2
----
+
generuje następujący Wirtualny Host:
+
[source]
-----
# Zarządzane przez 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>
-----
+
Dla odniesienia, oto domyślny wirtualny host dostarczany z systemami Debian/Ubuntu
(który można usunąć, ustawiając `apache_remove_default_vhost` na 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>
-----
Biorąc pod uwagę brak konfiguracji roli, odchylenia od instalacji Apache2 samodzielnie to
* pewne moduły są domyślnie aktywowane (`<<apache_mods_enabled>>`).
* system będzie miał powyższy prezentowany Wirtualny Host
* Przy pierwszej instalacji plik o nazwie `favicon.ico` (pochodzący z <<apache_default_favicon>>) zostanie umieszczony w `/var/www/html`
jeśli wcześniej nie było pliku o tej nazwie. Ten favicon domyślnie przypomina logo Ansible znalezione na Wikimedia.
_Uwaga, że ta rola nie usuwa zawartości `/var/www/html`
(nawet jeśli została stworzona przez/po początkowej instalacji apache2)._
====
.Logging
====
* Poniższy 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"
----
+
generuje następujący Wirtualny Host:
+
[source]
-----
# Zarządzane przez Ansible.
TODO
-----
====
.Użycie `extra_parameters`
====
[TIP]
======
Symbol rury na końcu linii w YAML oznacza, że wszelkie wcięte teksty, które następują
powinny być interpretowane jako wieloliniowa wartość skalarna.
Zobacz https://yaml-multiline.info/[yaml-multiline.info] dla interaktywnego wyjaśnienia.
======
* Poniższy 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: |
# Przekieruj wszystkie żądania na subdomenę 'www'. Apache 2.4+
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://www.%{HTTP_HOST}%{REQUEST_URI} [R=302,L]
----
+
generuje następujący Wirtualny Host:
+
[source]
-----
# Zarządzane przez Ansible.
TODO
-----
* Poniższy 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 }}
----
+
generuje następujący Wirtualny Host:
+
[source]
-----
# Zarządzane przez Ansible.
DirectoryIndex index.php index.html
<VirtualHost *:80>
ServerName srvcmk.intra.jonaspammer.com
Redirect / http://srvcmk.intra.jonaspammer.at/master
</VirtualHost>
-----
====
.Tworzenie własnego pliku wirtualnego hosta / integracja w rolę
====
_Rola apache2 może być wykonywana wielokrotnie w jednym playu, z głównym celem
https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#using-allow-duplicates-true[ta możliwość]
ma umożliwić tworzenie wirtualnych hostów._
[source,yaml,subs="+quotes,macros"]
----
- tasks:
pass:[#]...
- name: Generowanie Wirtualnego Hostu 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]]
== 🧪 Testowane dystrybucje
Rola może działać na różnych *dystrybucjach*, takich jak Red Hat Enterprise Linux (RHEL),
nawet jeśli nie ma testów dla tej dokładnej dystrybucji.
// dobrym odniesieniem dla tego, czego się trzymać -- większość znaków i przypiętych projektów geerlingguya:
// https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml
|===
| Rodzina OS | Dystrybucja | Data wydania dystrybucji | Data wycofania dystrybucji | Towarzyszący obraz Dockera
// https://endoflife.date/rocky-linux
| Rocky
| Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 w przebraniu])
| 2021-06
| 2029-05
| https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[obraz: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[obraz:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]
// https://endoflife.date/fedora (13 miesięcy)
| RedHat
| Fedora 39
| 2023-11
| 2024-12
| https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[obraz: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[obraz: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[obraz: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[obraz: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[obraz:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]]
|===
[[tested-ansible-versions]]
== 🧪 Testowane wersje Ansible
Testowane wersje Ansible starają się pozostać zgodne z
https://github.com/ansible-collections/community.general#tested-with-ansible[
wzorem wsparcia dla kolekcji `community.general` Ansible].
W momencie pisania są to:
* 2.13 (Ansible 6)
* 2.14 (Ansible 7)
* 2.15 (Ansible 8)
* 2.16 (Ansible 9)
[[development]]
== 📝 Rozwój
// Banery o konwencjach w tym projekcie
https://conventionalcommits.org[obraz: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[obraz:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-apache2/master.svg[status pre-commit]]
// obraz: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]]
=== 📌 Wymagania dotyczące maszyny deweloperskiej
* Python 3.10 lub wyższy
* Docker
[[development-dependencies]]
=== 📌 Zależności do rozwoju
Zależności do rozwoju są definiowane w
https://pip.pypa.io/en/stable/user_guide/#requirements-files[pliku wymagań pip]
nazwanym `requirements-dev.txt`.
Poniżej pokazane są przykłady instrukcji instalacji dla systemu Linux:
----
# "opcjonalne": utworzenie python virtualenv i aktywowanie go na bieżącą sesję
$ python3 -m venv venv
$ source venv/bin/activate
$ python3 -m pip install -r requirements-dev.txt
----
[[development-guidelines]]
=== ℹ️ Wytyczne dotyczące rozwoju ról Ansible
Proszę zapoznać się z moimi https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[
wytycznymi dotyczącymi rozwoju ról Ansible].
W razie zainteresowania, spisałem również kilka
https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[
ogólnych najlepszych praktyk dotyczących rozwoju ról Ansible].
[[versioning]]
=== 🔢 Wersjonowanie
Wersje są definiowane za pomocą https://git-scm.com/book/en/v2/Git-Basics-Tagging[Tagów],
które z kolei są https://galaxy.ansible.com/docs/contributing/version.html[rozpoznawane i używane] przez Ansible Galaxy.
*Wersje nie mogą zaczynać się od `v`.*
Gdy nowy tag zostanie wdrożony, https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/release-to-galaxy.yml[
workflow CI GitHub]
(obraz:https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/release-to-galaxy.yml/badge.svg[CI wydania])
zajmuje się importowaniem roli do mojego konta Ansible Galaxy.
[[testing]]
=== 🧪 Testowanie
Automatyczne testy są uruchamiane przy każdym wkładzie przy użyciu procesów GitHub.
Testy głównie dotyczą uruchamiania https://molecule.readthedocs.io/en/latest/[Molecule]
na <<tested-distributions,różnorodnym zestawie dystrybucji linuxowych>>
i użycia <<tested-ansible-versions,różnych wersji ansible>>.
Testy molekularne obejmują również krok, w którym wszystkie playbooki ansible są linterowane z użyciem
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
aby sprawdzić, czy best practices i zachowania mogą zostać potencjalnie ulepszone.
Aby uruchomić testy, wystarczy użyć `tox` w linii poleceń.
Możesz również przekazać opcjonalną zmienną środowiskową, aby zdefiniować dystrybucję
kontenera Docker, który ma być uruchomiony przez molekuły:
----
$ MOLECULE_DISTRO=ubuntu2204 tox
----
Aby zobaczyć listę możliwych wartości przekazywanych do `MOLECULE_DISTRO`,
sprawdź macierz zdefiniowaną w link:.github/workflows/ci.yml[].
==== 🐛 Debugowanie kontenera molekularnego
1. Uruchom swoje testy molekularne z opcją `MOLECULE_DESTROY=never`, np.:
+
[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:[___________________________________ summary ____________________________________]
pre-commit: commands succeeded
ERROR: py3-ansible-9: commands failed
----
2. Dowiedz się, jak nazywa się kontener uruchomiony przez molekuły:
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf# geerlingguy/docker-debian12-ansible:latest "/lib/systemd/systemd" 8 minutes ago Up 8 minutes instance-py3-ansible-9
----
3. Wejdź do shella bash kontenera i prowadź debugowanie:
+
[subs="quotes"]
----
$ *docker exec -it #30e9b8d59cdf# /bin/bash*
root@instance-py3-ansible-2:/#
----
+
[TIP]
====
Jeśli problem, który próbujesz zdebugować, dotyczy kroku `verify.yml` a nie samego `converge.yml`,
możesz chcieć wiedzieć, że wynik modułów ansible (`vars`), hostów (`hostvars`) i
zmiennych środowiskowych zostały zapisane w plikach zarówno na provisionerze, jak i w kontenerze docker pod:
* `/var/tmp/vars.yml` (zawiera zmienne hosta w kluczu `hostvars`)
* `/var/tmp/environment.yml`
`grep`, `cat` lub przenieś według własnego uznania!
====
+
[TIP]
=====
Możesz także chcieć wiedzieć, że wspomniane pliki w uwadze powyżej
są dołączone jako *artefakty CI GitHub* danej wersji procesu. +
To umożliwia sprawdzenie różnic między wykonaniami
i w ten sposób pomoc w debugowaniu, co spowodowało bit-rot lub ogólną awarię.
image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]
=====
4. Po zakończeniu debugowania, wyjdź i zniszcz kontener:
+
[subs="quotes"]
----
root@instance-py3-ansible-2:/# *exit*
$ *docker stop #30e9b8d59cdf#*
$ *docker container rm #30e9b8d59cdf#*
_lub_
$ *docker container prune*
----
==== 🐛 Debugowanie lokalnych wersji pakietów
Chociaż standardową funkcjonalnością w tox 3, to https://github.com/tox-dev/tox/pull/2794[teraz] dzieje się to tylko wtedy, gdy tox rozpozna obecność zmiennej CI.
Na przykład:
----
$ CI=true tox
----
[[development-container-extra]]
=== 🧃 TIP: Idealne środowisko deweloperskie w kontenerze
Ten projekt oferuje definicję "Jednoklikowego kontenerowego środowiska deweloperskiego".
Ten kontener umożliwia nawet uruchamianie kontenerów dockera wewnątrz niego (Docker-In-Docker, dind),
umożliwiając wykonanie molekuł.
Aby z niego skorzystać:
1. Upewnij się, że spełniasz link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
wymagania systemowe dla kontenerów rozwoju Visual Studio Code],
opcjonalnie postępując zgodnie z sekcją __Instalacja__ połączonej podstrony. +
Obejmuje to: instalację Dockera, instalację samego Visual Studio Code i zainstalowanie potrzebnego rozszerzenia.
2. Sklonuj projekt na swoją maszynę
3. Otwórz folder repozytorium w Visual Studio Code (_Plik - Otwórz folder…_).
4. Jeśli dostaniesz komunikat w prawym dolnym rogu informujący o obecności definicji devcontainer,
możesz nacisnąć towarzyszący przycisk, aby wprowadzić go.
*W przeciwnym razie,* możesz również wykonać polecenie Visual Studio `Remote-Containers: Open Folder in Container` samodzielnie (_Widok - Paleta poleceń_ -> _wpisz wspomniane polecenie_).
[TIP]
====
Zalecam użycie `Remote-Containers: Rebuild Without Cache and Reopen in Container`
raz na jakiś czas, ponieważ funkcja devcontainer ma swoje problemy z odpowiednim rozpoznawaniem
zmian wprowadzeń do niej.
====
[NOTE]
=====
Możesz potrzebować skonfigurować swój system gospodarza, aby umożliwić kontenerowi korzystanie z kluczy SSH/GPG.
Procedura jest opisana https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[
w oficjalnej dokumentacji devcontainer pod "Udostępnianie poświadczeń Git z kontenerem"].
=====
[[cookiecutter]]
=== 🍪 CookieCutter
Ten projekt powinien być utrzymywany w synchronizacji z
https://github.com/JonasPammer/cookiecutter-ansible-role[CookieCutter, z którego został pierwotnie stworzony]
z użyciem https://github.com/cruft/cruft[cruft] (jeśli to możliwe) lub ręcznymi zmianami (jeśli zajdzie taka potrzeba)
w jak najszerszym stopniu.
.Oficjalne przykłady użycia `cruft update`
____
obraz::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Oficjalne przykłady użycia `cruft update`]
____
==== 🕗 Dziennik zmian
Gdy nowy tag jest publikowany, odpowiedni GitHub Release zostanie stworzony
przez Utrzymującego repozytorium, aby dostarczyć odpowiedni ludzki dziennik zmian z tytułem i opisem.
[[pre-commit]]
=== ℹ️ Ogólne zasady dotyczące lintingu i stylu
Ogólne zasady dotyczące lintingu i stylu są
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*automatycznie* dostosowywane do standardów]
przez różne https://pre-commit.com/[hooki `pre-commit`], przynajmniej w jakimstopniu.
Automatyczne wykonywanie pre-commit odbywa się przy każdym wkładzie przy użyciu
https://pre-commit.ci[`pre-commit.ci`]<<note_pre-commit-ci,*>>.
Prośby o pull automatycznie uzyskują naprawy z tym narzędziem,
przynajmniej przez hooki, które automatycznie zmieniają pliki.
[NOTE]
====
Nie należy się mylić:
Chociaż niektóre hooki pre-commit mogą być w stanie ostrzec cię o błędach analizowanej składni lub nawet kodu w pewnym zakresie (z powodu czego hooki pre-commit są *częścią* zestawu testowego),
pre-commit nie uruchamia sama w sobie żadnych rzeczywistych zestawów testowych.
Aby uzyskać więcej informacji na temat testowania, zobacz <<testing>>.
====
[TIP]
====
[[note_pre-commit-ci]]
Niemniej jednak, zalecam integrację pre-commit w swoim lokalnym przepływie pracy deweloperskiej.
Można to zrobić, będąc w katalogu sklonowanego projektu i uruchamiając `pre-commit install`.
Dzięki temu git uruchamia kontrole pre-commit przy każdym commitie,
przerywając je, jeśli alarmuje hook.
Możesz także, na przykład, uruchomić hooki pre-commit w dowolnym momencie, wydając `pre-commit run --all-files`.
====
[[contributing]]
== 💪 Wkład
obraz:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[Przyjmujemy PRy!]
https://open.vscode.dev/JonasPammer/ansible-role-apache2[obraz:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Open%20in%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Otwórz w Visual Studio Code]]
// Zawarte w README.adoc
:toc:
:toclevels: 3
Poniższe sekcje mają charakter ogólny i służą do pomagania nowym współpracownikom.
Rzeczywista "Dokumentacja Rozwoju" tego projektu znajduje się w <<development>>.
=== 🤝 Wstęp
Na wstępie dziękuję za rozważenie wniesienia wkładu w ten projekt.
Przestrzeganie tych wytycznych pomaga komunikować, że szanujesz czas deweloperów zarządzających tym projektem typu open source.
W zamian powinni być gotowi odpowiedzieć na twoje zgłoszenie, ocenić zmiany i pomóc w finalizacji twoich pull requestów.
[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Ten projekt jest odpowiedzialny za wiele swoich plików
https://github.com/JonasPammer/cookiecutter-ansible-role[CookieCutter, z którego został pierwotnie stworzony].
Proszę sprawdzić, czy zmiana, którą masz na myśli, jest rzeczywiście odpowiednia dla szablonu
i jeśli tak, wprowadź odpowiednią zmianę tam.
Twoja zmiana może być również w pewnym stopniu odpowiednia zarówno dla szablonu,
jak i dla czegoś specyficznego dla tego projektu,
w takim przypadku tworzysz kilka PRów.
=== 💬 Konwencjonalne commity
Zwykły współpracownik nie musi martwić się o przestrzeganie
https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__specyfikacji__]
https://www.conventionalcommits.org/en/v1.0.0/[__z definicji__],
ponieważ pull requesty są scalane w jeden commit w projekcie.
Tylko rdzenni współpracownicy, tj. ci, którzy mają prawa do przesyłania zmian do gałęzi tego projektu, muszą się do tego stosować
(np. aby umożliwić automatyczne określenie wersji i generowanie changeloga).
=== 🚀 Aby rozpocząć
Wkłady do tego repozytorium realizowane są za pośrednictwem Zgłoszeń i Pull Requestów (PR).
Kilka ogólnych wytycznych, które dotyczą obu:
* Szukaj istniejących Zgłoszeń i PR przed stworzeniem własnego.
* Jeśli nigdy wcześniej nie współpracowałeś, zobacz https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
poradnik dla początkujących na blogu Auth0] w celu uzyskania zasobów i wskazówek dotyczących rozpoczęcia.
==== Zgłoszenia
Zgłoszenia powinny być używane do zgłaszania problemów, żądania nowej funkcji lub omawiania potencjalnych zmian *przed* stworzeniem PR.
Kiedy https://github.com/JonasPammer/ansible-role-apache2/issues/new[
tworzysz nowe zgłoszenie], zostanie załadowany szablon, który poprowadzi cię w zbieraniu i dostarczaniu informacji, które są potrzebne, abyśmy mogli to zbadać.
Jeśli znajdziesz zgłoszenie, które dotyczy problemu, z którym się zmagasz,
dodaj swoje własne informacje reprodukcyjne do istniejącego zgłoszenia *zamiast tworzyć nowe*.
Dodanie https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[reakcji]
może również pomóc wskazać naszym utrzymującym, że dany problem dotyczy nie tylko zgłaszającego.
==== Pull Requesty
PRy do tego projektu są zawsze mile widziane i mogą być szybkim sposobem na wprowadzenie naprawy lub ulepszenia w nadchodzącej wersji.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[W zasadzie], PRy powinny:
* Naprawiać/ dodawać tylko funkcjonalność w danej sprawie *LUB* zajmować się powszechnymi problemami związanymi z białą przestrzenią/stylami, a nie oboma.
* Dodawaj testy jednostkowe lub integracyjne dla naprawionej lub zmienionej funkcjonalności (jeśli już istnieje zestaw testów).
* *Dotyczyć jednej kwestii*
* *Zawierać dokumentację* w repozytorium
* Być podążany przez kompletny szablon Pull Requesta (załadowany automatycznie, gdy tworzony jest PR).
Dla zmian, które dotyczą głównych funkcji lub wymagałyby wprowadzenia zmian (np. ważne wydanie),
najpierw najlepiej otworzyć Zgłoszenie, aby omówić swoją propozycję.
Ogólnie rzecz biorąc, stosujemy "fork-and-pull" Git workflow
1. Rozgałęź repozytorium na swoje własne konto GitHub
2. Sklonuj projekt na swoją maszynę
3. Utwórz lokalnie gałąź z zwięzłą, ale opisową nazwą
4. Zatwierdź zmiany do gałęzi
5. Przestrzegając wszelkich zasad formatowania i testowania, które są specyficzne dla tej rolę
6. Zatwierdź zmiany do swojej gałęzi
7. Otwórz PR w naszym repozytorium i postępuj według szablonu PR, abyśmy mogli efektywnie przeglądać zmiany.
[[changelog]]
== 🗒 Dziennik zmian
Proszę zapoznać się z
https://github.com/JonasPammer/ansible-role-apache2/releases[Stroną wydań tego repozytorium]
w celu uzyskania ludzkiego dziennika zmian odpowiadającego
https://github.com/JonasPammer/ansible-role-apache2/tags[Tagom (Wersjom) tego projektu].
Należy pamiętać, że ten projekt przestrzega Semantycznego Wersjonowania.
Proszę zgłaszać wszelkie przypadkowe łamiące zmiany w aktualizacji wersji mniejszej.
[[license]]
== ⚖️ Licencja
.link:LICENSE[]
----
Licencja MIT
Copyright (c) 2022, Jonas Pammer
Zezwala się na darmowe użytkowanie Kopii
tego oprogramowania i pokrewnych plików dokumentacji ("Oprogramowanie"), bez ograniczeń,
w tym, ale nie tylko, prawa do korzystania z Oprogramowania, kopiowania, modyfikowania, łączenia, publikowania, dystrybucji, sublicencjonowania i/lub sprzedawania kopii Oprogramowania, oraz na wyrażenie zgód w Oprogramowaniu, bez dalszych wymagań.
Powyższa notka o prawach autorskich i ta notka o zgodach powinny być dołączane w każdych
kopiach lub istotnych częściach Oprogramowania.
OPROGRAMOWANIE JEST DOSTARCZANE "TAKIE JAK JEST", BEZ GWARANCJI JAKIEGOKOLWIEK RODZAJU, WYRAŹNEJ LUB
DOSTATECZNEJ, W TYM, ALE NIE OGRANICZAJĄC SIĘ DO GWARANCJI SPRZEDAWALNOŚCI,
DOPASOWANIA DO OKREŚLONEGO CELU I BRAKU NARUSZEŃ. W ŻADNYM RAZIE AUTORZY LUB POSIADACZE PRAW AUTORSKICH NIE BĘDĄ ODPOWIEDZIALNI ZA ŻADNE ŻĄDANIA, SZKODY LUB INNE
ODPOWIEDZIALNOŚCI, CZY TO W DZIAŁANIU UMOWOWYM, DELIKCIE LUB INNYM, POWSTAŁE Z
KONTAKTU LUB W ZWIĄZKU Z OPROGRAMOWANIEM LUB UŻYTKIEM INNYM W TRAKCIE OPROGRAMOWANIA.
----
O projekcie
An ansible role for installing Apache2, enabling/disabling modules, configuring its defaults and creating virtual hosts.
Zainstaluj
ansible-galaxy install jonaspammer.apache2Licencja
mit
Pobrania
21.3k
Właściciel
DevOps is just FullStack with one additional layer