OpenShift - szybki przewodnik

OpenShift to platforma programistyczna w chmurze jako usługa (PaaS) obsługiwana przez firmę Red Hat. Jest to oparta na chmurze, przyjazna dla użytkownika platforma typu open source służąca do tworzenia, testowania i uruchamiania aplikacji, a następnie wdrażania ich w chmurze.

OpenShift może zarządzać aplikacjami napisanymi w różnych językach, takich jak Node.js, Ruby, Python, Perl i Java. Jedną z kluczowych cech OpenShift jest to, że jest rozszerzalny, co pomaga użytkownikom obsługiwać aplikację napisaną w innych językach.

OpenShift zawiera różne koncepcje wirtualizacji jako warstwę abstrakcji. Podstawowa koncepcja OpenShift opiera się na wirtualizacji.

Wirtualizacja

Ogólnie wirtualizację można zdefiniować jako tworzenie systemu wirtualnego, a nie fizyczną lub rzeczywistą wersję czegokolwiek, zaczynając od systemu, pamięci masowej lub systemu operacyjnego. Głównym celem wirtualizacji jest zwiększenie skalowalności i niezawodności infrastruktury IT. Koncepcja wirtualizacji istnieje od dziesięcioleci, a wraz z rozwojem dzisiejszej branży IT można ją zastosować do szerokiego zakresu warstw, począwszy od poziomu systemu, poziomu sprzętu, a skończywszy na wirtualizacji na poziomie serwera.

Jak to działa

Można to opisać jako technologię, w której każda aplikacja lub system operacyjny jest wyodrębniony z rzeczywistej warstwy fizycznej. Jednym z kluczowych zastosowań technologii wirtualizacji jest wirtualizacja serwera, która wykorzystuje oprogramowanie zwane hiperwizorem, aby oddzielić warstwę od podstawowego sprzętu. Wydajność systemu operacyjnego działającego w ramach wirtualizacji jest tak dobra, jak w przypadku fizycznego sprzętu. Jednak koncepcja wirtualizacji jest popularna, ponieważ większość uruchomionych systemów i aplikacji nie wymaga użycia odpowiedniego sprzętu.

Architektura fizyczna a wirtualna

Rodzaje wirtualizacji

Application Virtualization- W tej metodzie aplikacja jest wyodrębniona z bazowego systemu operacyjnego. Ta metoda jest bardzo przydatna, gdy aplikacja może być uruchamiana w izolacji, bez uzależnienia od systemu operacyjnego pod nią.
Desktop Virtualization- Ta metoda służy do zmniejszenia obciążenia stacji roboczej, w której można uzyskać zdalny dostęp do pulpitu za pomocą cienkiego klienta przy biurku. W tej metodzie komputery stacjonarne są najczęściej uruchamiane w centrum danych. Klasycznym przykładem może być obraz wirtualnego pulpitu (VDI), który jest używany w większości organizacji.
Data Virtualization - Jest to metoda abstrakcji i odejścia od tradycyjnego sposobu zarządzania danymi i danymi.
Server Virtualization- W tej metodzie zwirtualizowane są zasoby związane z serwerem, w tym fizyczny serwer, proces i system operacyjny. Oprogramowanie, które umożliwia taką abstrakcję, jest często nazywane hiperwizorem.
Storage Virtualization - Jest to proces łączenia wielu urządzeń pamięci masowej w jedno urządzenie pamięci masowej, które jest zarządzane z jednej centralnej konsoli.
Network Virtualization - Jest to metoda, w której wszystkie dostępne zasoby sieciowe są łączone poprzez rozdzielenie dostępnej przepustowości i kanałów, z których każdy jest niezależny od siebie.

OpenShift

OpenShift to platforma aplikacji obsługująca chmurę jako usługa (PaaS). Jest to technologia typu open source, która pomaga organizacjom przenieść tradycyjną infrastrukturę i platformę aplikacji z fizycznych, wirtualnych nośników do chmury.

OpenShift obsługuje bardzo dużą różnorodność aplikacji, które można łatwo tworzyć i wdrażać na platformie chmurowej OpenShift. OpenShift zasadniczo obsługuje trzy rodzaje platform dla programistów i użytkowników.

Infrastruktura jako usługa (IaaS)

W tym formacie dostawca usług udostępnia maszyny wirtualne na poziomie sprzętu z pewną wstępnie zdefiniowaną wirtualną konfiguracją sprzętową. W tej przestrzeni jest wielu konkurentów, zaczynając od chmury AWS Google, Rackspace i wielu innych.

Główną wadą posiadania IaaS po długiej procedurze konfiguracji i inwestycji jest to, że nadal jest się odpowiedzialnym za instalację i utrzymanie systemu operacyjnego i pakietów serwerowych, zarządzanie siecią infrastruktury oraz podstawową administrację systemem.

Oprogramowanie jako usługa (SaaS)

W przypadku SaaS najmniej zmartwień jest podstawowa infrastruktura. Jest to tak proste, jak plug and play, w którym użytkownik musi po prostu zarejestrować się w usługach i zacząć z nich korzystać. Główną wadą tej konfiguracji jest to, że można wykonać tylko minimalną ilość dostosowań, na którą zezwala usługodawca. Jednym z najczęstszych przykładów SaaS jest Gmail, w którym użytkownik musi się tylko zalogować i zacząć go używać. Użytkownik może również wprowadzić drobne modyfikacje na swoim koncie. Jednak z punktu widzenia dewelopera nie jest to zbyt przydatne.

Platforma jako usługa (PaaS)

Można go uznać za środkową warstwę między SaaS i IaaS. Podstawowym celem oceny PaaS jest programista, w którym środowisko programistyczne można uruchomić za pomocą kilku poleceń. Te środowiska są zaprojektowane w taki sposób, aby mogły zaspokoić wszystkie potrzeby programistyczne, począwszy od posiadania serwera aplikacji internetowych z bazą danych. Aby to zrobić, potrzebujesz tylko jednego polecenia, a usługodawca zrobi wszystko za Ciebie.

Dlaczego warto korzystać z OpenShift?

OpenShift zapewnia wspólną platformę dla jednostek korporacyjnych do hostowania aplikacji w chmurze bez martwienia się o podstawowy system operacyjny. To sprawia, że korzystanie, tworzenie i wdrażanie aplikacji w chmurze jest bardzo łatwe. Jedną z kluczowych cech jest to, że zapewnia zarządzany sprzęt i zasoby sieciowe do wszelkiego rodzaju programowania i testowania. Dzięki OpenShift programista PaaS ma swobodę projektowania wymaganego środowiska ze specyfikacjami.

OpenShift zapewnia różnego rodzaju umowy dotyczące poziomu usług, jeśli chodzi o plany usług.

Free - Ten plan jest ograniczony do trzech lat z 1 GB miejsca na każdy.

Bronze - Ten plan obejmuje 3 lata i rozszerza się do 16 lat przy 1 GB przestrzeni rocznie.

Sliver - To 16-letni plan Bronze, jednak ma pojemność 6 GB bez dodatkowych kosztów.

Oprócz powyższych funkcji, OpenShift oferuje również wersję lokalną znaną jako OpenShift Enterprise. W OpenShift programiści mają możliwość projektowania skalowalnych i nieskalowalnych aplikacji, a projekty te są wdrażane przy użyciu serwerów HAproxy.

funkcje

Istnieje wiele funkcji obsługiwanych przez OpenShift. Niewielu z nich to -

Obsługa wielu języków
Obsługa wielu baz danych
System kaset rozszerzalnych
Zarządzanie wersjami kodu źródłowego
Wdrażanie jednym kliknięciem
Obsługa wielu środowisk
Standaryzowany przepływ pracy deweloperów
Zarządzanie zależnościami i kompilacją
Automatyczne skalowanie aplikacji
Responsywna konsola internetowa
Bogaty zestaw narzędzi wiersza polecenia
Zdalne logowanie SSH do aplikacji
Obsługa REST API
Samoobsługowy stos aplikacji na żądanie
Wbudowane usługi baz danych
Ciągła integracja i zarządzanie wersjami
Integracja IDE
Zdalne debugowanie aplikacji

OpenShift powstał z bazy o nazwie OpenShift V2, która opierała się głównie na koncepcji roku i kartridży, w których każdy komponent ma swoją specyfikację, począwszy od stworzenia maszyny do wdrożenia aplikacji, od zbudowania do wdrożenia aplikacji.

Cartridges - Byli centralnym punktem budowania nowej aplikacji, zaczynając od typu aplikacji, której środowisko wymaga do ich uruchomienia i wszystkich zależności spełnianych w tej sekcji.

year- Można go zdefiniować jako maszynę lub serwer z metalowym niedźwiedziem z określonymi specyfikacjami dotyczącymi zasobów, pamięci i procesora. Uważano je za podstawową jednostkę do uruchamiania aplikacji.

Application - Odnoszą się one po prostu do aplikacji lub dowolnej aplikacji integracyjnej, która zostanie wdrożona i uruchomiona w środowisku OpenShift.

W miarę zagłębiania się w tej sekcji omówimy różne formaty i oferty OpenShift. Wcześniej OpenShift miał trzy główne wersje.

OpenShift Origin- To był dodatek społecznościowy lub wersja open source OpenShift. Był również znany jako projekt upstream dla pozostałych dwóch wersji.

OpenShift Online - Jest to publiczny PaaS jako usługa hostowana na AWS.

OpenShift Enterprise - jest wzmocnioną wersją OpenShift z licencjami ISV i dostawców.

OpenShift Online

OpenShift online to oferta społeczności OpenShift, za pomocą której można szybko tworzyć, wdrażać i skalować aplikacje kontenerowe w chmurze publicznej. Jest to publiczna platforma do tworzenia i hostowania aplikacji w chmurze firmy Red Hat, która umożliwia automatyczne udostępnianie, zarządzanie i skalowanie aplikacji, co pomaga deweloperowi skupić się na pisaniu logiki aplikacji.

Zakładanie konta w Red Hat OpenShift Online

Step 1 - Przejdź do przeglądarki i odwiedź witrynę https://manage.openshift.com/

Step 2 - Jeśli masz konto Red Hat, zaloguj się do konta OpenShift przy użyciu identyfikatora logowania i hasła Red Hat, korzystając z następującego adresu URL. https://developers.redhat.com

Step 3 - Jeśli nie masz loginu do konta Red Hat, zarejestruj się w usłudze online OpenShift, korzystając z poniższego łącza.

https://developers.redhat.com/auth/realms/rhd/login-actions/registration?code=G4w-myLd3GCH_QZCqMUmIOQlU7DIf_gfIvGu38nnzZQ.cb229a9d-3cff-4c58-b7f6-7b2c9eb17926

Po zalogowaniu zobaczysz następującą stronę.

Gdy wszystko będzie gotowe, Red Hat pokaże podstawowe szczegóły konta, jak pokazano na poniższym zrzucie ekranu.

Wreszcie, gdy jesteś zalogowany, zobaczysz następującą stronę.

Platforma kontenerowa OpenShift

Platforma kontenerowa OpenShift to platforma dla przedsiębiorstw, która pomaga wielu zespołom, takim jak zespół programistów i działów IT, w tworzeniu i wdrażaniu infrastruktury kontenerowej. Wszystkie kontenery zbudowane w OpenShift wykorzystują bardzo niezawodną technologię konteneryzacji Docker, którą można wdrożyć w dowolnym centrum danych lub publicznie hostowanych platformach chmurowych.

Platforma kontenerowa OpenShift była formalnie znana jako OpenShift Enterprises. Jest to lokalna, prywatna platforma jako usługa firmy Red Hat, zbudowana w oparciu o podstawową koncepcję kontenerów aplikacji obsługiwanych przez platformę Docker, gdzie koordynacją i administracją zarządza Kubernetes.

Innymi słowy, OpenShift łączy Dockera i Kubernetes na poziomie przedsiębiorstwa. Jest to oprogramowanie platformy kontenerowej dla jednostek przedsiębiorstwa, które umożliwia wdrażanie kandydatów i zarządzanie nimi w wybranej infrastrukturze. Na przykład hosting instancji OpenShift w instancjach AWS.

Platforma kontenerowa OpenShift jest dostępna w two package levels.

OpenShift Container Local- To jest dla tych programistów, którzy chcą wdrażać i testować aplikacje na komputerze lokalnym. Ten pakiet jest używany głównie przez zespoły programistyczne do tworzenia i testowania aplikacji.

OpenShift Container Lab - Jest to przeznaczone do rozszerzonej oceny aplikacji, począwszy od etapu projektowania, aż do wdrożenia, do środowiska przed produkcją.

Dedykowany do OpenShift

To kolejna oferta dodana do portfolio OpenShift, w którym klient może wybrać hosting platformy kontenerowej w dowolnej wybranej przez siebie chmurze publicznej. Daje to użytkownikowi końcowemu prawdziwe poczucie oferty wielochmurowej, w której może używać OpenShift w dowolnej chmurze, która spełnia ich potrzeby.

Jest to jedna z najnowszych ofert firmy Red Hat, w której użytkownik końcowy może używać OpenShift do tworzenia testów wdrożeniowych i uruchamiania aplikacji w OpenShift, który jest hostowany w chmurze.

Funkcje OpenShift Dedykowane

Dedykowany OpenShift oferuje dostosowaną platformę aplikacji rozwiązań w chmurze publicznej i jest odziedziczony po technologii OpenShift 3.

Extensible and Open - Jest to oparte na otwartej koncepcji Dockera i wdrażane w chmurze, dzięki czemu może się wydawać w razie potrzeby.
Portability - Ponieważ jest zbudowany przy użyciu Dockera, aplikacje działające na platformie Docker można łatwo przenosić z jednego miejsca do drugiego, gdzie jest obsługiwany Docker.
Orchestration - Dzięki OpenShift 3 jedna z kluczowych funkcji orkiestracji kontenerów i zarządzania klastrami jest obsługiwana przy użyciu Kubernetes, który pojawił się w ofercie z OpenShift w wersji 3.
Automation - Ta wersja OpenShift jest wyposażona w funkcję zarządzania kodem źródłowym, automatyzacji kompilacji i automatyzacji wdrażania, co czyni ją bardzo popularną na rynku jako platforma jako dostawca usług.

Konkurenci OpenShift

Google App Engine- To bezpłatna platforma Google do tworzenia i hostowania aplikacji internetowych. Silnik aplikacji Google oferuje szybką platformę do tworzenia i wdrażania.

Microsoft Azure - Chmura Azure jest hostowana przez Microsoft w ich centrach danych.

Amazon Elastic Cloud Compute - Są to wbudowane usługi dostarczane przez Amazon, które pomagają w tworzeniu i hostowaniu skalowalnych aplikacji internetowych w chmurze.

Cloud Foundry - jest otwartą platformą PaaS dla aplikacji Java, Ruby, Python i Node.js.

CloudStack - CloudStack Apache to projekt opracowany przez Citrix i ma stać się bezpośrednim konkurentem OpenShift i OpenStack.

OpenStack - Kolejna technologia chmurowa dostarczona przez firmę Red Hat do przetwarzania w chmurze.

Kubernetes - Jest to technologia bezpośredniej orkiestracji i zarządzania klastrami stworzona do zarządzania kontenerem Docker.

OpenShift to system warstwowy, w którym każda warstwa jest ściśle powiązana z drugą warstwą za pomocą klastra Kubernetes i Docker. Architektura OpenShift jest zaprojektowana w taki sposób, że może obsługiwać i zarządzać kontenerami Docker, które są hostowane na wszystkich warstwach przy użyciu Kubernetes. W przeciwieństwie do wcześniejszej wersji OpenShift V2, nowa wersja OpenShift V3 obsługuje infrastrukturę kontenerową. W tym modelu Docker pomaga w tworzeniu lekkich kontenerów opartych na systemie Linux, a Kubernetes obsługuje zadanie organizowania i zarządzania kontenerami na wielu hostach.

Składniki OpenShift

Jednym z kluczowych elementów architektury OpenShift jest zarządzanie infrastrukturą kontenerową w Kubernetes. Kubernetes jest odpowiedzialny za wdrażanie i zarządzanie infrastrukturą. W każdym klastrze Kubernetes możemy mieć więcej niż jeden master i wiele węzłów, co zapewnia, że instalacja nie ma sensu.

Kubernetes Master Machine Components

Etcd- Przechowuje informacje o konfiguracji, które mogą być używane przez każdy z węzłów w klastrze. Jest to magazyn wartości kluczy o wysokiej dostępności, który można rozdzielić na wiele węzłów. Powinien być dostępny tylko przez serwer Kubernetes API, ponieważ może zawierać poufne informacje. Jest to rozproszony magazyn wartości kluczy, dostępny dla wszystkich.

API Server- Kubernetes to serwer API, który zapewnia wszystkie operacje w klastrze za pomocą API. Serwer API implementuje interfejs, co oznacza, że różne narzędzia i biblioteki mogą się z nim łatwo komunikować. Kubeconfig to pakiet wraz z narzędziami po stronie serwera, których można używać do komunikacji. Udostępnia Kubernetes API ”.

Controller Manager- Ten komponent odpowiada za większość kolektorów, które regulują stan klastra i wykonują zadanie. Można go uważać za demona, który działa w pętli niezakończonej i jest odpowiedzialny za zbieranie i wysyłanie informacji do serwera API. Działa w kierunku uzyskania udostępnionego stanu klastra, a następnie wprowadza zmiany w celu doprowadzenia bieżącego stanu serwera do pożądanego stanu. Kluczowymi kontrolerami są kontroler replikacji, kontroler punktu końcowego, kontroler przestrzeni nazw i kontroler konta usługi. Menedżer kontrolera obsługuje różnego rodzaju kontrolery do obsługi węzłów, punktów końcowych itp.

Scheduler- Jest to kluczowy składnik mastera Kubernetes. Jest to usługa w master, która odpowiada za dystrybucję obciążenia. Odpowiada za śledzenie wykorzystania obciążenia roboczego na węzłach klastra, a następnie umieszczanie obciążenia, na którym zasoby są dostępne, i akceptowanie obciążenia. Innymi słowy, jest to mechanizm odpowiedzialny za przydzielanie zasobników do dostępnych węzłów. Harmonogram jest odpowiedzialny za wykorzystanie obciążenia i przydzielanie modułu do nowego węzła.

Komponenty węzła Kubernetes

Poniżej znajdują się kluczowe komponenty serwera Node, które są niezbędne do komunikacji z masterem Kubernetes.

Docker - Pierwszym wymaganiem każdego węzła jest Docker, który pomaga w uruchamianiu hermetyzowanych kontenerów aplikacji w stosunkowo izolowanym, ale lekkim środowisku operacyjnym.

Kubelet Service- Jest to mała usługa w każdym węźle, która jest odpowiedzialna za przekazywanie informacji do i z usługi płaszczyzny sterowania. Współdziała ze sklepem etcd, aby odczytać szczegóły konfiguracji i wartości Wrighta. To komunikuje się z głównym komponentem w celu otrzymywania poleceń i pracy. Proces kubelet przejmuje wtedy odpowiedzialność za utrzymanie stanu pracy i serwera węzła. Zarządza regułami sieciowymi, przekierowaniem portów itp.

Kubernetes Proxy Service- Jest to usługa proxy, która działa na każdym węźle i pomaga w udostępnianiu usług hostowi zewnętrznemu. Pomaga w przekazywaniu żądania poprawnych kontenerów. Usługa proxy Kubernetes może przeprowadzać podstawowe równoważenie obciążenia. Daje pewność, że środowisko sieciowe jest przewidywalne i dostępne, ale jednocześnie jest izolowane. Zarządza podami w węźle, woluminach, sekretach, tworzy nowe sprawdzanie stanu kontenerów itp.

Zintegrowany rejestr kontenerów OpenShift

Rejestr kontenerów OpenShift to wbudowana jednostka pamięci firmy Red Hat, która służy do przechowywania obrazów Dockera. Wraz z najnowszą zintegrowaną wersją OpenShift pojawił się interfejs użytkownika do przeglądania obrazów w wewnętrznej pamięci OpenShift. Rejestry te mogą przechowywać obrazy z określonymi tagami, które są później używane do budowania z nich kontenerów.

Często używane terminy

Image- Obrazy Kubernetes (Docker) są kluczowymi elementami składowymi infrastruktury kontenerowej. Obecnie Kubernetes obsługuje tylko obrazy platformy Docker. Każdy kontener w kapsule ma w sobie uruchomiony obraz Dockera. Podczas konfigurowania poda właściwość obrazu w pliku konfiguracyjnym ma taką samą składnię jak polecenie Docker.

Project - Można je zdefiniować jako zmienioną nazwę domeny, która była obecna we wcześniejszej wersji OpenShift V2.

Container - Są to te, które są tworzone po wdrożeniu obrazu w węźle klastra Kubernetes.

Node- Węzeł to działająca maszyna w klastrze Kubernetes, która jest również znana jako sługa dla mistrza. Są to jednostki robocze, które mogą być instancją fizyczną, maszyną wirtualną lub chmurą.

Pod- Pod to zbiór kontenerów i ich miejsca do przechowywania w węźle klastra Kubernetes. Możliwe jest utworzenie kapsuły z wieloma kontenerami w środku. Na przykład przechowywanie kontenera bazy danych i kontenera serwera WWW wewnątrz kapsuły.

W tym rozdziale dowiemy się o konfiguracji środowiska OpenShift.

Wymagania systemowe

Aby skonfigurować Enterprise OpenShift, trzeba mieć aktywne konto Red Hat. Ponieważ OpenShift działa na architekturze master i node Kubernetes, musimy skonfigurować oba z nich na osobnych maszynach, gdzie jedna maszyna działa jako master, a druga działa w węźle. Aby skonfigurować oba, należy spełnić minimalne wymagania systemowe.

Konfiguracja maszyny głównej

Poniżej przedstawiono minimalne wymagania systemowe dotyczące konfiguracji maszyny głównej.

Maszyna podstawowa hostowana w środowisku fizycznym, wirtualnym lub w dowolnym środowisku chmury.
Co najmniej Linux 7 z wymaganymi pakietami w tej instancji.
2 rdzenie procesora.
Co najmniej 8 GB pamięci RAM.
30 GB wewnętrznej pamięci dysku twardego.

Konfiguracja maszyny węzłowej

Fizyczny lub wirtualny obraz podstawowy, taki jak podany dla maszyny głównej.
Co najmniej Linux 7 na komputerze.
Docker zainstalowany w wersji nie niższej niż 1.6.
1 rdzeń procesora.
8 GB pamięci RAM.
Dysk twardy 15 GB do przechowywania zdjęć i 15 GB do przechowywania obrazów.

Przewodnik krok po kroku do konfiguracji OpenShift

W poniższym opisie zamierzamy skonfigurować środowisko laboratoryjne OpenShift, które można później rozszerzyć na większy klaster. Ponieważ OpenShift wymaga konfiguracji głównej i węzła, potrzebowalibyśmy co najmniej dwóch maszyn hostowanych w chmurze, maszynach fizycznych lub maszynach wirtualnych.

Step 1- Najpierw zainstaluj Linuksa na obu maszynach, gdzie Linux 7 powinien być najmniejszą wersją. Można to zrobić za pomocą następujących poleceń, jeśli ktoś ma aktywną subskrypcję Red Hat.

# subscription-manager repos --disable = "*"

# subscription-manager repos --enable = "rhel-7-server-rpms"

# subscription-manager repos --enable = "rhel-7-server-extras-rpms"

# subscription-manager repos --enable = "rhel-7-server-optional-rpms"

# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install python-virtualenv

# yum install gcc

# yum install httpd-tools

# yum install docker

# yum update

Po zainstalowaniu wszystkich powyższych pakietów podstawowych na obu maszynach następnym krokiem byłoby skonfigurowanie Dockera na odpowiednich komputerach.

Step 2- Skonfiguruj Dockera tak, aby zezwalał na niezabezpieczoną komunikację tylko w sieci lokalnej. W tym celu edytuj plik Docker w / etc / sysconfig. Jeśli pliku nie ma, musisz utworzyć go ręcznie.

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

Po skonfigurowaniu Dockera na maszynie głównej, musimy ustawić komunikację bez hasła między oboma maszynami. W tym celu użyjemy uwierzytelniania za pomocą klucza publicznego i prywatnego.

Step 3 - Wygeneruj klucze na maszynie głównej, a następnie skopiuj klucz id_rsa.pub do autoryzowanego pliku kluczy maszyny węzła, co można zrobić za pomocą następującego polecenia.

# ssh-keygen

# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

Po wykonaniu wszystkich powyższych ustawień, następnym krokiem jest skonfigurowanie OpenShift w wersji 3 na maszynie głównej.

Step 4 - Na komputerze głównym uruchom następującą komendę curl.

# sh <(curl -s https://install.openshift.com/ose)

Powyższe polecenie umieści konfigurację dla OSV3. Następnym krokiem byłoby skonfigurowanie OpenShift V3 na komputerze.

Jeśli nie możesz pobrać bezpośrednio z Internetu, możesz to zrobić z witryny https://install.openshift.com/portable/oo-install-ose.tgz jako pakiet tar, z którego instalator może działać na lokalnym komputerze głównym.

Gdy mamy już gotową konfigurację, musimy zacząć od faktycznej konfiguracji OSV3 na maszynach. Ta konfiguracja jest bardzo specyficzna, aby przetestować środowisko pod kątem rzeczywistej produkcji, mamy LDAP i inne rzeczy na miejscu.

Step 5 - Na komputerze głównym skonfiguruj następujący kod znajdujący się w /etc/openshift/master/master-config.yaml

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

Następnie utwórz użytkownika standardowego do domyślnej administracji.

# htpasswd -c /root/users.htpasswd admin

Step 6- Ponieważ OpenShift używa rejestru Docker do konfigurowania obrazów, musimy skonfigurować rejestr Docker. Służy do tworzenia i przechowywania obrazów platformy Docker po kompilacji.

Utwórz katalog na maszynie węzła OpenShift za pomocą następującego polecenia.

# mkdir /images

Następnie zaloguj się do maszyny głównej przy użyciu domyślnych poświadczeń administratora, które są tworzone podczas konfigurowania rejestru.

# oc login
Username: system:admin

Przełącz się do domyślnego utworzonego projektu.

# oc project default

Step 7 - Utwórz rejestr Docker.

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

Edytuj uprawnienia użytkownika.

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry

Utwórz i edytuj rejestr obrazów.

#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

Step 8 - Utwórz trasę domyślną.

Domyślnie OpenShift używa OpenVswitch jako sieci oprogramowania. Użyj następującego polecenia, aby utworzyć trasę domyślną. Służy do równoważenia obciążenia i routingu proxy. Router jest podobny do rejestru Dockera i działa również w rejestrze.

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

Następnie edytuj uprawnienia użytkownika.

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

Step 9 - Skonfiguruj DNS.

Aby obsłużyć żądanie adresu URL, OpenShift potrzebuje działającego środowiska DNS. Ta konfiguracja DNS jest wymagana do utworzenia symbolu wieloznacznego, który jest wymagany do utworzenia symbolu wieloznacznego DNS wskazującego router.

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

Step 10- Ostatnim krokiem byłoby skonfigurowanie serwera github na maszynie głównej OpenShift V3, co jest opcjonalne. Można to łatwo zrobić za pomocą następującej sekwencji poleceń.

#yum install curl openssh-server

#systemctl enable sshd

# systemctl start sshd

# firewall-cmd --permanent --add-service = http

# systemctl reload firewalld

#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-

#yum install gitlab-ce

# gitlab-ctl reconfigure

Po zakończeniu powyższej konfiguracji możesz zweryfikować, testując i wdrażając aplikacje, o czym dowiemy się więcej w kolejnych rozdziałach.

Przed rozpoczęciem właściwej konfiguracji i wdrażania aplikacji musimy zrozumieć podstawowe terminy i pojęcia używane w OpenShift V3.

Kontenery i obrazy

Obrazy

To są podstawowe bloki konstrukcyjne OpenShift, które są tworzone z obrazów Dockera. W każdym pod OpenShift klaster ma swoje własne obrazy działające w nim. Kiedy konfigurujemy pod, mamy pole, które zostanie zebrane z rejestru. Ten plik konfiguracji pobierze obraz i wdroży go w węźle klastra.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> Name of Pod
      spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull

Aby wyciągnąć i utworzyć z niego obraz, uruchom następujące polecenie. OC to klient, który komunikuje się ze środowiskiem OpenShift po zalogowaniu.

$ oc create –f Tesing_for_Image_pull

Pojemnik

Jest to tworzone, gdy obraz platformy Docker zostanie wdrożony w klastrze OpenShift. Definiując dowolną konfigurację, w pliku konfiguracyjnym definiujemy sekcję kontenera. Jeden kontener może mieć wiele uruchomionych obrazów, a wszystkie kontenery działające w węźle klastra są zarządzane przez OpenShift Kubernetes.

spec:
   containers:
   - name: py ------------------------> Name of the container
   image: python----------> Image going to get deployed on container
   command: [“python”, “SUCCESS”]
   restartPocliy: Never --------> Restart policy of container

Poniżej przedstawiono specyfikacje dotyczące definiowania kontenera, w którym działa wiele obrazów.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
   - containerPort: 7500
      imagePullPolicy: Always
      -name: Database
      Image: mongoDB
      Ports:
      - containerPort: 7501
imagePullPolicy: Always

W powyższej konfiguracji zdefiniowaliśmy kapsułę wielokontenerową z dwoma obrazami Tomcat i MongoDB w środku.

Strąki i usługi

Strąki

Pod można zdefiniować jako zbiór kontenerów i ich przechowywania w węźle klastra OpenShift (Kubernetes). Ogólnie rzecz biorąc, mamy dwa rodzaje kapsuły, zaczynając od pojedynczego pojemnika na pojemnik na wiele pojemników.

Single Container Pod - Można je łatwo utworzyć za pomocą polecenia OC lub podstawowego pliku konfiguracyjnego yml.

$ oc run <name of pod> --image = <name of the image from registry>

Utwórz go za pomocą prostego pliku yaml w następujący sposób.

apiVersion: v1
kind: Pod
metadata:
   name: apache
spec:
   containers:
   - name: apache
   image: apache: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always

Po utworzeniu powyższego pliku wygeneruje on pod za pomocą następującego polecenia.

$ oc create –f apache.yml

Multi-Container Pod- Strąki wielokontenerowe to takie, w których mamy więcej niż jeden uruchomiony w nich kontener. Są tworzone przy użyciu plików yaml w następujący sposób.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
      - containerPort: 7501
imagePullPolicy: Always

Po utworzeniu tych plików możemy po prostu użyć tej samej metody co powyżej, aby utworzyć kontener.

Service- Ponieważ mamy zestaw kontenerów działających w zasobniku, w ten sam sposób mamy usługę, którą można zdefiniować jako logiczny zestaw zasobników. Jest to abstrakcyjna warstwa na górze kapsuły, która zapewnia pojedynczy adres IP i nazwę DNS, przez które można uzyskać dostęp do zasobników. Usługa pomaga w zarządzaniu konfiguracją równoważenia obciążenia i bardzo łatwym skalowaniu poda. W OpenShift, usługa jest obiektem REST, którego deifikacja może zostać wysłana do apiService w OpenShift master w celu utworzenia nowej instancji.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
      - port: 8080
         targetPort: 31999

Kompilacje i strumienie

Buduje

W OpenShift kompilacja to proces przekształcania obrazów w kontenery. To przetwarzanie konwertuje kod źródłowy na obraz. Ten proces kompilacji działa na wstępnie zdefiniowanej strategii budowania kodu źródłowego do obrazu.

Kompilacja przetwarza wiele strategii i źródeł.

Buduj strategie

Source to Image- To w zasadzie narzędzie, które pomaga w budowaniu powtarzalnych obrazów. Te obrazy są zawsze gotowe do uruchomienia za pomocą polecenia uruchamiania platformy Docker.
Docker Build - Jest to proces, w którym obrazy są budowane przy użyciu pliku Docker, uruchamiając proste polecenie kompilacji Docker.
Custom Build - To są kompilacje, które są używane do tworzenia podstawowych obrazów Dockera.

Buduj źródła

Git- To źródło jest używane, gdy repozytorium git jest używane do tworzenia obrazów. Plik Dockerfile jest opcjonalny. Konfiguracje z kodu źródłowego wyglądają następująco.

source:
type: "Git"
git:
   uri: "https://github.com/vipin/testing.git"
   ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"

Dockerfile - Plik Dockerfile jest używany jako dane wejściowe w pliku konfiguracyjnym.

source:
   type: "Dockerfile"
   dockerfile: "FROM ubuntu: latest
   RUN yum install -y httpd"

Image Streams- Strumienie obrazów są tworzone po ściągnięciu obrazów. Zaletą strumienia obrazów jest to, że wyszukuje aktualizacje nowej wersji obrazu. Służy do porównywania dowolnej liczby obrazów kontenerów w formacie Docker zidentyfikowanych za pomocą tagów.

Strumienie obrazów mogą automatycznie wykonywać akcję, gdy tworzony jest nowy obraz. Wszystkie kompilacje i wdrożenia mogą obserwować działanie obrazu i odpowiednio wykonywać akcję. Poniżej opisano, jak definiujemy strumień kompilacji.

apiVersion: v1
kind: ImageStream
metadata:
   annotations:
      openshift.io/generated-by: OpenShiftNewApp
   generation: 1
   labels:
      app: ruby-sample-build
   selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
   uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
   dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
   tags:
   - items:
      - created: 2016-01-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
      generation: 1
      image: vklnld908.int.clsa.com/vipin/test
   tag: latest

Trasy i szablony

Trasy

W OpenShift routing jest metodą ujawniania usługi światu zewnętrznemu poprzez tworzenie i konfigurowanie nazwy hosta osiągalnego zewnętrznie. Trasy i punkty końcowe służą do udostępnienia usługi światu zewnętrznemu, z którego użytkownik może korzystać z połączenia nazw (DNS) w celu uzyskania dostępu do określonej aplikacji.

W OpenShift trasy są tworzone przy użyciu routerów wdrożonych przez administratora OpenShift w klastrze. Routery służą do wiązania portów HTTP (80) i https (443) z aplikacjami zewnętrznymi.

Poniżej przedstawiono różne rodzaje protokołów obsługiwanych przez trasy -

HTTP
HTTPS
TSL i gniazdo sieciowe

Podczas konfigurowania usługi selektory służą do konfigurowania usługi i znajdowania punktu końcowego przy użyciu tej usługi. Poniżej znajduje się przykład, w jaki sposób tworzymy usługę i routing dla tej usługi przy użyciu odpowiedniego protokołu.

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-Rservice"},
   "spec": {
      "selector": {"name":"RService-openshift"},
      "ports": [
         {
            "protocol": "TCP",
            "port": 8888,
            "targetPort": 8080
         }
      ]
   }
}

Następnie uruchom następujące polecenie, a usługa zostanie utworzona.

$ oc create -f ~/training/content/Openshift-Rservice.json

Tak wygląda usługa po stworzeniu.

$ oc describe service Openshift-Rservice

Name:              Openshift-Rservice
Labels:            <none>
Selector:          name = RService-openshift
Type:              ClusterIP
IP:                172.30.42.80
Port:              <unnamed> 8080/TCP
Endpoints:         <none>
Session Affinity:  None
No events.

Utwórz trasę dla usługi przy użyciu następującego kodu.

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-service-route"},
   "spec": {
      "host": "hello-openshift.cloudapps.example.com",
      "to": {
         "kind": "Service",
         "name": "OpenShift-route-service"
      },
      "tls": {"termination": "edge"}
   }
}

Gdy do utworzenia trasy używana jest komenda OC, tworzona jest nowa instancja zasobu trasy.

Szablony

Szablony są zdefiniowane jako standardowy obiekt w OpenShift, którego można używać wielokrotnie. Jest sparametryzowany za pomocą listy symboli zastępczych, które są używane do tworzenia wielu obiektów. Można to wykorzystać do stworzenia wszystkiego, od poda do sieci, do której użytkownicy mają uprawnienia do tworzenia. Listę obiektów można utworzyć, jeśli szablon z interfejsu CLI lub GUI w obrazie zostanie załadowany do katalogu projektu.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Uwierzytelnianie i autoryzacja

Poświadczenie

W OpenShift, konfigurując strukturę master i client, master oferuje wbudowaną funkcję serwera OAuth. Serwer OAuth służy do generowania tokenów, które służą do uwierzytelniania w API. Ponieważ OAuth jest domyślną konfiguracją dla mastera, domyślnie używamy dostawcy tożsamości Allow All. Obecni są różni dostawcy tożsamości, których można skonfigurować pod adresem/etc/openshift/master/master-config.yaml.

W OAuth są obecne różne typy dostawców tożsamości.

Pozwól wszystkim
Zaprzeczać wszystkiemu
HTPasswd
LDAP
Uwierzytelnianie podstawowe

Pozwól wszystkim

apiVersion: v1
   kind: Pod
   metadata:
      name: redis-master
   spec:
      containers:
         image: dockerfile/redis
         name: master
      ports:
      - containerPort: 6379
         protocol: TCP
      oauthConfig:
      identityProviders:
      - name: my_allow_provider
         challenge: true
         login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Zaprzeczać wszystkiemu

apiVersion: v1
kind: Pod
metadata:
   name: redis-master
spec:
   containers:
      image: dockerfile/redis
   name: master
   ports:
   - containerPort: 6379
      protocol: TCP
   oauthConfig:
   identityProviders:
   - name: my_allow_provider
      challenge: true
      login: true
   provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

HTPasswd

Aby używać HTPasswd, musimy najpierw ustawić narzędzia Httpd na maszynie głównej, a następnie skonfigurować je w taki sam sposób, jak to zrobiliśmy dla innych.

identityProviders:
   - name: my_htpasswd_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider

Upoważnienie

Autoryzacja to funkcja mastera OpenShift, która służy do sprawdzania poprawności użytkownika. Oznacza to, że sprawdza użytkownika, który próbuje wykonać akcję, aby zobaczyć, czy użytkownik jest upoważniony do wykonania tej akcji w danym projekcie. Pomaga to administratorowi kontrolować dostęp do projektów.

Zasady autoryzacji są kontrolowane za pomocą -

Rules
Roles
Bindings

Ocena pozwolenia odbywa się za pomocą -

Identity
Action
Bindings

Korzystanie z zasad -

Polityka klastra
Polityka lokalna

OpenShift składa się z dwóch typów median służących do tworzenia i wdrażania aplikacji za pomocą interfejsu GUI lub CLI. W tym rozdziale będziemy używać CLI do tworzenia nowej aplikacji. Będziemy używać klienta OC do komunikacji ze środowiskiem OpenShift.

Tworzenie nowej aplikacji

W OpenShift istnieją trzy metody tworzenia nowej aplikacji.

Z kodu źródłowego
Z obrazu
Z szablonu

Z kodu źródłowego

Kiedy próbujemy stworzyć aplikację z kodu źródłowego, OpenShift szuka pliku Docker, który powinien znajdować się w repozytorium, który definiuje przepływ budowania aplikacji. Będziemy używać oc new-app do tworzenia aplikacji.

Pierwszą rzeczą, o której należy pamiętać podczas korzystania z repozytorium, jest to, że powinno wskazywać źródło w repozytorium, z którego OpenShift pobierze kod i zbuduje go.

Jeśli repozytorium zostanie sklonowane na komputerze Docker, na którym jest zainstalowany klient OC, a użytkownik znajduje się w tym samym katalogu, można je utworzyć za pomocą następującego polecenia.

$ oc new-app . <Hear. Denotes current working directory>

Poniżej znajduje się przykład próby zbudowania ze zdalnego repozytorium dla określonej gałęzi.

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

Tutaj test1 to gałąź, z której próbujemy utworzyć nową aplikację w OpenShift.

Określając plik Docker w repozytorium, musimy zdefiniować strategię kompilacji, jak pokazano poniżej.

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

Z obrazu

Podczas tworzenia aplikacji przy użyciu obrazów obrazy są obecne na lokalnym serwerze Docker, w wewnętrznym hostowanym repozytorium platformy Docker lub w centrum Docker. Jedyną rzeczą, którą użytkownik musi się upewnić, jest to, że ma dostęp do pobierania obrazów z centrum bez żadnych problemów.

OpenShift ma możliwość określenia używanego źródła, czy jest to obraz Docker, czy strumień źródłowy. Jeśli jednak użytkownik sobie tego życzy, może wyraźnie określić, czy jest to strumień obrazu, czy obraz Dockera.

$ oc new-app - - docker-image tomcat

Korzystanie ze strumienia obrazów -

$ oc new-app tomcat:v1

Z szablonu

Szablony mogą służyć do tworzenia nowej aplikacji. Może to być już istniejący szablon lub tworzenie nowego szablonu.

Poniższy plik yaml jest w zasadzie szablonem, którego można użyć do wdrożenia.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Opracuj i wdróż aplikację internetową

Tworzenie nowej aplikacji w OpenShift

Aby stworzyć nową aplikację w OpenShift, musimy napisać nowy kod aplikacji i zbudować go za pomocą poleceń kompilacji OpenShift OC. Jak już wspomniano, mamy wiele sposobów tworzenia nowego obrazu. Tutaj będziemy używać szablonu do budowy aplikacji. Ten szablon utworzy nową aplikację, gdy zostanie uruchomiony z poleceniem oc new-app.

Zostanie utworzony następujący szablon - Dwie aplikacje front-end i jedna baza danych. Wraz z tym utworzy dwie nowe usługi i te aplikacje zostaną wdrożone w klastrze OpenShift. Budując i wdrażając aplikację, na początku musimy utworzyć przestrzeń nazw w OpenShift i wdrożyć aplikację w tej przestrzeni nazw.

Create a new namespace

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

Szablon

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

Definicje obiektów

Secret definition in a template

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

Route definition in a template

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

Build config definition in a template

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               } 
            ]
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

Deployment config in a template

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},

Deployment config definition in a template

