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

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

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

Картинки

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

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

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

$ oc create –f Tesing_for_Image_pull

Контейнер

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

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

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

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

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

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

Стручки

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

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

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

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

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

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

$ oc create –f apache.yml

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

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

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

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

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

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

Строит

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

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

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

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

  • Docker Build - Это процесс, в котором образы создаются с использованием файла Docker путем выполнения простой команды сборки Docker.

  • Custom Build - Это сборки, которые используются для создания базовых образов Docker.

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

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

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

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

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

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

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

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

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

Маршруты

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

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

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

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

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

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

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

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

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

$ oc describe service Openshift-Rservice

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

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

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

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

Шаблоны

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

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

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

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

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

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

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

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

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

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

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

HTPasswd

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

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

Авторизация

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

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

  • Rules
  • Roles
  • Bindings

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

  • Identity
  • Action
  • Bindings

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

  • Кластерная политика
  • Местная политика
ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved