Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろです。 この記事は、Quarkus.io のブログ記事、 Quarkus 1.3.2.Final released - Bugfixes の翻訳記事です。 私たちはバグの修正とドキュメントの改良を経て 1.3.2.Final をリリースしました。 これは、1.3 .0.Finalまたは1.3 .1.Finalを使用するすべてのユーザにとって安全なアップグレードです。Hibernate ORMを使用している場合は、このアップグレードをお勧めします。 何が新しいの？ バグ修正 Hibernate ORM拡張で最近導入された2つの再現したバグを修正しました。 コンテナイメージ拡張も継続的に改善しています。 1.3.2.Final の完全な変更ログはGitHubで入手できます。 参加しよう 私たちはあなたのフィードバックをとても大切にしていますので、バグを報告し、改善を依頼してください...一緒に何か素晴らしいものを作りましょう! Quarkusのユーザーや好奇心の強い人は、恥ずかしがらずに歓迎コミュニティに参加してください。 GitHub にフィードバックを提供する; コードを作成して PRを行う ; Zulip や メーリングリスト で議論する; なにか質問があれば Stack Overflow で投稿してください。

Red Hat Enterprise Linux for SAP Solutionsの概要 こんにちわ。 レッドハット　ソリューションアーキテクトの石倉です。 レッドハットが提供しているソリューションが、SAP社アプリケーション向けにどのように有効活用できるかを紹介しています。 今回はRed Hat Enterprise Linux(RHEL)のSAP S/4HANA向け有効活用方法をシリーズでご紹介出来ればと考えています。 ERPシステムのシステム管理、あるいはシステム導入を担当されている方にとって、SAP社ERPソフトウェア(SAP ERP Central Component(ECC))の次期バージョン(SAP S/4HANA)へのバージョンアップのトピックスは日々注意深く、状況を確認されているかと思います。 また、様々な外部要因がある中で、2027年に向けたSAP社ERPソフトウェア(SAP ECC)のサポート終了に向けた準備を既に開始されているお客様も多いかと思われます。 SAP HANAでは、OS Platformのサポート対象が限定されている状況で、バージョンアップを検討されている皆様において、多少でも参考になる情報をお伝え出来れば幸いです。 さて、昨年2019年5月にエンタープライズLinuxとしては圧倒的なシェアをほこる、RHELが5年ぶりにメジャーバージョンアップし、新バージョンとなるバージョン8がリリースされてから、早くも1年が経過しました。 RHELでは、SAP S/4HANAに最適なディストリビューションを提供しており、バージョン8.xでも、1999年にLinux OSとしてSAPアプリケーションにサポートされて以降、同様の流れで対応をしています。 このディストリビューションは、Red Hat Enterprise Linux for SAP Solutions(RHEL for SAP)と呼ばれており、以下の機能を有しています。 RHELをベースにSAP Business Applicationsに最適化されたSubscriptionパッケージ Locale、Libraryを含む追加コンポネント Red Hat Enterprise Linux for SAP Solutions ー追加コンポネントー - 赤帽エンジニアブログ High Availability(高可用性)Add-Onの同梱 Red Hat Enterprise Linux for SAP Solutions ーHA Addonー - 赤帽エンジニアブログ SAP用System Roleの同梱 Red Hat Enterprise Linux for SAP Solutions ーSystem Roleー - 赤帽エンジニアブログ SAPユーザ限定の特別なアップデートサポート(Update Services for SAP Solutions) Red Hat Enterprise Linux for SAP Solutions ーE4Sー - 赤帽エンジニアブログ Red Hat Insights Add-On Red Hat Enterprise Linux for SAP Solutions ーRed Hat Insights Add-Onー - 赤帽エンジニアブログ Live Kernel Patchingによる脆弱性対策の無停止適用 SAP社〜レッドハット社のバックラインでの連携 (付帯情報)初めてでも安心、充実したトレーニングコース (付帯情報)他事例から学ぶ、失敗しないLinux化の進め方 本シリーズでは、RHEL for SAPの特徴的な機能や情報を個別にお伝えしていきたいと思います。 なお、RHEL8(Red Hat Enterprise Linux 8)そのものの機能紹介に関しては、以下をご一読頂くのが良いかと思います。 rheb.hatenablog.com

Red Hatの森若です。 今日はRHEL上でコンテナを使うときにちょっと不思議なアレについておはなしします。 Red Hat Universal Base Image 1年とすこし前、Red Hat Universal Base Images (以下UBI) というコンテナイメージが公開されました。 これはRHEL 7および RHEL 8の基本的なコンテナイメージと、さらにRHELの約1/3のrpmパッケージをEULA契約のみで無償で入手でき、さらに自由に利用・再配布できるというものです。 単に入手再配布が簡単というだけでなく、これをベースにアプリケーションのコンテナイメージを作成すると、Red Hatのコンテナ環境上(RHELまたはOpenShift)であればUBI部分もRed Hatからのサポート対象になります。 この仕組みが登場したことで「通常の契約ではRHELは再配布できない」という制約を部分的にゆるめ、OSSプロジェクトを含むISVがRHEL対応ソフトウェアのコンテナイメージを作成しやすくなりました。 UBIについて詳しくは、以下のページをごらんください。 developers.redhat.com Red Hatのテクノロジーパートナーによる認定コンテナイメージについては、2020年2月にさらに制約をゆるめるアナウンスが行われ、kernel以外の全てのrpmパッケージを配布できるようになっています。こちらについては以下の記事をごらんください。 developers.redhat.com RHELのベースイメージとしてのUBI さて、UBI自体はRHELを契約していなくても利用できますが、UBIはRHELのベースイメージを兼任しています。ついさっきUBIで「RHELの約1/3のrpmパッケージ」が利用できると書いていたのに、UBIに含まれないRHEL一般のrpmパッケージはどうやって使うのでしょうか? 実は、RHEL上でUBIを利用すると 自動的に RHELのリポジトリを利用できるようになります。今回はその仕組みをちょっと見てみましょう。 RHELのサブスクリプション情報はどこにある? RHELのユーザであれば、多くの方が subscription-manager を利用してシステムを登録し、システムとサブスクリプションとを対応づけたことがあるかと思います。この作業をすることで、 yumコマンドによるパッケージの導入などが利用できるようになります。(パブリッククラウド上のものに一部例外があります。) 普段あまり意識することはありませんが、これらのコマンドの裏側では複数の証明書を利用して個別のシステムを識別し、製品の種類や、いつからいつまで利用可能かなどを管理しています。 $ ls -l /etc/pki/product-default/ # 製品の種類 total 4 -rw-r--r--. 1 root root 2171 Mar 31 20:15 479.pem $ ls -l /etc/pki/entitlement/ # サブスクリプションの情報 total 144 -rw-r--r--. 1 root root 3247 Jun 8 15:24 5747300626421762999-key.pem -rw-r--r--. 1 root root 141049 Jun 8 15:24 5747300626421762999.pem $ ls -l /etc/pki/consumer/ # システムの識別情報 total 8 -rw-r-----. 1 root root 2228 Mar 9 17:35 cert.pem -rw-r-----. 1 root root 3247 Mar 9 17:35 key.pem UBIへホストRHELのサブスクリプション情報を共有する コンテナ内からRHELのリポジトリを利用できるよう、コンテナ実行時にホスト側のサブスクリプション情報を自動的にコンテナ内の(揮発する)ディレクトリへコピーしています。 具体的には、containers-common パッケージで提供される /usr/share/containers/mounts.conf が起点となります。このファイルにはホストの特定ディレクトリからコンテナの特定ディレクトリにファイルをコピーする設定を記述します。(ファイル名がまぎらわしいのですがbind mountではなく再帰的なコピーが行われます。) $ cat /usr/share/containers/mounts.conf /usr/share/rhel/secrets:/run/secrets ホストの/usr/share/rhel/secrets には、あらかじめサブスクリプション情報が含まれるディレクトリへのシンボリックリンクが作成されています。 $ ls -l /usr/share/rhel/secrets total 0 lrwxrwxrwx. 1 root root 20 Apr 21 03:17 etc-pki-entitlement -> /etc/pki/entitlement lrwxrwxrwx. 1 root root 28 Apr 21 03:17 redhat.repo -> /etc/yum.repos.d/redhat.repo lrwxrwxrwx. 1 root root 9 Apr 21 03:17 rhsm -> /etc/rhsm コンテナ内のyumでは、これらの情報を参照することでRHELのリポジトリを使うことができます。 UBIでRHELリポジトリを利用する サブスクリプションを登録したRHEL上で podman run -it bash ubi8 のようにして起動したコンテナの中で、利用できるリポジトリを確認してみましょう。RHELのリポジトリが利用できることがわかります。 # yum repolist Updating Subscription Management repositories. Unable to read consumer identity Subscription Manager is operating in container mode. repo id repo name rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) ubi-8-appstream Red Hat Universal Base Image 8 (RPMs) - AppStream ubi-8-baseos Red Hat Universal Base Image 8 (RPMs) - BaseOS ubi-8-codeready-builder Red Hat Universal Base Image 8 (RPMs) - CodeReady Builder コンテナイメージの中に製品証明書が含まれていて適切なリポジトリが選択されるので、ホストのRHELとコンテナUBIのバージョンが異なっていても問題なく利用できます。 ためしてみよう Red Hat Enterprise Linux 8を試せるラボを公開しています。以下リンクのラボではRHEL8のコンテナの基本的な利用をためせるほか、シナリオの中にないコマンドも自由に入力できます。以下のようなコマンドを試すとこの記事の理解が深まるかと思います。 ホスト側で # podman pull ubi8 # podman run -it ubi8 bash コンテナ内で # yum repolist # yum list coreutils # yum list postgresql # ls /run/secrets/ https://lab.redhat.com/podman-deploy lab.redhat.com

こんにちは。Red Hat Decision Manager ジャック4日目です！ 昨日の内容 に引き続き、その4をお送りします。 ルールエンジンでどんなことができるのか？ 業務内容と照らし合わせると、ルールエンジンは下記のようなことに適用できます。 ルールエンジンでできないことは下記になります。 画面や帳票の生成 データサービスへの読み書き 他システムとの連携 トランザクション処理 セッションプール等の管理 メールの送信 普通のif-then-elseと何が違うのか？ Java/C言語などでロジックを記述する場合、if文、for文、while文、case文等を駆使して書くのが一般的と思います。例えるならば、通常のロジックは「網の目」を作っていくような感覚です。一方、RETEアルゴリズムをベースとしたPhreakアルゴリズムを搭載するルールエンジンは、when - then のみでelseを記述しません。また、for文 while文等も記載しません。 Red Hat Decision Managerのルールエンジンはパターンマッチングという考え方から来ています。パターンマッチングとは、「神経衰弱ゲーム」を思い浮かべていただくとよいです。1枚めくって、それと同じ絵柄の違う一枚を引き当てると(whenに相当)それを自分の得点とする(thenに相当)ようなゲームです。ゲームではマッチが完了するまで繰り返します。 ルールエンジンでは、whenの「パターン」にマッチするかどうかを判定します。もしマッチすれば、thenを行います。また、繰り返し処理はマッチした分だけルールエンジンが勝手に処理してくれます。 一般的なプログラムでのif-then-else のelseは、条件にマッチしなかった場合の行動になります。ルールエンジンではelseに相当するパターンで何かを行う必要がある場合、else 相当する条件を whenに書き、thenを構成します。 一見するとルールが増えて面倒なことをやっているように思えますが、ルールをwhenとthenだけで構成することで、構造としてはシンプルになります。 whenにマッチすればthenを行う、whenでマッチしなかったらthenは行わない。 この法則を徹底することで得られるメリットは、必要な場合だけルールとして書き、不必要な場合は書かない、もしくは不必要になったら削除する（＝メンテナンスが容易になる）ということです。 今までのif-then-else/for/while文形式の場合、ifの中にwhileがあり、elseの中にさらにifがあり... となって、まさに「ロジックのスパゲッティ」が生成されてしまいます。そして、要らなくなったロジックは消していましたでしょうか？殆どの場合、ロジックを消すことによる副作用が見えず、死蔵されてきているのではないかと思います。その使っていないロジックも考慮した上で新しいロジックを追加していくものですから、どんどん複雑化し、切り出すことも不可能になってしまいます。 「ロジックの断捨離ができる」アプリケーションとなっていることで、常に単純化ができるようになります。これが「持続的にメンテナンス可能なシステム」であり、ルールエンジンとスクラッチ開発の大きな違いです。 ちょっと触ってみたいという方向けに、有償ハンズオンの資料部分のみを下記サイトで公開しております。 http://redhat.lookbookhq.com/rhdm_handson2019 ルールエンジンの呼び出し方は？ POJOでの呼出し、RESTでの呼出し方があります。何にせよ、大本になるものは、KieServicesになります。説明することが少々恥ずかしくなりますが、Kieは “Knowledge is Everything” から来ているらしいです。KieServicesはルールエンジンを動かす・支援する機能を生成するためのインターフェースで必ず必要になります。 KieServicesからKieContainer を生成します。KieContainerはまさにルールを動かすためのコンテナであり、KieBaseやKieSessionを生成することができます。 KieBaseはルール本体です。作成したルールはファイルなどからKieBaseに格納されます。KieSessionは実際にFactを投入したりルールを動かすためのセッションであり、ルールエンジンの実体になります。 POJOの場合はこれらのKie APIを組み合わせてルールの実行を行います。 Red Hat Decision ManagerにあるExecution Serverを利用すると、上記のようなKieAPI関連のオブジェクト生成を全て隠蔽して、RESTアクセスで行うことができます。（KieContainerID、KieSessionIDはパラメータとして渡す必要はあります） バッチ処理に使えるのか？ Red Hat Decision Managerは、オンラインの処理にもバッチ処理にも利用可能です。ルールエンジンに投入するデータ（FACT）の形として、1件でも複数件でも同じように扱えるようなルールを記述しておくと、オンラインとバッチで同じルールを利用することが可能です。 しかしながら、バッチ処理といっても数千万件のデータを一度に扱おうとすると、ルールとデータ間での組み合わせ数が爆発的に増えてしまい、メモリの枯渇や性能が出ない場合があります。データとデータの相関関係がない範囲で、一度に投入するFACTの数に制限を設けて実行することをお勧めしております。（ルールを呼び出す側でデータを分割してルールを繰り返し実行する、データは一度Queueに入れて、Publish/Subscribeのような仕組みを利用してルールエンジンを多重化するなど） ルールの数や投入するデータの量、項目数などに依存するため、何件ずつ処理を行うのが良いのかは一概に申し上げられません。是非、1件、2件、5件、10件、20件、50件、100件... のように数を増やしながら、許容できるTurn Around Timeとメモリ使用量となるような件数を見つけ出して、最適な件数を決めることをお勧めします。 DRLとかが独自言語で、他社との可搬性とかあるのか？ DRL(Drools Rule Language)はUpStreamコミュニティであるDrools.orgにて制定した形式になっており、そのままRETEアルゴリズムを利用している他社のルールエンジンで利用することはできません。しかしながら、例えば同じRETEアルゴリズムを搭載するIBM社のOperational Decision Manager製品で使用されているIRL(ILOG Rule Language)は、DRLと言語としての構造はかなり似通っております。その他の会社製品では書き方は異なるものの、ルールの考え方は同一であり、呼出し方なども含めたアーキテクチャとしては同じなので、原理原則に基づき正しく実装されたルールにおいては、乗換えを行う場合もゼロから作り変えるほどの労力は必要無いと思われます。 最適化は同じデータであれば同じ結果となるのか？ Red Hat Decision Managerの一つの機能として、Business Optimizerという、組合せ最適化のための機能があります。ルールエンジンを使って、沢山ある組み合わせの中からより良い組み合わせを探索することができて、いままで担当者が気づかなかったような、より良い組み合わせをITの力を使って高速に見つけることができます。 組み合わせ問題を解く際には、どの組合せから始めるかによって最適解が出るまでの時間が変わります。これは与えるデータを変えるという意味もありますし、最初のマッチングを作る時にランダムに行うという意味もあります。ですが、ランダムでしか行えないとすると、探索手順の妥当性などが検証できなくなります。 Business Optimizerでは、解の求め方をSolverConfig.xmlで定義しています。Solverの実行モードは、この中にある タグで設定をします。DefaultではREPRODUCIBLE となっており、特殊な設定をしない限り再現性はあります。開発時はREPRODUCIBLEで行うことでバグの発見がしやすくなります。 一方、本番環境ではPRODUCTIONとすることをお勧めします。組み合わせの作成をランダムにすることで、より良い解をより高速に求められる確率を高める設定となります。 ルールのアクションでは何ができるのか？ ルールエンジンはディシジョンサービスとも定義できます。サービスとは、要求を投げたら期待する答えが返却される形の概念です。ルールエンジンはアプリケーションから呼ばれて、アプリケーションに答えを返すだけが仕事になります。 従って、ルールエンジンのアクション部分(thenの部分)において、他のWebサービスを呼び出す、メールを送信する、DBやQueueにデータを書き込む等のアクションを行うのは適切ではありません。Javaのコード自体は書けてしまうので技術的には出来てしまいますが、アーキテクチャとして制限を設けて、閉じた世界に徹することをお勧めします。サービスの概念を遵守し、ディシジョンサービスは答えを返すのみのアクションとしましょう。データサービスやメッセージサービスを利用する場合は、ルールの呼び出し元（各サービスを連携するアプリケーション）にて適切なサービスにデータを渡す形とします。 いかがでしたでしょうか。 一旦はこちらで終了とさせていただきますが、皆様からのリクエストやお客様からのご質問が増えてきたらその5〜を書きたいと思います。 Chief Technologist 梅野

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろです。 この記事は、Red Hat Developerのブログ記事、 Mandrel: A community distribution of GraalVM for the Red Hat build of Quarkus - Red Hat Developer の翻訳記事です。 Javaコミュニティは、開発者とユーザーのニーズに合わせて進化、改善、適応する能力を何度も実証してきました。言語とフレームワークの選択に25年を費やした後も、 Java はエンタープライズ・ユース・ケースでの強力な実績と機能により、 現在使用されている 言語 の中で常に 上位 に位置しています。Red Hatは長い間、Javaおよびオープンソースソフトウェア開発における強力なリーダーであり、進化を続けるJavaの最前線であり続けることを約束してきました。 今日、Red Hatと GraalVMコミュニティ は共同で、 Mandrel と呼ばれるGraalVMの新しいダウンストリームディストリビューションを確立しました。このディストリビューションは、最近発表され Red Hat Runtimesへの追加 された QuarkusのRed Hatビルド に搭載されます。この記事では、Mandrelとは何か、なぜMandrelが必要なのかについて説明します。 今後のJava Red Hatはここしばらくの間、 Javaの将来 と、同社の顧客と開発者が長年のJavaの経験を、 コンテナ や マイクロサービス 、 Kubernetes といった新しい世界でどのように活用し続けられるかに注目してきました。Javaの経験は言語以外にも適用されます–Hibernate, CDI, RESTEasy, MicroProfile,あるいはEclipse Vertなどのリアクティブフレームワークなど、開発者の身体に深く染み付いたライブラリやフレームワークも数多く含まれています。 Quarkusプロジェクト は2019年に立ち上げられ、Kubernetesと サーバレス という新しい世界でJava開発者に必要な進化のステップを提供しました。要するに、Quarkusは Javaというゲームのルールを変更します 。Javaアプリケーションとそれを支えるフレームワークの両方を最適化して、それらがデプロイされる制約のある環境によりよく適合するようにし、 Java初期のアーキテクチャと設計の選択を逆転させます。Quarkusネイティブのアプリケーションは、Kubernetesと同じように、スケーリングと弾力性によって処理されるスループットを犠牲にしても、メモリ使用量を大幅に削減します。また、Kubernetesで分かったように、不変のデプロイメントアーキテクチャでは不要なオーバーヘッドが発生していますが、動的な実行時の動作を犠牲にしても、起動速度を高速化します。 Quarkus と GraalVM GraalVM はエコシステムであり、Javaを含む様々な言語にパフォーマンス上の利点を提供する共有ランタイムです。非常に最適化されたJavaアプリケーションを作成するために 事前のコンパイル を行うことができるため、従来のJVMデプロイメントよりも小さなフットプリントでJavaを実行するのに特に適しています。数年前にGraalVMプロジェクトが紹介されたことで、Quarkusとそれが提供する多くのフレームワークを設計し、このツールで使用できるようにすることは非常に理にかなうことでした。この決定により、Quarkusアプリケーションはさらに最適化され、開発者が使い慣れている豊富なAPIを犠牲にすることなく、シームレスかつ容易に連携できるようになります。GraalVMはQuarkusストーリーの重要な部分となっており、Red Hatはその成功にコミットしています。Red Hatは GraalVMプロジェクト諮問委員会 のメンバーであり、ネイティブイメージのデバッグ機能の改善、AArch 64ネイティブイメージのサポート、Java Flight Recorder (JFR) のサポートの継続など、GraalVMコミュニティの機能と修正を定期的に提供しています。 Red Hatは最近、私たちの顧客による本番環境での使用について Quarkusのサポートを発表 しました。 QuarkusのRed Hatビルド を使用することで、私たちの顧客はKubernetesとサーバーレスアプリケーション用に完全にサポートされ、高度に最適化されたJavaソリューションを手に入れることができます。開発者はGraalVMを使ってQuarkusアプリをネイティブバイナリにコンパイルし、クラウドやKubernetes向けに最適化することもできます。この機能は現在、GraalVMコミュニティと協力して テクニカルプレビュー を行っているので、Quarkusを使ってRed Hatの顧客をサポートすることができます。それでは、Mandrelの話に移りましょう。 Mandrel（マンドレル） Red Hatのオープンソースコミュニティへの献身は、同社のエンタープライズグレードのサポートモデルを支えています。私たちは、オープンソースの革新がRed Hatだけでなく、Red Hatが提供するコミュニティの成功にも不可欠であると確信しています。GraalVMは大きな動きがある大規模なプロジェクトであり、 Red HatやOracle,その他多くのGraalVMコミュニティメンバからのコントリビューションが毎日行われています。 私たちのオープンソースへのコミットメントを守りつつ、顧客をサポートする最良の方法は、アップストリームの対応するものと協調して構築されたダウンストリームのオープンソースディストリビューションを確立することであることがわかりました。 Fedora と CentOS を使ったLinuxのダウンストリームディストリビューション、 OKD を使ったKubernetes、そしてGraalVMのダウンストリームディストリビューションとしての Mandrel があります。これらのコミュニティは協力して、双方にとって理にかなった方法でオープンソース技術を進化させています。これはまた、Red Hatが 「アップストリーム優先」 の精神で、アップストリームから逸脱しないことを好むように、製品化プロセスにおいてさえ、オープンに革新を続けることを可能にします。 QuarkusにとってGraalVMの重要な部分は、ネイティブ実行可能ファイルを生成するネイティブイメージ機能であり、クラウドネイティブのワークロードでJavaを競争力のあるものにするための重要な機能です。Mandrelを使うと、Red Hat Enterprise Linuxやその他のOpenJDK 11ディストリビューションのOpenJDK 11上にGraalVMをバンドルすることができます。GraalVM側では、リリースのタイミングが必要な場合には、進行中のJava Flight Recorderなどの機能を、 GraalVMよりも早くMandrelでサポートすることができます。したがって、Mandrelは、特別にパッケージ化されたGraalVMネイティブ・イメージを持つ通常のOpenJDKのディストリビューションとして説明するのが最適です。 ユーザにとっての違いは最小限ですが、保守性の面では、 OpenJDK 11とGraalVMの両方を使用したアップストリームのアラインメントが非常に重要です。これは、OpenJDKとGraalVMコミュニティ内で作業している熟練したエンジニアがいるので、Red Hatが顧客により良いサポートを提供できることを意味します。 Mandrelを使うことで、Red Hatの顧客とGraalVMコミュニティの両方が真にオープンな開発から利益を得ることができ、Red Hatは、実証済みのメカニズムで顧客をサポートすると同時に、オープンソースコンピューティングの最先端を前進させ続けるために依存しているアップストリームコミュニティに還元することができます。

