OpenShift.IO：オールインワン開発プラットフォームとCI / CD

完全なコンテナ化とインフラストラクチャの開発と開発におけるコンテナの役割の再考は、オープンソースの世界の主要な支持者をさらなる成果に押し上げる助けにはなりませんでした。 Red Hatは着実にそのラインを曲げており、数年前にOpenShiftが単なるPaaSだったとしたら、今日はそれ以上のものです。 OpenShift自体は理解できますが、単純ではありません。 OpenShiftが追求している主なタスクは、コンテナーを管理し、アプリケーションを展開するプロセスを可能な限り痛みのない安全なものにすることであり、Red Hatが成功したことは注目に値します。 しかし、OpenShiftはそれだけでは、開発者、PM、QAエンジニアにすべてが存在する環境を提供するという大事な夢に近づきません。 これは、JiraやRedMine、無限のJenkinsスレーブ、不完全なステージング更新、GitHubでプロジェクトを手動で設定することなく、異なるプロジェクトで異なる動作をするさまざまなIDEのない理想的な世界です。 この理想の世界は、Red Hatが比較的最近、つまり2017年5月に発表したプロジェクトであり、その名前はopenshift.ioです。



OpenShiftからすべてを絞り出すために、いくつかのオープンソースプロジェクトが使用されました（通常、Red Hatでは、オープンソースを中心にビジネスが構築されています）-fabric8とEclipse Che。 まず最初に。



OpenShiftは、アプリケーションをKubernetesにデプロイする上で優れた働きをします。 しかし、devop、PM、および通常のコーダーに必要とされる可能性のあるすべてをプラットフォームが完全に提供することはほとんどありません。 これは、 Kubernetesの統合開発プラットフォームであるFabric8が助けになる場所です 。



基本的な考え方は、アプリケーションを展開するだけでは十分ではないということです。 つまり、プロジェクトとソース管理の作成からやり直す必要があります。 そのため、Fabric8をローカルで起動するか、openshift.ioのアカウントを引き出すことにより（ベータ版はまだ閉鎖されています）、ソースの場所を指定するスペースを作成し、パイプラインタイプを選択するよう求められます。 はい、openshift.ioは、選択したCI / CDタイプに応じて、サービスポッドを使用していくつかのネームスペースを自動的に作成します。







そのため、たとえば、次のいずれかのチェーンを自分で注文できます。

• ビルドリリース
• ビルドリリース>ステージ
• ビルドリリース>ステージ> prod

ご覧のとおり、単純なものから複雑なものへと進みます。 つまり、CIにJenkinsを使用するだけで、GitHubのWebhookが起動するとすぐに、ポッドでスレーブが発生します（プロバイダーは異なる場合があります）。 または、Jenkinsのビルド後、イメージはローカルレジストリにアップロードされ、ステージネームスペースで既に再利用されます。 最終構成には、ステージングから実動への昇格が含まれます。この場合、これは自動的には行われず、ユーザーの要求があったときにのみ行われます。







Fabric8自体は、囲炉裏の形でOpenShiftにデプロイされます。 起動されたフォームでは、高度なCI / CDを使用する1つのプロジェクト-ビルドリリース>ステージ> prod-すでに39の実行中のコンテナーがカウントされました-これは認証サーバー（これはKeyCloakです）、IPAサーバー、データベース、サービスポッド、ジェンキンスと彼のスレーブ、Eclipse Che、および関連するワークスペース。 一般的にRAMをストックする:)



ところで、 Eclipse Cheについて。 開発がブラウザで直接行われなかった場合、Openshift.ioの図は完全ではありません。 CI / CDスクリプトには、明らかにWebhookをプルする十分なコミットがありません。 また、Openshift.ioは、あなたがどこからコミットするかを知っており、OpenShiftの同じ場所でアプリケーションを開発することを提案します。 Red HatはEclipse Cheに長い間興味を持ち、Codenvyを買収しました。Codenvyの開発者はプロジェクトの創始者です。 興味深いことに、過去2年間で、Web IDEは倒産したか、巨人に引き継がれました（AWSでのCloud 9の出発を思い出さないために）。 まあ、それは本当です、ところで:)







Eclipse CheはOpenShiftで実行され、必要な構成のワークスペースを作成します。 つまり、スペースを作成してプロジェクトをインポートした後、Eclipse Cheはソースをインポートし、チェックアウトを離れることなく、ここでオンラインIDEを開きます。 Cheワークスペースには、最終的にブラウザーでIDEを提供する一連のサーバーおよびその他のソフトウェアがあります。 ワークスペースは、オンデマンドで、つまりユーザーが必要に応じて開始および停止します。 チェーンはより全体的になりました：



インポート-コードとプッシュ-CI / CD







しかし、これで終わりではありません。 コード、CI、およびアプリケーションの展開に加えて、計画もあります。 すべてを1つのボックスに収めるために、Plannerが開発されました。 もちろん、このようなJiraの類似物ははるかに単純ですが、プラットフォームの開発はまだ本格的であるため、改善が期待できます。







Fabric8とその商用のopenshift.ioはゆっくりですが、確実に、開発チーム、特にdevopsの苦痛と問題を包括的に解決しようとしています。 現時点では、このソリューションは湿気があり、明らかに実際のプロジェクトには対応していませんが、結局のところ、OpenShiftはすぐには構築されませんでした。 銀行、ひれ。 機関、最も厳しいセキュリティポリシーを持つ企業は、このようなソリューションの潜在的な消費者です。 特にRed Hatというブランド名で。 しかし、会社の各製品の背後にオープンソースプロジェクトがあることを忘れないでください-それを取り込んでインストールしてください。



待って、見て。 さらに、openshift.ioでRed Hatは分析システムを開発しています。 会社は、パブリックドメインの数十万のプロジェクトを分析して、コードの改善方法、ライブラリの新しいバージョンの提供、脆弱性の報告などを提案します。



ちなみに、Microsoftも同様のプラットフォームであるVSTSを宣伝しようとしています。 しかし、Red Hatの違いは、Kubernetesに賭けたことであり、明らかに失敗しなかったことです。