Sytuacja kobiet w IT w 2024 roku
6.12.202210 min
Tiexin Guo

Tiexin Guo Guest Security WriterGitGuardian

10 narzędzi DevOps, które warto znać w 2023

Zgromadziliśmy 10 praktycznych narzędzi, które przydadzą się każdemu DevOpsowi. Sprawdź je!

10 narzędzi DevOps, które warto znać w 2023

Do końca roku 2022 zostało już niewiele czasu, dlatego dziś chciałbym przyjrzeć się kilku nowym (względnie) narzędziom DevOps, które mogą przykuć naszą uwagę, ponieważ są w stanie zwiększyć produktywność inżynierów o kolejny poziom.

Uwaga autora: warto zauważyć, że nie wszystkie z nich to „zupełnie nowe” narzędzia, które zostały wydane w ostatnim czasie; większość z nich jest prawdopodobnie wypróbowana przez społeczność użytkowników końcowych CNCF. Warto przyjrzeć się tym narzędziom, jeśli potrzebujesz konkretnej technologii w swoich projektach.

Bez dalszych ceregieli, zaczynajmy!

Pulumi

Zacznijmy od podstaw DevOps, czyli infrastruktury.

A więc po kolei, Pulumi to narzędzie Infrastructure as Code (IaC), podobnie jak Terraform, AWS CDK, Terraform CDK, itp.

Pomimo, że Terraform stał się prawdopodobnie najpopularniejszym wyborem dla IaC, ma też pewne wady:

Czym więc jest Pulumi?

Jeśli miałeś do czynienia z AWS CDK, szybko załapiesz: tak, o to właśnie chodzi. Tyle że to narzędzie jest uniwersalne (przynajmniej stara się być) i kompatybilne z każdą chmurą.

Jeśli nie znasz AWS CDK, pomyśl o tym w ten sposób. Pulumi pozwala na zarządzanie infrastrukturą za pomocą języków programowania, które już znasz, eliminując koszty ogólne nauki kolejnego języka konfiguracji.

Dla kogo jest Pulumi? Dobre pytanie.

Jeśli znasz już jakiś język programowania, np. TypeScript, Python, Go, C#, Java itp., ale nie chcesz uczyć się kolejnego języka jakim jest HCL, Pulumi może być przeznaczony właśnie dla Ciebie. Jeśli używasz AWS, technicznie rzecz biorąc, możesz użyć również AWS CDK, ale jeśli planujesz orkiestrację architektury chmury hybrydowej, Pulumi sprawdzi się tutaj o wiele lepiej.

Jeśli często korzystasz z Terraforma, ale zmęczyły Cię już ograniczenia HCL i nie bardzo lubisz używać `count` oraz wbudowanych funkcji, które obniżają czytelność kodu infrastruktury, możesz też spróbować z Pulumi.

To narzędzie nie jest już takie „nowe”; ma ponad 14k gwiazdek na GitHubie. Ale zdecydowanie jest ono nowsze niż Terraform. Jeśli rozwiąże ono konkretny problem, warto dać mu szansę.

SOPS

SOPS, czyli skrót od Secrets OPerationS, to open-source’owy edytor plików tekstowych, który szyfruje/deszyfruje pliki w sposób automatyczny.

Szczególną uwagę skierujmy na edytor tekstu, szyfrowanie i automatyzację.

Zazwyczaj, gdy chcesz zaszyfrować plik tekstowy:

  • Używasz swojego ulubionego edytora do pisania, edytowania i manipulowania danymi tekstowymi, a następnie zapisujesz je jako plik.
  • Używasz narzędzia do szyfrowania/deszyfrowania, aby zaszyfrować cały plik.

Gdy trzeba odczytać zaszyfrowany plik:

  • Najpierw musisz odszyfrować plik za pomocą narzędzia do szyfrowania/deszyfrowania.
  • Otwierasz odszyfrowany plik (teraz jest to zwykły plik tekstowy) za pomocą wybranego edytora tekstu.

Wada tego „normalnego” procesu jest oczywista: potrzebujesz dwóch narzędzi (edytora i narzędzia do szyfrowania/deszyfrowania) do jednego zadania.

Pewnie już wiesz do czego zmierzam i masz rację: SOPS służy właśnie do tego.

W skrócie, można go zintegrować z wieloma usługami szyfrowania (takimi jak HashiCorp Vault, AWS KMS itp.), aby automatycznie zaszyfrować tajne pliki, dzięki czemu używanie repozytorium Git do przechowywania tajnych plików jest możliwe i łatwe w obsłudze.

