Przetwarzanie w chmurze to ostatnio bardzo popularny temat. Wiele instytucji zastanawia się nad przeniesieniem infrastruktury na rozwiązania chmurowe.
Wykorzystanie chmury hybrydowej daje szereg korzyści. Użytkownik płaci tylko za to, czego faktycznie używa, nie ma opłat za cały miesiąc z góry, zamiast tego obowiązuje stawka za godzinę. Kolejną zaletą chmury hybrydowej jest uproszczenie procesu utrzymania infrastruktury, która wymaga znacznie mniej wysiłku od zespołu.
Rozwiązania Red Hat OpenShift oraz Red Hat Ansible w chmurze pozwalają na łatwe skalowanie w poziomie tzw. „scale-out”. OpenShift jest narzędziem dostarczającym środowisko do uruchamiania aplikacji, które dzięki wykorzystaniu konteneryzacji są dużo „lżejsze” od rozwiązania opartego o wirtualizację. Platforma OpenShift usprawnia przenoszenie i skalowanie aplikacji. „Lekkość” kontenerów zawdzięczamy funkcjonalnościom namespaces oraz cgroups, które z selinux tworzą bezpieczne i wydajne rozwiązanie. Jeżeli zależy nam na maksymalnej wydajności i bezpieczeństwie, OpenShift umożliwia pracę również w oparciu o RHEL Atomic Host.
Zobacz też: OpenShift 4.1 już dostępny
OpenShift posiada szereg narzędzi, pozwalających na zarządzanie, monitorowanie kontenerów/aplikacji – między innymi mechanizm „Horizontal pod auto scaler”. Umożliwia to automatyczne skalowanie poziome naszych aplikacji w zależności od wykorzystania cpu lub pamięci na węzłach (nodes) – maszynach wykorzystywanych do uruchamiania kontenerów. Więcej o tym mechanizmie postaram się napisać w następnym artykule.
Skoro OpenShift umożliwia łatwe skalowanie to dlaczego potrzebuję Ansible?
Co w przypadku gdy zasoby są w pełni wykorzystane na węzłach, na których pracują kontenery, a my chcielibyśmy w łatwy sposób rozbudować infrastrukturę, na której działa Red Hat OpenShift? Z pomocą przychodzi nam Ansible, który w połączeniu z chmurą hybrydową przyśpiesza i ułatwia tworzenie, a także konfigurowanie nowych węzłów, na których zostaną uruchomione kontenery.
Ansible jest narzędziem wykorzystywanym przez DevOps do automatyzacji zarządzania konfiguracją oprogramowania. Posiada wiele zalet, m.in.:
- współpracuje z najpopularniejszymi dostawcami rozwiązań chmurowych takimi jak Amazon AWS, Google Cloud Platform, Azure oraz obsługuje systemy z rodziny Linux oraz Windows;
- jest bezagentowy – do jego działania nie jest wymagana żadna instalacja agenta po stronie klienta, należy zapewnić kanał ssh/winrm i klucze ssh;
- wykorzystuje mechanizm idempotentności, co pozwala na wykonanie modułu tylko w przypadku odnotowania zmian w pliku konfiguracyjnym aplikacji, dzięki czemu proces monitorowania jest mało obciążający dla klientów;
- jest przejrzysty dzięki skryptom napisanym w języku yaml oraz strukturze opartej o moduły zarówno dla administratora, jak i dewelopera.
Podsumowując, dzięki Red Hat Ansible i ogromnej ilości modułów posiadamy jedno narzędzie, które pozwala na współpracę z wieloma rozwiązaniami. Zaczynając od instalacji i konfiguracji oprogramowania, poprzez konfigurację urządzeń sieciowych, a kończąc na wdrożeniu infrastruktury w chmurze, którą pokrótce poruszymy.
Zobacz też: DevOps — „symfonia kompetencji”
Chcę wypróbować OpenShift w chmurze hybrydowej. Co mam zrobić?
W tym artykule skupię się na Microsoft Azure, jako przykładzie chmury hybrydowej zapewniającej infrastrukturę, na której działa OpenShift. Zademonstruję, jak za pomocą narzędzia Ansible, możemy rozbudować istniejącą infrastrukturę OpenShift poprzez dodanie dodatkowego węzła, który będzie wykorzystany przez kontenery. Jakie wymagania musimy spełnić, aby zacząć przygodę z OpenShift na Azure? Przede wszystkim musimy posiadać licencję. Oczywiście mamy możliwość skorzystania z testowych licencji, dostępnych pod poniższymi linkami:
Istnieje wiele możliwości uruchomienia OpenShift na platformie hybrydowej. W celach deweloperskich wykorzystałem 30-dniową wersję próbną platformy Azure, na której został wdrożony OpenShift Origin.
Jeżeli jesteś zainteresowany dostarczeniem OpenShift w chmurze u dostawców takich jak Microsoft, Amazon, Google czy IBM skontaktuj się z nami.
Krótko na temat architektury OpenShift w chmurze hybrydowej
Poniższy rysunek przedstawia architekturę stworzoną w chmurze hybrydowej. Zawiera ona szereg komponentów, które odpowiadają za funkcjonowanie OpenShift, m.in.:
- „Master Nodes” – odpowiadają za dostarczenie Web-UI, etcd, API i innych mechanizmów odpowiedzialnych za przechowywanie informacji o całej infrastrukturze OpenShift.
- „Infra Nodes” – odpowiadają za uruchomienie podów/kontenerów, niezbędnych do działania OpenShift. Są to wszystkie ważne komponenty, bez których platforma nie byłby w pełni funkcjonalna, m.in. routers (haproxy) i registry. Za sprawą kontenera haproxy na ten węzeł/ły jest kierowany ruch przychodzący z zewnątrz do usług i finalnie do naszych podów/kontenerów.
- „Application Nodes” – węzły, które zostały odseparowane ze względów bezpieczeństwa. Są odpowiedzialne za uruchamianie stworzonych przez nas kontenerów/aplikacji. Kontenery są domyślnie widoczne tylko w wewnętrznej sieci OpenShift za sprawą funkcji „Routes”. Zawartość kontenera jest upubliczniana przez mechanizm haproxy.
- „Bastion Node” – opcjonalny węzeł, który na etapie dostarczania OpenShift w chmurze hybrydowej został wykorzystany do instalacji i konfiguracji OpenShift na pozostałych węzłach. Węzeł ten ma możliwość komunikacji z każdym węzłem w sieci i zostanie wykorzystany do skalowania infrastruktury.
- „Load Balancers” – odpowiedzialne za zapewnienie wysokiej dostępności. W naszej architekturze wyróżniamy dwa “Load Balancers”, do których są przypisane publiczne adresy oraz opublikowane odpowiednie porty. Pierwszy „Master Load Balancer” odpowiada za przekierowywanie ruchu do „Master Nodes”. Drugi przekierowuje ruch do „Infra Nodes”. „Application Nodes” mogą się komunikować z pozostałymi węzłami tylko w wewnętrznej sieci.
Model, w jakim funkcjonuje OpenShift, pozwala na stworzenie bezpiecznej i wydajnej platformy do skalowania aplikacji.
wydajnej platformy do skalowania aplikacjiZobacz też: Wstęp do zagadnień bezpieczeństwa na platformie Red Hat Openshift
Skalujemy infrastrukturę OpenShift w Azure
W celu uruchomienia playbooka/skryptu należy odpowiednio przygotować system operacyjny lub „Bastion Node”, który zostanie wykorzystany do komunikacji z API Azure. Należy dokonać instalacji odpowiednich paczek wymaganych przez Python, które są potrzebne do działania modułów Azure w Ansible.
$ sudo yum install ansible python-devel git -y
Instalujemy managera pakietów pip oraz paczki niezbędne do komunikacji z API Azure.
$ sudo easy_install pip
$ sudo pip install packaging azure azure-storage
Po zakończeniu procesu wstępnej konfiguracji musimy przekazać Ansible zmienne, które zostaną wykorzystane w procesie autentykacji i komunikacji z API Azure. Oczywiście na tym etapie istnieje wiele sposobów dostarczenia informacji do Red Hat Ansible oraz samych mechanizmów autentykacji, np.:
- Rozwiązanie „Service Principal” – jest dużo bezpieczniejsze, ale wymaga stworzenia „Application”, a następnie stworzenia i przypisania „Resource Group”, w obrębie której nasza aplikacja będzie działać – metoda obowiązkowa w środowisku produkcyjnym.
- Wykorzystanie użytkownika stworzonego w usłudze Active Directory na platformie Azure. Ten sposób autentykacji umożliwia pełen dostęp do wprowadzania zmian na platformie Microsoft Azure, jednocześnie zmniejszając bezpieczeństwo – metoda nie jest zalecana w warunkach produkcyjnych.
W tym artykule wykorzystam drugie rozwiązanie wykorzystujące autentykację w oparciu o konto AD, które pozwoli nam na uproszczenie całego procesu. Aby aplikacja Ansible mogła komunikować się z Azure API, należy wyeksportować poniższe zmienne środowiskowe. Jeśli chcemy, aby zmienne były dostępne po restarcie maszyny, należy dodać poniższe wpisy do ~/.bash_profile lub /etc/profile.d:
export AZURE_AD_USER=""
export AZURE_PASSWORD=""
export AZURE_SUBSCRIPTION_ID="6e97d9f4-xxxx-49ae-xxxx-0d6f6632ffff"
Ansible szuka informacji o poświadczeniach w wielu miejscach, m.in. w ~/.azure/credentials. Wszystko zależy od przypadku użycia. Nasze zmienne zawierają informację o użytkowniku i haśle, za pomocą którego logujemy się do platformy Azure oraz subskrypcję, której numer możemy podejrzeć po zalogowaniu się na konto i otwarciu zasobu „Subscriptions/Subskrypcje” (w zależności od wersji językowej). Poniżej zrzut ekranu.
SubskrypcjePo dodaniu wpisów do ~/.bash_profile należy pamiętać o odświeżeniu naszych zmiennych w systemie, wykonując polecenie:
$ git clone https://github.com/Qwiatu-LinuxPolska/azure-ansible-openshift.git
$ cd azure-ansible-openshift
Przed uruchomieniem skryptu ansible-openshift-add-app-node.yml musimy zadbać o określenie zmiennych, które są podane w sekcji „var”. Poniżej krótki komentarz do każdej ze zmiennych:
- rg_name: „ocplinuxpolska” – nazwa resource group, w której funkcjonuje infrastruktura OpenShift;
- rg_location: „eastus” – resource group location, w której funkcjonuje platforma OpenShift;
- vnet_name: „openshiftvnet” – nazwa wirtualnej sieci;
- vnet_subnet_name: „nodesubnet” – nazwa podsieci, z której zostanie nadany adres ip dla tworzonego węzła;
- vm_name: „s1” – nazwa węzła;
- vm_user: „ocpadmin” – nazwa użytkownika, który będzie z tworzony i wykorzystywany do procesu logowania przez Ansible;
- vm_passwd: „TajneHasło03@” – hasło do naszego użytkownika;
- ssh_public_key: „ssh-rsa AAAAB3…” – klucz publiczny, który będzie wstrzykiwany do maszyny wirtualnej podczas procesu kreowania.
Poniższe zmienne określają serwer, który zawiera niezbędne playbooki, odpowiedzialne za dodanie maszyny węzła do struktury Red Hat OpenShift. W naszym przypadku takim węzłem jest „Bastion Node”, który ze względu na wcześniejsze dostarczenie OpenShift posiada wymagane skrypty:
- vm_deployment_public_ip: „52.16.1.82” – adres publiczny „Bastion Node”;
- vm_deployment_ssh_port: „2200” – port ssh;
- vm_deployment_user: „ocpadmin” – użytkownik ssh.
Po uzupełnieniu wszystkich wymaganych zmiennych możemy przejść do uruchomienia naszego skryptu poniższym poleceniem, które rozpocznie proces automatycznego deploymentu” węzła:
$ ansible-playbook -i /etc/ansible/hosts ansible-openshift-add-app-node.yml
Należy pamiętać, że Red Hat Ansible łączy się z węzłami przy wykorzystaniu kluczy ssh. Zakładam, że użytkownik posiada właściwe klucze, umożliwiające dostęp do wszystkich dostępnych węzłów w chmurze.
Po prawidłowym wykonaniu playbooka, w chmurze Microsoft Azure oraz w OpenShift (po wydaniu polecenia „oc get nodes” w projekcie „defaults”) powinien być widoczny węzeł, który jest gotowy do uruchamiania aplikacji/kontenerów.
Zrzut z ekranu prezentujący prawidłowe dodanie węzła „s1” na platformie OpenShift.
prawidłowe dodanie węzła „s1”Zrzut ekranu prezentujący poprawne dostarczenie węzła „s1” w chmurze hybrydowej.
poprawne dostarczenie węzła „s1”Udało się. Co dalej?
W artykule pokazałem, jak dostarczyć w pełni funkcjonalny węzeł do infrastruktury OpenShift wykorzystując rozwiązania Red Hat Ansible i Microsoft Azure.
Oczywiście Ansible jako narzędzie do automatyzacji daje nam dużo więcej możliwości. Za pomocą playbooków można w łatwy sposób zautomatyzować proces skalowania infrastruktury w zależności od różnych czynników. Wszystko zależy od informacji, jakiej dostarczymy narzędziu Ansible. Tym samym automatyczny sposób skalowania może obniżyć koszty utrzymania aplikacji w chmurze hybrydowej. Taka funkcjonalność nie byłaby możliwa bez platformy OpenShift i konteneryzacji.
Jeżeli chciałbyś dowiedzieć się więcej na temat OpenShift i Ansible w modelu chmury hybrydowej zapraszamy do kontaktu.
Powiązane wpisy:
Nowy wymiar automatyzacji z Red Hat Ansible Automation Platform
Konfigurowanie systemów Windows za pomocą Ansible na platformie MS Azure
Ansible dla Splunk sprawniejszy proces budowania aplikacji
Integracja Ansible i Splunk w strategii automatyzacji IT
Warta transformuje IT dzięki konteneryzacji