OpenShift

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 - Типы

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

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

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

Application - Они про­сто отно­сят­ся к при­ло­же­нию или любо­му при­ло­же­нию инте­гра­ции, кото­рое будет раз­вер­ну­то и запу­ще­но в сре­де OpenShift.

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

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

OpenShift Online - Это пуб­лич­ный PaaS как сер­вис, раз­ме­щен­ный на AWS.

OpenShift Enterprise - это уси­лен­ная вер­сия OpenShift с лицен­зи­я­ми неза­ви­си­мых постав­щи­ков про­грамм­но­го обес­пе­че­ния и поставщиков.

OpenShift Online

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

Настройка учетной записи в Red Hat OpenShift Online

Step 1 - Зай­ди­те в бра­у­зер и посе­ти­те сайт https://manage.openshift.com/

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 - это мно­го­уров­не­вая систе­ма, в кото­рой каж­дый уро­вень тес­но свя­зан с дру­гим уров­нем с помо­щью Kubernetes и кла­сте­ра Docker. Архи­тек­ту­ра OpenShift спро­ек­ти­ро­ва­на таким обра­зом, что она может под­дер­жи­вать и управ­лять кон­тей­не­ра­ми Docker, кото­рые раз­ме­ща­ют­ся поверх всех сло­ев с исполь­зо­ва­ни­ем Kubernetes. В отли­чие от более ран­ней вер­сии OpenShift V2, новая вер­сия OpenShift V3 под­дер­жи­ва­ет кон­тей­нер­ную инфра­струк­ту­ру. В этой моде­ли Docker помо­га­ет в созда­нии лег­ких кон­тей­не­ров на базе Linux, а Kubernetes под­дер­жи­ва­ет зада­чу оркест­ров­ки и управ­ле­ния кон­тей­не­ра­ми на несколь­ких хостах.

Компоненты OpenShift

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

Компоненты Kubernetes Master Machine

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

API Server- Kubernetes - это сер­вер API, кото­рый обес­пе­чи­ва­ет все опе­ра­ции в кла­сте­ре с помо­щью API. Сер­вер API реа­ли­зу­ет интер­фейс, кото­рый озна­ча­ет, что раз­лич­ные инстру­мен­ты и биб­лио­те­ки могут лег­ко вза­и­мо­дей­ство­вать с ним. Kubeconfig - это пакет вме­сте с инстру­мен­та­ми на сто­роне сер­ве­ра, кото­рые мож­но исполь­зо­вать для свя­зи. Он предо­став­ля­ет Kubernetes API ».

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

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

Компоненты узла Kubernetes

Ниже при­ве­де­ны клю­че­вые ком­по­нен­ты сер­ве­ра Node, кото­рые необ­хо­ди­мы для свя­зи с масте­ром Kubernetes.

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

Kubelet Service- Это неболь­шая служ­ба в каж­дом узле, кото­рая отве­ча­ет за пере­да­чу инфор­ма­ции в служ­бу уров­ня управ­ле­ния и из нее. Он вза­и­мо­дей­ству­ет с хра­ни­ли­щем etcd для чте­ния дета­лей кон­фи­гу­ра­ции и зна­че­ний Рай­та. Он вза­и­мо­дей­ству­ет с глав­ным ком­по­нен­том для полу­че­ния команд и рабо­ты. Затем про­цесс kubelet берет на себя ответ­ствен­ность за под­дер­жа­ние состо­я­ния рабо­ты и сер­ве­ра узла. Он управ­ля­ет сете­вы­ми пра­ви­ла­ми, пере­ад­ре­са­ци­ей пор­тов и т. Д.

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

Интегрированный реестр контейнеров OpenShift

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

Часто используемые термины

Image- Обра­зы Kubernetes (Docker) явля­ют­ся клю­че­вы­ми стро­и­тель­ны­ми бло­ка­ми кон­тей­нер­ной инфра­струк­ту­ры. На дан­ный момент Kubernetes под­дер­жи­ва­ет толь­ко обра­зы Docker. У каж­до­го кон­тей­не­ра в моду­ле есть свой образ Docker, рабо­та­ю­щий внут­ри него. При настрой­ке моду­ля свой­ство image в фай­ле кон­фи­гу­ра­ции име­ет тот же син­так­сис, что и коман­да Docker.

Project - Их мож­но опре­де­лить как пере­име­но­ван­ную вер­сию доме­на, кото­рая при­сут­ство­ва­ла в более ран­ней вер­сии OpenShift V2.

Container - Это те, кото­рые созда­ют­ся после раз­вер­ты­ва­ния обра­за на узле кла­сте­ра Kubernetes.

Node- Узел - это рабо­чая маши­на в кла­сте­ре Kubernetes, так­же извест­ная как миньон для масте­ра. Это рабо­чие еди­ни­цы, кото­рые могут быть физи­че­ски­ми, вир­ту­аль­ны­ми или облачными.

Pod- Pod - это набор кон­тей­не­ров и их хра­ни­ли­ще внут­ри узла кла­сте­ра Kubernetes. Мож­но создать кон­тей­нер с несколь­ки­ми кон­тей­не­ра­ми внут­ри. Напри­мер, хра­не­ние кон­тей­не­ра базы дан­ных и кон­тей­не­ра веб-сер­ве­ра внут­ри модуля.

 

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 у нас есть несколь­ко мето­дов авто­ма­ти­за­ции кон­вей­е­ра сбор­ки. Для это­го нам нуж­но создать ресурс BuildConfig для опи­са­ния про­цес­са сбор­ки. Поток в BuildConfig мож­но срав­нить с опре­де­ле­ни­ем зада­ния в опре­де­ле­нии зада­ния Jenkins. При созда­нии про­цес­са сбор­ки мы долж­ны выбрать стра­те­гию сборки.

Файл BuildConfig

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Using build pipeline

 

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

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

Настройка OpenShift CLI

Что­бы настро­ить кли­ент OC в дру­гой опе­ра­ци­он­ной систе­ме, нам нуж­но выпол­нить дру­гую после­до­ва­тель­ность шагов.

OC Client для Windows

Step 1 - Загру­зи­те oc cli по сле­ду­ю­щей ссыл­ке https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Step 2 - Разар­хи­ви­руй­те пакет по целе­во­му пути на машине.

Step 3 - Отре­дак­ти­руй­те пере­мен­ную сре­ды пути в системе.

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 - масштабирование приложений

Авто­мас­шта­би­ро­ва­ние - это функ­ция OpenShift, при кото­рой раз­вер­ну­тые при­ло­же­ния могут мас­шта­би­ро­вать­ся и умень­шать­ся по мере необ­хо­ди­мо­сти в соот­вет­ствии с опре­де­лен­ны­ми спе­ци­фи­ка­ци­я­ми. В при­ло­же­нии OpenShift авто­мас­шта­би­ро­ва­ние так­же извест­но как авто­мас­шта­би­ро­ва­ние пода. Есть дваtypes of application scaling сле­ду­ю­щим образом.

Вертикальное масштабирование

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

Горизонтальное масштабирование

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

В OpenShift есть two methods to enable the scaling feature.

  • Исполь­зо­ва­ние фай­ла кон­фи­гу­ра­ции развертывания
  • При запус­ке образа

Использование файла конфигурации развертывания

В этом мето­де функ­ция мас­шта­би­ро­ва­ния вклю­ча­ет­ся через yaml-файл кон­фи­гу­ра­ции раз­вер­ты­ва­ния. Для это­го исполь­зу­ет­ся коман­да OC autoscale с мини­маль­ным и мак­си­маль­ным коли­че­ством реплик, кото­рые долж­ны выпол­нять­ся в любой задан­ный момент вре­ме­ни в кла­сте­ре. Нам нуж­но опре­де­ле­ние объ­ек­та для созда­ния авто­мас­шта­би­ро­ва­ния. Ниже при­ве­ден при­мер фай­ла опре­де­ле­ния авто­мас­шта­би­ро­ва­ния модуля.

Когда у нас есть файл, нам нуж­но сохра­нить его в фор­ма­те 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 нам нуж­но исполь­зо­вать коман­ду start вме­сте с OC для загруз­ки ново­го сер­ве­ра. При запус­ке ново­го масте­ра нам нуж­но исполь­зо­вать мастер вме­сте с коман­дой запус­ка, тогда как при запус­ке ново­го узла нам нуж­но исполь­зо­вать узел вме­сте с коман­дой запус­ка. Для это­го нам необ­хо­ди­мо создать фай­лы кон­фи­гу­ра­ции как для масте­ра, так и для узлов. Мы можем создать базо­вый файл кон­фи­гу­ра­ции для масте­ра и узла, исполь­зуя сле­ду­ю­щую команду.

Для главного файла конфигурации

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

Для файла конфигурации узла

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

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

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

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

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

В 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

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