Podczas Open Source Day 2018 miałem okazję przedstawić laboratorium prezentujące pracę z Ansible w środowisku serwerów Microsoft Windows. Zawiera ono kilka ćwiczeń pokazujących praktyczne zastosowania i najczęściej pojawiające się problemy. Zachęcam do własnoręcznego przetestowania możliwości Ansible poprzez wykonanie ćwiczeń. Lab znajduje się na stronie: git.io/ansiblewins, zaś slajdy z prezentacji na stronie: bit.ly/ansiblewins
Zrealizowanie wszystkich ćwiczeń powinno zająć 2-3 godziny.
Instalacja stacji zarządzającej Ansible za pomocą gotowego szablonu
To ćwiczenie prezentuje, jak w prosty sposób można wykorzystywać portal Azure do uruchamiania gotowych konfigurowalnych zasobów obliczeniowych za pomocą jednego kliknięcia i wypełnienia prostego formularza. Udostępniony formularz instaluje pojedynczą instancję Red Hat Linux 7.3 wraz z zainstalowanym oprogramowaniem Ansible 2.5 ze wsparciem do konfigurowania nowych zasobów w Azure.
W celu uruchomienia środowiska konieczne jest zalogowanie do panelu portal.azure.com, a następnie wejście na stronę git.io/ansiblewins i kliknięcie niebieskiego przycisku “Deploy to Azure”. Następnie należy wybrać nazwę grupy zasobów (“ansiblerg”), region (“East US”) oraz wybrać i zapamiętać hasło dostępu do serwera (przykładowe hasło spełniające warunki złożoności: @ns1blePassword). Należy zaakceptować warunki i potwierdzić (“Purchase”). Serwer powinien być gotowy w ciągu 10-12 minut. Do zalogowania się należy użyć klienta ssh (np. Putty). Login to “ansible”, hasło zostało wybrane podczas uruchamiania instalacji z szablonu. W konsoli serwera można zweryfikować stan instalacji poleceniem “ansible –version”.
W przypadku konieczności utworzenia nowego konta w Azure należy wykonać następujące kroki przed uruchomieniem szablonu – opisy etykiet i przycisków mogą się różnić w zależności od języka przeglądarki:
- Wejść na stronę https://azure.microsoft.com/en-us/free/ i wybrać “Start Free account”.
- (Opcjonalnie – jeśli konto jest już założone, należy wybrać “Use another account”).
- Wybrać tworzenie nowego konta – “Create one!”.
- Wybrać tworzenie nowego konta pocztowego w domenie @outlook.com – “Get a new email address”.
- Wpisać krótki identyfikator użytkownika (nie powinien mieć więcej niż 16 znaków i nie może zawierać słów “microsoft”, “azure”, “windows”, itp).
- Wybrać hasło i zatwierdzić przez ‚Next’.
- Rozwiązać zagadkę captcha i wybrać opcję pozostania zalogowanym.
- Podłączyć kartę kredytową do konta – “Select subscription”.
Konfiguracja dostępu Ansible do konta Azure
Aby Ansible mógł korzystać z aktywnej subskrypcji Azure, musimy wykonać najpierw kilka kroków, w szczególności stworzyć dla Ansible dedykowane konto aplikacji oraz przydzielić mu dostęp do naszej subskrypcji – opisy etykiet i przycisków mogą się różnić w zależności od języka przeglądarki:
- W portalu Azure należy wybrać kolejno: Azure Active Directory / App registrations / New App Registration i wypełnić formularz następującymi danymi:
nazwa: ansible,
typ: Web app / API,
url: https://www.ansible.com/ (de fakto dowolny URL, to nie jest nigdy weryfikowane). - Wybrać: Create.
- Pozyskany w menu “Application ID” należy zapisać w pliku azure.yml w głównym katalogu labu w wierszu: azure_client_id (po dwukropku).
- Wybrać kolejno: Settings / Keys i wypełnić pierwszy wiersz następującymi danymi:
opis: ansible,
wygasanie: Never expires. - Wybrać: Save i zapisać wartość klucza – uwaga: klucz będzie wyświetlony tylko raz, jeśli nie uda się go zanotować, należy po prostu stworzyć nowy. Pozyskaną wartość należy zapisać w pliku azure.yml w głównym katalogu labu w wierszu: azure_secret (po dwukropku).
- Wybrać kolejno: Azure Active Directory / Properties i zanotować wartość: Directory ID. Pozyskaną wartość należy zapisać w pliku azure.yml w głównym katalogu labu w wierszu: azure_tenant.
- Autoryzować nowoutworzoną aplikację Ansible do zarządzania naszą subskrypcją przez wybranie kolejno: Subscriptions / [nazwa subscrypcji] i zapisanie wartości: Subscription ID. Pozyskaną wartość należy zapisać w pliku azure.yml w głównym katalogu labu w wierszu: azure_subscription_id.
- Wybrać kolejno: Access Control (IAM) / Add i wypełnić formularz następującymi danymi:
rola: owner,
dostęp do: Azure AD user, group, or application,
wyszukać i wybrać: ansible,
potwierdzić poprzez “Save”.
Automatyczna instalacja środowiska Windows
To ćwiczenie pozwala uruchomić i skonfigurować do pracy instancje Microsoft Windows na zasobach Azure wyłącznie za pomocą Ansible. Proces ten w razie potrzeby może być powtarzany lub modyfikowany (gdzie modyfikacje przechowywane są w repozytorium kodu git). Niezależnie od liczby potrzebnych instancji czas wdrożenia jest stały i wynosi ok. 10-15 minut (wszystkie wymagane instancje są tworzone równolegle).
Pierwszym krokiem jest utworzenia hasła dostępowego dla maszyn Windowsowych. Odpowiednie hasło (przykładowe hasło spełniające warunki złożoności: @ns1blePassword) należy umieścić w pliku secrets.yml w głównym katalogu labu w wierszu: vault_windows_pass (po dwukropku). Następnie szyfrujemy plik poleceniem: ansible-vault encrypt secrets.yml zapamiętując podane hasło.
Następnie należy przejść do katalogu:
~/rhsummit18-ansible-windows/lab01-azure_provisioning i uruchomić skrypt deploy.sh
W czasie pracy Ansible warto zapoznać się z playbookiem, w którym zawarta jest konfiguracja środowiska.
Po zakończeniu procesu instalacji możemy potwierdzić czy wszystkie serwery są dostępne komendą:
ansible -i ../instances.txt -m win_ping windows
Alternatywnie można połączyć się do maszyn Windows za pomocą klienta RDP i danych dostępowych (IP/login/hasło) zapisanych w pliku ../instances.txt
Nienadzorowane instalowanie oprogramowania i lokalne repozytorium pakietów Chocolatey
To ćwiczenie pokazuje, jak w szybki sposób zainstalować oprogramowanie na serwerach Windows korzystając z managera pakietów Chocolatey, zawierający takie – znane z systemów linuksowych – funkcje jak instalacja z linii poleceń, rozwiązywanie zależności czy wsparcie dla wielu repozytoriów.
Należy przejść do katalogu:
~/rhsummit18-ansible-windows/lab02-installing_software i uruchomić skrypt install_software.sh
W czasie pracy Ansible warto zapoznać się z playbookiem, w którym zawarta jest konfiguracja środowiska. Na dwóch serwerach zostanie zainstalowany Putty wraz ze skrótem na pulpicie. Na pierwszym serwerze zainstalowany zostanie Git i Visual Studio Code. Na drugim serwerze zainstalowany zostanie Firefox.
Warto zwrócić uwagę, że oprogramowanie Chocolatey zostaje zainstalowane automatycznie przed pierwszym jego użyciem przez Ansible. Nie musimy zatem pamiętać o własnoręcznym wykonaniu tego kroku.
Po zainstalowaniu oprogramowania serwery zostaną zrestartowane. Można zalogować się na nie poprzez RDP, aby potwierdzić stan instalacji.
W większości środowisk korporacyjnych nie jest możliwe instalowanie oprogramowania z internetu. Dlatego przygotujemy i zainstalujemy własne repozytorium Chocolatey i dodamy do niego przykładowe pakiety.
Należy przejść do katalogu:
~/rhsummit18-ansible-windows/lab04-local_chocolatey i uruchomić skrypt setup.sh
W czasie pracy Ansible warto zapoznać się z playbookiem, w którym zawarta jest konfiguracja środowiska. Rola chocolatey_server pozwala zainstalować i skonfigurować własny serwer Chocolatey w oparciu o IIS. Role przeznaczone są do wykonywaniu wielu kroków konfiguracji systemu, które są ze sobą powiązane w logiczną całość i służą jednemu zadaniu. Role można również parametryzować przekazując jej zdefiniowane wartości argumentów. Nasza rola kolejno:
- Potwierdza, że IIS i ASP.NET są zainstalowane
- Instaluje aplikację Chocolatey.server.
- Konfiguruje odpowiednie prawa dostępu do katalogów.
- Konfiguruje aplikację w IIS i przydziela jej odpowiedni klucz API (zdefiniowany w playbooku).
Następnie playbook synchronizuje pakiet Firefox (wraz z zależnościami) do lokalnego repozytorium i weryfikuje jego działanie przez uruchomienie instalacji oprogramowania z lokalnego repozytorium na serwerze workshop-w1.
Rozwiązywanie problemów z modułami Ansible dla Windows
W tym ćwiczeniu zdefiniujemy baner, jaki powinien wyświetlać się użytkownikom w czasie logowania do systemu.
Należy przejść do katalogu:
~/rhsummit18-ansible-windows/lab03-troubleshoot i uruchomić skrypt setup1.sh
Playbook site.yml zawiera konfigurację rejestru Windows. Ustawione zostaną odpowiednio ścieżka (path), nazwa (name) i wartość (val).
Po wykonaniu playbooka logujemy się na serwer workstation-w1. Dlaczego nie pojawia się nam banner?
Uruchommy skrypt setup2.sh po to, aby zobaczyć większą liczbę szczegółów. Widzimy, że używany jest moduł win_regedit, ale nie wiemy dokładnie, jak on działa, ani jakie powinien zwracać rezultaty.
Znajdźmy linię, która mówi: Using module file /[…]/win_regedit.ps1 i zajrzyjmy do wnętrza pliku, który ona wskazuje. W naszym przypadku będzie to
/usr/local/python-virtualenvs/project-virtualenv/lib/python2.7/site-packages/ansible/modules/windows/win_regedit.ps1. Zobaczmy sam jego początek za pomocą polecenia less -N
Widzimy, że:
- Skrypt nie zawiera parametru $val
- Parametr $data (w linii 18), nie zawiera weryfikacji danych wejściowych i pozwala przekazać pustą wartość.
Okazuje się, że moduł win_regedit ignoruje fakt, że przekazano do niego wartość $val, której ten moduł nie używa. Pozwala on także na nieprzekazanie zmiennej $data, która niesie ze sobą kluczową wartość dla wykonania naszego zadania. Jeszcze jeden problem – moduł mimo, że ustawia pustą wartość w rejestrze, to zawsze w takim wypadku raportuje sukces.
Poprawmy problem, uruchamiając setup3.sh. Teraz po zalogowaniu się poprzez RDP powinniśmy zobaczyć nasz baner.
Finalnie możemy uruchomić skrypt setup4.sh, który zdefiniuje nam zmienną ANSIBLE_KEEP_REMOTE_FILES=1, która pozwoli nam zachować pliki tworzone przez Ansible na serwerach Windows. Lokalizację tych plików możemy sprawdzić za pomocą skryptu setup5.sh. Pozwoli nam to zbadać te pliki bezpośrednio na serwerze Windows w przypadku wystąpienia bardziej poważnych problemów.
Idempotentność modułów Ansible dla Windows
Ostatnie ćwiczenie ma na celu zachęcić do eksperymentowania z modułami Ansible. Czasem tę samą czynność można wykonać na wiele sposobów. W jaki sposób znaleźć najlepszy sposób?
Idempotentność to własność, dzięki której uruchamiając Ansible wielokrotnie, wciąż dostajemy te same rezultaty. Spróbujmy stworzyć nową aplikację IIS i znajdźmy idempotentny sposób na osiągnięcie tego zadania.
Należy przejść do katalogu:
~/rhsummit18-ansible-windows/lab05-idempotency i uruchomić skrypt deploy1.sh
Teraz należy uruchomić skrypt ponownie. Pojawił się błąd, który wskazuje na brak idempotentności wykorzystanego modułu raw.
Spróbujmy skrypt deploy2.sh. Zauważmy, że – pomimo że ten playbook próbuje utworzyć aplikację, która już została wcześniej przez nas utworzona – nie pojawia się błąd. Jednak wciąż dostajemy status “changed”, co sugeruje, że każde uruchomienie tego skryptu tworzy aplikację na nowo. Tak się jednak nie dzieje, to skrypt DSC nie zwraca prawidłowego statusu. Zauważmy też, że moduł DSC nie wyświetla nam zbyt użytecznych informacji na temat tego, co zostało zrobione.
Na koniec użyjemy modułu natywnego, który jest wywoływany przez skrypt deploy3.sh – i tym razem uzyskaliśmy upragnioną idempotentność. Uruchomienie modułu zwraca nam stan “ok”, który wskazuje na to, że serwis został już wcześniej utworzony. Zwraca też podstawowe informacje na temat tego, co zostało skonfigurowane.
Wszystkie trzy moduły korzystają z pliku zmiennych – vars.yml. Poeksperymentuj i zmodyfikuj jego zawartość, obserwując, jak zmienia się zachowanie naszych modułów.
To ostatnie ćwiczenie w tym cyklu. W celu poznania innych modułów i możliwości konfiguracji serwerów z Windows zachęcam do zapoznania się z laboratorium (w języku angielskim): github.com/mgmt-sa-tiger-team/lightbulb-windows.