Thank you for reading this post, don't forget to subscribe!

1.обзор
2.типы
3.архитектура
4.настройка сре­ды
5.основная кон­цеп­ция
6.начало рабо­ты
7.автоматизация сбор­ки
8.интерфейс команд­ной строки
9.операции через интер­фейс команд­ной строки
10.Кластеры
11.масштабирование при­ло­же­ний
12.администрирование
13.безопасность

OpenShift - это плат­фор­ма облач­ной раз­ра­бот­ки как услу­га (PaaS), раз­ра­бо­тан­ная Red Hat. Это плат­фор­ма раз­ра­бот­ки с откры­тым исход­ным кодом, кото­рая поз­во­ля­ет раз­ра­бот­чи­кам раз­ра­ба­ты­вать и раз­вер­ты­вать свои при­ло­же­ния в облач­ной инфра­струк­ту­ре. Это очень полез­но при раз­ра­бот­ке облач­ных сер­ви­сов. Это руко­вод­ство помо­жет вам понять OpenShift и то, как его мож­но исполь­зо­вать в суще­ству­ю­щей инфра­струк­ту­ре. Все при­ме­ры и фраг­мен­ты кода, исполь­зу­е­мые в этом руко­вод­стве, явля­ют­ся про­те­сти­ро­ван­ным и рабо­чим кодом, кото­рый мож­но про­сто исполь­зо­вать в любой настрой­ке OpenShift, изме­нив теку­щие опре­де­лен­ные име­на и переменные.

Виртуализация

В общем, вир­ту­а­ли­за­цию мож­но опре­де­лить как созда­ние вир­ту­аль­ной систе­мы, а не физи­че­ской или фак­ти­че­ской вер­сии чего-либо, начи­ная с систе­мы, хра­ни­ли­ща или опе­ра­ци­он­ной систе­мы. Основ­ная цель вир­ту­а­ли­за­ции - сде­лать ИТ-инфра­струк­ту­ру более мас­шта­би­ру­е­мой и надеж­ной. Кон­цеп­ция вир­ту­а­ли­за­ции суще­ству­ет на про­тя­же­нии деся­ти­ле­тий, и с раз­ви­ти­ем ИТ-инду­стрии сего­дня ее мож­но при­ме­нять к широ­ко­му спек­тру уров­ней, начи­ная от уров­ня систе­мы, уров­ня обо­ру­до­ва­ния и закан­чи­вая вир­ту­а­ли­за­ци­ей на уровне сервера.

Как это устроено

Его мож­но опи­сать как тех­но­ло­гию, в кото­рой любое при­ло­же­ние или опе­ра­ци­он­ная систе­ма абстра­ги­ру­ют­ся от сво­е­го реаль­но­го физи­че­ско­го уров­ня. Одним из клю­че­вых при­ме­не­ний тех­но­ло­гии вир­ту­а­ли­за­ции явля­ет­ся вир­ту­а­ли­за­ция сер­ве­ров, кото­рая исполь­зу­ет про­грамм­ное обес­пе­че­ние, назы­ва­е­мое гипер­ви­зо­ром, для абстра­ги­ро­ва­ния уров­ня от базо­во­го обо­ру­до­ва­ния. Про­из­во­ди­тель­ность опе­ра­ци­он­ной систе­мы, рабо­та­ю­щей в режи­ме вир­ту­а­ли­за­ции, такая же, как и при рабо­те на физи­че­ском обо­ру­до­ва­нии. Одна­ко кон­цеп­ция вир­ту­а­ли­за­ции попу­ляр­на, так как боль­шая часть рабо­та­ю­щих систем и при­ло­же­ний не тре­бу­ет исполь­зо­ва­ния базо­во­го оборудования.

Физическая и виртуальная архитектура

Типы виртуализации

• Application Virtualization- В этом мето­де при­ло­же­ние абстра­ги­ру­ет­ся от базо­вой опе­ра­ци­он­ной систе­мы. Этот метод очень поле­зен, когда при­ло­же­ние может рабо­тать изо­ли­ро­ван­но, не зави­си­мо от опе­ра­ци­он­ной системы.
• Desktop Virtualization- Этот метод исполь­зу­ет­ся для умень­ше­ния нагруз­ки на рабо­чую стан­цию, когда мож­но полу­чить уда­лен­ный доступ к рабо­че­му сто­лу с помо­щью тон­ко­го кли­ен­та на рабо­чем сто­ле. В этом мето­де рабо­чие сто­лы в основ­ном рабо­та­ют в цен­тре обра­бот­ки дан­ных. Клас­си­че­ским при­ме­ром может слу­жить образ вир­ту­аль­но­го рабо­че­го сто­ла (VDI), кото­рый исполь­зу­ет­ся в боль­шин­стве организаций.
• Data Virtualization - Это метод абстра­ги­ро­ва­ния и ухо­да от тра­ди­ци­он­но­го мето­да управ­ле­ния данными.
• Server Virtualization- В этом мето­де вир­ту­а­ли­зи­ру­ют­ся ресур­сы, свя­зан­ные с сер­ве­ром, вклю­чая физи­че­ский сер­вер, про­цесс и опе­ра­ци­он­ную систе­му. Про­грамм­ное обес­пе­че­ние, обес­пе­чи­ва­ю­щее эту абстрак­цию, часто назы­ва­ют гипервизором.
• Storage Virtualization - Это про­цесс объ­еди­не­ния несколь­ких запо­ми­на­ю­щих устройств в одно запо­ми­на­ю­щее устрой­ство, кото­рым управ­ля­ют с еди­ной цен­траль­ной консоли.
• Network Virtualization - Это метод, при кото­ром все доступ­ные сете­вые ресур­сы объ­еди­ня­ют­ся путем раз­де­ле­ния доступ­ной поло­сы про­пус­ка­ния и кана­лов, каж­дый из кото­рых не зави­сит друг от друга.

OpenShift

OpenShift - это облач­ная плат­фор­ма при­ло­же­ний как услу­га (PaaS). Это тех­но­ло­гия с откры­тым исход­ным кодом, кото­рая помо­га­ет орга­ни­за­ци­ям пере­но­сить свою тра­ди­ци­он­ную инфра­струк­ту­ру при­ло­же­ний и плат­фор­му с физи­че­ских вир­ту­аль­ных сред в облако.

OpenShift под­дер­жи­ва­ет очень широ­кий спектр при­ло­же­ний, кото­рые мож­но лег­ко раз­ра­бо­тать и раз­вер­нуть на облач­ной плат­фор­ме OpenShift. OpenShift в основ­ном под­дер­жи­ва­ет три типа плат­форм для раз­ра­бот­чи­ков и пользователей.

Инфраструктура как услуга (IaaS)

В этом фор­ма­те постав­щик услуг предо­став­ля­ет вир­ту­аль­ным маши­нам аппа­рат­но­го уров­ня неко­то­рую пред­опре­де­лен­ную кон­фи­гу­ра­цию вир­ту­аль­но­го обо­ру­до­ва­ния. В этом про­стран­стве есть несколь­ко кон­ку­рен­тов, начи­ная с обла­ка AWS, Google, Rackspace и мно­гих других.

Глав­ный недо­ста­ток IaaS после дли­тель­ной про­це­ду­ры настрой­ки и инве­сти­ций заклю­ча­ет­ся в том, что каж­дый по-преж­не­му несет ответ­ствен­ность за уста­нов­ку и обслу­жи­ва­ние опе­ра­ци­он­ной систе­мы и паке­тов сер­ве­ров, управ­ле­ние сетью инфра­струк­ту­ры и забо­ту об основ­ном систем­ном администрировании.

Программное обеспечение как услуга (SaaS)

С SaaS мож­но мень­ше все­го бес­по­ко­ить­ся о базо­вой инфра­струк­ту­ре. Это так же про­сто, как под­клю­чи и рабо­тай, когда поль­зо­ва­те­лю про­сто нуж­но под­пи­сать­ся на услу­ги и начать их исполь­зо­вать. Основ­ным недо­стат­ком такой настрой­ки явля­ет­ся то, что мож­но выпол­нить толь­ко мини­маль­ный объ­ем настрой­ки, раз­ре­шен­ный постав­щи­ком услуг. Одним из наи­бо­лее рас­про­стра­нен­ных при­ме­ров SaaS явля­ет­ся Gmail, где поль­зо­ва­те­лю про­сто нуж­но вой­ти в систе­му и начать его исполь­зо­вать. Поль­зо­ва­тель так­же может вне­сти неболь­шие изме­не­ния в свою учет­ную запись. Одна­ко с точ­ки зре­ния раз­ра­бот­чи­ка это не очень полезно.

Платформа как услуга (PaaS)

Его мож­но рас­смат­ри­вать как про­ме­жу­точ­ный уро­вень меж­ду SaaS и IaaS. Основ­ная цель оцен­ки PaaS - для раз­ра­бот­чи­ков, в кото­рых сре­да раз­ра­бот­ки может быть раз­вер­ну­та с помо­щью несколь­ких команд. Эти сре­ды спро­ек­ти­ро­ва­ны таким обра­зом, что могут удо­вле­тво­рить все потреб­но­сти раз­ра­бот­ки, пря­мо от нали­чия сер­ве­ра веб-при­ло­же­ний с базой дан­ных. Для это­го вам потре­бу­ет­ся все­го лишь одна коман­да, и постав­щик услуг сде­ла­ет все за вас.

Зачем использовать OpenShift?

OpenShift предо­став­ля­ет кор­по­ра­тив­ным под­раз­де­ле­ни­ям общую плат­фор­му для раз­ме­ще­ния сво­их при­ло­же­ний в обла­ке, не бес­по­ко­ясь о базо­вой опе­ра­ци­он­ной систе­ме. Это упро­ща­ет исполь­зо­ва­ние, раз­ра­бот­ку и раз­вер­ты­ва­ние при­ло­же­ний в обла­ке. Одна из клю­че­вых осо­бен­но­стей - это предо­став­ле­ние управ­ля­е­мо­го обо­ру­до­ва­ния и сете­вых ресур­сов для всех видов раз­ра­бот­ки и тести­ро­ва­ния. С OpenShift раз­ра­бот­чик PaaS может сво­бод­но раз­ра­ба­ты­вать необ­хо­ди­мую сре­ду со спецификациями.

OpenShift предо­став­ля­ет раз­лич­ные виды согла­ше­ний об уровне обслу­жи­ва­ния, когда речь идет о пла­нах обслуживания.

Free - Этот план огра­ни­чен тре­мя года­ми с 1 ГБ места на каждый.

Bronze - Этот план вклю­ча­ет 3 года и рас­ши­ря­ет­ся до 16 лет с 1 ГБ про­стран­ства в год.

Sliver - Это брон­зо­вый план на 16 лет, одна­ко он име­ет емкость 6 ГБ без допол­ни­тель­ных затрат.

Поми­мо пере­чис­лен­ных выше функ­ций, OpenShift так­же пред­ла­га­ет локаль­ную вер­сию, извест­ную как OpenShift Enterprise. В OpenShift раз­ра­бот­чи­ки могут созда­вать мас­шта­би­ру­е­мые и немас­шта­би­ру­е­мые при­ло­же­ния, и эти про­ек­ты реа­ли­зу­ют­ся с исполь­зо­ва­ни­ем сер­ве­ров HAproxy.

Особенности

OpenShift под­дер­жи­ва­ет несколь­ко функ­ций. Немно­гие из них -

