Openshift-basic-concept

提供：Dev Guides
移動先:案内、検索

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クラスターにデプロイされるときに作成されます。 構成を定義するときに、構成ファイルにコンテナセクションを定義します。 1つのコンテナ内で複数のイメージを実行でき、クラスターノードで実行されているすべてのコンテナは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の2つのイメージが内部にあるマルチコンテナーポッドを定義しました。

ポッドとサービス

Pods

Podは、OpenShift（Kubernetes）クラスターのノード内のコンテナーとそのストレージのコレクションとして定義できます。 一般に、単一のコンテナポッドから複数のコンテナポッドまで、2種類のポッドがあります。

シングルコンテナポッド-これらは、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

マルチコンテナポッド-マルチコンテナポッドは、内部で複数のコンテナが実行されているものです。 これらは、次のように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オブジェクトであり、その定義をOpenShiftマスターのapiServiceにポストして、新しいインスタンスを作成できます。 

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

ビルドとストリーム

ビルド

OpenShiftでは、ビルドはイメージをコンテナーに変換するプロセスです。 ソースコードを画像に変換する処理です。 このビルドプロセスは、イメージ化するソースコードをビルドする事前定義された戦略で機能します。

ビルドは、複数の戦略とソースを処理します。

構築戦略

  • Source to Image -これは基本的に、再現可能な画像の構築に役立つツールです。 これらのイメージは、常にDocker runコマンドを使用して実行する準備ができた段階にあります。
  • * Dockerビルド*-これは、単純なDockerビルドコマンドを実行して、Dockerファイルを使用してイメージをビルドするプロセスです。
  • カスタムビルド-これらは、ベース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 adminによってデプロイされるルーターを使用してルートが作成されます。 ルーターは、HTTP（80）およびhttps（443）ポートを外部アプリケーションにバインドするために使用されます。

ルートがサポートするプロトコルの種類は次のとおりです-

  • HTTP
  • HTTPS *TSLおよびWebソケット

サービスを構成する場合、セレクターを使用してサービスを構成し、そのサービスを使用するエンドポイントを見つけます。 以下は、適切なプロトコルを使用してサービスとそのサービスのルーティングを作成する方法の例です。 

{
   "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はマスターのデフォルトのセットアップとして提供されるため、デフォルトで使用されるAllow All IDプロバイダーがあります。*/etc/openshift/master/master-config.yaml *で構成できるさまざまなIDプロバイダーが存在します。

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マスターの機能であり、ユーザーの検証を検証するために使用されます。 つまり、アクションを実行しようとしているユーザーをチェックして、特定のプロジェクトでそのアクションを実行する権限があるかどうかを確認します。 これにより、管理者はプロジェクトへのアクセスを制御できます。

認可ポリシーは次を使用して制御されます-

  • 規則
  • 役割
  • バインディング

認可の評価は次を使用して行われます-

  • 身元
  • アクション
  • バインディング

ポリシーを使用する-

  • クラスターポリシー
  • ローカルポリシー
「https://www.finddevguides.com/index.php?title=Openshift-basic-concept&oldid=25956」から取得
Powered by MediaWiki