こんにちは。Red Hat Decision Manager ジャック3日目です！ 昨日の内容 に引き続き、その3をお送りします。 ルールエンジンを適用したほうが良いケース・よくないケースは？ 「変更の多いところにはルールエンジン、そうでないところはJavaで」というお話をよく聞きますが、この基準で適用を判断することはオススメしません。アプリケーションは時代の流れや業務の修正などによって常に変わっていくものです。業務アプリケーションの三大要素である、ルール・データ・プロセスについては、管理としては集中させ、互いを疎結合にしてサービス化・マイクロサービス化して稼働させることで可変性最大限に引き出せます。 アプリケーションアーキテクチャとして、ルールを「ディシジョンサービス」、データを「データサービス」、プロセスを「プロセスサービス」と位置づけ、チェック・判断・計算・推論の類は全て「ディシジョンサービス」とすることを強くオススメします。サービスという考えを導入して機能をカテゴライズすることで、一部はソースコードに、一部はルールエンジンに、一部はSQLとして等とロジックの分散化を排除すことが可能です。管理上においては、ロジックはディシジョンサービスに集中させるべきと考えています。 一方、業務ではないルール（制約）もプログラム上は出てきます。例えば、ある項目がnullかどうかを判断しないとNull Pointer Exceptionが出てしまうような場合、例えばDBに投入する際の桁あふれなどを防ぐための桁数チェックなどは、システム側の制約になります。このようなチェックは、Javaであればpojoのレベルでアノテーションを付けることでチェックすることも可能です。その場合は「業務に関連しない、システムとしての単項目チェックはpojoにてチェックすること」などと設計書に明記しておくことをお勧めします。 ただし、ある項目のチェックにおいて、A事業部とB事業部では同じ項目でも解釈が違うのでチェックすべき内容が違うとなると、それは業務ルールになりますので、ルールエンジン側でチェックを掛けるほうが良いケースになります。データの使い方をよく考えることが重要です。 ルールエンジンの適用基準は、「アプリケーションの改変をスムースに行うという観点で、アプリケーションアーキテクチャとしてディシジョンサービスを想定した時にその役割を担うものの全て」が大前提となります。そのうえで業務的な制約や使い方になっているかどうかを吟味して決定することをお勧めします。 Business Centralは使うのか？ Red Hat Decision Managerには、ルールの作成・管理の為のWeb ApplicationであるBusiness Centralが添付されています。Phreakアルゴリズムを利用するDRL形式のルール記述、意思決定表形式のルール記述、BPMN2.0のモジュールを利用したルールフローの記述が可能です。新しいルールの記述方式であるDMN形式にも対応しています。FACT(Javaのclassに相当）の為のツールも備わっています。また、ルールのテスト、シミュレーションに必要な画面等も用意されています。 ルールの実行環境としてDecision Server (KieServer)を利用した、REST形式で呼び出す場合は、Business Centralとの親和性が高く、簡単なルールであれば、Javaの知識をほとんど持たずともルールを記述することは可能です。 しかしながら、Decision Serverは、多数のアプリケーションからリクエストを受け付けることが可能になるため、CPU/Memoryのサイジングが難しいです。また、アプリケーションからはRESTでの呼出しになるために、月末締めバッチ処理等の大量一括処理には向きません。 ご採用頂いている日本の多くの事例においては、REST呼出しの他にEJB/POJOの呼出し等も多く、またFACTの設計として複雑な構造を持つものや、Javaによるメソッドが追加されることがあり、Javaによる開発が伴います。Business Centralでの作業よりもCodeReady Studio (旧名 JBoss Developer Studio) やMicrosoft Excelを利用したルール開発・ルール呼出しアプリ開発が多いのが実情です。 テストはどのようにすればよいのか？ 書いたルールに対するテストについてです。通常のJava等の開発であれば、作ったメソッド毎にテストケースを書いてテストをする、いわゆる単体テストを行うのが一般的です。単体テストの場合、全ての分岐を通るようなテストパターンを作ったりします。 ルールの場合、ルール一つ一つに対する単体テストを行うことは稀です。というのも、記述するルールの多くは単純なルールが多く、それはルールを評価するというよりもルールエンジンを評価するものに近くなってしまいます。品質が保証されていないコミュニティ版をご利用になるのであれば、そのようなテストも意味があるかもしれませんが、製品として提供しているRed Hat Decision Managerの場合は品質を保証しているわけですから、ルールエンジンを評価するようなテストは不要です。 ルールは複数のルールをまとめて構成し、ディシジョンサービスとして提供するのが一般的です。その場合、結合テストのようにディシジョンサービスへの入出力の結果をもってテストを行います。さらに、ルールエンジンが採用しているPhreakアルゴリズムは、FACTがルールによって書き換えられたことをトリガーに再評価を行う機構を有しています。この場合、データやルールによっては数百万通りにも及ぶ組み合わせができる可能性があり、パスとして定義することが事実上不可能になります。その意味でも、ルールに与える入力値と期待値を予め用意しておき、ルールエンジンの実行結果と期待値を比較した上で合否判定を行う方法をお勧めしています。 ルールエンジンはトレースのログを出力することができます。ログを出力すると性能の低下がみられるために本番環境では無効化しますが、開発・テスト環境においては入力したFACTがどのような順番でルールが実行されたのか、Audit Logを取ることができます。テストにおいて否定されたデータが有る場合、そのデータのみを開発環境で流し、Audit Logを取得して動作の検証を行います。 開発ツールであるCodeReady Studioを利用すると、Break Pointを置いたステップ実行によるデバッグも可能です。 ルールの全てをExcelで編集できるのか？ ルールエンジン=意思決定表(Excelのシート)のイメージが強いと思います。表形式はわかりやすいのです。意思決定表は、ルールエンジンが動作するために必要なDRL形式のルールを生成するためのツールという位置づけです。つまり、意思決定表で記述したものは全てDRLに変換されて動作します。 意思決定表で記載すると扱いやすいルールは、同じような判定条件が1,000件未満であるような場合になります。それ以外の場合は、DRLと併用します。 大概の場合、意思決定表は固定値や範囲値を持ちます。その行数や列数が少ない場合は編集しやすいので便利ですが、その数が10,000にもなると、シートをスクロールするだけでも時間がかかります。このような場合、究極的に申し上げると、意思決定表にせずに、マスターデータに相当するような判定する値を持ったFACTとルールに入力されたFACTとを比較する、メタルールのような形式にすることで、ルールの数を減らしてデータ同士のマッチングにできます。10,000を超えるような判定は「マスターデータ」としてデータベースで扱うほうが頻繁な変更対しては扱いやすくなりますし、ルールは固定値を持たない汎用的なルールとして記述できます。 データとルールの整理を行い、ルールのメンテナンス性や性能面などを総合的に評価した上で、DRL形式や意思決定表形式をうまく組み合わせて利用することをお勧めします。 次でラストー！ Chief Technologist 梅野

こんにちは。Red Hat Decision Manager ジャック2日目です！ 昨日の内容 rheb.hatenablog.com に引き続き、その2をお送りします。お楽しみくださいませ。 製品トレーニングはあるか？ Red Hatのコンサルタントが提供しているRed Hat Decision Manager HandsOn（有償）を受講いただくのが一番効率よく、かつ、皆様が抱えている課題に対してディスカッションを行うことで、より深い理解が得られますのでお勧めしております。 一方で、ちょっと触ってみたいという方向けに、有償ハンズオンの資料部分のみを下記サイトで公開しております。 http://redhat.lookbookhq.com/rhdm_handson2019 また、オンライントレーニングとして、Red Hat Global Learning Serviceより下記のコースを提供しています。 JB731R Decision Manager and Red Hat Process Automation Manager for Business Users JB737R Red Hat Decision Manager and Red Hat Process Automation Manager for Developers 下記サイトからお申し込みが可能です。 https://www.redhat.com/ja/services/training/learning-subscription オンライントレーニングを受講しての質問は、ラーニングコミュニティという下記サイトにて受け付けています。 https://learn.redhat.com/ RHへの支援要請は開発段階からでよいか？ いいえ。システムの要件定義の時点から必要になります。 ルールエンジンを導入することの目的は、業務要件の変更に柔軟に対応することです。そのためには、アプリケーション・アーキテクチャをサービス化・マイクロサービス化に対応させる必要があります。 一般的にルールエンジンを含むアプリケーションの設計開発では、何をルールとするのか、何をデータとするのかの整理が重要になります。この整理を早い段階で行うことで、データとロジックの分離構造がとりやすくなり、アプリケーション全体のシンプル化に繋がります。 また、既にあるアプリケーションを刷新する場合、ソースコードの解析から始めるケースが多いのですが、大概の場合は旧来のフレームワークの制約などにより構造が固定概念化してしまい、「多少整理されたけど今までと同じ構造」になりがちです。この場合、数年後には現状と同じ状況に陥りかねません。 Red Hat ではアーキテクチャを根本から見直して、メンテナンス性を向上させ品質良くプロジェクトを進める手法を提供しています。プロジェクトのなるべく早い段階から支援を要請いただくことで、リスクの低減と品質の向上が行われ、結果的にコストの削減につなげることが可能です。システムの要件定義の時点から要請いただくことを強くお勧めします。 設計手法はあるか？ Red Hat Decision Manager 特有の設計手法はありませんが、Object Management Group [1]で提唱されいている、Decision Model and Notation [2]をベースとした、データとロジックの明確化を行い、ルール間の関連性の整理を行います。その情報を元に、ルールの構成やサービスとしての実行単位の構成などを決定していきます。 また、Red Hat Decision Managerは「メンテナンス性の向上」を目的としたツールであり、ただ単に動けば良いというものを作るツールではありません。ルールを改変する担当者が、時間を掛けずに変更できる形式にする必要があります。このため、設計時においてもプロトタイプを作成し、担当者にレビューしてもらい、より良い形に再設計していく手法も合わせて必要になります。 [1] https://www.omg.org/index.htm [2] https://www.omg.org/dmn/ 開発方法論は何を選択すべきか ウォーターフォールからスクラムまで、世間では沢山の開発方法が論じられています。Red Hat Decision Managerの役割は、業務の変更に柔軟に対応できる仕組みとすることに他なりません。どういうことかと言うと、運用開始後の要求変更があった時に、短時間で改修が完了することを意味しています。つまり、ちょっと作って確認するような使い方がベストとなります。 初期の開発時から、「ちょっと作って確認」という開発をやってみるのはいかがでしょうか。アジャイルやスクラムのように聞こえますが、基幹システムのような箇所で使われるルールエンジンは、一部だけがリリースされても使えません。画面やデータベース等が揃って、はじめて基幹業務ができます。リリースするタイミングは全部揃ってからになるのですが、ルールエンジンをディシジョンサービスとして定義し、インターフェースを決めておくことで、ディシジョンサービスとしてのテストを繰り返しながら品質良く作ることが可能です。これをイテレーション開発と言います。大前提となることとして、アプリケーションアーキテクチャをしっかり策定しておくことが必要です。データ・プロセス・ルール・画面をサービス化し、それぞれが疎結合となるアーキテクチャを取ることを強くお勧めしています。 また、基幹システムの更改のような、アプリケーション・モダナイゼーションでは、ソースコードの解析から入りがちな現行要件確認をせず、既存のソースコードをほとんど見ずに業務要件から直接設計・実装する「ルール駆動開発」というものもお勧めしています。品質良く短期間で実装ができ、その後のメンテナンス性も向上する手法です。 業務テンプレートはあるか？ 似たような業務をお持ちの会社は沢山ありますので、業務テンプレートがあると早く構築ができると思われる方も多いと思います。しかし、記述するルールはデータの形に依存するため、データの型が同じでないとテンプレートが利用できません。弊社でのプロジェクト経験からすると、データモデルが同じケースは一つとしてありませんでした。さらに、ルールとして定義している部分はその会社特有のポリシーであるため、全く応用が効きません。 お客様のポリシーを尊重してお客様の業務を伸ばすためにも、業務テンプレートを用いて業務を他社と同じにすべきではないと考えております。 パフォーマンスチューニングの観点は？ RETEアルゴリズムをベースとしたPhreakアルゴリズムは、パターンマッチング技術を利用しており、Fact(データ)とルールのマッチングを行います。この時に、複数のFactとルールにより、ルールエンジン内のAgendaという領域に複数の組み合わせができます。 Agendaにある実行待ち候補を優先順位に基づき一つ一つ実行するのですが、ある組み合わせを実行することで再評価が走り、先に作成した組み合わせが無効化されるケースがあります。その数が多いと、組み合わせを作成することが無駄になり、速度低下になる可能性があります。 再評価してくれるアルゴリズムは、for文等を書かなくとも条件にあうデータとルールの組み合わせを自動的に実行してくれるので、ソースコードの単純化には大きく寄与しますが、組み合わせが数百万もできるような場合は速度低下となるところがあります。 Phreakアルゴリズムでは、評価（組み合わせの作成）時にキャッシュで対応できるところは即反応し、そうでないところはキャッシュでの反応が終わった後に評価する「遅延評価」という仕組みを入れて、作成する組み合わせの数の削減を自動的に行うような仕組みを導入しています。 最終的には、ルールの書き方や評価の順序を見直したり、一度に投入するデータ量を調整することで、内部的な組み合わ作成の数を減らすようなチューニングを行います。 まだまだ続きます。明日もお楽しみに！ Chief Technologist 梅野

皆様こんにちは、Red Hat ソリューションアーキテクトの岡野です。 前回 に続き、今回は、vSphere 環境を Ansible Tower で操作するための具体的な方法についてご説明したいと思います。♬ ※今回一連のブログで利用する Playbook は こちら に公開しています。 この一連のブログは、vSphere 環境と、Ansible Tower の環境を準備頂き、実際に操作しながら読んでいただけると理解が深まって良いと思います。ということで、Ansible Tower のインストール方法も書いておきます。ご存じの方は読み飛ばしてください♪ 1. Ansible Tower のインストール インストールは極めて簡単です。 RHEL 8 を基本インストール ※2CPU 4GBのリソースが必要です！ バイナリ を入手し解凍 inventory ファイルの編集 ./setup.sh でインストール # wget https://releases.ansible.com/ansible-tower/setup/ansible-tower-setup-latest.tar.gz # tar xvzf ansible-tower-setup-latest.tar.gz # cd ansible-tower-setup-<version> # vim inventory ファイル内の以下2か所にパスワードを設定 admin_password='password' pg_password='password' # ./setup.sh Ansible Tower のインストールはこれで完了です！ 2. vSphere の操作に必要なコンポーネントのインストール Part 1 でご説明した通り、Ansible Tower で vSphere 環境を操作するためには、 PyVmomi と、 vSphere Automation SDK が必要になります。 PyVmoni は vSphere Automation SDK に含まれますので、 vSphere Automation SDK をインストールしておきます。Windowsの仮想マシンも自動化の対象としたい場合は、 pywinrm もインストールしておきましょう。インストール先は、そう、Ansible Tower 上です。♪ # wget https://bootstrap.pypa.io/get-pip.py # python get-pip.py # pip install git+https://github.com/vmware/vsphere-automation-sdk-python.git # pip install pywinrm 準備完了です！これで、Playbook を書いて、Ansible Tower から vSphere 環境を操作できます！！ 3. Playbook の作成 まず手始めに、vCenter Server に対して、データセンターの作成・削除を行う Playbook を作って実行してみましょう。何故、データセンターから？というと、『オプションが少なくて簡単だから』、というのと、万が一間違ったオペレーションを Playbook の中に書いてしまったとしても、他の vCenter Server のオブジェクトに影響を与える可能性が低いということがあります。特に、Playbook を初めて書く方は、まず簡単な Playbook から作って動かしてみることをお勧めします。 簡単なことでも Ansible で動かすと、きっとその面白さに気付くと思います。♪ そして次がやりたくなる。その繰り返しがとても大事です。♬ では、vmware_datacenter モジュール詳細を見てみましょう。 docs.ansible.com モジュールの詳細も見慣れてくると Parameters あたりから”スーっと”入っていけるのですが、最初は難しく感じるかもしれませんので、Examples から眺めてみましょう。Examples は Playbook の中の実行内容である Task について記入例を示しています。 利用モジュール (vmware_datacenter) を宣言して、vCenter Server への接続情報を入力、データセンター名を指定し、作成か削除かを指定します。 ここで、 '{{ vcenter_hostname }}' など、 '{{ }}' で記述されている部分は変数です。Playbook 実行時に値を入力します。こちらは、後程 Ansible Tower の説明の中でご説明します。 ここまで理解した上で、モジュール詳細の Parameters を見てみてください。 なるほどという感じでしょうか。♬ ここまでが、このモジュールに対する Parameter の設定です。 Delegate_to: localhost というのは、この Task をローカルで実行するための宣言です。vCenter Server に対する Ansible 実行は、ローカルホスト上で Playbook を実行しながら、vSphere Automation SDK 経由で、vCenter Server の操作を行います。このため、Task （Playbook と考えても大丈夫です）の実行先は vCenter Server ではなく、ローカルホストとなります。そのため、このように記述します。Playbook の実行先が、 Localhost で指定してあれば、特に記載の必要はありません。・・・って、ちょっと難しいでしょうか。ま、理解が難しかったら、最初は『おまじない』と思っていただければ大丈夫です。まずは難しいことの理解より動かすことの方が遥かに重要です。♬ この Task に Play部分（実行条件など）を上部に追加したものが Playbook です。 今回使う Playbook (createDC.yml) は こちら です。 --- - name: vSphere datacenter Manage hosts: all gather_facts: no tasks: - name: vSphere Datacenter Manage vmware_datacenter: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" datacenter_name: "{{dc_name}}" state: "{{dc_state}}" validate_certs: False delegate_to: localhost Play 部分で、hosts には all を指定していますが、後程 Ansible Tower のインベントリーで、Localhost を指定するので、実行ホストは 自分自身となります。 gather_facts は、対象ノードの情報を自動的に集めてくる仕組みなのですが、今回は必要ないので、 no としています。 変数が先ほどよりも少し複雑な表記になってますね。こちらは、vCenter Server への接続情報を Ansible が持つ環境変数から取り込むための記述方法です。環境変数に対する値の入力は Ansible Tower から簡単に行う事が出来ますので後ほどご説明します。♪ また、 state を変数で定義しています。これは、作成削除を実行時に決められるようにするためです。 4. Ansible Tower を使った Playbook の実行 さていよいよ Ansible Tower で Playbook を実行するための設定を行っていきましょう。♪ Playbook は上記した Github にあるものを使います。 https://<ansible_tower_ip>/ で Ansible Tower にアクセスし、admin / password でログインします。Ansible Tower には色々なオブジェクトがありますが、Playbook を動作させるために設定が必要なのは、以下で示す 4 つです。では順に設定していきましょう。 1. プロジェクトの作成 プロジェクトは Ansible Tower 独自のオブジェクトなのでなじみのない方も多いと思いますが、Playbook の保存されているパスを管理するための仕組みです。Ansible Tower 自身のローカルパス（/var/lib/awx/projects/）配下や、Git等のSCMを利用する事が出来ます。今回は Git を使います。 　　 プロジェクトを選択し、続いて右にある、緑色の "+" をクリック。以下を入力して保存します。 名前 : vmware-pro SCM : Git SCM URL : https://github.com/hiro52/tower-demo.git SCM 更新オプション : 起動時のリビジョン更新にチェックを入れます 2. インベントリーの作成 インベントリーは Ansible Tower でも、対象ノードを記述する場所です。早速登録します。今回、Playbook の実行先は Ansible Tower 自身なので、localhost 用のインベントリーを作成します。 　　 インベントリーを選択し、緑色の "+" をクリックして、表示されるプルダウンで "インベントリー" を選択。 名前 : localhost を入力して、保存をクリック。さらに、上部にある ホスト をクリックします。 緑の "+"をクリックし、 ホストの作成画面で、 ホスト名 : localhost を入力して、保存をクリックします。 ※なお、ホストの登録方法として、変数に 　ansible_host: <Ansible_Tower_Ipaddress> 　と入力することも可能です。ここでは簡単のため、ホスト名にそのまま localhost を入力しています。 3. 認証情報の取得 次に、認証情報の作成します。認証情報は以下の2つを作成します。 ・Localhost 用の認証情報 　Ansible Tower自身に ssh ログインするための認証情報 ・vCenter Server 用の認証情報（こちらは以下2つの用途で利用します ） 　Playbook で定義した環境変数への値の入力 　vCenter Server が持つ仮想マシンインベントリ情報を取得するため（今回は使いません　次回以降利用予定です） では作成しましょう。♪ 認証情報を選択し、続いて右にある、緑色の "+" をクリック。以下を入力して保存します。 Localhost アクセス用 名前: localhost 組織: Default 認証情報タイプ: マシン ユーザー名: <ssh 接続ユーザー> パスワード: <ssh 接続パスワード> 続いて、vCenter Server 用も作成します。 vCenter Server アクセス用 名前: vcenter 組織: Default 認証情報タイプ: VMware vCenter VCENTER ホスト: <vCenter Server IP Address> ユーザー名: <vCenter Server 接続ユーザー> パスワード: <vCenter Server 接続パスワード> 4. ジョブテンプレートの作成 ジョブテンプレートも Ansible Tower 独自のオブジェクトです。上記したプロジェクト、認証情報、インベントリーを紐づけて Playbook が実行する仕組みを提供します。実行時の変数入力に関する設定もここで行います。ジョブテンプレートが完成すれば、Playbook の実行が出来ます。あと一歩です。♪ テンプレートを選択し、緑色の "+" をクリックして、表示されるプルダウンで "ジョブテンプレート" を選択。以下の情報を入力します。全て今まで作成してきたものです。 名前: vCenter DC 管理 ジョブタイプ: 実行 インベントリー: localhost プロジェクト: vmware-pro PLAYBOOK: createDC.yml 認証情報: localhost (認証情報タイプ: マシン) / vcenter (認証情報タイプ: VMware vCenter) ※vCenter Server の認証情報は、環境変数への値の入力に利用されます 入力後、右下の緑の保存をクリックします。・・・、ここで終わりではありません、もう少し。そう、変数入力ですね。 変数入力について 今回使う Playbook （createDC.yml） には以下の、5つの変数が定義されていました。 hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" datacenter_name: "{{dc_name}}" state: "{{dc_state}}" このうち、1～3は、テンプレートで定義した vcenter の認証情報から『環境変数経由』で、自動的に入力されるので考慮は不要です。残りのデータセンターの名前と、データセンターの有無の状態の定義が必要となります。Ansible Tower ではこの定義を Survey という概念で与えることが可能です。 先ほどのジョブテンプレート作成の画面で、上部の SURVEY の追加 をクリックし、2つの変数に与える値を下記の通りそれぞれ定義しましょう。 データーセンター名の定義 プロンプト: DCの名前 回答の変数名: dc_name 回答タイプ: テキスト デフォルトの応答: DC2 　※お使いの vSphere の環境に合わせて適当に変えてください。未使用のデータセンター名をお勧めします。 入力が終了したら、 +Add をクリックし、もう一つの変数入力を定義します。 作成 or 削除の定義 プロンプト: DC 作成 or 削除 回答の変数名: dc_name 回答タイプ: 複数の選択（単一の選択） 複数選択オプション: present absent デフォルトの応答: present 入力が終了したら、 +Add をクリックし、右下の保存をクリックし、ジョブテンプレート入力画面に戻ります。さらに、 保存 をクリックし、ジョブテンプレートを保存します。 はい、長くなりましたが、これで完了です！！♪ さっそく実行してみましょう♬ 保存の左側にある、青い 起動 ボタンをクリックします。 Survey で定義した変数入力値がポップアップされることを確認します。 次へをクリックし、さらに、起動をクリックしてみましょう！ データセンター作成されましたか？♬ 無事動いたら、今度は、 DC 作成 or 削除 でプルダウンから absent を選択して実行してみましょう。削除されると思います。 まとめ さて、Part 2 如何でしたでしょうか。今回は以下をご説明しました。 ・Ansible Tower のインストール ・必要なコンポーネント（vSphere Automation SDKなど）のインストール ・Playbook について ・Ansible Tower での Playbook 実行方法 ・vCenter Server の環境変数とその与え方 ・Survey を使った変数の入力方法 お楽しみいただけましたでしょうか。 次回、 Part3 では、もう少し複雑かつ実践的な、ESXi ホストに対する各種設定を行っていきたいと思います。インストールしたばかりの ESXi が vMotion 出来る様になります。♬ Ansible Tower のバイナリーと評価ライセンスは以下から取得可能です。是非使ってみてください！！ ・Ansible Tower バイナリーダウンロードは こちら から ・Ansible Towerの評価ライセンスは こちら から 　※Customer Portal のアカウント作成が必要です。 （2020年8月4日追記） 一連のブログが終了しましたので、各回に対するダイレクトのリンクを貼っておきます。 Part1 ：Ansible Tower で vSphere の何をどうやって自動化できるのか Part3 ：Ansible Tower を使った ESXi ホストの自動構築とvMotion による確認 Part4 ：info モジュールを使った vSphere 環境の構成の確認 Part5 ：仮想マシンの作成とアプリケーションの構築・設定、ダイナミックインベントリの利用、仮想マシン情報（タグ情報）の取得について

こんにちは。レッドハットでプリセールスを担当している梅野です。 本日から4日間連続で、ここ赤帽エンジニアブログをジャックして、Red Hat Decision Manager でよく聞かれる話シリーズをお届けします。 アプリケーション・モダナイゼーションの要とも言えるコンポーネントとして注目を集めている、ルールエンジン製品、Red Hat Decision Manager。 今回から数回に分けてお届けするのは、営業活動でよく聞かれるご質問に対して回答する形でブログを書いてみました。 必要なハードウェアのスペックは？ ルールエンジンの稼働はJavaVM上となります。サポートされているJava VMであれば、対象とするハードウェアチップに依存性はありません。つまり、IBM JDKをご利用の場合はIBM JDKがサポートしている、z/OSやAIX, IBM iシリーズでの稼働も可能です。 RHDMにてサポートされるJava VMは下記のサイトに記載があります。 https://access.redhat.com/articles/3354301 ルールエンジンが使用するCPU負荷やメモリ使用量は、書かれたルールの数や複雑度、一度に投入するデータ量やデータ項目量、ルールでマッチングした時の候補数等に依存します。RETEアルゴリズムベースのエンジンであり、オブジェクトとオブジェクトの組み合わせをルールに基づき作成し、オブジェクトに対して操作を行い、場合によっては再評価を行い繰り返し処理を行うというような動作をするために、事前に計算することがかなり困難です。 プロトタイプを作成し、ある程度のボリュームでデータを流し、Turn Around Time やメモリ消費量を確認した上でハードウェアスペックを決定することを強くお勧めしています。 ディスク容量は、格納するルール、残しておきたいLogファイルとその期間、稼働させるアプリケーション・サーバー等によって異なりますが、おおよそ5GB以上あればよいでしょう。 ルールを呼び出す方法は通常、RESTかEJB/Pojoになりますので、ネットワーク環境としては通常のアプリケーションに準じた帯域や優先度となります。 GPUでの稼働は想定されていないため、GPUユニットなどは必要ありません。 必要なソフトウェアは？ Red Hat Decision ManagerはサポートされているJavaVMがあれば稼働します。 2020年5月時点では OpenJDK Version 8 もしくは 11 OracleJDK Version 8 IBMJDK Version 8.0.5.11 となっていますが、対象の製品のテストが終了次第、随時追加されていきます。詳細は下記サイトにて必ずご確認ください。 https://access.redhat.com/articles/3354301 ルールを作成するツールとして、EclipseベースのRed Hat CodeReady Studio (旧名 Red Hat JBoss Developper Studio)、製品に添付でWebブラウザを利用したBusiness Centralが提供されています。サポートされるアプリケーションサーバ、ブラウザは下記サイトにて確認できます。 https://access.redhat.com/articles/3354301 意思決定表はマイクロソフト社のExcelに準拠した.xlsファイル、もしくは.xlsxファイルであり、所定の記述方式に則った記載になっていれば、ルールエンジンに直接取り込むことが可能です。Microsoft Excelの他、Google Sheets等もご利用になれます。意思決定表はBusiness Centralにて記述することも可能です。 作成したルールやソースコードの管理として、Github等のリポジトリ（バージョン管理ツール）の利用をお勧めします。 ルールを含むアプリケーションのビルド環境として、maven等のリポジトリの利用をお勧めします。Internetに接続できる環境であれば、pomファイルに記述しておくことで常に最新のリポジトリを参照してビルドすることが可能です。Internetに接続できない環境の場合、製品としてはmaven リポジトリを各マイナーバージョン毎に用意していますので、ダウンロードしてmavenのローカルリポジトリに登録してお使いください。 アプリケーションサーバ上で稼働させる場合は、JavaEEに対応するアプリケーションサーバが別途必要になりますが、ルールエンジンを稼働させる場合、Red Hat Decision ManagerはRed Hat JBoss Enterprise Application ServerのSubscriptionを含みますので、この用途に限った場合は別途必要はありません。 Red Hat Decision Manager はデータベースを必要としていません。 サポートしているOSは？ Red Hat Decision Managerのサポート対象はJava VMです。データベースやOSはサポート対象ではありません。OSはJavaVMがサポートしているOSをお使いください。サポートしているJava VMはこちらのサイトに記載されています。 https://access.redhat.com/articles/3354301 上記ページ内に「Tested Configuration」「Tested Integrations」というのがありますが、これは「この組み合わせでテストしました」というだけで、この構成でしかサポートしないという意味ではありません。 コンテナ対応は？ Red Hat Decision ManagerのExecution Server(KieServer)はコンテナにも対応しており、Kubernates等のコンテナ管理ツールを利用して、Podのスケールアップ・スケールダウンやコンテナの起動停止が可能になっています。OpenShift Container Platform上のコンテナイメージを作成するためのyamlテンプレートを配布しています。必要な項目名（アプリケーションの名前、表示名、URL等）を決定し、ocコマンドを実行することでコンテナイメージが出来上がり、Pod上でコンテナとして稼働させることが可能です。 アプリケーション内部に抱え込むような実装方式、つまりExecution Server(KieServer)を使用しない場合は、アプリケーションのコンテナイメージとしてのBuild/Deployに準じます。 どのようなコンテナ環境においても、Red Hat Decision ManagerがサポートするのはJava VMとなります。ただし、Red Hat OpenShift Container Platform以外のコンテナ環境においては、同様の事象がベアメタル上のOSで動作するサポートしているJavaVM上でも再現可能であることが示された場合にのみサポート対象となります。Red Hat OpenShift Container Platformをご利用の場合は、コンテナイメージごとサポートすることが可能です。 Serverless対応は？ メモリ消費量の削減や起動時間の短縮化を目的としたServerless環境は、OpenJDK上で動作するQuarkusプラットフォームをベースとしたKogito（コジトと発音）環境を提供予定です。従来の構成では年1回しか動作しないルールもデプロイしておく必要がありましたが、Kogitoで実装された場合は、そのルールを含むアプリケーションはオンメモリとして常駐させず、必要なタイミングで起動し、終了したら自動的にメモリ領域を開放することもできます。 2020年5月現在、Kogitoは製品化を目指してコミュニティで醸成中です。 https://kogito.kie.org/ 製品のバージョンアップ方法は？ Red Hat Decision Manager Version 6 から Version 7へバージョンアップする際には下記の点についての考慮が必要でした。 KieService関連のライブラリの入れ替え 　MavenにてBuildを行う場合はpomファイルを書き換えます。 ルールフロー 　Version 5までのルールフローを使用していた場合、Version 6から導入されたBPMN2.0形式のルールフローに書き換えます。 Business Central 　Webアプリケーション自体を入れ替えます。 下記の点については、特殊な例を除き基本的には考慮する必要がありませんでした。 DRLファイル、.xlsファイルに記載されたルール本体 KieSessionを作成するソースコード本体 ルールの格納リポジトリ なお、将来のバージョンに関しては言及出来かねます。Subscriptionをご購入の上、カスタマーサポートにお問い合わせください。 その2 に続きます。 Chief Technologist 梅野

皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 5/19に開催させていただいた、ウェビナー、 ” ユースケースから学ぶ、Ansible AutomationによるVMware環境の自動化 ” にご参加いただいた方、ありがとうございました！登録約1,000 人、参加は650人を超えたと聞いています。質問も凄くたくさんいただきまして、改めてこの領域での自動化のニーズってあるんだなぁと思いました。1時間という限られた中でどこまで解説できるか、チャレンジングではあったのですが、満足度もそれなりに高かったようで、やって良かったと思ってます。♪ 個人的な予想を遥かに上回る反響があったこと、また、当日は時間制限があって、なかなかお伝え出来なかったこともありますので、こちらのブログで、Ansible Towerを使った VMware vSphere 環境の自動化について、つらつらと何回かに分けて書いていきたいと思います。Ansible を使った VMware 関連の自動化の際、よく聞かれる ”こんなことできますか？” の質問に対しても、具体的な手法をご紹介できれば良いなぁと思っています。 ウェビナーにご参加いただいた方は復習兼ねてご覧頂ければ幸いです。♬ ＜本ブログの目的＞ ・Ansible Tower を使って vSphere 環境の何が自動化出来るのか。自分がやりたいことが Ansible で出来るのか？その調査方法について理解する ・実際にどうやればよいのかを理解する 　必要なコンポーネントと Playbook の書き方など この一連のブログを読んでいただければ、 『 仮想OS含めた vSphere 環境に対して Ansible Tower で自動化できるようになる！』 というところを目指します。Roles を使った Palybook の最適化など Ansible の少し高度な使い方については踏み込まず、vSphere 環境で良くある作業を簡単な Playbook で書いて、それを Ansible Tower で実行出来る様になるところを目指したいと思います。 ＜想定する対象者＞ VMware vSphere 及びその周辺（仮想OS、スイッチ、ストレージ、AWS等のクラウド）の管理者の方を想定しています。このため、vSphere をはじめとする Ansible 管理対象機器ついては知識があるものとしてご説明を割愛しています。あらかじめご了承ください。 ＜環境＞ このブログでは以下の環境を想定しています。 ・vSphere 7 (vCenter Server 7 & ESXi 7) ・Ansible Engine 2.9 / Ansible Tower 3.7 ※vSphere 6でも問題なく動きます。ま、せっかく新しい vSphere 7が出たのでこちらでやってみました。♪ また、本ブログでは こちらの Playbook を利用します。可能な限り環境依存なパラメータは排除していますので多くはそのまま利用可能なのではないかと思います。 Part 1 調査方法について 前置きが長くなりました。第1回目は調査方法についてご説明したいと思います。 Ansible のセミナーを行うと、終了後、”これ出来ますか？” という質問を良くいただきます。その場ではお答えさせていただいておりますが、『Ansible 化の可否』についてご自身で答えが出せないと、いつまでたっても不明点やモヤモヤが残り実装が進みません。そこで、まずこの点をテーマに開始したいと思います。 Ansible の主な構成要素は Inventory ファイル、Playbook 、モジュールの3つです。 この中で、 『Ansible でこれ出来るの？』 は、モジュールを調査すると分かります。 モジュール一覧は こちら にありますが、 "ansible modules" で検索いただくとすぐに出てきます。VMware 用のモジュールは、Cloud Modules の中にありますが、 こちら です。この一覧のそれぞれはリンクとなっていて、クリックすることによりモジュールの詳細を把握する事が出来ます。 ※この中で（D）のマークがついたものは、Deprecated で、廃止予定となっていますので使わないようにしましょう。 　Dマークがついたものを除いて、123個のモジュールがあります。 最初は英語なのでとっつきにくそうに感じるかもしれませんが、vSphere Client をしょっちゅう触っている管理者の方であれば、一覧を見ると何となく何をやるモジュールか分かるのではないかと思います。ちなみに、よく聞かれる質問の一つに、 『ESXi ホストに対するライセンスの適応って出来ますか？』 というのがあるのですが・・・、モジュールありそうですよね。♪ このモジュール一覧の記述は、 モジュール名 - モジュール概要 となっています。例えば、 vmware_cluster_ha – Manage High Availability (HA) on VMware vSphere clusters であれば、 モジュール名：vmware_cluster_ha モジュールの目的：Manage High Availability (HA) on VMware vSphere clusters を示しています。 これを見れば、vSphere の管理をしたことのある方であれば、アドミッションコントロールの設定や仮想マシンモニタリング等、VMware HA の細かいパラメータの設定が行えるのではないか？ということが何となく想像がつきますよね。何となくわかる事、それがまずはとても大事です。♪ この一覧の中にあればモジュールを使って簡単に Ansible で管理する事が出来ますし、無ければ、Red Hat としては手出しの出来ないものにはなりますが、 このあたり とか、VMware の自動化のツールである、PowerCLI など他のツールとの連携を考える必要が出てきます。逆に言うと、Ansible で何とでもやりようはあるのですが、その点は今回は置いておきます。♬ ちょっと脱線しましたが、一覧の中には他にも、vmware_cluster_drs や vmware_cluster_vsan など、分かりやすい名前と目的が記載されています。 ここでは、一例として、vmware_datacenter を見てみましょう。 vmware_datacenter – Manage VMware vSphere Datacenters をクリックします。 モジュール名と目的、そして、動作要件が記載されています。 python 2.6 以降、PyVmomi と記載がありますが、こちらは、管理対象ノード側ではなく、Ansible 側の要件です。 モジュールによって動作要件は異なりますが、VMware モジュールの場合は、PyVmomi と vSphere Automation SDK が必要となります。なお、 vSphere Automation SDK の中には、PyVmomi が含まれていますので、vSphere Automation SDK のみインストールしておけば大丈夫です。 こちらはオプションの記述に関する説明です。必須のオプションであるかどうかやオプションに与えることのできる引数も記載されています。赤い破線で強調した部分が良く使われるオプションです。 datacenter_name：データセンターの名前 hostname：vCener Server のホスト名（IPアドレス） password：vCener Server に接続するためのパスワード username：vCener Server に接続するためのユーザー名 state：作成 or 削除 ま、何となくわかりますよね。vCenter Server に認証情報使ってログインして、データセンター名を指定して、データセンターを作成・削除する。その際のパラメータを与えているだけです、簡単ですよね。♬ このオプションまで確認すれば、自身がやりたい事が出来るのか出来ないのかという事が明確に分かります。 ※ちなみに、 state というオプションは Ansible の他の多くのモジュールにも存在します。ここで面白いのは、 state に対して、 create / remove とは書かずに、 present / absent という書き方をする点です。Ansible では、 『動作』 でなく 『最終状態』 を記述します。既にデータセンターが存在する状態で present を実行すると、既にあるのでそのタスクはスキップされます。逆に、 『存在しない状態』 であれば、 『存在する状態』 にしてくれます。つまり作成されます。これは、Ansible の冪等性という性質で、 if-then （もしなかったら作ってね）の様な事前の確認は不要です。 『最終的にこうして欲しい』 と書けば、そうしてくれます。記述がとても簡単になるのと同時に、実行した後の結果の信頼度は非常に高いものとなる Ansible の優れた特徴です。 実際のPlaybook (正確には Playbook 内の Task) の記述例が書かれています。ここを確認すると、オプションの具体的な指定方法などが分かります。 ここでは、オプションが少なく簡単な vmware_datacenter モジュールを使って調査方法をご説明させていただきました。例えば、仮想マシンを作成・削除したり、電源操作を行ったりするようなモジュールとしては、 vmware_guest があって、こちらはオプションがたくさんあり一見難しく見えるのですが、vSphere 環境でテンプレートから仮想マシンを良くデプロイしている方であれば、何となく何が出来そうかということが分かると思います。vSphere Client で仮想マシン作る際も、テンプレート、データストア、ポートグループ、カスタマイズオプション、ネットワーク設定などなど、いっぱいオプション指定しますよね。それがモジュールのオプションに置き換わっているだけですのでそれほど難しいものではありません。 ＜まとめ＞ さて、第1回目は、自身のやりたいことが Ansible で出来るのか？その調査方法についてご説明させていただきました。 モジュール一覧 を眺めてみる 該当しそうなモジュールがあったら詳細を確認してみる Task の書き方の例を見て記述方法もつでに学んでおく これが最初の一歩となります。♬ ここが突破できれば、あとは Playbook を書いて、Ansible Tower で実行するだけです。 では、 次回 、Playbook の具体的な書き方についてご説明したいと思います。 Ansible Tower のバイナリーと評価ライセンスは以下から取得可能です。是非使ってみてください！！ ・Ansible Tower バイナリーダウンロードは こちら から ・Ansible Towerの評価ライセンスは こちら から 　※Customer Portal のアカウント作成が必要です。 （2020年8月4日追記） 一連のブログが終了しましたので、各回に対するダイレクトのリンクを貼っておきます。 Part2 ：vSphere モジュールを使った Playbook の書き方とAnsible Tower での実行方法について Part3 ：Ansible Tower を使った ESXi ホストの自動構築とvMotion による確認 Part4 ：info モジュールを使った vSphere 環境の構成の確認 Part5 ：仮想マシンの作成とアプリケーションの構築・設定、ダイナミックインベントリの利用、仮想マシン情報（タグ情報）の取得について

はいども、ストレージを生業にしているソリューションアーキテクトの宇都宮(うつぼ)です。お久しぶり。 今日はストレージのマニアックな話ではなく、ちょうど1ヶ月前にRed Hat Summit 2020のセッションをご紹介します。やっぱりストレージですけど。 Red Hat Summit 2020 Virtual Experience 今年のRed Hat Summitは新型コロナウイルスの感染拡大を防ぐために史上初のバーチャル開催でした。バーチャル開催になることでGeneral Sessionはもちろん好きなBreakout Sessionが観放題、しかも無料となりました。日本からも結構多くの方がご覧になったのではないかと思います。 ※リアルタイムでの視聴はネットワークが混雑しすぎてお世辞にも気持ちいい体験だったとは言えないと思いますが…今後の大きな課題としてとらえます もちろん我が生業のストレージに関するセッションもありました。インフラスキーな貴兄貴女はストレージのセッション観ていただけましたよね？……よね？ いや観てないというかたのために、今日は1つだけストレージのセッションをピックアップしてご紹介します。ライトな内容なのでおやつタイムにでも読んでいただければと！ The Cloud OS—OpenShift with OpenShift Container Storage 本セッションはDell EMC社, Intel社, Red Hatからそれぞれ1人ずつ、計3人のスピーカーが話しています。 Arkady Kanevsky Chief Technologist, Dell EMC, Service Provider Strategy and Solutions, Infrastructure Solutions Group David Tuhy VP&GM, Intel, Datacenter Optane Division, Non-volatile Memory Solutions Group Ranga Rangachari VP&GM, Red Hat, Red Hat Storage この3社は10年以上前からコラボレーションしていて、HW/SWともに新しいテクノロジーを採用したインフラを合同で開発/検証したり、Reference Architectureを作ったりなどしています。 そんな3社がいま注目するのはやはりコンテナプラットフォームで、本セッションではOpenShiftとその最適なストレージであるOpenShift Container Storageに関する話を繰り広げます。 ITの"メガトレンド"とストレージに対するチャレンジ 現在のITのメガトレンドは、 　①ハイブリッドクラウドまたはマルチクラウドなシステム環境を利用すること 　②AIやML(機械学習)といった"データセントリック"な処理を行うこと です。 最近だと②をやろうと思ったら①みたいなインフラを見据えてやるのかなーと思います。 そしてこれらのトレンドではデータの扱いに対していくつかのチャレンジが出てきますが、おおむね3つに集約できます。 『スケーラビリティ、パフォーマンス、ポータビリティ』 です。 スケーラビリティ データセントリックな処理はデータが命です。AIやMLの処理は2桁GB級のデータが必要となることは珍しくなくなり、3桁GB級にも至らんとしています。押せば命の泉湧く、がごとく無尽蔵にデータが増える今日、ストレージのスケーラビリティは必要不可欠でしょう。 ストレージのスケーラビリティは多分にデバイスの容量に依存します。様々な技術の発展によりHDDやSSDといったデバイスの容量はものすごい勢いで増えています。1本40TB超のHDDも出てくるとか。 SSDでは言わずともがな3D NANDですね。bitを保存するメモリセルを鉛直に重ねることで面積あたりの容量を大きくしています。1本100TB超(GBじゃない)のSSDもそろそろ出てくるでしょう。 また分散型のストレージソフトウェア使うことで、ストレージノードを水平方向にいくつもスケールすることができます。 パフォーマンス 一方でパフォーマンスには課題が残ります。ストレージのパフォーマンスは詰まるところデバイスの性能に依存しますが、残念ながら容量が増える速度に追いついていません。 用途によりますが、データセントリックな処理においては、ストレージの容量が増えれば格納されるデータが増え、比例して発生するI/Oも増えるのが自然です。 しかしその途中でデバイスのI/O性能が限界に達し、ストレージのパフォーマンスの、ひいてはシステムのボトルネックとなり得ます。デバイスの数を増やせばストレージ全体としてのI/O性能を向上できますが、TCO観点では最適な方法とは言いがたいでしょう。 ここでIntel社のTuhy氏が言うには、 「DRAMの代替として開発されたIntel Optaneのような、高速デバイスをSSDの上位層に置くことで、SSDのI/Oボトルネックを解消することができる。より少ないノードとデバイスで同等のパフォーマンスを提供でき、TCOの改善に貢献する」 とのこと。 大容量なSATA/SAS SSDやHDDが担えないような性能要求を、Optaneのような3D XPointの技術を使った超高速なデバイスが中間で受けることで、ストレージ全体のパフォーマンスを向上できるということです。 またTuhy氏によると、Optaneを使うことで19ノードのストレージと同じIOs/TBを7ノードで達成できたそうです。デバイスの高速性がノードの数を減らし、結果としてTCOを削減しながらパフォーマンスを満たせるという例です。 ポータビリティ スケーラビリティとパフォーマンスは言わばストレージの内部の話でしたが、ポータビリティはストレージの外の話です。データのポータビリティは、ストレージを展開する自由度に帰結します。 「アプリケーションのモデルはモノリシックからマイクロサービスに変遷している。同様にシステム基盤も疎結合なモデルになるべくOpenな技術を利用した”Best of Breed”(それぞれ最適な部品を組み合わせて利用すること)な手法に向かう事は自然な動きである」 とはDell EMC社のKanevsky氏。 プラットフォームが存在するのがプライベートクラウドかパブリッククラウドかなどは問わず、全体としての最適化を追求することが好ましいと言うことですね。 また同氏は 「AI/MLのような大量のデータを利用する処理は、より素早い意思決定を可能とすべくクラウドのCore部からデータが生まれるEdge部に移って実行される傾向が見られる。よってCore/Edgeを問わず展開でき、容量と性能が共に拡張できるSoftware-defined Storageは必要となる」 と言います。 いやーほんまええ事言うわぁ。 OpenShift Container PlatformとOpenShift Container Storageが果たす役割 先の通り、AI/MLのようなデータセントリックな処理は、データが生まれるその場所で実行されることが理想的です。わざわざ特定の場所に大量のデータを転送するのは時間もかかるし、ネットワークリソースも必要になるためです。 いかなる環境でも全く同じ処理ができるよう、アプリケーションをコンテナ化して可搬な形態にすることはもはや必要不可欠です。そこで、OpenShift Container PlatformとOpenShift Container Storageはとても大きな役割を果たします。 OpenShift Container Platformは、Private/Publicのクラウド形態や、Core/Edgeといったロケーションの違いを問わず、どのような環境でも展開して稼働できるコンテナプラットフォームです。 そしてOpenShift Container Storageも同様に、OpenShift Container Platformが稼働していればどのような環境でも展開・稼働できるSoftware-defined Storageです。 OpenShift Container Storageは特定のハードウェアやデバイスに依存することがなく、自由度が高いSoftware-defined Storageです。そのためワークロードの要件に応じて大容量なデバイスを使うなり、超高速なデバイスを使うなり、適切な拡張を行うことができます。ワークロードにマッチしたストレージを用意することで、Total Costを引き下げることができます。 Red HatのRanga氏はセッションの最初から最後までOpenShift Container PlatformとOpenShift Container Storageは『ゲームチェンジャー』だと言っています。 OpenShift Container PlatformとOpenShift Container Storageを利用したシステム基盤は、モダンなワークロードが稼働するシステム基盤が直面する3つのチャレンジ、 『スケーラビリティ、パフォーマンス、ポータビリティ』 の全てに対応ができます。 これらを使った柔軟なシステムプラットフォームを展開することによって、アプリケーションアーキテクチャの変革を促進することができる。まさに『ゲームチェンジャー』ですね。 それでは今日はこのへんで。

レッドハットの森若です。 Red Hat Enterprise Linux 8.2もでて、「そろそろRHEL8を使ってみようかな」という人も増えてきたのではないかと思います。 RHEL 8 ではアプリケーションストリームが導入されていますから、一部パッケージは10年の標準的なライフサイクルではなく、2年から5年程度の短い期間だけ維持されます。 ではどのパッケージがいつまでサポートされるのでしょうか? この記事ではその調べ方をご紹介します。 その前にまず2点ほど前提知識をご紹介します。 Compatibility Level Red Hat Enterprise Linux では、RHEL5の頃から Application Compatibility Guideを公開し、各パッケージについての互換性維持を4段階のレベルに分けています。 RHEL 7までは、以下のようになっていました。 Compatibility Level (以下CL) 1は3つのメジャーバージョンに渡ってAPI/ABIの互換性を維持 CL 2では1つのメジャーバージョン内でAPI/ABIの互換性を維持 CL 3は将来のため未使用 CL 4は互換性を維持しません。 RHEL 8では、CL 3が新しく登場し、以下のように変わります。 CL 1は3つのメジャーバージョンに渡ってAPI/ABIの互換性を維持 CL 2では1つのメジャーバージョン内でAPI/ABIの互換性を維持 CL 3は各コンポーネントについてあらかじめ定義された期間維持し、期間が終了する前に新しいバージョンを継続的に提供 CL 4は互換性を維持しません CLが記載されていないものはCL 2です。 CL4であってもパッケージの提供はRHELのメジャーバージョン中維持されますが、API/ABIの互換性が失われる更新が行われる可能性があります。 厳密な定義や、CL 1, CL 2, CL 4のパッケージ一覧はガイドに記載されています。 access.redhat.com Application Streams Lifecycle RHEL 8で新しく導入された CL 3に該当するのが Application Streams Lifecycleです。 access.redhat.com この表に記載されたコンポーネントはライフサイクルがRHEL 8の10年(2019年5月から2029年5月まで)とは独立したものになります。 Application Streamsはフルサポート中はどんどん新しいバージョンに対応したストリームが出てきますが、2024年5月にメンテナンスフェーズに入る前にいずれかのストリームが指定され、メンテナンスフェーズ中はそのストリームだけがメンテナンスされます。 注意が必要な点として、Application Streams Lifecycleが定義されたパッケージはEUSおよびELSのいずれの対象にもなりません。 10年維持されるパッケージはどれ? やっと標題の質問に戻ります。「10年維持されるパッケージはどれ?」という質問に答えるには、CL 3またはCL 4でないことを確認する必要があります。 つまり https://access.redhat.com/articles/rhel8-abi-compatibility#Appendix にあるCL 4の表と、 https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle にあるApplication Streams Lifecycleの表を参照して、これらに掲載されていないことを確認すると、RHEL 8と同じライフサイクルの間、API/ABIが維持される形でメンテナンスされることがわかります。 例1: Python RHEL 8.2には Python 2.7, 3.6, 3.8が含まれています。 これらについて以下2つの表を確認すると、以下のことが言えます。 Python 2.7 → CL 3。2024年6月までサポート Python 3.6 → どこにも記載がないのでCL 2。RHEL 8と同一期間サポート Python 3.8 → CL 3。2023年5月までサポート Pythonについては 3.6がRHEL 8と同じ期間維持されることがわかります。 Compatibility Level 4のパッケージ群 Application Streams Lifecycleの一覧 例2: PHP RHEL 8.2には PHP 7.2, 7.3が含まれています。同様に確認すると、以下のことがわかります。 PHP 7.2 → CL 3。2021年5月までサポート PHP 7.3 → CL 3。2021年11月までサポート 前述のとおりEUSもELSもApplication Streams Lifecycleが設定されているものは対象になりません。そのためPHPの処理系について 「利用開始してからのバージョン変更が不可能」 でかつ 「2021年12月以降もサポートが必要」 な場合には、RHEL同梱のものを利用するのではなく別途長期間のサポートを提供している企業を探すか、運用計画を変更して途中でのバージョン更新を盛り込むなどの対応が必要なことがわかります。

Red Hatのソリューションアーキテクトの松田です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ミドルウェアラインナップが充実していることをご存知ですか？ ここでは、Red Hatのミドルウェアに関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 月イチくらいのペースで続けたいと思います。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集１:ついにリリース！超高速に開発できて超軽量に動く次世代Javaフレームワーク「Quarkus」 Quarkus を使うためのビジネス的なメリットや技術的なメリットの両面から簡単に以下について紹介します。 Quarkus を使うビジネス的なメリットである、開発コストと稼働するコストの削減、市場へ価値を届ける時間の短縮、信頼性について また技術的なメリットである、開発者に嬉しい、超高速で超軽量、様々なスタイルでの開発、様々なライブラリとの融合について Quarkusのビジネスと技術的な価値 from Chihiro Ito www.slideshare.net 特集２:「Red Hat Integration」提案のしどころ Red Hat Integrationのユースケースや提案メリットについて以下の2つのトピックでご紹介します。 Red Hatのミドルウェア製品を提案するメリット データには価値がある、一度データを溜め出したら抜け出せない、データパイプラインを Red Hat ポートフォリオで抑える方法 speakerdeck.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 実施済みの回については、オンデマンド視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com

おはようございます。レッドハットでAnsibleのテクニカルサポートエンジニアをしている八木澤(ひよこ大佐)です。 Ansible Towerをインストールする際は、各種リポジトリから依存パッケージをダウンロードする必要があります。Ansible Towerのインストールパッケージには依存パッケージが同梱されていないものと、同梱されているもの(Bundle)があります。 しかし、Bundle Installerを利用してもすべてのパッケージが同梱されているわけではありません。一部のパッケージはリポジトリからダウンロードする必要があります。 通常は問題ありませんが、Ansible Towerを外部ネットワークから遮断した環境でインストールしたい場合には、別途オフライン用のリポジトリを用意するなどの追加手順が必要となります。今回はその手順を、本記事執筆時点(2020年5月22日)での最新版である「Red Hat Enterprise Linux 8.2」と「Ansible Tower 3.7.0」の組み合わせを用いて解説します。 今回はAll-in-One構成(1台のAnsible Towerノードと内部DB)での手順をご紹介します。この手順はインストールする環境、構成(クラスタ構成および外部DBの有無）等によっても異なります。 また、必ずこの手順でセットアップできることを保証するものではありませんので、あくまで一例として参考にしていただければ幸いです。 「 Ansible Tower のオフラインインストール 」として、Ansible Tower 3.3.1をRHEL 7.4にインストールする記事が既に公開されていますが、今回の記事はアップデート版として併せて参照していただければ幸いです。 1. オフライン環境のRHELのシステム登録を実施する 通常RHELは「subscription-manager」コマンドを利用してオンラインでシステムを登録することができますが、オフライン環境では別の手順でサブスクリプションを登録する必要があります。 以下のドキュメントに従って、オフライン環境でシステムを登録します。 access.redhat.com 2. オフラインリポジトリを構成する まずセットアップ時に追加パッケージをダウンロードするために、オフラインリポジトリを構成する必要があります。以下のURLから、「Red Hat Enterprise Linux 8.2 Binary DVD」のisoイメージをダウンロードします。 Software & Download Center - Red Hat Customer Portal ダウンロードしたISOファイルをRHELに転送します。（VMware vSphereなどであれば、DVD-ROMドライブを仮想マシンに追加し、isoイメージをマウントすることも可能です) 転送したら、マウントポイントを作成し、isoイメージをマウントします。 [root@tower ~]# mkdir /mnt/disc [root@tower ~]# mount -o loop /tmp/rhel-8.2-x86_64-dvd.iso /mnt/disc/ mount: /mnt/disc: WARNING: device write-protected, mounted read-only. マウントが完了したら、 マウントしたDVDイメージからrepoファイルをコピーし、 /etc/yum.repos.d/ ディレクトリ配下に配置します。 [root@tower ~]# cp /mnt/disc/media.repo /etc/yum.repos.d/rhel8disc.repo [root@tower ~]# chmod 644 /etc/yum.repos.d/rhel8disc.repo コピーしたrepoファイルを元に、AppStream用とBase用のrepoファイルをそれぞれ作成します。 [root@tower ~]# vi /etc/yum.repos.d/rhel8disc_appstream.repo [RHEL8-Server-DVD-Appstream] name=Red Hat Enterprise Linux 8.2.0 (DVD) Appstream mediaid=None metadata_expire=-1 gpgcheck=1 cost=500 baseurl=file:///mnt/disc/AppStream enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release [root@tower ~]# vi /etc/yum.repos.d/rhel8disc_base.repo [RHEL8-Server-DVD-BaseOS] name=Red Hat Enterprise Linux 8.2.0 (DVD) BaseOS mediaid=None metadata_expire=-1 gpgcheck=1 cost=500 baseurl=file:///mnt/disc/BaseOS enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release リポジトリが正常に認識されているか確認し、問題がなければオフラインリポジトリのセットアップは完了です。 [root@tower ~]# dnf repolist Updating Subscription Management repositories. Unable to read consumer identity repo id repo name RHEL8-Server-DVD-Appstream Red Hat Enterprise Linux 8.2.0 (DVD) Appstream RHEL8-Server-DVD-BaseOS Red Hat Enterprise Linux 8.2.0 (DVD) BaseOS 3. Ansible Towerをインストールする では、実際にAnsible Towerをインストールしてみましょう。Ansible Tower 3.7.0のBundleパッケージは以下のURLから入手可能です。 https://releases.ansible.com/ansible-tower/setup-bundle/ansible-tower-setup-bundle-3.7.0-4.tar.gz ダウンロードしたアーカイブをscpコマンド等でオフライン環境下にあるRHELサーバーへ配置します。 その後、RHEL上で配置したアーカイブを展開します。 [root@tower ~]# tar xvf ansible-tower-setup-bundle-3.7.0-4.tar.gz [root@tower ~]# cd ansible-tower-setup-bundle-3.7.0-4/ 展開が完了したら、インストールのためにinventoryファイルを編集します。今回は以下のように記述します。 [root@tower ansible-tower-setup-bundle-3.7.0-4]# vi inventory [tower] localhost ansible_connection=local [database] [all:vars] admin_password='redhat' pg_host='' pg_port='' pg_database='awx' pg_username='awx' pg_password='redhat' pg_sslmode='prefer' # set to 'verify-full' for client-side enforced SSL # Isolated Tower nodes automatically generate an RSA key for authentication; # To disable this behavior, set this value to false # isolated_key_generation=true # SSL-related variables # If set, this will install a custom CA certificate to the system trust store. # custom_ca_cert=/path/to/ca.crt # Certificate and key to install in nginx for the web UI and API # web_server_ssl_cert=/path/to/tower.cert # web_server_ssl_key=/path/to/tower.key # Server-side SSL settings for PostgreSQL (when we are installing it). # postgres_use_ssl=False # postgres_ssl_cert=/path/to/pgsql.crt # postgres_ssl_key=/path/to/pgsql.key inventoryファイルの編集が完了したら、後は通常のTowerのインストールと同様にsetup.shを実行します。 [root@tower ansible-tower-setup-bundle-3.7.0-4]# ./setup.sh 無事setup.shの実行が完了したら、 https://<TOWERのIPアドレス>/ をWebブラウザで開き、TowerのWeb UIを開きます。ライセンス投入後、以下のダッシュボードが表示されればAnsible Towerのインストールは完了です。 オフライン環境では通常よりもひと手間増えてしまいますが、オフラインリポジトリを正しく構成すればセットアップすることができます。ぜひ参考にしていただければ幸いです。 Happy Automation!

Red Hat Virtual Trainingが2020年4月中旬より開講しました！！ Red Hat K.K.では、2020年4月18日より、バーチャルトレーニングを開講しております。 COVID-19の影響によりeラーニングによるリモート育成が注目される中で、もう一つの種類のトレーニングとなります。 これでレッドハットでは、定期のクラスルーム、オンデマンドのオンラインラーニング、サブスクリプションのeラーニングのRHLS、 そして、バーチャルトレーニングと様々な形での提供が実現できました！ バーチャルトレーニングは、リモートツールとしてBlueJeansを、用いてインストラクターから教育を受講します。 ただし、希望のリモートツール、ZoomやGoogle meetなどでの教育も行っております。 レッドハットの演習と言えば、ラボ環境ですね？ラボは、Virtual Labを用いて行います。 インストラクターが事前に、参加者のLabを準備し、リモートで監視ができる状況での演習を進める形のトレーニングになります。 クラスルームと変わらないクオリティを目指しおり、ホワイトボードを使った説明や、資料を使った説明、コンテンツはPDFでダウンロードできるなど 参加した生徒のみなさんが学習できる環境を準備し公開運用しております。 ただし、いくつかの条件もあります。 それは、生徒は事前にマシンチェックを行うということ、そしてネットワークの安定した環境から 指定のURLへログインができることです。 コースは、約３日から５日の講演を受ける形になるので、あとはみなさまの身の回り環境を整えるくらいですね。 インストラクターとの会話はチャットで行われますので、マイクは必須ではありませんが スピーカーが無いとちょっと大変です、スピーカーはご準備ください。 動作確認、購入のステップ、スケジュールは下部にリンクを記載しております。 タイトルにて希望のコースを選び、是非ご登録、参加して楽しんで学んでください！ バーチャルトレーニングに参加する前に『動作確認をする』 バーチャルトレーニングの『購入から受講までの流れ』 バーチャルトレーニングの『スケジュール』 i-Learningのバーチャルトレーニングサイト

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。 突然ですが、Red Hat Insights というサービスはご存知ですか。cloud.redhat.com にて、SaaS として提供されています。RHEL の OS にインストールされているパッケージの状況を調べてくれて、もし脆弱性があったりするとチェックしてパッチを当てるようお勧めしてくれたりするサービスです。 www.redhat.com RHEL 8.2 を用意してみました。ホスト名は myrhel82 としています。ログインしますと、このように出てきます。 This system is not registered to Red Hat Insights. See https://cloud.redhat.com/ To register this system, run: insights-client --register さっそくやってみましょう。あらかじめ subscription-manager で登録してある必要があります。 [root@myrhel82 ~]# insights-client --register You successfully registered xxxxxxxx-8b27-4828-8cf8-xxxxxxxxxxxx to account 99999999. Successfully registered host myrhel82 Automatic scheduling for Insights has been enabled. Starting to collect Insights data for myrhel82 sed: /sys/kernel/debug/sched_features を読み込めません: 許可されていない操作です Uploading Insights data. Successfully uploaded report from myrhel82 to account 99999999. View the Red Hat Insights console at https://cloud.redhat.com/insights/ sed のエラーが出ていますが特に気にせず進めてください。 さっそく Insights にアクセスしてみます。左側の Inventory のメニューをクリックしますと、いま登録した myrhel82 が出てきます。 例えば Patch のタブを選びますと、適用できるパッチの一覧が出てきます。 チェックボックスにチェックを入れると、Remediate (修復する) のボタンが押せるようになります。 3つ選んで押してみます。 この3つのパッチを適用するための、Ansible のプレイブックを作成してくれます。プレイブックに名前をつけて保存します。 作成したプレイブックは Remediations のメニューから見ることができます。 Download playbook のボタンを押すと実際にダウンロードすることができますので、興味のある方は中身を見てみてください。 ここからが本題です。 このプレイブックを実行するために ansible-playbook コマンドを実行してもいいのですが、Ansible Tower にはこの Insights と連携する機能があります。 まず Ansible Tower のインベントリーで、この myrhel82 にアクセスできるように設定しておきます。 RUN COMMANDS から ping で接続できることを確認しておいてください。 次に、Insights への認証情報を Credentials のメニューから作成します。CREDENTIAL TYPE は Insights を選びます。 Projects から Insights 用のプロジェクトを作成します。SCM TYPE に Red Hat Insights を選びまして、CREDENTIAL には上で作成した認証情報を入れます。 myrhel82 のインベントリーに戻って、INSIGHTS CREDENTIAL を設定しますと、REMEDIATE INVENTORY のボタンが出てきます。 この REMEDIATE INVENTORY のボタンを押しますと、ジョブテンプレートが作成されます。 Insights の画面で作成したプレイブックが Insights プロジェクトに同期され、プレイブックが選択できるようになります。 ジョブテンプレートの他の設定を埋めます。myrhel82 に対する認証情報を追加して、適切な名前をつけて保存します。 保存したら LAUNCH ボタンを押して起動します。5分ほどで実行が終わりました。パッチの適用と再起動がされているようです。 実際に myrhel82 にログインして確認してみると、確かにパッケージがアップデートされていることがわかります。 [root@myrhel82 ~]# dnf history info 2 Updating Subscription Management repositories. トランザクション ID : 2 開始時間 : 2020年05月21日 10時53分20秒 開始 rpmdb : 1354:9aece94c2d19a22084c5189313072949f2e52369 終了時間 : 2020年05月21日 10時54分07秒 (47 秒) 終了 rpmdb : 1357:56e3a93ed16b194cc0b2698e6b96c2b9e853407c ユーザー : <sugimura> 終了コード : 成功 Releasever : 8 コマンドライン : update -d 2 -y --advisory RHBA-2020:2240 --advisory RHSA-2020:2031 --advisory RHSA-2020:2102 変更されたパッケージ: インストール kernel-core-4.18.0-193.1.2.el8_2.x86_64 @rhel-8-for-x86_64-baseos-rpms インストール kernel-4.18.0-193.1.2.el8_2.x86_64 @rhel-8-for-x86_64-baseos-rpms インストール kernel-modules-4.18.0-193.1.2.el8_2.x86_64 @rhel-8-for-x86_64-baseos-rpms Upgrade firefox-68.8.0-1.el8_2.x86_64 @rhel-8-for-x86_64-appstream-rpms Upgraded firefox-68.6.0-1.el8_1.x86_64 @@System Upgrade dnsmasq-2.79-11.el8_2.1.x86_64 @rhel-8-for-x86_64-appstream-rpms Upgraded dnsmasq-2.79-11.el8.x86_64 @@System Upgrade bpftool-4.18.0-193.1.2.el8_2.x86_64 @rhel-8-for-x86_64-baseos-rpms Upgraded bpftool-4.18.0-193.el8.x86_64 @@System Upgrade python3-perf-4.18.0-193.1.2.el8_2.x86_64 @rhel-8-for-x86_64-baseos-rpms Upgraded python3-perf-4.18.0-193.el8.x86_64 @@System Upgrade kernel-tools-4.18.0-193.1.2.el8_2.x86_64 @rhel-8-for-x86_64-baseos-rpms Upgraded kernel-tools-4.18.0-193.el8.x86_64 @@System Upgrade kernel-tools-libs-4.18.0-193.1.2.el8_2.x86_64 @rhel-8-for-x86_64-baseos-rpms Upgraded kernel-tools-libs-4.18.0-193.el8.x86_64 @@System [root@myrhel82 ~]# ここまで見てきて、最初の設定は少々面倒だったかもしれません。一度一通り流すことができますと、あとはプレイブックを Insights で生成して Tower で流すだけというようにとても簡単にできるようになります。 他にも Ansible Tower と Insights の連携の機能としましては Advisor を連携してくるものもあります。 これまで見てきた機能と同様に最初は少々設定が必要なのですが、この機能も便利に使えると思います。推奨される設定変更の案内が出てきたら、それに従ってプレイブックを自動的に作成して流すだけになります。ご興味ある方は、ドキュメントをご参照ください。 https://docs.ansible.com/ansible-tower/latest/html/userguide/insights.html Insights でプレイブックを自動的に作成して Ansible Tower で実行するという一連の流れについて紹介しました。ご興味持っていただけましたらうれしく思います。 Ansible Towerの評価ライセンスリクエストはこちらからご利用いただけます。 https://www.ansible.com/products/tower/trial Happy Automation!

こんにちは、レッドハットでAnsibleのテクニカルサポートエンジニアをしている八木澤(ひよこ大佐)です。 システム運用では、アクセス先のユーザー名やパスワードなどの機密情報の管理に気を配る必要があります。通常、Ansible Towerに登録した認証情報などは、暗号化されPostgreSQLのデータベース内に保持されます。そのため、特別な操作をすることなく認証情報を安全に保管することができます。 しかし、運用ポリシーによっては認証情報などを「 Microsoft Azure Key Vault 」や「 CyberArk AIM 」などの外部の認証情報管理サービスに一元的に保管している場合があり、Towerに機密情報を保持することができない場合があります。Ansible Towerではそのような外部の認証情報管理サービスと連携し、認証情報を取得することが可能です。 今回は、「 Microsoft Azure Key Vault 」を利用して認証情報を取得する実際の手順をご紹介します。 azure.microsoft.com その他のサービスの詳細な設定内容については、以下のAnsible Tower公式ドキュメントを参照してください。 12. シークレット管理システム — Ansible Tower User Guide v3.6.3 Azure側の設定 では実際に設定してみましょう。 Ansible TowerでKey Vaultを利用するためには、以下の情報を確認する必要があります。 Azure側の情報 概要 Vault URL (DNS名) Key Vaultで設定されるURLです。確認方法については後ほど解説します。(例: https://xxxxxx.vault.azure.net) クライアント ID Azure ADの「アプリの登録」から登録した際に発行されるIDです。 クライアントシークレット Azure ADの「アプリの登録」から登録した際に発行されるシークレットキーです。 テナント ID Azure ADの設定画面から確認することができます。 クライアントIDおよびクライアントシークレットの登録方法については、本記事では割愛します。詳細な登録方法を確認したい場合は、以下の公式ドキュメントを確認してください。 ポータルで Azure AD アプリとサービス プリンシパルを作成する - Microsoft identity platform | Microsoft Docs ※私が作成した以下のスライドの19ページ以降でもクライアントIDおよびシークレットの登録方法をスクリーンショット付きで紹介しています。 speakerdeck.com キーコンテナーの作成とシークレットの保存 シークレットを保存する前に、まずはキーコンテナーを作成する必要があります。キーコンテナーは以下の手順で作成できます。 「すべてのサービス」から「キーコンテナー」を選択 「キーコンテナーの作成」をクリック 必要事項を入力しキーコンテナーを作成したら、実際にシークレットを登録してみましょう。シークレットの画面から、「生成/インポート」をクリックし新規登録画面へ移動します。 「生成/インポート」をクリック 生成画面を開いたら、「名前」に適切な名前を、「値」に保存するパスワードを入力します。 シークレットを作成 キーを作成したら、後のTowerでの設定のために、作成したシークレットの名前と、キーコンテナーのトップページに表示されているDNS名(Vault URL)を控えておきましょう。 DNS名(Vault URL) アクセスポリシーの設定 デフォルトではAnsible Towerはキーコンテナー内の情報にアクセスする権限がないため、エラーが発生してしまいます。その回避のため、キーコンテナーの設定から「アクセス ポリシー」の設定を開き、クライアントID取得時に登録したアプリに対してアクセス権を付与しておきましょう。 これで、Azure側の設定は完了です。 Tower側の設定 Tower側の操作に移ります。Tower UIから「認証情報」を開き、新規に認証情報を作成します。認証情報のタイプは「Microsoft Azure Key Vault」を選択してください。 Microsoft Azure Key Vaultを選択 認証情報には、Azure側で確認した情報を入力します。内容に誤りがないか確認したら、「保存」をクリックしてください。「テスト」をクリックすることで、正しくシークレットを取得できるか確認することもできます。このテストでエラーが発生する場合は、入力したIDやシークレットに誤りがないか、アクセスポリシーが正しく設定されているか今一度確認してください。 必要情報を入力し保存 設定したシークレットが取得できるかテストすることも可能 マシンクレデンシャルとの関連付け Key Vaultの認証情報を設定することができましたが、このままではジョブテンプレートに適用することができません。実際にKey Vaultに保存されているシークレットを使用してターゲットノードにログインするためには、マシンクレデンシャルに上記Key Vaultの認証情報を紐付ける必要があります。 まず、マシンクレデンシャルを作成後、「パスワード」の虫眼鏡アイコンをクリックし、「入力ソースの設定」画面を開きます。「認証情報」タブから先程作成したKey Vaultの認証情報を選択し、「次へ」をクリックします。 入力ソースの設定 その後、「シークレット名」にKey Vaultで作成したシークレット名を入力し、「OK」をクリックします。 シークレット名を入力 あとは通常通りこのマシンクレデンシャルをジョブテンプレートに関連付け、ジョブを実行すれば認証情報を利用することができます。 おわりに Ansible Towerでは内部に認証情報を保持するだけでなく、外部サービスから認証情報を取得することもできます。さまざまな運用形態に柔軟に対応することができますので、ぜひ一度試してみてください。 Happy Automation!

こんにちは！Red Hatの石川と申します。 昨年よりOpenShiftのテクニカルサポートエンジニアとして働いております。 まだまだOpenShift勉強中の身ですが、日々の業務で気付いたことなどを少しずつ記事にしていけたらと考えております。 今回はService Accountの認証の仕組みがどのようになっているかについて触れてみたいと思います。 Service Accountって？ Service Accountは通常のUserとは別に、Podや各種コンポーネントがAPI呼び出しを行うために設計されたKubernetesのオブジェクトです。JenkinsやTravis CIなどでアプリケーションを自動化する際にも利用されます。 Service AccountはUserと違い、特定のタスクを実行することを目的に作られていますので、特定のnamespaceに紐づいています。ただし、namespaceを跨げば名前の重複が可能です。 普段使っているPodにも必ず1つのService Accountが紐づいています。Pod作成時にService Accountを明示的に指定しなかった場合そのnamespaceのdefaultという名前のService Accountが紐づけられます。 PodはService Accountの持つ認証情報を利用することでAPI serverやイメージレジストリへのアクセスが可能になります。 Service Accountを作成する さっそくService Accountを作成してみます。 なお、当記事ではOpenShift Container Platform 4.3を利用しています。 $ oc create sa shishika serviceaccount/shishika created $ oc describe sa shishika Name: shishika Namespace: default Labels: <none> Annotations: <none> Image pull secrets: shishika-dockercfg-nklpv Mountable secrets: shishika-dockercfg-nklpv shishika-token-nrm7j Tokens: shishika-token-h69f4 shishika-token-nrm7j Events: <none> default namespaceに shishika という名前のService Accountを作成しました。 するとImage pull secrets以下に何やら色々と作成されていることがわかります。 oc get secret コマンドを実行すると、secretが合計3つ作成されていることがわかります( shishika-dockercfg-nklpv , shishika-token-nrm7j , shishika-token-h69f4 )。 1つ1つ見ていきましょう。 それぞれのsecretについて Image pull secretsに作成された shishika-dockercfg-nklpv はOpenShiftの内部イメージレジストリにアクセスしてイメージストリームからイメージをpullするために使用されます。 shishika-token-nrm7j はBuilt-in(組み込み) secretと呼ばれるもので、APIを呼び出すための認証情報として利用されます。 これらはMountable secretsとして登録され、Podにマウントして利用されます。 ちなみにKubernetesの場合、内部イメージレジストリが無いのでImage pull secretsは自動作成されません。 Kubernetesで作成した場合 $ kubectl describe sa shishika Name: shishika Namespace: default Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: shishika-token-c4jz2 Tokens: shishika-token-c4jz2 Events: <none> OpenShiftのマニュアルには以下のように記載されています。 各サービスアカウントには、2 つのシークレットが自動的に含まれます。 API トークン OpenShift Container レジストリーの認証情報 Built-in secretの shishika-token-nrm7j は「APIトークン」、Image pull secretの shishika-dockercfg-nklpv は「OpenShift Container レジストリーの認証情報」に該当します。 それでは、3つ目の shishika-token-h69f4 は何に利用されているのでしょう？ 検証してみましょう。 secretを削除してみる まずはBuilt-in secret( shishika-token-nrm7j )から消してみます。 $ oc delete secret shishika-token-nrm7j secret "shishika-token-nrm7j" deleted $ oc describe sa shishika Name: shishika Namespace: default Labels: <none> Annotations: <none> Image pull secrets: shishika-dockercfg-nklpv Mountable secrets: shishika-dockercfg-nklpv - shishika-token-nrm7j + shishika-token-l2tv4 Tokens: shishika-token-h69f4 - shishika-token-nrm7j + shishika-token-l2tv4 Events: <none> shishika-token-l2tv4 という新しいsecretが登録されました。 次にImage pull secret shishika-dockercfg-nklpv を削除してみます。 $ oc delete secret shishika-dockercfg-nklpv secret "shishika-dockercfg-nklpv" deleted $ oc describe sa shishika Name: shishika Namespace: default Labels: <none> Annotations: <none> -Image pull secrets: shishika-dockercfg-nklpv +Image pull secrets: shishika-dockercfg-kwrbf Mountable secrets: shishika-token-l2tv4 - shishika-dockercfg-nklpv + shishika-dockercfg-kwrbf -Tokens: shishika-token-h69f4 +Tokens: shishika-token-4nnbp shishika-token-l2tv4 Events: <none> すると、Image pull secretsが shishika-dockercfg-kwrbf に変更された上、 3つ目のsecretも shishika-token-h69f4 から shishika-token-4nnbp というsecretに変更されています。 逆もまた然りで、3つ目のsecretを削除してもImage pull secretが再作成されます。どうやら、3つ目のsecretはImage pull secretと関係しているようです。 どのように実装されているか、ソースコードを確認してみましょう。 3つ目のsecretについて 泥臭くソースコードを解析していきます。 余談ですが、Githubは2019年6月頃からGo、Python、Rubyなど一部の開発言語で関数名をクリックすることで定義元にジャンプすることが可能になりました。 Go言語で書かれたOpenShiftやKubernetesのコードは、Github上で静的解析が可能です。 help.github.com ソースコードはopenshift-controller-managerにあります。 github.com Service AccountはserviceAccountControllerによって監視され、Image pull secretが見つからなくなると syncServiceAccount 関数によって再作成されています。 func (e *DockercfgController) syncServiceAccount(key string ) error { (省略) serviceAccount := obj.(*v1.ServiceAccount).DeepCopyObject().(*v1.ServiceAccount) mountableDockercfgSecrets, imageDockercfgPullSecrets := getGeneratedDockercfgSecretNames(serviceAccount) // If we have a pull secret in one list, use it for the other. It must only be in one list because // otherwise we wouldn't "needsDockercfgSecret" foundPullSecret := len (imageDockercfgPullSecrets) > 0 foundMountableSecret := len (mountableDockercfgSecrets) > 0 if foundPullSecret || foundMountableSecret { switch { case foundPullSecret: serviceAccount.Secrets = append (serviceAccount.Secrets, v1.ObjectReference{Name: imageDockercfgPullSecrets.List()[ 0 ]}) case foundMountableSecret: serviceAccount.ImagePullSecrets = append (serviceAccount.ImagePullSecrets, v1.LocalObjectReference{Name: mountableDockercfgSecrets.List()[ 0 ]}) } // Clear the pending token annotation when updating delete (serviceAccount.Annotations, PendingTokenAnnotation) updatedSA, err := e.client.CoreV1().ServiceAccounts(serviceAccount.Namespace).Update(serviceAccount) if err == nil { e.serviceAccountCache.Mutation(updatedSA) } return err } dockercfgSecret, created, err := e.createDockerPullSecret(serviceAccount) (省略) } https://github.com/openshift/openshift-controller-manager/blob/release-4.3/pkg/serviceaccounts/controllers/create_dockercfg_secrets.go#L316-L401 secret作成部分の createDockerPullSecret 関数を見てみます。3つ目のsecretはpull secretを作成する際のアノテーションやパスワードのために作成されていることがわかります。 // createDockerPullSecret creates a dockercfg secret based on the token secret func (e *DockercfgController) createDockerPullSecret(serviceAccount *v1.ServiceAccount) (*v1.Secret, bool , error ) { tokenSecret, isPopulated, err := e.createTokenSecret(serviceAccount) (省略) dockercfgSecret := &v1.Secret{ ObjectMeta: metav1.ObjectMeta{ Name: secret.Strategy.GenerateName(getDockercfgSecretNamePrefix(serviceAccount.Name)), Namespace: tokenSecret.Namespace, Annotations: map [ string ] string { v1.ServiceAccountNameKey: serviceAccount.Name, v1.ServiceAccountUIDKey: string (serviceAccount.UID), ServiceAccountTokenSecretNameKey: string (tokenSecret.Name), ServiceAccountTokenValueAnnotation: string (tokenSecret.Data[v1.ServiceAccountTokenKey]), }, }, Type: v1.SecretTypeDockercfg, Data: map [ string ][] byte {}, } glog.V( 4 ).Infof( "Creating dockercfg secret %q for service account %s/%s" , dockercfgSecret.Name, serviceAccount.Namespace, serviceAccount.Name) (省略) dockercfg := credentialprovider.DockerConfig{} for _, dockerURL := range e.dockerURLs { dockercfg[dockerURL] = credentialprovider.DockerConfigEntry{ Username: "serviceaccount" , Password: string (tokenSecret.Data[v1.ServiceAccountTokenKey]), // token keyをPasswordとして設定 Email: "serviceaccount@example.org" , } } (省略) // Save the secret createdSecret, err := e.client.Core().Secrets(tokenSecret.Namespace).Create(dockercfgSecret) return createdSecret, err == nil , err } https://github.com/openshift/openshift-controller-manager/blob/release-4.3/pkg/serviceaccounts/controllers/create_dockercfg_secrets.go#L462-L514 上記のソースコードは元々 origin にありましたが、OpenShift4からOperator管理となったため移動されています。 おわりに Service Accountのsecretについて見てきました。 OpenShiftはKubernetesをベースとしながらも、各種組み込みコンポーネントやそれにアクセスする仕組みがデフォルトで用意されています。 是非皆様もService Accountを駆使してアプリケーションの自動化に取り組んでみてください！ 以上です。

こんにちは、小杉です。 前回ご紹介した Knative Serving に引き続き、Apache Kafka & Camel K Quarkus を使った Knative Eventing をご紹介します。 medium.com Apache Kafka & Ceph による Knative Eventing Red Hat ではソフトウェア開発者向けの情報を Webinar で配信しています。 来週 5/21(木) はサーバーレスの内容も含んだ 「マイクロサービス/サーバーレス入門」 が配信される予定です。 また 5/28(木) には 「これからのシステム連携を実現するデジタル基盤とアプローチ」 を配信する予定です。 見逃した方も オンデマンドで視聴 できるようになっているので是非登録してご覧ください。

こんにちは、レッドハットでAnsibleのテクニカルサポートエンジニアをしている八木澤(ひよこ大佐)です。 Ansibleにはターゲットノードに対して操作を実行する際に利用するModule(モジュール)の他に、Plugin(プラグイン)という仕組みがあります。PluginにはBecome PluginやCallback Pluginなど、目的に応じていくつか種類がありますが、どのプラグインも主にAnsibleに対して追加機能を提供する目的で実装されています。 今回は、その中でも「Callback Plugin」に焦点を当てて解説していきます。 Callback Pluginとは Ansibleでは、Playbookの実行時に「タスクがokになった」など、各種のイベントが発生します。Callback Pluginは、それらのイベントに基づいて出力などを整形する目的で主に利用されます。例を挙げれば「各タスクの実行にかかった時間を表示させたい」場合には「timer」が利用できますし、「タスクが失敗した際にメールを送信したい」という場合には「mail」が利用できます。 利用可能なプラグインの一覧については、以下のドキュメントを参照してください。 Callback Plugins — Ansible Documentation 実際に利用してみよう Callback Pluginを有効化する では試しに「timer」プラグインを有効化してみましょう。Ansibleのコントロールノードに接続し、「/etc/ansible/ansible.cfg」内の以下の行を編集します。 # enable callback plugins, they can output to stdout but cannot be 'stdout' type. callback_whitelist = timer Callback Pluginを有効化するには、「callback_whitelist」に有効化するプラグインを指定します。上記を編集して保存すると、次のansible-playbookコマンドの実行時から有効になります。 では早速実行してみましょう。 $ ansible-playbook -i hosts hello_world.yml PLAY [Hello World] ******************************************************************************************************************************************************** TASK [Gathering Facts] **************************************************************************************************************************************************** ok: [localhost] TASK [Say Hello] ********************************************************************************************************************************************************** ok: [localhost] => { "msg": "Hello World!" } PLAY RECAP **************************************************************************************************************************************************************** localhost : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Playbook run took 0 days, 0 hours, 0 minutes, 1 seconds このPlaybookはdebugモジュールで「Hello World!」と表示するだけのシンプルなものです。注目していただきたいのは「PLAY RECAP」の一番下の行です。 Playbook run took 0 days, 0 hours, 0 minutes, 1 seconds 上記のように、Playbookの実行にかかった時間が表示されます。このPlaybookは重たい処理ではないので1秒（！）で実行が完了していたことがわかります。 タスクごとにかかった時間を測定する(profile_tasks) timerプラグインではPlaybook実行にかかった時間を確認できましたが、各タスクごとにかかった時間を確認したいケースもあると思います。その場合は、以下のように「profile_tasks」プラグインを有効化します。callback_whitelistには複数のCallback Pluginを指定することが可能ですので、timerモジュールと一緒に有効化してみましょう。 callback_whitelist = timer, profile_tasks では、さきほどのPlaybookで実際の出力を確認してみましょう。 $ ansible-playbook -i hosts hello_world.yml PLAY [Hello World] ******************************************************************************************************************************************************** TASK [Gathering Facts] **************************************************************************************************************************************************** Thursday 14 May 2020 12:40:40 +0900 (0:00:00.038) 0:00:00.038 ********** ok: [localhost] TASK [Say Hello] ********************************************************************************************************************************************************** Thursday 14 May 2020 12:40:41 +0900 (0:00:01.231) 0:00:01.269 ********** ok: [localhost] => { "msg": "Hello World!" } PLAY RECAP **************************************************************************************************************************************************************** localhost : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Thursday 14 May 2020 12:40:41 +0900 (0:00:00.039) 0:00:01.309 ********** =============================================================================== Gathering Facts ---------------------------------------------------------------------------------------------------------------------------------------------------- 1.23s Say Hello ---------------------------------------------------------------------------------------------------------------------------------------------------------- 0.04s Playbook run took 0 days, 0 hours, 0 minutes, 1 seconds 出力が大幅に変化しました。各タスクに経過時間が表示され、PLAY RECAPの下部にも各タスクごとの経過時間が表示されています。その下には、さきほど有効化したtimerプラグインの出力が確認できますね。このサンプルではシンプルなPlaybookを利用しているのであまり確認する意味はないのですが、複雑なPlaybookを実行する際には、より効果を発揮します。 ご紹介したCallbackプラグインを活用することで、どのタスクの実行に時間がかかっているのかを特定することができますので、トラブルシューティングに大いに役立ちます。このように、出力を整形したりトラブルシューティングをする際にもCallback Pluginは活用できます。皆様もぜひ一度、お手元で試してみてください。 Happy Automation！