Zaintrygowany? Więcej na ten temat przeczytasz tutaj, gdzie znajdziesz także szybkie demo/tutoriale, które możesz sam wypróbować.

Trivy

Konteneryzacja i podejście 12-factor app (dwanaście aspektów aplikacji) stały się tak popularne w dzisiejszych czasach, że przychodzą pierwsze na myśl, gdy chcesz zbudować/wdrożyć aplikację. Ponieważ mocno polegamy na obrazach kontenerów dla typowo chmurowych obciążeń, znaczenie bezpieczeństwa obrazów kontenerów cały czas rośnie: każdy kontener utworzony z obrazu dziedziczy wszystkie jego cechy – w tym luki bezpieczeństwa, błędne konfiguracje, a nawet złośliwe oprogramowanie.

Trivy to skaner bezpieczeństwa. Jest niezawodny, szybki, nie wymaga dużo wysiłku i działa wszędzie tam, gdzie go potrzebujesz. Trivy ma różne skanery, które wyszukują różne problemy bezpieczeństwa, a najbardziej znanym przypadkiem użycia jest skanowanie obrazów kontenerów znanych podatności (CVEs).

Możesz uruchomić to narzędzie CLI lokalnie, aby przeskanować lokalny obraz kontenera i inne artefakty, przed dostaniem się go do rejestru kontenerów lub przed wdrożeniem aplikacji.

Co więcej, Trivy został zaprojektowany do użycia w CI i może być łatwo zintegrowany z pipeline’em CI, dzięki czemu doskonale wpisuje się w mentalność „ciągłego wszystkiego” w DevOpsach.

Cluster API

Cluster API to podprojekt Kubernetes skupiający się na dostarczaniu deklaratywnych API i narzędzi upraszczających dostarczanie, aktualizację i obsługę wielu klastrów Kubernetes.

Rozpoczęty przez Kubernetes Special Interest Group (SIG) Cluster Lifecycle, projekt Cluster API wykorzystuje API w stylu Kubernetes i wzorce do automatyzacji zarządzania cyklem życia klastra dla operatorów platform. Infrastruktura pomocnicza, taka jak maszyny wirtualne, sieci, load balancery i VPC, a także konfiguracja klastra Kubernetes są definiowane w ten sam sposób, w jaki deweloperzy aplikacji obsługują wdrażanie i zarządzanie obciążeniami. Umożliwia to spójne i powtarzalne wdrożenia klastrów w wielu różnych środowiskach infrastrukturalnych.

Jeśli oficjalna definicja zbiła Cię z tropu, pomyśl o tym w ten sposób: możesz uruchomić jedno polecenie kubectl apply, aby utworzyć klaster K8s i działa on dla AWS, Azure, DigitalOcean, Docker, GCP, OpenStack i innych.

Nie trzeba tworzyć modułów Terraform (lub co gorsza, próbować rozgryźć wszystkie parametry modułów innych osób) dla klastrów K8s, nie trzeba kombinować, jak użyć eksctl w AWS i czegoś tam jeszcze dla innej chmury; po prostu używasz kubectl apply, aby utworzyć klastry. Brzmi ciekawie, prawda? Wiem, wiem. Dlatego właśnie jest na tej liście.

Linkerd

Linkerd to najlżejsza i najszybsza na świecie siatka usług (przynajmniej tak twierdzą). A co to jest siatka usług? Siatka usług to dedykowana warstwa infrastruktury, dzięki której komunikacja między usługami jest bezpieczna, szybka i niezawodna.

Łatwość obsługi to element, dzięki któremu Linkerd naprawdę zachwyca. Możesz go zainstalować za pomocą jednej linii komendy. I to już koniec tego akapitu. Nie wiem co tu więcej dodać; bo w sumie takie to jest proste.

No ale dobrze, rozwińmy ten temat.

Ustawienie nie zajmuje wiele czasu. Nawet obrazy docker są małe, więc można je szybciej przeciągnąć.

Architektura nie różni się tutaj drastycznie. Istnieje płaszczyzna sterowania i płaszczyzna danych, gdzie płaszczyzna sterowania jest zestawem usług odpowiedzialnych za telemetrię, API, dostarczanie danych kontrolnych do proxy płaszczyzny danych itp., a płaszczyzna danych posiada proxy, które działają obok każdej instancji usługi. Sprawdź oficjalny dokument, jeśli interesuje cię więcej szczegółów.