{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

Powyższy plik szablonu należy natychmiast skompilować. Musimy najpierw skopiować całą zawartość do jednego pliku i nazwać go jako plik yaml po zakończeniu.

Aby utworzyć aplikację, musimy uruchomić następujące polecenie.

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

Jeśli chcemy monitorować kompilację, można to zrobić za pomocą -

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

Możemy sprawdzić wdrożone aplikacje w OpenShift za pomocą -

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

Możemy sprawdzić, czy usługi aplikacji są tworzone zgodnie z definicją usługi za pomocą

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

W OpenShift mamy wiele metod automatyzacji potoku kompilacji. Aby to zrobić, musimy utworzyć zasób BuildConfig, aby opisać przepływ kompilacji. Przepływ w BuildConfig można porównać z definicją zadania w definicji zadania Jenkins. Tworząc przepływ kompilacji, musimy wybrać strategię kompilacji.

Plik BuildConfig

W OpenShift BuildConfig jest obiektem odpoczynku używanym do łączenia się z API, a następnie tworzenia nowej instancji.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

W OpenShift istnieją cztery typy strategii kompilacji.

Strategia od źródła do obrazu
Strategia Dockera
Strategia niestandardowa
Strategia rurociągów

Strategia od źródła do obrazu

Umożliwia tworzenie obrazów kontenerów zaczynając od kodu źródłowego. W tym przepływie rzeczywisty kod jest najpierw pobierany w kontenerze, a następnie kompilowany w nim. Skompilowany kod jest wdrażany w tym samym kontenerze, a obraz jest budowany na podstawie tego kodu.

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

Istnieje wiele zasad strategii.

Forcepull
Kompilacje przyrostowe
Kompilacje zewnętrzne

Strategia Dockera

W tym przepływie OpenShift używa Dockerfile do kompilowania obrazu, a następnie przekazuje utworzone obrazy do rejestru Docker.

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

Opcja pliku platformy Docker może być używana w wielu lokalizacjach, zaczynając od ścieżki pliku, bez pamięci podręcznej i wymuszonego ściągania.

Z obrazu
Ścieżka pliku Dockerfile
Brak pamięci podręcznej
Siła przyciągania

Strategia niestandardowa

Jest to jeden z różnych rodzajów strategii kompilacji, w których nie ma takiego przymusu, aby wynikiem kompilacji był obraz. Można to porównać do wolnej pracy Jenkinsa. Dzięki temu możemy tworzyć pakiety Jar, rpm i inne.

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

Składa się z wielu strategii kompilacji.

Ujawnij gniazdo Dockera
Secrets
Siła przyciągania

Strategia rurociągów

Strategia potoków służy do tworzenia niestandardowych potoków kompilacji. Jest to zasadniczo używane do implementacji przepływu pracy w potoku. Ten przepływ kompilacji używa niestandardowego przepływu potoku kompilacji przy użyciu języka Groovy DSL. OpenShift utworzy zadanie potoku w Jenkins i wykona je. Ten przepływ potoku może być również używany w Jenkins. W tej strategii używamy Jenkinsfile i dodajemy go do definicji buildconfig.

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Using build pipeline

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

OpenShift CLI służy do zarządzania aplikacjami OpenShift z wiersza poleceń. OpenShift CLI umożliwia zarządzanie pełnym cyklem życia aplikacji. Ogólnie rzecz biorąc, używalibyśmy OC, które jest klientem OpenShift do komunikacji z OpenShift.

Konfiguracja OpenShift CLI

Aby skonfigurować klienta OC w innym systemie operacyjnym, musimy przejść przez inną sekwencję kroków.

Klient OC dla Windows

Step 1 - Pobierz oc cli z poniższego linku https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Step 2 - Rozpakuj pakiet w docelowej ścieżce na komputerze.

Step 3 - Edytuj zmienną środowiskową ścieżki systemu.

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

Step 4 - Sprawdź poprawność konfiguracji OC w systemie Windows.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

Klient OC dla Mac OS X

Możemy pobrać pliki binarne instalacji Mac OS dla tej samej lokalizacji, co dla Windows, a później rozpakować je w lokalizacji i ustawić ścieżkę do pliku wykonywalnego w zmiennej środowiskowej PATH.

Alternatively

Możemy użyć Home brew i ustawić go za pomocą następującego polecenia.

$ brew install openshift-cli

Klient OC dla systemu Linux

Na tej samej stronie mamy plik tar do instalacji systemu Linux, którego można użyć do instalacji. Później można ustawić zmienną ścieżki wskazującą na tę konkretną lokalizację pliku wykonywalnego.

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Rozpakuj plik tar, używając następującego polecenia.

$ tar –xf < path to the OC setup tar file >

Uruchom następujące polecenie, aby sprawdzić uwierzytelnianie.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://localhost:8443]:

Pliki konfiguracyjne CLI

Plik konfiguracyjny OC CLI służy do zarządzania wieloma połączeniami z serwerami OpenShift i mechanizmem uwierzytelniania. Ten plik konfiguracyjny jest również używany do przechowywania wielu profili i zarządzania nimi oraz do przełączania się między nimi. Normalny plik konfiguracyjny wygląda następująco.

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Konfigurowanie klienta CLI

Do ustawiania poświadczeń użytkownika

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

Do ustawiania klastra

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

Przykład

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Do ustawienia kontekstu

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

Profile CLI

W jednym pliku konfiguracyjnym CLI możemy mieć wiele profili, przy czym każdy profil ma inną konfigurację serwera OpenShift, której później można użyć do przełączania między różnymi profilami CLI.

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

W powyższej konfiguracji widzimy, że jest on podzielony na cztery główne sekcje, zaczynając od klastra, który definiuje dwie instancje maszyn głównych OpenShift. Druga sekcja kontekstu definiuje dwa konteksty zwane vipin i alim. Bieżący kontekst określa, który kontekst jest aktualnie używany. Można go zmienić na inny kontekst lub profil, jeśli zmienimy tutaj definicję. Na koniec definiujemy definicję użytkownika i jego token uwierzytelniający, którym w naszym przypadku jest vipin.

Jeśli chcemy sprawdzić aktualnie używany profil, można to zrobić za pomocą -

$ oc status oc status In project testing Project (testing-project) $ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

Jeśli chcemy przełączyć się na inny CLI, można to zrobić z wiersza poleceń za pomocą następującego polecenia.

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

Za pomocą powyższego polecenia możemy przełączać się między profilami. W dowolnym momencie, jeśli chcemy zobaczyć konfigurację, możemy użyć polecenia $ oc config view.

OpenShift CLI jest w stanie wykonywać wszystkie podstawowe i zaawansowane konfiguracje, zarządzanie, dodawanie i wdrażanie aplikacji.

Za pomocą poleceń OC możemy wykonywać różnego rodzaju operacje. Ten klient pomaga w projektowaniu, tworzeniu, wdrażaniu i uruchamianiu aplikacji na dowolnej platformie zgodnej z OpenShift lub Kubernetes. Zawiera również polecenia administracyjne służące do zarządzania klastrem za pomocą podkomendy „adm”.

Podstawowe polecenia

Poniższa tabela zawiera podstawowe polecenia OC.

Sr.No.	Polecenia i opis
1	Types Wprowadzenie do pojęć i typów
2	Login Zaloguj się do serwera
3	new-project Poproś o nowy projekt
4	new-app Stwórz nową aplikację
5	Status Pokaż przegląd bieżącego projektu
6	Project Przejdź do innego projektu
7	Projects Wyświetl istniejące projekty
8	Explain Dokumentacja zasobów
9	Cluster Uruchamianie i zatrzymywanie klastra OpenShift

Zaloguj sie

Zaloguj się do swojego serwera i zapisz login do późniejszego wykorzystania. Użytkownicy klienta po raz pierwszy powinni uruchomić to polecenie, aby połączyć się z serwerem, ustanowić uwierzytelnioną sesję i zapisać połączenie w pliku konfiguracyjnym. Domyślna konfiguracja zostanie zapisana w Twoim katalogu domowym w „.kube / config”.

Informacje wymagane do zalogowania, takie jak nazwa użytkownika i hasło, token sesji lub dane serwera, można podać za pomocą flag. Jeśli nie zostanie podany, polecenie wyświetli monit o wprowadzenie danych przez użytkownika w razie potrzeby.

Usage

oc login [URL] [options]

Example

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

Opcje -

-p, --password = " - Hasło, pojawi się monit, jeśli nie zostanie podane

-u, --username = " - Nazwa użytkownika, jeśli nie zostanie podana, wyświetli się monit

--certificate-authority = "- Ścieżka do cert. plik dla urzędu certyfikacji

--insecure-skip-tls-verify = false- Jeśli prawda, certyfikat serwera nie będzie sprawdzany pod kątem ważności. Spowoduje to, że połączenia HTTPS będą niezabezpieczone

--token = " - Token okaziciela do uwierzytelniania na serwerze API

Aby uzyskać pełne szczegóły dotyczące dowolnego polecenia, użyj pliku oc <Command Name> --help Komenda.

Twórz i wdrażaj polecenia

Poniższa tabela zawiera listę poleceń kompilacji i wdrażania.

Sr.No.	Polecenia i opis
1	Rollout Zarządzaj wdrożeniem Kubernetes lub OpenShift
2	Deploy Wyświetl, uruchom, anuluj lub ponów próbę wdrożenia
3	Rollback Przywróć część aplikacji do poprzedniego stanu
4	new-build Utwórz nową konfigurację kompilacji
5	start-build Rozpocznij nową kompilację
6	cancel-build Anuluj aktywne, oczekujące lub nowe kompilacje
7	import-image Importuje obrazy z rejestru platformy Docker
8	Tag Oznacz istniejące obrazy jako strumienie obrazów

Polecenia zarządzania aplikacjami

Poniższa tabela zawiera listę poleceń zarządzania aplikacjami.

Sr.No.	Polecenia i opis
1	Get Wyświetl jeden lub wiele zasobów
2	Describe Pokaż szczegóły określonego zasobu lub grupy zasobów
3	Edit Edytuj zasób na serwerze
4	Set Polecenia pomagające ustawić określone funkcje na obiektach
5	Label Zaktualizuj etykiety zasobu
6	Annotate Zaktualizuj adnotacje w zasobie
7	Expose Przedstaw replikowaną aplikację jako usługę lub trasę
8	Delete Usuń jeden lub więcej zasobów
9	Scale Zmień liczbę zasobników we wdrożeniu
10	Autoscale Automatyczne skalowanie konfiguracji wdrożenia, wdrożenia, replikacji, kontrolera lub zestawu replik
11	Secrets Zarządzaj sekretami
12	Serviceaccounts Zarządzaj kontami usług w swoim projekcie

Rozwiązywanie problemów i polecenia debugowania

Poniższa tabela zawiera listę poleceń dotyczących rozwiązywania problemów i debugowania.

Sr.No.	Polecenia i opis
1	logs Wydrukuj dzienniki zasobu
2	Rsh Rozpocznij sesję powłoki w kapsule
3	Rsync Kopiuj pliki między lokalnym systemem plików a pod
4	port-forward Przekaż jeden lub więcej portów lokalnych do poda
5	Debug Uruchom nową instancję poda do debugowania
6	Exec Wykonaj polecenie w kontenerze
7	Procy Uruchom serwer proxy na serwerze Kubernetes API
9	Attach Dołącz do działającego kontenera
10	Run Uruchom określony obraz w klastrze
11	Cp Kopiuj pliki i katalogi do iz kontenerów

Zaawansowane polecenia

Poniższa tabela zawiera listę zaawansowanych poleceń.

Sr.No.	Polecenia i opis
1	adm Narzędzia do zarządzania klastrem
2	create Utwórz zasób według nazwy pliku lub standardowego wejścia
3	replace Zastąp zasób nazwą pliku lub standardowym wejściem
4	apply Zastosuj konfigurację do zasobu za pomocą nazwy pliku lub standardowego wejścia
5	patch Zaktualizuj pole (a) zasobu za pomocą strategicznej poprawki scalającej
6	process Przetwórz szablon na listę zasobów
7	export Eksportuj zasoby, aby można je było wykorzystać w innym miejscu
8	extract Wyodrębnij wpisy tajne lub mapy konfiguracji na dysk
9	idle Bezczynne skalowalne zasoby
10	observe Obserwuj zmiany w zasobach i reaguj na nie (eksperymentalnie)
11	policy Zarządzaj polityką autoryzacji
12	auth Sprawdź autoryzację
13	convert Konwertuj pliki konfiguracyjne między różnymi wersjami interfejsu API
14	import Polecenia importujące aplikacje

Polecenia ustawień

Poniższa tabela zawiera listę poleceń ustawień.

Sr.No.	Polecenia i opis
1	Logout Zakończ bieżącą sesję serwera
2	Config Zmień pliki konfiguracyjne klienta
3	Whoami Zwróć informacje o bieżącej sesji
4	Completion Kod zakończenia powłoki wyjściowej dla określonej powłoki (bash lub zsh)

OpenShift wykorzystuje dwie metody instalacji do konfigurowania klastra OpenShift.

Szybka metoda instalacji
Zaawansowana metoda konfiguracji

Konfigurowanie klastra

Szybka metoda instalacji

Ta metoda służy do uruchamiania szybkiej konfiguracji konfiguracji nieosiągniętej klastra. Aby skorzystać z tej metody, musimy najpierw zainstalować instalator. Można to zrobić, uruchamiając następujące polecenie.

Interactive method

$ atomic-openshift-installer install

Jest to przydatne, gdy chce się uruchomić instalację interaktywną.

Unattended installation method

Ta metoda jest używana, gdy chce się ustawić nienadzorowany sposób instalacji, w którym użytkownik może zdefiniować plik konfiguracyjny yaml i umieścić go pod ~/.config/openshift/o nazwie installer.cfg.yml. Następnie można uruchomić następujące polecenie, aby zainstalować–u tag.

$ atomic-openshift-installer –u install

Domyślnie używa pliku konfiguracyjnego znajdującego się w ~/.config/openshift/. Z drugiej strony Ansible służy jako kopia zapasowa instalacji.

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

Tutaj mamy zmienną specyficzną dla roli, którą można zdefiniować, jeśli chce się ustawić określoną zmienną.

Po zakończeniu możemy zweryfikować instalację za pomocą następującego polecenia.

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

Zaawansowana instalacja

Zaawansowana instalacja jest całkowicie oparta na konfiguracji Ansible, w której dostępna jest pełna konfiguracja hosta i definicja zmiennych dotyczących konfiguracji mastera i węzła. Zawiera wszystkie szczegóły dotyczące konfiguracji.

Gdy mamy już konfigurację, a playbook jest gotowy, możemy po prostu uruchomić następujące polecenie, aby skonfigurować klaster.

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

Dodawanie hostów do klastra

Możemy dodać hosta do klastra za pomocą -

Narzędzie szybkiego instalatora
Zaawansowana metoda konfiguracji

Quick installation tooldziała zarówno w trybie interaktywnym, jak i nieinteraktywnym. Użyj następującego polecenia.

$ atomic-openshift-installer -u -c </path/to/file> scaleup

Format skalowania wyglądu pliku konfiguracyjnego aplikacji można wykorzystać do dodania zarówno głównego, jak i węzła.

Zaawansowana metoda konfiguracji

W tej metodzie aktualizujemy plik hosta Ansible, a następnie dodajemy nowe szczegóły węzła lub serwera w tym pliku. Plik konfiguracyjny wygląda następująco.

[OSEv3:children]
masters
nodes
new_nodes
new_master

W tym samym pliku hostów Ansible dodaj szczegóły zmiennej dotyczące nowego węzła, jak pokazano poniżej.

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

Na koniec, używając zaktualizowanego pliku hosta, uruchom nową konfigurację i wywołaj plik konfiguracyjny, aby przeprowadzić konfigurację, używając następującego polecenia.

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

Zarządzanie dziennikami klastra

Dziennik klastra OpenShift to nic innego jak dzienniki, które są generowane z maszyn głównych i węzłów klastra. Mogą one zarządzać dowolnym rodzajem dziennika, począwszy od dziennika serwera, dziennika głównego, dziennika kontenera, dziennika podowego itp. Istnieje wiele technologii i aplikacji do zarządzania dziennikami kontenerów.

Niewiele z narzędzi jest wymienionych na liście, które można zaimplementować do zarządzania dziennikami.

Fluentd
ELK
Kabna
Nagios
Splunk

ELK stack- Ten stos jest przydatny podczas próby zebrania dzienników ze wszystkich węzłów i przedstawienia ich w usystematyzowanym formacie. Stos ELK jest podzielony głównie na trzy główne kategorie.

ElasticSearch - Odpowiedzialny głównie za zbieranie informacji ze wszystkich pojemników i umieszczanie ich w centralnej lokalizacji.

Fluentd - Służy do podawania zebranych kłód do silnika kontenera Flexiblesearch.

Kibana - Graficzny interfejs służący do prezentacji zebranych danych jako przydatnych informacji w interfejsie graficznym.

Jednym z kluczowych punktów, na które należy zwrócić uwagę, jest to, że po wdrożeniu tego systemu w klastrze rozpoczyna on zbieranie dzienników ze wszystkich węzłów.

Diagnostyka dziennika

OpenShift ma wbudowany oc adm dignosticspolecenie z OC, które może być użyte do analizy wielu sytuacji błędów. To narzędzie może być używane z poziomu głównego jako administrator klastra. To narzędzie jest bardzo pomocne w rozwiązywaniu problemów i eliminowaniu znanych problemów. Działa na głównym kliencie i węzłach.

Jeśli zostanie uruchomiony bez żadnych agrumentów lub flag, będzie szukał plików konfiguracyjnych klienta, serwera i węzłów i używał ich do diagnostyki. Diagnostykę można uruchomić indywidualnie, podając następujące argumenty -

AggregatedLogging
AnalyzeLogs
ClusterRegistry
ClusterRoleBindings
ClusterRoles
ClusterRouter
ConfigContexts
DiagnosticPod
MasterConfigCheck
MasterNode
MetricsApiProxy
NetworkCheck
NodeConfigCheck
NodeDefinitions
ServiceExternalIPs
UnitStatus

Można je po prostu uruchomić za pomocą następującego polecenia.

$ oc adm diagnostics <DiagnosticName>

Aktualizacja klastra

Aktualizacja klastra obejmuje aktualizację wielu rzeczy w klastrze i pobranie aktualizacji klastra o nowe komponenty i aktualizacje. Obejmuje to -

Aktualizacja głównych komponentów
Modernizacja komponentów węzła
Aktualizacja zasad
Modernizacja tras
Aktualizacja strumienia obrazu

Aby wykonać wszystkie te aktualizacje, musimy najpierw zainstalować szybkie instalatory lub narzędzia. W tym celu musimy zaktualizować następujące narzędzia -

atomic-openshift-utils
atomic-openshift-excluder
atomic-openshift-docker-excluder
pakiet etcd

Przed rozpoczęciem aktualizacji musimy wykonać kopię zapasową etcd na maszynie głównej, co można zrobić za pomocą następujących poleceń.

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \ --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

Aktualizacja głównych komponentów

W OpenShift master, aktualizację rozpoczynamy od aktualizacji pliku etcd, a następnie przechodzimy do Dockera. Na koniec uruchamiamy automatyczny program wykonawczy, aby ustawić klaster w wymaganej pozycji. Jednak przed rozpoczęciem aktualizacji musimy najpierw aktywować atomowe pakiety openshift na każdym z masterów. Można to zrobić za pomocą następujących poleceń.

Step 1 - Usuń pakiety atomic-openshift

$ atomic-openshift-excluder unexclude

Step 2 - Uaktualnij etcd na wszystkich masterach.

$ yum update etcd

Step 3 - Uruchom ponownie usługę etcd i sprawdź, czy została pomyślnie uruchomiona.

$ systemctl restart etcd
$ journalctl -r -u etcd

Step 4 - Zaktualizuj pakiet Docker.

$ yum update docker

Step 5 - Uruchom ponownie usługę Docker i sprawdź, czy jest poprawnie uruchomiona.

$ systemctl restart docker $ journalctl -r -u docker

Step 6 - Po zakończeniu uruchom ponownie system za pomocą następujących poleceń.

$ systemctl reboot $ journalctl -r -u docker

Step 7 - Na koniec uruchom atomic-executer, aby przywrócić pakiety do listy wykluczeń yum.

$ atomic-openshift-excluder exclude

Nie ma takiego przymusu do aktualizacji polityki, wystarczy ją zaktualizować tylko wtedy, gdy jest to zalecane, co można sprawdzić za pomocą następującego polecenia.

$ oadm policy reconcile-cluster-roles

W większości przypadków nie musimy aktualizować definicji zasad.

Aktualizacja komponentów węzła

Po zakończeniu głównej aktualizacji możemy rozpocząć aktualizację węzłów. Należy pamiętać, że okres aktualizacji powinien być krótki, aby uniknąć wszelkiego rodzaju problemów w klastrze.

Step 1 - Usuń wszystkie atomowe pakiety OpenShift ze wszystkich węzłów, w których chcesz przeprowadzić aktualizację.

$ atomic-openshift-excluder unexclude

Step 2 - Następnie wyłącz planowanie węzłów przed aktualizacją.

$ oadm manage-node <node name> --schedulable = false

Step 3 - Wykonaj replikację całego węzła z bieżącego hosta na inny host.

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

Step 4 - Uaktualnij konfigurację Dockera na hoście.

$ yum update docker

Step 5 - Uruchom ponownie usługę Docker, a następnie uruchom węzeł usługi Docker.

$systemctl restart docker $ systemctl restart atomic-openshift-node

Step 6 - Sprawdź, czy oba uruchomiły się poprawnie.

$ journalctl -r -u atomic-openshift-node

Step 7 - Po zakończeniu aktualizacji uruchom ponownie komputer węzła.

$ systemctl reboot
$ journalctl -r -u docker

Step 8 - Włącz ponownie planowanie w węzłach.

$ oadm manage-node <node> --schedulable.

Step 9 - Uruchom plik wykonawczy atomic-openshift, aby pobrać pakiet OpenShift z powrotem do węzła.

$ atomic-openshift-excluder exclude

Step 10 - Na koniec sprawdź, czy wszystkie węzły są dostępne.

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

Automatyczne skalowanie to funkcja w OpenShift, w której wdrożone aplikacje mogą skalować się i zlewać w miarę potrzeb, zgodnie z określonymi specyfikacjami. W aplikacji OpenShift autoskalowanie jest również nazywane autoskalowaniem podów. Istnieją dwatypes of application scaling następująco.

Skalowanie pionowe

Skalowanie w pionie polega na dodawaniu coraz większej mocy do pojedynczej maszyny, co oznacza dodawanie większej ilości procesora i dysku twardego. Jest to stara metoda OpenShift, która nie jest teraz obsługiwana przez wersje OpenShift.

Skalowanie poziome

Ten rodzaj skalowania jest przydatny, gdy istnieje potrzeba obsługi większej liczby żądań poprzez zwiększenie liczby maszyn.

W OpenShift jest two methods to enable the scaling feature.

Korzystanie z pliku konfiguracji wdrożenia
Podczas uruchamiania obrazu

Korzystanie z pliku konfiguracji wdrażania

W tej metodzie funkcja skalowania jest włączana za pośrednictwem deploymantowego pliku konfiguracyjnego yaml. W tym celu używane jest polecenie OC autoscale z minimalną i maksymalną liczbą replik, które muszą być uruchomione w dowolnym momencie w klastrze. Potrzebujemy definicji obiektu do stworzenia autoskalera. Poniżej znajduje się przykład pliku definicji autoskalera podów.

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

Gdy mamy już plik na miejscu, musimy go zapisać w formacie yaml i uruchomić następujące polecenie w celu wdrożenia.

$ oc create –f <file name>.yaml

Podczas uruchamiania obrazu

Można również skalować automatycznie bez pliku yaml, korzystając z następującego polecenia oc autoscale polecenie w linii poleceń oc.

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

To polecenie wygeneruje również podobny rodzaj pliku, który można później wykorzystać jako odniesienie.

Strategie wdrażania w OpenShift

Strategia wdrażania w OpenShift definiuje przepływ wdrażania za pomocą różnych dostępnych metod. W OpenShift następujące plikiimportant types of deployment strategies.

Strategia krocząca
Odtwórz strategię
Strategia niestandardowa

Poniżej znajduje się przykład pliku konfiguracji wdrożenia, który jest używany głównie do wdrażania na węzłach OpenShift.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

W powyższym pliku Deploymentconfig mamy strategię Rolling.

Do wdrożenia możemy użyć następującego polecenia OC.

$ oc deploy <deployment_config> --latest

Strategia krocząca

Strategia krocząca jest używana do aktualizacji kroczących lub wdrażania. Ten proces obsługuje również punkty zaczepienia cyklu życia, które służą do wstrzykiwania kodu do dowolnego procesu wdrażania.

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

Odtwórz strategię

Ta strategia wdrażania ma kilka podstawowych cech strategii wdrażania kroczącego, a także obsługuje hak cyklu życia.

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

Strategia niestandardowa

Jest to bardzo pomocne, gdy ktoś chce zapewnić własny proces lub przepływ wdrażania. Wszystkie dostosowania można wykonać zgodnie z wymaganiami.

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

W tym rozdziale zajmiemy się takimi tematami, jak zarządzanie węzłem, konfigurowanie konta usługi itp.

Konfiguracja nadrzędna i węzłowa

W OpenShift musimy użyć polecenia start wraz z OC, aby uruchomić nowy serwer. Podczas uruchamiania nowego mastera musimy użyć mastera wraz z poleceniem start, natomiast podczas uruchamiania nowego węzła musimy użyć node wraz z poleceniem start. Aby to zrobić, musimy utworzyć pliki konfiguracyjne zarówno dla mastera, jak i dla węzłów. Możemy utworzyć podstawowy plik konfiguracyjny dla mastera i węzła za pomocą następującego polecenia.

Dla głównego pliku konfiguracyjnego

$ openshift start master --write-config = /openshift.local.config/master

Plik konfiguracyjny węzła

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

Po uruchomieniu następujących poleceń otrzymamy podstawowe pliki konfiguracyjne, których można użyć jako punktu wyjścia do konfiguracji. Później możemy mieć ten sam plik do uruchamiania nowych serwerów.

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

Pliki konfiguracyjne węzła

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

Tak wyglądają pliki konfiguracyjne węzła. Gdy mamy już te pliki konfiguracyjne, możemy uruchomić następujące polecenie, aby utworzyć serwer główny i węzłowy.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Zarządzanie węzłami

W OpenShift mamy narzędzie wiersza poleceń OC, które jest najczęściej używane do wykonywania wszystkich operacji w OpenShift. Do zarządzania węzłami możemy użyć następujących poleceń.

Aby wyświetlić węzeł

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

Opisywanie szczegółów dotyczących węzła

$ oc describe node <node name>

Usuwanie węzła

$ oc delete node <node name>

Wyświetlanie podów w węźle

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Ocenianie podów w węźle

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Uwierzytelnianie konfiguracji

W OpenShift master jest wbudowany serwer OAuth, który może służyć do zarządzania uwierzytelnianiem. Wszyscy użytkownicy OpenShift otrzymują token z tego serwera, który pomaga im komunikować się z OpenShift API.

W OpenShift istnieją różne rodzaje poziomów uwierzytelniania, które można skonfigurować wraz z głównym plikiem konfiguracyjnym.

Pozwól wszystkim
Zaprzeczać wszystkiemu
HTPasswd
LDAP
Uwierzytelnianie podstawowe
Nagłówek żądania

Definiując konfigurację główną, możemy zdefiniować politykę identyfikacji, w której możemy zdefiniować typ polityki, której chcemy używać.

Pozwól wszystkim

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Zaprzeczać wszystkiemu

Spowoduje to odmowę dostępu do wszystkich nazw użytkowników i haseł.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd służy do sprawdzania nazwy użytkownika i hasła w odniesieniu do zaszyfrowanego hasła do pliku.

Aby wygenerować zaszyfrowany plik, wykonaj następujące polecenie.

$ htpasswd </path/to/users.htpasswd> <user_name>

Korzystanie z zaszyfrowanego pliku.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

Dostawca tożsamości LDAP

Służy do uwierzytelniania LDAP, w którym serwer LDAP odgrywa kluczową rolę w uwierzytelnianiu.

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

Uwierzytelnianie podstawowe

Jest to używane, gdy weryfikacja nazwy użytkownika i hasła jest wykonywana w odniesieniu do uwierzytelniania między serwerami. Uwierzytelnienie jest chronione w podstawowym adresie URL i jest prezentowane w formacie JSON.

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

Konfiguracja konta usługi

Konta usług zapewniają elastyczny sposób uzyskiwania dostępu do OpenShift API, ujawniając nazwę użytkownika i hasło w celu uwierzytelnienia.

Włączanie konta usługi

Konto usługi używa pary kluczy publicznego i prywatnego do uwierzytelniania. Uwierzytelnianie w interfejsie API odbywa się za pomocą klucza prywatnego i weryfikuje go z kluczem publicznym.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

Tworzenie konta usługi

Użyj następującego polecenia, aby utworzyć konto usługi

$ Openshift cli create service account <name of server account>

Praca z proxy HTTP

W większości środowisk produkcyjnych bezpośredni dostęp do Internetu jest ograniczony. Nie są one ujawniane w Internecie lub przez serwer proxy HTTP lub HTTPS. W środowisku OpenShift ta definicja maszyny proxy jest ustawiana jako zmienna środowiskowa.

Można to zrobić, dodając definicję proxy do plików głównych i węzłów znajdujących się w /etc/sysconfig. Jest to podobne, jak w przypadku każdej innej aplikacji.

Mistrzowska maszyna

/ etc / sysconfig / openshift-master

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Maszyna węzłowa

/ etc / sysconfig / openshift-node

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Po zakończeniu musimy zrestartować maszyny główne i węzłowe.

Dla Docker Pull

/ etc / sysconfig / docker

HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com

Aby uruchomić kapsułę w środowisku proxy, można to zrobić za pomocą -

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

Polecenie OC environment może być użyte do zaktualizowania istniejącego env.

Pamięć OpenShift z NFS

W OpenShift koncepcja trwałego woluminu i trwałego oświadczenia woluminu tworzy trwały magazyn. Jest to jedna z kluczowych koncepcji, w której tworzony jest pierwszy trwały wolumin, a później ten sam wolumin jest zajmowany. W tym celu musimy mieć wystarczającą pojemność i miejsce na dysku na podstawowym sprzęcie.

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

Następnie za pomocą polecenia OC create utwórz trwały wolumin.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Odbieranie utworzonego wolumenu.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

Utwórz roszczenie.

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Zarządzanie użytkownikami i rolami

Administracja użytkownikami i rolami służy do zarządzania użytkownikami, ich dostępem i kontrolą w różnych projektach.

Tworzenie użytkownika

Do tworzenia nowych użytkowników w OpenShift można użyć predefiniowanych szablonów.

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}" - kind: "Identity" apiVersion: "v1" metadata: name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}" - kind: "UserIdentityMapping" apiVersion: "v1" identity: name: "vipin:${email}"
user:
   name: "${email}"

