一般的な話 アプリケーションの中ではたくさんの通信やファイルなどのI/Oが実行されます。これらのI/Oが行われている間、スレッドはI/Oが終わるのを待っているしかありません。そのため、これらの処理はブロッキング処理と呼ばれています。待っている間、アプリケーションは処理をできなくなってしまいます。そのため、これまでのミドルウェアは100～1,000スレッドを用意して、同時に処理する数を増やすことでアプリケーションを稼働していました。 ブロッキング処理の対義語となる物はノンブロッキング処理です。ノンブロッキングではブロッキングの処理になったら別の処理をすることでスレッドが待機することを避けるようになっています。 多くのミドルウェアはノンブロッキングをサポートしています。しかし、ブロッキングを前提にしたアーキテクチャが多く残っています。そのため、アプリケーションとミドルウェアの内部で完全にノンブロッキングのメリットを受けることはできないことが多いです。 Quarkusでは Quarkusはノンブロッキングを前提に設計されています。ノンブロッキングの部分の実装としてはVert.xを使用しています。ノンブロッキング対応の拡張機能を使うことで、アプリケーションとミドルウェアの両方がノンブロッキングで動きます。 また、Quarkusはもちろんブロッキング処理にも対応しています。この場合、ミドルウェアの部分はノンブロッキングで動きますが、アプリケーションの部分はブロッキングで動きます。 スループットが向上するため、ノンブロッキングの拡張機能がある場合はアプリケーションの部分をノンブロッキングで実装することをお奨めします。 以下のグラフはアプリケーションの実装方法によるスループットの比較です。アプリケーションの中で別のサービスへのREST APIを実行しており、その拡張機能がブロッキングかノンブロッキングなのかでスループットが大きく変わっています。 Quarkusは一般的によく使われているライブラリをノンブロッキングな拡張機能として提供しています。しかしながら、これまで使われてきた全てのケースでノンブロッキングなものが使えるとは限りません。そのため、ブロッキングなライブラリを使わないといけないケースも多くあります。 Quarkusでブロッキング処理を実装するのも非常に簡単にできます。以下のように、これまで通りアプリケーションを実装するだけです。 @GET @Path( "/api" ) public Message endpoint1() { return blockingRestClient.invoke(); } これだけでミドルウェア部分はノンブロッキングで、アプリケーションの部分だけブロッキングで処理されます。 やってはいけないことは、アプリケーションの中で「ノンブロッキングです」と宣言しておいて、ブロッキングの処理をする事です。それをするとノンブロッキング用のライブラリの中でブロッキング処理するため、性能が非常に低下します。 @GET @Path( "/blocking/api" ) public Uni<Message> endpoint4() { return Uni.createFrom().item(blockingRestClient.invoke()); } 参考 以下のブログでスレッドの使い方について細かく検証しました。詳細に興味があるかたはごらん下さい。 b.chiroito.dev b.chiroito.dev

こんにちは、Red Hatでソリューションアーキテクトをしている北村です。今回はROSA（Red Hat OpenShift on AWS）環境のdedicated-adminの権限について軽くまとめていきます。 dedicated-adminへの権限付与の仕組み ROSAをインストールしたのちログインするとdedicated-adminsというGroupが存在しているのが確認できます。 $ oc get group NAME USERS cluster-admins cluster-admin dedicated-admins このdedicated-adminに紐づいているロールは以下の手順にてコンソール上で確認できます。 「ユーザー管理」→「グループ」→「dedicated-admins」→「ロールバインディング」 実際に確認いただくと分かりますが、dedicated-adminは大きく以下の方針でRoleが渡されています。 ClusterRoleBindingで、Cluster APIに関するRoleを clusterrole:dedicated-admins-cluster で付与 Projectごとに clusterrole:dedicated-admins-project と clusterrole:admin を付与 dedicated-admins-project ：limitrangeやresourcequotaなどクラスター管理者が扱うリソースの操作権限 admin ：project作成者が持つ権限 いくつかのOpenShiftの管理Projectに対しては独自のroleを付与 ここで特徴的なのが、ProjectごとにClusteRroleをBindingしている点です。おそらく「ClusterRoleBindingでProject全体には付与したくないけど、ユーザーが作成したProjectに対してはより幅広い権限を持たせたい」といった目的があるのではないかと思います。しかしこの運用を行うためには、ユーザーがProjectを作成するたびにRoleBindingリソースをデプロイする必要がでてきます。 この運用を自動化するべく、ROSAやOSD（OpenShift Dedicated）には専用のOperatorとして「RBAC Permissions Operator」がインストールされています。 RBAC Permissions Operator RBAC Permissions OperatorはROSA/OSDにプリインストールされているOperatorです。 このOperatorはProjectに対するRoleBindingを管理しており、Projectの作成を検知して自動でRoleBindingの作成を実施してくれます。どのProjectにどんなRoleBindingをデプロイするのかは、カスタムリソースであるSubjectPermissionで定義します。（残念ながらROSAでは新たにSubjectPermissionを作成することはできません。） まずSubjectPermissionリソースを確認してみましょう。dedicated-admins-projectとadminの付与については、dedicated-adminsで管理されています。 apiVersion: managed.openshift.io/v1alpha1 kind: SubjectPermission metadata: name: dedicated-admins namespace: openshift-rbac-permissions spec: subjectKind: Group subjectName: dedicated-admins clusterPermissions: - dedicated-admins-cluster permissions: - clusterRoleName: dedicated-admins-project namespacesAllowedRegex: ".*" namespacesDeniedRegex: "(^kube$|^kube-.*|^openshift$|^openshift-.*|^default$|^redhat-.*)" allowFirst: true - clusterRoleName: admin namespacesAllowedRegex: ".*" namespacesDeniedRegex: "(^kube$|^kube-.*|^openshift$|^openshift-.*|^default$|^redhat-.*)" allowFirst: true subjectKind で Group or User を指定し、 subjectName にGroup名 or User名を指定。 permissions でBindしたいClusterRoleの指定と、自動でRoleBindingをデプロイしたいNamespaceの条件を正規表現を使って指定。 namespaceAllowedRegex ：対象とするNamespaceの条件。ここでは全てのNamespaceを指定。 namespacesDeniedRegex ：対象外とするNamespaceの条件。ここではKubernetesやOpenShiftの管理系のプロジェクトを対象外としている。 allowFirst ：AllowedとDeniedの順序を指定。 true にすると「基本はAllowだけどDeniedに指定してるものは除く」というロジックでチェック。 clusterPermissions ：こちらを指定することでClusterRoleBindingも自動で実施。 上記のリソースの結果、ユーザーがProjectを作成すると自動でRoleBindingが作成されます。 $ oc new-project rbac-test $ oc get rolebinding -n rbac-test | grep dedicated-admins admin-dedicated-admins ClusterRole/admin 4m11s dedicated-admins-project-dedicated-admins ClusterRole/dedicated-admins-project 4m11s dedicated-admins-project-system:serviceaccounts:dedicated-admin ClusterRole/dedicated-admins-project 4m11s 作成されたリソース名は”{付与するRole名}-{SubjectPermission名}”になっていることがわかります。 dedicated-adminの権限 さて、自動でRoleが付与される仕組みがわかったところで、dedicated-adminの権限を見ていきましょう。 基本的にはほとんどcluster-adminが持つ権限と変わりません。ここではいくつか運用する上で差分がありそうなポイントをピックアップしてお伝えします。 MachineAutoscaler/MachineConfig関連の操作ができない ClusterのAutoscaling設定やMachineConfigの閲覧・編集は不可 インストールできるOperatorに制限がある openshift-operators Projectにデプロイ可能（＝全てのNamespacesで利用可能）なOperatorのみインストール可能 開発者に該当のRoleBinding( admin-dedicated-admins / dedicated-admins-project-dedicated-admins )を削除されると、Projectへのアクセスがままならなくなる ClusterRoleBindingでRole/RoleBindingの作成が付与されているので作り直すことは可能 別のユーザーやグループに対して自分より強い権限（cluster-admin）の付与は不可 Red Hatが提供するOperatorにおいては、PipelinesやServiceMeshなど、クラスターに閉じた運用がメインのものは openshift-operators Projectにデプロイされるためdedicated-adminでもインストール可能です。 一方で、Advanced Cluster Management for Kubernetes OperatorやOpenShift Data Foundation Operatorのようにクラスター外のリソースをがっつり使うようなOperatorについては、個別にNamespace/OperatorGroupを作成する必要があるためインストールできません。 以上のような特性を持つことから、cluster-adminとdedicated-adminは以下のよう使い分けできるといいのではと思います。 開発チームに対してクラスターごと払い出している場合 開発環境においては開発チームメンバー（もしくはその一部）にdedicated-adminを払い出して、ある程度柔軟に操作できる仕組みにする インフラ運用者はcluster-adminの権限を利用 インフラコストにシビアにいくならリーダー層のみcluster-admin、その他のメンバはdedicated-adminを利用 開発チームに対してProjectを払い出している場合 LimitrangeやResourceQuotaが操作できるため開発者に対するdedicated-adminの付与は不可 インフラ運用者はcluster-adminの権限を利用 インフラコストにシビアにいくならリーダー層のみcluster-admin、その他のメンバはdedicated-adminを利用 結論 基本的にROSAにおいてはcluster-adminが利用できることから、dedicated-adminは「開発者に対してより幅広な権限を付与する際に利用する」くらいの位置付けになるかと思います。 ちなみに、インストールするOperatorによっては「Operatorはデプロイできたけど、カスタムリソースがデプロイできない」といった事象が発生する可能性がありますので、詳しくは実機の権限を確認しながら、cluster-adminによって適宜権限付与の対応を行なってください。 せっかく従量課金ですので、開発チームごとにクラスターを払い出してdedicated-adminを付与し、開発スピードの向上＆運用チームの稼働削減を図ってみてはいかがでしょうか？

