Skip to content

testing service_base

Testowanie service_base

Przypadek minimalny [#130 (closed)]

Potrzebne są dwie zmienne: service_name i docker_service_image. Sprawdzam poprawność akcji poprzez sprawdzenie definicji serwisu w systemd oraz inspekcję kontenera dockerem.

Failowanie przy braku zdefiniowanych zmiennych [#131 (closed)]

  • service_name
  • docker_service_image

Testy zmiennych analogiczne do roli service

Testy zmiennych specyficzne dla roli docker

Zakładam, że to będziemy testować tak samo jak service, czyli ustawimy konfigurację i zobaczymy czy docker ją widzi. Potencjalnie można wykorzystać ansiblowy docker_container.

docker_pull_images [#137 (closed)]

  • yes (default)
  • no

Zakładam, że jeśli obrazu nie będzie lokalnie i będzie ustawione na no to sfailuje (?), więc można sprawdzić tego faila albo z drugiej strony, ściagając najpierw obraz "ręcznie" i zobaczyć czy przejdzie.

docker_service_container_name [#138 (closed)]

  • "{{ service_name }}" - default
  • custom

docker_service_volumes [#139 (closed)]

Te info można wyciągnąć z docker inspect, więc moznaby postawić kontener z odpowiednią konfiguracją i sprawdzić czy widzi.

docker_service_ports [#140 (closed)]

J/w, te info można wyciągnąć z docker inspect, więc moznaby postawić kontener z odpowiednią konfiguracją i sprawdzić czy widzi.

docker_service_port_filters [#140 (closed)]

Wykorzystać nginxa i sprawdzić za pomoca modułu uri

docker_service_network_name [#141 (closed)]

Można wyciągnąć z docker inspect.

docker_service_command [#142 (closed)]

Można wyciągnąć z docker inspect.

docker_service_parameters [#143 (closed)]

Sprawdzam parametr --privileged na podstawie tego czy odpowiednia wartość w polu .HostConfig.Privileged wyciągnięta z docker inspect jest true.

Edited by Cyprian Kleist
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information