Cisco Cloud Native Security – Część 2, Udostępnianie infrastruktury

Kobieta Technologia

W części 1 tej serii blogów omówiliśmy różne narzędzia, które są używane podczas przechodzenia od infrastruktury do aplikacji. W tym blogu zajmiemy się dostarczaniem naszej infrastruktury jako kodu (IaC) przy użyciu Terraform, Ansible, Jenkinsa i GitHuba. Najpierw skonfigurujemy nasze środowisko programistyczne z wszystkimi narzędziami potrzebnymi do tego wdrożenia. Następnie szczegółowo przejrzymy nasze pliki konfiguracyjne Terraform i podręczniki Ansible.

Jak zawsze, Twoje środowisko programistyczne może się różnić od tego, które jest używane w tej serii, ale wszystkie narzędzia Dev, których będziemy używać, są dostępne w systemach operacyjnych Microsoft, Mac i Linux. W naszym przypadku będziemy używać Ubuntu 20.04 do uruchamiania wszystkich naszych narzędzi DevOps.

Na naszym DevBoxie wdrożymy najnowsze wersje Terraform, Ansible, AWS CLI, Docker, Jenkins i kubectl. Następnie utworzymy repozytorium GitHub do zarządzania kodem źródłowym i kontroli wersji naszej infrastruktury. W tej serii będziemy używać repozytorium Cloud Native Security SPOT-ON Series. Pierwszą rzeczą, którą zrobimy, będzie utworzenie gałęzi funkcji o nazwie infra. Będziemy używać gałęzi fabularnych do łączenia naszego kodu z gałęzią główną, która jest naszą gałęzią produkcyjną. Gdy w gałęzi głównej zostaną wprowadzone zmiany, Jenkins uruchomi kompilację. Z każdym odcinkiem SPOT-On, który tworzymy, będzie związana gałąź fabularna. Na przykład, w następnym odcinku będziemy wdrażać nasze aplikacje, więc utworzymy kolejną gałąź o nazwie apps i połączymy ją z główną.

Demonstracja wideo dla „Konfigurowanie środowiska programistycznego”.

W następnym odcinku przyjrzymy się szczegółowo instalacji. Stworzyłem również film demonstracyjny dla tych z Was, którzy wolą oglądać zamiast czytać. Ci, którzy wolą moje szczegółowe instrukcje pisemne, znajdą je poniżej. Nie martwcie się też, to nie jest ostatni odcinek tej serii! W następnym wykorzystamy GitOps i CI/CD do zbudowania i wdrożenia infrastruktury chmury. Na razie, oto mój film demonstracyjny do tej części 2:

Cisco Secure Cloud Native Security – Część 2.1 – Konfiguracja środowiska deweloperskiego

Szczegółowe instrukcje

Jeśli to czytasz, oznacza to, że jesteś zainteresowany poznaniem szczegółów tej konfiguracji. Przejdźmy więc od razu do konkretów! Po pierwsze, zajrzyjmy do Jenkinsa. Utworzymy wielogałęziowy potok o nazwie Spot On. Użyjemy Cloud Native Security SPOT ON Series jako naszego źródła gałęzi i odkryjemy wszystkie gałęzie.

Konfiguracja budowania będzie określona w pliku Jenkinsfile. Plik Jenkinsfile jest instrukcją samego potoku. Zagłębimy się bardziej w plik Jenkinsfile w następnej sekcji.

Gdy zapiszemy zadanie potoku, Jenkins przeskanuje repozytorium GitHub i znajdzie utworzone przez nas gałęzie. Kiedy zostanie uruchomiona kompilacja, pobierze kod z tego repozytorium.

Teraz, gdy mamy już nasz potok zintegrowany z naszym repozytorium kodu źródłowego, przyjrzyjmy się infrastrukturze jako kodowi. Patrząc na strukturę naszej gałęzi infra , widzimy plik Jenkinsfile, który jest naszym Pipeline as Code. Widzimy również pliki Terraform: main.tf, output.tf i variables.tf. Te pliki konfiguracyjne Terraform są ustawione w korzeniu projektu, zwanym modułem głównym (Root Module). Tam teżZnajduje się tam również katalog modules/infra, który również zawiera kilka plików Terraform. Ten katalog modułów zawiera kod, który będzie dostarczał infrastrukturę.

Jak powiedzieliśmy wcześniej, plik Jenkinsfile jest naszym Pipeline as Code i zawiera wszystkie instrukcje dotyczące budowy naszego rurociągu. Patrząc na plik Jenkinsa , najpierw definiujemy agentów rurociągu. W tym przypadku używamy tylko głównego agenta Jenkinsa, ale możemy mieć zdefiniowanych agentów dla każdego etapu, jeśli chcemy. Następnie ustawiamy zmienne środowiskowe. Tutaj ustawiamy nazwę i identyfikator środowiska, klucze dostępu i tajne klucze AWS, a także region, strefy dostępności, klucz SSH i dane uwierzytelniające FTD.