はじめに みなさん、こんにちは。 Red Hatでソリューションアーキテクトをしている小野です。 みなさんはエッジコンピューティングを検討する際に「エッジって何？どこを指してるの？」と感じたことはありませんか？ それもそのはず、エッジコンピューティングはとても抽象的な言葉で、業界や団体等によって様々な定義で用いられているからです。 新しい技術ワードはあえて曖昧な定義のまま、あらゆる場面で汎用的に使用できた方が世の中に広く浸透させる上で使いやすいというメリットを理解しつつ、お客様と会話する場面では理解を共通にしておく必要がありますし、お客様の対象としているエッジの意味や特徴をある程度理解しておかないと、踏み込んだ議論が中々難しいかなと感じます。 そこで本稿では、エッジコンピューティングとは何かをざっくり俯瞰し、各エッジの特徴をまとめたいと思います。 エッジコンピューティングとは エッジコンピューティングとは、データ生成場所に近い 場所（＝エッジ） で 処理（＝コンピューティング） を行う概念です。 Youtube等にも解説動画が多数存在し、下記の動画は参考になります。 ここで疑問に思うのは「近ければ何でもエッジなの？」という点です。 エッジコンピューティングの解決する課題として、よく以下が挙げられます。 基本はネットワークの信頼性や品質を高めたいという ネットワークに関する非機能要件 のメリットです。 このメリットを享受するには、「単に近いこと」だけでなく、下記の特徴をおさえる必要があります。 自社の管理下にあるプライベートネットワークを介して、極力少ないHop数でアクセスできる 自社の管理下にないネットワークを介する場合は、通信キャリアの網内折り返しなど、閉域ネットワークを介し、極力少ないHop数でアクセスできる センサーや端末がコンピューティングへ接続する際に介する アクセスネットワークの低リスク化 をセットで考える必要があるということです。 同時に、センサーやデバイスが設置される環境は、データセンターなどの様な潤沢なファシリティリソースがあるわけでなく、例えば店舗など、電源や空調に制約のある環境下にコンピューティングが設置されると想定されます。そのため、コンピューティングのフットプリントを小さくしつつ堅牢性や性能を損なわない様にする技術進化が求められます。 さらに、効率良く分散配置されたコンピューティング環境を運用できる様、クラウド技術の適用やエッジ向けの改善がトレンドになっています。 いわば、エッジコンピューティングとは、 コンピューティングの高性能・小型化 × アクセスネットワークの低リスク化 × クラウド技術の適用・改善 、と言えます。 エッジの定義 Linux Foundationのエッジコンピューティング関連のプロジェクトを推進する LF Edge は、あらゆる業界の人が参加する上で言葉の曖昧さを回避し、業界横断のコラボレーションを促進する事を目的に、エッジコンピューティング界隈の用語をまとめた Open Glossary of Edge Computing をリリースしています。 この定義を参考にしつつ、全体像をおさえてみると下記の様な分類になります。 Device Edge … アプリ処理の場所がデバイス上。エンドポイントとも言われる。 (類似単語) Edge Device … 端末のこと Customer Edge … アプリ処理の場所がお客様拠点内のネットワーク上。CPEやサーバなど (類似単語) End-User Premise Edge … お客様拠点内のオンプレミス設備 (類似単語) On-Premise Edge … 企業のオンプレミス環境上(End-User Premise Edgeと同義) (類似単語) Enterprise Edge … 法人局舎のネットワーク上 (類似単語) Remote Office Edge… 本社に対する店舗や支社などの環境（場所というよりユースケース寄り） (類似単語) Operational Edge… 工場などのOT(Operational Technology)が導入されている現場（場所というよりユースケース寄り） Provider Edge … アプリ処理の場所がエッジ環境のプロバイダのネットワーク上 (類似単語) Network Edge … ネットワーク上(モバイルネットワークだけでなくISPのネットワークも含む) (類似単語) Telco Edge … 通信キャリアのネットワーク上 (モバイルネットワークを指すことが多い) (類似単語) Access Edge ... 基地局(RU)の設置場所 (類似単語) Far Edge … 基地局のコンポーネントのDUなどを設置する、県内複数場所に存在する分散局舎 (類似単語) Edge / Aggregated Edge … 基地局のネットワークの内、県単位などの集約局舎 (類似単語) Regional Edge … 関東・関西などの地域単位の集約局舎 ざっくり、 Device Edgeはデバイスそのもの 、 Customer Edgeは顧客側に導入されたオンプレミス機器で、時にDevice Edgeも包含 、 Provider Edgeはネットワーク提供者側 の環境を指し、ユースケースや場所のイメージを具体化するために類似単語が多く存在しています。 本稿では「ざっくり大枠を押さえる」ということを目的に、以下の3つのエッジで全体を定義します。 各エッジの特徴を深掘る Device Edge Device Edgeは、新しいデバイスの導入がハードルではないお客様にとっての選択肢です。 Chipsetの進化により、カメラやロボットなど、デバイスそのものでAIなどの高度な処理を行える様になり、様々な製品・ソリューションが登場しています。 デバイスに搭載されるハードウェアが高性能・高品質になればなるほど提供価格に影響し、Device Edgeの技術ポイントは フットプリントを小さくしつつ、いかに品質を高めるか と言えます。 On-Premise Edge On-Premise Edgeは「既存のカメラなどの資産を有効活用して高度な処理をしたい」というニーズに応えるものです。 カメラなどの機器の取り替えに抵抗のあるお客様向けの選択肢になります。 技術的には「フットプリントが小さく高性能」に加えて、 「古い機器も含めたインタフェースの対応の柔軟性」 が重要になります。 例えば、特定の製造装置向け、ロボット向け、エレベーター向けなど、特定機器に特化して垂直統合モデルで多くの機種に対応する形で提供されるパターンと、 多様な機器のインターフェイスに対応しつつ、対応機種を徐々に増やしていく水平モデルで提供されるパターンの2パターン存在しています。 垂直統合モデルは、特定のベンダーにロックされる代わりに、そのベンダーの提供する機器の範囲であればサポート対象機種が広く、手軽さがメリットになります。 一方、水平モデルは、同じ空間にマルチベンダー機器が混在する場合に機器間の相互運用性を向上できるメリットがありますが、サポート対象機種を広げるのに時間がかかるというデメリットがあります。 水平モデルは例えば FIWARE や EdgeX Foundry 、 Edgecross など、オープンソースやコンソーシアムを通じてエコシステムを広げ、標準化が進められています。 Provider Edge Provider Edgeは、通信キャリアなどのネットワークプロバイダのエッジ環境を指し、クラウドサービス(プラットフォームサービス)として提供されることが多いです。 これは、 On-Premise Edgeに対して手軽さを向上させたもの と言え、現状、ざっくり以下の3つのユースケースでまとめられます。 ※通信キャリアのエッジで提供されるコンピューティング環境をMEC(Multi-access Edge Computing)とも言います。 ① On-Premise EdgeのLift & Shift ② デバイスのオフロード環境として利用 ③ デバイス間の状態同期や協調制御に利用 ①は、例えば店舗へAIカメラを導入したいけど、新しいカメラを置くスペースがないという場合に、既設のカメラをネットワークと接続してProvider Edgeまでデータを引き込みAI処理を行う、というユースケースです。IoTゲートウェイの仮想化などもこの用途に該当します。 ②は、例えば、3Dモデルのレンダリングや、ロボットやドローンなどのAI処理をProvider Edgeへオフロードし、デバイス側の低廉化や電池持ちの向上を図るというケースです。デバイスの配置場所に依存せず汎用的なオフロード環境としてProvider Edgeの活用が期待され、実証実験が徐々に開始されています。 news.kddi.com www.aviationtoday.com ③は、例えばマルチプレイヤー型のARゲームやクラウドゲームなど、プレイヤー同士の状態に合わせて画面のレンダリングを制御するユースケースや、工場や倉庫での複数のAGVの活用や、ビルでの警備ロボットや清掃ロボットの活用など、複数のロボットを協調動作させて安全に運行できる様に制御するユースケースなどが該当します。 Provider Edgeを利用する際は、 外部ネットワークへの接続が必要 な点で注意が必要です。ネットワークプロバイダーとなる通信キャリアの網内で折り返すとは言え、回線コストがかかりますので、TCO（Total Cost of Ownership）で見たときに必ずしもOn-Premise Edgeより安くなるとは言い切れません。 5Gの観点では、On-Premise Edgeはローカル5Gと、Provider Edgeはパブリック5Gと親和性が高く、5Gを使いたい場合にProvider Edgeしか選択肢がないわけでないので、取り扱うデータのセキュリティやファシリティの制約、発生するデータトラフィックなどを鑑みてエッジを選択するのが良いでしょう。 エッジコンピューティングの今後 2021年までは、AIエンジンの低廉化によってAIカメラなど、デバイス自体を高度化する流れが生まれました。ネットワーク観点では5Gが登場し、一部のユースケースでMECを用いた実証実験が進められています。 2022年より、ネットワークの高度化(5G SA)によって通信制御の柔軟性が向上し、広域に分散配置されたMECへ柔軟にアクセスさせることが可能になります。広域分散MECの検討が進むことで、デバイス処理のオフロードの実現性が高まり、高度なデバイスの多様化が進んでいくことが期待されます。 まとめ 本稿では、エッジの定義をざっくり俯瞰した上で各エッジの特徴をまとめました。 今後も引き続きエッジコンピューティングを紹介していきたいと思いますのでよろしくお願いします！

  クラウドインフラ全般を担当しているソリューションアーキテクトの伊藤です。 ※この記事は記事公開時点での手順を紹介しております。   この記事の情報 レッドハットのカスタマーポータルで2FAを有効にする方法 2FAを有効にするための手順 1. 2要素認証を有効化するページへアクセスする 2. 認証アプリへQRコードを読ませる 3. 2つのフォームを埋めて有効化するボタンをクリックする 4. 再度ログインしなおして有効化を確認する まとめ   この記事の情報 ・レッドハットのカスタマーポータルで2FAを有効にする方法   弊社のナレッジベースでは様々な情報を閲覧することができます。 製品に関する情報に留まらず弊社が提供しているサイトについての情報も得ることができます。 ナレッジベース： Red Hat Customer Portal - Access to 24x7 support and knowledge 本記事ではそのナレッジベースから、レッドハットのカスタマーポータルで2FAを有効にする方法についてご紹介したいと思います。   レッドハットのカスタマーポータルで2FAを有効にする方法 通常のカスタマーポータルの中にあるアカウント管理の画面からでは、2FAを有効にすることはできません。 以下のナレッジベースを確認することで2FAを有効にすることができます。   access.redhat.com   以下に日本語の手順を記載致します。 2FAを有効にするための手順 1. 2要素認証を有効化するページへアクセスする 以下のURLから2要素認証を有効化するページにアクセスすることができます。 https://sso.redhat.com/auth/realms/redhat-external/account/totp   2. 認証アプリへQRコードを読ませる Free OTP、Google Authenticator等の認証アプリで表示されているQRコードを読み込ませます   3. 2つのフォームを埋めて有効化するボタンをクリックする 画面下部に入力フォームがあります。 認証アプリに表示された6桁の数字と任意のデバイス名を入力し、有効化ボタンをクリックします。 有効化するボタンをクリックすると、有効化された旨を確認することができます。   4. 再度ログインしなおして有効化を確認する 通常のログアウト/ログインを行って頂き、ログイン過程でワンタイムパスワードが要求されることを確認します。   以上でレッドハットアカウントのログインにおいて2FAが有効化されました。 まとめ 昨今レッドハットアカウントを通じて、レッドハットはクラウドサービスの機能を提供しており、レッドハットアカウントの重要性が増しています。 個人の感想として、そのような中でカスタマーポータルの通常の画面から2FAが有効化できないのは如何なものかと感じました。 より安全にログインする手法の提供は開始しておりますので、この記事を読んで2FAを有効化してご利用頂けると幸いです。    

はじめに みなさんこんにちは。 Red Hatでソリューションアーキテクトをしている小野です。 2/22に開催された Open Mobile Network Infra Meetup #6 にてMECの標準化動向をお話しさせた頂いた際、以下のご質問を頂きました。 ※発表内容は こちら を参照 MECはどの程度の数まで配置されると考えるか？ 通信キャリアはハイパースケーラーと戦うべきか？ 頂いたご質問は、通信キャリアの皆様がMECのビジネス戦略を検討する上で重要な課題であり、同時にこの課題にどの様に向き合うかによって、将来のMECの姿が変わってくると思います。 そこで、私自身の経験を踏まえて深掘りしてみました。 詳細は以下の記事をご参照下さい。 qiita.com ぜひご一読頂けると幸いです！ Appendix 以下、Youtubeです。

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 以前に本ブログでOpenShiftで利用可能なCIパイプラインであるTektonについてご紹介しましたが、今回はTektonを使ってCIパイプラインの中でコンテナイメージを外部のレジストリにコピーする方法についてご紹介させて頂こうと思います。 以前の記事は以下となります。 Tektonの基本やインストール方法について知りたいという方はこちらの記事をご参照下さい。 rheb.hatenablog.com rheb.hatenablog.com なぜイメージのコピーが必要か？ 最近ではOpenShiftをシステムの本番環境だけでなく、開発環境、ステージング環境と、一つのシステムであっても複数のクラスタをご利用頂くケースが多くなっています。 OpenShiftにはクラスタの内部にイメージを保管するレジストリがあるのですが、ステージング環境や本番環境で動かすアプリケーションのイメージを個々のクラスタの内部レジストリから取ってこようとする場合、あらかじめ開発環境でビルドしたイメージをそれぞれの環境にコピーしておく必要があります。 コピーを行う方法として、Podmanなどを使い手動でpullとpushを繰り返す方法も考えられますが、新規のコンテナイメージが作られるたびにこうした作業を繰り返すのは手間がかかり、また人手による操作だと作業ミスが発生する可能性もあります。 そのため本記事ではOpenShift Pipelines(Tekton)とskopeoを使ってCIパイプラインの中でイメージコピーの仕組みを実装していきたいと思います。 利用するパイプライン 今回利用するパイプラインとして以下を準備しました。 それぞれのTaskでは以下を行なっています。 ・git-clone: コンテナ化するアプリケーションのソースコードの取得 ・s2i-nodejs: コンテナのビルドと内部レジストリへのプッシュ ・skopeo-copy: コンテナイメージの別クラスタへのコピー コンテナイメージのコピーについては skopeo を使用します。 skopeoはコンテナイメージを複数のレジストリ間で移動させたいときに便利なツールです。 デーモンレスで動作し、かつコピーの実行にあたってroot権限が不要など、気軽に利用することができます。 skopeoの利用方法については こちらのブログ が参考になると思います。 さて今回はこのskopeoをTektonのTaskとして利用するわけですが、OpenShiftではOpenShift Pipelines Operatorをインストールする際に、クラスタ全体で利用可能なClusterTaskの一つとして skopeo-copy がインストールされます。そのため今回はそちらを使ってPipelineを作成します。 実際に作成したPipelineのyamlは以下となります。(クリックで展開) skopeo-pipeline.yaml apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: skopeo-pipeline spec: workspaces: - name: shared-workspace - name: tmp-vol params: - name: git-url type: string - name: git-revision type: string - name: target-path type: string - name: dest-imageurl type: string tasks: - name: git-clone-health taskRef: name: git-clone kind: ClusterTask params: - name: url value: $(params.git-url) - name: revision value: $(params.git-revision) workspaces: - name: output workspace: shared-workspace - name: build-container taskRef: name: s2i-nodejs kind: ClusterTask runAfter: - git-clone-health workspaces: - name: source workspace: shared-workspace params: - name: PATH_CONTEXT value: $(workspaces.source.path)/$(params.target-path) - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/source/health-record:latest - name: copy-image taskRef: name: skopeo-copy kind: ClusterTask runAfter: - build-container workspaces: - name: images-url workspace: tmp-vol params: - name: srcImageURL value: 'docker://image-registry.openshift-image-registry.svc:5000/source/health-record' - name: destImageURL value: $(params.dest-imageurl) - name: srcTLSverify value: 'false' - name: destTLSverify value: 'false' 環境の準備 今回は2つのOpenShiftクラスタを準備し、その間でイメージのコピーを行います。 一つはAWSのオハイオ(us-east-2)リージョンに構築したROSAクラスタで、もう一つは東京(ap-northeast-1)リージョンにIPIで構築したOCPクラスタです。 ROSAクラスタ側でCIパイプラインを実行し、OCP IPIクラスタの内部レジストリにイメージをコピーしたいと思います。 クラスタを構築したらすぐにイメージのコピーができるかというとそうではなく、事前に以下の三点の準備が必要となります。 1. それぞれのクラスタでNamespaceを作成しておく 2. あて先となるクラスタ（OCP IPI側）でレジストリを外部公開しておく 3. あて先のレジストリの認証情報を取得し、CIパイプライン実行時のServiceAccountに紐付ける 1. それぞれのクラスタでNamespaceを作成しておく CI実行を行うクラスタには source 、あて先のクラスタでは destination というNamespaceをそれぞれ作成し、これらを使っていきます。 それぞれのクラスタに対して、 oc new-project コマンド、もしくはOpenShiftのコンソールを使ってこれらのNamespaceを作成しておきましょう。 2. あて先となるクラスタでレジストリを公開しておく IPIで作成されたOCPクラスタではデフォルトだと内部レジストリが外部に公開されていないため、コンテナイメージをPushすることができません。 そのため以下のコマンドを実行し、レジストリの外部公開を行うよう設定を変更します。 oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge 設定が反映されると openshift-image-registry のNamespaceにて、外部公開用のRouteを確認することができます。 レジストリの公開についての詳細は こちらのドキュメント をご参照下さい。 3. あて先のレジストリの認証情報を取得し、CIパイプライン実行時のServiceAccountに紐付ける 公開されたレジストリにイメージをPushするためには、イメージのPushを行うことが可能なユーザー、もしくはServiceAccountとして認証される必要があります。 OpenShiftでは各Namespaceにデフォルトで、 default 、 builder 、 deployer という3つのServiceAccountが存在します。このうち builder はレジストリにイメージをPushすることができる権限を持っているため、今回はこの builder の認証情報を利用したいと思います。 あて先クラスタ側で以下のコマンドを実行すると destination Namespaceにおける builder の認証情報が出力されます。 SECRET=$(oc -n destination get secret | grep builder-docker | awk {'print $1'}) oc -n destination get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].password' # 実行結果の例 "eyJhbGci...（中略）...HddvV0" 得られた認証情報をCI実行を行う方のクラスタに追加していきましょう。 ここからはコンソールで操作をしていきます。 source NamespaceにてSecret一覧を開き、pipeline-dockercfgから始まるSecretを選択して編集を行います。 このSecretはパイプライン実行を行うServiceAccountである pipeline で利用されます。 "認証情報の追加"をクリックし以下を入力します。 レジストリサーバーのアドレス: 公開したあて先クラスタのレジストリのURL ユーザー名: serviceaccount パスワード: builder の認証情報 認証情報を登録することで、CI実行側のクラスタであて先クラスタのレジストリにアクセスする準備が整いました。 パイプラインの実行 それではいよいよパイプラインを実行していきたいと思います。 CI実行を行うクラスタにはOpenShift Pipelinesをインストールした上で、先ほどのskopeo-pipeline.yamlを適用しておきましょう。 oc apply -n source -f skopeo-pipeline.yaml 今回はPipelineRunを作成し、Pipelineの実行を行います。EventListnerを使ったPipelineの実行については本記事の冒頭にある以前の記事をご参照下さい。 PipelineRunのyamlは以下となります。(クリックで展開) skopeo-pipelinerun.yaml apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: skopeo-pipeline-run- spec: pipelineRef: name: skopeo-pipeline params: - name: target-path value: 'site' - name: git-url value: 'https://gitlab.com/jpishikawa/starter-kit-cicd-app' - name: git-revision value: 'main' - name: dest-imageurl value: 'docker://default-route-openshift-image-registry.apps.mycluster3.sandbox663.opentlc.com/destination/starter-kit-cicd-app' workspaces: - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - name: tmp-vol emptyDir: {} あて先となるレジストリのURLを .spec.params.dest-imageurl というパラメーターの中で指定していますが、先頭部分が https:// ではなく docker:// から始まる点に注意して下さい。 このファイルを適用するとパイプラインの実行が開始されます。 oc create -n source -f skopeo-pipelinerun.yaml 実行してしばらく待つと以下のような形でパイプラインが成功となります。 今度はあて先側のクラスタを見て、イメージがコピーされているか確認をしましょう。 コンソールの destination Namespaceにて、画面左側の"ビルド">"イメージストリーム"を開くとコピーされたイメージを確認することができます。 これでCIパイプラインの中でイメージをコピーできることが確認できました。 まとめ 本記事ではTektonとskopeoを使って、イメージのビルドから外部のレジストリへのコピーまで一連の流れとして行う方法をご紹介しました。 いくつかの事前準備は必要となりますが、skopeoを使うことでイメージのコピーが簡単に実施できることをご理解いただけたのではないでしょうか。 さて、今回はあて先のクラスタにてレジストリを外部公開してコピーを実現しましたが、そもそもレジストリを外部公開したくないケースもあるのではと考えます。 そこで次回は skupper を使い、レジストリを外部公開をせずにイメージをコピーする方法についてご紹介したいと思います。

はじめに みなさん、こんにちは。 Red Hatでソリューションアーキテクトをしている小野です。 OpenShift にはエッジ向けデプロイメントとして、Control Plane と Worker のデプロイメントパターンがいくつか存在します。 本稿では、各デプロイメントパターンの違いや使い分け、CPU やメモリのサイジングなどの最小ハードウェア要件をまとめます。 まとめ記事ですので、ぜひブックマークしておいて頂ければ幸いです！ デプロイメントパターン エッジ環境へ OpenShift をデプロイする際に、大きく以下の5パターンの選択肢があります。 OpenShiftのデプロイメントパターン OpenShiftの基本構成は、Control Plane 3台、Worker 2台です。 OCP 4.6よりサポートされた Remote Worker Node は、何か特別な機能を提供するものでなく、Control Plane からネットワーク的に離れたオンプレミス環境へ Worker Node のみをデプロイできる、という構成の一つと理解頂くのが良いかと思います。 スペース制約のあるエッジ環境へも OpenShift を展開できるようにする目的で提供されています。 例えば、vRAN のコンポーネントである CU(Central Unit) と DU(Distributed Unit) のトポロジを考えたときに、 スペース制約のある県内の分散局舎に Remote Worker Node を配置して DU を稼働させ、県を統括する集約局舎で CU を配置し、県内のDUを集約する、というような使い方が考えられます。 ただし、Remote Worker Node を採用する際は、Control Plane と Worker 間のネットワーク障害を考慮した設計が必要である点に注意して下さい。 注意事項の詳細は以下のドキュメントをご参照下さい。 access.redhat.com 3 Nodeは、OCP 4.5 よりサポートされ、OpenShift の可用性とFootprintのバランスを取りたい場合の選択肢です。 Red Hat のコンテナストレージ製品の Red Hat OpenShift Data Foundation (ODF) のデプロイも可能です。 Single Node は、OCP 4.9 よりサポートされ、単一のサーバで OpenShift の Control Plane と Worker を展開するパターンです。 Remote Worker Node と同様、スペース制約のあるエッジ環境への OpenShift の展開を目的に提供されていますが、Remote Worker Node との違いは、 ネットワーク障害発生によりエッジサイトが NW上孤立状態に陥っても、エッジサイト内でノードの管理が可能である点です。 その反面、OpenShiftのControl Planeが分散配置される形となりますので、アプリケーションのデプロイが煩雑になります。Single Nodeのクラスタが多くのエッジサイトへデプロイされるケースでは、Red Hat Advanced Cluster Management for Kubernetes（RHACM）を用いて各クラスタを一元管理することもあわせて検討するのが良いかと思います。 Single Node の構成は、Red Hat の実験プロジェクトである MicroShift というソフトウェアでも実現可能です。 MicroShiftはラズパイなどのエッジデバイスへのOpenShiftのデプロイを目的に開発されたバイナリサイズ160MBの最小Footprintの OpenShift です。 但し、MicroShiftは実験プロジェクトですので、現時点で製品サポートは無く、将来の製品リリースが約束されているわけではない点ご注意下さい。 各パターン一長一短あり、どのパターンを採用するかは、Footprint(消費リソースの多さ)の大きさと Availability のどちらをどれだけ重視するかに依るかと思います。 以下にて各パターンのポジションと使い分けの例をまとめてみました。 Remote Worker Nodeは、前述の通りControl PlaneとWorker間のネットワーク断により、クラスタの動作が不安定になるリスクが潜在しています。 したがって、品質を自分達でコントロールできるネットワークを介して構成するのをお薦めします。 同時に、エッジサイトの消費リソースを小さくするという目的を考えると、特定のアプリケーション専用のWorker Nodeとする、という使い方が適していると考えます。 OpenShift Installの最小ハードウェア要件 最後に各パターンの最小ハードウェア要件を以下にまとめます。 パターン ノード 台数 CPU/台 メモリ/台 DISK/台 備考 default Bootstrap Control Plane Worker 1 3 2 4 4 2 16GB 16GB 8GB 120GB ・基本的な構成 ・Bootstrapはインストール後に削除してOK ・install後にWorker/Remote Worker Nodeを追加可能 3 Node Cluster Control Plane+Worker 3 6 24GB 120GB ・Small Footprintかつ高可用性のバランス重視 ・このクラスタへODFのデプロイも可能 ・install後にWorker/Remote Worker Nodeを追加可能 Remote Worker Node Worker 1 2 8GB 120GB ・Workerをリモート配置するoption (何か特別な機能があるわけでなくパターンの一つ) ・Control Plane間は2ms未満のレイテンシ要件でリモート設置はNG（Raftアルゴリズムのため） ・Control Plane-Worker間のレイテンシは、サポート要件はないが200ms未満が推奨される Single Node Control Plane+Worker 1 8 16GB 120GB ・高可用性よりもFootprint重視 ・Control Planeは約2コアとメモリ16GBが使用され、残りはユーザーワークロードの実行に使用 ・専用のISOを用いてinstall(Red Hat ACM 2.4のゼロタッチプロビジョニング or Assisted Installer ) MicroShift Control Plane+Worker 1 2 2GB 1GB ・ラズパイなどのエッジデバイス向けのバイナリサイズ160MBの軽量OpenShift ・現時点ではRed Hatの実験プロジェクトでありサポートされない ・対象OS：RHEL8/CentOS Stream8/Fedora 34+ ・AMD64/ARM64/RISCV64も対象 ・ (参考)Qiitaにてインストール方法を少し触れてます (参考)CodeReadyContainer Control Plane+Worker 1 4 9GB 35GB ・実稼働環境での使用は目的外。開発や試験用途 ・対象OS: MAC/Windows/Linux ・新バージョンへのアップグレードパス無 (参考)MiniShift Control Plane+Worker 1 2 4GB 20GB ・実稼働環境での使用は目的外。開発や試験用途 ・OpenShift 3のデプロイとなり現在の使用は非推奨 (参考) RHEL ー ー 1 1.5GB 10GB おまけ RHEL や OpenShift の認定ハードウェアやソフトウェアなどの情報は以下のサイトにて公開されています。 catalog.redhat.com 例えば、Certified Hardware のページを飛ぶとエッジシステムなどのカテゴリで認定ハードウェアを検索できるようになっています。 エッジ環境へ RHEL や OpenShift のデプロイを検討する際はぜひ参考にして下さい。 参考情報 Red Hat Enterprise Linux technology capabilities and limits Red Hat OpenShift Document - Minimum Requirements Red Hat Blog - Delivering a Three-node Architecture for Edge Deployments Red Hat Blog - Deploy Single-Node Kubernetes at the Edge with OpenShift Red Hat Customer Portal - 第8章 ネットワークエッジ上にあるリモートワーカーノード OpenShift Document - Using remote worker nodes at the network edge Red Hat Blog - Delivering a Three-node Architecture for Edge Deployments Red Hat Blog - Red Hat OpenShift 4.9 Is Now Generally Available OpenShift Document - Requirements for installing OpenShift on a single node

