Учебники

OpenShift — базовая концепция

Декабрь 24, 2018

Прежде чем начать с фактической настройки и развертывания приложений, нам необходимо понять некоторые основные термины и понятия, используемые в 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 внутри.

Стручки и Услуги

Бобы

Pod можно определить как коллекцию контейнера и его хранилище внутри узла кластера 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

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

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

  • Сборка Docker — это процесс, в котором изображения создаются с использованием файла Docker с помощью простой команды сборки Docker.

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

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

Сборка Docker — это процесс, в котором изображения создаются с использованием файла 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"

Потоки изображений — Потоки изображений создаются после вытягивания изображений. Преимущество потока изображений заключается в том, что он ищет обновления для новой версии изображения. Это используется для сравнения любого количества изображений контейнера в формате 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, который можно использовать несколько раз. Он параметризован списком заполнителей, которые используются для создания нескольких объектов. Это может быть использовано для создания чего угодно, начиная от модуля и заканчивая сетью, для которого пользователи имеют право создавать. Список объектов может быть создан, если шаблон из интерфейса CLI или GUI в образе загружен в каталог проекта. 

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 является настройкой по умолчанию для master, у нас по умолчанию используется провайдер идентификации 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, которая используется для валидации пользователя. Это означает, что он проверяет пользователя, который пытается выполнить действие, чтобы определить, авторизован ли пользователь для выполнения этого действия в данном проекте. Это помогает администратору контролировать доступ к проектам.

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

  • правила
  • Роли
  • Наручники

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

  • тождественность
  • действие
  • Наручники

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

131
Share: