lrk.flyway
Rola Ansible: Narzędzie wiersza poleceń Flyway (lrk.flyway)
Rola Ansible, która instaluje narzędzie wiersza poleceń Flyway.
Obsługiwane systemy operacyjne
Ta rola została przetestowana na następujących systemach operacyjnych:
- EL - 7
- Ubuntu - Bionic / Xenial
- Debian - Buster / Stretch / Jessie
Wymagania
Ta rola nie ma żadnych wymagań, ale Flyway potrzebuje Javy do działania.
Zmienne roli
Dostępne zmienne wraz z wartościami domyślnymi są wymienione poniżej (patrz defaults/main.yml)
---
# Wersja Flyway
flyway_version: 6.0.1
# Edycja Flyway
# jeśli wersja jest wcześniejsza niż 5.2.0, ta wartość jest ignorowana
flyway_edition: community
# Główna ścieżka instalacji Flyway
flyway_install_root: /opt/flyway
# Repozytorium, z którego jest pobierany Flyway (opcjonalne)
# Domyślnie: https://repo1.maven.org/maven2
flyway_repo_url: None
# Nazwa użytkownika repozytorium do uwierzytelniania
# Domyślnie: None
flyway_repo_username: None
# Hasło repozytorium do uwierzytelniania
# Domyślnie: None
flyway_repo_password: None
# Czy usunąć domyślne sterowniki?
flyway_remove_default_drivers: false
# Skonfiguruj dodatkowe sterowniki do pobrania poprzez maven
# Domyślnie: pusta
# Przykład:
# flyway_additional_mvn_drivers:
# - {
# group_id: "group.id", # identyfikator grupy sterownika
# artifact_id: "artifact.id", # identyfikator artefaktu sterownika
# version: "1.0.0", # wersja sterownika
# extension: "jar", # (opcjonalnie) rozszerzenie artefaktu maven. Domyślnie: jar
# classifier: None, # (opcjonalnie) klasyfikator maven. Domyślnie: None
# state: "present", # (opcjonalnie) stan artefaktu. Domyślnie: present
# repo_url: None, # (opcjonalnie) repozytorium, z którego powinien być pobrany sterownik. Domyślnie: https://repo1.maven.org/maven2
# repo_user: None, # (opcjonalnie) nazwa użytkownika repozytorium. Domyślnie: flyway_repo_username
# repo_password: None, # (opcjonalnie) hasło repozytorium. Domyślnie: flyway_repo_password
# repo_validate_certs: "yes", # (opcjonalnie) walidacja certyfikatu repozytorium. Domyślnie: yes
# }
# - ...
flyway_additional_mvn_drivers: []
# Konfiguracja Flyway
# zobacz https://flywaydb.org/documentation/configfiles
# URL JDBC używany do połączenia z bazą danych
# Przykłady
# --------
# Większość sterowników jest dostarczana z pudełka.
# * = Sterownik JDBC musi być pobrany i zainstalowany w /drivers ręcznie
# ** = Zmienna środowiskowa TNS_ADMIN musi wskazywać na katalog, w którym znajduje się tnsnames.ora
# Aurora MySQL : jdbc:mysql://<instance>.<region>.rds.amazonaws.com:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
# Aurora PostgreSQL : jdbc:postgresql://<instance>.<region>.rds.amazonaws.com:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
# CockroachDB : jdbc:postgresql://<host>:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
# DB2* : jdbc:db2://<host>:<port>/<database>
# Derby : jdbc:derby:<subsubprotocol>:<database><;atrybut=value>
# Firebird : jdbc:firebirdsql://<host>[:<port>]/<database>?<key1>=<value1>&<key2>=<value2>...
# H2 : jdbc:h2:<file>
# HSQLDB : jdbc:hsqldb:file:<file>
# Informix* : jdbc:informix-sqli://<host>:<port>/<database>:informixserver=dev
# MariaDB : jdbc:mariadb://<host>:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
# MySQL : jdbc:mysql://<host>:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
# Oracle* : jdbc:oracle:thin:@//<host>:<port>/<service>
# Oracle* (TNS)** : jdbc:oracle:thin:@<tns_entry>
# PostgreSQL : jdbc:postgresql://<host>:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
# SAP HANA* : jdbc:sap://<host>:<port>/?databaseName=<database>
# SQL Server : jdbc:sqlserver:////<host>:<port>;databaseName=<database>
# SQLite : jdbc:sqlite:<database>
# Sybase ASE : jdbc:jtds:sybase://<host>:<port>/<database>
# Redshift* : jdbc:redshift://<host>:<port>/<database>
flyway_url: null
# W pełni kwalifikowana nazwa klasy sterownika JDBC (domyślnie wykrywana na podstawie flyway.url)
flyway_driver: null
# Użytkownik do użycia do połączenia z bazą danych. Flyway poprosi o jego podanie, jeśli nie zostanie określony.
flyway_user: null
# Hasło do użycia do połączenia z bazą danych. Flyway poprosi o jego podanie, jeśli nie zostanie określone.
flyway_password: null
# Maksymalna liczba prób przy łączeniu się z bazą danych. Po każdej nieudanej próbie,
# Flyway poczeka 1 sekundę przed ponowną próbą połączenia, do maksymalnej liczby określonej przez connectRetries. (domyślnie: 0)
flyway_connect_retries: 0
# SQL, które mają być uruchomione w celu zainicjowania nowego połączenia z bazą danych bezpośrednio po jego otwarciu. (domyślnie: brak)
flyway_init_sql: null
# Lista oddzielona przecinkami schematów zarządzanych przez Flyway. Te nazwy schematów są wrażliwe na wielkość liter.
# Konsekwencje:
# - Flyway automatycznie spróbuje utworzyć wszystkie te schematy, chyba że pierwszy z nich już istnieje.
# - Pierwszy schemat na liście zostanie automatycznie ustawiony jako domyślny podczas migracji.
# - Pierwszy schemat na liście będzie również tym, który zawiera tabelę historii schematu.
# - Schematy będą czyszczone w kolejności na tej liście.
# - Jeśli Flyway je utworzyło, same schematy również zostaną usunięte podczas czyszczenia.
# (domyślnie: domyślny schemat dla połączenia z bazą danych)
flyway_schemas: []
# Nazwa tabeli historii schematu Flyway (domyślnie: flyway_schema_history)
# Domyślnie (tryb pojedynczego schematu) tabela historii schematu jest umieszczana w domyślnym schemacie dla połączenia
# podanego przez źródło danych.
# Gdy właściwość flyway.schemas jest ustawiona (tryb wielu schematów), tabela historii schematu jest umieszczana w pierwszym
# schemacie na liście.
flyway_table: 'flyway_schema_history'
# Przestrzeń tabel, w której zostanie utworzona tabela historii schematu, która będzie używana przez Flyway.
# Ta ustawienie jest istotne tylko dla baz danych, które wspierają pojęcie przestrzeni tabel. Jego wartość jest po prostu
# ignorowana dla wszystkich innych. (domyślnie: domyślna przestrzeń tabel dla połączenia z bazą danych)
flyway_tablespace: null
# Lista oddzielona przecinkami lokalizacji do skanowania rekurencyjnie w poszukiwaniu migracji. (domyślnie: filesystem:<<INSTALL-DIR>>/sql)
# Typ lokalizacji jest określany przez jego prefiks.
# Lokalizacje bez prefiksu lub lokalizacje zaczynające się od classpath: wskazują na pakiet w ścieżce klas i mogą zawierać
# zarówno migracje SQL, jak i oparte na Javie.
# Lokalizacje zaczynające się od filesystem: wskazują na katalog w systemie plików, mogą zawierać tylko
# migracje SQL i są skanowane rekurencyjnie tylko w nieukrytych katalogach.
flyway_locations: []
# Lista oddzielona przecinkami w pełni kwalifikowanych nazw klas niestandardowych MigrationResolver do użycia w celu rozwiązania migracji.
flyway_resolvers: []
# Jeśli ustawione na true, pomijane są domyślne wbudowane resolver-y (jdbc, spring-jdbc i sql) i używane są tylko niestandardowe resolver-y
# zdefiniowane przez 'flyway.resolvers'. (domyślnie: false)
flyway_skip_default_resolvers: false
# Lista oddzielona przecinkami katalogów zawierających sterowniki JDBC i migracje oparte na Javie.
# (domyślnie: <INSTALL-DIR>/jars)
flyway_jar_dirs: []
# Prefiks nazwy pliku dla wersjonowanych migracji SQL (domyślnie: V)
# Wersjonowane migracje SQL mają następującą strukturę nazwy pliku: prefixVERSIONseparatorDESCRIPTIONsuffix ,
# co przy użyciu domyślnych wartości przekłada się na V1_1__My_description.sql
flyway_sql_migration_prefix: "V"
# Prefiks nazwy pliku dla migracji SQL undo. (domyślnie: U)
# Migracje SQL undo są odpowiedzialne za cofnięcie efektów wersjonowanej migracji o tej samej wersji.
# Mają następującą strukturę nazwy pliku: prefixVERSIONseparatorDESCRIPTIONsuffix ,
# co przy użyciu domyślnych wartości przekłada się na U1.1__My_description.sql
# Tylko Flyway Pro i Flyway Enterprise
flyway_undo_sql_migration_prefix: "U"
# Prefiks nazwy pliku dla powtarzalnych migracji SQL (domyślnie: R)
# Powtarzalne migracje SQL mają następującą strukturę nazwy pliku: prefixSeparatorDESCRIPTIONsuffix ,
# co przy użyciu domyślnych wartości przekłada się na R__My_description.sql
flyway_repeatable_sql_migration_prefix: "R"
# Separator nazwy pliku dla migracji SQL (domyślnie: __)
# Migracje SQL mają następującą strukturę nazwy pliku: prefixVERSIONseparatorDESCRIPTIONsuffix ,
# co przy użyciu domyślnych wartości przekłada się na V1_1__My_description.sql
flyway_sql_migration_separator: "__"
#
# ZNIESIONE od wersji ??? (zobacz flyway_sql_migration_suffixes dla nowszych wersji)
#
# Sufiks nazwy pliku dla migracji SQL (domyślnie: .sql)
# Migracje SQL mają następującą strukturę nazwy pliku: prefixVERSIONseparatorDESCRIPTIONsuffix ,
# co przy użyciu domyślnych wartości przekłada się na V1_1__My_description.sql
flyway_sql_migration_suffix: null
# Lista oddzielona przecinkami sufiksów nazw plików dla migracji SQL. (domyślnie: .sql)
# Migracje SQL mają następującą strukturę nazwy pliku: prefixVERSIONseparatorDESCRIPTIONsuffix ,
# co przy użyciu domyślnych wartości przekłada się na V1_1__My_description.sql
# Można określić wiele sufiksów (jak .sql,.pkg,.pkb) dla łatwiejszej zgodności z innymi narzędziami, takimi jak
# edytory z określonymi skojarzeniami plików.
flyway_sql_migration_suffixes: []
# Czy migracje SQL powinny być przesyłane strumieniowo podczas ich wykonywania. (domyślnie: false)
# Streamowanie nie ładuje całej migracji do pamięci za jednym razem. Zamiast tego każde polecenie jest ładowane indywidualnie.
# Jest to szczególnie przydatne dla bardzo dużych migracji SQL składających się z danych referencyjnych o wielu MB lub nawet GB,
# ponieważ znacznie zmniejsza to zużycie pamięci przez Flyway.
# Tylko Flyway Pro i Flyway Enterprise
flyway_stream: false
# Czy grupować instrukcje SQL podczas ich wykonywania. (domyślnie: false)
# Grupowanie może zaoszczędzić do 99 procent okrążeń sieciowych, wysyłając do 100 instrukcji jednocześnie przez
# sieć do bazy danych, zamiast wysyłać każdą instrukcję z osobna. Jest to szczególnie przydatne dla bardzo
# dużych migracji SQL składających się z danych referencyjnych o wielu MB lub nawet GB, ponieważ może to znacznie zmniejszyć
# obciążenie sieci. Obsługiwane są wszystkie pozostałe polecenia, które są automatycznie wykonywane bez grupowania.
# Tylko Flyway Pro i Flyway Enterprise
flyway_batch: false
# Kodowanie migracji SQL (domyślnie: UTF-8)
flyway_encoding: "UTF-8"
# Czy miejsca zastępcze powinny być zastępowane. (domyślnie: true)
flyway_placeholder_replacement: true
# Miejsca zastępcze do zastąpienia w migracjach SQL
flyway_placeholders_user: null
flyway_placeholders_my_other_placeholder: null
# Prefiks każdego miejsca zastępczego (domyślnie: ${ )
flyway_placeholder_prefix: "${"
# Sufiks każdego miejsca zastępczego (domyślnie: } )
flyway_placeholder_suffix: "}"
# Docelowa wersja, do której Flyway powinien brać pod uwagę migracje.
# Domyślnie na 'latest'
# Specjalne wartości:
# - 'current': oznacza aktualną wersję schematu
# - 'latest': najnowsza wersja schematu, określona przez migrację z najwyższą wersją
flyway_target: null
# Czy automatycznie wywołać walidację, gdy uruchamiana jest migracja. (domyślnie: true)
flyway_validate_on_migrate: true
# Czy automatycznie wywołać czyszczenie, gdy wystąpi błąd walidacji. (domyślnie: false)
# Jest to wyłącznie dla wygody podczas rozwoju. Mimo iż
# zdecydowanie odradzamy zmianę skryptów migracji po ich zarejestrowaniu w SCM i uruchomieniu, to zapewnia to
# sposób radzenia sobie z tą sytuacją w płynny sposób. Baza danych zostanie automatycznie wyczyszczona, co zapewni,
# że następna migracja przywróci cię do stanu zapisanego w SCM.
# Uwaga! Nie włączać w produkcji!
flyway_clean_on_validation_error: false
# Czy wyłączyć czyszczenie. (domyślnie: false)
# Jest to szczególnie przydatne w środowiskach produkcyjnych, gdzie uruchomienie czyszczenia może być działaniem
# ograniczającym karierę.
flyway_clean_disabled: false
# Wersja do oznaczenia istniejącego schematu podczas wykonywania bazowej migracji. (domyślnie: 1)
flyway_baseline_version: 1
# Opis do oznaczenia istniejącego schematu podczas wykonywania bazowej migracji. (domyślnie: << Flyway Baseline >>)
flyway_baseline_description: "Flyway Baseline"
# Czy automatycznie wywołać bazową migrację, gdy migracja jest wykonywana w odniesieniu do niepustego schematu bez tabeli historii schematu
# Taki schemat zostanie następnie zainicjowany z baselineVersion przed wykonaniem migracji.
# Tylko migracje powyżej baselineVersion będą następnie stosowane.
# Jest to przydatne dla początkowych wdrożeń Flyway w produkcji na projektach z istniejącą bazą danych.
# Bądź ostrożny przy włączaniu tego, ponieważ usuwa to zabezpieczenie, które zapewnia
# Flyway nie migruje niewłaściwej bazy danych w przypadku błędu konfiguracji! (domyślnie: false)
flyway_baseline_on_migrate: false
# Umożliwia migracje "poza kolejnością" (domyślnie: false).
# Jeśli masz już zastosowane wersje 1 i 3, a teraz znaleziono wersję 2,
# również ją zastosuje zamiast zignorować.
flyway_out_of_order: false
# Czy Flyway powinien wyświetlić tabelę z wynikami zapytań przy uruchamianiu migracji (domyślnie: true).
# Tylko Flyway Pro i Flyway Enterprise
flyway_output_query_results: true
# Umożliwia powiązanie własnego kodu i logiki z powiadomieniami o cyklu życia Flyway (domyślnie: pusta).
# Ustaw to na listę oddzieloną przecinkami w pełni kwalifikowanych nazw klas implementacji org.flywaydb.core.api.callback.Callback.
flyway_callbacks: []
# Jeśli ustawione na true, domyślne wbudowane wywołania (sql) są pomijane i używane są tylko niestandardowe wywołania
# zdefiniowane przez 'flyway.callbacks'. (domyślnie: false)
flyway_skip_default_callbacks: false
# Ignoruj brakujące migracje podczas czytania tabeli historii schematu. Są to migracje, które były wykonywane przez
# wcześniejsze wdrożenie aplikacji, które nie są już dostępne w tej wersji. Na przykład: mamy migracje
# dostępne w ścieżce klas z wersjami 1.0 i 3.0. Tabela historii schematu wskazuje, że migracja z
# wersją 2.0 (nieznana dla nas) również została zastosowana. Zamiast zakończyć działanie (fail fast) z wyjątkiem,
# to logowana jest ostrzeżenie i Flyway kontynuuje normalnie. Jest to przydatne w sytuacjach, w których trzeba
# umożliwić wdrożenie nowszej wersji aplikacji, mimo że nie zawiera już migracji z wcześniejszej wersji.
# Prawda, aby kontynuować normalnie i zarejestrować ostrzeżenie, fałsz, aby zakończyć działanie
# szybko z wyjątkiem. (domyślnie: false)
flyway_ignore_missing_migrations: false
# Ignoruj zignorowane migracje podczas czytania tabeli historii schematu. Są to migracje, które były dodane pomiędzy
# już zastosowanymi migracjami w tej wersji. Na przykład: mamy migracje dostępne w ścieżce klas z
# wersjami od 1.0 do 3.0. Tabela historii schematu wskazuje, że wersja 1 została zakończona na 1.0.15, a następna
# to 2.0.0. Ale z następnym wydaniem dodano nową migrację do wersji 1: 1.0.16. Taki scenariusz jest ignorowany
# przez polecenie migrate, ale domyślnie jest odrzucany przez walidację. Gdy ignoreIgnoredMigrations jest włączone,
# taki przypadek nie zostanie zgłoszony przez polecenie walidacji. Jest to przydatne w sytuacjach, w których musisz
# dostarczyć pełny zestaw migracji w pakiecie dostawy dla wielu wersji produktu, co umożliwia dalszy rozwój
# starszych wersji.
# Prawda, aby kontynuować normalnie, fałsz, aby zakończyć działanie szybko z wyjątkiem. (domyślnie: false)
flyway_ignore_ignored_migrations: false
# Ignoruj migracje oczekujące podczas czytania tabeli historii schematu. Są to migracje, które są dostępne
# ale jeszcze nie zostały zastosowane. Może to być przydatne do weryfikacji, że zmiany migracji w trakcie
# rozwoju nie zawierają żadnych zmian łamiących walidacje migracji, które już zostały zastosowane do
# środowiska produkcyjnego, np. jako część procesu CI/CD, bez zakończenia działania z powodu istnienia
# nowych wersji migracji. (domyślnie: false)
flyway_ignore_pending_migrations: false
# Ignoruj przyszłe migracje podczas czytania tabeli historii schematu. Są to migracje, które były wykonywane przez
# nowsze wdrożenie aplikacji, które nie są jeszcze dostępne w tej wersji. Na przykład: mamy migracje
# dostępne w ścieżce klas do wersji 3.0. Tabela historii schematu wskazuje, że migracja do wersji 4.0
# (nieznana dla nas) została już zastosowana. Zamiast zakończyć działanie (fail fast) z wyjątkiem,
# logowane jest ostrzeżenie i Flyway kontynuuje normalnie. Jest to przydatne w sytuacjach, w których trzeba
# ponownie wdrożyć starszą wersję aplikacji po tym, jak baza danych została zmigrowana przez nowszą.
# prawda, aby kontynuować normalnie i zarejestrować ostrzeżenie, fałsz, aby zakończyć działanie
# szybko z wyjątkiem. (domyślnie: true)
flyway_ignore_future_migrations: true
# Czy zezwolić na mieszanie transakcyjnych i nietransakcyjnych poleceń w ramach tej samej migracji. Włączenie tego
# automatycznie powoduje, że cała migracja jest wykonywana bez transakcji.
# Zauważ, że dotyczy to tylko PostgreSQL, Aurora PostgreSQL, SQL Server i SQLite, które wszystkie mają
# instrukcje, które nie działają w ramach transakcji.
# Nie należy tego mylić z transakcją implicit, jak mają to miejsce w MySQL lub Oracle, gdzie nawet jeśli
# instrukcja DDL została uruchomiona w ramach transakcji, baza danych wyda implikowane zatwierdzenie przed i po
# jej wykonaniu.
# Prawda, jeśli mieszane migracje powinny być dozwolone. fałsz, jeśli powinien być zgłoszony błąd zamiast. (domyślnie: false)
flyway_mixed: false
# Czy grupować wszystkie oczekujące migracje w tej samej transakcji podczas ich stosowania
# (zalecane tylko dla baz danych wspierających transakcje DDL).
# prawda, jeśli migracje powinny być grupowane. fałsz, jeśli powinny być stosowane indywidualnie. (domyślnie: false)
flyway_group: false
# Nazwa użytkownika, która zostanie zarejestrowana w tabeli historii schematu jako osoba, która zastosowała migrację.
# <<pusta>> dla obecnego użytkownika bazy danych połączenia. (domyślnie: <<pusta>>).
flyway_installed_by: null
# Zasady dla wbudowanego obsługiwacza błędów, które pozwalają na nadpisanie konkretnego stanu SQL i kodów błędów w celu
# wymuszenia, aby konkretne błędy lub ostrzeżenia były traktowane jako wiadomości debugujące, wiadomości informacyjne,
# ostrzeżenia lub błędy.
# Każde nadpisanie błędu ma następujący format: STATE:12345:W.
# To jest 5-znakowy stan SQL (lub * aby dopasować wszystkie stany SQL), dwukropek,
# kod błędu SQL (lub * aby dopasować wszystkie kody błędów SQL), dwukropek i w końcu
# pożądane zachowanie, które powinno nadpisać początkowe.
# Akceptowane są następujące zachowania:
# - D aby wymusić wiadomość debugującą
# - D- aby wymusić wiadomość debugującą, ale nie wyświetlać oryginalnego stanu sql i kodu błędu
# - I aby wymusić wiadomość informacyjną
# - I- aby wymusić wiadomość informacyjną, ale nie wyświetlać oryginalnego stanu sql i kodu błędu
# - W aby wymusić ostrzeżenie
# - W- aby wymusić ostrzeżenie, ale nie wyświetlać oryginalnego stanu sql i kodu błędu
# - E aby wymusić błąd
# - E- aby wymusić błąd, ale nie wyświetlać oryginalnego stanu sql i kodu błędu
# Przykład 1: aby wymusić, aby problemy kompilacji procedury Oracle generowały
# błędy zamiast ostrzeżeń, można użyć następującego błęduOverride: 99999:17110:E
# Przykład 2: aby wymusić, aby komunikaty PRINT SQL Server były wyświetlane jako wiadomości informacyjne (bez szczegółów dotyczących stanu SQL i kodu błędu)
# zamiast ostrzeżeń, można użyć następującego błęduOverride: S0001:0:I-
# Przykład 3: aby wymusić, aby wszystkie błędy z kodem błędu SQL 123 były traktowane jako ostrzeżenia,
# można użyć następującego błęduOverride: *:123:W
# Tylko Flyway Pro i Flyway Enterprise
flyway_error_overrides: null
# Plik, w którym zostaną wyjściowe polecenia SQL z symulacji migracji. Jeśli wskazany plik znajduje się w nieistniejącym
# katalogu, Flyway utworzy wszystkie katalogi i katalogi nadrzędne, jak to potrzebne.
# <<pusta>> aby wykonać polecenia SQL bezpośrednio na bazie danych. (domyślnie: <<pusta>>)
# Tylko Flyway Pro i Flyway Enterprise
flyway_dry_run_output: null
# Czy należy aktywować wsparcie Flyway dla poleceń Oracle SQL*Plus. (domyślnie: false)
# Tylko Flyway Pro i Flyway Enterprise
flyway_oracle_sqlplus: false
# Czy Flyway powinien wydać ostrzeżenie zamiast błędu, gdy napotka polecenie Oracle SQL*Plus,
# którego jeszcze nie obsługuje. (domyślnie: false)
# Tylko Flyway Pro i Flyway Enterprise
flyway_oracle_sqlplus_warn: false
# Twój klucz licencyjny Flyway (FL01...). Jeszcze nie jesteś klientem Flyway Pro lub Enterprise Edition?
# Poproś o klucz próbny Flyway na stronie https://flywaydb.org/download/
# aby wypróbować funkcje Flyway Pro i Enterprise Edition za darmo przez 30 dni.
# Tylko Flyway Pro i Flyway Enterprise
flyway_license_key: null
Zależności
Brak
Przykład Playbooka
- hosts: serwery
roles:
- lrk.flyway
Licencja
Licencja Apache Wersja 2.0
Odniesienia
Informacje o autorze
Ta rola została stworzona przez Lrk.