レッドハットの杉村です。Ansible のテクニカルサポートをしています。毎月1つは何か書くことを目標にしています。 しかしながら2月はあっという間に過ぎてしまい、28日になってしまいました。今月はKCS (Knowledge Centered Service) について紹介しようと思います。 製品やサービスのナレッジを提供するサービスは各社ありまして、一般に KCS (Knowledge Centered Service) と呼ぶそうです。レッドハットでもそのように呼んでいまして、カスタマーポータルからご利用いただけます。 access.redhat.com 製品についてのドキュメントはもちろんあるのですが、実際の使い方の細かいところまで載っていないということや、トラブルへの対処方法がよくわからないということはどうしても出てきてしまいます。お客さまからの問い合わせを元に事例化することでより早く問題を解決して製品を活用いただきたいという目的で、我々テクニカルサポートのメンバーが KCS のドキュメントを作成しています。 今月はわたしはこのようなものを書いてきました。だいたい週1〜2つくらいは新しい題材が出てきて、ナレッジとして残しておこうという習慣付けをしています。 access.redhat.com access.redhat.com access.redhat.com access.redhat.com access.redhat.com access.redhat.com このように KCS ドキュメントを残しておくことで、カスタマーポータルから問い合わせしようとしたときに関連するドキュメントとして表示されるようになることで、サポートケースでのやりとりの前に解決してしまうかもしれないという期待を持っています。 もし解決できたら、THIS SOLVED MY ISSUE のボタンを押していただけるとうれしいです。 解決できずにサポートケースでの問い合わせをいただく際でも、どのドキュメントを見たけれどもうまくいかなかった、などの情報があるととても助かります。 Ansible 関連の KCS ドキュメントでは日本語のものはほとんど提供しておりませんが、需要はありますでしょうか。 おわりに Ansible Automation Platform は Developer Subscription でもお試しいただけますので、ご興味持たれましたら試してみてください。 rheb.hatenablog.com 製品トライアルもこちらからご利用いただけますのでご検討ください。利用できる機能についてはともに製品版と違いはありません。 www.redhat.com Happy Automation!

こんにちは、Red Hatでソリューションアーキテクトをしている北村です。 今回はAWS環境でOpenShiftを構築・利用する際の認証情報の扱いについて考えていきます。 みなさんはOpenShift上のコンテナからAWSを操作する時、どのような形で権限を付与していますか？よくあるパターンとしてIAMユーザーのアクセスキーとシークレットキーをSecretで環境変数としてアタッチすることが多いかと思います。 しかしAWSでのベストプラクティスでは、システム上での認証はIAMユーザーでなくIAMロールやAWS STS(Security Token Service)による一時的な形での付与を推奨されています。また企業のセキュリティ規約上、システムリソースにIAMユーザーを使うことを明示的にNGにしていることもあるかと思います。 そこで、OpenShift上のコンテナに対して、IAMユーザーの認証情報ではなく、STSを使った一時的な認証情報を渡す方法についてご紹介します。 まずは今回のキーコンポーネントであるCloud Credential Operatorの説明から。 Cloud Credential Operator（CCO） Cloud Credential Operator（CCO）はOpenShiftの管理Operatorで、IPIインストールした場合はデフォルトでクラスターにインストールされています。 CCOはクラウドの認証情報をCredentialsRequestというカスタムリソースで管理しており、このリソース内に記述したIAMポリシー情報や利用先のNamespace情報を元に、自動的に該当のIAMユーザーの作成とSecretの作成を実施してくれる便利なツールです。 IAMユーザーの利用で問題なければ、上記を活用して簡単にAWSアクセス用のリソースが準備できるのでぜひご利用してみてください。 今回はSTSを使うということなのでOpenShift上のこちらの機能は活用できませんが、CCOはccoctlというバイナリツールを提供しており、それを使うことでCredentialsRequestからSTSを使う場合のSecret yamlファイルを作成することができます。 ちなみにOpenShiftのSTSによるインストールはバージョン4.8からGAになりました。 以下は CCOのgithub にある、STSを使った一時的なCredential付与の概要です。 OpenShiftは、AWS Security Token Service(STS)で様々なコンポーネントの一時的なクレデンシャルを使用するように設定できます。これにより、認証フローが有効になり、コンポーネントがIAMロールを引き受けることができるため、資格情報が短命になります。また、AWS IAM OpenID Connect（OIDC）IDプロバイダーを使用して、Credentialsのリクエストと更新を自動化します。OpenShiftは、AWS IAMによって信頼されているServiceAccountトークンに署名できます。このトークンは、Podにプロジェクションして認証に使用できます。以下は、それがどのように機能するかを示す図です。 手順 今回は、以下の2つの作業を行います。 STSを使ってAWS IPIインストールを実施 Podに対してSTSで一時的な認証情報を付与してS3バケット一覧を取得する ちなみにSTSを使ったROSAのインストール方法については、以前に弊社の石川がまとめています。STSのメリットなどもわかりやすくまとまっていますので、ぜひ参照ください。 rheb.hatenablog.com 前提条件 ocコマンド AdministratorAcccess権限を持つIAMユーザー OpenShiftサブスクリプション STS を使ったAWS IPIインストール まずは https://console.redhat.com/openshift/install/aws/installer-provisioned からpull-secretをダウンロードします。 次に今回デプロイするOpenShiftのリリースイメージから、AWS CredentialsRequestオブジェクトを抽出します。そのために https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable-4.9/release.txt にアクセスし、Pull From 行からイメージのIDを取得しRELEASE_IMAGEに格納します $ export RELEASE_IMAGE="quay.io/openshift-release-dev/ocp-release@sha256:1c13f0926c37c122eb5c86afd754c007f38977c8fc32d7da090490f556945afd" 以下コマンドでAWS CredentialsRequestオブジェクトを抽出します。 0000から始まる5つのファイルが普通にIPIインストールした際にデプロイされるCredentialsRequestリソースのyamlになります。 $ mkdir credreqs ; oc adm release extract --cloud=aws --credentials-requests $RELEASE_IMAGE --to=./credreqs $ ls credreqs/ 0000_30_machine-api-operator_00_credentials-request.yaml 0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml 0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml 0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 0000_50_cluster-storage-operator_03_credentials_request_aws.yaml 次にリリースイメージからOpenShiftインストールバイナリーを抽出します。 $ oc adm release extract --command=openshift-install $RELEASE_IMAGE install-config.yamlを作成します。 Pull Secretには先ほどダウンロードしたpull-secretの中身をペーストしてください。 $ ./openshift-install create install-config ? Platform aws INFO Credentials loaded from the "default" profile in file "/home/username/.aws/credentials" ? Region ap-northeast-1 ? Base Domain xxxx.com ? Cluster Name sts-test-cluster-1 ? Pull Secret [? for help] ************************* INFO Install-Config created in: . 作成されたinstall-config.yamlに、credentialsModeをManualでデプロイするための設定を挿入します。 $ echo "credentialsMode: Manual" >> install-config.yaml インストールマニフェストを作成します。 $ ./openshift-install create manifests INFO Credentials loaded from the "default" profile in file "/home/ｕｓｅｒｎａｍｅ/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: manifests and openshift 次にOpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを展開します。 ここでは冒頭でダウンロードしたpull-secretを~/.pull-secretとして保存していることを前提としています。 $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE) $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret $ chmod 775 ccoctl ccoctlを使ってAWSリソースを作成します。 以下のコマンドでは次の操作を一気に実行します。 ServiceAccount署名キー(Private/Public)を生成 S3バケットを作成し、OIDC設定をバケットにアップロード S3バケット設定を信頼するIAM Identity Providerを設定 先述で抽出したcredreqsディレクトリ内のAWSCredentialsRequestごとにIAMロールを作成 インストーラーが必要とするファイルをoutputディレクトリにdump $ ccoctl aws create-all \ --name sts-test-1 \ --region ap-northeast-1 \ --credentials-requests-dir ./credreqs \ --output-dir ./outputs 実行結果 2022/02/25 08:38:07 Generating RSA keypair 2022/02/25 08:38:16 Writing private key to outputs/serviceaccount-signer.private 2022/02/25 08:38:16 Writing public key to outputs/serviceaccount-signer.public 2022/02/25 08:38:16 Copying signing key for use by installer 2022/02/25 08:38:18 Bucket sts-test-1-oidc created 2022/02/25 08:38:19 OpenID Connect discovery document in the S3 bucket sts-test-1-oidc at .well-known/openid-configuration updated 2022/02/25 08:38:19 Reading public key 2022/02/25 08:38:19 JSON web key set (JWKS) in the S3 bucket sts-test-1-oidc at keys.json updated 2022/02/25 08:38:21 Identity Provider created with ARN: arn:aws:iam::XXXXXXXXXXXX:oidc-provider/sts-test-1-oidc.s3.ap-northeast-1.amazonaws.com 2022/02/25 08:38:21 Role arn:aws:iam::XXXXXXXXXXXX:role/sts-test-1-openshift-machine-api-aws-cloud-credentials created 2022/02/25 08:38:21 Saved credentials configuration to: outputs/manifests/openshift-machine-api-aws-cloud-credentials-credentials.yaml 2022/02/25 08:38:22 Updated Role policy for Role sts-test-1-openshift-machine-api-aws-cloud-credentials 2022/02/25 08:38:22 Role arn:aws:iam::XXXXXXXXXXXX:role/sts-test-1-openshift-cloud-credential-operator-cloud-credential- created 2022/02/25 08:38:22 Saved credentials configuration to: outputs/manifests/openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml 2022/02/25 08:38:22 Updated Role policy for Role sts-test-1-openshift-cloud-credential-operator-cloud-credential- 2022/02/25 08:38:23 Role arn:aws:iam::XXXXXXXXXXXX:role/sts-test-1-openshift-image-registry-installer-cloud-credentials created 2022/02/25 08:38:23 Saved credentials configuration to: outputs/manifests/openshift-image-registry-installer-cloud-credentials-credentials.yaml 2022/02/25 08:38:23 Updated Role policy for Role sts-test-1-openshift-image-registry-installer-cloud-credentials 2022/02/25 08:38:24 Role arn:aws:iam::XXXXXXXXXXXX:role/sts-test-1-openshift-ingress-operator-cloud-credentials created 2022/02/25 08:38:24 Saved credentials configuration to: outputs/manifests/openshift-ingress-operator-cloud-credentials-credentials.yaml 2022/02/25 08:38:24 Updated Role policy for Role sts-test-1-openshift-ingress-operator-cloud-credentials 2022/02/25 08:38:24 Role arn:aws:iam::XXXXXXXXXXXX:role/sts-test-1-openshift-cluster-csi-drivers-ebs-cloud-credentials created 2022/02/25 08:38:24 Saved credentials configuration to: outputs/manifests/openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml 2022/02/25 08:38:24 Updated Role policy for Role sts-test-1-openshift-cluster-csi-drivers-ebs-cloud-credentials AWSのIAMを見ると、たしかにIAMユーザーでなくIAMロールが作成されていることがわかります。 IAM Identity Providerも構築されていることが確認できます。 outputsにdumpされたmanifestディレクトリ内のファイルを./manifest配下にコピーします。 $ cp outputs/manifests/* manifests/ 同じくtlsディレクトリも直下のディレクトリにコピーします。 $ cp -a outputs/tls . 先ほどマニフェストを作成した際にinstall-config.yamlが消えてしまっている場合は、再度以下のコマンドを実行します。 入力値は.openshift_install_state.jsonに保存されているため、特に対話なしにファイルが作成されます。 $ ./openshift-install create install-config 以上の作業を行なった後、クラスターのデプロイを実施します。 $ ./openshift-install create cluster インストール後デプロイされたAWSの認証情報のSecretを確認すると、たしかにIAMロールの情報が格納されていることがわかります。 （通常のインストールでは、この情報がIAMユーザーのものになります） $ oc get secrets -n openshift-image-registry installer-cloud-credentials -o json | jq -r .data.credentials | base64 -d [default] role_arn = arn:aws:iam::XXXXXXXXXXXX:role/sts-test-1-openshift-image-registry-installer-cloud-credentials web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token STSによる一時的な認証情報を付与してPodをデプロイ さて、STSを使ってOpenShiftがデプロイできましたので、次はその上でデプロイするPodに対してSTSを使った一時的なCredentials付与を実施します。 実施する手順は大きく以下の4つです。 CredentialsRequestリソースのyamlファイルを作成 ccoctlで上記yamlファイルをもとにIAMロールの作成とデプロイ用マニフェスト(kind: secret)を作成 作成されたSecretマニフェストをデプロイ Secretとサービスアカウントのトークンを要求する設定を行なったPodをデプロイ まずCredentialsRequestを作成します。以下はS3の一覧を取得するための権限を持つIAMを作成するためのものです。 Secretのデプロイ先を「default」に、またPodに付与するService Accountを「default」にすることを前提として記述しています。 $ mkdir -p sts-test-resource/cred-reqs $ cd sts-test-resource $ vi cred-reqs/s3-access-secret.yaml apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: sts-test-cr namespace: openshift-cloud-credential-operator spec: secretRef: name: s3-access-secret namespace: default providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - effect: Allow action: - s3:ListAllMyBuckets resource: "*" serviceAccountNames: - default 次にccoctlでIAMロールの作成とsecretマニフェストの作成を行います。 ※identity-provider-arnにはAWSコンソールのIAM→IDプロバイダから確認してください。 $ ccoctl aws create-iam-roles \ --identity-provider-arn arn:aws:iam::XXXXXXXXXXXX:oidc-provider/sts-test-1-oidc.s3.ap-northeast-1.amazonaws.com \ --output-dir ./outputs \ --name sts-test-1 \ --region ap-northeast-1 \ --credentials-requests-dir ./cred-reqs/ 上記コマンドで作成されたoutputsディレクトリ配下のマニフェストをデプロイします $ oc create -f ./outputs/manifest/default-s3-access-secret-credentials.yaml 最後にデプロイするPodのyamlファイルを作成していきます。 デプロイしたSecretを/var/run/secrets/awsにVolumeMount awscli実行時の認証ファイルに/var/run/secrets/aws/credentialsを使うようAWS_CONFIG_FILE環境変数を設定 サービスアカウントのトークンを/var/run/secrets/openshift/serviceaccountに格納するようbound-sa-tokenvolumesを設定（詳細は こちら を参照） $ vi pod.yaml apiVersion: v1 kind: Pod metadata: labels: run: running-aws name: running-aws spec: containers: - command: - tail - -f - /dev/null image: amazon/aws-cli name: running-aws resources: {} env: - name: AWS_CONFIG_FILE value: /var/run/secrets/aws/credentials volumeMounts: - name: aws-credentials mountPath: /var/run/secrets/aws readOnly: true - name: bound-sa-token mountPath: /var/run/secrets/openshift/serviceaccount readOnly: true volumes: - name: aws-credentials secret: defaultMode: 420 secretName: s3-access-secret - name: bound-sa-token projected: defaultMode: 420 sources: - serviceAccountToken: audience: openshift expirationSeconds: 3600 path: token 上記のPodをデプロイします。 $ oc create -f pod.yaml 実際にPodにログインしてawsコマンドを叩いてみます。 $ oc rsh running-aws sh-4.2# aws s3 ls 2022-02-25 08:38:19 sts-test-1-oidc 2022-02-25 09:13:08 sts-test-cluster-1-5rtrx-image-registry-ap-northeast-1-abcdefg 無事にS3バケットの情報が取得できました。 ちなみにマウントされたawsのCredentialsファイルを見てみましょう sh-4.2# cat /var/run/secrets/aws/credentials [default] role_arn = arn:aws:iam::XXXXXXXXXXXX:role/sts-test-1-default-s3-access-secret web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token たしかにIAMロールで認証設定されていますね。 ということで、IAMユーザーではなくSTSでの一時的な認証付与を行なったPodの作成方法についてご紹介しました。 CCOの機能を最大限活用するにはIAMユーザーでの運用が望ましいですが、セキュリティ的な側面からIAMユーザー認証が使えない際は、この手法を検討してみてはいかがでしょうか？ 参考サイト access.redhat.com github.com

