OpenShift-기본 개념

애플리케이션의 실제 설정 및 배포를 시작하기 전에 OpenShift V3에서 사용되는 몇 가지 기본 용어와 개념을 이해해야합니다.

컨테이너 및 이미지

이미지

이들은 Docker 이미지로 구성된 OpenShift의 기본 구성 요소입니다. 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에서 서비스는 새 인스턴스를 생성하기 위해 OpenShift 마스터의 apiService에 신명을 게시 할 수있는 REST 객체입니다.

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의 표준 개체로 정의됩니다. 여러 개체를 만드는 데 사용되는 자리 표시 자 목록으로 매개 변수화됩니다. 이는 포드에서 네트워킹에 이르기까지 사용자에게 생성 권한이있는 모든 것을 생성하는 데 사용할 수 있습니다. 이미지의 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는 마스터의 기본 설정으로 제공되므로 기본적으로 모든 ID 공급자 허용이 사용됩니다. 구성 할 수있는 다른 ID 공급자가 있습니다./etc/openshift/master/master-config.yaml.

OAuth에는 다양한 유형의 ID 공급자가 있습니다.

  • 모두 허용
  • 모두 거부
  • 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

정책 사용-

  • 클러스터 정책
  • 지역 정책