• Под­держ­ка несколь­ких языков
• Под­держ­ка несколь­ких баз данных
• Систе­ма рас­ши­ря­е­мых картриджей
• Управ­ле­ние вер­си­я­ми исход­но­го кода
• Раз­вер­ты­ва­ние в один клик
• Под­держ­ка несколь­ких сред
• Стан­дарт­ный рабо­чий про­цесс разработчиков
• Управ­ле­ние зави­си­мо­стя­ми и сборкой
• Авто­ма­ти­че­ское мас­шта­би­ро­ва­ние приложений
• Адап­тив­ная веб-консоль
• Бога­тый набор инстру­мен­тов команд­ной строки
• Уда­лен­ный вход в при­ло­же­ния по SSH
• Под­держ­ка Rest API
• Стек при­ло­же­ний само­об­слу­жи­ва­ния по запросу
• Встро­ен­ные служ­бы баз данных
• Непре­рыв­ная инте­гра­ция и управ­ле­ние выпусками
• Инте­гра­ция IDE
• Уда­лен­ная отлад­ка приложений

OpenShift - Типы

Step 2 - Если у вас есть учет­ная запись Red Hat, вой­ди­те в учет­ную запись OpenShift, исполь­зуя иден­ти­фи­ка­тор и пароль для вхо­да в Red Hat, исполь­зуя сле­ду­ю­щий URL-адрес. https://developers.redhat.com

Step 3 - Если у вас нет учет­ной запи­си Red Hat, заре­ги­стри­руй­тесь в онлайн-сер­ви­се OpenShift, исполь­зуя сле­ду­ю­щую ссылку.

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

После вхо­да вы уви­ди­те сле­ду­ю­щую страницу.

Когда все будет гото­во, Red Hat пока­жет неко­то­рые основ­ные све­де­ния об учет­ной запи­си, как пока­за­но на сле­ду­ю­щем сним­ке экрана.

Нако­нец, когда вы вой­де­те в систе­му, вы уви­ди­те сле­ду­ю­щую страницу.

Контейнерная платформа OpenShift

Кон­тей­нер­ная плат­фор­ма OpenShift - это кор­по­ра­тив­ная плат­фор­ма, кото­рая помо­га­ет несколь­ким груп­пам, таким как груп­па раз­ра­бот­чи­ков и ИТ-спе­ци­а­ли­стов, созда­вать и раз­вер­ты­вать кон­тей­нер­ную инфра­струк­ту­ру. Все кон­тей­не­ры, создан­ные в OpenShift, исполь­зу­ют очень надеж­ную тех­но­ло­гию кон­тей­не­ри­за­ции Docker, кото­рую мож­но раз­вер­нуть в любом цен­тре обра­бот­ки дан­ных на пуб­лич­но раз­ме­щен­ных облач­ных платформах.

Кон­тей­нер­ная плат­фор­ма OpenShift фор­маль­но была извест­на как OpenShift Enterprises. Это локаль­ная част­ная плат­фор­ма в каче­стве служ­бы Red Hat, постро­ен­ная на осно­ве базо­вой кон­цеп­ции кон­тей­не­ров при­ло­же­ний на базе Docker, где оркест­ров­ка и адми­ни­стри­ро­ва­ние управ­ля­ют­ся Kubernetes.

Дру­ги­ми сло­ва­ми, OpenShift объ­еди­ня­ет Docker и Kubernetes на кор­по­ра­тив­ном уровне. Это про­грамм­ное обес­пе­че­ние кон­тей­нер­ной плат­фор­мы для кор­по­ра­тив­ных под­раз­де­ле­ний, поз­во­ля­ю­щее раз­вер­ты­вать кан­ди­да­тов и управ­лять ими в инфра­струк­ту­ре по сво­е­му выбо­ру. Напри­мер, раз­ме­ще­ние экзем­пля­ров OpenShift на экзем­пля­рах AWS.

Кон­тей­нер­ная плат­фор­ма OpenShift доступ­на в two package levels.

OpenShift Container Local- Это для тех раз­ра­бот­чи­ков, кото­рые хотят раз­вер­ты­вать и тести­ро­вать при­ло­же­ния на локаль­ной машине. Этот пакет в основ­ном исполь­зу­ет­ся коман­да­ми раз­ра­бот­чи­ков для раз­ра­бот­ки и тести­ро­ва­ния приложений.

OpenShift Container Lab - Это пред­на­зна­че­но для рас­ши­рен­ной оцен­ки при­ло­же­ния от раз­ра­бот­ки до раз­вер­ты­ва­ния в сре­де pre-prod.

Выделенный OpenShift

Это еще одно пред­ло­же­ние, добав­лен­ное к порт­фе­лю OpenShift, в кото­ром заказ­чик может раз­ме­стить кон­тей­нер­ную плат­фор­му в любом пуб­лич­ном обла­ке по сво­е­му выбо­ру. Это дает конеч­но­му поль­зо­ва­те­лю истин­ное пред­став­ле­ние о муль­ти­об­лач­ном пред­ло­же­нии, когда он может исполь­зо­вать OpenShift в любом обла­ке, кото­рое удо­вле­тво­ря­ет их потребности.

Это одно из новей­ших пред­ло­же­ний Red Hat, в кото­ром конеч­ный поль­зо­ва­тель может исполь­зо­вать OpenShift для созда­ния тесто­во­го раз­вер­ты­ва­ния и запус­ка сво­е­го при­ло­же­ния на OpenShift, кото­рый раз­ме­щен в облаке.

Особенности OpenShift Dedicated

OpenShift пред­ла­га­ет плат­фор­му при­ло­же­ний для настра­и­ва­е­мых реше­ний в обще­до­ступ­ном обла­ке, уна­сле­до­ван­ную от тех­но­ло­гии OpenShift 3.

• Extensible and Open - Он постро­ен на откры­той кон­цеп­ции Docker и раз­вер­нут в обла­ке, поэто­му он может рас­хо­до­вать себя по мере необходимости.
• Portability - Посколь­ку он постро­ен с исполь­зо­ва­ни­ем Docker, при­ло­же­ния, рабо­та­ю­щие на Docker, мож­но лег­ко доста­вить из одно­го места в дру­гое, где Docker поддерживается.
• Orchestration - В OpenShift 3 одна из клю­че­вых функ­ций оркест­ров­ки кон­тей­не­ров и управ­ле­ния кла­сте­ром под­дер­жи­ва­ет­ся с помо­щью Kubernetes, кото­рый появил­ся в OpenShift вер­сии 3.
• Automation - Эта вер­сия OpenShift под­дер­жи­ва­ет функ­цию управ­ле­ния исход­ным кодом, авто­ма­ти­за­ции сбор­ки и раз­вер­ты­ва­ния, что дела­ет ее очень попу­ляр­ной на рын­ке в каче­стве плат­фор­мы как постав­щи­ка услуг.

Конкуренты OpenShift

Google App Engine- Это бес­плат­ная плат­фор­ма Google для раз­ра­бот­ки и раз­ме­ще­ния веб-при­ло­же­ний. Дви­жок при­ло­же­ний Google пред­ла­га­ет плат­фор­му для быст­рой раз­ра­бот­ки и развертывания.

Microsoft Azure - Обла­ко Azure раз­ме­ще­но Microsoft в их цен­трах обра­бот­ки данных.

Amazon Elastic Cloud Compute - Это встро­ен­ные сер­ви­сы, предо­став­ля­е­мые Amazon, кото­рые помо­га­ют в раз­ра­бот­ке и раз­ме­ще­нии мас­шта­би­ру­е­мых веб-при­ло­же­ний в облаке.

Cloud Foundry - это плат­фор­ма PaaS с откры­тым исход­ным кодом для при­ло­же­ний Java, Ruby, Python и Node.js.

CloudStack - CloudStack от Apache - это про­ект, раз­ра­бо­тан­ный Citrix и при­зван­ный стать пря­мым кон­ку­рен­том OpenShift и OpenStack.

OpenStack - Еще одна облач­ная тех­но­ло­гия, предо­став­ля­е­мая Red Hat для облач­ных вычислений.

Kubernetes - Это тех­но­ло­гия пря­мой оркест­ра­ции и управ­ле­ния кла­сте­ром, создан­ная для управ­ле­ния кон­тей­не­ром Docker.

 

OpenShift - Архитектура

 

OpenShift - Настройка среды

В этой гла­ве мы узна­ем о настрой­ке сре­ды OpenShift.

Системные требования

Что­бы настро­ить кор­по­ра­тив­ный OpenShift, необ­хо­ди­мо иметь актив­ную учет­ную запись Red Hat. Посколь­ку OpenShift рабо­та­ет на архи­тек­ту­ре масте­ра и узла Kubernetes, нам необ­хо­ди­мо настро­ить их обо­их на отдель­ных маши­нах, где одна маши­на дей­ству­ет как мастер, а дру­гая рабо­та­ет на узле. Для уста­нов­ки обо­их суще­ству­ют мини­маль­ные систем­ные требования.

Конфигурация главной машины

Ниже при­ве­де­ны мини­маль­ные систем­ные тре­бо­ва­ния для кон­фи­гу­ра­ции глав­ной машины.

• Базо­вая маши­на, раз­ме­щен­ная в физи­че­ской, вир­ту­аль­ной или любой облач­ной среде.
• По край­ней мере, Linux 7 с необ­хо­ди­мы­ми паке­та­ми на этом экземпляре.
• 2 ядра процессора.
• Не менее 8 ГБ опе­ра­тив­ной памяти.
• 30 ГБ встро­ен­ной памя­ти на жест­ком диске.

Конфигурация узлового компьютера

• Физи­че­ский или вир­ту­аль­ный базо­вый образ, предо­став­лен­ный для глав­ной машины.
• Хотя бы Linux 7 на машине.
• Докер уста­нов­лен с вер­си­ей не ниже 1.6.
• 1 ядро процессора.
• Опе­ра­тив­ная память 8 ГБ.
• Жест­кий диск 15 ГБ для раз­ме­ще­ния изоб­ра­же­ний и 15 ГБ для хра­не­ния изображений.

Пошаговое руководство по установке OpenShift

В сле­ду­ю­щем опи­са­нии мы соби­ра­ем­ся настро­ить лабо­ра­тор­ную сре­ду OpenShift, кото­рую впо­след­ствии мож­но будет рас­ши­рить до более круп­но­го кла­сте­ра. Посколь­ку OpenShift тре­бу­ет настрой­ки масте­ра и узла, нам потре­бу­ет­ся как мини­мум две маши­ны, раз­ме­щен­ные в обла­ке, физи­че­ских или вир­ту­аль­ных машинах.

Step 1- Сна­ча­ла уста­но­ви­те Linux на обе маши­ны, где Linux 7 долж­на быть наи­мень­шей вер­си­ей. Это мож­но сде­лать с помо­щью сле­ду­ю­щих команд, если у вас есть актив­ная под­пис­ка 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

После того, как все выше­пе­ре­чис­лен­ные базо­вые паке­ты уста­нов­ле­ны на обе­их маши­нах, сле­ду­ю­щим шагом будет уста­нов­ка Docker на соот­вет­ству­ю­щих машинах.

Step 2- Настрой­те Docker так, что­бы он раз­ре­шал небез­опас­ную связь толь­ко в локаль­ной сети. Для это­го отре­дак­ти­руй­те файл Docker внут­ри / etc / sysconfig. Если файл отсут­ству­ет, вам необ­хо­ди­мо создать его вручную.

# vi /etc/sysconfig/docker

OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

После настрой­ки Docker на глав­ной машине нам нуж­но настро­ить связь без паро­ля меж­ду обо­и­ми маши­на­ми. Для это­го мы будем исполь­зо­вать аутен­ти­фи­ка­цию с откры­тым и закры­тым ключом.

Step 3 - Сге­не­ри­руй­те клю­чи на глав­ном ком­пью­те­ре, а затем ско­пи­руй­те ключ id_rsa.pub в авто­ри­зо­ван­ный файл клю­чей на узло­вой машине, что мож­но сде­лать с помо­щью сле­ду­ю­щей команды.

# ssh-keygen
# ssh-copy-id -i .ssh/id_rsa.pub root@ose3-node.test.com

