Rola Ansible Nginx Passenger

Ta rola zainstaluje serwer Nginx wraz z powiązaniami Phusion Passenger do obsługi aplikacji Node, Python lub Ruby. Może również ustawić i skonfigurować stronę dla podanej domeny.

Wymagania

Ta rola korzysta z list kontroli dostępu (ACL) w systemie Linux oraz grupy o nazwie "web-admin" do przyznawania dostępu do katalogów konfiguracyjnych. Można te kroki skonfigurować ręcznie lub zainstalować rolę bbatsche.Base.

Zmienne roli

• env_name — Czy ten serwer jest w środowisku "deweloperskim", "produkcyjnym" czy innym. Domyślnie "dev".
• http_root — Gdzie powinny być tworzone katalogi strony. Domyślnie "/srv/http".
• public_directory — Publicznie widoczny katalog dla strony, np. "public" lub "htdocs". Domyślnie "public".
• max_upload_size — Maksymalny rozmiar przesyłania w MB. Domyślnie "10".
• domain — Nazwa domeny dla utworzonej strony. Domyślnie undefined.
• content_security_policy — Polityka bezpieczeństwa treści do dodania do domeny, sformatowana jako słownik list lub wartości logicznych. Odpowiednie wartości automatycznie otrzymają pojedyncze cudzysłowy ('). Domyślnie: patrz defaults/main.yml.
• nginx_configs — Dodatkowe pliki konfiguracyjne do dodania na końcu bloku server domeny. Te pliki powinny być skopiowane do /etc/nginx/conf.d. Dodaj konfiguracje dla swojego konkretnego typu serwera aplikacji tutaj. Domyślnie jest to pusty zestaw.
• passenger_app — Czy aktualna domena jest aplikacją Passenger (tj. Node, Ruby, Python)? Przydatne, gdy aplikacja musi być ponownie uruchomiona po aktualizacji konfiguracji. Domyślnie nie.
• copy_index — Skopiuj szkielet index.html do strony. Domyślnie nie.
• use_ssl — Czy udostępniać treści przez SSL (właściwie TLS). Domyślnie nie.
• use_letsencrypt — Czy używać Let's Encrypt do wygenerowania certyfikatu dla strony. W przeciwnym razie zostanie użyty certyfikat self-signed na poziomie serwera. Domyślnie nie.
• privatekey_bits — Liczba bitów do użycia przy generowaniu self-signed klucza prywatnego. Domyślnie 4096.
• dhparam_bits — Liczba bitów do użycia przy generowaniu statycznego certyfikatu DH. Domyślnie 2048. Ustalanie zbyt wysokich wartości może być czasochłonne.
• cert_valid_days — Liczba dni, przez które self-signed certyfikat będzie ważny. Domyślnie 3650 (~1 rok).
• email_address — Adres e-mail do użycia dla self-signed certyfikatu oraz Let's Encrypt. Domyślnie undefined.
• country_name — Dwuliterowy skrót kraju do użycia przy generowaniu self-signed certyfikatu. Domyślnie undefined.
• state_name — Nazwa stanu lub prowincji do użycia przy generowaniu self-signed certyfikatu. Domyślnie undefined.
• locality_name — Nazwa miasta lub lokalności do użycia przy generowaniu self-signed certyfikatu. Domyślnie undefined.
• org_name — Nazwa organizacji do użycia przy generowaniu self-signed certyfikatu. Domyślnie undefined.
• h5bp_commit — Hash Git lub numer wersji do użycia do pobierania plików z HTML5 Boilerplate Server Configs. Domyślnie "3.1.0".
• setuptools_version — Wersja setuptools do zainstalowania za pomocą Pip. Domyślnie 40.6.2.

SSL i Let's Encrypt

Let's Encrypt wymaga, aby Twój serwer www był dostępny z zewnątrz, dlatego nie należy go używać przy generowaniu stron deweloperskich w Vagrant lub Docker. Ponadto należy upewnić się, że DNS jest prawidłowo skonfigurowany przed utworzeniem certyfikatu. Po zrobieniu tego, dla Twojej domeny zostanie wydany w pełni wspierany i podpisany certyfikat, a także zadanie cron, aby upewnić się, że certyfikat będzie regularnie odnawiany w przyszłości. Serwer i certyfikat zostały zoptymalizowane pod kątem jak najlepszej bezpieczeństwa, uzyskując ocenę "A+" od SSL Labs od października 2017.

Przykładowy Playbook

- hosts: servers
  roles:
     - { role: bbatsche.Nginx, domain: my-test-domain.test }

Licencja

MIT

Testowanie

Wraz z tą rolą dołączony jest zestaw specyfikacji do testowania każdej czynności indywidualnie lub jako całości. Aby uruchomić te testy, najpierw musisz mieć zainstalowane Vagrant i VirtualBox. Pliki specyfikacji są napisane przy użyciu Serverspec, więc będziesz potrzebować Ruby i Bundler.

Aby uruchomić pełny zestaw specyfikacji:

$ gem install bundler
$ bundle install
$ rake

Zestaw specyfikacji będzie testować Ubuntu Trusty Tahr (14.04), Xenial Xerus (16.04) i Bionic Bever (18.04).

Aby zobaczyć dostępne zadania rake (i specyfikacje):

$ rake -T

Te specyfikacje nie są przeznaczone do testowania idempotencji. Mają na celu sprawdzenie, czy określone zadania wykonują swoje oczekiwane kroki. Idempotencję testuje się niezależnie za pomocą testów integracyjnych.