Istio i AWS App Mesh używają open-source’owego Envoy Proxy, wysokowydajnego rozproszonego proxy w języku C++, zaprojektowanego dla pojedynczych usług i aplikacji. Jest to złożone proxy ogólnego przeznaczenia. Linkerd, z drugiej jednak strony, używa specjalnie zaprojektowanego proxy napisanego w Rust, aby było tak małe, lekkie i bezpieczne, jak to tylko możliwe. Nie jestem tutaj, aby oceniać, który jest najlepszym i najbezpieczniejszym językiem, C ++ czy Rust, ale jako nowoczesny język ze specyficznym sposobem zarządzania pamięcią (własność zamiast odśmiecania pamięci), Rust z pewnością ma tutaj pewną przewagę.

Do zarządzania wieloma klastrami, w przeciwieństwie do Istio, Linkerd wykorzystuje mechanizm service mirroring. Konfiguracja jest również stosunkowo prosta, prawie tak samo jak w przypadku konfiguracji pojedynczego klastra, z wyjątkiem tego, że musisz zrobić to dwa razy plus płaszczyzna sterowania dla wielu klastrów.

Podsumowując, Linkerd to inny rodzaj siatki usług: narzędzie ultra lekkie, ultra proste i ultra przydatne. Linkerd to dodatkowe bezpieczeństwo, obserwowalność i niezawodność do Kubernetes bez złożoności. To też nie jest do końca nowe narzędzie, ale jeśli funkcje pasują do Twoich potrzeb i lubisz prostotę, daj mu szansę.

GitHub Actions

GitHub Actions to kolejne CI.

Dlaczego GitHub Actions?

Cóż, po pierwsze, jest w radarze technologicznym CNCF (i na etapie „oceny”, co czyni go „nowym” narzędziem), więc w pewnym sensie powinniśmy na nie spojrzeć dobrym okiem.

Po drugie, CI wchodzi często w interakcje z twoim kodem, a z natury GitHub Actions łatwo wchodzi w interakcje z twoimi repozytoriami GitHuba. Koniec więc problemów z integracją CI z repozytoriami kodu.

Kolejna korzyść dla start-upów: GitHub Actions to kwestia bardzo małej kwoty, więc jeśli właśnie wypuściłeś nowy produkt, ta kwota będzie więcej niż wystarczająca, co czyni całą tą operację całkowicie darmową. Najpewniej nie będziesz potrzebował rejestrować żadnych dodatkowych samo-hostowanych uruchomień przez dłuższy czas, no i oszczędzasz koszty uruchamiania kilku maszyn wirtualnych w jakiejś chmurze dla własnej infrastruktury tylko dla części CI.

Tekton

Tekton to kolejny CI (wiem, skopiowałem ten wiersz z poprzedniej części).

Kluczowe funkcje to:

  • Można go uruchomić w klastrze K8s.
  • Definiujesz pipeliny jak natywny zasób K8s i po prostu stosujesz  kubectl apply.
  • Teraz ma zarówno dashboard, jak i CLI.

Poza tym Tekton pozwala budować, testować i wdrażać w wielu środowiskach, takich jak maszyny wirtualne czy serverless. Możesz również wdrożyć u różnych dostawców chmury lub środowiskach hybrydowych za pomocą pipelinów Tekton.

Czy powinieneś korzystać z tego narzędzia? Moje zdanie jest takie, że jeśli:

  • musisz „posiadać” swój system CI (to przykładowo korzystanie z GitHub Actions za małą opłatą nie będzie dla Ciebie);
  • już używasz K8s;
  • podoba ci się sposób, w jaki współdziałasz z K8s;

to warto dać Tektonowi szansę.

Instalacja jest prosta, a uruchomienie nie zajmuje dużo czasu.

HashiCorp Harness

Harness to kolejny CI, ale to również coś więcej.

Pochodzi od znanej nam już nazwy HashiCorp i łączy w sobie kilka rzeczy:

  • CI
  • CD/GitOps
  • flagi funkcji
  • koszty chmury

Harness oferuje hostowane maszyny wirtualne (VM) do uruchamiania Twoich kompilacji. Dzięki Harness Cloud możesz bez obaw budować swój kod na infrastrukturze, którą zapewnia Harness. Poświęcisz mniej czasu i wysiłku na utrzymanie infrastruktury i zamiast tego skupisz się na tworzeniu świetnego oprogramowania.

W Harness, ciągłe dostarczanie (CD) jest modelowane za pomocą Pipeline i Stages (etapów). Na każdym etapie definiujesz co chcesz wdrożyć używając Services, gdzie chcesz wdrożyć używając Environments i jak chcesz wdrożyć używając Execution steps.