После того, как вы выпол­ни­ли все выше­пе­ре­чис­лен­ные настрой­ки, сле­ду­ет уста­но­вить OpenShift вер­сии 3 на глав­ном компьютере.

Step 4 - На глав­ном ком­пью­те­ре выпол­ни­те сле­ду­ю­щую коман­ду curl.

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

При­ве­ден­ная выше коман­да уста­но­вит уста­нов­ку для OSV3. Сле­ду­ю­щим шагом будет настрой­ка OpenShift V3 на машине.

Если вы не може­те загру­зить напря­мую из Интер­не­та, его мож­но загру­зить с https://install.openshift.com/portable/oo-install-ose.tgz как tar-пакет, из кото­ро­го уста­нов­щик может запус­кать­ся на локаль­ном глав­ном компьютере.

После того, как мы под­го­то­ви­ли уста­нов­ку, нам нуж­но начать с фак­ти­че­ской настрой­ки OSV3 на маши­нах. Эта настрой­ка очень спе­ци­фич­на для тести­ро­ва­ния сре­ды для реаль­но­го про­из­вод­ства, у нас есть LDAP и дру­гие вещи.

Step 5 - На глав­ном ком­пью­те­ре настрой­те сле­ду­ю­щий код, рас­по­ло­жен­ный в /etc/openshift/master/master-config.yaml

 

Затем создай­те стан­дарт­но­го поль­зо­ва­те­ля для адми­ни­стри­ро­ва­ния по умолчанию.

# htpasswd -c /root/users.htpasswd admin

Step 6- Посколь­ку OpenShift исполь­зу­ет реестр Docker для настрой­ки обра­зов, нам необ­хо­ди­мо настро­ить реестр Docker. Это исполь­зу­ет­ся для созда­ния и хра­не­ния обра­зов Docker после сборки.

Создай­те ката­лог на ком­пью­те­ре узла OpenShift, исполь­зуя сле­ду­ю­щую команду.

# mkdir /images

Затем вой­ди­те на глав­ный ком­пью­тер, исполь­зуя учет­ные дан­ные адми­ни­стра­то­ра по умол­ча­нию, кото­рые созда­ют­ся при настрой­ке реестра.

# oc login

Username: system:admin

Пере­клю­чи­тесь на создан­ный по умол­ча­нию проект.

# oc project default

Step 7 - Создай­те реестр Docker.

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

Отре­дак­ти­руй­те пра­ва пользователя.

Создай­те и отре­дак­ти­руй­те реестр образов.

Step 8 - Создай­те марш­ру­ти­за­цию по умолчанию.

По умол­ча­нию OpenShift исполь­зу­ет OpenVswitch как про­грамм­ную сеть. Исполь­зуй­те сле­ду­ю­щую коман­ду для созда­ния марш­ру­ти­за­ции по умол­ча­нию. Это исполь­зу­ет­ся для балан­си­ров­ки нагруз­ки и марш­ру­ти­за­ции прок­си. Марш­ру­ти­за­тор похож на реестр Docker, а так­же рабо­та­ет в реестре.

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

Затем отре­дак­ти­руй­те при­ви­ле­гии пользователя.

Step 9 - Настро­ить DNS.

Для обра­бот­ки запро­са URL OpenShift тре­бу­ет­ся рабо­чая сре­да DNS. Эта кон­фи­гу­ра­ция DNS тре­бу­ет­ся для созда­ния под­ста­но­воч­но­го зна­ка, кото­рый тре­бу­ет­ся для созда­ния под­ста­но­воч­но­го зна­ка DNS, ука­зы­ва­ю­ще­го на маршрутизатор.

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

Step 10- Послед­ним шагом будет уста­нов­ка сер­ве­ра github на глав­ной машине OpenShift V3, что не явля­ет­ся обя­за­тель­ным. Это лег­ко сде­лать с помо­щью сле­ду­ю­щей после­до­ва­тель­но­сти команд.

#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

Как толь­ко опи­сан­ная выше настрой­ка будет завер­ше­на, вы може­те про­ве­рить это с помо­щью тести­ро­ва­ния и раз­вер­ты­ва­ния при­ло­же­ний, о кото­рых мы узна­ем боль­ше в сле­ду­ю­щих главах.

 

OpenShift - основная концепция

Преж­де чем начать фак­ти­че­скую настрой­ку и раз­вер­ты­ва­ние при­ло­же­ний, нам нуж­но понять неко­то­рые основ­ные тер­ми­ны и кон­цеп­ции, исполь­зу­е­мые в OpenShift V3.

Контейнеры и изображения

Картинки

Это основ­ные стро­и­тель­ные бло­ки OpenShift, кото­рые фор­ми­ру­ют­ся из обра­зов Docker. В каж­дом моду­ле OpenShift кла­стер име­ет свои соб­ствен­ные изоб­ра­же­ния, рабо­та­ю­щие внут­ри него. Когда мы настра­и­ва­ем модуль, у нас есть поле, кото­рое будет объ­еди­не­но из реест­ра. Этот файл кон­фи­гу­ра­ции извле­чет образ и раз­вер­нет его на узле кластера.

Что­бы извлечь и создать из него изоб­ра­же­ние, выпол­ни­те сле­ду­ю­щую коман­ду. OC - ​​это кли­ент для свя­зи со сре­дой OpenShift после вхо­да в систему.

$ oc create –f Tesing_for_Image_pull

Контейнер

Он созда­ет­ся при раз­вер­ты­ва­нии обра­за Docker в кла­сте­ре OpenShift. При опре­де­ле­нии любой кон­фи­гу­ра­ции мы опре­де­ля­ем сек­цию кон­тей­не­ра в фай­ле кон­фи­гу­ра­ции. В одном кон­тей­не­ре может быть запу­ще­но несколь­ко обра­зов, и все кон­тей­не­ры, запу­щен­ные на узле кла­сте­ра, управ­ля­ют­ся OpenShift Kubernetes.

Ниже при­ве­де­ны спе­ци­фи­ка­ции для опре­де­ле­ния кон­тей­не­ра, в кото­ром запу­ще­но несколь­ко изображений.

В при­ве­ден­ной выше кон­фи­гу­ра­ции мы опре­де­ли­ли мно­го­кон­тей­нер­ный модуль с дву­мя обра­за­ми Tomcat и MongoDB внут­ри него.

Модули и службы

Стручки

Под мож­но опре­де­лить как набор кон­тей­не­ров и их хра­ни­ли­ще внут­ри узла кла­сте­ра OpenShift (Kubernetes). В общем, у нас есть два типа моду­лей: от одно­го кон­тей­не­ра до несколь­ких контейнеров.

Single Container Pod - Их мож­но лег­ко создать с помо­щью коман­ды OC или с помо­щью фай­ла yml базо­вой конфигурации.

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

Создай­те его с помо­щью про­сто­го фай­ла yaml сле­ду­ю­щим образом.

После созда­ния ука­зан­но­го выше фай­ла он сге­не­ри­ру­ет модуль с помо­щью сле­ду­ю­щей команды.

$ oc create –f apache.yml

Multi-Container Pod- Мно­го­кон­тей­нер­ные поды - это те кон­тей­не­ры, в кото­рых у нас рабо­та­ет более одно­го кон­тей­не­ра. Они созда­ют­ся с исполь­зо­ва­ни­ем фай­лов yaml сле­ду­ю­щим образом.

После созда­ния этих фай­лов мы можем про­сто исполь­зо­вать тот же метод, что и выше, для созда­ния контейнера.

Service- Посколь­ку у нас есть набор кон­тей­не­ров, рабо­та­ю­щих внут­ри моду­ля, точ­но так же у нас есть служ­ба, кото­рую мож­но опре­де­лить как логи­че­ский набор моду­лей. Это абстракт­ный уро­вень над моду­лем, кото­рый предо­став­ля­ет еди­ный IP и DNS-имя, через кото­рое мож­но полу­чить доступ к моду­лям. Сер­вис помо­га­ет управ­лять кон­фи­гу­ра­ци­ей балан­си­ров­ки нагруз­ки и очень лег­ко мас­шта­би­ро­вать модуль. В OpenShift служ­ба - это объ­ект REST, обо­жеств­ле­ние кото­ро­го может быть отправ­ле­но в apiService на глав­ном сер­ве­ре OpenShift для созда­ния ново­го экземпляра.

Сборки и стримы

В OpenShift сбор­ка - это про­цесс пре­об­ра­зо­ва­ния изоб­ра­же­ний в кон­тей­не­ры. Это обра­бот­ка, кото­рая пре­об­ра­зу­ет исход­ный код в изоб­ра­же­ние. Этот про­цесс сбор­ки рабо­та­ет по зара­нее опре­де­лен­ной стра­те­гии сбор­ки исход­но­го кода в образ.

Сбор­ка обра­ба­ты­ва­ет несколь­ко стра­те­гий и источников.

Строить стратегии

• Source to Image- По сути, это инстру­мент, кото­рый помо­га­ет созда­вать вос­про­из­во­ди­мые изоб­ра­же­ния. Эти обра­зы все­гда гото­вы к запус­ку с помо­щью коман­ды Docker run.
• Docker Build - Это про­цесс, в кото­ром обра­зы созда­ют­ся с исполь­зо­ва­ни­ем фай­ла Docker путем выпол­не­ния про­стой коман­ды сбор­ки Docker.
• Custom Build - Это сбор­ки, кото­рые исполь­зу­ют­ся для созда­ния базо­вых обра­зов Docker.

Источники сборки

Git- Этот источ­ник исполь­зу­ет­ся, когда репо­зи­то­рий git исполь­зу­ет­ся для созда­ния изоб­ра­же­ний. Dockerfile не явля­ет­ся обя­за­тель­ным. Кон­фи­гу­ра­ции из исход­но­го кода выгля­дят сле­ду­ю­щим образом.

Dockerfile - Dockerfile исполь­зу­ет­ся в каче­стве вход­ных дан­ных в фай­ле конфигурации.

Image Streams- Пото­ки изоб­ра­же­ний созда­ют­ся после извле­че­ния изоб­ра­же­ний. Пре­иму­ще­ство пото­ка изоб­ра­же­ний заклю­ча­ет­ся в том, что он ищет обнов­ле­ния для новой вер­сии изоб­ра­же­ния. Это исполь­зу­ет­ся для срав­не­ния любо­го коли­че­ства обра­зов кон­тей­не­ров в фор­ма­те Docker, иден­ти­фи­ци­ро­ван­ных тегами.

Пото­ки изоб­ра­же­ний могут авто­ма­ти­че­ски выпол­нять дей­ствие при созда­нии ново­го изоб­ра­же­ния. Все сбор­ки и раз­вер­ты­ва­ния могут отсле­жи­вать дей­ствия с изоб­ра­же­ни­я­ми и выпол­нять соот­вет­ству­ю­щие дей­ствия. Ниже пока­за­но, как мы опре­де­ля­ем сбор­ку потока.

Маршруты и шаблоны

Маршруты

В OpenShift марш­ру­ти­за­ция - это метод предо­став­ле­ния услу­ги внеш­не­му миру путем созда­ния и настрой­ки внеш­не­го доступ­но­го име­ни хоста. Марш­ру­ты и конеч­ные точ­ки исполь­зу­ют­ся для предо­став­ле­ния услу­ги внеш­не­му миру, отку­да поль­зо­ва­тель может исполь­зо­вать под­клю­че­ние име­ни (DNS) для досту­па к опре­де­лен­но­му приложению.

В OpenShift марш­ру­ты созда­ют­ся с помо­щью марш­ру­ти­за­то­ров, кото­рые раз­вер­ты­ва­ют­ся адми­ни­стра­то­ром OpenShift в кла­сте­ре. Марш­ру­ти­за­то­ры исполь­зу­ют­ся для при­вяз­ки пор­тов HTTP (80) и https (443) к внеш­ним приложениям.