Jak widać, niektóre z tych zmiennych są zdefiniowane tutaj, w pliku Jenkinsa, ale niektóre z nich odwołują się do składni credentials(). Deklaratywny potok Jenkinsa używa tej metody pomocniczej, która obsługuje tekst tajny, nazwę użytkownika i hasło, a także tajne poświadczenia plików. Zmienne te ustawiamy w Jenkinsie na stronie Zarządzaj Jenkinsem > Zarządzaj po świadczeniami. W ten sposób możemy bezpiecznie przekazać te tajne zmienne do Terraforma.

Kolejna sekcja pliku Jenkinsa to miejsce, w którym definiujemy nasze etapy. Na razie mamy tylko jeden etap, którym jest Środowisko budowania. W ramach każdego etapu mamy wiele kroków. Pierwszy krok to po prostu echo Building Environment na wyjściu budowania. Drugim krokiem będzie terraform get -update, który jest używany do aktualizacji wszystkich nowych dostawców Terraform dodanych do projektu. W trzecim kroku zostaną zainicjowane wszystkie dostawcy skonfigurowane w projekcie. W czwartym kroku zastosowana zostanie konfiguracja Terraforma, przekazująca wszystkie zmienne potrzebne do udostępnienia środowiska.

Przyjrzyjmy się plikom konfiguracyjnym Terraforma. Pierwszym plikiem, w który należy się zagłębić, jest main.tf. Plik ten jest umieszczony w korzeniu projektu, co oznacza, że znajduje się w module głównym. W tym pliku definiujemy kolejny moduł o nazwie Infrastructure, który pochodzi z pliku ./modules/infra. O module można myśleć jak o funkcji w innych językach programowania. W tym przypadku tworzymy moduł do wdrażania naszej infrastruktury i przekazujemy do niego niezbędne zmienne środowiskowe. Dlaczego mielibyśmy to robić? Na przykład, załóżmy, że mamy wiele środowisk, takich jak Dev, Test, QA i Prod. Chcemy wdrożyć każde środowisko z tymi samymi zasobami, ale zmienne środowiskowe, takie jak adresy IP, podsieci, regiony i strefy, powinny być różne. Tutaj, w pliku main.tf, ustawiamy również naszych dostawców Terraform.

W module głównym znajduje się również plik variables. tf. Są to te same zmienne, które przekazujemy z Jenkinsa, jak pokazano powyżej, tylko deklarujemy je w Terraformie.

Następnie mamy katalog modules/infra, w którym znajdują się pliki konfiguracyjne modułów infrastruktury. W tym katalogu widzimy kolejne pliki main.tf i variables.tf. Może się to wydawać zbędne, ale pomyśl o tym tak, jakbyśmy w innych językach programowania ustawiali zmienne globalne i zmienne lokalne. W tym przypadku definiujemy zmienne w module głównym i przekazujemy je do modułu infra, co byłoby tym samym, co deklarowanie zmiennych globalnie i przekazywanie ich jako argumentów do funkcji.

Istnieją również pliki konfiguracyjne dla modułów vpc.tf, ftdv.tf, a

nd eks.tf. W każdym z tych plików zapisane są odpowiednie konfiguracje. Moglibyśmy umieścić wszystkie te konfiguracje w jednym pliku, ale rozbicie go na mniejsze części ułatwia czytanie i sprawia, że jest bardziej modułowy. Istnieje również plik o nazwie ftdv_ansible_deploy.tf

. Używamy tego pliku konfiguracyjnego Terraform do uruchamiania playbooków Ansible w kontenerze Docker. Te podręczniki Ansible są używane do konfigurowania polityki Secure Firewall, którą wdrożyliśmy na jednej z instancji EC2.

Stay tuned

W następnym odcinku tej serii użyjemy GitOps i CI/CD do budowania i wdrażania infrastruktury chmury. Mam nadzieję, że zobaczymy się ponownie!

Jeśli masz jakieś pytania, daj mi znać w komentarzach poniżej lub przez GitHub

.

Chętnie dowiemy się, co o tym myślisz. Zadaj pytanie lub zostaw komentarz poniżej.
I bądź na bieżąco z Cisco DevNet w serwisach społecznościowych!

LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel

Share

:

Czytaj dalej: https://blogs.cisco.com/developer/cloudnativesecurity02

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.