Użyj oc create –f <nazwa pliku>, aby utworzyć użytkowników.

$ oc create –f vipin.yaml

Użyj następującego polecenia, aby usunąć użytkownika w OpenShift.

$ oc delete user <user name>

Ograniczanie dostępu użytkowników

ResourceQuotas i LimitRanges służą do ograniczania poziomów dostępu użytkowników. Służą do ograniczania zasobników i kontenerów w klastrze.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Tworzenie oferty przy użyciu powyższej konfiguracji

$ oc create -f resource-quota.yaml –n –Openshift-sample

Opisywanie oferty zasobów

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

Definiowanie limitów kontenerów może posłużyć do ograniczenia zasobów, które będą używane przez wdrożone kontenery. Służą do definiowania maksymalnych i minimalnych ograniczeń niektórych obiektów.

Ograniczenia projektu użytkownika

Jest to zasadniczo używane do liczby projektów, które użytkownik może mieć w dowolnym momencie. Zasadniczo odbywa się to poprzez zdefiniowanie poziomów użytkowników w kategoriach brązu, srebra i złota.

Najpierw musimy zdefiniować obiekt, który ma wartość tego, ile projektów może mieć kategoria brązowa, srebrna i złota. Należy to zrobić w pliku master-confif.yaml.

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

Zrestartuj serwer główny.

Przypisanie użytkownika do określonego poziomu.

$ oc label user vipin level = gold

W razie potrzeby przeniesienie użytkownika z etykiety.

$ oc label user <user_name> level-

Dodawanie ról do użytkownika.

$ oadm policy add-role-to-user 
      
        <user_name>

Usunięcie roli użytkownika.

$ oadm policy remove-role-from-user 
      
        <user_name>

Dodanie roli klastra do użytkownika.

$ oadm policy add-cluster-role-to-user 
      
        <user_name>

Usuwanie roli klastra od użytkownika.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name>

Dodawanie roli do grupy.

$ oadm policy add-role-to-user 
      
        <user_name>

Usuwanie roli z grupy.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name>

Dodawanie roli klastra do grupy.

$ oadm policy add-cluster-role-to-group 
      
        <groupname>

Usuwanie roli klastra z grupy.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Użytkownik do administrowania klastrem

Jest to jedna z najpotężniejszych ról, w której użytkownik ma możliwość zarządzania całym klastrem, począwszy od jego utworzenia aż do jego usunięcia.

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

Użytkownik z najwyższą mocą

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

OpenShift jest oparty na platformach Docker i Kubernetes. Wszystkie kontenery są zbudowane na klastrze Docker, który jest w zasadzie usługą Kubernetes na komputerach z systemem Linux, przy użyciu funkcji orkiestracji Kubernetes.

W tym procesie budujemy Kubernetes master, który kontroluje wszystkie węzły i wdraża kontenery we wszystkich węzłach. Główną funkcją Kubernetes jest sterowanie klastrem OpenShift i przepływem wdrażania przy użyciu innego rodzaju pliku konfiguracyjnego. Podobnie jak w Kubernetes, używamy kubctl w taki sam sposób, w jaki używamy narzędzia wiersza poleceń OC do budowania i wdrażania kontenerów w węzłach klastra.

Poniżej przedstawiono różne rodzaje plików konfiguracyjnych używanych do tworzenia różnego rodzaju obiektów w klastrze.

Images
POD
Service
Kontroler replikacji
Zestaw replik
Deployment

Obrazy

Obrazy Kubernetes (Docker) są kluczowymi elementami składowymi infrastruktury kontenerowej. Obecnie Kubernetes obsługuje tylko plikiDockerobrazy. Każdy kontener w kapsule ma w sobie uruchomiony obraz Dockera.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

STRĄK

Pod to kolekcja kontenerów i ich magazynu wewnątrz węzła klastra Kubernetes. Możliwe jest utworzenie kapsuły z wieloma kontenerami w środku. Poniżej znajduje się przykład przechowywania kontenera bazy danych i kontenera interfejsu internetowego w tym samym pod.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
      image: tomcat: 8.0
      ports:
- containerPort: 7500
imagePullPolicy: Always

Usługa

Usługę można zdefiniować jako logiczny zestaw zasobników. Można go zdefiniować jako abstrakcję na szczycie kapsuły, która zapewnia pojedynczy adres IP i nazwę DNS, za pomocą której można uzyskać dostęp do zasobników. Dzięki usłudze bardzo łatwo jest zarządzać konfiguracją równoważenia obciążenia. Ułatwia skalowanie POD-ów.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
      targetPort: 31999

Kontroler replikacji

Kontroler replikacji to jedna z kluczowych funkcji Kubernetes, która jest odpowiedzialna za zarządzanie cyklem życia poda. Jest odpowiedzialny za upewnienie się, że określona liczba replik pod jest uruchomiona w dowolnym momencie.

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Zestaw replik

Zestaw replik zapewnia, ile replik ma być uruchomionych. Można to traktować jako zamiennik kontrolera replikacji.

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

Rozlokowanie

Wdrożenia to uaktualnione i wyższe wersje kontrolera replikacji. Zarządzają wdrażaniem zestawów replik, które są również ulepszoną wersją kontrolera replikacji. Mają możliwość aktualizowania zestawu replik, a także przywracania poprzedniej wersji.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

Wszystkie pliki konfiguracyjne mogą służyć do tworzenia odpowiednich obiektów Kubernetes.

$ Kubectl create –f <file name>.yaml

Poniższych poleceń można użyć, aby poznać szczegóły i opis obiektów Kubernetes.

For POD

$ Kubectl get pod <pod name> $ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

For Replication Controller

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name> $ kubectl describe rc <rc name>

For Service

$ Kubectl get svc <svc name> $ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

Aby uzyskać więcej informacji na temat pracy z Dockerem i Kubernetesem, odwiedź nasz samouczek Kubernetes, korzystając z następującego łącza kubernetes .

Bezpieczeństwo OpenShift to głównie połączenie dwóch komponentów, które głównie obsługują ograniczenia bezpieczeństwa.

Ograniczenia kontekstu bezpieczeństwa (SCC)
Konto usługi

Ograniczenia kontekstu bezpieczeństwa (SCC)

Zasadniczo jest używany do ograniczenia kapsuły, co oznacza, że definiuje ograniczenia dla kapsuły, takie jak czynności, które może wykonywać i do czego ma dostęp w klastrze.

OpenShift zapewnia zestaw predefiniowanych SCC, które mogą być używane, modyfikowane i rozszerzane przez administratora.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Jeśli ktoś chce użyć dowolnego wstępnie zdefiniowanego scc, można to zrobić po prostu dodając użytkownika lub grupę do grupy scc.

$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>

Konto usługi

Konta usług są zasadniczo używane do kontrolowania dostępu do głównego interfejsu API OpenShift, który jest wywoływany, gdy polecenie lub żądanie jest uruchamiane z dowolnej maszyny głównej lub węzła.

Za każdym razem, gdy aplikacja lub proces wymaga możliwości, która nie jest przyznawana przez ograniczony SCC, będziesz musiał utworzyć określone konto usługi i dodać je do odpowiedniego SCC. Jeśli jednak SCC nie spełnia twoich wymagań, lepiej jest utworzyć nowy SCC specyficzny dla twoich wymagań, niż używać tego, który jest najlepiej dopasowany. Na koniec ustaw go dla konfiguracji wdrożenia.

$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin

Bezpieczeństwo kontenerów

W OpenShift bezpieczeństwo kontenerów opiera się na koncepcji tego, jak bezpieczna jest platforma kontenerowa i gdzie są uruchomione kontenery. Jest wiele rzeczy, które pojawiają się, kiedy mówimy o bezpieczeństwie kontenerów io tym, czym należy się zająć.

Image Provenance - Wdrożono bezpieczny system etykietowania, który dokładnie i w sposób niepodważalny identyfikuje, skąd pochodzą pojemniki używane w środowisku produkcyjnym.

Security Scanning - Skaner obrazów automatycznie sprawdza wszystkie obrazy pod kątem znanych luk w zabezpieczeniach.

Auditing - Środowisko produkcyjne jest regularnie kontrolowane, aby upewnić się, że wszystkie kontenery są oparte na aktualnych kontenerach, a hosty i kontenery są bezpiecznie skonfigurowane.

Isolation and Least Privilege- Kontenery działają przy minimalnych zasobach i uprawnieniach potrzebnych do skutecznego działania. Nie są w stanie nadmiernie ingerować w hosta lub inne pojemniki.

Runtime Threat Detection - Funkcja, która wykrywa aktywne zagrożenia dla aplikacji w kontenerach w czasie wykonywania i automatycznie na nie reaguje.

Access Controls - Moduły bezpieczeństwa Linuksa, takie jak AppArmor lub SELinux, służą do egzekwowania kontroli dostępu.

Istnieje kilka kluczowych metod archiwizowania zabezpieczeń kontenerów.

Kontrolowanie dostępu przez OAuth
Za pomocą samoobsługowej konsoli internetowej
Certyfikaty platformy

Kontrolowanie dostępu przez OAuth

W tej metodzie uwierzytelnianie do kontroli dostępu do API jest archiwizowane, uzyskując bezpieczny token do uwierzytelniania za pośrednictwem serwerów OAuth, który jest wbudowany w maszynę główną OpenShift. Jako administrator masz możliwość modyfikowania konfiguracji serwera OAuth.

Więcej informacji na temat konfiguracji serwera OAuth można znaleźć w rozdziale 5 tego samouczka.

Za pośrednictwem samoobsługowej konsoli internetowej

Ta funkcja bezpieczeństwa konsoli internetowej jest wbudowana w konsolę internetową OpenShift. Ta konsola zapewnia, że wszystkie współpracujące ze sobą zespoły nie mają dostępu do innych środowisk bez uwierzytelnienia. Master multi-telnet w OpenShift ma następujące funkcje bezpieczeństwa -

Warstwa TCL jest włączona
Używa certyfikatu x.509 do uwierzytelniania
Zabezpiecza konfigurację etcd na maszynie głównej

Za pomocą certyfikatów platformy

W tej metodzie certyfikaty dla każdego hosta są konfigurowane podczas instalacji za pośrednictwem Ansible. Ponieważ wykorzystuje protokół komunikacyjny HTTPS poprzez Rest API, potrzebujemy bezpiecznego połączenia TCL z różnymi komponentami i obiektami. Są to wstępnie zdefiniowane certyfikaty, ale można nawet mieć niestandardowy certyfikat zainstalowany w klastrze master w celu uzyskania dostępu. Podczas początkowej konfiguracji certyfikatu głównego można skonfigurować niestandardowe certyfikaty, zastępując istniejące certyfikaty za pomocąopenshift_master_overwrite_named_certificates parametr.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Aby uzyskać więcej informacji na temat generowania certyfikatów niestandardowych, odwiedź poniższy link -

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

Bezpieczeństwo sieci

W OpenShift do komunikacji używana jest sieć definiowana programowo (SDN). Sieciowa przestrzeń nazw jest używana dla każdego poda w klastrze, przy czym każdy pod otrzymuje własny adres IP i zakres portów, aby uzyskać na nim ruch sieciowy. W ten sposób można izolować strąki, z powodu których nie może się komunikować z zasobnikami w innym projekcie.

Izolowanie projektu

Może to zrobić administrator klastra, korzystając z następującego polecenia oadm command z CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Oznacza to, że projekty zdefiniowane powyżej nie mogą komunikować się z innymi projektami w klastrze.

Bezpieczeństwo wolumenu

Bezpieczeństwo wolumenu wyraźnie oznacza zabezpieczenie PV i PVC projektów w klastrze OpenShift. Istnieją głównie cztery sekcje kontrolujące dostęp do woluminów w OpenShift.

Grupy dodatkowe
fsGroup
runAsUser
seLinuxOptions

Grupy dodatkowe - grupy dodatkowe to zwykłe grupy systemu Linux. Gdy proces działa w systemie, działa z identyfikatorem użytkownika i identyfikatorem grupy. Te grupy służą do kontrolowania dostępu do pamięci współużytkowanej.

Sprawdź podłączenie NFS za pomocą następującego polecenia.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Sprawdź szczegóły NFS na serwerze montowania, używając następującego polecenia.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

Plik / opt / nfs / export jest dostępny przez UID454265 i grupę 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup oznacza grupę systemu plików, która jest używana do dodawania dodatkowych grup kontenerów. Identyfikator grupy suplementów jest używany do przechowywania współdzielonego, a fsGroup jest używany do przechowywania blokowego.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser używa identyfikatora użytkownika do komunikacji. Służy do definiowania obrazu kontenera w definicji poda. W razie potrzeby we wszystkich kontenerach można użyć jednego identyfikatora użytkownika.

Podczas uruchamiania kontenera zdefiniowany identyfikator jest dopasowywany do identyfikatora właściciela podczas eksportu. Jeśli określony identyfikator jest zdefiniowany na zewnątrz, staje się globalny dla wszystkich kontenerów w pod. Jeśli jest zdefiniowany z określonym kapsułą, staje się specyficzny dla pojedynczego kontenera.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265