Ниже при­ве­де­ны раз­лич­ные типы про­то­ко­лов, под­дер­жи­ва­е­мых маршрутами.

• HTTP
• HTTPS
• TSL и веб-сокет

При настрой­ке служ­бы селек­то­ры исполь­зу­ют­ся для настрой­ки служ­бы и поис­ка конеч­ной точ­ки, исполь­зу­ю­щей эту служ­бу. Ниже при­во­дит­ся при­мер того, как мы созда­ем служ­бу и марш­ру­ти­за­цию для этой служ­бы с исполь­зо­ва­ни­ем соот­вет­ству­ю­ще­го протокола.

Затем выпол­ни­те сле­ду­ю­щую коман­ду, и служ­ба будет создана.

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

Так выгля­дит сер­вис после создания.

Создай­те марш­ру­ти­за­цию для обслу­жи­ва­ния, исполь­зуя сле­ду­ю­щий код.

Когда для созда­ния марш­ру­та исполь­зу­ет­ся коман­да OC, созда­ет­ся новый экзем­пляр ресур­са маршрута.

Шаблоны

Шаб­ло­ны опре­де­ля­ют­ся в OpenShift как стан­дарт­ный объ­ект, кото­рый мож­но исполь­зо­вать несколь­ко раз. Он пара­мет­ри­зо­ван спис­ком запол­ни­те­лей, кото­рые исполь­зу­ют­ся для созда­ния несколь­ких объ­ек­тов. Это может быть исполь­зо­ва­но для созда­ния чего угод­но, от моду­ля до сети, для чего поль­зо­ва­те­ли име­ют пра­во созда­вать. Спи­сок объ­ек­тов может быть создан, если шаб­лон из интер­фей­са команд­ной стро­ки или гра­фи­че­ско­го интер­фей­са поль­зо­ва­те­ля в изоб­ра­же­нии загру­жен в ката­лог проекта.

Аутентификация и авторизация

Аутентификация

В OpenShift, настра­и­вая струк­ту­ру масте­ра и кли­ен­та, мастер пред­ла­га­ет встро­ен­ную функ­цию сер­ве­ра OAuth. Сер­вер OAuth исполь­зу­ет­ся для гене­ра­ции токе­нов, кото­рые исполь­зу­ют­ся для аутен­ти­фи­ка­ции в API. Посколь­ку OAuth явля­ет­ся настрой­кой по умол­ча­нию для масте­ра, по умол­ча­нию исполь­зу­ет­ся постав­щик удо­сто­ве­ре­ний Allow All. При­сут­ству­ют раз­ные постав­щи­ки удо­сто­ве­ре­ний, кото­рые мож­но настро­ить на/etc/openshift/master/master-config.yaml.

В OAuth пред­став­ле­ны раз­ные типы постав­щи­ков удостоверений.

• Поз­во­лять все
• Запре­тить все
• HTPasswd
• LDAP
• Базо­вая аутентификация

Позволять все

Запретить все

HTPasswd

Что­бы исполь­зо­вать HTPasswd, нам нуж­но сна­ча­ла настро­ить Httpd-tools на глав­ном ком­пью­те­ре, а затем настро­ить его так же, как мы дела­ли для других.

Авторизация

Авто­ри­за­ция - это функ­ция масте­ра OpenShift, кото­рая исполь­зу­ет­ся для про­вер­ки под­лин­но­сти поль­зо­ва­те­ля. Это озна­ча­ет, что он про­ве­ря­ет поль­зо­ва­те­ля, кото­рый пыта­ет­ся выпол­нить дей­ствие, что­бы узнать, авто­ри­зо­ван ли поль­зо­ва­тель для выпол­не­ния это­го дей­ствия в дан­ном про­ек­те. Это помо­га­ет адми­ни­стра­то­ру кон­тро­ли­ро­вать доступ к проектам.

Поли­ти­ки авто­ри­за­ции кон­тро­ли­ру­ют­ся с помощью -

• Rules
• Roles
• Bindings

Оцен­ка авто­ри­за­ции выпол­ня­ет­ся с использованием -

• Identity
• Action
• Bindings

Исполь­зо­ва­ние политик -

• Кла­стер­ная политика
• Мест­ная политика

 

OpenShift - Начало работы

OpenShift состо­ит из двух типов меди­а­нов для созда­ния и раз­вер­ты­ва­ния при­ло­же­ний с помо­щью гра­фи­че­ско­го интер­фей­са или интер­фей­са команд­ной стро­ки. В этой гла­ве мы будем исполь­зо­вать интер­фейс команд­ной стро­ки для созда­ния ново­го при­ло­же­ния. Мы будем исполь­зо­вать кли­ент OC для свя­зи со сре­дой OpenShift.

Создание нового приложения

В OpenShift есть три мето­да созда­ния ново­го приложения.

• Из исход­но­го кода
• Из изоб­ра­же­ния
• Из шаб­ло­на

Из исходного кода

Когда мы пыта­ем­ся создать при­ло­же­ние из исход­но­го кода, OpenShift ищет файл Docker, кото­рый дол­жен при­сут­ство­вать внут­ри репо­зи­то­рия, кото­рый опре­де­ля­ет про­цесс сбор­ки при­ло­же­ния. Мы будем исполь­зо­вать oc new-app для созда­ния приложения.

Пер­вое, что сле­ду­ет иметь в виду при исполь­зо­ва­нии репо, это то, что он дол­жен ука­зы­вать на источ­ник в репо, отку­да OpenShift извле­чет код и постро­ит его.

Если репо кло­ни­ро­ва­но на машине Docker, на кото­рой уста­нов­лен кли­ент OC, и поль­зо­ва­тель нахо­дит­ся внут­ри того же ката­ло­га, его мож­но создать с помо­щью сле­ду­ю­щей команды.

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

Ниже при­ве­ден при­мер попыт­ки сбор­ки из уда­лен­но­го репо для кон­крет­ной ветки.

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

Здесь test1 - это вет­ка, из кото­рой мы пыта­ем­ся создать новое при­ло­же­ние в OpenShift.

При ука­за­нии фай­ла Docker в репо­зи­то­рии нам необ­хо­ди­мо опре­де­лить стра­те­гию сбор­ки, как пока­за­но ниже.

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

Из изображения

При созда­нии при­ло­же­ния с исполь­зо­ва­ни­ем обра­зов они при­сут­ству­ют на локаль­ном сер­ве­ре Docker, в соб­ствен­ном репо­зи­то­рии Docker или в хабе Docker. Един­ствен­ное, в чем дол­жен убе­дить­ся поль­зо­ва­тель, это то, что у него есть доступ для извле­че­ния изоб­ра­же­ний из хаба без каких-либо проблем.

OpenShift может опре­де­лять исполь­зу­е­мый источ­ник, будь то образ Docker или исход­ный поток. Одна­ко, если поль­зо­ва­тель жела­ет, он может явно опре­де­лить, явля­ет­ся ли это пото­ком изоб­ра­же­ний или изоб­ра­же­ни­ем Docker.

$ oc new-app - - docker-image tomcat

Исполь­зо­ва­ние пото­ка изображений -

$ oc new-app tomcat:v1

Из шаблона

Шаб­ло­ны мож­но исполь­зо­вать для созда­ния ново­го при­ло­же­ния. Это может быть уже суще­ству­ю­щий шаб­лон или созда­ние ново­го шаблона.

Сле­ду­ю­щий файл yaml - это в основ­ном шаб­лон, кото­рый мож­но исполь­зо­вать для развертывания.

Разработка и развертывание веб-приложения

Разработка нового приложения в OpenShift

Что­бы создать новое при­ло­же­ние в OpenShift, мы долж­ны напи­сать новый код при­ло­же­ния и постро­ить его с помо­щью команд сбор­ки OpenShift OC. Как уже гово­ри­лось, у нас есть несколь­ко спо­со­бов созда­ния ново­го изоб­ра­же­ния. Здесь мы будем исполь­зо­вать шаб­лон для созда­ния при­ло­же­ния. Этот шаб­лон создаст новое при­ло­же­ние при запус­ке с коман­дой oc new-app.

Будет создан сле­ду­ю­щий шаб­лон - два интер­фейс­ных при­ло­же­ния и одна база дан­ных. Наря­ду с этим он создаст две новые служ­бы, и эти при­ло­же­ния будут раз­вер­ну­ты в кла­сте­ре OpenShift. При созда­нии и раз­вер­ты­ва­нии при­ло­же­ния нам сна­ча­ла нуж­но создать про­стран­ство имен в OpenShift и раз­вер­нуть при­ло­же­ние в этом про­стран­стве имен.

Create a new namespace

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

Шаблон

Определения объектов

Secret definition in a template

Service definition in a template

Route definition in a template

Build config definition in a template

Deployment config in a template

Service definition in a template

Deployment config definition in a template

При­ве­ден­ный выше файл шаб­ло­на необ­хо­ди­мо ском­пи­ли­ро­вать сра­зу. Нам нуж­но сна­ча­ла ско­пи­ро­вать весь кон­тент в один файл и назы­вать его как yaml-файл после завершения.

Нам нуж­но запу­стить сле­ду­ю­щую коман­ду, что­бы создать приложение.

Если мы хотим отсле­жи­вать сбор­ку, это мож­но сде­лать с помощью -

 

OpenShift - автоматизация сборки

В OpenShift суще­ству­ет четы­ре типа стра­те­гий сборки.

• Стра­те­гия пре­об­ра­зо­ва­ния источ­ни­ка в изображение
• Докер­ская стратегия
• Инди­ви­ду­аль­ная стратегия
• Тру­бо­про­вод­ная стратегия

Стратегия преобразования источника в изображение

Поз­во­ля­ет созда­вать обра­зы кон­тей­не­ров, начи­ная с исход­но­го кода. В этом пото­ке фак­ти­че­ский код сна­ча­ла загру­жа­ет­ся в кон­тей­нер, а затем ком­пи­ли­ру­ет­ся внут­ри него. Ском­пи­ли­ро­ван­ный код раз­вер­ты­ва­ет­ся в том же кон­тей­не­ре, и образ созда­ет­ся из это­го кода.

Есть несколь­ко стра­те­ги­че­ских политик.

• Forcepull
• Допол­ни­тель­ные сборки
• Внеш­ние сборки

Докер стратегия

В этом пото­ке OpenShift исполь­зу­ет Dockerfile для созда­ния обра­за, а затем загру­жа­ет создан­ные обра­зы в реестр Docker.

Пара­метр фай­ла Docker мож­но исполь­зо­вать в несколь­ких местах, начи­ная с пути к фай­лу, без кеша и при­ну­ди­тель­но­го извлечения.

• Из изоб­ра­же­ния
• Путь к Dockerfile
• Нет кеша
• Сила тяги

Индивидуальная стратегия

Это один из раз­лич­ных видов стра­те­гии сбор­ки, в кото­рой нет тако­го при­нуж­де­ния, что выхо­дом сбор­ки будет изоб­ра­же­ние. Это мож­но срав­нить с рабо­той Джен­кин­са в сво­бод­ном сти­ле. С его помо­щью мы можем созда­вать Jar, rpm и дру­гие пакеты.

Он состо­ит из несколь­ких стра­те­гий сборки.

• Открыть сокет Docker
• Secrets
• Сила тяги

Трубопроводная стратегия

Стра­те­гия кон­вей­е­ра исполь­зу­ет­ся для созда­ния настра­и­ва­е­мых кон­вей­е­ров сбор­ки. Это в основ­ном исполь­зу­ет­ся для реа­ли­за­ции рабо­че­го про­цес­са в кон­вей­е­ре. Этот поток сбор­ки исполь­зу­ет настра­и­ва­е­мый поток кон­вей­е­ра сбор­ки с исполь­зо­ва­ни­ем язы­ка Groovy DSL. OpenShift создаст зада­ние кон­вей­е­ра в Jenkins и выпол­нит его. Этот кон­вей­ер­ный поток так­же мож­но исполь­зо­вать в Jenkins. В этой стра­те­гии мы исполь­зу­ем Jenkinsfile и добав­ля­ем его в опре­де­ле­ние buildconfig.

