Openshift-quick-guide
OpenShift-概要
OpenShiftは、Red Hatがホストするクラウド開発サービスとしてのプラットフォーム（PaaS）です。 これは、アプリケーションを作成、テスト、実行し、最終的にクラウドに展開するために使用される、オープンソースのクラウドベースのユーザーフレンドリーなプラットフォームです。
OpenShiftは、Node.js、Ruby、Python、Perl、Javaなどのさまざまな言語で記述されたアプリケーションを管理できます。 OpenShiftの主要な機能の1つは拡張可能であり、ユーザーが他の言語で記述されたアプリケーションをサポートするのに役立ちます。
OpenShiftは、抽象化レイヤーとして仮想化のさまざまな概念を備えています。 OpenShiftの背後にある基本概念は、仮想化に基づいています。
仮想化
一般に、仮想化は、システム、ストレージ、またはオペレーティングシステムから始まる物理的または実際のバージョンではなく、仮想システムの作成として定義できます。 仮想化の主な目標は、ITインフラストラクチャのスケーラビリティと信頼性を高めることです。 仮想化の概念は何十年も前から存在しており、今日のIT業界の進化に伴い、システムレベル、ハードウェアレベル、サーバーレベルの仮想化に至る幅広い層に適用できます。
使い方
これは、アプリケーションまたはオペレーティングシステムが実際の物理層から抽象化された技術として説明できます。 仮想化テクノロジーの主な用途の1つはサーバーの仮想化であり、ハイパーバイザーと呼ばれるソフトウェアを使用して、基盤となるハードウェアからレイヤーを抽象化します。 仮想化で実行されているオペレーティングシステムのパフォーマンスは、物理ハードウェアで実行されているときと同等です。 ただし、実行中のシステムとアプリケーションのほとんどは、基盤となるハードウェアの使用を必要としないため、仮想化の概念が一般的です。
物理アーキテクチャと仮想アーキテクチャ
仮想化の種類
- アプリケーションの仮想化-この方法では、アプリケーションは基盤となるオペレーティングシステムから抽象化されます。 この方法は、アプリケーションをその下のオペレーティングシステムに依存せずに単独で実行できる非常に便利です。
- デスクトップ仮想化-この方法は、デスクのシンクライアントを使用してデスクトップにリモートでアクセスできるワークステーションの負荷を軽減するために使用されます。 この方法では、デスクトップはほとんどデータセンターで実行されます。 典型的な例は、ほとんどの組織で使用されている仮想デスクトップイメージ（VDI）です。
- データ仮想化-これは、データおよびデータ管理の従来の方法を抽象化し、それを回避する方法です。
- サーバー仮想化-この方法では、物理サーバー、プロセス、およびオペレーティングシステムを含むサーバー関連のリソースが仮想化されます。 この抽象化を可能にするソフトウェアは、しばしばハイパーバイザーと呼ばれます。
- ストレージの仮想化-複数のストレージデバイスを単一の中央コンソールから管理される単一のストレージデバイスにプールするプロセスです。
- ネットワーク仮想化-利用可能なすべてのネットワークリソースを、それぞれ独立した利用可能な帯域幅とチャネルに分割することにより結合する方法です。
OpenShift
OpenShiftは、クラウド対応のサービスとしてのプラットフォーム（PaaS）です。 これは、組織が従来のアプリケーションインフラストラクチャとプラットフォームを物理的な仮想メディアからクラウドに移行するのに役立つオープンソーステクノロジーです。
OpenShiftは非常に多様なアプリケーションをサポートしており、OpenShiftクラウドプラットフォームで簡単に開発および展開できます。 OpenShiftは基本的に、開発者とユーザー向けに3種類のプラットフォームをサポートしています。
サービスとしてのインフラストラクチャ（IaaS）
この形式では、サービスプロバイダーはハードウェアレベルの仮想マシンに事前定義された仮想ハードウェア構成を提供します。 このスペースには、AWS Googleクラウド、Rackspaceなど、複数の競合他社が存在します。
セットアップと投資の長い手順の後にIaaSを使用することの主な欠点は、オペレーティングシステムとサーバーパッケージのインストールと保守、インフラストラクチャのネットワークの管理、および基本的なシステム管理の面倒を見る責任があることです。
サービスとしてのソフトウェア（SaaS）
SaaSを使用すると、基盤となるインフラストラクチャに対する心配が最も少なくなります。 プラグアンドプレイと同じくらい簡単で、ユーザーはサービスにサインアップして使用を開始するだけです。 このセットアップの主な欠点は、サービスプロバイダーが許可している最小限のカスタマイズしか実行できないことです。 SaaSの最も一般的な例の1つはGmailで、ユーザーはログインして使用を開始するだけです。 ユーザーは自分のアカウントにいくつかの小さな変更を加えることもできます。 ただし、開発者の観点からはあまり有用ではありません。
サービスとしてのプラットフォーム（PaaS）
SaaSとIaaSの間の中間層と考えることができます。 PaaS評価の主な対象は、いくつかのコマンドで開発環境をスピンアップできる開発者です。 これらの環境は、データベースを備えたWebアプリケーションサーバーを持つことから、すべての開発ニーズを満たすことができるように設計されています。 これを行うには、1つのコマンドが必要なだけで、サービスプロバイダーが処理を行います。
OpenShiftを使用する理由
OpenShiftは、基盤となるオペレーティングシステムを気にすることなく、エンタープライズユニットがクラウド上でアプリケーションをホストするための共通プラットフォームを提供します。 これにより、クラウドでのアプリケーションの使用、開発、展開が非常に簡単になります。 主な機能の1つは、あらゆる種類の開発とテストのために管理されたハードウェアとネットワークリソースを提供することです。 OpenShiftを使用すると、PaaS開発者は必要な環境を仕様で自由に設計できます。
OpenShiftは、サービスプランに関して、異なる種類のサービスレベル契約を提供します。
無料-このプランは3年間に制限されており、それぞれ1 GBのスペースがあります。
ブロンズ-このプランには3年間が含まれ、1年間に1GBのスペースで最大16年間まで拡張されます。
スライバ-これは16年間のブロンズ計画ですが、追加容量なしで6GBのストレージ容量があります。
上記の機能以外に、OpenShiftはOpenShift Enterpriseと呼ばれるオンプレミスバージョンも提供します。 OpenShiftでは、開発者はスケーラブルおよび非スケーラブルなアプリケーションを設計するために活用し、これらの設計はHAproxyサーバーを使用して実装されます。
特徴
OpenShiftには複数の機能がサポートされています。 それらのいくつかは-
- 多言語サポート
- 複数データベースのサポート
- 拡張可能なカートリッジシステム
- ソースコードバージョン管理
- ワンクリック展開
- マルチ環境サポート
- 標準化された開発者のワークフロー
- 依存関係とビルド管理
- 自動アプリケーションスケーリング
- レスポンシブWebコンソール
- 豊富なコマンドラインツールセット
- アプリケーションへのリモートSSHログイン
- REST APIサポート
- セルフサービスオンデマンドアプリケーションスタック
- 組み込みのデータベースサービス
- 継続的な統合とリリース管理
- IDEの統合
- アプリケーションのリモートデバッグ
OpenShift-タイプ
OpenShiftは、主にギアとカートリッジの概念に基づいたOpenShift V2という名前のベースから誕生しました。各コンポーネントは、マシンの作成からアプリケーションのデプロイまで、アプリケーションの構築からデプロイまでの仕様を備えています。
カートリッジ-それらは、環境がそれらを実行するために必要なアプリケーションのタイプと、このセクションで満たされるすべての依存関係から開始する新しいアプリケーションを構築する焦点でした。
ギア-リソース、メモリ、およびCPUに関する特定の仕様を持つベアメタルマシンまたはサーバーとして定義できます。 これらは、アプリケーションを実行するための基本単位と見なされていました。
アプリケーション-これらは、OpenShift環境でデプロイおよび実行されるアプリケーションまたは統合アプリケーションを指します。
このセクションの詳細に進むにつれて、OpenShiftのさまざまな形式と製品について説明します。 以前は、OpenShiftには3つのメジャーバージョンがありました。
*OpenShift Origin* -これはOpenShiftのコミュニティ追加またはオープンソースバージョンでした。 他の2つのバージョンのアップストリームプロジェクトとしても知られていました。*OpenShift Online* -AWSでホストされるサービスとしての公開PaaSです。*OpenShift Enterprise* -ISVおよびベンダーライセンスを備えたOpenShiftの強化バージョンです。OpenShift Online
OpenShift onlineは、パブリッククラウド上でコンテナー化されたアプリケーションを迅速に構築、デプロイ、およびスケーリングできるOpenShiftコミュニティの提供です。 Red Hatのパブリッククラウドアプリケーション開発およびホスティングプラットフォームであり、アプリケーションの自動プロビジョニング、管理、スケーリングを可能にし、開発者がアプリケーションロジックの作成に集中できるようにします。
Red Hat OpenShift Onlineでのアカウントのセットアップ
- ステップ1 *-ブラウザーに移動して、サイトhttps://manage.openshift.com/にアクセスします
- ステップ2 *-Red Hatアカウントを持っている場合は、次のURLを使用してRed HatログインIDとパスワードを使用してOpenShiftアカウントにログインします。 https://developers.redhat.com/auth/realms/rhd/protocol/openid-connect/auth?client_id=oso&redirect_uri=https%3A%2F%2Fmanage.openshift.com%2Faccounts%2Fauth%2Fkeycloak%2Fcallback&response_type=code&scope= openid + profile + email＆state = b73466d00a5b3b4028ca95eac867e2dd [https://developers.redhat.com]
- ステップ3 *-Red Hatアカウントにログインしていない場合は、次のリンクを使用してOpenShiftオンラインサービスにサインアップします。
ログイン後、次のページが表示されます。
すべての準備が整ったら、次のスクリーンショットに示すように、Red Hatは基本的なアカウントの詳細を表示します。
最後に、ログインすると、次のページが表示されます。
OpenShift Container Platform
OpenShiftコンテナプラットフォームは、開発およびIT運用チームなどの複数のチームがコンテナ化されたインフラストラクチャを構築および展開するのに役立つエンタープライズプラットフォームです。 OpenShiftで構築されたすべてのコンテナーは、非常に信頼性の高いDockerコンテナー化テクノロジーを使用しており、パブリックにホストされているクラウドプラットフォームのデータセンターに展開できます。
OpenShiftコンテナプラットフォームは、正式にはOpenShift Enterprisesと呼ばれていました。 これは、Dockerを使用したアプリケーションコンテナのコアコンセプトに基づいて構築された、サービスとしてのRed Hatオンプレミスプライベートプラットフォームであり、オーケストレーションと管理はKubernetesによって管理されます。
つまり、OpenShiftはDockerとKubernetesをエンタープライズレベルに統合します。 エンタープライズユニットが希望するインフラストラクチャで申請者を展開および管理するためのコンテナプラットフォームソフトウェアです。 たとえば、AWSインスタンスでOpenShiftインスタンスをホストします。
OpenShiftコンテナプラットフォームは、* 2つのパッケージレベル*で利用できます。
*OpenShift Container Local* -これは、ローカルマシンでアプリケーションをデプロイおよびテストしたい開発者向けです。 このパッケージは、主にアプリケーションの開発とテストのために開発チームが使用します。*OpenShift Container Lab* -これは、開発からプリプロダクション環境への展開までのアプリケーションの拡張評価用に設計されています。OpenShift Dedicated
これは、OpenShiftのポートフォリオに追加された別の製品であり、お客様が選択したパブリッククラウドのいずれかでコンテナー化されたプラットフォームをホストするという選択肢があります。 これにより、エンドユーザーは、ニーズを満たすクラウド上でOpenShiftを使用できるマルチクラウド製品の真の感覚を得ることができます。
これは、エンドユーザーがOpenShiftを使用してテストデプロイを構築し、クラウドでホストされているOpenShiftでアプリケーションを実行できるRed Hatの最新製品の1つです。
OpenShift Dedicatedの機能
OpenShift専用は、パブリッククラウド上のカスタマイズされたソリューションアプリケーションプラットフォームを提供し、OpenShift 3テクノロジーから継承されます。
- 拡張可能でオープン-これはDockerのオープンコンセプトに基づいて構築されており、必要に応じて必要に応じて使用できるため、クラウドにデプロイされます。
- 移植性-Dockerを使用して構築されているため、Docker上で実行されるアプリケーションは、ある場所から別の場所（Dockerがサポートされている場所）に簡単に出荷できます。
- オーケストレーション-OpenShift 3では、コンテナオーケストレーションとクラスター管理の主要機能の1つが、OpenShiftバージョン3で提供されるようになったKubernetesを使用してサポートされます。
- 自動化-このバージョンのOpenShiftは、ソースコード管理、ビルドの自動化、および展開の自動化の機能を備えており、サービスプロバイダーとしてのプラットフォームとして市場で非常に人気があります。
OpenShiftの競合他社
*Google App Engine* -これは、Webアプリケーションを開発およびホストするためのGoogleの無料プラットフォームです。 Googleのアプリエンジンは、迅速な開発および展開プラットフォームを提供します。*Microsoft Azure* -Azureクラウドは、Microsoftのデータセンターでホストされています。*Amazon Elastic Cloud Compute* -Amazonが提供する組み込みサービスであり、クラウド上でスケーラブルなWebアプリケーションの開発とホスティングを支援します。*Cloud Foundry* -Java、Ruby、Python、およびNode.jsアプリケーション向けのオープンソースPaaSプラットフォームです。*CloudStack* -ApacheのCloudStackは、Citrixによって開発されたプロジェクトであり、OpenShiftとOpenStackの直接の競合他社になるように設計されています。*OpenStack* -Red Hatがクラウドコンピューティング用に提供する別のクラウドテクノロジー。*Kubernetes* -Dockerコンテナを管理するために構築された直接的なオーケストレーションおよびクラスター管理テクノロジーです。OpenShift-アーキテクチャ
OpenShiftは、KubernetesとDockerクラスターを使用して、各レイヤーが他のレイヤーと緊密にバインドされているレイヤードシステムです。 OpenShiftのアーキテクチャは、Kubernetesを使用してすべてのレイヤーの上にホストされるDockerコンテナーをサポートおよび管理できるように設計されています。 OpenShift V2の以前のバージョンとは異なり、OpenShift V3の新しいバージョンはコンテナー化されたインフラストラクチャをサポートします。 このモデルでは、Dockerは軽量のLinuxベースのコンテナーの作成を支援し、Kubernetesは複数のホスト上のコンテナーを調整および管理するタスクをサポートします。
OpenShift Container Platform Architecture
OpenShiftのコンポーネント
OpenShiftアーキテクチャの重要なコンポーネントの1つは、Kubernetesでコンテナー化されたインフラストラクチャを管理することです。 Kubernetesは、インフラストラクチャの展開と管理を担当しています。 Kubernetesクラスターには、複数のマスターと複数のノードを含めることができます。これにより、セットアップで障害が発生しないことが保証されます。
Kubernetes Master Machineコンポーネント
*Etcd* -クラスター内の各ノードで使用できる構成情報を保存します。 これは、複数のノードに分散できる高可用性キーバリューストアです。 機密情報が含まれている可能性があるため、Kubernetes APIサーバーからのみアクセスできるようにする必要があります。 これは、すべてにアクセス可能な分散キー値ストアです。APIサーバー*-Kubernetesは、APIを使用してクラスターでのすべての操作を提供するAPIサーバーです。 APIサーバーは、さまざまなツールやライブラリが簡単に通信できるインターフェースを実装しています。 kubeconfigは、通信に使用できるサーバー側ツールと一緒のパッケージです。 Kubernetes APIを公開しています。」
*Controller Manager* -このコンポーネントは、クラスターの状態を調整し、タスクを実行するほとんどのコレクターを担当します。 これは、非終了ループで実行され、APIサーバーへの情報の収集と送信を担当するデーモンと見なすことができます。 クラスターの共有状態を取得し、サーバーの現在のステータスを目的の状態にするために変更を行います。 キーコントローラーは、レプリケーションコントローラー、エンドポイントコントローラー、名前空間コントローラー、およびサービスアカウントコントローラーです。 コントローラーマネージャーは、さまざまな種類のコントローラーを実行して、ノード、エンドポイントなどを処理します。
スケジューラ-Kubernetesマスターの重要なコンポーネントです。 これは、ワークロードの分散を担当するマスターのサービスです。 クラスタノードの作業負荷の使用率を追跡し、リソースが利用可能なワークロードを配置し、ワークロードを受け入れる役割を果たします。 言い換えれば、これはポッドを利用可能なノードに割り当てる責任があるメカニズムです。 スケジューラーは、ワークロードの使用率と、新しいノードへのポッドの割り当てを担当します。
Kubernetesノードのコンポーネント
以下は、Kubernetesマスターと通信するために必要なNodeサーバーの主要コンポーネントです。
*Docker* -各ノードの最初の要件は、比較的孤立しているが軽量の動作環境でカプセル化されたアプリケーションコンテナを実行するのに役立つDockerです。Kubeletサービス*-これは各ノードの小さなサービスであり、コントロールプレーンサービスとの間で情報を中継します。 etcdストアと対話して、構成の詳細とWrightの値を読み取ります。 これは、コマンドを受信して作業するためにマスターコンポーネントと通信します。 その後、kubeletプロセスは、作業の状態とノードサーバーを維持する責任を負います。 ネットワークルール、ポート転送などを管理します。
*Kubernetes Proxy Service* -これは各ノードで実行されるプロキシサービスであり、外部ホストでサービスを利用できるようにするのに役立ちます。 リクエストを正しいコンテナに転送するのに役立ちます。 Kubernetes Proxy Serviceは、プリミティブロードバランシングを実行できます。 これにより、ネットワーク環境が予測可能でアクセスしやすくなりますが、同時に隔離されます。 ノード上のポッド、ボリューム、シークレットを管理し、新しいコンテナの健康診断などを作成します。
統合OpenShift Container Registry
OpenShiftコンテナレジストリは、Dockerイメージの格納に使用されるRed Hatの組み込みストレージユニットです。 OpenShiftの最新の統合バージョンでは、OpenShift内部ストレージに画像を表示するためのユーザーインターフェイスが用意されています。 これらのレジストリは、指定されたタグを持つイメージを保持することができます。タグは、後でコンテナを構築するために使用されます。
よく使用される用語
画像-Kubernetes（Docker）画像は、コンテナ化されたインフラストラクチャの重要な構成要素です。 現在、KubernetesはDockerイメージのみをサポートしています。 ポッドの各コンテナーには、その内部で実行されるDockerイメージがあります。 ポッドを設定する場合、設定ファイルの画像プロパティの構文はDockerコマンドと同じです。
プロジェクト-OpenShift V2の以前のバージョンに存在していたドメインの名前を変更したバージョンとして定義できます。
コンテナ-イメージがKubernetesクラスタノードにデプロイされた後に作成されるものです。
ノード-ノードは、マスターのミニオンとしても知られるKubernetesクラスター内の稼働中のマシンです。 これらは、物理インスタンス、VMインスタンス、またはクラウドインスタンスにすることができる作業単位です。
- ポッド-ポッドは、Kubernetesクラスターのノード内のコンテナーとそのストレージのコレクションです。 内部に複数のコンテナを持つポッドを作成することが可能です。 たとえば、データベースコンテナーとWebサーバーコンテナーをポッド内に保持します。
OpenShift-環境設定
この章では、OpenShiftの環境設定について学習します。
システム要件
エンタープライズOpenShiftをセットアップするには、アクティブなRed Hatアカウントが必要です。 OpenShiftはKubernetesマスターおよびノードアーキテクチャで動作するため、両方を別々のマシンでセットアップする必要があります。1台のマシンがマスターとして機能し、他のマシンがノードで機能します。 両方をセットアップするには、最小システム要件があります。
マスターマシン構成
マスターマシン構成の最小システム要件は次のとおりです。
- 物理、仮想、またはクラウド環境のいずれかでホストされるベースマシン。
- そのインスタンスに必要なパッケージを備えた少なくともLinux 7。
- 2 CPUコア。
- 少なくとも8 GBのRAM。
- 30 GBの内蔵ハードディスクメモリ。
ノードマシン構成
- マスターマシンに指定された物理または仮想ベースイメージ。
- マシン上の少なくともLinux 7。
- Dockerは、バージョン1.6以上でインストールされています。
- 1 CPUコア。
- 8 GBのRAM
- 画像をホストするための15 GBのハードディスクと画像を保存するための15 GB。
OpenShiftセットアップのステップバイステップガイド
以下の説明では、OpenShiftラボ環境をセットアップします。これは、後でより大きなクラスターに拡張できます。 OpenShiftにはマスターとノードのセットアップが必要であるため、クラウド、物理、または仮想マシンのいずれかでホストされる少なくとも2つのマシンが必要になります。
- ステップ1 *-最初に両方のマシンにLinuxをインストールします。Linux7が最小バージョンである必要があります。 これは、アクティブな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をセットアップすることです。
- ステップ2 *-ローカルネットワーク上でのみ安全でない通信を許可するようにDockerを構成します。 このためには、/etc/sysconfig内のDockerファイルを編集します。 ファイルが存在しない場合は、手動で作成する必要があります。
# vi/etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24マスターマシンでDockerを構成したら、両方のマシン間でパスワードなしの通信をセットアップする必要があります。 このために、公開キーと秘密キーの認証を使用します。
- ステップ3 *-マスターマシンでキーを生成し、id_rsa.pubキーをノードマシンの認証キーファイルにコピーします。これは、次のコマンドを使用して実行できます。
# ssh-keygen# ssh-copy-id -i .ssh/id_rsa.pub [email protected]上記のセットアップをすべて完了したら、次はマスターマシンでOpenShiftバージョン3をセットアップします。
- ステップ4 *-マスターマシンから、次のcurlコマンドを実行します。
# sh https://install.openshift.com/ose)上記のコマンドにより、OSV3のセットアップが行われます。 次のステップは、マシンでOpenShift V3を構成することです。
インターネットから直接ダウンロードできない場合は、ローカルマスターマシンでインストーラを実行できるtarパッケージとしてhttps://install.openshift.com/portable/oo-install-ose.tgzからダウンロードできます。
セットアップの準備ができたら、マシン上のOSV3の実際の構成から開始する必要があります。 このセットアップは、実際の実稼働環境をテストするために非常に固有のものであり、LDAPなどが用意されています。
- ステップ5 *-マスターマシンで、/etc/openshift/master/master-config.yamlの下にある次のコードを設定します
# vi/etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file:/root/users.htpasswd
routingConfig:
subdomain: testing.com次に、デフォルト管理用の標準ユーザーを作成します。
# htpasswd -c/root/users.htpasswd admin- ステップ6 *-OpenShiftはイメージの構成にDockerレジストリを使用するため、Dockerレジストリを構成する必要があります。 これは、ビルド後にDockerイメージを作成および保存するために使用されます。
次のコマンドを使用して、OpenShiftノードマシンにディレクトリを作成します。
# mkdir/images次に、デフォルトの管理者資格情報を使用してマスターマシンにログインします。これは、レジストリのセットアップ中に作成されます。
# oc login
Username: system:adminデフォルトで作成されたプロジェクトに切り替えます。
# oc project default- ステップ7 *-Dockerレジストリを作成します。
#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -ユーザー権限を編集します。
#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registryイメージレジストリを作成および編集します。
#oadm registry --service-account = registry --
config =/etc/openshift/master/admin.kubeconfig --
credentials =/etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host =/images- ステップ8 *-デフォルトのルーティングを作成します。
デフォルトでは、OpenShiftはOpenVswitchをソフトウェアネットワークとして使用します。 次のコマンドを使用して、デフォルトのルーティングを作成します。 これは、負荷分散とプロキシルーティングに使用されます。 ルーターはDockerレジストリに似ており、レジストリでも実行されます。
# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -次に、ユーザーの権限を編集します。
#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'- ステップ9 *-DNSを構成します。
URLリクエストを処理するために、OpenShiftは動作するDNS環境を必要とします。 このDNS構成は、ルーターを指すDNSワイルドカードを作成するために必要なワイルドカードを作成するために必要です。
# yum install bind-utils bind# systemctl start named# systemctl enable namedvi/etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
10.38.55.13;
;
};
zone "lab.com" IN {
type master;
file "/var/named/dynamic/test.com.zone";
allow-update { none; };
};- ステップ10 *-最後のステップは、オプションのOpenShift V3マスターマシンでgithubサーバーをセットアップすることです。 これは、次の一連のコマンドを使用して簡単に実行できます。
#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の各ポッドでは、クラスター内で独自のイメージが実行されています。 ポッドを構成すると、レジストリからプールされるフィールドがあります。 この構成ファイルはイメージをプルし、クラスターノードに展開します。
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: DenyAllPasswordIdentityProviderHTPasswd
HTPasswdを使用するには、最初にマスターマシンでHttpd-toolsをセットアップしてから、他のマシンと同じ方法で構成する必要があります。
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider承認
承認はOpenShiftマスターの機能であり、ユーザーの検証を検証するために使用されます。 つまり、アクションを実行しようとしているユーザーをチェックして、特定のプロジェクトでそのアクションを実行する権限があるかどうかを確認します。 これにより、管理者はプロジェクトへのアクセスを制御できます。
認可ポリシーは次を使用して制御されます-
- 規則
- 役割
- バインディング
認可の評価は次を使用して行われます-
- 身元
- アクション
- バインディング
ポリシーを使用する-
- クラスターポリシー
- ローカルポリシー
OpenShift-はじめに
OpenShiftは、GUIまたはCLIによってアプリケーションを作成およびデプロイするための2種類の中央値で構成されています。 この章では、CLIを使用して新しいアプリケーションを作成します。 OCクライアントを使用してOpenShift環境と通信します。
新しいアプリケーションを作成する
OpenShiftには、新しいアプリケーションを作成する3つの方法があります。
- ソースコードから
- 画像から
- テンプレートから
ソースコードから
ソースコードからアプリケーションを作成しようとすると、OpenShiftは、アプリケーションビルドフローを定義するレポジトリ内に存在するDockerファイルを探します。 oc new-appを使用してアプリケーションを作成します。
レポジトリを使用する際に最初に留意すべきことは、OpenShiftがコードをプルしてビルドするレポジトリのオリジンを指す必要があるということです。
レポジトリがOCクライアントがインストールされているDockerマシンで複製され、ユーザーが同じディレクトリ内にある場合、次のコマンドを使用して作成できます。
$ 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ファイルは、基本的に展開に使用できるテンプレートです。
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>Webアプリケーションの開発と展開
OpenShiftでの新しいアプリケーションの開発
OpenShiftで新しいアプリケーションを作成するには、新しいアプリケーションコードを記述し、OpenShift OCビルドコマンドを使用してビルドする必要があります。 説明したように、新しいイメージを作成する方法は複数あります。 ここでは、テンプレートを使用してアプリケーションを構築します。 このテンプレートは、oc new-appコマンドで実行すると、新しいアプリケーションを構築します。
次のテンプレートが作成されます-2つのフロントエンドアプリケーションと1つのデータベース。 それとともに、2つの新しいサービスを作成し、それらのアプリケーションをOpenShiftクラスターにデプロイします。 アプリケーションをビルドおよびデプロイする際、最初にOpenShiftでネームスペースを作成し、そのネームスペースの下にアプリケーションをデプロイする必要があります。
新しい名前空間を作成
$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"テンプレート
{
"kind": "Template",
"apiVersion": "v1",
"metadata": {
"name": "openshift-helloworld-sample",
"creationTimestamp": null,
"annotations": {
"description": "This example shows how to create a simple openshift
application in openshift origin v3",
"iconClass": "icon-openshift",
"tags": "instant-app,openshift,mysql"
}
}
},オブジェクト定義
テンプレートの秘密の定義
"objects": [
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {"name": "dbsecret"},
"stringData" : {
"mysql-user" : "${MYSQL_USER}",
"mysql-password" : "${MYSQL_PASSWORD}"
}
},テンプレート内のサービス定義
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "frontend",
"creationTimestamp": null
},
"spec": {
"ports": [
{
"name": "web",
"protocol": "TCP",
"port": 5432,
"targetPort": 8080,
"nodePort": 0
}
],
"selector": {"name": "frontend"},
"type": "ClusterIP",
"sessionAffinity": "None"
},
"status": {
"loadBalancer": {}
}
},テンプレートでのルート定義
{
"kind": "Route",
"apiVersion": "v1",
"metadata": {
"name": "route-edge",
"creationTimestamp": null,
"annotations": {
"template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
}
},
"spec": {
"host": "www.example.com",
"to": {
"kind": "Service",
"name": "frontend"
},
"tls": {
"termination": "edge"
}
},
"status": {}
},
{
"kind": "ImageStream",
"apiVersion": "v1",
"metadata": {
"name": "origin-openshift-sample",
"creationTimestamp": null
},
"spec": {},
"status": {
"dockerImageRepository": ""
}
},
{
"kind": "ImageStream",
"apiVersion": "v1",
"metadata": {
"name": "openshift-22-ubuntu7",
"creationTimestamp": null
},
"spec": {
"dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
},
"status": {
"dockerImageRepository": ""
}
},テンプレートで構成定義を作成
{
"kind": "BuildConfig",
"apiVersion": "v1",
"metadata": {
"name": "openshift-sample-build",
"creationTimestamp": null,
"labels": {name": "openshift-sample-build"}
},
"spec": {
"triggers": [
{ "type": "GitHub",
"github": {
"secret": "secret101" }
},
{
"type": "Generic",
"generic": {
"secret": "secret101",
"allowEnv": true }
},
{
"type": "ImageChange",
"imageChange": {}
},
{ "type": "ConfigChange”}
],
"source": {
"type": "Git",
"git": {
"uri": https://github.com/openshift/openshift-hello-world.git }
},
"strategy": {
"type": "Docker",
"dockerStrategy": {
"from": {
"kind": "ImageStreamTag",
"name": "openshift-22-ubuntu7:latest”
},
"env": [
{
"name": "EXAMPLE",
"value": "sample-app"
}
]
}
},
"output": {
"to": {
"kind": "ImageStreamTag",
"name": "origin-openshift-sample:latest"
}
},
"postCommit": {
"args": ["bundle", "exec", "rake", "test"]
},
"status": {
"lastVersion": 0
}
}
},テンプレートでの展開設定
"status": {
"lastVersion": 0
}
{
"kind": "DeploymentConfig",
"apiVersion": "v1",
"metadata": {
"name": "frontend",
"creationTimestamp": null
}
},
"spec": {
"strategy": {
"type": "Rolling",
"rollingParams": {
"updatePeriodSeconds": 1,
"intervalSeconds": 1,
"timeoutSeconds": 120,
"pre": {
"failurePolicy": "Abort",
"execNewPod": {
"command": [
"/bin/true"
],
"env": [
{
"name": "CUSTOM_VAR1",
"value": "custom_value1"
}
]
}
}
}
}
}
"triggers": [
{
"type": "ImageChange",
"imageChangeParams": {
"automatic": true,
"containerNames": [
"openshift-helloworld"
],
"from": {
"kind": "ImageStreamTag",
"name": "origin-openshift-sample:latest"
}
}
},
{
"type": "ConfigChange"
}
],
"replicas": 2,
"selector": {
"name": "frontend"
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"name": "frontend"
}
},
"spec": {
"containers": [
{
"name": "openshift-helloworld",
"image": "origin-openshift-sample",
"ports": [
{
"containerPort": 8080,
"protocol": "TCP”
}
],
"env": [
{
"name": "MYSQL_USER",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-user"
}
}
},
{
"name": "MYSQL_PASSWORD",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-password"
}
}
},
{
"name": "MYSQL_DATABASE",
"value": "${MYSQL_DATABASE}"
}
],
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"imagePullPolicy": "IfNotPresent",
"securityContext": {
"capabilities": {},
"privileged": false
}
}
],
"restartPolicy": "Always",
"dnsPolicy": "ClusterFirst"
},
"status": {}
},テンプレート内のサービス定義
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "database",
"creationTimestamp": null
},
"spec": {
"ports": [
{
"name": "db",
"protocol": "TCP",
"port": 5434,
"targetPort": 3306,
"nodePort": 0
}
],
"selector": {
"name": "database
},
"type": "ClusterIP",
"sessionAffinity": "None" },
"status": {
"loadBalancer": {}
}
},- テンプレートでの展開構成定義 *
{
"kind": "DeploymentConfig",
"apiVersion": "v1",
"metadata": {
"name": "database",
"creationTimestamp": null
},
"spec": {
"strategy": {
"type": "Recreate",
"resources": {}
},
"triggers": [
{
"type": "ConfigChange"
}
],
"replicas": 1,
"selector": {"name": "database"},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {"name": "database"}
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"name": "database"
}
},
"spec": {
"containers": [
{
"name": "openshift-helloworld-database",
"image": "ubuntu/mysql-57-ubuntu7:latest",
"ports": [
{
"containerPort": 3306,
"protocol": "TCP"
}
],
"env": [
{
"name": "MYSQL_USER",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-user"
}
}
},
{
"name": "MYSQL_PASSWORD",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-password"
}
}
},
{
"name": "MYSQL_DATABASE",
"value": "${MYSQL_DATABASE}"
}
],
"resources": {},
"volumeMounts": [
{
"name": "openshift-helloworld-data",
"mountPath": "/var/lib/mysql/data"
}
],
"terminationMessagePath": "/dev/termination-log",
"imagePullPolicy": "Always",
"securityContext": {
"capabilities": {},
"privileged": false
}
}
],
"volumes": [
{
"name": "openshift-helloworld-data",
"emptyDir": {"medium": ""}
}
],
"restartPolicy": "Always",
"dnsPolicy": "ClusterFirst”
}
}
},
"status": {}
},
"parameters": [
{
"name": "MYSQL_USER",
"description": "database username",
"generate": "expression",
"from": "user[A-Z0-9]{3}",
"required": true
},
{
"name": "MYSQL_PASSWORD",
"description": "database password",
"generate": "expression",
"from": "[a-zA-Z0-9]{8}",
"required": true
},
{
"name": "MYSQL_DATABASE",
"description": "database name",
"value": "root",
"required": true
}
],
"labels": {
"template": "application-template-dockerbuild"
}
}上記のテンプレートファイルは、一度にコンパイルする必要があります。 最初にすべてのコンテンツを1つのファイルにコピーし、完了したらyamlファイルとして名前を付ける必要があります。
アプリケーションを作成するには、次のコマンドを実行する必要があります。
$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"
openshift-helloworld-sample
---------
This example shows how to create a simple ruby application in openshift origin v3
* With parameters:
*MYSQL_USER = userPJJ # generated
* MYSQL_PASSWORD = cJHNK3se # generated
* MYSQL_DATABASE = root
--> Creating resources with label app = ruby-helloworld-sample ...
service "frontend" created
route "route-edge" created
imagestream "origin-ruby-sample" created
imagestream "ruby-22-centos7" created
buildconfig "ruby-sample-build" created
deploymentconfig "frontend" created
service "database" created
deploymentconfig "database" created
--> Success
Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
Run 'oc status' to view your app.ビルドを監視したい場合、それを使用して行うことができます-
$ oc get builds
NAME TYPE FROM STATUS STARTED DURATION
openshift-sample-build-1 Source Git@bd94cbb Running 7 seconds ago 7s以下を使用して、OpenShiftにデプロイされたアプリケーションを確認できます-
$ oc get pods
NAME READY STATUS RESTARTS AGE
database-1-le4wx 1/1 Running 0 1m
frontend-1-e572n 1/1 Running 0 27s
frontend-1-votq4 1/1 Running 0 31s
opeshift-sample-build-1-build 0/1 Completed 0 1mサービス定義に従ってアプリケーションサービスが作成されているかどうかを確認できます。
$ oc get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) SELECTOR AGE
database 172.30.80.39 <none> 5434/TCP name=database 1m
frontend 172.30.17.4 <none> 5432/TCP name=frontend 1mOpenShift-ビルドオートメーション
OpenShiftには、ビルドパイプラインを自動化する複数の方法があります。 そのためには、ビルドフローを記述するBuildConfigリソースを作成する必要があります。 BuildConfigのフローは、Jenkinsジョブ定義のジョブ定義と比較できます。 ビルドフローの作成中に、ビルド戦略を選択する必要があります。
BuildConfigファイル
OpenShiftでは、BuildConfigはAPIに接続してから新しいインスタンスを作成するために使用される残りのオブジェクトです。
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "<Name of build config file>"
spec:
runPolicy: "Serial"
triggers:
-
type: "GitHub"
github:
secret: "<Secrete file name>"
- type: "Generic"
generic:
secret: "secret101"
-
type: "ImageChange"
source:
type: "<Source of code>"
git:
uri: "https://github.com/openshift/openshift-hello-world"
dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
strategy:
type: "Source"
sourceStrategy:
from:
kind: "ImageStreamTag"
name: "openshift-20-centos7:latest"
output:
to:
kind: "ImageStreamTag"
name: "origin-openshift-sample:latest"
postCommit:
script: "bundle exec rake test"OpenShiftには、4種類のビルド戦略があります。
- ソースからイメージへの戦略
- Docker戦略
- カスタム戦略
- パイプライン戦略
ソースからイメージへの戦略
ソースコードからコンテナイメージを作成できます。 このフローでは、実際のコードが最初にコンテナにダウンロードされ、次にその内部でコンパイルされます。 コンパイルされたコードは同じコンテナ内にデプロイされ、イメージはそのコードから構築されます。
strategy:
type: "Source"
sourceStrategy:
from:
kind: "ImageStreamTag"
name: "builder-image:latest"
forcePull: true複数の戦略ポリシーがあります。
- フォースプル
- 増分ビルド
- 外部ビルド
Docker戦略
このフローでは、OpenShiftはDockerfileを使用してイメージをビルドし、作成されたイメージをDockerレジストリにアップロードします。
strategy:
type: Docker
dockerStrategy:
from:
kind: "ImageStreamTag"
name: "ubuntu:latest"Dockerファイルオプションは、ファイルパス、キャッシュなし、強制プルから始まる複数の場所で使用できます。
- イメージから
- Dockerfileパス
- キャッシュなし
- 強制プル
カスタム戦略
これは、さまざまな種類のビルド戦略の1つであり、ビルドの出力がイメージになるような強制はありません。 Jenkinsのフリースタイルの仕事と比較できます。 これにより、Jar、rpm、およびその他のパッケージを作成できます。
strategy:
type: "Custom"
customStrategy:
from:
kind: "DockerImage"
name: "openshift/sti-image-builder"複数のビルド戦略で構成されています。
- Dockerソケットを公開する
- 秘密
- 強制プル
パイプライン戦略
パイプライン戦略は、カスタムビルドパイプラインの作成に使用されます。 これは基本的に、パイプラインでワークフローを実装するために使用されます。 このビルドフローは、Groovy DSL言語を使用したカスタムビルドパイプラインフローを使用します。 OpenShiftはJenkinsでパイプラインジョブを作成して実行します。 このパイプラインフローはJenkinsでも使用できます。 この戦略では、Jenkinsfileを使用し、buildconfig定義に追加します。
Strategy:
type: "JenkinsPipeline"
jenkinsPipelineStrategy:
jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"ビルドパイプラインの使用
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "test-pipeline"
spec:
source:
type: "Git"
git:
uri: "https://github.com/openshift/openshift-hello-world"
strategy:
type: "JenkinsPipeline"
jenkinsPipelineStrategy:
jenkinsfilePath: <file path repository>OpenShift-CLI
OpenShift CLIは、コマンドラインからOpenShiftアプリケーションを管理するために使用されます。 OpenShift CLIには、エンドツーエンドのアプリケーションライフサイクルを管理する機能があります。 一般的に、OpenShiftと通信するためにOpenShiftクライアントであるOCを使用します。
OpenShift CLIセットアップ
別のオペレーティングシステムでOCクライアントをセットアップするには、異なる一連の手順を実行する必要があります。
Windows用OCクライアント
- ステップ1 *-次のリンクからoc cliをダウンロードしますhttps://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2
- ステップ2 *-マシン上のターゲットパスでパッケージを解凍します。
- ステップ3 *-システムのパス環境変数を編集します。
C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%
C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files
(x86)\ATI Technologies\ATI.ACE\C
ore-Static;C:\Program Files\Intel\Intel(R) Management Engine
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;- ステップ4 *-WindowsでOCセットアップを検証します。
C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-AuthMac OS X用OCクライアント
Windowsと同じ場所にMac OSセットアップバイナリをダウンロードし、後でその場所で解凍し、環境のPATH変数で実行可能ファイルのパスを設定できます。
あるいは
Home brewを使用して、次のコマンドを使用してセットアップできます。
$ brew install openshift-cliLinux用OCクライアント
同じページの下に、インストールに使用できるLinuxインストール用のtarファイルがあります。 後で、その特定の実行可能場所を指すパス変数を設定できます。
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サーバー接続と認証メカニズムを管理するために使用されます。 この構成ファイルは、複数のプロファイルを保存および管理し、それらを切り替えるためにも使用されます。 通常の構成ファイルは次のようになります。
$ oc config view
apiVersion: v1
clusters:
- cluster:
server: https://vklnld908.int.example.com
name: openshift
contexts:
- context:
cluster: openshift
namespace: testproject
user: alice
name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
user:
token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232CLIクライアントのセットアップ
ユーザー資格情報の設定用
$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]クラスターの設定用
$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]例
$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232コンテキストの設定用
$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]CLIプロファイル
単一のCLI構成ファイルには、複数のプロファイルを含めることができます。各プロファイルには異なるOpenShiftサーバー構成があり、後で異なるCLIプロファイル間の切り替えに使用できます。
apiVersion: v1
clusters: --→ 1
- cluster:
insecure-skip-tls-verify: true
server: https://vklnld908.int.example.com:8443
name: vklnld908.int.example.com:8443
- cluster:
insecure-skip-tls-verify: true
server: https://vklnld1446.int.example.com:8443
name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
cluster: vklnld908.int.example.com:8443
namespace: openshift-project
user: vipin/vklnld908.int.example.com:8443
name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
cluster: vklnld908.int.example.com:8443
namespace: testing-project
user: alim/vklnld908.int.example.com:8443
name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}
users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232上記の構成では、OpenShiftマスターマシンの2つのインスタンスを定義するクラスターから始まる4つの主要なセクションに分かれています。 2番目のコンテキストセクションでは、vipinおよびalimという2つのコンテキストを定義します。 現在のコンテキストは、現在使用されているコンテキストを定義します。 ここで定義を変更すると、他のコンテキストまたはプロファイルに変更できます。 最後に、ユーザー定義とその認証トークンが定義されます。これは、この例ではvipinです。
使用中の現在のプロファイルを確認したい場合、それを使用して行うことができます-
$ oc status
oc status
In project testing Project (testing-project)
$ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".他のCLIに切り替えたい場合は、次のコマンドを使用してコマンドラインから実行できます。
$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".上記のコマンドを使用して、プロファイルを切り替えることができます。 構成を表示したい場合は、いつでも$ oc config viewコマンドを使用できます。
OpenShift-CLI操作
OpenShift CLIは、アプリケーションのすべての基本的な事前設定、管理、追加、および展開を実行できます。
OCコマンドを使用して、さまざまな種類の操作を実行できます。 このクライアントは、OpenShiftまたはKubernetes互換プラットフォームでアプリケーションを開発、構築、デプロイ、実行するのに役立ちます。 また、「adm」サブコマンドでクラスターを管理するための管理コマンドも含まれています。
基本的なコマンド
次の表に、基本的なOCコマンドを示します。
| Sr.No. | Commands & Description |
|---|---|
| 1 |
Types 概念とタイプの紹介 |
| 2 |
Login サーバーにログインする |
| 3 |
new-project 新しいプロジェクトをリクエストする |
| 4 |
new-app 新しいアプリケーションを作成する |
| 5 |
Status 現在のプロジェクトの概要を表示する |
| 6 |
Project 別のプロジェクトに切り替える |
| 7 |
Projects 既存のプロジェクトを表示する |
| 8 |
Explain リソースの文書化 |
| 9 |
Cluster OpenShiftクラスターの開始と停止 |
ログイン
サーバーにログインし、後で使用するためにログインを保存します。 クライアントの初めてのユーザーは、このコマンドを実行してサーバーに接続し、認証済みセッションを確立し、構成ファイルへの接続を保存する必要があります。 デフォルト設定は、「。kube/config」の下のホームディレクトリに保存されます。
ログインに必要な情報（ユーザー名とパスワード、セッショントークン、サーバーの詳細など）はフラグを介して提供できます。 指定しない場合、コマンドは必要に応じてユーザー入力のプロンプトを表示します。
使用法
oc login [URL] [options]例
# Log in interactively
oc login
# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority =/path/to/cert.crt
# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypassオプション-
- -p、-password = "*-パスワード。指定しない場合はプロンプトが表示されます
- -u、--username = "*-ユーザー名。指定されていない場合はプロンプトが表示されます
-certificate-authority = "-証明書へのパス。 認証局のファイル
- -insecure-skip-tls-verify = false *-trueの場合、サーバーの証明書の有効性はチェックされません。 これにより、HTTPS接続が安全でなくなります
-token = "-APIサーバーへの認証用のベアラートークン
コマンドに関する完全な詳細を取得するには、 oc <コマンド名> --help コマンドを使用します。
ビルドおよびデプロイコマンド
次の表に、ビルドコマンドとデプロイコマンドを示します。
| Sr.No. | Commands & Description |
|---|---|
| 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. | Commands & Description |
|---|---|
| 1 |
Get 1つまたは複数のリソースを表示する |
| 2 |
Describe 特定のリソースまたはリソースのグループの詳細を表示する |
| 3 |
Edit サーバー上のリソースを編集する |
| 4 |
Set オブジェクトに特定の機能を設定するのに役立つコマンド |
| 5 |
Label リソースのラベルを更新する |
| 6 |
Annotate リソースの注釈を更新する |
| 7 |
Expose 複製されたアプリケーションをサービスまたはルートとして公開する |
| 8 |
Delete 1つ以上のリソースを削除します |
| 9 |
Scale 展開内のポッドの数を変更する |
| 10 |
Autoscale 展開構成、展開、複製、コントローラーまたはレプリカセットの自動スケーリング |
| 11 |
Secrets 秘密を管理する |
| 12 |
Serviceaccounts プロジェクトのサービスアカウントを管理する |
トラブルシューティングおよびデバッグコマンド
次の表に、トラブルシューティングとデバッグのコマンドを示します。
| Sr.No. | Commands & Description |
|---|---|
| 1 |
logs リソースのログを印刷する |
| 2 |
Rsh ポッドでシェルセッションを開始する |
| 3 |
Rsync ローカルファイルシステムとポッドの間でファイルをコピーする |
| 4 |
port-forward 1つ以上のローカルポートをポッドに転送する |
| 5 |
Debug デバッグのためにポッドの新しいインスタンスを起動します |
| 6 |
Exec コンテナでコマンドを実行する |
| 7 |
Procy Kubernetes APIサーバーへのプロキシを実行する |
| 9 |
Attach 実行中のコンテナーに接続する |
| 10 |
Run クラスターで特定のイメージを実行する |
| 11 |
Cp コンテナとの間でファイルとディレクトリをコピーする |
高度なコマンド
次の表に、高度なコマンドを示します。
| Sr.No. | Commands & Description |
|---|---|
| 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. | Commands & Description |
|---|---|
| 1 |
Logout 現在のサーバーセッションを終了する |
| 2 |
Config クライアントの構成ファイルを変更する |
| 3 |
Whoami 現在のセッションに関する情報を返す |
| 4 |
Completion 指定されたシェル（bashまたはzsh）のシェル完了コードを出力します |
OpenShift-クラスター
OpenShiftは、OpenShiftクラスターをセットアップする2つのインストール方法を使用します。
- クイックインストール方法
- 高度な設定方法
クラスターのセットアップ
クイックインストール方法
このメソッドは、未達成の迅速なクラスターセットアップ構成の実行に使用されます。 この方法を使用するには、最初にインストーラーをインストールする必要があります。 これは、次のコマンドを実行して実行できます。
インタラクティブな方法
$ atomic-openshift-installer installこれは、対話型セットアップを実行する場合に便利です。
無人インストール方法
この方法は、ユーザーが無人インストール方法を設定する場合に使用されます。ユーザーは、設定yamlファイルを定義し、installer.cfg.ymlという名前で*〜/.config/openshift/に配置できます。 その後、次のコマンドを実行して –uタグ*をインストールできます。
$ atomic-openshift-installer –u installデフォルトでは、*〜/.config/openshift/*の下にある設定ファイルを使用します。 一方、Ansibleはインストールのバックアップとして使用されます。
version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path:/tmp/ansible.log
deployment:
ansible_ssh_user: root
hosts:
- ip: 172.10.10.1
hostname: vklnld908.int.example.com
public_ip: 24.222.0.1
public_hostname: master.example.com
roles:
- master
- node
containerized: true
connect_to: 24.222.0.1
- ip: 172.10.10.2
hostname: vklnld1446.int.example.com
public_ip: 24.222.0.2
public_hostname: node1.example.com
roles:
- node
connect_to: 10.0.0.2
- ip: 172.10.10.3
hostname: vklnld1447.int.example.com
public_ip: 10..22.2.3
public_hostname: node2.example.com
roles:
- node
connect_to: 10.0.0.3
roles:
master:
<variable_name1>: "<value1>"
<variable_name2>: "<value2>"
node:
<variable_name1>: "<value1>"ここには、特定の変数を設定したい場合に定義できるロール固有の変数があります。
完了したら、次のコマンドを使用してインストールを確認できます。
$ oc get nodes
NAME STATUS AGE
master.example.com Ready 10d
node1.example.com Ready 10d
node2.example.com Ready 10d高度なインストール
拡張インストールは、完全なホスト構成と、マスターおよびノード構成に関する変数定義が存在するAnsible構成に完全に基づいています。 これには、構成に関するすべての詳細が含まれます。
セットアップが完了し、プレイブックの準備ができたら、次のコマンドを実行してクラスターをセットアップできます。
$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.ymlクラスターへのホストの追加
を使用してクラスターにホストを追加できます-
- クイックインストーラツール
- 高度な設定方法
- クイックインストールツール*は、インタラクティブモードと非インタラクティブモードの両方で動作します。 次のコマンドを使用します。
$ atomic-openshift-installer -u -c </path/to/file> scaleupアプリケーション構成ファイルの外観をスケーリングする形式は、マスターとノードの両方を追加するために使用できます。
高度な設定方法
この方法では、Ansibleのホストファイルを更新し、このファイルに新しいノードまたはサーバーの詳細を追加します。 設定ファイルは次のようになります。
[OSEv3:children]
masters
nodes
new_nodes
new_master同じAnsibleホストファイルで、以下に示すように、新しいノードに関する変数の詳細を追加します。
[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"最後に、更新されたホストファイルを使用して、新しい構成を実行し、構成ファイルを呼び出して、次のコマンドを使用してセットアップを完了します。
$ ansible-playbook -i/inventory/hosts/usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.ymlクラスターログの管理
OpenShiftクラスターログは、クラスターのマスターマシンとノードマシンから生成されるログに他なりません。 これらは、サーバーログ、マスターログ、コンテナーログ、ポッドログなどから始まる、あらゆる種類のログを管理できます。 コンテナログ管理には、複数のテクノロジーとアプリケーションがあります。
ログ管理のために実装できるツールはほとんどありません。
流Flu
ELK
カブナ
ナギオス
スプランク
ELKスタック*-このスタックは、すべてのノードからログを収集し、それらを体系的な形式で表示しようとするときに役立ちます。 ELKスタックは、主に3つの主要なカテゴリに分類されます。
*ElasticSearch* -主にすべてのコンテナから情報を収集し、それを中央の場所に配置する責任があります。*Fluentd* -収集されたログをelasticsearchコンテナーエンジンに供給するために使用されます。*Kibana* -収集したデータを有用な情報としてグラフィカルインターフェイスに表示するために使用されるグラフィカルインターフェイス。
重要なポイントの1つは、このシステムがクラスターにデプロイされると、すべてのノードからログの収集を開始することです。
ログ診断
OpenShiftには、OCに組み込まれた oc adm dignostics コマンドがあり、複数のエラー状況の分析に使用できます。 このツールは、クラスター管理者としてマスターから使用できます。 このユーティリティは、既知の問題のトラブルシューティングと無視に非常に役立ちます。 これは、マスタークライアントとノードで実行されます。
アグリメントまたはフラグなしで実行すると、クライアント、サーバー、およびノードマシンの構成ファイルを検索し、診断に使用します。 次の引数を渡すことにより、個別に診断を実行できます-
- AggregatedLogging
- 分析ログ
- ClusterRegistry
- ClusterRoleBindings
- ClusterRoles
- ClusterRouter
- ConfigContexts
- DiagnosticPod
- MasterConfigCheck
- マスターノード
- MetricsApiProxy
- NetworkCheck
- NodeConfigCheck
- NodeDefinitions
- ServiceExternalIPs
- UnitStatus
次のコマンドで簡単に実行できます。
$ oc adm diagnostics <DiagnosticName>クラスターのアップグレード
クラスターのアップグレードには、クラスター内の複数のもののアップグレードと、新しいコンポーネントとアップグレードで更新されたクラスターの取得が含まれます。 これには-
- マスターコンポーネントのアップグレード
- ノードコンポーネントのアップグレード
- ポリシーのアップグレード
- ルートのアップグレード
- 画像ストリームのアップグレード
これらすべてのアップグレードを実行するには、最初にクイックインストーラーまたはユーティリティを適切にインストールする必要があります。 そのためには、次のユーティリティを更新する必要があります-
- atomic-openshift-utils
- atomic-openshift-excluder
- atomic-openshift-docker-excluder
- etcdパッケージ
アップグレードを開始する前に、マスターマシンにetcdをバックアップする必要があります。これは、次のコマンドを使用して実行できます。
$ ETCD_DATA_DIR =/var/lib/origin/openshift.local.etcd
$ etcdctl backup \
--data-dir $ETCD_DATA_DIR \
--backup-dir $ETCD_DATA_DIR.bak.<date>マスターコンポーネントのアップグレード
OpenShiftマスターでは、etcdファイルを更新してからDockerに移行することでアップグレードを開始します。 最後に、自動実行プログラムを実行して、クラスターを必要な位置に配置します。 ただし、アップグレードを開始する前に、まず各マスターでアトミックOpenShiftパッケージをアクティブ化する必要があります。 これは、次のコマンドを使用して実行できます。
- ステップ1 *-atomic-openshiftパッケージを削除する
$ atomic-openshift-excluder unexclude- ステップ2 *-すべてのマスターでetcdをアップグレードします。
$ yum update etcd- ステップ3 *-etcdのサービスを再起動し、正常に開始されたかどうかを確認します。
$ systemctl restart etcd
$ journalctl -r -u etcd- ステップ4 *-Dockerパッケージをアップグレードします。
$ yum update docker- ステップ5 *-Dockerサービスを再起動し、正しく起動しているかどうかを確認します。
$ systemctl restart docker
$ journalctl -r -u docker- ステップ6 *-完了したら、次のコマンドでシステムを再起動します。
$ systemctl reboot
$ journalctl -r -u docker- ステップ7 *-最後に、atomic-executerを実行して、パッケージをyum excludesのリストに戻します。
$ atomic-openshift-excluder excludeポリシーのアップグレードにそのような強制はありません。推奨される場合にのみアップグレードする必要があり、次のコマンドで確認できます。
$ oadm policy reconcile-cluster-rolesほとんどの場合、ポリシー定義を更新する必要はありません。
ノードコンポーネントのアップグレード
マスターの更新が完了したら、ノードのアップグレードを開始できます。 心に留めておくべきことの1つは、クラスター内のあらゆる種類の問題を回避するために、アップグレードの期間を短くする必要があることです。
- ステップ1 *-アップグレードを実行するすべてのノードからすべてのアトミックOpenShiftパッケージを削除します。
$ atomic-openshift-excluder unexclude- ステップ2 *-次に、アップグレードの前にノードのスケジューリングを無効にします。
$ oadm manage-node <node name> --schedulable = false- ステップ3 *-すべてのノードを現在のホストから他のホストに複製します。
$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets- ステップ4 *-ホスト上のDockerセットアップをアップグレードします。
$ yum update docker- ステップ5 *-Dockerサービスを再起動してから、Dockerサービスノードを開始します。
$systemctl restart docker
$ systemctl restart atomic-openshift-node- ステップ6 *-両方が正しく起動したかどうかを確認します。
$ journalctl -r -u atomic-openshift-node- ステップ7 *-アップグレードが完了したら、ノードマシンを再起動します。
$ systemctl reboot
$ journalctl -r -u docker- ステップ8 *-ノードでスケジューリングを再度有効にします。
$ oadm manage-node <node> --schedulable.- ステップ9 *-atomic-openshift実行プログラムを実行して、OpenShiftパッケージをノードに戻します。
$ atomic-openshift-excluder exclude- ステップ10 *-最後に、すべてのノードが使用可能かどうかを確認します。
$ oc get nodes
NAME STATUS AGE
master.example.com Ready 12d
node1.example.com Ready 12d
node2.example.com Ready 12dOpenShift-アプリケーションのスケーリング
自動スケーリングはOpenShiftの機能であり、デプロイされたアプリケーションは特定の仕様に従って必要に応じてスケーリングおよびシンクできます。 OpenShiftアプリケーションでは、自動スケーリングはポッド自動スケーリングとも呼ばれます。 次のように、アプリケーションのスケーリングには2つのタイプがあります。
垂直スケーリング
垂直スケーリングとは、単一のマシンにますます多くの電力を追加することです。つまり、CPUとハードディスクを追加することです。 これはOpenShiftの古い方法であり、現在OpenShiftリリースではサポートされていません。
水平スケーリング
このタイプのスケーリングは、マシンの数を増やしてより多くの要求を処理する必要がある場合に役立ちます。
OpenShiftには、スケーリング機能を有効にする* 2つの方法があります。
- 展開構成ファイルを使用する
- イメージの実行中
展開構成ファイルの使用
この方法では、deploymant設定yamlファイルを介してスケーリング機能が有効になります。 このため、OC autoscaleコマンドは、クラスター内の任意の時点で実行する必要があるレプリカの最小数と最大数で使用されます。 オートスケーラーを作成するには、オブジェクト定義が必要です。 以下は、ポッドオートスケーラー定義ファイルの例です。
apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
name: database
spec:
scaleRef:
kind: DeploymentConfig
name: database
apiVersion: v1
subresource: scale
minReplicas: 1
maxReplicas: 10
cpuUtilization:
targetPercentage: 80ファイルを配置したら、yaml形式で保存し、展開のために次のコマンドを実行する必要があります。
$ oc create –f <file name>.yamlイメージの実行中
ocコマンドラインで次の oc autoscale コマンドを使用することにより、yamlファイルなしで自動スケーリングすることもできます。
$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaledこのコマンドは、後で参照に使用できる同様の種類のファイルも生成します。
OpenShiftの展開戦略
OpenShiftの展開戦略では、利用可能なさまざまな方法で展開のフローを定義します。 OpenShiftでは、*重要な展開戦略の種類*を以下に示します。
- ローリング戦略
- 戦略を再作成する
- カスタム戦略
以下は、主にOpenShiftノードでのデプロイメントに使用されるデプロイメント構成ファイルの例です。
kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
name: "database"
spec:
template:
metadata:
labels:
name: "Database1"
spec:
containers:
- name: "vipinopenshifttest"
image: "openshift/mongoDB"
ports:
- containerPort: 8080
protocol: "TCP"
replicas: 5
selector:
name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
imageChangeParams:
automatic: true
containerNames:
- "vipinopenshifttest"
from:
kind: "ImageStreamTag"
name: "mongoDB:latest"
strategy:
type: "Rolling"上記のDeploymentconfigファイルには、ローリングという戦略があります。
次のOCコマンドを使用して展開できます。
$ oc deploy <deployment_config> --latestローリング戦略
ローリング戦略は、ローリングアップデートまたは展開に使用されます。 このプロセスは、ライフサイクルフックもサポートします。これは、任意の展開プロセスにコードを挿入するために使用されます。
strategy:
type: Rolling
rollingParams:
timeoutSeconds: <time in seconds>
maxSurge: "<definition in %>"
maxUnavailable: "<Defintion in %>"
pre: {}
post: {}戦略を再作成する
この展開戦略には、ローリング展開戦略の基本的な機能の一部があり、ライフサイクルフックもサポートしています。
strategy:
type: Recreate
recreateParams:
pre: {}
mid: {}
post: {}カスタム戦略
これは、独自の展開プロセスまたはフローを提供する場合に非常に役立ちます。 すべてのカスタマイズは、要件に従って実行できます。
strategy:
type: Custom
customParams:
image: organization/mongoDB
command: [ "ls -l", "$HOME" ]
environment:
- name: VipinOpenshiftteat
value: Dev1OpenShift-管理
この章では、ノードの管理方法、サービスアカウントの構成方法などのトピックを扱います。
マスターとノードの構成
OpenShiftでは、OCとともにstartコマンドを使用して新しいサーバーを起動する必要があります。 新しいマスターを起動するときは、startコマンドとともにマスターを使用する必要がありますが、新しいノードを起動するときには、startコマンドとともにノードを使用する必要があります。 これを行うには、マスターとノードの構成ファイルを作成する必要があります。 次のコマンドを使用して、マスターとノードの基本的な構成ファイルを作成できます。
マスター構成ファイル用
$ 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>次のコマンドを実行すると、構成の開始点として使用できる基本構成ファイルが取得されます。 後で、同じファイルを使用して新しいサーバーを起動できます。
apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
logoutURL: ""
masterPublicURL: https://172.10.12.1:7449
publicURL: https://172.10.2.2:7449/console/
servingInfo:
bindAddress: 0.0.0.0:7449
certFile: master.server.crt
clientCA: ""
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
bindAddress: 0.0.0.0:53
etcdClientInfo:
ca: ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.key
urls:
- https://10.0.2.15:4001
etcdConfig:
address: 10.0.2.15:4001
peerAddress: 10.0.2.15:7001
peerServingInfo:
bindAddress: 0.0.0.0:7001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
servingInfo:
bindAddress: 0.0.0.0:4001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
storageDirectory:/root/openshift.local.etcd
etcdStorageConfig:
kubernetesStoragePrefix: kubernetes.io
kubernetesStorageVersion: v1
openShiftStoragePrefix: openshift.io
openShiftStorageVersion: v1
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: MasterConfig
kubeletClientInfo:
ca: ca.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.key
port: 10250
kubernetesMasterConfig:
apiLevels:
- v1beta3
- v1
apiServerArguments: null
controllerArguments: null
masterCount: 1
masterIP: 10.0.2.15
podEvictionTimeout: 5m
schedulerConfigFile: ""
servicesNodePortRange: 30000-32767
servicesSubnet: 172.30.0.0/16
staticNodeNames: []
masterClients:
externalKubernetesKubeConfig: ""
openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
clusterNetworkCIDR: 10.1.0.0/16
hostSubnetLength: 8
networkPluginName: ""
serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
assetPublicURL: https://172.10.2.2:7449/console/
grantConfig:
method: auto
identityProviders:
- challenge: true
login: true
name: anypassword
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
masterPublicURL: https://172.10.2.2:7449/
masterURL: https://172.10.2.2:7449/
sessionConfig:
sessionMaxAgeSeconds: 300
sessionName: ssn
sessionSecretsFile: ""
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
policyConfig:
bootstrapPolicyFile: policy.json
openshiftInfrastructureNamespace: openshift-infra
openshiftSharedResourcesNamespace: openshift
projectConfig:
defaultNodeSelector: ""
projectRequestMessage: ""
projectRequestTemplate: ""
securityAllocator:
mcsAllocatorRange: s0:/2
mcsLabelsPerProject: 5
uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
subdomain: router.default.svc.cluster.local
serviceAccountConfig:
managedNames:
- default
- builder
- deployer
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
servingInfo:
bindAddress: 0.0.0.0:8443
certFile: master.server.crt
clientCA: ca.crt
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 3600ノード構成ファイル
allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
execHandlerName: native
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
mtu: 1450
networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com
podManifestConfig:
path: "/path/to/pod-manifest-file"
fileCheckIntervalSeconds: 30
servingInfo:
bindAddress: 0.0.0.0:10250
certFile: server.crt
clientCA: node-client-ca.crt
keyFile: server.key
volumeDirectory:/root/openshift.local.volumesこれは、ノード構成ファイルの外観です。 これらの構成ファイルを配置したら、次のコマンドを実行してマスターサーバーとノードサーバーを作成できます。
$ openshift start --master-config =/openshift.local.config/master/master-
config.yaml --node-config =/openshift.local.config/node-<node_hostname>/node-
config.yaml管理ノード
OpenShiftには、主にOpenShiftのすべての操作を実行するために使用されるOCコマンドラインユーティリティがあります。 次のコマンドを使用して、ノードを管理できます。
ノードをリストするため
$ oc get nodes
NAME LABELS
node1.example.com kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com kubernetes.io/hostname = vklnld1447.int.example.comノードに関する詳細の説明
$ 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
- 基本認証
- リクエストヘッダ
マスター構成の定義中に、使用するポリシーのタイプを定義できる識別ポリシーを定義できます。
すべて許可
すべて許可
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProviderすべて拒否
これにより、すべてのユーザー名とパスワードへのアクセスが拒否されます。
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProviderHTPasswd
HTPasswdは、暗号化されたファイルパスワードに対してユーザー名とパスワードを検証するために使用されます。
暗号化されたファイルを生成するためのコマンドは次のとおりです。
$ htpasswd </path/to/users.htpasswd> <user_name>暗号化されたファイルを使用します。
oauthConfig:
...
identityProviders:
- name: htpasswd_authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file:/path/to/users.htpasswdLDAP IDプロバイダー
これは、LDAPサーバーが認証で重要な役割を果たすLDAP認証に使用されます。
oauthConfig:
...
identityProviders:
- name: "ldap_authontication"
challenge: true
login: true
provider:
apiVersion: v1
kind: LDAPPasswordIdentityProvider
attributes:
id:
- dn
email:
- mail
name:
- cn
preferredUsername:
- uid
bindDN: ""
bindPassword: ""
ca: my-ldap-ca-bundle.crt
insecure: false
url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"基本認証
これは、サーバー間認証に対してユーザー名とパスワードの検証が行われるときに使用されます。 認証はベースURLで保護され、JSON形式で提示されます。
oauthConfig:
...
identityProviders:
- name: my_remote_basic_auth_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: BasicAuthPasswordIdentityProvider
url: https://www.vklnld908.int.example.com/remote-idp
ca:/path/to/ca.file
certFile:/path/to/client.crt
keyFile:/path/to/client.keyサービスアカウントの構成
サービスアカウントは、認証用のユーザー名とパスワードを公開するOpenShift APIにアクセスする柔軟な方法を提供します。
サービスアカウントの有効化
サービスアカウントは、認証に公開キーと秘密キーのキーペアを使用します。 APIへの認証は、秘密鍵を使用して行われ、公開鍵に対して検証されます。
ServiceAccountConfig:
...
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
- ...サービスアカウントの作成
次のコマンドを使用して、サービスアカウントを作成します
$ Openshift cli create service account <name of server account>HTTPプロキシの使用
ほとんどの実稼働環境では、インターネットへの直接アクセスが制限されています。 インターネットに公開されていないか、HTTPまたはHTTPSプロキシを介して公開されています。 OpenShift環境では、このプロキシマシン定義は環境変数として設定されます。
これは、 /etc/sysconfig の下にあるマスターファイルとノードファイルにプロキシ定義を追加することで実行できます。 これは、他のアプリケーションの場合と同様です。
マスターマシン
/etc/sysconfig/openshift-master
HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.comノードマシン
/etc/sysconfig/openshift-node
HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com完了したら、マスターマシンとノードマシンを再起動する必要があります。
Docker Pullの場合
/etc/sysconfig/docker
HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.comプロキシ環境でポッドを実行するために、それを使用して行うことができます-
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"OC環境コマンドを使用して、既存のenvを更新できます。
NFSを使用したOpenShift Storage
OpenShiftでは、永続ボリュームと永続ボリュームクレームの概念が永続ストレージを形成します。 これは、最初の永続ボリュームが作成され、後で同じボリュームが要求される重要な概念の1つです。 そのためには、基盤となるハードウェアに十分な容量とディスク容量が必要です。
apiVersion: v1
kind: PersistentVolume
metadata:
name: storage-unit1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
path:/opt
server: 10.12.2.2
persistentVolumeReclaimPolicy: Recycle次に、OC createコマンドcreate Persistent Volumeを使用します。
$ oc create -f storage-unit1.yaml
persistentvolume " storage-unit1 " created作成されたボリュームを要求します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: Storage-clame1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Giクレームを作成します。
$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " createdユーザーおよびロール管理
ユーザーおよびロール管理は、さまざまなプロジェクトのユーザー、アクセス、および制御を管理するために使用されます。
ユーザーを作成する
事前定義されたテンプレートを使用して、OpenShiftで新しいユーザーを作成できます。
kind: "Template"
apiVersion: "v1"
parameters:
- name: vipin
required: true
objects:
- kind: "User"
apiVersion: "v1"
metadata:
name: "${email}"
- kind: "Identity"
apiVersion: "v1"
metadata:
name: "vipin:${email}"
providerName: "SAML"
providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
name: "vipin:${email}"
user:
name: "${email}"oc create –f <ファイル名>を使用してユーザーを作成します。
$ oc create –f vipin.yamlOpenShiftでユーザーを削除するには、次のコマンドを使用します。
$ oc delete user <user name>ユーザーアクセスの制限
ResourceQuotasとLimitRangesは、ユーザーアクセスレベルを制限するために使用されます。 これらは、クラスター上のポッドとコンテナーを制限するために使用されます。
apiVersion: v1
kind: ResourceQuota
metadata:
name: resources-utilization
spec:
hard:
pods: "10"上記の構成を使用して見積もりを作成する
$ oc create -f resource-quota.yaml –n –Openshift-sampleリソース見積もりの説明
$ oc describe quota resource-quota -n Openshift-sample
Name: resource-quota
Namespace: Openshift-sample
Resource Used Hard
-------- ---- ----
pods 3 10コンテナ制限の定義は、デプロイされたコンテナが使用するリソースを制限するために使用できます。 これらは、特定のオブジェクトの最大および最小制限を定義するために使用されます。
ユーザープロジェクトの制限
これは基本的に、ユーザーがいつでも持つことができるプロジェクトの数に使用されます。 基本的には、ブロンズ、シルバー、ゴールドのカテゴリでユーザーレベルを定義することによって行われます。
最初に、ブロンズ、シルバー、ゴールドのカテゴリが持つことができるプロジェクトの数の値を保持するオブジェクトを定義する必要があります。 これらはmaster-confif.yamlファイルで行う必要があります。
admissionConfig:
pluginConfig:
ProjectRequestLimit:
configuration:
apiVersion: v1
kind: ProjectRequestLimitConfig
limits:
- selector:
level: platinum
- selector:
level: gold
maxProjects: 15
- selector:
level: silver
maxProjects: 10
- selector:
level: bronze
maxProjects: 5マスターサーバーを再起動します。
特定のレベルへのユーザーの割り当て。
$ oc label user vipin level = gold必要に応じて、ラベルからユーザーを移動します。
$ oc label user <user_name> level-ユーザーにロールを追加します。
$ oadm policy add-role-to-user <user_name>ユーザーからロールを削除します。
$ oadm policy remove-role-from-user <user_name>ユーザーへのクラスターロールの追加。
$ oadm policy add-cluster-role-to-user <user_name>ユーザーからクラスターの役割を削除します。
$ oadm policy remove-cluster-role-from-user <user_name>グループに役割を追加します。
$ oadm policy add-role-to-user <user_name>グループから役割を削除する。
$ oadm policy remove-cluster-role-from-user <user_name>グループにクラスターロールを追加します。
$ oadm policy add-cluster-role-to-group <groupname>グループからクラスターの役割を削除する。
$ oadm policy remove-cluster-role-from-group <role> <groupname>クラスター管理のユーザー
これは、ユーザーがクラスターの作成から削除までの完全なクラスターを管理できる最も強力な役割の1つです。
$ oadm policy add-role-to-user admin <user_name> -n <project_name>究極のパワーを持つユーザー
$ oadm policy add-cluster-role-to-user cluster-admin <user_name>OpenShift-DockerおよびKubernetes
OpenShiftはDockerおよびKubernetesの上に構築されています。 すべてのコンテナはDockerクラスター上に構築されます。これは、基本的にLinuxマシン上のKubernetesサービスであり、Kubernetesオーケストレーション機能を使用します。
このプロセスでは、すべてのノードを制御し、コンテナーをすべてのノードに展開するKubernetesマスターを構築します。 Kubernetesの主な機能は、異なる種類の構成ファイルを使用してOpenShiftクラスターと展開フローを制御することです。 Kubernetesの場合と同様に、OCコマンドラインユーティリティを使用してクラスターノードでコンテナーを構築および展開するのと同じ方法でkubctlを使用します。
以下は、クラスター内のさまざまな種類のオブジェクトの作成に使用されるさまざまな種類の構成ファイルです。
- 画像
- POD
- サービス
- 複製コントローラー
- レプリカセット
- 展開
画像
Kubernetes（Docker）イメージは、コンテナ化されたインフラストラクチャの主要な構成要素です。 現在のところ、Kubernetesは Docker イメージのみをサポートしています。 ポッドの各コンテナーには、その内部で実行されるDockerイメージがあります。
apiVersion: v1
kind: pod
metadata:
name: Tesing_for_Image_pull -----------> 1
spec:
containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5POD
ポッドは、Kubernetesクラスターのノード内のコンテナーとそのストレージのコレクションです。 内部に複数のコンテナを持つポッドを作成することが可能です。 以下は、データベースコンテナーとWebインターフェイスコンテナーを同じポッドに保持する例です。
apiVersion: v1
kind: Pod
metadata:
name: Tomcat
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Alwaysサービス
サービスは、ポッドの論理セットとして定義できます。 これは、ポッドにアクセスできる単一のIPアドレスとDNS名を提供するポッドの上部の抽象化として定義できます。 サービスを使用すると、負荷分散の構成を非常に簡単に管理できます。 PODのスケーリングが非常に簡単になります。
apiVersion: v1
kind: Service
metadata:
name: Tutorial_point_service
spec:
ports:
- port: 8080
targetPort: 31999複製コントローラー
レプリケーションコントローラーは、Kubernetesの重要な機能の1つであり、ポッドのライフサイクルを管理します。 指定された数のポッドレプリカが任意の時点で実行されていることを確認する必要があります。
apiVersion: v1
kind: ReplicationController
metadata:
name: Tomcat-ReplicationController
spec:
replicas: 3
template:
metadata:
name: Tomcat-ReplicationController
labels:
app: App
component: neo4j
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7474レプリカセット
レプリカセットにより、ポッドのレプリカをいくつ実行する必要があります。 レプリケーションコントローラーの代替と見なすことができます。
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: Tomcat-ReplicaSet
spec:
replicas: 3
selector:
matchLables:
tier: Backend
matchExpression:
- { key: tier, operation: In, values: [Backend]}
app: App
component: neo4j
spec:
containers:
- name: Tomcat-
image: tomcat: 8.0
ports:
containerPort: 7474展開
展開はアップグレードされ、レプリケーションコントローラーの上位バージョンになります。 レプリカセットの展開を管理します。これは、レプリケーションコントローラーのアップグレードバージョンでもあります。 レプリカセットを更新する機能があり、以前のバージョンにロールバックすることもできます。
apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
name: Tomcat-ReplicaSet
spec:
replicas: 3
template:
metadata:
lables:
app: Tomcat-ReplicaSet
tier: Backend
spec:
containers:
name: Tomcat-
image: tomcat: 8.0
ports:
- containerPort: 7474すべての構成ファイルを使用して、それぞれのKubernetesオブジェクトを作成できます。
$ Kubectl create –f <file name>.yaml次のコマンドを使用して、Kubernetesオブジェクトの詳細と説明を知ることができます。
*POD* の場合$ Kubectl get pod <pod name>
$ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>レプリケーションコントローラ
$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name>
$ kubectl describe rc <rc name>サービス
$ Kubectl get svc <svc name>
$ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>DockerとKubernetesの操作方法の詳細については、次のリンクを使用して、Kubernetesチュートリアルにアクセスしてください：/kubernetes/index [kubernetes]。
OpenShift-セキュリティ
OpenShiftセキュリティは、主にセキュリティ制約を処理する2つのコンポーネントの組み合わせです。
- セキュリティコンテキストの制約（SCC）
- サービスアカウント
セキュリティコンテキストの制約（SCC）
基本的にポッドの制限に使用されます。つまり、実行できるアクションやクラスター内でアクセスできるすべてのものなど、ポッドの制限を定義します。
OpenShiftは、管理者が使用、変更、および拡張できる事前定義されたSCCのセットを提供します。
$ oc get scc
NAME PRIV CAPS HOSTDIR SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY
anyuid false [] false MustRunAs RunAsAny RunAsAny RunAsAny 10
hostaccess false [] true MustRunAs MustRunAsRange RunAsAny RunAsAny <none>
hostmount-anyuid false [] true MustRunAs RunAsAny RunAsAny RunAsAny <none>
nonroot false [] false MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none>
privileged true [] true RunAsAny RunAsAny RunAsAny RunAsAny <none>
restricted false [] false MustRunAs MustRunAsRange RunAsAny RunAsAny <none>事前定義されたsccを使用する場合は、sccグループにユーザーまたはグループを追加するだけで実行できます。
$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>サービスアカウント
サービスアカウントは、基本的にOpenShiftマスターAPIへのアクセスを制御するために使用され、マスターまたはノードマシンのいずれかからコマンドまたはリクエストが起動されると呼び出されます。
アプリケーションまたはプロセスが、制限されたSCCによって許可されていない機能を必要とするときはいつでも、特定のサービスアカウントを作成し、そのアカウントをそれぞれのSCCに追加する必要があります。 ただし、SCCが要件に合わない場合は、最適なものを使用するよりも、要件に固有の新しいSCCを作成することをお勧めします。 最後に、展開構成用に設定します。
$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadminコンテナセキュリティ
OpenShiftでは、コンテナーのセキュリティは、コンテナープラットフォームの安全性とコンテナーの実行場所の概念に基づいています。 コンテナのセキュリティと何に注意する必要があるかについて話すとき、いくつかのことが明らかになります。
画像の出所-生産環境で実行されているコンテナの出所を正確かつ議論の余地なく特定する安全なラベリングシステムが設置されています。
セキュリティスキャン-イメージスキャナーは、既知の脆弱性についてすべてのイメージを自動的にチェックします。
監査-実稼働環境は定期的に監査され、すべてのコンテナが最新のコンテナに基づいており、ホストとコンテナの両方が安全に構成されていることを確認します。
分離と最小特権-コンテナは、効果的に機能するために必要な最小限のリソースと特権で実行されます。 ホストや他のコンテナに過度に干渉することはできません。
実行時脅威検出-実行時にコンテナ化されたアプリケーションに対するアクティブな脅威を検出し、それに自動的に応答する機能。
アクセス制御-AppArmorやSELinuxなどのLinuxセキュリティモジュールは、アクセス制御を実施するために使用されます。
コンテナのセキュリティをアーカイブする主要な方法はほとんどありません。
- oAuthを介したアクセスの制御
- セルフサービスWebコンソール経由
- プラットフォームの証明書による
OAuthを介したアクセスの制御
この方法では、API制御アクセスへの認証はアーカイブされ、OpenShiftマスターマシンに組み込まれたOAuthサーバーを介した認証用の安全なトークンを取得します。 管理者は、OAuthサーバー構成の構成を変更することができます。
OAuthサーバー設定の詳細については、このチュートリアルの第5章を参照してください。
セルフサービスWebコンソール経由
このWebコンソールセキュリティ機能は、OpenShift Webコンソールに組み込まれています。 このコンソールは、一緒に働くすべてのチームが認証なしで他の環境にアクセスできないようにします。 OpenShiftのマルチtelnetマスターには、次のセキュリティ機能があります-
- TCLレイヤーが有効になっています
- 認証にx.509証明書を使用します
- マスターマシンのetcd構成を保護します
プラットフォームの証明書による
この方法では、各ホストの証明書は、インストール中にAnsible経由で構成されます。 REST APIを介してHTTPS通信プロトコルを使用するため、さまざまなコンポーネントおよびオブジェクトへのTCLセキュア接続が必要です。 これらは事前定義された証明書ですが、アクセスのためにマスターのクラスターにカスタム証明書をインストールすることもできます。 マスターの初期セットアップ中に、 openshift_master_overwrite_named_certificates パラメーターを使用して既存の証明書をオーバーライドすることにより、カスタム証明書を構成できます。
例
openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt",
"keyfile": "/path/on/host/to/master.key",
"cafile": "/path/on/host/to/mastercert.crt"}]カスタム証明書を生成する方法の詳細については、次のリンクにアクセスしてください-
https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux
ネットワークセキュリティー
OpenShiftでは、通信にソフトウェア定義ネットワーク（SDN）が使用されます。 ネットワーク名前空間は、クラスター内の各ポッドに使用されます。各ポッドは、独自のIPとポートの範囲を取得して、ネットワークトラフィックを取得します。 この方法では、他のプロジェクトのポッドと通信できないため、ポッドを分離できます。
プロジェクトの分離
これは、CLIから次の* oadmコマンド*を使用してクラスター管理者が実行できます。
$ oadm pod-network isolate-projects <project name 1> <project name 2>これは、上記で定義したプロジェクトがクラスター内の他のプロジェクトと通信できないことを意味します。
ボリュームセキュリティ
ボリュームセキュリティとは、明らかにOpenShiftクラスター内のプロジェクトのPVおよびPVCを保護することを意味します。 OpenShiftのボリュームへのアクセスを制御するには、主に4つのセクションがあります。
- 補足グループ
- fsGroup
- runAsUser *seLinuxOptions
補足グループ-補足グループは通常のLinuxグループです。 システムでプロセスが実行されると、ユーザーIDとグループIDで実行されます。 これらのグループは、共有ストレージへのアクセスを制御するために使用されます。
次のコマンドを使用して、NFSマウントを確認します。
# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs*次のコマンドを使用して、マウントサーバー上のNFSの詳細を確認します。
# cat/etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ/opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0/opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)_/opt/nfs/_エクスポートには、UID 454265 およびグループ 2325 でアクセスできます。
apiVersion: v1
kind: Pod
...
spec:
containers:
- name: ...
volumeMounts:
- name: nfs
mountPath:/usr/share/...
securityContext:
supplementalGroups: [2325]
volumes:
- name: nfs
nfs:
server: <nfs_server_ip_or_host>
path:/opt/nfs*fsGroup*fsGroupは、コンテナ補助グループの追加に使用されるファイルシステムグループを表します。 補足グループIDは共有ストレージに使用され、fsGroupはブロックストレージに使用されます。
kind: Pod
spec:
containers:
- name: ...
securityContext:
fsGroup: 2325*runAsUser*runAsUserは、通信にユーザーIDを使用します。 これは、ポッド定義でコンテナーイメージを定義する際に使用されます。 必要に応じて、すべてのコンテナで単一のIDユーザーを使用できます。
コンテナの実行中、定義されたIDはエクスポートの所有者IDと一致します。 指定されたIDが外部で定義されている場合、ポッド内のすべてのコンテナーに対してグローバルになります。 特定のポッドで定義されている場合、単一のコンテナーに固有になります。
spec:
containers:
- name: ...
securityContext:
runAsUser: 454265