Harness GitOps pozwala wykonywać wdrożenia GitOps w Harness. Definiujesz pożądany stan usługi, którą chcesz wdrożyć w swoim manifeście Git, a następnie używasz Harness GitOps do synchronizacji stanu z klastrem Kubernetes.

Harness Feature Flags (FF) jest rozwiązaniem do zarządzania funkcjami, które pozwala na zmianę funkcjonalności oprogramowania bez konieczności wdrażania nowego kodu. Pozwala ukryć kod lub zachowanie, bez wysyłania nowych wersji oprogramowania. Flaga funkcji jest jak potężna instrukcja `if`.

W skrócie, jeśli potrzebujesz mieć SaaS CI/CD/FeatureFlags w jednym miejscu, to jest to narzędzie, na które warto zwrócić uwagę.

Thanos

Najpierw trochę o lokalnym przechowywaniu Prometheusa:

Lokalne przechowywanie Prometheusa nie jest przeznaczone do długotrwałego przechowywania; rozwiązania zewnętrzne oferują rozszerzoną pamięć i trwałość danych.

Chociaż możemy ustawić długi okres przechowywania danych jak np. lata ze storage.tsdb.retention, pozostaje pytanie o skalę i planowanie. Przy wieloletnich sondach o wysokiej rozdzielczości przetwarzanie bardzo długich zapytań może zająć dużo pamięci. Sprowadza się to również do skali: na przykład funkcja rate() przez jeden rok z 15-sekundowym interwałem scrape wymaga 2,1 miliona próbek lub około 2,6MiB danych. I to tylko dla pojedynczej metryki.

Jeśli masz małą infrastrukturę, nie ma nic złego w dostosowaniu czasu retencji do lat; obecna implementacja TSDB jest w stanie doskonale sobie z tym poradzić. W przypadku większych aplikacji należy rozważyć bardziej rozproszoną TSDB.

Thanos jest rozwiązaniem, które rozwiązuje ten problem: jest to open-source’owa, wysoce dostępna konfiguracja Prometheusa z możliwościami długoterminowego przechowywania. Jeśli napotkałeś problemy z Prometeushem, spróbuj Thanosa.

HashiCorp Sentinel

I wreszcie, porozmawiajmy o Sentinel.

Policy-as-code to podejście do zarządzania polityką, w którym polityki są definiowane, aktualizowane, udostępniane i egzekwowane za pomocą kodu, a Sentinel jest rozwiązaniem HashiCorp.

Ponieważ Sentinel jest od HashiCorp, dobrze integruje się z jego innymi produktami. Jeśli więc jesteś zaawansowanym użytkownikiem Terraform, Vault, Consul lub Nomad i chcesz wypróbować Policy-as-Code, Sentinel będzie dla ciebie odpowiednim narzędziem.

Podam kilka konkretnych przykładów tego, co może zrobić polityka Sentinel:

  • Nie pozwala na zaopatrywanie zasobów Cloud bez znaczników za pomocą Terraform.
  • Gwarantuje, że modyfikacja krytycznych danych Vault może być wykonywana tylko przez upoważnionych operatorów systemów z prawidłowym MFA.
  • Pozwala tylko na obciążenia Docker w Nomad.
  • Klucze mogą być aktualizowane tylko w godzinach pracy.

Krótka próbka kodu:

import “tfplan/v2” as tfplan
 
aws_instances = filter tfplan.resource_changes as _, rc {
  rc.mode is “managed” and
  rc.type is “aws_instance” and
  rc.change.actions is not “delete”
}
 
main = rule {
  all aws_instances as _, instance {
    (instance.change.after.tags else {}) is not empty
  }
}


Wszystko jest dość zrozumiałe, prawda? Pobierz instancje AWS z planu Terraform; tagi nie mogą być puste po zmianie (chyba że próbujesz usunąć instancję).

Jeśli interesuje cię Policy-as-Code, bądź ze mną na bieżąco; wkrótce opublikuję artykuł wprowadzający do tego tematu.

Podsumujmy

Szybka kategoryzacja wszystkich wymienionych w tym artykule narzędzi:

  • Infrastructure-as-Code: Pulumi
  • Bezpieczeństwo: SOPS,. Trivy
  • K8s/wieloklastrowe: Cluster API, Linkerd
  • CI/CD: GitHub Actions, Tekton, HashiCorp Harness
  • Monitoring: Thanos
  • Policy-as-Code: HashiCorp Sentinel

Jeśli podobał Ci się ten artykuł, polajkuj proszę, skomentuj i zasubskrybuj! Do zobaczenia w następnym.

<p>Loading...</p>