Using build pipeline

 

OpenShift - интерфейс командной строки

Step 4 - Про­верь­те настрой­ку OC в Windows.

OC Client для Mac OS X

Мы можем загру­зить дво­ич­ные фай­лы уста­нов­ки Mac OS в то же место, что и для Windows, а затем разар­хи­ви­ро­вать его в опре­де­лен­ном месте и уста­но­вить путь к испол­ня­е­мо­му фай­лу в пере­мен­ной сре­ды PATH.

Alternatively

Мы можем исполь­зо­вать Home brew и настро­ить его с помо­щью сле­ду­ю­щей команды.

OC Client для Linux

На той же стра­ни­це у нас есть tar-файл для уста­нов­ки Linux, кото­рый мож­но исполь­зо­вать для уста­нов­ки. Поз­же мож­но задать пере­мен­ную пути, ука­зы­ва­ю­щую на это кон­крет­ное испол­ня­е­мое место.

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

Рас­па­куй­те tar-файл, исполь­зуя сле­ду­ю­щую команду.

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

Выпол­ни­те сле­ду­ю­щую коман­ду, что­бы про­ве­рить аутентификацию.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login

Server [https://localhost:8443]:

Файлы конфигурации CLI

Файл кон­фи­гу­ра­ции OC CLI исполь­зу­ет­ся для управ­ле­ния несколь­ки­ми под­клю­че­ни­я­ми к сер­ве­ру OpenShift и меха­низ­мом аутен­ти­фи­ка­ции. Этот файл кон­фи­гу­ра­ции так­же исполь­зу­ет­ся для хра­не­ния и управ­ле­ния несколь­ки­ми про­фи­ля­ми, а так­же для пере­клю­че­ния меж­ду ними. Обыч­ный файл кон­фи­гу­ра­ции выгля­дит сле­ду­ю­щим образом.

Настройка клиента CLI

Для установки учетных данных пользователя

Для настройки кластера

пример

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

Для настройки контекста

Профили CLI

В одном фай­ле кон­фи­гу­ра­ции CLI мы можем иметь несколь­ко про­фи­лей, каж­дый из кото­рых име­ет свою кон­фи­гу­ра­цию сер­ве­ра OpenShift, кото­рую поз­же мож­но исполь­зо­вать для пере­клю­че­ния меж­ду раз­ны­ми про­фи­ля­ми CLI.

В при­ве­ден­ной выше кон­фи­гу­ра­ции мы видим, что она раз­де­ле­на на четы­ре основ­ных раз­де­ла, начи­ная с кла­сте­ра, кото­рый опре­де­ля­ет два экзем­пля­ра глав­ных машин OpenShift. Вто­рой раз­дел кон­тек­ста опре­де­ля­ет два кон­тек­ста с име­на­ми vipin и alim. Теку­щий кон­текст опре­де­ля­ет, какой кон­текст в насто­я­щее вре­мя исполь­зу­ет­ся. Его мож­но изме­нить на дру­гой кон­текст или про­филь, если мы изме­ним опре­де­ле­ние здесь. Нако­нец, опре­де­ля­ет­ся опре­де­ле­ние поль­зо­ва­те­ля и его токен аутен­ти­фи­ка­ции, кото­рым в нашем слу­чае явля­ет­ся vipin.

Если мы хотим про­ве­рить теку­щий исполь­зу­е­мый про­филь, это мож­но сде­лать с помощью -

Если мы хотим пере­клю­чить­ся на дру­гой интер­фейс команд­ной стро­ки, это мож­но сде­лать из команд­ной стро­ки с помо­щью сле­ду­ю­щей команды.

Исполь­зуя ука­зан­ную выше коман­ду, мы можем пере­клю­чать­ся меж­ду про­фи­ля­ми. В любой момент, если мы хотим про­смот­реть кон­фи­гу­ра­цию, мы можем исполь­зо­вать коман­ду $ oc config view.

 

OpenShift - Операции через интерфейс командной строки

OpenShift CLI может выпол­нять все основ­ные и допол­ни­тель­ные функ­ции настрой­ки, управ­ле­ния, добав­ле­ния и раз­вер­ты­ва­ния приложений.

Мы можем выпол­нять раз­лич­ные опе­ра­ции с помо­щью команд OC. Этот кли­ент помо­га­ет вам раз­ра­ба­ты­вать, созда­вать, раз­вер­ты­вать и запус­кать при­ло­же­ния на любой плат­фор­ме, сов­ме­сти­мой с OpenShift или Kubernetes. Он так­же вклю­ча­ет адми­ни­стра­тив­ные коман­ды для управ­ле­ния кла­сте­ром с помо­щью под­ко­ман­ды adm.

Основные команды

В сле­ду­ю­щей таб­ли­це пере­чис­ле­ны основ­ные коман­ды OC.

Sr. No.	Коман­ды и описание
1	Types Вве­де­ние в кон­цеп­ции и тип
2	Login Вой­ти на сервер
3	new-project Запро­сить новый проект
4	new-app Создать новое приложение
5	Status Пока­зать обзор теку­ще­го проекта
6	Project Перей­ти к дру­го­му проекту
7	Projects Пока­зать суще­ству­ю­щие проекты
8	Explain Доку­мен­та­ция ресурсов
9	Cluster Запуск и оста­нов­ка кла­сте­ра OpenShift

Авторизоваться

Вой­ди­те на свой сер­вер и сохра­ни­те логин для после­ду­ю­ще­го исполь­зо­ва­ния. Поль­зо­ва­те­ли, впер­вые исполь­зу­ю­щие кли­ент, долж­ны выпол­нить эту коман­ду, что­бы под­клю­чить­ся к сер­ве­ру, уста­но­вить сеанс с аутен­ти­фи­ка­ци­ей и сохра­нить соеди­не­ние в фай­ле кон­фи­гу­ра­ции. Кон­фи­гу­ра­ция по умол­ча­нию будет сохра­не­на в вашем домаш­нем ката­ло­ге в «.kube / config».

Инфор­ма­ция, необ­хо­ди­мая для вхо­да в систе­му, напри­мер имя поль­зо­ва­те­ля и пароль, токен сеан­са или све­де­ния о сер­ве­ре, может быть предо­став­ле­на ​​с помо­щью фла­гов. Если не ука­зан, коман­да запро­сит ввод дан­ных поль­зо­ва­те­лем по мере необходимости.

Usage

oc login [URL] [options]

Example

Опции -

-p, --password = " - Пароль, под­ска­жет, если не указан

-u, --username = " - Имя поль­зо­ва­те­ля, под­ска­жет, если не указано

--certificate-authority = "- Путь к сер­ти­фи­ка­ту. файл для цен­тра сертификации

--insecure-skip-tls-verify = false- Если true, сер­ти­фи­кат сер­ве­ра не будет про­ве­рять­ся на дей­стви­тель­ность. Это сде­ла­ет ваши HTTPS-соеди­не­ния небезопасными.

--token = " - Токен-носи­тель для аутен­ти­фи­ка­ции на сер­ве­ре API

Что­бы полу­чить пол­ную инфор­ма­цию о любой коман­де, исполь­зуй­те oc <Command Name> --help команда.

Команды сборки и развертывания

В сле­ду­ю­щей таб­ли­це пере­чис­ле­ны коман­ды сбор­ки и развертывания.

Sr. No.	Коман­ды и описание
1	Rollout Управ­ле­ние раз­вер­ты­ва­ни­ем Kubernetes или OpenShift
2	Deploy Про­смотр, запуск, отме­на или повтор­ная попыт­ка развертывания
3	Rollback Вер­нуть часть при­ло­же­ния в преды­ду­щее состояние
4	new-build Создать новую кон­фи­гу­ра­цию сборки
5	start-build Начать новую сборку
6	cancel-build Отме­нить выпол­не­ние, ожи­да­ю­щие или новые сборки
7	import-image Импор­ти­ру­ет обра­зы из реест­ра Docker
8	Tag Поме­тить суще­ству­ю­щие изоб­ра­же­ния в пото­ки изображений

Команды управления приложениями

В сле­ду­ю­щей таб­ли­це пере­чис­ле­ны коман­ды управ­ле­ния приложением.

Sr. No.	Коман­ды и описание
1	Get Пока­зать один или несколь­ко ресурсов
2	Describe Пока­зать подроб­ную инфор­ма­цию о кон­крет­ном ресур­се или груп­пе ресурсов
3	Edit Редак­ти­ро­вать ресурс на сервере
4	Set Коман­ды, кото­рые помо­га­ют уста­но­вить опре­де­лен­ные функ­ции на объектах
5	Label Обно­ви­те ярлы­ки на ресурсе
6	Annotate Обно­вить анно­та­ции к ресурсу
7	Expose Предо­став­ле­ние реп­ли­ци­ро­ван­но­го при­ло­же­ния как служ­бы или маршрута
8	Delete Уда­лить один или несколь­ко ресурсов
9	Scale Изме­нить коли­че­ство моду­лей в развертывании
10	Autoscale Авто­ма­ти­че­ское мас­шта­би­ро­ва­ние кон­фи­гу­ра­ции раз­вер­ты­ва­ния, раз­вер­ты­ва­ния, репли­ка­ции, кон­трол­ле­ра или набо­ра реплик
11	Secrets Управ­ляй­те секретами
12	Serviceaccounts Управ­ляй­те сер­вис­ны­ми акка­ун­та­ми в вашем проекте

Команды для устранения неполадок и отладки

В сле­ду­ю­щей таб­ли­це пере­чис­ле­ны коман­ды устра­не­ния непо­ла­док и отладки.

Sr. No.	Коман­ды и описание
1	logs Рас­пе­ча­тать жур­на­лы для ресурса
2	Rsh Начать сеанс обо­лоч­ки в модуле
3	Rsync Копи­ро­ва­ние фай­лов меж­ду локаль­ной фай­ло­вой систе­мой и модулем
4	port-forward Пере­на­пра­вить один или несколь­ко локаль­ных пор­тов на под
5	Debug Запу­стить новый экзем­пляр моду­ля для отладки
6	Exec Выпол­нить коман­ду в контейнере
7	Procy Запу­стить прок­си на сер­вер Kubernetes API
9	Attach При­со­еди­нить к рабо­та­ю­ще­му контейнеру
10	Run Запу­стить кон­крет­ный образ в кластере
11	Cp Копи­ро­ва­ние фай­лов и ката­ло­гов в кон­тей­не­ры и из них

Расширенные команды

В сле­ду­ю­щей таб­ли­це пере­чис­ле­ны рас­ши­рен­ные команды.

Sr. No.	Коман­ды и описание
1	adm Инстру­мен­ты для управ­ле­ния кластером
2	create Создать ресурс по име­ни фай­ла или стан­дарт­но­му вводу
3	replace Заме­нить ресурс име­нем фай­ла или стан­дарт­ным вводом
4	apply При­ме­нить кон­фи­гу­ра­цию к ресур­су по име­ни фай­ла или стан­дарт­но­му вводу
5	patch Обнов­ле­ние поля (полей) ресур­са с помо­щью стра­те­ги­че­ско­го пат­ча слияния
6	process Доба­вить шаб­лон в спи­сок ресурсов
7	export Экс­порт ресур­сов, что­бы их мож­но было исполь­зо­вать в дру­гом месте
8	extract Извлечь сек­ре­ты или кар­ты кон­фи­гу­ра­ции на диск
9	idle Про­ста­и­ва­ю­щие мас­шта­би­ру­е­мые ресурсы
10	observe Наблю­дай­те за изме­не­ни­я­ми ресур­сов и реа­ги­руй­те на них (экс­пе­ри­мен­таль­но)
11	policy Управ­ле­ние поли­ти­кой авторизации
12	auth Про­ве­рить авторизацию
13	convert Пре­об­ра­зо­ва­ние фай­лов кон­фи­гу­ра­ции меж­ду раз­ны­ми вер­си­я­ми API
14	import Коман­ды, импор­ти­ру­ю­щие приложения

Установка команд

В сле­ду­ю­щей таб­ли­це пере­чис­ле­ны коман­ды настройки.

Sr. No.	Коман­ды и описание
1	Logout Завер­шить теку­щий сеанс сервера
2	Config Изме­ни­те фай­лы кон­фи­гу­ра­ции для клиента
3	Whoami Вер­нуть инфор­ма­цию о теку­щем сеансе
4	Completion Код завер­ше­ния выво­да обо­лоч­ки для ука­зан­ной обо­лоч­ки (bash или zsh)

 

OpenShift - Кластеры

OpenShift исполь­зу­ет два мето­да уста­нов­ки для настрой­ки кла­сте­ра OpenShift.

• Метод быст­рой установки
• Рас­ши­рен­ный метод настройки

Настройка кластера

Метод быстрой установки

Этот метод исполь­зу­ет­ся для запус­ка быст­рой кон­фи­гу­ра­ции уста­нов­ки кла­сте­ра без под­держ­ки. Что­бы исполь­зо­вать этот метод, нам нуж­но сна­ча­ла уста­но­вить уста­нов­щик. Это мож­но сде­лать, выпол­нив сле­ду­ю­щую команду.

Interactive method

$ atomic-openshift-installer install

Это полез­но, когда нуж­но запу­стить интер­ак­тив­ную установку.

Unattended installation method

Этот метод исполь­зу­ет­ся, когда нуж­но настро­ить метод авто­ма­ти­че­ской уста­нов­ки, при кото­ром поль­зо­ва­тель может опре­де­лить файл кон­фи­гу­ра­ции yaml и поме­стить его в ~/.config/openshift/с име­нем installer.cfg.yml. Затем мож­но запу­стить сле­ду­ю­щую коман­ду, что­бы уста­но­вить–u tag.

$ atomic-openshift-installer –u install

По умол­ча­нию он исполь­зу­ет файл кон­фи­гу­ра­ции, рас­по­ло­жен­ный в ~/.config/openshift/. С дру­гой сто­ро­ны, Ansible исполь­зу­ет­ся в каче­стве резерв­ной копии установки.

Здесь у нас есть пере­мен­ная для кон­крет­ной роли, кото­рую мож­но опре­де­лить, если кто-то хочет уста­но­вить какую-то кон­крет­ную переменную.

После это­го мы можем про­ве­рить уста­нов­ку, исполь­зуя сле­ду­ю­щую команду.

Расширенная установка

Рас­ши­рен­ная уста­нов­ка пол­но­стью осно­ва­на на кон­фи­гу­ра­ции Ansible, в кото­рой при­сут­ству­ет пол­ная кон­фи­гу­ра­ция хоста и опре­де­ле­ние пере­мен­ных, каса­ю­щих­ся кон­фи­гу­ра­ции масте­ра и узла. Он содер­жит все подроб­но­сти, каса­ю­щи­е­ся конфигурации.

После того, как мы настро­и­ли и под­го­то­ви­ли playbook, мы можем про­сто запу­стить сле­ду­ю­щую коман­ду для настрой­ки кластера.

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

Добавление хостов в кластер

Мы можем доба­вить хост в кла­стер, используя -

• Инстру­мент быст­рой установки
• Рас­ши­рен­ный метод настройки

Quick installation toolрабо­та­ет как в интер­ак­тив­ном, так и в неин­тер­ак­тив­ном режи­ме. Исполь­зуй­те сле­ду­ю­щую команду.

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

Фор­мат мас­шта­би­ро­ва­ния внеш­не­го вида фай­ла кон­фи­гу­ра­ции при­ло­же­ния может исполь­зо­вать­ся для добав­ле­ния как масте­ра, так и узла.

Расширенный метод настройки

В этом мето­де мы обнов­ля­ем файл хоста Ansible, а затем добав­ля­ем в этот файл све­де­ния о новом узле или сер­ве­ре. Файл кон­фи­гу­ра­ции выгля­дит сле­ду­ю­щим образом.

В том же фай­ле Ansible hosts добавь­те подроб­ные све­де­ния о новом узле, как пока­за­но ниже.

Нако­нец, исполь­зуя обнов­лен­ный файл хоста, запу­сти­те новую кон­фи­гу­ра­цию и вызо­ви­те файл кон­фи­гу­ра­ции, что­бы выпол­нить настрой­ку, исполь­зуя сле­ду­ю­щую команду.

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

Управление журналами кластера

Жур­нал кла­сте­ра OpenShift - это не что иное, как жур­на­лы, кото­рые гене­ри­ру­ют­ся с глав­ной и узло­вой машин кла­сте­ра. Они могут управ­лять любым типом жур­на­ла, начи­ная с жур­на­ла сер­ве­ра, глав­но­го жур­на­ла, жур­на­ла кон­тей­не­ра, жур­на­ла моду­ля и т. Д. Для управ­ле­ния жур­на­лом кон­тей­не­ра суще­ству­ет мно­же­ство тех­но­ло­гий и приложений.

Неко­то­рые из пере­чис­лен­ных инстру­мен­тов могут быть реа­ли­зо­ва­ны для управ­ле­ния журналами.

• Fluentd
• ELK
• Kabna
• Nagios
• Splunk

ELK stack- Этот стек поле­зен при попыт­ке собрать жур­на­лы со всех узлов и пред­ста­вить их в систе­ма­ти­зи­ро­ван­ном фор­ма­те. Стек ELK в основ­ном делит­ся на три основ­ные категории.

ElasticSearch - В основ­ном отве­ча­ет за сбор инфор­ма­ции из всех кон­тей­не­ров и раз­ме­ще­ние ее в цен­траль­ном месте.

Fluentd - Исполь­зу­ет­ся для пода­чи собран­ных бре­вен в дви­жок кон­тей­не­ра elasticsearch.

Kibana - Гра­фи­че­ский интер­фейс, исполь­зу­е­мый для пред­став­ле­ния собран­ных дан­ных в виде полез­ной инфор­ма­ции в гра­фи­че­ском интерфейсе.

Сле­ду­ет отме­тить один клю­че­вой момент: когда эта систе­ма раз­вер­ты­ва­ет­ся в кла­сте­ре, она начи­на­ет сбор жур­на­лов со всех узлов.

Журнал диагностики

OpenShift име­ет встро­ен­ный oc adm dignosticsкоман­да с OC, кото­рая может исполь­зо­вать­ся для ана­ли­за мно­же­ства оши­боч­ных ситу­а­ций. Этот инстру­мент может быть исполь­зо­ван масте­ром в каче­стве адми­ни­стра­то­ра кла­сте­ра. Эта ути­ли­та очень полез­на при поис­ке и устра­не­нии извест­ных про­блем. Это рабо­та­ет на глав­ном кли­ен­те и узлах.

Если он запу­щен без каких-либо агру­мен­тов или фла­гов, он будет искать фай­лы кон­фи­гу­ра­ции кли­ен­та, сер­ве­ра и узло­вых машин и исполь­зо­вать их для диа­гно­сти­ки. Мож­но запу­стить диа­гно­сти­ку инди­ви­ду­аль­но, пере­дав сле­ду­ю­щие аргументы:

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

Их мож­но про­сто запу­стить с помо­щью сле­ду­ю­щей команды.

$ oc adm diagnostics <DiagnosticName>

Обновление кластера

Обнов­ле­ние кла­сте­ра вклю­ча­ет обнов­ле­ние несколь­ких вещей в кла­сте­ре и обнов­ле­ние кла­сте­ра новы­ми ком­по­нен­та­ми и обнов­ле­ни­я­ми. Это вклю­ча­ет в себя -

• Обнов­ле­ние основ­ных компонентов
• Обнов­ле­ние узло­вых компонентов
• Обнов­ле­ние политик
• Обнов­ле­ние маршрутов
• Обнов­ле­ние пото­ка изображений

Что­бы выпол­нить все эти обнов­ле­ния, нам нуж­но сна­ча­ла уста­но­вить быст­рые уста­нов­щи­ки или ути­ли­ты. Для это­го нам нуж­но обно­вить сле­ду­ю­щие утилиты -

• atomic-openshift-utils
• atomic-openshift-excluder
• atomic-openshift-docker-excluder
• пакет etcd

Перед нача­лом обнов­ле­ния нам необ­хо­ди­мо создать резерв­ную копию etcd на глав­ной машине, что мож­но сде­лать с помо­щью сле­ду­ю­щих команд.

Обновление основных компонентов

В масте­ре OpenShift мы начи­на­ем обнов­ле­ние с обнов­ле­ния фай­ла etcd, а затем пере­хо­дим к Docker. Нако­нец, мы запус­ка­ем авто­ма­ти­зи­ро­ван­ный испол­ни­тель, что­бы уста­но­вить кла­стер в нуж­ное поло­же­ние. Одна­ко перед запус­ком обнов­ле­ния нам нуж­но сна­ча­ла акти­ви­ро­вать ато­мар­ные паке­ты openshift на каж­дом из масте­ров. Это мож­но сде­лать с помо­щью сле­ду­ю­щих команд.

Step 1 - Уда­ли­те паке­ты atomic-openshift

$ atomic-openshift-excluder unexclude

Step 2 - Обно­вить etcd на всех мастерах.

$ yum update etcd

Step 3 - Пере­за­пу­сти­те служ­бу etcd и про­верь­те, успеш­но ли она запустилась.

$ systemctl restart etcd

$journalctl -r -u etcd

Step 4 - Обно­ви­те пакет Docker.

$ yum update docker

Step 5 - Пере­за­пу­сти­те служ­бу Docker и про­верь­те, пра­виль­но ли она работает.
$ systemctl restart docker

$ journalctl -r -u docker

Step 6 - После это­го пере­за­гру­зи­те систе­му с помо­щью сле­ду­ю­щих команд.

$ systemctl reboot

$ journalctl -r -u docker

Step 7 - Нако­нец, запу­сти­те atomic-executer, что­бы вер­нуть паке­ты в спи­сок исклю­че­ний yum.

$ atomic-openshift-excluder exclude

Нет тако­го при­нуж­де­ния к обнов­ле­нию поли­ти­ки, ее нуж­но обнов­лять толь­ко в слу­чае реко­мен­да­ции, что мож­но про­ве­рить с помо­щью сле­ду­ю­щей команды.

$ oadm policy reconcile-cluster-roles

В боль­шин­стве слу­ча­ев нам не нуж­но обнов­лять опре­де­ле­ние политики.

Обновление компонентов узла

После завер­ше­ния основ­но­го обнов­ле­ния мы можем при­сту­пить к обнов­ле­нию узлов. Сле­ду­ет иметь в виду, что пери­од обнов­ле­ния дол­жен быть корот­ким, что­бы избе­жать каких-либо про­блем в кластере.

Step 1 - Уда­ли­те все ато­мар­ные паке­ты OpenShift со всех узлов, на кото­рых вы хоти­те выпол­нить обновление.

$ atomic-openshift-excluder unexclude

Step 2 - Затем отклю­чи­те пла­ни­ро­ва­ние узлов перед обновлением.

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

Step 3 - Реп­ли­ци­руй­те весь узел с теку­ще­го хоста на дру­гой хост.

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

Step 4 - Обно­ви­те уста­нов­ку Docker на хосте.

$ yum update docker

Step 5 - Пере­за­пу­сти­те служ­бу Docker, а затем запу­сти­те узел служ­бы Docker.

$systemctl restart docker

$ systemctl restart atomic-openshift-node

Step 6 - Про­верь­те, пра­виль­но ли они оба запустились.

$ journalctl -r -u atomic-openshift-node

Step 7 - После завер­ше­ния обнов­ле­ния пере­за­гру­зи­те узел.

$ systemctl reboot

$ journalctl -r -u docker

Step 8 - Повтор­но вклю­чи­те пла­ни­ро­ва­ние на узлах.

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

Step 9 - Запу­сти­те про­грам­му-испол­ни­тель atomic-openshift, что­бы вер­нуть пакет OpenShift на узел.

$ atomic-openshift-excluder exclude

Step 10 - Нако­нец, про­верь­те, все ли узлы доступны.

 

OpenShift - масштабирование приложений

Когда у нас есть файл, нам нуж­но сохра­нить его в фор­ма­те yaml и выпол­нить сле­ду­ю­щую коман­ду для развертывания.

$ oc create –f <file name>.yaml

При запуске изображения

Мож­но так­же авто­мас­шта­би­ро­вать без фай­ла yaml, исполь­зуя сле­ду­ю­щие oc autoscale коман­да в команд­ной стро­ке oc.

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

deploymentconfig "database" autoscaled

Эта коман­да так­же сге­не­ри­ру­ет файл ана­ло­гич­но­го типа, кото­рый поз­же мож­но будет исполь­зо­вать для справки.

Стратегии развертывания в OpenShift

Стра­те­гия раз­вер­ты­ва­ния в OpenShift опре­де­ля­ет поток раз­вер­ты­ва­ния с исполь­зо­ва­ни­ем раз­лич­ных доступ­ных мето­дов. В OpenShift сле­ду­ю­щиеimportant types of deployment strategies.

• Сколь­зя­щая стратегия
• Вос­со­здать стратегию
• Инди­ви­ду­аль­ная стратегия

Ниже при­ве­ден при­мер фай­ла кон­фи­гу­ра­ции раз­вер­ты­ва­ния, кото­рый исполь­зу­ет­ся в основ­ном для раз­вер­ты­ва­ния на узлах OpenShift.

В при­ве­ден­ном выше фай­ле Deploymentconfig у нас есть стра­те­гия Rolling.

Мы можем исполь­зо­вать сле­ду­ю­щую коман­ду OC для развертывания.

$ oc deploy <deployment_config> --latest

Скользящая стратегия

Стра­те­гия про­кат­ки исполь­зу­ет­ся для после­до­ва­тель­но­го обнов­ле­ния или раз­вер­ты­ва­ния. Этот про­цесс так­же под­дер­жи­ва­ет хуки жиз­нен­но­го цик­ла, кото­рые исполь­зу­ют­ся для внед­ре­ния кода в любой про­цесс развертывания.

Воссоздать стратегию

Эта стра­те­гия раз­вер­ты­ва­ния име­ет неко­то­рые из основ­ных функ­ций стра­те­гии сколь­зя­ще­го раз­вер­ты­ва­ния, а так­же под­дер­жи­ва­ет при­вяз­ку жиз­нен­но­го цикла.

Индивидуальная стратегия

Это очень полез­но, когда кто-то хочет предо­ста­вить свой соб­ствен­ный про­цесс или поток раз­вер­ты­ва­ния. Все настрой­ки могут быть выпол­не­ны в соот­вет­ствии с требованиями.

 

OpenShift - Администрирование

Файлы конфигурации узла

Так выгля­дят фай­лы кон­фи­гу­ра­ции узла. Когда у нас есть эти фай­лы кон­фи­гу­ра­ции, мы можем запу­стить сле­ду­ю­щую коман­ду для созда­ния глав­но­го и узло­во­го серверов.

Управление узлами

В OpenShift у нас есть ути­ли­та команд­ной стро­ки OC, кото­рая в основ­ном исполь­зу­ет­ся для выпол­не­ния всех опе­ра­ций в OpenShift. Мы можем исполь­зо­вать сле­ду­ю­щие коман­ды для управ­ле­ния узлами.

Для перечисления узла

 

Описание подробностей об узле

$ oc describe node <node name>

Удаление узла

$ oc delete node <node name>

Вывод списка модулей на узел

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

Оценка модулей на узле

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

Проверка подлинности конфигурации

В масте­ре OpenShift есть встро­ен­ный сер­вер OAuth, кото­рый мож­но исполь­зо­вать для управ­ле­ния аутен­ти­фи­ка­ци­ей. Все поль­зо­ва­те­ли OpenShift полу­ча­ют токен с это­го сер­ве­ра, кото­рый помо­га­ет им общать­ся с OpenShift API.

В OpenShift есть раз­ные типы уров­ней аутен­ти­фи­ка­ции, кото­рые мож­но настро­ить вме­сте с основ­ным фай­лом конфигурации.

• Поз­во­лять все
• Запре­тить все
• HTPasswd
• LDAP
• Обыч­ная про­вер­ка подлинности
• Заго­ло­вок запроса

При опре­де­ле­нии глав­ной кон­фи­гу­ра­ции мы можем опре­де­лить поли­ти­ку иден­ти­фи­ка­ции, в кото­рой мы можем опре­де­лить тип поли­ти­ки, кото­рую мы хотим использовать.

Позволять все

Поз­во­лять все

Запретить все

Это запре­тит доступ ко всем име­нам поль­зо­ва­те­лей и паролям.

HTPasswd

HTPasswd исполь­зу­ет­ся для про­вер­ки име­ни поль­зо­ва­те­ля и паро­ля по зашиф­ро­ван­но­му паро­лю файла.

Для созда­ния зашиф­ро­ван­но­го фай­ла выпол­ни­те сле­ду­ю­щую команду.

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

Исполь­зуя зашиф­ро­ван­ный файл.

Поставщик удостоверений LDAP

Это исполь­зу­ет­ся для аутен­ти­фи­ка­ции LDAP, в кото­рой сер­вер LDAP игра­ет клю­че­вую роль в аутентификации.

Базовая аутентификация

Это исполь­зу­ет­ся, когда про­вер­ка име­ни поль­зо­ва­те­ля и паро­ля выпол­ня­ет­ся при меж­сер­вер­ной аутен­ти­фи­ка­ции. Аутен­ти­фи­ка­ция защи­ще­на базо­вым URL-адре­сом и пред­став­ле­на ​​в фор­ма­те JSON.

Настройка учетной записи службы

Учет­ные запи­си служб предо­став­ля­ют гиб­кий спо­соб досту­па к OpenShift API, предо­став­ляя имя поль­зо­ва­те­ля и пароль для аутентификации.

Включение учетной записи службы

Учет­ная запись служ­бы исполь­зу­ет пару клю­чей из откры­то­го и закры­то­го клю­чей для аутен­ти­фи­ка­ции. Аутен­ти­фи­ка­ция в API выпол­ня­ет­ся с исполь­зо­ва­ни­ем закры­то­го клю­ча и его про­вер­ка по обще­му ключу.

 

Создание учетной записи службы

Исполь­зуй­те сле­ду­ю­щую коман­ду для созда­ния учет­ной запи­си службы

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

Работа с HTTP-прокси

В боль­шей части про­из­вод­ствен­ной сре­ды пря­мой доступ к Интер­не­ту огра­ни­чен. Они либо не доступ­ны в Интер­не­те, либо доступ­ны через прок­си HTTP или HTTPS. В сре­де OpenShift это опре­де­ле­ние прок­си-маши­ны уста­нав­ли­ва­ет­ся как пере­мен­ная среды.

Это мож­но сде­лать, доба­вив опре­де­ле­ние прок­си к фай­лам master и node, рас­по­ло­жен­ным в /etc/sysconfig. Это похо­же на то, что мы дела­ем для любо­го дру­го­го приложения.

Мастер машина

/ и т.д. / sysconfig / openshift-master

HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/

HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/

NO_PROXY=master.vklnld908.int.example.com

Узловая машина

/ и т.д. / sysconfig / openshift-node

HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/

HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/

NO_PROXY=master.vklnld908.int.example.com

После это­го нам нуж­но пере­за­пу­стить глав­ный и узло­вой машины.

Для Docker Pull

/ и т. д. / sysconfig / докер

HTTP_PROXY = http://USERNAME:PASSWORD@172.10.10.1:8080/

HTTPS_PROXY = https://USERNAME:PASSWORD@172.10.10.1:8080/

NO_PROXY = master.vklnld1446.int.example.com

Что­бы запу­стить модуль в прок­си-сре­де, это мож­но сде­лать с помощью -

Коман­ду сре­ды OC мож­но исполь­зо­вать для обнов­ле­ния суще­ству­ю­щей сре­ды env.

Хранилище OpenShift с NFS

В OpenShift кон­цеп­ция посто­ян­но­го тома и заяв­ки на посто­ян­ный том фор­ми­ру­ют посто­ян­ное хра­ни­ли­ще. Это одна из клю­че­вых кон­цеп­ций, при кото­рой сна­ча­ла созда­ет­ся посто­ян­ный том, а затем запра­ши­ва­ет­ся тот же самый том. Для это­го нам необ­хо­ди­мо иметь доста­точ­но емко­сти и дис­ко­во­го про­стран­ства на базо­вом оборудовании.

Затем с помо­щью коман­ды OC create создай­те посто­ян­ный том.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Полу­че­ние создан­но­го тома.

Создай­те претензию.

$ oc create -f Storage-claim1.yaml

persistentvolume " Storage-clame1 " created

Управление пользователями и ролями

Адми­ни­стри­ро­ва­ние поль­зо­ва­те­лей и ролей исполь­зу­ет­ся для управ­ле­ния поль­зо­ва­те­ля­ми, их досту­пом и кон­тро­лем в раз­лич­ных проектах.

Создание пользователя

Пред­опре­де­лен­ные шаб­ло­ны мож­но исполь­зо­вать для созда­ния новых поль­зо­ва­те­лей в OpenShift.

Исполь­зуй­те oc create –f <имя фай­ла> для созда­ния пользователей.

$ oc create –f vipin.yaml

Исполь­зуй­те сле­ду­ю­щую коман­ду, что­бы уда­лить поль­зо­ва­те­ля в OpenShift.

$ oc delete user <user name>

Ограничение доступа пользователей

ResourceQuotas и LimitRanges исполь­зу­ют­ся для огра­ни­че­ния уров­ней досту­па поль­зо­ва­те­лей. Они исполь­зу­ют­ся для огра­ни­че­ния подов и кон­тей­не­ров в кластере.

 

Создание предложения с использованием указанной выше конфигурации

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

Описание цитаты ресурса

 

Опре­де­ле­ние огра­ни­че­ний кон­тей­не­ра может исполь­зо­вать­ся для огра­ни­че­ния ресур­сов, кото­рые будут исполь­зо­вать­ся раз­вер­ну­ты­ми кон­тей­не­ра­ми. Они исполь­зу­ют­ся для опре­де­ле­ния мак­си­маль­ных и мини­маль­ных огра­ни­че­ний опре­де­лен­ных объектов.

Ограничения пользовательского проекта

Это в основ­ном исполь­зу­ет­ся для коли­че­ства про­ек­тов, кото­рые поль­зо­ва­тель может иметь в любой момент вре­ме­ни. В основ­ном они выпол­ня­ют­ся путем опре­де­ле­ния поль­зо­ва­тель­ских уров­ней в кате­го­ри­ях брон­за, сереб­ро и золото.

Сна­ча­ла нам нуж­но опре­де­лить объ­ект, кото­рый содер­жит зна­че­ние того, сколь­ко про­ек­тов может иметь брон­зо­вая, сереб­ря­ная и золо­тая кате­го­рия. Это необ­хо­ди­мо сде­лать в фай­ле master-confif.yaml.

Пере­за­гру­зи­те глав­ный сервер.

При­сво­е­ние поль­зо­ва­те­лю опре­де­лен­но­го уровня.

$ oc label user vipin level = gold

При необ­хо­ди­мо­сти, уда­ле­ние поль­зо­ва­те­ля из метки.

$ oc label user <user_name> level-

Добав­ле­ние ролей пользователю.

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


Уда­ле­ние роли у пользователя.

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


Добав­ле­ние роли кла­сте­ра пользователю.

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


Уда­ле­ние роли кла­сте­ра у пользователя.

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


Добав­ле­ние роли в группу.

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


Уда­ле­ние роли из группы.

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


Добав­ле­ние роли кла­сте­ра в группу.

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


Уда­ле­ние роли кла­сте­ра из группы.

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

Пользователь для администрирования кластера

Это одна из самых мощ­ных ролей, в кото­рой поль­зо­ва­тель име­ет воз­мож­ность управ­лять всем кла­сте­ром, начи­ная с созда­ния и закан­чи­вая уда­ле­ни­ем кластера.

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

Пользователь с максимальной властью

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

 

OpenShift - Безопасность

Без­опас­ность OpenShift в основ­ном пред­став­ля­ет собой ком­би­на­цию двух ком­по­нен­тов, кото­рые в основ­ном обра­ба­ты­ва­ют огра­ни­че­ния безопасности.

• Огра­ни­че­ния кон­тек­ста без­опас­но­сти (SCC)
• Учет­ная запись службы

Ограничения контекста безопасности (SCC)

Он в основ­ном исполь­зу­ет­ся для огра­ни­че­ния моду­ля, что озна­ча­ет, что он опре­де­ля­ет огра­ни­че­ния для моду­ля, напри­мер, какие дей­ствия он может выпол­нять и ко всем вещам, к кото­рым он может полу­чить доступ в кластере.

OpenShift предо­став­ля­ет набор пред­опре­де­лен­ных SCC, кото­рые может исполь­зо­вать, изме­нять и рас­ши­рять администратор.

 

Если кто-то хочет исполь­зо­вать какой-либо пред­опре­де­лен­ный scc, это мож­но сде­лать, про­сто доба­вив поль­зо­ва­те­ля или груп­пу в груп­пу scc.

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

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

Учетная запись службы

Учет­ные запи­си служб в основ­ном исполь­зу­ют­ся для управ­ле­ния досту­пом к глав­но­му API OpenShift, кото­рый вызы­ва­ет­ся, когда коман­да или запрос запус­ка­ют­ся с любо­го из глав­но­го или узло­во­го компьютера.

Каж­дый раз, когда при­ло­же­нию или про­цес­су тре­бу­ет­ся воз­мож­ность, кото­рая не предо­став­ля­ет­ся огра­ни­чен­ным SCC, вам необ­хо­ди­мо будет создать кон­крет­ную учет­ную запись служ­бы и доба­вить ее в соот­вет­ству­ю­щий SCC. Одна­ко, если SCC не соот­вет­ству­ет вашим тре­бо­ва­ни­ям, луч­ше создать новый SCC, соот­вет­ству­ю­щий вашим тре­бо­ва­ни­ям, а не исполь­зо­вать тот, кото­рый луч­ше все­го под­хо­дит. В кон­це уста­но­ви­те его для кон­фи­гу­ра­ции развертывания.

$ oc create serviceaccount Cadmin

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

Безопасность контейнеров

В OpenShift без­опас­ность кон­тей­не­ров осно­ва­на на кон­цеп­ции того, насколь­ко без­опас­на плат­фор­ма кон­тей­не­ров и где рабо­та­ют кон­тей­не­ры. Когда мы гово­рим о без­опас­но­сти кон­тей­не­ров и о том, о чем необ­хо­ди­мо поза­бо­тить­ся, воз­ни­ка­ет мно­же­ство вещей.

Image Provenance - Име­ет­ся без­опас­ная систе­ма мар­ки­ров­ки, кото­рая точ­но и неопро­вер­жи­мо опре­де­ля­ет, отку­да взя­лись кон­тей­не­ры, рабо­та­ю­щие в про­из­вод­ствен­ной среде.

Security Scanning - Ска­нер изоб­ра­же­ний авто­ма­ти­че­ски про­ве­ря­ет все изоб­ра­же­ния на нали­чие извест­ных уязвимостей.

Auditing - Про­из­вод­ствен­ная сре­да регу­ляр­но про­ве­ря­ет­ся, что­бы убе­дить­ся, что все кон­тей­не­ры осно­ва­ны на совре­мен­ных кон­тей­не­рах, а хосты и кон­тей­не­ры надеж­но настроены.

Isolation and Least Privilege- Кон­тей­не­ры рабо­та­ют с мини­маль­ны­ми ресур­са­ми и при­ви­ле­ги­я­ми, необ­хо­ди­мы­ми для эффек­тив­но­го функ­ци­о­ни­ро­ва­ния. Они не могут чрез­мер­но мешать хосту или дру­гим контейнерам.

Runtime Threat Detection - Воз­мож­ность обна­ру­же­ния актив­ных угроз для кон­тей­нер­ных при­ло­же­ний во вре­мя выпол­не­ния и авто­ма­ти­че­ско­го реа­ги­ро­ва­ния на них.

Access Controls - Моду­ли без­опас­но­сти Linux, такие как AppArmor или SELinux, исполь­зу­ют­ся для обес­пе­че­ния кон­тро­ля доступа.

Суще­ству­ет несколь­ко основ­ных мето­дов архи­ви­ро­ва­ния без­опас­но­сти контейнера.

• Управ­ле­ние досту­пом через oAuth
• Через веб-кон­соль самообслуживания
• По Сер­ти­фи­ка­там платформы

Управление доступом через OAuth

В этом мето­де аутен­ти­фи­ка­ция для досту­па к управ­ле­нию API архи­ви­ру­ет­ся с полу­че­ни­ем защи­щен­но­го токе­на для аутен­ти­фи­ка­ции через сер­ве­ры OAuth, кото­рый встро­ен в глав­ную маши­ну OpenShift. Как адми­ни­стра­тор, вы може­те изме­нять кон­фи­гу­ра­цию сер­ве­ра OAuth.

Допол­ни­тель­ные све­де­ния о настрой­ке сер­ве­ра OAuth см. В гла­ве 5 это­го руководства.

Через веб-консоль самообслуживания

Эта функ­ция без­опас­но­сти веб-кон­со­ли встро­е­на в веб-кон­соль OpenShift. Эта кон­соль гаран­ти­ру­ет, что все коман­ды, рабо­та­ю­щие вме­сте, не име­ют досту­па к дру­гим сре­дам без аутен­ти­фи­ка­ции. Мастер multi-telnet в OpenShift име­ет сле­ду­ю­щие функ­ции безопасности:

• Уро­вень TCL включен
• Исполь­зу­ет сер­ти­фи­кат x.509 для аутентификации
• Защи­ща­ет кон­фи­гу­ра­цию etcd на глав­ном компьютере

По сертификатам платформы

В этом мето­де сер­ти­фи­ка­ты для каж­до­го хоста настра­и­ва­ют­ся во вре­мя уста­нов­ки через Ansible. Посколь­ку он исполь­зу­ет про­то­кол свя­зи HTTPS через Rest API, нам необ­хо­ди­мо защи­щен­ное соеди­не­ние TCL с раз­лич­ны­ми ком­по­нен­та­ми и объ­ек­та­ми. Это пред­опре­де­лен­ные сер­ти­фи­ка­ты, одна­ко мож­но даже уста­но­вить соб­ствен­ный сер­ти­фи­кат в кла­сте­ре масте­ра для досту­па. Во вре­мя пер­во­на­чаль­ной настрой­ки масте­ра поль­зо­ва­тель­ские сер­ти­фи­ка­ты мож­но настро­ить, пере­опре­де­лив суще­ству­ю­щие сер­ти­фи­ка­ты с помо­щьюopenshift_master_overwrite_named_certificates параметр.

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"}]

Для полу­че­ния допол­ни­тель­ных све­де­ний о том, как созда­вать соб­ствен­ные сер­ти­фи­ка­ты, перей­ди­те по сле­ду­ю­щей ссылке -

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

Сетевая безопасность

В OpenShift для свя­зи исполь­зу­ет­ся про­грамм­но-опре­де­ля­е­мая сеть (SDN). Сете­вое про­стран­ство имен исполь­зу­ет­ся для каж­до­го моду­ля в кла­сте­ре, при этом каж­дый модуль полу­ча­ет свой соб­ствен­ный IP-адрес и диа­па­зон пор­тов для полу­че­ния сете­во­го тра­фи­ка. С помо­щью это­го мето­да мож­но изо­ли­ро­вать моду­ли, из-за кото­рых он не может вза­и­мо­дей­ство­вать с моду­ля­ми в дру­гом проекте.

Изоляция проекта

Это может сде­лать адми­ни­стра­тор кла­сте­ра, исполь­зуя сле­ду­ю­щие oadm command из CLI.

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

Это озна­ча­ет, что ука­зан­ные выше про­ек­ты не могут вза­и­мо­дей­ство­вать с дру­ги­ми про­ек­та­ми в кластере.

Объем безопасности

Без­услов­но, объ­ем­ная без­опас­ность озна­ча­ет защи­ту PV и PVC про­ек­тов в кла­сте­ре OpenShift. В OpenShift в основ­ном есть четы­ре раз­де­ла для управ­ле­ния досту­пом к томам.

• Допол­ни­тель­ные группы
• fsGroup
• runAsUser
• seLinuxOptions

Допол­ни­тель­ные груп­пы - Допол­ни­тель­ные груп­пы - это обыч­ные груп­пы Linux. Когда про­цесс выпол­ня­ет­ся в систе­ме, он запус­ка­ет­ся с иден­ти­фи­ка­то­ром поль­зо­ва­те­ля и иден­ти­фи­ка­то­ром груп­пы. Эти груп­пы исполь­зу­ют­ся для управ­ле­ния досту­пом к обще­му хранилищу.

Про­верь­те мон­ти­ро­ва­ние NFS с помо­щью сле­ду­ю­щей команды.
# showmount -e <nfs-server-ip-or-hostname>

Export list for f21-nfs.vm:

/opt/nfs *

Про­верь­те све­де­ния о NFS на сер­ве­ре мон­ти­ро­ва­ния, исполь­зуя сле­ду­ю­щую команду.

/ Opt / NFS / экс­порт досту­пен UID454265 и груп­па 2325.

fsGroup

fsGroup обо­зна­ча­ет груп­пу фай­ло­вой систе­мы, кото­рая исполь­зу­ет­ся для добав­ле­ния допол­ни­тель­ных групп кон­тей­не­ра. Иден­ти­фи­ка­тор груп­пы допол­не­ний исполь­зу­ет­ся для обще­го хра­ни­ли­ща, а fsGroup - для блоч­но­го хранилища.

runAsUser

runAsUser исполь­зу­ет ID поль­зо­ва­те­ля для свя­зи. Это исполь­зу­ет­ся при опре­де­ле­нии обра­за кон­тей­не­ра в опре­де­ле­нии моду­ля. При необ­хо­ди­мо­сти мож­но исполь­зо­вать один иден­ти­фи­ка­тор поль­зо­ва­те­ля во всех контейнерах.

При запус­ке кон­тей­не­ра опре­де­лен­ный иден­ти­фи­ка­тор сопо­став­ля­ет­ся с иден­ти­фи­ка­то­ром вла­дель­ца при экс­пор­те. Если ука­зан­ный иден­ти­фи­ка­тор опре­де­лен сна­ру­жи, он ста­но­вит­ся гло­баль­ным для всех кон­тей­не­ров в моду­ле. Если он опре­де­лен с кон­крет­ным моду­лем, то он ста­но­вит­ся спе­ци­фич­ным для одно­го контейнера.