Red Hat のソリューションアーキテクトの伊藤ちひろです。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2022/3月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: Red Hat Single Sign-on OperatorがGAに Red Hat Single Sign-on OperatorがRed Hat Single Sign-On 7.5.1 からとうとうサポートになりました!! こちらの記事で、サポート記念にRed Hat Single Sign-on Operatorのkeycloakカスタムリソース作成までを紹介します。 rheb.hatenablog.com 特集2: Developer Summit 2022 でレガシーアプリケーションの段階的移行の話をしました 2月17日〜18日にオンライン開催された、Developers Summit 2022 のスポンサーセッションで、「レッドハットのミドルウェアでレガシーアプリケーションを段階的にモダナイズする話」というテーマで、レガシーシステムを段階的に移行するにあたり、必要な技術要素と実装例について、デモを交えながらお話をさせて頂きました。 こちらで当日の講演資料を公開しておりますので、ご興味のある方は是非ご覧ください。 rheb.hatenablog.com 特集3: OpenShift で始めるローコード開発（最終回） OpenShiftでローコードを始める場合どのような方法があるかということをテーマにサンプルアプリの作成やデプロイ手順などを解説いたします。 今回は本シリーズ最後となります、Mendixアプリの環境設定を行いOpenShiftにデプロイしてみたいと思います。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 PAM/DM 7.12 Red Hat Data Grid 8.3

Red Hatのソリューションアーキテクトの井上たかひろです。 Red Hat Single Sign-on OperatorがRed Hat Single Sign-On 7.5.1 からとうとうサポートになりました。 これにより、Red Hat SSOのインストール、特に運用が楽になります。(インストールは元から簡単でしたが。。) この記事では、サポート記念にRed Hat Single Sign-on Operatorのkeycloakカスタムリソース作成までを紹介します。 Red Hat Single Sign-on Operatorでは、カスタムリソースで、レルム、クライアント(アプリケーション)、ユーザなどを作成できます。 注意点としては、レルム、クライアント(アプリケーション)、ユーザの作成・編集は、カスタムリソースと管理コンソールのどちらかに統一する必要があります。 具体的には、カスタムリソースで、レルムを作成して管理コンソールで編集すると、カスタムリソースに反映されません。 参照の方は、カスタムリソースで作成・編集した内容は、管理コンソール側で確認できます。 個人的には、REST APIで自動化するよりかは、カスタムリソースの方がシンプルで管理が容易と考えています。 なお、Red Hat Single Sign-on Operatorがサポートになった旨の記載は下記にあります。 access.redhat.com Red Hat Single Sign-on Operatorを触ってみる OpenShift 4.9で、Red Hat Single Sign-on Operatorを日本語表示設定で、管理コンソールのログインまで触っていきます。 まず、雑な名前のプロジェクトを作成しておきます。 oc new-project sso OperatorHubでRed Hat Single Sign-on Operatorを探します。 Red Hat Single Sign-on Operatorのバージョンが7.5.1になっています。(7.5.0以下のOperatorはサポート対象になりません) Operatorのインストール画面で、更新チャネルにstableがあります。GAした感が出てます。 さきほど作成したプロジェクトのssoを選択して、インストールします。 次に、Keycloakカスタムリソースを作成して、管理コンソールを触りにいきます。 以下のyamlをKeycloak.yamlにします。 apiVersion: keycloak.org/v1alpha1 kind: Keycloak metadata: name: example-sso labels: app: sso spec: instances: 1 externalAccess: enabled: True Keycloak.yamlを使ってkeycloakのカスタムリソースを作成します。 oc create -f Keycloak.yaml -n sso keycloak.keycloak.org/example-sso created 管理者アカウントのSecretは、credential-<Keycloakカスタムリソースの名前>になります。 oc describeでも確認しておきます。 oc describe Keycloak 〜〜 Status: Credential Secret: credential-example-sso External URL: https://keycloak-sso.apps.xxx.com Internal URL: https://keycloak.sso.svc:8443 Message: Phase: reconciling Ready: true 〜〜 Secretを見にいって、管理者アカウントのユーザ名とパスワードをメモしておきます。 管理コンソールを見に行きます。 URLはルートから辿るか、KeycloakのカスタムリソースのExternal URLを直接ブラウザに入力してください。 https://keycloak-sso.apps.xxx.com にアクセスすると、 https://keycloak-sso.apps.xxx.com/auth にリダイレクトされます。 いつもの画面が表示されますので、Administration Consoleをクリックして、Secretで確認した管理者アカウントのユーザ名とパスワードを入力します。 ログインするとこれまたいつもの画面が表示されます。 今回は、管理コンソールのログインまでの記載ですが、プロダクトドキュメントには、他のカスタムリソースの作成方法、外部DB設定、カスタムエクステンション(SPI)のインストールなどの説明がありますので、ぜひ、ご参照ください。 access.redhat.com 最後に 今後、OpenShiftのマネージド・サービス上などで、Red Hat Single Sign-on Operatorで認証・認可基盤を構築するシステムが増えてくるのではないかなと思います。 その際には、Red Hat Single Sign-onのセッションを外だしできるRed Hat Data Gridもあわせて利用することで、可用性やメンテナンス性がさらに向上します。 Red Hat Data Gridの利用は、Red Hat Runtimesのサブスクリプションが必要となります。 Red Hat Single Sign-onについては、OpenShiftのサブスクリプションにエンタイトルメントされていますので、ワーカノードで気兼ねなく動かして頂ければ幸いです。 (注: サブスクリプションについては執筆時の情報となります)

レッドハットのソリューションアーキテクトの森です。 2月17日〜18日にオンライン開催された、 Developers Summit 2022 のスポンサーセッションで、「レッドハットのミドルウェアでレガシーアプリケーションを段階的にモダナイズする話」というテーマで、レガシーシステムを段階的に移行するにあたり、必要な技術要素と実装例について、デモを交えながらお話をさせて頂きました。 event.shoeisha.jp アジェンダとしては、以下の内容になります。 段階的移行に有効な4つのテクノロジーについてのご紹介 マイクロサービス コンテナ ストラングラーパターン イベント駆動アーキテクチャ イベント駆動アーキテクチャを使用したデザインパターン、 CQRS(コマンドとクエリの責務分離) CDC(Change Data Capture)によるCQRSの実装例 共有データベースを、CQRS+CDCによるストリーム処理で解体し、イベント駆動型データ連携システムへ システム移行を検討されている皆様のヒントにしていただければ幸いです。 講演資料は Speaker Deck に公開しておりますので、興味のある方は是非ご覧ください！ speakerdeck.com また、当日に頂いたご質問の中で、CDC(Change Data Capture)でエラーや障害が発生した時に、どのような対応が必要か？という内容を頂きましたが、 以下のRed Hat Integration の Debezium のマニュアルにて、障害発生時の対応方法の一例が記載されておりますので、ご参考にして頂ければと思います。(例としてPosgreSQLの場合) access.redhat.com

OpenShift Commons Gathering Japan 2021 Recap: OpenShift Commons Gathering Japan 2021 (vol.3) 2021年12月に閉幕した 「 OpenShift Commons Gathering Japan 2021 」。 前回の第二回目では「 コンテナ導入の成功要因は自己完結型の運用体制 」と題して、レッドハットからみるコンテナのグローバル市場を振り返りました。 最終回となる今回は、コンテナビジネスにおけるRed Hatのこれからの目指す姿をお送りします。 Red Hatが目指す「プラットフォーマー」 いまやビジネスの根幹を支える多くのエンタープライズ企業は、迅速に安定したサービスを提供するためのひとつの手段として「コンテナ」を選択しています。これまでの仮想化技術では移行するとある程度のリソースコスト圧縮が期待されましたが、コンテナ技術へ移行してもリソース集約に直結するわけではありません。 これまでの記事でもお伝えしたように、運用そのものをシステムの自動化に任せ、サービス開発に専念できる体制を作ることがコンテナのメリットでした。 これらの観点からすると、 これからのビジネス開発ではより「開発」にフォーカスすべきであり「運用」はどんどん自動化、標準化に委ねられることが望ましいあり方です。 OpenShift自身もどんどん運用を任せるスタイルに移行するため、主要なクラウドプロバイダーではマネージド環境が提供されています。 rheb.hatenablog.com こうしたマネージドな環境を利用し、よりビジネスにフォーカスできることがこれからのプラットフォームの姿であり、Red Hatはその プラットフォーマー を目指しています。 コンテナの次に提供するサービス OpenShiftの利用企業がよりビジネス開発にフォーカスするためには、Red Hatのサービス提供のあり方も変えていかなければいけません。 コンテナが普及するとともに各企業のサービスは一つのモノリシックなサービスで構成されるのではなく、複数のサービスをつなぎ合わせて成り立っていきます。したがって、サービス間の連携やリアルタイムのデータの受け渡しといった機能が新たに求められます。 これらを開発者が運用をしていくことは負担に繋がります。Red Hatはそれらを見越して、OpenShift上のマイクロサービスを補助するコンポーネントを今後OpenShiftのマネージド・サービスにアドオン( OpenShift Managed Cloud Services )して提供していきます。 OpenShift Managed Cloud Servicecs 代表的な「OpenShift Managed Cloud Services」をみてみましょう。 Red Hat OpenShift Streams for Apache Kafka OpenShift上にApache Kafkaをボタン一つで構築し、リアルタイムデータストリームの作成、検出、および接続を提供するサービスです。マイクロサービス間のデータ連携だけにとどまらず、データストリームを活用することによって、イベント駆動型およびデータ分析アプリケーションが実装できます。 rheb.hatenablog.com Red Hat OpenShift Data Science データサイエンティストに、JupyterLabを始めとした機械学習モデル開発のサンドボックス環境を提供するサービスです。このサービスを利用することにより、機械学習モデルの開発、トレーニングおよびテスト、およびモデルのデプロイが可能です。 rheb.hatenablog.com 新たなクラウドプロバイダーとしてのRed Hat OpenShift上に展開されたマネージドサービスを利用することによって、開発者、またはサービス提供チームだけでサービスが運用できる世界が作れるようになると、よりアジリティの高いシステム開発につながるとも言えます。Red Hatは既存のクラウドのようにData CenterをもってIaaSは提供していませんが、どこのインフラにも依存しないサービスを提供することを目指しています。 これがRed Hatの製品戦略の根幹である「 Open Hybrid Cloud 」です。 www.youtube.com Red HatはOpen Hybrid Cloudという戦略を掲げ、XaaS(Anything as a Service)という世界を創りながら、各企業がビジネスにフォーカスできる環境を提供し続けていきます。 今後もこれらの使命を全うするため、OpenShiftをコアに戦略を掲げていきます。 まとめ さて、３回に渡ってお送りしたOpenShift Commonsのセッション紹介いかがだったでしょうか？ 先行している企業が、どういったビジネス価値を求めてコンテナを活用しているのかが少しでもお伝えできていれば幸いです。そしてRed Hatも日々挑戦し続け、RHELのコアな技術要素を最大限活かしながら、次世代のプラットフォームであるOpenShiftを主軸に今後も皆様のビジネスを支え続けていきます。 Red Hatのコンテナ導入ノウハウを提供「Container Adoption Journey」 Red Hat自身もコンテナ導入の先駆者から多くのノウハウを学び続けています。こうしたノウハウを標準化していき、ツールの力だけでなく利用者の開発プロセスやチームの見直しを支援する Container Adoption Journey(CAJ) というサービスを提供しています。 グローバルにおける導入事例や、SI文化が根強い日本の運用体制から得られた知見をもとに、どのようなステップでコンテナを導入すればよいのか？という疑問に答えつつ、各社の状況に合わせたコンテナ導入のサービスです。 Container Adoption Journey events.redhat.com 詳しくは上記セミナーで紹介されますので、こちらもぜひご参加ください。 オンデマンド配信中!! OpenShift Commons Gathering Japan 2021は 特設サイト にてログイン無しで動画、資料の無償配信をおこなっています。 今回ご紹介したキーノートセッション(57:24～)も是非お楽しみください!! www.youtube.com 本ブログは Solution Architect 北山 よりお送りしました。

ソリューションアーキテクトの蒸野（ムシノ）です。 今回も引き続き「OpenShift上でのローコード開発」についてお伝えさせて頂けたらと思います。 前回までの振り返り 前回までは、ローコードビジネスのメリットやMendixサンプルアプリを作成しました。 また、MendixアプリをOpenShift上で動作させるためのクラスタ設定方法について言及させていただきました。 rheb.hatenablog.com rheb.hatenablog.com Mendixアプリの環境設定 今回は本シリーズ最後となります、Mendixアプリの環境設定を行いOpenShiftにデプロイしてみたいと思います。 4.サンプルアプリケーションの公開 4.1.サンプルアプリの環境設定 サンプルアプリを作成したクラスタに対してデプロイしていきましょう。 以前、Mendix Developer Portal で作成した「TimeSheet-TestApp」を選択します。 左メニューの「Deploy」カテゴリにある「Environments」をクリックすると、未だ Deploy 設定がされていないことが分かります。 ここで「Please select your preferred cloud」をクリックします。 「Cloud Settings」画面が表示されます。 クラウド選択メニューから「Mendix for Private Cloud」を選択します。 次に、「Set up Mendix for Private Cloud」を選択すると「Environments Overview」画面が表示されますので、「Create Environment」をクリックします。 「Create Environment」の設定項目には下記の項目を入力します。 Environment Name：dev Select Namespace：mendix-dev-workspace [ My Private Cloud Cluster ] Purpose： Development Internal NameはランダムなIDが既に入力されていますので、このままにします。 「Next」をクリックすると、Mendix の App Version を選択する画面が表示されるので「Mendix 9.05」を選びます。 最後に下記のようPlanを設定します。 Database Plan：mendix-database Storage Plan：mendix-storage 「Create Environment」をクリックすると環境設定が行われます。 数分待つと環境のステータスが表示され、「Network」「Storage」「Database」ともに緑のチェックマークが出ていれば問題ありません。 4.2.環境設定の確認 それでは次に、 OpenShift コンソールをチェックしてみましょう。 プロジェクトのPodを見ると環境作成時にランダムに振られていた Internal Name でビルドとマスタPodが出来上がっていることが分かります。 ステータスエラーなどで失敗する場合、このビルドやマスタPodのログを確認するなどしてビルドエラーの原因を特定していきます。 ここで問題なければしばらくすると「Environment Details」の「Loaded Deployment Details」のステータスに結果が反映されます。 これでようやくサンプルアプリを OpenShift 上で動かす設定がすべて整いました。 4.3.サンプルアプリの公開 それではサンプルアプリケーションを「Publish」しましょう。Mendix「Developer Portal」から、「Edit in Studio」をクリックしサンプルアプリの編集画面に遷移します。 右上に表示されるメニューの「Publish」をクリックします。Publish 確認画面が表示されますが、ここでも「Publish」をクリックします。 OpenShift 環境に サンプルアプリが公開されるまで数分かかります。 「Publish」完了するとサンプルアプリのアクセスURLが表示されます。 OpenShift の マスターPodログにはデプロイ実行のログが表示されています。 「the application is now available」と表示されていれば問題なくPublishできています。 4.4.サンプルアプリの再確認 早速URLにアクセスしてみます。 「Publish」が成功していると、Mendix 標準のログイン画面が表示されるはずです。 それではログインしようと思いますが、その前にログイン情報を入手する必要があります。 少し分かり難い点ではありますが、このログイン情報については Mendix Pro からログイン情報を入手する必要があります。 方法はMendix のオンラインマニュアルにありますのでこちらを参照ください。 docs.mendix.com Mendix Proからユーザ情報とパスワードを取得し、「demo_approver」ユーザでログインします。 ここではセキュリティの関係上画面は省きますが無事ログインできるかと思います。 ログインすることができましたら、以前サンプルアプリを操作したように「タイムシート」など作成できることを確認してみます。 プレビュー同様問題なく動作できることが確認できるかと思います。 最後に いかがでしたでしょうか？Mendixサンプルアプリを用い、 OpenShift 上で ローコード を実行する場合の説明をさせて頂きました。 Mendixマニュアルだけでは示されていない部分もあり、本解説で具体的に OpenShift 上で実行する場合のイメージを持って頂けたのではないでしょうか？ 機会があれば運用面などの注意点についても今後解説していけたらと思います。 Mendixのオンラインマニュアルについてもう一度掲載させていただきます。 Creating a Private Cloud Cluster： docs.mendix.com デモユーザのプロパティ参照方法： docs.mendix.com

みなさん、こんにちは。 Red Hatでソリューションアーキテクトをしている小野です。 ハイブリッドクラウドやマルチクラウドの環境下へKubernetesクラスタをインストールしたときに、 Kubernetesクラスタ同士を接続するネットワークをどのように構成するのか要検討ポイントとなります。 クラスタ間のネットワークを構成する方法として、以下の記事にて紹介されているSubmarinerを用いてクラスタ間でIPsecを張る方法や、OpenShift Service MeshのFederation機能を使用してmTLSでマルチクラスタ間を連携する方法などがありますが、2つ以上の多くのクラスタを接続することを考えると、ネットワークトポロジがフルメッシュとなり、NATやファイアウォール越えの対応や、クラスタ数の増加に伴う管理の煩雑化、などの懸念が出てきます。 rheb.hatenablog.com cloud.redhat.com そこで、本稿ではAMQP Interconnectベースでクラスタ間ネットワークを実現する Skupper について紹介します。 詳細や簡単な使い方は以下のQiitaの記事にてまとめてみましたのでぜひご参照ください。 qiita.com また、公式ドキュメントは以下となります。 skupper.io Skupperとは Skupperは、KubernetesのマルチクラスタをAMQP Interconnectベースで接続するソフトウェアです。 Red Hat AMQのAMQP Interconnect 2.0にて テクノロジープレビュー として使えます。 access.redhat.com Skupperは、非特権でnamespace単位にdeployされたQpid Dispatch Router(以降、QDR)を介してPod間通信を可能にします。 対象のServiceリソースのバックエンドがQDRとなり、QDRが宛先のクラスタへルーティングするイメージです。 QDRはステートレスなアプリケーションですので、スケールアウトできます。 また、フルメッシュはもちろん、Hub＆SpokeでQDRのネットワークを構成することもできます。 QDR同士を接続して構成したネットワークは、OSPFとIS-ISに似たリンクステートルーティングプロトコルのアルゴリズムを使用して、送信元から宛先すべてにコストベースで最適なパスを計算してルーティング、障害時は迅速に復元するように動作します。 アプリケーション構成 Skupperのアプリケーション構成はとてもシンプルで、Control Planeの skupper-service-controller とData Planeの skupper-router の2コンポーネントが提供されます。 skupper-service-controller Pod(Deployment) consolenやAPIを提供（APIへはskupperCLIでアクセス）し、skupper routerの設定(qdrのqdrouterd.jsonの一部箇所)をconfig-syncと連携して変更したりします。 skupper-router Pod(Deployment) routerコンテナとconfig-syncコンテナが含まれ、routerコンテナはQDR、config-syncコンテナは、skupper-service-controllerと連携してAPIやGUI上で設定されたconfigをrouterと同期します。 Skupperの全体イメージ ユースケースイメージ Skupperは、VPNやファイアウォールのルール、アクセスポリシーなどの複雑なL3処理を介さず、場所を問わずどこからどこへでもアプリケーション間通信を可能にするネットワークとして、Virtual Application Network(VAN)を構成できる、というコンセプトを掲げています。 VANのユースケースとして、下記の様な例が考えられるかと思います。 特にネットワークエッジにQDRを分散配置し、カスタマーエッジやパブリッククラウドからVANへ接続する、と言うことを実現できたら、容易にエッジとクラウド上のアプリケーション間を連携できるな、と夢想しました。 プライベートクラウド上のKubernetesクラスタとパブリッククラウド上のKubernetesクラスタをP2Pで接続し、ハイブリッドクラウドを構成する。 本社をHubとして、支社 to 支社の通信を本社経由で管理。支社からのデータは本社で一元化。また、本社にいるデータ分析者が、支社データを支社内に閉じた状態で活用するHubとなるクラスタを通信キャリアのネットワーク上に分散配置して、エッジとクラウドを中継するネットワークを構成する、など Hubとなるクラスタを通信キャリアのネットワーク上に分散配置して、エッジとクラウドを中継するネットワークを構成する、など VAN構成イメージ GettingStarted Skupperを使うには、公式ドキュメントに記載されている skupper CLIツールを用いるか、OperatorHubにて公開されている Skupper site operator を使います。 Skupper site operator をインストールし、Skupperのコンポーネントの設定情報をまとめた skupper-site と言う名前のConfigMapを作成すれば、コンポーネントのPodが自動deployされます。 Skupper Operator 以下は、ConfigMapの例です。 apiVersion: v1 data: cluster-local: "false" console: "true" console-authentication: internal console-password: "changeme" console-user: "admin" edge: "true" name: east-site router-console: "true" service-controller: "true" service-sync: "true" kind: ConfigMap metadata: name: skupper-site 詳細は、前述のQiitaの記事や公式ドキュメントを参考にしてください。 とても簡単に使えますので、Kubernetesのマルチクラスタのネットワークソリューションの一つとしてぜひお試しください！

OpenShift Commons Gathering Japan 2021 Recap: OpenShift Commons Gathering Japan 2021 (vol.2) 2021年12月に閉幕した 「 OpenShift Commons Gathering Japan 2021 」。 このイベントレポートとして、キーノートの内容を3回に渡って振り返っていきます。 第一回目は「グローバルにおけるコンテナ市場の実態」と題して、レッドハットからみるコンテナのグローバル市場を振り返りました。 rheb.hatenablog.com 前回はグローバルにおけるコンテナ市場の話でしたが、今回は日本市場におけるコンテナ活用企業の動向です。 コンテナ導入のビジネス価値は「Agility / Steady / Optimize」 エンタープライズのコンテナ導入において、よく耳にすることの一つが「コンテナ導入に伴うビジネスメリット(ニーズ)」が腹落ちしないという点です。すでにコンテナを導入してきた企業は、どのようなビジネス価値を期待してコンテナ導入を進めているのでしょうか？ グローバルと同様に、日本におけるコンテナの導入のニーズも単一のものではありません。開発スピードを上げ、安定した品質を提供したいという思いは変わりませんが、上手く活用できている企業はツールと運用プロセスを上手く組み合わして効果を出しています。 コンテナ導入におけるビジネス価値 開発アジリティの向上 (Agility) 開発者がコードをGitリポジトリにコミットした時点で、動的にテストされた成果物(コンテナイメージ)を作れる継続的インテグレーションを実装。これによって開発のスピードや品質を向上します。 安定したサービス維持継続 (Steady) 人の手作業によるデプロイメントをなくし、Kubernetesにデプロイ作業を任すことによって、安定的にコンテナをデプロイし続ける仕組みを提供します。また、Kubernetesにおけるデプロイの標準化を活かし、同様の作業で複数の環境にデプロイできることでデプロイメント品質を担保します。 トータルコストの削減 (Optimize) 仮想マシン導入の時ように、Kubernetes導入だけではコスト効果は多く見込めません。業務プロセスや普段の運用プロセスそのものをKubernetesの自動化、標準化に合わせていくことによって運用全体の効率化を目指すことが望まれます。 Kubernetesが提供する「自動化」や「標準化」を最大限活かしながら、アプリケーション開発ライフサイクルをより早く、安定的に、そして効率良く提供できるのかがポイントです。特にコンテナのアプリケーションライフサイクルでは、CI/CD(継続的インテグレーション/継続的デリバリ)は不可欠な要素だとも言えます。これらの価値を見いださずにコンテナ導入を推進すると、期待したビジネス効果が得られないだけでなく、かえって複雑なシステムを設計してしまうことになりかねません。 ここで今回のイベントに参加いただいた方々のアンケート結果もあわせて見てみましょう。 コンテナ導入に期待する効果 聴講者の皆様も、コンテナ導入にはアプリケーションやインフラリソース運用の効率化、安定性、標準化に期待していることが顕著にわかります。このような変革の事例として、三菱UFJインフォメーションテクノロジー千野様の動画も是非合わせて御覧ください。 www.youtube.com 運用プロセス変化の一手はセルフサービス化!? とはいえ、なかなか既存の運用プロセスやその体制をすぐに変えられる企業も多くありません。 特にこれまでは「開発者」から「運用者」にデプロイやリリース作業、仮想マシンなどのリソース要求を依頼していました。しかし、コンテナ環境においては、これらの作業を サービス提供側の開発チームだけで完結すること が重要です。 詳細については、アイムデジタルラボの鈴木雄介様のブログも大変参考になるため是非参考にしてみてください。 arclamp.hatenablog.com OpenShiftは自己完結型のチームで、アプリケーションを運用できるような セルフサービス化 の機能が豊富に提供されています。たとえばアプリケーションに必要なミドルウェアの展開を開発者自身の権限で設定でき、システムが自律的に運用していくといった仕組みがあります。自律的なシステムの恩恵を受けながら、サービス提供チーム側で運用を担うことによって、これまで人に依頼していた作業をシステムに依頼するだけで完結します。この自己完結型の運用が、結果として開発のスピードや品質向上に繋がります。 コンテナ運用に適した役割りの再定義 コンテナ導入によってビジネスメリットを適切に得るためには、サービス提供チームの役割りの再定義が欠かせません。これは開発したものをリリースするまでの運用体制をサービス提供チーム側で担うための役割りです。コンテナ導入において効果が見えづらい要因の一つが、既存のインフラ運用者にアプリケーション運用を任せ続けている例です。チーム内で完結するための役割りを改めて定義し直してみましょう。 自己完結型のチーム体制に必要な3つの役割 Application Engineering アプリケーションのビジネスドメイン(影響範囲)を明確に分離し、サービスごとにアプリケーションを管理する役割り Release Engineering アプリケーションの成果物を継続的にテストし、サービスの安全なリリースを維持できるような環境を改善し続ける役割り Site Reliability Engineering クラスタそのものの運用管理やアプリケーション間を共有するリソースの権限分離を管理する役割り とくにOpenShiftを上手く活用していくためには、上記の大きく3つの役割りを意識することで、最適なビジネス効果が得られます。 まとめ コンテナ導入でビジネスメリットを享受するためには、システム変更に対する恩恵が受けられるようなチーム体制を築くことが秘訣です。アプリケーション運用の体制を見直し、サービス提供のアジリティ向上や安定性の維持といったビジネス価値へとつなげている企業が日本でも増えているようですね。 次回はレッドハットの未来について語り尽くします!! お楽しみにっ。 オンデマンド配信中!! OpenShift Commons Gathering Japan 2021は 特設サイト にてログイン無しで動画、資料の無償配信をおこなっています。 今回ご紹介したキーノートセッション(31:56～)も是非お楽しみください!! www.youtube.com 本ブログは Solution Architect 北山 よりお送りしました。

皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 メインの仕事はパートナーを担当する SA なのですが、『Ansible 大好き』 を公言しているので、関連する仕事は良くやっています。 長らく赤帽エンジニアブログを書いていませんでした、皆様お久しぶりです。（＾＾） さて、その大好きな Ansible Automation Platform （以下AAP）の最新版 AAP 2.1 が昨年末にリリースされましたのでご紹介したいと思います。なお、AAP 2.1 の技術詳細に関しては、弊社サポートの凄腕の面々から本ブログを通じで既にご紹介させていただいておりますので、プリセールスの私からはどちらかというと『使い方』にフォーカスした情報をご提供できればと思います。 なお、旧 AAP1.2 (Ansible Tower 3.8) から大きく実装が変わってるため、1度で書ききれません。 このため複数回に分けてご紹介したいと思います。以下の様な内容を今のところ想定しています。 ボリュームによっては 5 回になるかもしれません。♪ コンテナ化された実行環境と automation controller による実行 ansible-navigator を使った実行環境の確認と実行 AAP 2.1 へのアップグレードの考慮点と実行方法 その他（Automation Hub / Automation Meshなど） ※本一連のブログは AAP 1.2 を理解されている方を想定しています、ご了承ください。 　また、ご紹介する機能は、2022年1月31日現在、最新のバイナリバージョンである AAP 2.1.1 を前提にしています。 第1回目は、 『コンテナ化された実行環境と automation controller による実行』 というところをご紹介できればと思います。実行環境は AAP2.1 で大きく実装の変わったところの1つです。 非常に重要なポイントなのでここから始めたいと思います。 AAP 2.1 概要 2021年12月2日にリリース 旧 AAP 1.2 で親しまれていた 『Ansible Tower』 は AAP 2.1 では 『automation controller』 と名称が変更になっています。多機能化されていますが基本的な部分での使い勝手は旧 Ansible Tower と変わりませんのでご心配は無用です。（バージョンなど詳細は下記赤い帽子のリンク先参照） CPU/Memory/OS の要件（抜粋）は下記の表の通りです。 旧バージョンは 2CPU/4GB でした。また、AAP2.1 ではついにOSが RHEL8 系のみとなっていますので、特に AAP1.2 → 2.1 へのアップグレードを考えている方はご注意ください。表の中の『Control』 とか、『Execution』とかって何？という話はまた後程。それでも気になる方は、まずは Control ≒ 旧 Ansible Tower と思ってください。（＾＾） ansible のバージョンは、2.9.x → 2.12.x* へ AAP 1.2 (Ansible Tower 3.8) の EOL は 2022年11月18日です！ AAP1.2をご利用の方はそろそろアップグレードの準備をお願いいたします。（＿.＿） 　 Control/Execution/Hop Automation Hub CPU 4 (最小) 2 (最小) RAM 16GB (最小) 8GB (最小) OS Red Hat Enterprise Linux 8.4 or later 64-bit (x86) ← Ansible 2.11 required* - *マニュアル上は、ansible 2.11 required となっていますが、2022年1月末現在、実行環境には 2.12 が包含されています。 ※Disk などその他の要件は、マニュアルをご確認ください。 バージョンやライフサイクルなどは以下ご確認ください。 access.redhat.com コンテナ化された実行環境 AAP 2.1 の最も大きな変更点は、 『ansible の実行環境がコンテナ化された』 これに尽きると思います。 実行環境がコンテナ化された理由については以下 "Container Runtime for Ansible" をご確認ください。 rheb.hatenablog.com AAP 1.2 、つまり旧 Ansible Tower 3.8 では新規インストールすると、必要コンポーネントとして、ホストOS に ansible 2.9.x が同時にインストールされますよね。でも、AAP 2.1 の場合、ansible-core はホスト OS にはインストールされません。* 『えええっ！ じゃ、どうやって Playbook 実行するんですか？？』 って、そうですよね。AAP 2.1 では、ansible-core はホスト OS には直接インストールされず、 実行環境 と呼ばれるコンテナ内部のコンポーネントとして提供されます。モジュールや Python の依存関係なども "基本的には" その実行環境の中にパッケージングされ提供されます。 一方、OS 側には、Ansible Runner** がインストールされるのですが、Playbook 実行時にはこの Ansible Runner が実行環境コンテナ内の ansible-core を呼び出して Playbook を実行する、そんな仕組みになっています。Playbook は、ホスト OS の Current Directory に配置されたものをコンテナがボリュームマウントすることで利用します。 ま、細かい実装面や裏の動きは置いておいて、 『AAP 2.1 では、ansible-core はコンテナ化された実行環境の中にある』 ということをまずしっかり押さえておいてください。 *AAP 2.1 インストールには ansible-core が必要です。このためインストーラを実行するするホストには必要に応じて ansible-core がインストールされます。しかしながら AAP 2.1 のジョブ実行としては利用されません。 **Ansible Runner は AAP1.2で v1が実装されていますが、AAP2.1ではv2となりコンテナ化された実行環境対応となっています。 実行環境の入手方法 実行環境はコンテナイメージとして Red Hat Ecosystem Catalog (リポジトリは registry.redhat.io) より提供されます。本ブログ執筆現在、提供されているイメージは以下の 3種類で、それぞれに特徴があります。 1. Ansible Automation Platform supported execution environment 　ansible-automation-platform-21/ee-supported-rhel8 以下のコンポーネントが含まれています。 ansible-core : 2.12 モジュール : Content Collections の中で Supported By が Red Hat になっているものが含まれます。 依存パッケージ : Collections に必要なパッケージ群及び ansible 2.9 環境と同等のパッケージ "supported" という表記がありますが、AAP 2.1 で標準的に利用されることを想定している実行環境です。 これは AAP 2.1 の制限ではありませんが、ansible-core 2.11 や 2.12 ではコミュニティモジュールは含まれず、約70個のコアモジュールのみが包含されています。この実行環境はそのコアモジュールに Collections の中から Red Hat がサポートする物、約30個を合わせてパッケージングしたものとなっています。旧 AAP 1.2 と互換性の高い ansible 2.9 の実行環境と同等の Python 依存関係も同時にパッケージングされていますが、コミュニティモジュールは含まれていません。 2. Ansible Automation Platform compatibility execution environment 　ansible-automation-platform-21/ee-29-rhel8 ansible : 2.9 モジュール : ansible 2.9 に含まれるモジュール群（3,000+） 依存パッケージ : ansible 2.9 環境で必要とされる Python 依存パッケージも数多く含まれています。 "compatibility" という表記があるとおり、旧 AAP 1.2 環境と互換性の高い実行環境です。旧 AAP 1.2 の環境でモジュールや Python パッケージを特に追加していない場合、既存環境を AAP 2.1 にアップデートするだけで問題なく動作する可能性が高いイメージです。ansible 2.9 ですので将来的にはより新しい、ansible-core バージョンへの移行が必要となってきますが、ansible-core 2.11 への移行期間には強い味方となります。 3. Ansible Automation Platform minimal execution environment 　ansible-automation-platform-21/ee-minimal-rhel8 ansible-core 2.12 をベースとした最低限必要なパッケージ群のみを包含した実行環境のイメージです。実行環境はカスタマイズして作成する事も可能ですが、その際のプレーンなベースイメージとしての利用も想定される実行環境です。 実行環境コンテナを使った Playbook の実行方法 ではそのコンテナ化された実行環境をどうやって使うか、ですが、方法の1つ目として automation controller を使った方法をご説明します。・・・、と言っても、説明する程の事もなく凄く簡単です。♬ 実行環境は前記した通り Red Hat Ecosystem Catalog (registry.redhat.io) などのコンテナレジストリーより提供されますが、automation controller のジョブテンプレート内で指定すれば OKです。こんな感じです。 ここまで指定しておけば、あとはジョブテンプレートを実行するだけでです。実行環境がコンテナであることを意識する必要がありません、簡単でしょ？（＾＾） まとめ 今回、AAP 2.1 で大きく変更された ansible の実行環境についてご説明しました。 その環境はコンテナ化されており、その中で、ansible-core が実行される。その実行方法についてもご紹介しました。 次回は、ansible-navigator を使った実行環境の確認と実行についてご紹介する予定です、お楽しみに。♬

Red Hat のソリューションアーキテクトの蒸野（ムシノ）です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2022/2月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: OptaPlanner 8 の新しくなった最適化問題のサンプルを動かしてみる Red Hat Business Optimizer はプランニング問題を解決するAI制約ソルバーです。複雑な制約条件下で最良の結果を得たいというようなケースの場合、どの組合せが最適なのかを現実的な時間で探索することができます。OptaPlannerをベースとしており、ルールエンジン「Red Hat Decision Manager」 の機能の一つとして提供をされています。今回は1つのサンプルを示しながら探索方法をご紹介致します。 rheb.hatenablog.com 特集2: Karavan Designerの紹介（その２） 前回のKaravan Designerの紹介の続きになります。アーキテクトやインフラエンジニア向けに、Apache KafkaのTopicを読み出して、AtlasMapで項目編集、再度Kafka Topicに出力するようなCamel DSLの書き方を紹介いたします。 rheb.hatenablog.com 特集3: TomcatからはじめるコンテナとOpenShift (その1) TomcatからはじめるコンテナとOpenShiftということで、Tomcatを題材にして、コンテナ化して、OpenShiftに持っていったら、デプロイ、tomcatの設定、NW等がどうなるか・設定どうなるなどの連載記事の第一弾となります。 qiita.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 AMQ Streams 2.0 Red Hat Integration Operator 1.3

みなさんこんにちは、レッドハットでソリューションアーキテクトをしている暮林といいます。 前回はKaravan Designerがどんなものかということを紹介いたしました。 rheb.hatenablog.com 今回の記事では、前回の予告通りノーコードでapache KafkaのPoCができるような使い方の紹介をしたいとおもいます。 Karavan DesignerにAtlas Mapを組み合わせていきます。 AtlasMapとは 使ってみる プラグインインストール 空ファイル作成 早速マッピングしてみる つなげてみる Karavan Designerから利用する まとめ AtlasMapとは AtlasMapはデータマッピングソリューションです。 www.atlasmap.io データマッピングというのは、あるサービスと別のサービス（またはデータベースなど）を接続するときに、どの項目をどの項目に移送するのか、または編集を施すのか、といった作業のことです。 このときに複雑な変換を行う必要がある場合と、よくある編集操作（たとえばTrimや文字数でカットなど）で済む場合があります。AtrasMapは後者で済んでしまうような場合に効果を発揮します。もちろんこの手の編集は通常のプログラミングでも行うことはできますが、Boring Jobになること間違いなしです。 使ってみる AtlasMapは実行可能Jarとして配布されていますが、VSCodeプラグインとしても起動できます。とはいえVSCode内で実行可能Jarを起動しているだけっぽいので、Javaが実行できる環境は必要です。 プラグインインストール VSCodeのマーケットプレースから「AtlasMap」を検索して、「AtlasMap Data Transformation editor by Red Hat」をインストールしてください。 空ファイル作成 AtlasMapプラグインは「*.adm」という拡張子に反応します。ここではためしに、「order-mapping.adm」というファイルをVSCodeのファイルメニューから作成して、ダブルクリックしてみましょう。 AtlasMapのエディターが開きましたね！ 早速マッピングしてみる 早速マッピングをしてみましょう。JsonやXMLのスキーマ、もしくはインスタンスをインポートしましょう。 少し長いですが、今回はこのJsonをつかってみましょう。適当な名前で保存してから、上記のメニューからインポートしてください。インスタンスかスキーマかをきれるので、インスタンスを選んでください。 { "schema": { "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "OrderId" }, { "type": "string", "optional": false, "field": "OrderType" }, { "type": "string", "optional": false, "field": "OrderItemName" }, { "type": "int32", "optional": false, "field": "Quantity" }, { "type": "string", "optional": false, "field": "Price" }, { "type": "string", "optional": false, "field": "ShipmentAddress" }, { "type": "string", "optional": false, "field": "ZipCode" }, { "type": "string", "optional": false, "field": "OrderUser" } ], "optional": true, "name": "user1.earth.dbo.Orders.Value", "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "OrderId" }, { "type": "string", "optional": false, "field": "OrderType" }, { "type": "string", "optional": false, "field": "OrderItemName" }, { "type": "int32", "optional": false, "field": "Quantity" }, { "type": "string", "optional": false, "field": "Price" }, { "type": "string", "optional": false, "field": "ShipmentAddress" }, { "type": "string", "optional": false, "field": "ZipCode" }, { "type": "string", "optional": false, "field": "OrderUser" } ], "optional": true, "name": "user1.earth.dbo.Orders.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "string", "optional": true, "name": "io.debezium.data.Enum", "version": 1, "parameters": { "allowed": "true,last,false" }, "default": "false", "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "schema" }, { "type": "string", "optional": false, "field": "table" }, { "type": "string", "optional": true, "field": "change_lsn" }, { "type": "string", "optional": true, "field": "commit_lsn" }, { "type": "int64", "optional": true, "field": "event_serial_no" } ], "optional": false, "name": "io.debezium.connector.sqlserver.Source", "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "id" }, { "type": "int64", "optional": false, "field": "total_order" }, { "type": "int64", "optional": false, "field": "data_collection_order" } ], "optional": true, "field": "transaction" } ], "optional": false, "name": "user1.earth.dbo.Orders.Envelope" }, "payload": { "before": null, "after": { "OrderId": 1, "OrderType": "E", "OrderItemName": "Lime", "Quantity": 100, "Price": "3.69", "ShipmentAddress": "541-428 Nulla Avenue", "ZipCode": "4286", "OrderUser": "user1" }, "source": { "version": "1.1.2.Final-redhat-00001", "connector": "sqlserver", "name": "user1.earth", "ts_ms": 1636711635163, "snapshot": "true", "db": "InternationalDB", "schema": "dbo", "table": "Orders", "change_lsn": null, "commit_lsn": "00000049:00007a08:0003", "event_serial_no": null }, "op": "r", "ts_ms": 1636711635166, "transaction": null } } このJsonはDebeziumというChange Data Captureソリューションが出力するJsonの例です。アプリとしては前半部分のスキーマが不要で、payloadの中のafterの中身だけが欲しいと想定します。今度はTarget側でインポートしましょう。（これも一旦適当なファイルに保存してください） { "OrderId": 1, "OrderType": "E", "OrderItemName": "Lime", "Quantity": 100, "Price": "3.69", "ShipmentAddress": "541-428 Nulla Avenue", "ZipCode": "4286", "OrderUser": "user1" } こんな感じになったはずです。（Payload→Afterと開いてあります） つなげてみる 勘のいい方はここからの操作は想像がついているかもしれません。左側の項目を右側の項目のマッピングしたい項目にドラッグアンドドロップしてみてください。 線が引けましたね。あとは他の項目もどんどん線をひいていきましょう。 あとはファイルをセーブしてマッピングの作成は完了です！admファイルはそのまま利用します。 Karavan Designerから利用する では当初の目的に戻ってKaravan DesignerからできあがったAtlasMapを利用するDSLを書いてみましょう。 まず最初のステップはKafka TopicNot Secured Sourceからです。検索ボックスに「Kafka」といれてSourceタブを選んでください。 ひとまずパラメータの設定はおいておきましょう。次がAtlasMapのステップです。検索ボックスにatlasといれてProducerタブを選んでください。 最後はまたKafkaですね。検索ボックスに「Kafka」といれてSinkタブを選んでください。 こんな感じになったと思います。この例では色気を出して途中でログを出力しています。（Log Sinkをつかっています） 現状のYAML DSLはこんなかんじです。 apiVersion: camel.apache.org/v1 kind: Integration metadata: name: kafkatokafka.yaml spec: flows: - from: uri: 'kamelet:kafka-not-secured-source' steps: - to: uri: atlasmap - kamelet: name: log-sink - kamelet: name: kafka-not-secured-sink あとはそれぞれのステップをクリックしてパラメータをうめましょう。 Kafka not Secured SourceについてはBrokerとTopic Namesだけいれれば十分ですが、Consumer GroupまでいれておくとKafka側でどこまで読んだか覚えてくれるようになります。（Consumer GroupはConsumerをスケールアウトしたときにきちんとそれぞれのプロセス割り振るためのパラメータですが、Consumerが1多重でもどこまで読んだかをKafka側に記憶してもらうために使うことができます） 次はAtlasMapのパラメーターです。ここはちょっと覚えゲー的なところがありますが、Resource Uriにこのようにいれてください。 file:/etc/camel/resources/order-mapping.adm パラメータを入れ終わったらファイルメニューからセーブしておきましょう。今回の例では最終的にこうなりました。 apiVersion: camel.apache.org/v1 kind: Integration metadata: name: kafkatokafka.yaml spec: flows: - from: uri: 'kamelet:kafka-not-secured-source' steps: - to: uri: 'atlasmap:file:/etc/camel/resources/order-mapping.adm' - kamelet: name: log-sink - kamelet: name: kafka-not-secured-sink parameters: brokers: my-cluster.svc topic: outcoming-topic parameters: brokers: 'my-cluster.svc:9092' topic: incoming-topic consumerGroup: group1 これでKafka Topicを読み出して、項目を編集、ログを出して、別のKafka Topicに出力するDSLがかけました！ おいおい、これじゃAtlasMapのadmファイルローカルにあるままだぞ？感じですが、Camel-Kを実行するコマンドで --resource オプションとして指定してあげるとadmファイルがクラスパスの通っている場所にアップロードされる仕組みになっています。（下記のコマンドはadmファイルをmapディレクトリに置いている前提のコマンドです） kamel run kafkatokafka.yaml --resource file:map/order-mapping.adm まとめ 今回はAtlasMapでデータマッピングを作成して、Karavan Designerのステップに組み込む方法をおつたえいたしました。 例として前後をKafkaとましたが、Camel-KのSourceとSinkには様々なサービスが使えることがチラチラと見えたと思いますので、同じようなやりかたで別々のサービスをつなげることができます。 そうはいってもREST APIで普通受けるよね？それはどうやるの？と思った方は下記のブログを読んでみてください。OpenAPI Specを使ってhttpの受け口を自動生成する方法です。 developers.redhat.com developers.redhat.com Karavan Designerについて2回の連載を行いましたがいかがでしたでしょううか？エンジニアを駆り出さなくてもサービスとサービスの接続ができそうな気がして来た！という方がいらっしゃれば幸いです。

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 今回はアプリケーション開発者の方向けに簡単に使うことができるセキュリティツールをご紹介したいと思います。 昨今、アプリケーションの多くはOSSとして提供されているパッケージを利用しており、効率的にアプリ開発を行うためにもこうしたパッケージの重要度は非常に大きいと言えます。 一方でアプリが依存しているパッケージに脆弱性が見つかれば、アプリそのものにもセキュリティのリスクが及び得ることにもなります。 こうしたパッケージの脆弱性は、SCA（Software Composition Analysis）と呼ばれるツールや、一部のコンテナスキャンツールにて検出が可能となるため、開発ライフサイクルの中の適切なタイミングで脆弱性の診断/修正を継続的に実行していくことが重要と言えるでしょう。 Dependency Analytics Dependency Analytics はRed HatがOSSとして提供しているセキュリティ診断のプラグインツールで、Red Hat CodeReady WorkspacesやVisual Studio Codeなどのコードエディタで使用することができます。 Dependency AnalyticsはSnyk社が提供している脆弱性データベースである Snyk Intel Vulnerbility Database の情報を元に、アプリの依存関係（Dependency）において脆弱性を含むパッケージの検出や修正のサポートを実施してくれます。 また脆弱性に関わる情報だけでなく、使用しているパッケージがどういった種類のOSSライセンスで提供されているかを特定し、コンフリクトの発生等を検知し表示してくれます。 Dependency Analyticsは現在以下の言語に対応しています。 ・Java ・Node ・Python ・Golang Dependency Analyticsの使い方 VSCodeを利用している場合、一般的なプラグインと同様に以下のページからインストールを行うことができます。 marketplace.visualstudio.com OpenShift上でRed Hat CodeReady Workspacesを利用している場合、デフォルトでインストール可能なプラグインとして登録されているため、こちらも簡単に使い始めることが可能です。 Dependency Analyticsで診断を実行する前提条件として、開発環境のPATHに以下が登録されている必要があります。 診断対象とする言語に合わせてこれらのバイナリを登録しておきましょう。 ・ mvn (Java) ・ npm (Node) ・ python (Python) ・ go (Golang) 使い方として、まずエディタから診断対象とするリポジトリを開き、パッケージの依存関係を記述しているファイルを開きます。 ・ pom.xml (Java) ・ package.json (Node) ・ requirements.txt (Python) ・ go.mod (Golang) 例えばNodeアプリケーションの package.json を開くと、 dependencies 以下にこのアプリで利用しているパッケージの一覧が記載されています。 表示されたパッケージのうち、バージョンの部分に赤い波線が付いているものをマウスオーバーすると、そのパッケージに含まれる脆弱性の概要を表示できます。 ここで更に"クイック　フィックス"を選択するとパッケージのバージョンを脆弱性修正済みのバージョンに簡単に書き換えることも可能です。 このプラグインのサポートにより、普段の開発作業の中でなるべく手間をかけずに脆弱性対応していくことが可能となります。 またDependency Analyticsではより詳細な脆弱性レポートを表示することもできます。 ここでは各パッケージに含まれる脆弱性の深刻さを評価するCVSSの値や、脆弱性IDについての情報を確認することができます。 このレポートではSnyk社が管理している一意の脆弱性IDが表示されますが、リンクをクリックするとSnyk社のページに飛び、脆弱性の詳細情報や一般的なCVEとの紐付けを確認することも可能です。 こうした機能を活用することでパッケージに含まれる脆弱性の詳細を確認しつつ、それらに対し適切な対処を取ることができるようになります。 まとめ 今回はDependency Analyticsについてご紹介しました。 昨今のトレンドとして、開発の段階からアプリのセキュリティを担保していくセキュリティのシフトレフトの動きが広がりつつあります。 脆弱性からアプリを保護していくという上では非常に重要なことではありますが、一方でセキュリティ担保の取り組みが開発者にとって負担にならないような仕組み作りもシフトレフトを行う上での大事なポイントと言えるでしょう。 脆弱性を検知するためのツールは世の中に多くありますが、導入のし易さや、使い易さという観点からDependency Analyticsは有効な手段の一つではないでしょうか。 ご興味湧いたら是非お試し下さい。