Red Hatでソリューションアーキテクトをしている田中司恩です。前回記事では Red Hat CodeReady Containers （以下、CRC）をリモート接続してシングルノードのOpenShiftとして利用する方法を紹介しました。 rheb.hatenablog.com 今回はCRCを利用する上で構築する時の注意点とTipsをいくつかご紹介します。 CRCについてはまとめ記事を書いていますのでそちらも参考にしてください。 rheb.hatenablog.com CRC構築時の注意点 ディスク容量 （参考）CRCセットアップ後の関連ファイルの構成（v.1.24.0） crc deleteで消えない.crcフォルダ crc start 初回の起動時間 仮想環境でのネスト実行 Tips pull-secretをファイルから読み込ませる方法 PVは事前に作成済み kubeadminのパスワードの確認 oc コマンドのパスを設定する方法 ocコマンドのタブ補完を有効にする CRC VMへSSHログインする CRC VMのvCPU/Memory割り当て量を変更する 最小構成のRHEL上でCRCを実行する手順 まとめ CRC構築時の注意点 CRC構築時の注意点、ハマりポイントをいくつかピックアップします。 ディスク容量 CRCのディスク要件はかなり大きめで「35GBの空きスペースが必要」となっています。 CRCは1つのバイナリ crc でコマンドの実行とコマンド自体に格納されたイメージの展開を行います。そのため crc バイナリの容量が非常に大きいです（Linux版 v.1.24.0 約2.3GB）。また、セットアップ時に展開されるイメージ（.crc/cache/crc.qcow2）の容量が約10GBあり、さらにCRC起動時にマシンイメージ（.crc/machines/crc.qcow2）が追加で作成されます。 （参考）CRCセットアップ後の関連ファイルの構成（v.1.24.0） $ tree ~/.crc /home/user/.crc ├── bin │   ├── admin-helper-linux │   ├── crc-driver-libvirt │   └── oc │   └── oc -> /home/user/.crc/cache/crc_libvirt_4.7.2/oc ├── cache │   ├── crc_libvirt_4.7.2 │   │   ├── crc-bundle-info.json │   │   ├── crc.qcow2 │   │   ├── id_ecdsa_crc │   │   ├── kubeadmin-password │   │   ├── kubeconfig │   │   └── oc │   └── crc_libvirt_4.7.2.crcbundle ├── crc.json ├── crc.log └── machines └── crc ├── config.json ├── crc.qcow2 ├── id_ecdsa ├── id_ecdsa.pub ├── kubeadmin-password └── kubeconfig 6 directories, 18 files CRCはユーザー権限での実行が前提となりますので、ユーザーのホームディレクトリのあるパーティションの空き容量には十分注意ください。 crc delete で消えない .crc フォルダ CRCの削除用に crc delete コマンドがあります。実行するとOpenShiftクラスターの削除を行なってくれるのですが、完全にデータを削除するようにはなっていません。削除されるのは ~/.crc/machines/crc/ ディレクトリのみです。その他のキャッシュデータなどはそのままです。 crc delete 実行後も約13GB程度のファイルは残っているので（v.1.24.0の場合）、完全に削除する場合は ~/.crc フォルダごと削除してください。 なお、再度 crc setup を実行することで環境は再構築されます。 crc start 初回の起動時間 CRCの初回起動はセットアップのプロセスを含むので若干時間がかかります（手元の環境で 7分程度 ）。二回目以降の起動時間はやや短縮され、手元の環境では 5分半程度 になりました。 なお、同じ検証仮想環境上で実行するシングルノードのOCPの起動時間は 9分程度 かかりました。CRCは実行ホスト上の仮想マシンでの実行オーバーヘッドを考慮しても短い時間で起動できるようにチューニングされているようです。 仮想環境でのネスト実行 CRCの実行ホストを仮想環境で動かす場合、CRC自体は実行ホスト上の仮想マシンとして動作することになるためネスト（Nested）に対応した環境が必要です。 例）VMware ESXi上の仮想マシンでは、CPU＞ハードウェア仮想化を有効化する VMware ESXiのハードウェア仮想化オプション ハードウェア仮想化オプションが有効になっていない場合、 crc setup の実行時にエラーになります。 $ crc setup INFO Checking if running as non-root INFO Checking if admin-helper executable is cached INFO Checking if running on a supported CPU architecture INFO Checking minimum RAM requirements INFO Checking if Virtualization is enabled INFO Setting up virtualization You need to enable virtualization in BIOS Tips CRCを利用する上で便利なコマンドや機能について紹介します。 pull-secretをファイルから読み込ませる方法 CRCの初回起動時にはプルシークレットの入力が求められます。手順としてはプルシークレットの内容をコピペするだけなのですが、起動時のコマンドに引数をつけることで手動でのコピペ作業を回避し、ファイルから直接読み込ませることができます。 引数でプルシークレットのファイルを指定した初回実行コマンド （pull-secretは任意の名前） $ crc start -p pull-secret （参考）プルシークレットは OpenShift Cluster Manager より入手可能です。 OpenShift Cluster Managerのプルシークレット取得場所 PVは事前に作成済み CRCは事前構成済みのOpenShift 4環境ですが、永続ボリューム（PV）についても事前に構成されているものが使えます。 pv0001 〜 pv0030 の30個のPVが事前に用意されていて、全て容量は100Giとなっています。 なお、 pv0001 はイメージレジストリー用のPVとして使用済みです。残りの29個を自由に利用できます。 CRCの事前構成済み永続ボリューム（PV） kubeadminのパスワードの確認 CRCの管理者である kubeadmin のパスワードは、 crc start の完了後にコンソール画面に表示されます。その後にコンソールの画面をクリアするなどしてパスワードが分からなくなった場合は下記のコマンドで確認することが可能です。 $ crc console --credentials To login as a regular user, run 'oc login -u developer -p developer https://api.crc.testing:6443'. To login as an admin, run 'oc login -u kubeadmin -p XXXXX-XXXXX-XXXXX-XXXXX https://api.crc.testing:6443' パスワードファイルの実体から確認することも可能です。 $ cat ~/.crc/machines/crc/kubeadmin-password XXXXX-XXXXX-XXXXX-XXXXX oc コマンドのパスを設定する方法 CLIでアクセスする場合の「oc」コマンドは下記の手順で使用できます（別途入手したocコマンドを使用するのも可）。 crc oc-env を実行します $ crc oc-env exportから始まるコマンドを実行し、環境変数にパスを追加します。 （下記はユーザー名「user」の例） export PATH="/home/user/.crc/bin/oc:$PATH" # Run this command to configure your shell: # eval $(crc oc-env) ocコマンドのタブ補完を有効にする $ oc completion --help を実行すると出力されたExampleの中に設定方法の記述があります。 macOSとLinux向けのそれぞれの設定方法が記載されています。 （参考）Linux向けの設定方法 oc completion bash > ~/.kube/completion.bash.inc printf " # Kubectl shell completion source '$HOME/.kube/completion.bash.inc' " >> $HOME/.bash_profile source $HOME/.bash_profile CRC VMへSSHログインする ~/.crc/machines/crc 配下にあるSSHキーを使用することでCRC VMへSSH接続することができます。 CRC VMのIPアドレスは crc ip コマンドで確認 初回接続時のみフィンガープリントの確認があります $ export CRC_IP=$(crc ip) $ ssh -i ~/.crc/machines/crc/id_ecdsa core@$CRC_IP The authenticity of host '192.168.130.11 (192.168.130.11)' can't be established. ECDSA key fingerprint is SHA256:a39rGpjdfzT/RWRzLY3POzL0iyKYFzxAyoLOLELR0oA. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.130.11' (ECDSA) to the list of known hosts. Red Hat Enterprise Linux CoreOS 47.83.202103051045-0 Part of OpenShift 4.7, RHCOS is a Kubernetes native operating system managed by the Machine Config Operator (`clusteroperator/machine-config`). WARNING: Direct SSH access to machines is not recommended; instead, make configuration changes via `machineconfig` objects: https://docs.openshift.com/container-platform/4.7/architecture/architecture-rhcos.html --- [core@crc-rsppg-master-0 ~]$ CRC VMのvCPU/Memory割り当て量を変更する crc config コマンドを使用することで CRC VMのカスタマイズを行うことが可能です。 vCPU、Memory容量はCRC上で実行するコンテナ/Podの起動可否に大きく関わってきますので、必要に応じて適切に設定してください。 CRCデフォルトのvCPU/Memoryの値を確認 $ crc config get cpus Configuration property 'cpus' is not set. Default value is '4' $ crc config get memory Configuration property 'memory' is not set. Default value is '9216' vCPU→6、Memory→12GBへ変更する（MemoryはMiBで指定） $ crc config set cpus 6 $ crc config set memory 12288 変更後、確認 $ crc config get cpus cpus : 6 $ crc config get memory memory : 12288 CRC実行ホストの空きメモリ容量を上回る設定すると警告が出て実行されません $ crc config set memory 16384 Value '16384' for configuration property 'memory' is invalid, reason: only 16.6GB of memory found (17.18GB required) crc config には他にもオプションがありますので、いろいろ試してカスタマイズに挑戦してみてください。 最小構成のRHEL上でCRCを実行する手順 最小構成でインストールしたRHEL上で最小限のステップでCRCを実行する手順の参考です。 例）RHEL 8.3を最小構成でインストールした環境 OSインストール後、ホスト名、固定IPアドレスは設定済みの状況 作業ディレクトリ：~/CRC crc 実行パスの配置先：~/bin subscription-manager登録、OSのアップデート $ sudo subscription-manager register --auto-attach $ sudo dnf update -y CRCの入手と展開（v.1.24.0の場合） $ mkdir ~/CRC && cd CRC $ curl -O https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/crc-linux-amd64.tar.xz $ xz -dc crc-linux-amd64.tar.xz |tar xvf - $ CRC_DIR=~/CRC/crc-linux-1.24.0-amd64 CRCの初期セットアップ $ mkdir ~/bin $ ln -s $CRC_DIR/crc ~/bin/crc $ crc setup CRCの初回起動（pull-secretはcloud.redhat.comから別途入手して配置しておくこと） $ crc start -p pull-secret 以降は 前回記事 を参考にリモート接続の構成を行うことでシングルノードのOpenShift環境が出来上がります。 まとめ CRC構築時の注意点やTipsをいくつかご紹介しました。公式ドキュメントにあまり詳細に書いていない点も多くありますので、是非参考にしてCRCをさらに活用してみてください。 RHELやLinuxホストを1台用意できれば簡単にCRCのリモート構成も構築可能です。開発や検証用に一家に一台、シングルノードなOpenShiftの導入をお勧めします。

レッドハットのソリューションアーキテクトの森です。 今回は、Operator を使って、Process Automation Manager を OpenShift へデプロイする方法について解説をしていきます。 インストーラーウィザードを使用したデプロイ 環境を定義した yaml を使用したデプロイ Operator を使用してデプロイした環境の変更 PAMとOpenShiftについては、以下のバージョンのものを使用しています。 Process Automation Manager : 7.10 OpenShift Containar Platform : 4.7 インストーラーウィザードを使用したデプロイ まずは、Openshift に Operator をインストールしていきます。 OpenShiftのコンソール画面にログインをしたら、まずはPAMをデプロイする Project を作成しましよう。 ここでは、 pam-demo という名称で作成していきます。 プロジェクトを作成したら、左のメニューから Operators -> OperatorHub を選択します。 OperatorHub のカタログの中から、 Business Automation を選択してください。 テキストボックスのフィルタに business とすると探し易いと思います。 2021年3月時点での最新版は、 7.10.0-2 です。 間違いがなければ、 Install ボタンを押してください。 Install Operator の画面が開いたら、 Installed Namespace に先ほど作成したPAMをインストールするProject名になっていることを確認します。 他はそのままで、下部の Install ボタンを押してください。 Operatorのインストールが完了すると、下記の画面が表示されます。 Operator のインストール完了後、中央に表示された View Operator のボタンを押すか、 左のメニューから Operators -> Installed Operators を選択し、 Business Automation をクリックします。 Business Automation の Operator の詳細画面右側の、 Installer の URL をクリックします。 別画面が開きますので、中央の Log in with Openshift をクリックし、 再度、OpenShiftの認証情報でログインをします。 下記の画面が表示された場合は、 Allow selected permissions を選択してください。 Business Automation の インストーラーウィザードが開きますので、必要な事項を入力していきます。 Application name (必須) OpenShift アプリケーションの名前を入力します。この名前は、すべてのコンポーネントのデフォルト URL で使用されます。 ここでは、 rhpam7 としておきます。 Environment (必須) 環境のタイプを選択します。こちらで選択したタイプをベースにして、インストーラウィザードより他の設定をカスタマイズしていきます。 詳細については、こちらのドキュメント: 環境の基本設定の構成 を参照してください。 ここでは、 rhpam-authoring を選択します。 Admin user Username と Password を入力します。 PAM の管理者ユーザーのユーザー名およびパスワードになります。 最低限の設定ですが、以上でデプロイする準備ができました。 インストーラーウィザードの下部の、 View YAML をクリックすると、 実行するYAMLの内容を確認することができます。 確認後、 インストーラーウィザードの下部の、 Finish をクリックし、 Deploy をボタンを押して実行してください。 OpenShiftのコンソール画面に戻り、 Developer View に切り替えて、 Topology 画面を選択します。 Business Central と、 KIE Server のデプロイが実行されているので、3分ほど待ちます。 白丸から青丸に変わると、デプロイ完了です。 その後、Business Centralの円の右上の矢印マークをクリックしてください。 Business Central のログイン画面が表示されますので、インストーラーウィザードで入力したユーザー名とパスワードを使用してログインします。 環境を定義した yaml を使用したデプロイ 次に、yaml を使用して、Operator で PAM/DM をインストールする方法をご紹介します。 ここでは、OpenShift CLIツール を使用していきます。 まずはPAMをインストールする Project を作成していきます。 先ほどと同様に、 pam-demo という名称で作成をします。 $ oc new-project pam-demo 次に、作成したProjectへ、Operator をインストールします。 下記のコマンドをターミナルより実行してください。 なお、 ${NAMESPACE} は、先ほど作成したプロジェクトの名称に置き換えて実行してください。 cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: businessautomation namespace: ${NAMESPACE} spec: targetNamespaces: - ${NAMESPACE} --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: businessautomation-operator namespace: ${NAMESPACE} spec: channel: stable name: businessautomation-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF 実行されると、以下のような出力が表示されます。 operatorgroup.operators.coreos.com/businessautomation created subscription.operators.coreos.com/businessautomation-operator created Operator が正常にインストールされているかを確認するには、下記のコマンドを実行してみてください。 $ oc get operators 出力例 NAME AGE businessautomation-operator.pam-demo 171m 次に、PAMのデプロイをします。 先ほどインストーラーウィザードで作成したものと同じ yaml でデプロイをしてみましょう。 下記のコマンドをターミナルより実行してください。 cat <<EOF | oc apply -f - apiVersion: app.kiegroup.org/v2 kind: KieApp metadata: name: rhpam7 spec: environment: rhpam-authoring commonConfig: adminUser: admin adminPassword: admin EOF 実行されると、以下のような出力が表示されます。 kieapp.app.kiegroup.org/rhpam7 created これで、Operator を通してPAMのデプロイが開始されます。 インストールの進行状況については、次のコマンドで確認してみてください。 $ oc get pods 出力例 NAME READY STATUS RESTARTS AGE business-automation-operator-5d5b87475b-lmdln 1/1 Running 0 14m console-cr-form 2/2 Running 0 14m rhpam7-kieserver-1-deploy 0/1 Completed 0 3m35s rhpam7-kieserver-1-zjzm2 1/1 Running 0 3m32s rhpam7-rhpamcentr-1-deploy 0/1 Completed 0 3m35s rhpam7-rhpamcentr-1-w8dsh 1/1 Running 0 3m32s Business Central へアクセスするURLは、下記のコマンドで調べることができます。 $ oc get route 出力例 NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD console-cr-form console-cr-form-pam-demo.apps.cluster-57e9.57e9.sandbox106.opentlc.com console-cr-form <all> reencrypt None rhpam7-kieserver rhpam7-kieserver-pam-demo.apps.cluster-57e9.57e9.sandbox106.opentlc.com rhpam7-kieserver https passthrough/Redirect None rhpam7-rhpamcentr rhpam7-rhpamcentr-pam-demo.apps.cluster-57e9.57e9.sandbox106.opentlc.com rhpam7-rhpamcentr https passthrough/Redirect None rhpam7-rhpamcentr のURLを用いて、ブラウザからBusiness Centralへログインすることができます。 yaml に記述した管理ユーザー名とパスワードを使ってログインをしてください。 Operator を使用してデプロイした環境の変更 Operator を使用してデプロイした場合は、デプロイした環境の変更を行うには、KieApp の yaml 変更する必要があります。 KieApp のyamlソースは、以下のコマンドから確認することができます。 ${APPLICATION_NAME} は、インストール時に指定した Application name に置き換えて実行してください。 $ oc get kieapp ${APPLICATION_NAME} -o yaml また、より詳細な設定を行いたい場合は、カスタムリソースから変更を行うことも可能です。 カスタムリソースの内容は、以下のコマンドから確認をすることができます。 $ oc get crd kieapps.app.kiegroup.org -o yaml

Red Hatのソリューションアーキテクトの暮林達也です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services]に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2021/4月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: シングルサインオンどんだけリソースいるんですか？サイジング基礎値をとってみました。 Red Hat Single Sign-Onのコミュニティ版のkeycloakで、CPUやメモリのサイジング基礎値をとってみました。 qiita.com 特集2: REST/gRPC だけでは運用が困難になる？マイクロサービスデータ連携の肝 新しいシステムをマイクロサービスで構築しようと考える企業が増えてきています。 その際に、同期通信である REST/gRPC の口を持ったマイクロサービスだけでシステム全体を設計してしまうと、運用時、人手では収拾がつかなくなってしまいます。イミュータブルインフラストラクチャである Kubernetes、サービスメッシュの Istio の必要性を考えながらマイクロサービス間のデータ連携パターンをまとめました。イベント駆動マイクロサービスやサーバーレスアーキテクチャまで網羅しています。 speakerdeck.com 特集3: Operatorを使ってOpenShiftへPAMをデプロイしてみよう rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat Integration 2021.Q1 Red Hat Integration Operator 1.0 Debezium 1.4 Red Hat AMQ 2021.Q1 Red Hat build of Eclipse Vert.x 4.0 Red Hat build of Quarkus 1.11

Red Hatでソリューションアーキテクトをしている田中司恩です。 前回記事 の続きのCodeReady Containers（以下、CRC）に関する記事となります。 CRCのインストールから実用的な利用方法については杉村さんの記事で詳細に書かれていますので、そちらを参照してください。 rheb.hatenablog.com この記事では杉村さんの記事でも利用されている「CRCのリモート接続」について掘り下げて解説いたします。 CRCのリモート接続とは CRC v.1.15からひっそりとサポートされている構成方法です。v.1.15からドキュメントに使用方法が記載されています。 code-ready.github.io 5.3. Setting up CodeReady Containers on a remote server Red Hat製品ドキュメント 5.3. Setting up CodeReady Containers on a remote server CRCはローカル端末上での実行を前提としてますので、本来はCRCを実行している端末上でしかウェブコンソールとCLIによるOpenShiftクラスターへの接続はできません。そこで追加のセットアップを行うことでLinux版のみ、リモートサーバー上に配置したCRCへアクセスすることがサポートされるようになりました。具体的にはCRCを実行するLinux上にhaproxyでロードバランサー機能を立ち上げ、リモートからのアクセスをCRC仮想マシンへ転送する仕組みとなります。また、CRCでは「crc.testing」と「apps-crc.testing」の2つの事前に定義済みのドメイン名が使用されます。リモート接続するためには外部からこれらの名前解決が行えるようにする設定も追加で必要となります。リモート接続の設定を行うことで外部の端末からウェブコンソールやCLIを使ってOpenShiftクラスターへのアクセスが可能となります。 CRCをリモート接続で構成することによりリソースに余裕のある検証・開発用のLinux端末などをOpenShiftの実行環境として利用できるので、手元のローカル端末のリソース消費を心配する必要はありません。 CRCのデフォルト接続構成 CRCのリモート接続構成 !!! 注意 !!! CRCのリモート接続はローカルネットワーク内での使用を強く推奨しています。またCRCはシングルユーザーでの利用を前提としており 複数ユーザーでのサーバー用途として利用することはできません 。マルチユーザーでの利用は フル機能版のOpenShift をご利用ください。 CRCのDNSのアーキテクチャー リモート接続の説明に先立って、CRCのDNSアーキテクチャーについて解説します。 CRCで構成されているDNSのアーキテクチャーは下記の図のようになります。 ※ アーキテクチャー図はCRCの挙動から判断し、独自に書き起こしたものです。公式なものではありません。 ※ 本記事ではLinux版のみ対象としています。macOS、Windows版は同様の仕組みですが詳細は異なります CRCのDNSアーキテクチャー図 ここからはCRC VMとCRCホストの設定内容を確認していきます。 CRC VMの内部動作確認 CRC VMへssh接続して確認します $ ssh -i ~/.crc/machines/crc/id_ecdsa core@192.168.130.11 Red Hat Enterprise Linux CoreOS 47.83.202102090044-0 Part of OpenShift 4.7, RHCOS is a Kubernetes native operating system managed by the Machine Config Operator (`clusteroperator/machine-config`). WARNING: Direct SSH access to machines is not recommended; instead, make configuration changes via `machineconfig` objects: https://docs.openshift.com/container-platform/4.7/architecture/architecture-rhcos.html [core@crc-l6qvn-master-0 ~]$ CRC VMの中ではpodmanでdnsmasq（DNSサーバー）が起動されています。 [core@crc-l6qvn-master-0 ~]$ sudo podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5f7915d883be quay.io/crcont/gvisor-tap-vsock:v4 2 weeks ago Up 31 minutes ago gvisor-tap-vsock 6e00d97c9ac9 quay.io/crcont/dnsmasq:latest 31 minutes ago Up 31 minutes ago 0.0.0.0:53->53/udp dnsmasq 使用されている dnsmaq.conf の中身を確認（podman inspectでマウントしている実態ファイルのパスを確認済み） [core@crc-l6qvn-master-0 ~]$ sudo cat /var/srv/dnsmasq.conf user=root port= 53 bind-interfaces expand-hosts log-queries local=/crc.testing/ domain=crc.testing address=/apps-crc.testing/192.168.130.11 address=/api.crc.testing/192.168.130.11 address=/api-int.crc.testing/192.168.130.11 address=/crc-l6qvn-master-0.crc.testing/192.168.126.11 CRCで使用しているDNSの名前解決は、ホストからこのpodmanで起動しているdnsmasq宛に問い合わせる構成となっています。ホストではNetwork Managerのdnsmasqプラグインを使用して特定のDNSの問い合わせをCRC VMへ転送するように設定されています。 CRC実行ホストのNetwork Manager設定 CRCセットアップ後のホスト上のdnsmasqのCRC用インスタンスは下記のようになっています。 $ cat /etc/NetworkManager/dnsmasq.d/crc.conf server=/apps-crc.testing/192.168.130.11 server=/crc.testing/192.168.130.11 なお、このcrc.confは crc setup および crc start 時にチェックされ、設定を変更することができません（下記はcrc start実行時のログ） $ crc start 〜省略〜 INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists 設定を変更した場合はCRCが起動できなくなります $ crc start INFO Checking if running as non-root INFO Checking if podman remote executable is cached INFO Checking if admin-helper executable is cached INFO Checking minimum RAM requirements INFO Checking if Virtualization is enabled INFO Checking if KVM is enabled INFO Checking if libvirt is installed INFO Checking if user is part of libvirt group INFO Checking if libvirt daemon is running INFO Checking if a supported libvirt version is installed INFO Checking if crc-driver-libvirt is installed INFO Checking if systemd-networkd is running INFO Checking if NetworkManager is installed INFO Checking if NetworkManager service is running INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists WARN Preflight checks failed during `crc start`, please try to run `crc setup` first in case you haven't done so yet File has unexpected content: /etc/NetworkManager/dnsmasq.d/crc.conf CRCホストの/etc/hosts CRCセットアップ後、CRCを実行するホストの/etc/hostsには設定が追加されます $ sudo cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.130.11 api.crc.testing console-openshift-console.apps-crc.testing default-route-openshift-image-registry.apps-crc.testing oauth-openshift.apps-crc.testing このようにCRCの名前解決の仕組みは複雑に構成されています。リモート接続を行う場合はこれらの仕組みを維持しつつ、外部からの接続を受け付けるようにする必要があります。 リモート接続の構成方法 ここからはリモート接続の実際の設定方法を紹介します。やることは大きく2つです。 CRCを立ち上げるサーバー側での設定 CRCへ接続するクライアント側の設定 さらに、サーバー側の設定はLoadBalancer（haproxy）とDNS（dnsmasq）の設定をそれぞれ行います。 リモート接続後の構成は下記の図の通りです。 （リモートクライアントは後述するmacOSを想定して構成図になっています） CRCのリモート接続構成 ※ 以降の解説のサーバー環境は、RHEL8.3をサーバー（GUI使用）でセットアップした環境を想定しています。 サーバー側の設定：haproxy 下記はドキュメント（5.3. Setting up CodeReady Containers on a remote server）に載っている方法です。 haproxyパッケージとその他のユーティリティ をインストールします。 $ sudo dnf install haproxy policycoreutils-python-utils jq ファイアウォールを変更して、クラスターとの通信を許可します。 $ sudo systemctl start firewalld $ sudo firewall-cmd --add-port=80/tcp --permanent $ sudo firewall-cmd --add-port=6443/tcp --permanent $ sudo firewall-cmd --add-port=443/tcp --permanent $ sudo systemctl restart firewalld SELinuxのためのTCPポート6443のリッスンを許可します。 $ sudo semanage port -a -t http_port_t -p tcp 6443 デフォルトのhaproxyコンフィグのバックアップを作成します。 $ sudo cp /etc/haproxy/haproxy.cfg{,.bak} haproxyのコンフィグを作成します。コンフィグ内の $CRC_IP にはCRCのIPアドレス（デフォルト：192.168.130.11）が記載されます。 $ export CRC_IP=$(crc ip) $ sudo tee /etc/haproxy/haproxy.cfg &>/dev/null <<EOF global debug defaults log global mode http timeout connect 5000 timeout client 500000 timeout server 500000 frontend apps bind 0.0.0.0:80 option tcplog mode tcp default_backend apps frontend apps_ssl bind 0.0.0.0:443 option tcplog mode tcp default_backend apps_ssl backend apps mode tcp balance roundrobin server webserver1 $CRC_IP:80 check backend apps_ssl mode tcp balance roundrobin option ssl-hello-chk server webserver1 $CRC_IP:443 check frontend api bind 0.0.0.0:6443 option tcplog mode tcp default_backend api backend api mode tcp balance roundrobin option ssl-hello-chk server webserver1 $CRC_IP:6443 check EOF haproxyのサービス登録とサービスの起動を行います $ sudo systemctl enable haproxy $ sudo systemctl start haproxy サーバー側の設定：dnsmasq ドキュメントではサーバー側の設定はhaproxyについてしかありません。実際にクライアント側からアクセスする場合はCRC用のDNSによる名前解決が必要です。CRCでは *.apps.crc.testing のワイルドカードレコードの名前解決が必要です。そのため接続元のクライアントのhostsファイルへの単純な追記などでは対応が大変です。クライアント自身にDNSサーバーを立てるまたは外部のDNSサーバーを利用する、などの方法がありますが本記事ではよりシンプルに、CRCサーバーにクライアント向けのDNSサーバーを兼用する設定方法を紹介します。 作業ステップは下記の通りです。 dnsmasqのインストール firewallの設定変更 dnsmasq.confの設定 dnsmasqサービスの登録、起動 dnsmasqの動作確認 1. dnsmasqのインストール dnfでdnsmasqをインストールします $ sudo dnf install dnsmasq -y 2. firewallの設定変更 DNSで使用するポートの追加、反映を行います $ sudo firewall-cmd --add-port=53/tcp --permanent $ sudo firewall-cmd --add-port=53/udp --permanent $ sudo firewall-cmd --reload 3. dnsmasq.confの設定 デフォルトのdnsmasq.confをバックアップし、新規に作成します。 下記の 192.168.1.25 はご自身のCRCサーバーのIPアドレスに置き換えてください。 $ sudo mv /etc/dnsmasq.conf{,.bak} $ sudo tee /etc/dnsmasq.conf &>/dev/null <<EOF user=dnsmasq group=dnsmasq no-hosts bind-interfaces listen-address=192.168.1.25 address=/testing/192.168.1.25 EOF no-hosts：CRCを実行するホストの/etc/hostsにCRC用設定が追記されるため、そのアドレスを応答するのを防ぐための設定 bind-interfaces：Network Managerのdnsmasqプラグインによってバインドされているアドレスを避けてdnsmasqを起動するために設定 listen-address：クライアントからのDNS問い合わせを待ち受けるIPアドレスを指定 address=/testing/ ：*.testingのワイルドカードアドレスを解決するIPアドレスを指定 4. dnsmasqサービスの登録、起動 systemctlコマンドでサービスを登録、起動します $ sudo systemctl enable dnsmasq.service $ sudo systemctl start dnsmasq.service dnsmasqサービスの起動後、サービスが起動していること、指定したIPアドレスでtcp/udp port:53がリッスンしていることを確認します。 $ sudo systemctl status dnsmasq.service |grep Active: Active: active (running) since Fri 2021-03-19 01:06:40 JST; 15min ago $ sudo ss -tlnup | grep 192.168.1.25:53 udp UNCONN 0 0 192.168.1.25:53 0.0.0.0:* users:(("dnsmasq",pid=54226,fd=4)) tcp LISTEN 0 32 192.168.1.25:53 0.0.0.0:* users:(("dnsmasq",pid=54226,fd=5)) （2021/3/29、追記） CRC実行ホストを再起動後、dnsmasqのネットワークバインドがうまくいかない場合があります。dnsmasqサービスの起動をネットワーク起動後に遅延させることで回避できます。 systemctl edit サービス名 を実行 $ sudo systemctl edit dnsmasq エディター画面が開いたら下記を記載して vi の手順でファイルを保存し閉じる [Unit] After=network-online.target 追記した内容は下記のファイルに保存されています $ cat /etc/systemd/system/dnsmasq.service.d/override.conf [Unit] After=network-online.target 参考リンク access.redhat.com 5. dnsmasqの動作確認 dnsmasqが無事起動したら、あとはクライアントから api.crc.testing や任意のワイルドカードアドレス aaa.apps-crc.testing などが名前解決できればOKです。 （クライアントから実行） $ dig @192.168.1.25 api.crc.testing |grep -A 1 "ANSWER SECTION" ;; ANSWER SECTION: api.crc.testing. 0 IN A 192.168.1.25 $ dig @192.168.1.25 aaa.apps-crc.testing |grep -A 1 "ANSWER SECTION" ;; ANSWER SECTION: aaa.apps-crc.testing. 0 IN A 192.168.1.25 クライアント側の設定 クライアント側の設定として、LinuxとmacOS用の設定方法を紹介します。 Linux用設定 ドキュメントではLinuxクライアントから接続する前提での方法が記載されています。 code-ready.github.io 5.4. Connecting to a remote CodeReady Containers instance Red Hat製品ドキュメント 5.4. Connecting to a remote CodeReady Containers instance サーバー側と同様に、dnsmasqを利用してクライアント自身にDNSサーバーを構成する方法となります。 1. dnsmasqのインストール $ sudo dnf install dnsmasq -y 2. NetworkManagerでdnsmasqによるDNS名前解決の使用を有効にします $ sudo tee /etc/NetworkManager/conf.d/use-dnsmasq.conf &>/dev/null <<EOF [main] dns=dnsmasq EOF 3. CRC用のDNSエントリを設定に追加します。 $ sudo tee /etc/NetworkManager/dnsmasq.d/external-crc.conf &>/dev/null <<EOF address=/apps-crc.testing/192.168.1.25 address=/api.crc.testing/192.168.1.25 EOF 4. NetworkManagerサービスをリロードします。 $ sudo systemctl reload NetworkManager macOS用の設定 macOSではDNSサーバーを立てることなく、特定のドメイン名だけを指定したDNSサーバーを使って名前解決することができます。 /etc/resolver を使用します。設定方法は簡単で /etc/resolver 配下にドメイン名のファイルを作成し、中に nameserver IPアドレス の記入を行うだけです。 $ sudo tee /etc/resolver/testing &>/dev/null <<EOF nameserver 192.168.1.25 EOF 設定を行なった後、CRCサーバーをDNSサーバーとして指定せずにdigコマンドを実行しても正しく名前解決できません。しかしながらpingでは/etc/resolverの設定に従って名前解決が行われます。ご注意ください。 CRCにリモート接続してみる リモートの端末からブラウザでCRCの管理コンソールにアクセスします。 接続先URL：https://console-openshift-console.apps-crc.testing/ .testing ドメインで問題なくコンソールが表示できればCRCのリモート接続の完成です。あとはお好きなようにOpenShift 4の環境として利用できます。 CRCのコンソール画面 まとめ CRCをリモートサーバー上で実行し、リモートクライアントから接続して利用する方法についてご紹介しました。 リモート接続の構成に当たってはDNSの名前解決の理解が必要なため、CRCのDNSのアーキテクチャーについても合わせてご紹介しました。 CRCは簡単にセットアップできるシングルノードのOpenShift 4そのものであり、比較的簡単に自由に使えるOpenShiftの環境を手に入れる方法の1つです。CRCのリモート接続でローカル端末のリソース問題を解消して開発やテスト環境でのOpenShift 4の利用がさらに便利になると思います。 次回記事ではCRCのセットアップや利用時におけるTips、注意点などについてご紹介いたします。 （2021/3/30、追記） 次回記事をアップしました rheb.hatenablog.com

Red Hatの森若です。 この記事は Software Design 2021年3月号 に執筆した「CentOS Stream入門」の原稿から派生させた記事です。 CentOS Streamとは? CentOS Streamは2019年9月に公開された比較的新しいLinuxディストリビューションです。 その後2020年12月に、CentOS プロジェクトが出荷されたRHELをリビルドしたCentOS Linuxの作成を近い将来やめ、CentOS Streamへシフトする発表を行いました ("CentOS Project shifts focus to CentOS Stream") 。このアナウンスでCentOS Streamの存在を知ったという方も多いかと思います。今回はこのCentOS Streamを紹介していきます。 CentOS Streamは安定志向のディストリビューションで、将来のRHELに含まれる予定のソフトウェアが各種のテストを通過した場合のみパッケージが更新されます。RHELとの違いはパッケージのリリースタイミングが随時行われるローリングリリースモデルであることです。RHELのようなマイナーリリース(8."2"や8."3"など)は存在しませんし、yumリポジトリには最新のパッケージしか含まれません。 一方メジャーバージョンははっきりと区別されており、CentOS Stream 8をインストールしたらいつのまにかCentOS Stream 9になっていたというようなことは発生しません。逆に考えると、現在のところ8から9へのスムーズなアップグレード方法がありません。 用途に制限はありませんが、Red Hat Enterprise Linux(以下RHEL)をターゲット環境とするソフトウェア開発者がCI環境で利用することを強く意識しています。開発者・利用者からのフィードバックを受けつけ、素早く対応するための窓口となることも期待されています。現在RHELやCentOS Linuxなどを使っている方の内、日常的にパッケージを最新へ更新している方であれば違和感なく利用できると思います。 利用者視点でのCentOS Stream 利用する側から見たCentOS Streamの特徴を見ていきます。 常に機能拡張を含む最新パッケージしか提供されませんから、バージョンや機能セットを固定して維持したい用途には向きません。そのような場合にはRHELが向いています。一方RHELむけのソフトウェア開発を行っている場合や、新規ソフトウェアを利用したい場合には(問題なければ)将来のRHELに含まれるソフトウェアが使えるので便利に使えます。 CentOS Streamに含まれるソフトウェアのセットは、基本的にRHELと同じです。次のリリースで投入予定のバージョンであるほか、Red Hatの商標やCPE等のOS名、リポジトリ設定、パッケージの署名などは違います。 CentOS Streamに「マイナーリリース」はなく、ある時点でバージョンや機能を固定してメンテナンスされることはありません。パッケージの互換性維持の方針はRHELに準じます ("Red Hat Enterprise Linux 8: Application Compatibility GUIDE") 。 CentOS Streamのライフサイクルは、対応するRHELのフルサポート期間(5年間)が終わるまでの間です。RHEL 8のフルサポート期間は2024年5月末までですから、CentOS Stream 8もそこで廃止され、メンテナンスは終了します。RHELのメジャーバージョンの出荷は3年おきなので、対応するRHELリリース前の期間(RHEL 9以降ではGA前にCentOS Streamが先に公開予定)をのぞいた5年間のライフサイクルのうち、2年間は次のメジャーバージョンと並行して提供されます。 ソフトウェア修正の出荷時期は場合により前後関係が変わります。RebaseやupstreamプロジェクトからのバックポートなどはRHELより早くCentOS Streamへ公開されます。一方パートナとのNDAや、セキュリティ修正のembargo期間など守秘義務がある場合、RHELのパッケージ公開後にCentOS Streamへ公開されます。RHELではerrataが出荷されても、CentOS Streamではrebaseにより対応が不要なケースもありますので、RHELとCentOS Streamのパッケージは1対1に対応しません。 RHELのために開発・整備されている大量のテストを通過したパッケージだけがCentOS Streamとして公開されるので、CentOS Streamにパッケージが登場する時点で安定していると言ってよいと思います。問題を発見した場合には、後述のBugzillaへ報告やパッチを送ることができ、Red Hatのエンジニアにより修正やテスト拡張などの対応が行われます。 このようにCentOS StreamはRHELと深い関係がありますが、Red Hatの製品ではないので、製品としてのサポートや各種認定プログラムなどは存在しません。 RHEL開発をオープンにするCentOS Stream Red Hatの視点では、CentOS StreamはRHELの開発をオープンにしていく取り組みのひとつです。将来RHELに含まれる修正や機能追加の状況をコミュニティから随時アクセス可能にすることで、変更に対するフィードバックとその対応を容易かつ早くするすることが狙いの一つです。 CentOS Streamの位置づけはRHELのNightlyビルドにあたります。単一ソフトウェアのNightlyビルドとは少し異なり、ここではディストリビューションの最新パッケージ群のセットのことを示しています。Red Hatのエンジニア達が次のマイナーリリースに含めようとしているバージョン変更、機能追加、バグ修正、セキュリティ修正などの内、テストを通過したものが随時追加されていきます。これはCentOS Streamが現れる以前にはRed Hat社内と、ごく一部のパートナーしかアクセスできないものでした。 図1にイメージ図を描いています。Fedora Rawhideではどんどん新バージョンや新機能を統合し、品質保証プロセスを経てFedoraがリリースされます。新しいRHELはFedoraからforkして開発が始まり、CentOS Streamとなります。約1年ほどの開発ののち、新しいメジャーバージョンのRHELとしてリリースされます。 図1 Fedora Rawhide, Fedora, CentOS Stream, RHELの関係図 CentOS Stream以外にも、upstreamの最新kernelとのCIを継続的に行う Always Ready Kernel や、通常のFedoraリリースとは別にRHELに相当する設定(たとえばFedoraにはbtrfsが含まれますがRHELには含まれません)でパッケージのビルド、CIを行う Fedora ELN などの取り組みを行っています。 問題発生期間の短縮 モデルケースを使って、CentOS Streamが存在しない従来のRHEL開発と、CentOS Streamが組み込まれたRHEL開発を比較してみます。RHELに含まれているソフトウェアを開発するOSSプロジェクト「upstreamプロジェクトA」と、RHELでの動作をサポートする「ISV製品B」が登場します。 図2はCentOS Streamがないときの開発です。わかりやすさのためにRHEL 7という名前にしていますが、リリースタイミングはRHEL 8以降と同じく定期的に行われるように絵を描いていますので実際とは異なります。 upstreamプロジェクトAにISV製品Bと非互換な変更が行われます。 7.1リリース後、upstreamプロジェクトAの更新を取りこみます。 非互換な変更を含む7.2がリリースされます。 ISV製品Bのテスト環境を7.2へ更新し、問題が発見・報告されます。 原因調査ののちRed Hatが問題を修正します。このときupstreamプロジェクト A でまず修正を行い、それをRHELへバックポートします(upstream firstポリシー)。 4,5の作業中に7.3がリリースされていたため、7.3のerrataとして出荷されます。 図2 CentOS Streamがないとき 図3はCentOS Streamがあるときの開発です。テスト環境がリリースされたRHELではなくCentOS Streamになっている以外はほぼ同じですが、将来出荷予定の変更が公開されるCentOS Streamをテスト環境として利用することで、RHELでの不具合発生期間が大幅に短縮されます。さらにRHEL出荷前に問題の存在がわかるため「製品BはRHEL 9.2では今のところ動作しない」のようなアナウンスを事前に行えます。 図3 CentOS Streamがあるとき CentOS Streamの入手・インストール CentOS Streamは CentOS ProjectのWebサイト から入手できます。 ISOイメージをダウンロードして、インストールします。 図4 CentOS StreamのWebサイト 執筆時点ではVMイメージは散発的なタイミングで 公開 されています。最新パッケージが必要な場合はこれをもとにパッケージを更新するのがよいでしょう。 執筆時点ではCentOS Streamのコンテナイメージは提供されていません。そのため Red Hat Universal Base Image(以下UBI)をベースとして、CentOS Streamのパッケージと差し替えることでCentOS Streamのコンテナイメージを作成する手順をリスト1 で紹介します。ほとんどのコマンドについて出力を省略しています。 (1) CentOS Stream 8の環境でUBI 8を取得し、作業用のコンテナを作成します。 # yum module install -y container-tools $ podman pull registry.access.redhat.com/ubi8 $ buildah from ubi8 ubi8-working-container (2) CentOS Streamのリポジトリ情報を持つrpmをダウンロードし、コンテナにコピーします。 $ yum download centos-stream-repos centos-gpg-keys $ buildah copy ubi8-working-container centos* /tmp (3) コンテナ内のシェルでパッケージの削除と入れ替えを行います。 $ buildah run ubi8-working-container bash # yum remove -y *subscription* ## RHELとのサブスクリプション共有は不要なので削除する # yum install /tmp/centos-* ## CentOS Streamのリポジトリ設定 # yum --setopt protected_packages= swap redhat-release centos-stream-release ## redhat-releaseをcentos-stream-releaseで置き換える # rm /etc/yum.repos.d/ubi.repo ## UBIのリポジトリを削除する # yum clean all # yum distro-sync -y ## CentOS Streamのパッケージに置き換え # yum clean all # rm /tmp/centos* # exit (4) コンテナからイメージ cs8 を作成し、コンテナを削除します。 $ buildah commit ubi8-working-container cs8 $ buildah delete ubi8-working-container リスト1 Red Hat UBIをもとにCentOS Streamのコンテナイメージを作成する CentOS Streamの問題に対応する CentOS Streamではバグレポートや修正パッチを受けつけており、各コンポーネントを担当しているRed Hatのエンジニアが対応します。Red Hatはupstream firstポリシーでRHELを開発しているため、CentOS StreamやRHELが修正されるだけでなく、upstreamプロジェクトでも問題が解決されることを期待できます。 CentOS Streamでのバグ修正はその時点の最新パッケージだけが対象です。レポート前に最新パッケージで問題が再現することを確認しましょう。 Red Hat Bugzilla へバグレポートや修正パッチを送ると、Red Hatのエンジニアがアサインされ、内容を確認してCentOS Streamでの対応方針を決めます。不明点の確認や、修正により問題が解消されたかの確認もここで行われます。 Red Hat Bugzillaで報告するには、アカウント作成が必要です。Red Hatのアカウントを使うこともできますし、メールアドレスがあれば新規に作成することもできます。 報告するには、トップページから "New" → "Red Hat" → "Red Hat Enterprise Linux 8" とリンクをクリックします。図5のような画面が表示され、Versionの中に8.2, 8.3などのマイナーリリースと並んで "CentOS Stream" という選択肢があります。 図5 Red Hat Bugzilla バグレポートではなくPull Requestを送ることもできます。詳しい手順は CentOS Wikiに記載 がありますが、PRを作成することでRed Hat Bugzillaのチケットが自動的に作成されます。

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。 東京は桜の開花宣言が出たそうです。わたしは北海道出身なもので桜と言えばゴールデンウィーク明けの感覚なのですが、実家を出て30年くらいになってもまだ慣れないものです。 Ansible Tower は OpenShift にも対応しておりまして、実際に使われているお客様も多くいらっしゃいます。サポートをするためには問題を再現するための検証環境が必要なもので、手元でも OpenShift を動かしたいということで環境構築に悩んでいたのですが、PC 1台の中でフルスペックの OpenShift を構成すると VM を多数作ることになり、リソースが足りないという問題がありました。そもそも OpenShift を構築すること自体もそう簡単ではなく、本来検証したいことができないというのは本末転倒です。 そこで、CRC (Red Hat CodeReady Containers) を利用してみようと思いまして実際に構築してみました。 ドキュメントはこちらです。 code-ready.github.io 以前にもこの赤帽エンジニアブログで田中司恩さんが記事を書かれているので、より詳しくはそちらもご覧ください。 rheb.hatenablog.com 用意したPC 15cm四方くらいの小さいPCを以前買いまして、今回 CRC 用に使うことにしました。だいたい10万円くらいで、ケース全体で熱を放出するために冷却が気になるところですが、音は静かで気に入っています。TOPTON というメーカーのものです。 大まかなスペックはこちらです。CRC を動かすためであれば、いま売っているPCであればだいたいなんでも構わないと思います。Ansible Tower を動かすためには、だいたい 6core でメモリは 16GB くらいあれば良さそうです。 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz 12core 64GB RAM 1TB SSD RHEL 8.3 をインストールしまして、IPアドレスとホスト名を振りました。 IP address: 192.168.0.6 hostname: toptonpc.sugimura.home ホスト名は DNS で解決できるようにしています。DNS は別に検証環境に置いていまして、dnsmasq で構築しています。 この PC の中で、10core 48GB(49152MB) を CRC に使うことにします。 CRC は一般ユーザで動作させる必要があります。sugimura ユーザを作りまして、sudo できるようにしておきます。 これでインストールするための準備ができたので、早速進めていきます。 CRC の制限 CRC は OpenShift をフルスペックでインストールするのと比べまして、いくつかの制限があります。 machine-config と monitoring の Operator が無効になっています master と worker が同居する1台構成になっており、アップデートなどはできません ドメインが crc.testing 固定です 内部で使うIPアドレスは変更することができません CRC のインストール CRC は弊社のサイトから配布しています。こちらに Red Hat のアカウントでログインしてください。 cloud.redhat.com CodeReady Containers archive で Linux を選択して、ダウンロードします。Pull secret もダウンロードして、適当なファイル名で保存しておきます。 この2つのファイルをダウンロードできたら、RHEL に転送します。 crc-linux-amd64.tar.xz pull-secret.json tar を展開します。2021年3月14日の時点では、CRC のバージョンは 1.23.1 でした。 [sugimura@toptonpc ~]$ tar xvf crc-linux-amd64.tar.xz crc-linux-1.23.1-amd64/ crc-linux-1.23.1-amd64/LICENSE crc-linux-1.23.1-amd64/doc.pdf crc-linux-1.23.1-amd64/crc [sugimura@toptonpc ~]$ cd crc-linux-1.23.1-amd64/ [sugimura@toptonpc crc-linux-1.23.1-amd64]$ この crc コマンドを使うことで CRC 用の VM が起動されて設定などがされるのですが、この VM についての設定をあらかじめしておきます。初期値では 4 CPU と 9GB RAM に設定されているので、その値を変えておきます。DNS はわたしの検証環境では 192.168.0.93 です。 [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc config set cpus 10 [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc config set memory 49152 [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc config set pull-secret-file /home/sugimura/pull-secret.json [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc config set nameserver 192.168.0.93 設定できたら ./crc setup を実行します。使用状況を送信するかどうかと sudo のパスワードを聞かれますが、適切に回答して進めてください。 [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc setup CodeReady Containers is constantly improving and we would like to know more about usage (more details at https://developers.redhat.com/article/tool-data-collection) Your preference can be changed manually if desired using 'crc config set consent-telemetry <yes/no>' Would you like to contribute anonymous usage statistics? [y/N]: No worry, you can still enable telemetry manually with the command 'crc config set consent-telemetry yes'. INFO Checking if running as non-root INFO Checking if podman remote executable is cached INFO Checking if admin-helper executable is cached INFO Caching admin-helper executable INFO Using root access: Changing ownership of /home/sugimura/.crc/bin/admin-helper-linux [sudo] sugimura のパスワード: INFO Using root access: Setting suid for /home/sugimura/.crc/bin/admin-helper-linux INFO Checking minimum RAM requirements INFO Checking if Virtualization is enabled INFO Checking if KVM is enabled INFO Checking if libvirt is installed INFO Installing libvirt service and dependencies INFO Using root access: Installing virtualization packages INFO Checking if user is part of libvirt group INFO Adding user to libvirt group INFO Using root access: Adding user to the libvirt group INFO Checking if libvirt daemon is running WARN No active (running) libvirtd systemd unit could be found - make sure one of libvirt systemd units is enabled so that it's autostarted at boot time. INFO Starting libvirt service INFO Using root access: Executing systemctl daemon-reload command INFO Using root access: Executing systemctl start libvirtd INFO Checking if a supported libvirt version is installed INFO Checking if crc-driver-libvirt is installed INFO Installing crc-driver-libvirt INFO Checking if systemd-networkd is running INFO Checking if NetworkManager is installed INFO Checking if NetworkManager service is running INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists INFO Writing Network Manager config for crc INFO Using root access: Writing NetworkManager configuration to /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf INFO Using root access: Changing permissions for /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf to 644 INFO Using root access: Executing systemctl daemon-reload command INFO Using root access: Executing systemctl reload NetworkManager INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists INFO Writing dnsmasq config for crc INFO Using root access: Writing NetworkManager configuration to /etc/NetworkManager/dnsmasq.d/crc.conf INFO Using root access: Changing permissions for /etc/NetworkManager/dnsmasq.d/crc.conf to 644 INFO Using root access: Executing systemctl daemon-reload command INFO Using root access: Executing systemctl reload NetworkManager INFO Checking if libvirt 'crc' network is available INFO Setting up libvirt 'crc' network INFO Checking if libvirt 'crc' network is active INFO Starting libvirt 'crc' network INFO Checking if CRC bundle is extracted in '$HOME/.crc' INFO Checking if /home/sugimura/.crc/cache/crc_libvirt_4.7.0.crcbundle exists INFO Extracting bundle from the CRC executable INFO Ensuring directory /home/sugimura/.crc/cache exists INFO Extracting embedded bundle crc_libvirt_4.7.0.crcbundle to /home/sugimura/.crc/cache INFO Uncompressing crc_libvirt_4.7.0.crcbundle crc.qcow2: 9.97 GiB / 9.97 GiB [-----------------------------------------------------------------------------------------------------------------------------] 100.00% Setup is complete, you can now run 'crc start' to start the OpenShift cluster WARN が一つ出たので一応確認しておきます。この CRC は KVM で動作しまして、そのためのサービス libvirtd が有効になっていないと起動しませんよということです。 [sugimura@toptonpc crc-linux-1.23.1-amd64]$ sudo systemctl list-unit-files | grep libvirtd.service libvirtd.service enabled setup が無事終わったので、 ./crc start で起動します。 [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc start INFO Checking if running as non-root INFO Checking if podman remote executable is cached INFO Checking if admin-helper executable is cached INFO Checking minimum RAM requirements INFO Checking if Virtualization is enabled INFO Checking if KVM is enabled INFO Checking if libvirt is installed INFO Checking if user is part of libvirt group INFO Checking if libvirt daemon is running INFO Checking if a supported libvirt version is installed INFO Checking if crc-driver-libvirt is installed INFO Checking if systemd-networkd is running INFO Checking if NetworkManager is installed INFO Checking if NetworkManager service is running INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists INFO Checking if libvirt 'crc' network is available INFO Checking if libvirt 'crc' network is active INFO Loading bundle: crc_libvirt_4.7.0.crcbundle ... INFO Creating CodeReady Containers VM for OpenShift 4.7.0... INFO CodeReady Containers VM is running INFO Generating new SSH Key pair ... INFO Updating authorized keys ... INFO Copying kubeconfig file to instance dir ... INFO Starting network time synchronization in CodeReady Containers VM INFO Adding 192.168.0.93 as nameserver to the instance ... INFO Check internal and public DNS query ... INFO Check DNS query from host ... INFO Adding user's pull secret to instance disk... INFO Verifying validity of the kubelet certificates ... INFO Starting OpenShift kubelet service INFO Waiting for kube-apiserver availability... [takes around 2min] INFO Adding user's pull secret to the cluster ... INFO Updating cluster ID ... INFO Starting OpenShift cluster ... [waiting for the cluster to stabilize] INFO 6 operators are progressing: dns, image-registry, network, openshift-controller-manager, operator-lifecycle-manager-packageserver, service-ca INFO 4 operators are progressing: image-registry, network, openshift-controller-manager, service-ca INFO 3 operators are progressing: image-registry, openshift-controller-manager, service-ca INFO 2 operators are progressing: image-registry, openshift-controller-manager INFO Operator openshift-controller-manager is progressing INFO 2 operators are progressing: kube-apiserver, openshift-controller-manager INFO 2 operators are progressing: kube-apiserver, openshift-controller-manager INFO 2 operators are progressing: kube-apiserver, operator-lifecycle-manager-packageserver INFO Operator kube-apiserver is progressing INFO Operator kube-apiserver is progressing INFO All operators are available. Ensuring stability ... INFO Operators are stable (2/3) ... INFO Operators are stable (3/3) ... INFO Updating kubeconfig WARN The cluster might report a degraded or error state. This is expected since several operators have been disabled to lower the resource usage. For more information, please consult the documentation Started the OpenShift cluster. The server is accessible via web console at: https://console-openshift-console.apps-crc.testing Log in as administrator: Username: kubeadmin Password: XXXXXXXXXXXXXXXXXXXXXX Log in as user: Username: developer Password: developer Use the 'oc' command line interface: $ eval $(crc oc-env) $ oc login -u developer https://api.crc.testing:6443 この最後に出てくる情報はメモしておいてください。 oc コマンドはよく使いますので、PATH を設定しておくと便利です。 [sugimura@toptonpc crc-linux-1.23.1-amd64]$ echo "eval $(~/crc-linux-1.23.1-amd64/crc oc-env)" > ~/.bash_profile [sugimura@toptonpc crc-linux-1.23.1-amd64]$ source ~/.bash_profile [sugimura@toptonpc crc-linux-1.23.1-amd64]$ which oc ~/.crc/bin/oc/oc [sugimura@toptonpc crc-linux-1.23.1-amd64]$ oc version Client Version: 4.7.0 Server Version: 4.7.0 Kubernetes Version: v1.20.0+bd9e442 これで使えるようになりましたが、そのままではこの RHEL 上でしか CRC を使うことができません。外からアクセスするための設定もいくつか実施しておきます。 この RHEL で haproxy を動作させて、外からの通信を CRC の中に中継していくというものです。 [sugimura@toptonpc ~]$ sudo dnf install haproxy policycoreutils-python-utils jq [sugimura@toptonpc ~]$ sudo systemctl start firewalld [sugimura@toptonpc ~]$ sudo firewall-cmd --add-port=80/tcp --permanent success [sugimura@toptonpc ~]$ sudo firewall-cmd --add-port=6443/tcp --permanent success [sugimura@toptonpc ~]$ sudo firewall-cmd --add-port=443/tcp --permanent success [sugimura@toptonpc ~]$ sudo systemctl restart firewalld [sugimura@toptonpc ~]$ sudo semanage port -a -t http_port_t -p tcp 6443 [sugimura@toptonpc ~]$ sudo cp /etc/haproxy/haproxy.cfg{,.bak} [sugimura@toptonpc ~]$ export CRC_IP=$(crc-linux-1.23.1-amd64/crc ip) [sugimura@toptonpc ~]$ echo $CRC_IP 192.168.130.11 [sugimura@toptonpc ~]$ sudo tee /etc/haproxy/haproxy.cfg &>/dev/null <<EOF global debug defaults log global mode http timeout connect 5000 timeout client 500000 timeout server 500000 frontend apps bind 0.0.0.0:80 option tcplog mode tcp default_backend apps frontend apps_ssl bind 0.0.0.0:443 option tcplog mode tcp default_backend apps_ssl backend apps mode tcp balance roundrobin server webserver1 $CRC_IP:80 check backend apps_ssl mode tcp balance roundrobin option ssl-hello-chk server webserver1 $CRC_IP:443 check frontend api bind 0.0.0.0:6443 option tcplog mode tcp default_backend api backend api mode tcp balance roundrobin option ssl-hello-chk server webserver1 $CRC_IP:6443 check EOF [sugimura@toptonpc ~]$ sudo systemctl enable haproxy [sugimura@toptonpc ~]$ sudo systemctl start haproxy また、FQDN でアクセスできるようにする必要があります。DNS を設定して、apps-crc.testing と api.crc.testing がこの RHEL に向くようにしてください。dnsmasq が動作している DNS (192.168.0.93) ではこのように設定を追加しました。 # cat /etc/dnsmasq.d/crc.testing.conf address=/apps-crc.testing/192.168.0.6 address=/api.crc.testing/192.168.0.6 # systemctl restart dnsmasq これで使うための設定は終わりですが、この CRC の VM から外に通信することができず、一度再起動する必要がありました。 [sugimura@toptonpc ~]$ sudo shutdown -r now 再起動して OS がまた上がってきたら、crc start をやり直してください。 [sugimura@toptonpc ~]$ cd crc-linux-1.23.1-amd64/ [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc start Web ブラウザからアクセス ./crc start したときに最後に表示された URL にアクセスすることで、CRC のコンロール画面が開きます。 https://console-openshift-console.apps-crc.testing kube:admin をクリックして、kubeadmin でログインしてみます。 monitoring がないからなのかリソースの情報は表示されませんが、OpenShift 4.7.0 が動いていることがわかります。ブラウザの設定が日本語になっているときは、日本語でも表示されるようになりました。 こちらの記事もご参照ください。 rheb.hatenablog.com これでこの Web コンソールや oc コマンドから、OpenShift を使うことができます。 Ansible Tower のインストール ようやく本題なのですが、この CRC に Ansible Tower の現時点での最新版 3.8.2 をインストールしてみました。ドキュメントはこちらです。日本語版ドキュメントは翻訳の都合で 3.8.1 になっていますが、3.8.2 でも同様です。 docs.ansible.com PostgreSQL データベースのインストールはいくつかの方法があります。 外部に用意する (お勧め) OpenShift の永続ボリュームを使って設定 OpenShift の一時ボリュームを使って設定 今回はお試しなので、簡単にインストールできる方法の一時ボリュームを使って設定することにします。 RHEL 8.3 上に Tower のインストーラを展開したら、inventory ファイルを設定します。 #localhost ansible_connection=local ansible_python_interpreter="/usr/bin/env python" localhost ansible_connection=local ansible_python_interpreter=/usr/libexec/platform-python [all:vars] admin_user=admin admin_password='XXXXXXXX' secret_key='XXXXXXXX' pg_username='awx' pg_password='XXXXXXXX' pg_database='tower' pg_port=5432 pg_sslmode='prefer' # set to 'verify-full' for client-side enforced SSL openshift_host=https://api.crc.testing:6443 openshift_skip_tls_verify=true openshift_project=tower openshift_user=kubeadmin openshift_password=XXXXXXXXXXXXXXXXXXXXXXXX openshift_pg_emptydir=true この CRC 環境では、特にこの2つの値はこのように設定しないと動きませんのでご注意ください。 openshift_host=https://api.crc.testing:6443 openshift_skip_tls_verify=true あとは setup_openshift.sh を実行します。 [sugimura@toptonpc ansible-tower-openshift-setup-3.8.2-1]$ ./setup_openshift.sh OpenShift としては tower プロジェクトとして設定されます。oc コマンドや Web UI から確認してみてください。 [sugimura@toptonpc ~]$ oc login -u kubeadmin https://api.crc.testing:6443 Authentication required for https://api.crc.testing:6443 (openshift) Username: kubeadmin Password: Login successful. You have access to 64 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "mkdocs-dev". [sugimura@toptonpc ~]$ oc get all -n tower NAME READY STATUS RESTARTS AGE pod/ansible-tower-786dcc67d8-7r6nb 3/3 Running 0 22h pod/postgresql-1-deploy 0/1 Completed 0 22h pod/postgresql-1-vl7rp 1/1 Running 0 22h NAME DESIRED CURRENT READY AGE replicationcontroller/postgresql-1 1 1 1 22h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/ansible-tower-web-svc NodePort 10.217.4.39 <none> 80:30695/TCP 22h service/postgresql ClusterIP 10.217.4.148 <none> 5432/TCP 22h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/ansible-tower 1/1 1 1 22h NAME DESIRED CURRENT READY AGE replicaset.apps/ansible-tower-786dcc67d8 1 1 1 22h NAME REVISION DESIRED CURRENT TRIGGERED BY deploymentconfig.apps.openshift.io/postgresql 1 1 1 config NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD route.route.openshift.io/ansible-tower-web-svc ansible-tower-web-svc-tower.apps-crc.testing ansible-tower-web-svc http edge/Redirect None [sugimura@toptonpc ~]$ ここに出ているように、 https://ansible-tower-web-svc-tower.apps-crc.testing/ にアクセスすると Ansible Tower のログイン画面が出てきます。あとはオンプレミス版と同じように、ライセンス情報を投入すれば使うことができます。 OpenShift のデプロイメントから Pod をスケールアウトすることで動的にノード数を拡張したりすることはできますが、OpenShift 版の Tower には制限がありまして、isolated node はご利用いただくことができません。 CRC 環境のデバッグ CRC の動きがなにかおかしいというときには、いくつか調査するための方法があります。 情報収集 [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc version CodeReady Containers version: 1.23.1+be17b141 OpenShift version: 4.7.0 (embedded in executable) [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc status --log-level debug DEBU CodeReady Containers version: 1.23.1+be17b141 DEBU OpenShift version: 4.7.0 (embedded in executable) DEBU Running 'crc status' DEBU Checking file: /home/sugimura/.crc/machines/crc/.crc-exist DEBU Checking file: /home/sugimura/.crc/machines/crc/.crc-exist DEBU Found binary path at /home/sugimura/.crc/bin/crc-driver-libvirt DEBU Launching plugin server for driver libvirt DEBU Plugin server listening at address 127.0.0.1:38205 DEBU () Calling .GetVersion DEBU Using API Version 1 DEBU () Calling .SetConfigRaw DEBU () Calling .GetMachineName DEBU (crc) Calling .GetState DEBU (crc) DBG | time="2021-03-14T16:32:46+09:00" level=debug msg="Getting current state..." DEBU (crc) DBG | time="2021-03-14T16:32:46+09:00" level=debug msg="Fetching VM..." DEBU (crc) Calling .GetBundleName DEBU (crc) Calling .GetIP DEBU (crc) DBG | time="2021-03-14T16:32:46+09:00" level=debug msg="GetIP called for crc" DEBU (crc) DBG | time="2021-03-14T16:32:46+09:00" level=debug msg="Getting current state..." DEBU (crc) DBG | time="2021-03-14T16:32:46+09:00" level=debug msg="IP address: 192.168.130.11" DEBU Running SSH command: df -B1 --output=size,used,target /sysroot | tail -1 DEBU Using ssh private keys: [/home/sugimura/.crc/machines/crc/id_ecdsa] DEBU SSH command results: err: <nil>, output: 32737570816 16375975936 /sysroot DEBU Running private SSH command DEBU SSH command succeeded DEBU Unexpected operator status for network: ManagementStateDegraded DEBU Making call to close driver server DEBU (crc) Calling .Close DEBU Successfully made call to close driver server DEBU Making call to close connection to plugin binary CRC VM: Running OpenShift: Running (v4.7.0) Disk Usage: 16.38GB of 32.74GB (Inside the CRC VM) Cache Usage: 13.01GB Cache Directory: /home/sugimura/.crc/cacheDEBU (crc) DBG | time="2021-03-14T16:32:47+09:00" level=debug msg="Closing plugin on server side" [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ./crc config view - consent-telemetry : no - cpus : 10 - memory : 49152 - nameserver : 192.168.0.93 - pull-secret-file : /home/sugimura/pull-secret.json VM の中に入る [sugimura@toptonpc crc-linux-1.23.1-amd64]$ export CRC_IP=$(./crc ip) [sugimura@toptonpc crc-linux-1.23.1-amd64]$ ssh -i ~/.crc/machines/crc/id_ecdsa core@$CRC_IP Red Hat Enterprise Linux CoreOS 47.83.202102090044-0 Part of OpenShift 4.7, RHCOS is a Kubernetes native operating system managed by the Machine Config Operator (`clusteroperator/machine-config`). WARNING: Direct SSH access to machines is not recommended; instead, make configuration changes via `machineconfig` objects: https://docs.openshift.com/container-platform/4.7/architecture/architecture-rhcos.html --- Last login: Sun Mar 14 07:35:09 2021 from 192.168.130.1 [core@crc-l6qvn-master-0 ~]$ おわりに CRC (Red Hat CodeReady Containers) についてインストールするところから、Ansible Tower のインストールを通して OpenShift として使ってみるというところまで紹介してみました。ご興味持たれましたらお手元でも同じように試していただけましたらと思います。 Ansible Towerの評価ライセンスリクエストはこちらからご利用いただけます。 www.redhat.com Happy Automation!

みなさんこんにちは、Red Hatの能島です。Red Hatでは、省メモリ、高速起動など、コンテナ環境での動作に求められる要件に基づいて新しく設計されたQuarkusというオープンソースのJavaのアプリケーションフレームワークの開発を主導してますが、その 公式サイト の 日本語版 (https://ja.quarkus.io) を公開しました。 Quarkusの公式サイトでは、Quarkusの各種機能の利用方法を解説するガイドや、ブログなど、Quarkusに関する情報が豊富に揃っています。その公式サイトの日本語化をRed Hat社員の有志で進めてきましたが、今回、正式に https://ja.quarkus.io で公開を開始しました。まだ一部コンテンツは翻訳が終わっておらず、今後順次翻訳を進めてまいります。 翻訳の取組自体、GitHub上のパブリックなレポジトリ ( https://github.com/quarkusio/ja.quarkus.io ) でオープンに進めていますので、ご興味のある方は翻訳プロジェクトに参加頂けると大歓迎です。DeepL APIを活用した下訳が自動で行われていますので、分量は多いですが始め易いかと思います。 DeepL APIを活用した下訳など、公式サイト翻訳の取組の技術的なポイントについては、いずれ別記事で紹介させて頂きたいと思います。 おわりに Quarkus、後発のJavaのアプリケーションフレームワークということもあり、非常に使いやすく、分かりやすいフレームワークに仕上がっています。公式サイトの日本語版の提供開始のこの機会に是非お試しください！

  本記事はOpenShiftコンソールの ・多言語UI対応が始まる ・Webコンソール画面でクイックスタートが利用可能 この2つについて取り上げます。   はじめに 多言語UI対応が始まる Webコンソール画面でクイックスタートが利用可能 おわりに     はじめに こんにちは、 クラウドインフラ全般を担当しているソリューションアーキテクトの伊藤です。 OpenShiftはバージョン4.7が提供開始され、様々な機能強化がありました。今回はその様々な機能強化の中でもWebコンソール部分に絞って機能をご紹介したいと思います。   OpenShiftは当然のようにCertified Kubernetes Conformance Programを取得しており、 Kubernetesに期待されているKubernetesとしての動作に適合しています。 その上でOpenShiftのWebコンソールでは、Kubernetesをより強化する方向で以下の4点に注力をしています。 ・Developing on Kubernetes ・Learning Kubernetes ・Extending Kubernetes ・Managing Kubernetes     つまり、OpenShiftはKubernetesの上で管理、機能拡張、学習を成し遂げており、それに加えてKubernetesの上でアプリケーション開発ができるような仕組みを整えています。   多言語UI対応が始まる OpenShift 4.7から多言語UIが提供されるようになりました。 従来からの英語に加えて日本語、中国語に対応し、今後は韓国語も追加される予定になっています。 ブラウザの言語設定に合わせてデフォルトの言語設定が行われます。任意で言語の変更も可能です。   馴染み深い日本語でWebコンソールが利用可能になったので、今まで英語ばかりで学習しづらかった方には学習の第一歩になるのではないでしょうか。         Webコンソール画面でクイックスタートが利用可能 日本語Webコンソールの追加に加えて、クイックスタートの利用が可能になりました。 OpenShiftを使用されている方が、一方的にクイックスタートが利用できるようになった訳ではなく、 デフォルトで備わっているクイックスタートに加えて、自分自身でクイックスタートが作れるようになります！ OpenShiftを提供するプラットフォームエンジニアが、アプリケーション開発エンジニアに向けてHow toを共有することができます。 また、自社サービスとしてOpenShiftを提供している企業様が、自社サービスとしてお客様のためにHow toを提供することもできます。     そして、なんとこのクイックスタートの機能ですが、KubernetesらしくCRDで提供されています！ ConsoleQuickStart CRDで定義するので、Kubernetesに精通したエンジニアがCRDを使ってKubernetes初心者にステップバイステップで 使い方を教えることができるという、理にかなった仕組みです。         クイックスタートの作成にはガイドラインも提供されています。 マークダウンで構成されており、エンジニアであれば比較的低い難易度でクイックスタートを作成することができます。 以下のURLをご確認頂けるとKatacodaによく似た形で実装できることが分かると思います。   openshift.github.io   最初から備わっているクイックスタートを見るには、ConsoleQuickStart CRDで定義されたリソース一覧を検索します。   おわりに 本記事ではOpenShift4.7で利用可能になった、多言語UIとConsoleQuickStart CRDについてご紹介をしました。 バージョンが上がるにつれてすべてのエンジニアを支援する仕組みが増えており、コンテナ基盤導入の敷居が下がっていっていると言えます。   その他にKubernetes上でのアプリケーション開発を支える仕組みとして以下の記事を紹介いたします。   CodeReady Workspacesをカスタマイズして便利に開発してみよう その1 rheb.hatenablog.com   Eclipse CheをベースにしたCodeReady Workspaceというもので、Kubernetes上でのアプリケーション開発を支えています。    

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。 毎月何か書くはずだったのですが2月はとても時間が過ぎるのが早く、結局28日の夜になりました。 今回は Ansible Tower のアップグレードについてお話します。 Ansible Tower のライフサイクル 最近は5月と11月にリリースが出て、1年半後にEOL(End Of Life)となる流れが続いています。いま最新版の3.8については、2年間サポートするものとなりました。3.x 系としての最終版となることが予定されています。 access.redhat.com 3.6 は5月にEOLとなってサポートを提供できなくなります。以前の記事にも書きましたが、3.7 ではアーキテクチャを刷新して大きくパフォーマンスの改善が行われましたので、まだお使いのお客様には少しでも早くバージョンアップをご検討いただきたいところです。 rheb.hatenablog.com 3.6 まで使われていた RabbitMQ は安定稼働させることが難しく、これまでさまざまなトラブルを経験してきました。ようやく捨てることができることになって我々サポートエンジニアも一つ大きな肩の荷を降ろせると喜ばしく思っています。 バックアップに含まれるもの アップデートのためには、まずはバックアップを取っていただくことをお勧めします。 Ansible Tower のバックアップはインストール時に使った setup.sh を使いまして、setup.sh -b コマンドで取ることができます。そのバックアップには、このような内容が含まれています。 PostgreSQL データベースのダンプファイル /etc/tower/ にある設定ファイル (DBへの接続情報など) /var/lib/awx/projects/ ディレクトリに格納されている「手動」プロジェクト /var/lib/awx/venv/ に作成した virtualenv 環境 (awx, ansible を除く) この4点目で注意なのですが、Ansible Tower が提供する標準の Ansible Engine のための virtualenv 環境 (/var/lib/awx/venv/ansible) に Python モジュールを追加して構成されている場合であっても、バックアップは取られません。必要なときには再度 pip でインストールする必要があります。 こちらのドキュメントにも記載しておりますのでご覧ください。わたしが書いたものです。 access.redhat.com バックアップから戻すときには、Ansible Tower をまず構成してから setup.sh -r コマンドで戻します。Ansible Tower を構成してからというのがポイントで、新しく別にインストールした場合であっても戻すことができます。もちろん既存の Tower にそのまま戻していただくこともできます。 リストア時の注意 Ansible Tower のバックアップからのリストアは、同じバージョンのものからしか行うことができません。 アップデートと一緒に構成も変えたいときは、まず同じ Tower のバージョンで構築してからバックアップをリストアし、そこからアップデートしていただくという流れになります。 RHEL 7 から 8 への移行 Ansible Tower 3.8 は RHEL 7 をサポートする最後のバージョンとなりました。 まだまだ自動化の対象が RHEL 8 に移行できないということも多いとは思いますが、Tower はその外側から基本的には SSH だけで接続して操作するというものですので、Ansible Tower だけでも RHEL 8 にして使っていただくことをご検討いただきたいです。 RHEL 7 でお使いの Tower を RHEL 8 にしていただくためにはこのような方法になります。 RHEL 7 の Tower でバックアップを取得する (setup.sh -b) RHEL 8 を新規構築するか、RHEL 8 に直接(in-place)アップデートする setup.sh を実行する setup.sh -r でバックアップからリストアする (可能であれば) Tower を最新版にアップグレードする RHEL 7 を RHEL 8 に直接アップデートする方法についてはこちらのドキュメントをご確認ください。 access.redhat.com このとき、新規構築した場合でも RHEL をアップデートした場合でも、Ansible Tower としては基本的に再構築と同じ扱いになります。リストア処理の中で再構築した状態を収集しつつ、バックアップから戻して再度きちんと構成しなおすという流れになります。 また、virtualenv に作った Ansible Engine の実行環境については、Python の実行環境の違いからそのままでは動作しませんので、再度作っていただく必要があります。実行環境についてはこちらもご覧ください。 rheb.hatenablog.com シングル構成からクラスタ構成へ バックアップからリストアするときに構成を変えてもよいということで、シングル構成で作った Tower をクラスタ構成にすることについても同じ方法で実施いただけます。 シングル構成でバックアップ (setup.sh -b) クラスタ構成用にインベントリを編集してインストールを実行 (setup.sh) (別に構築したのであれば) バックアップからリストアする (setup.sh -r) (RHEL 7 から 8 へ移行した場合は) virtualenv を再構成する (可能であれば) Tower を最新版にアップグレードする Ansible Tower はさまざまな構成を取ることができますが、それまで運用されていたジョブテンプレートやインベントリなどの情報をそのまま引き継いで、クラスタ構成に拡張するなどができるようになっています。 シングル構成 (Ansible Tower と PostgreSQL が同居) シングル構成 + 外部DB クラスタ構成(3台〜20台) + 外部DB 最初は小さく始めていただくところからだと思いますが、お使いになるうちに自動化の対象が拡大してきたり、ジョブ実行のパフォーマンスを上げたいということが出てくると思います。バックアップを取って新しく構築して戻す、という流れで基本的にはそのまま移行していただけます。 インスタンスグループについて ここまでは isolated node については触れませんでしたが、Ansible Tower はクラスタ構成や isolated node の構成のためのインスタンスグループの設定についても PostgreSQL データベースに保存して管理しています。構成の異なるバックアップからリストアしたい場合には、リストア処理の中できちんと対応していますので安心してリストアすることができます。具体的には、このような流れでリストアを実行します。 構築されたインスタンスグループの情報を収集 バックアップに含まれる PostgreSQL のダンプファイルから書き戻す 収集したインスタンスグループの情報をさらに上書きする おわりに 最新版の RHEL 8 で最新版の Ansible Tower 3.8 を使っていただきたいということで、一つ記事をまとめてみました。 毎度毎度のご案内になりますが、Ansible Towerの評価ライセンスリクエストはこちらからご利用いただけますのでお試しください。 www.redhat.com Happy Automation!

Red Hat で OpenShift のコンサルタントをしている橋本です。 今回は Software Design 2021 年 4 月号に掲載予定だったものの、紙面の都合でカットしたトピックをご紹介します。 もともとは Fedora CoreOS とセキュリティをテーマに、ホスト OS や OKD におけるセキュリティの機能を紹介する予定でしたが、最終的に 20 ページになり、7 ページまで減らす必要があったため、ここでは次のテーマを掲載します。 NIST SP 800-190 におけるセキュリティの範囲は？ Multus CNI プラグインにどれを選ぶ？ Linux カーネルを用いるコンテナ技術 rpm-ostree による OS のバージョン管理 Ignition によるシステムの初期化 NIST SP 800-190 におけるセキュリティの範囲は？ 具体的にコンテナやコンテナ基盤に関するセキュリティとはどの様な分類でリスクを評価するのでしょうか。 例えば NIST SP 800-190 *1 ではコンテナやコンテナ基盤に対する汎用的なセキュリティ基準を定義しており、コンテナ技術における主要なコンポーネントに対するリスクを次のように分類します。 *2 NIST SP 800-190 イメージに関するリスク: イメージの脆弱性、Dockerfile やイメージ設定の不備、マルウェアや認証情報の埋め込み、信頼されないイメージの利用 レジストリに関するリスク: セキュアでない通信の利用、利用していないイメージの脆弱性、認証や認可の不備 オーケストレーターに関するリスク: マルチテナンシーと権限分離の不備、オーケーストレーション自身の認証、オーバーレイによるPod 間通信、機密性のレベルによる分離、Control Plane と Worker Node の信頼性 コンテナに関するリスク: コンテナランタイムの脆弱性、コンテナからホスト OS へのアクセス、コンテナランタイムの設定不備、アプリケーションの脆弱性、不正なコンテナの起動 ホスト OS に関するリスク: 攻撃対象となるサービスの公開、カーネルの共有、ホスト OS の脆弱性、不要なユーザ権限の付与、ファイルシステムの改ざん この様にして、主要なコンポーネントに焦点をあてることで、コンテナ技術、ホスト OS、オーケストレーター、またはパブリックまたはプライベートクラウドなどプラットフォームに依存せず、汎用的に適用される規格を目的としています。そのため、例えば、開発者の検証環境、管理者のシステム、ホストハードウェアと仮想マシンといった間接的に関与するコンポーネントに関するリスクは含まれません。 次にコンテナに関するリスク想定する場合、コンテナランタイムの脆弱性による権限昇格や権限の適用に対する設定の不備などに加えて、マルウェアや設定の不備による認証情報の埋め込み、ソフトウェア提供ベンダーやコミュニティ以外からの信頼されないイメージの利用などコンテナイメージにおける関するリスクが考えられます。 そこで NIST SP 800-154 *3 におけるデータを中心としたシステム脅威モデルにより項目が評価され、保護すべきデータにイメージとコンテナが該当します。前者はアプリケーションのプロパティファイルやデータを含むファイルが、後者はメモリ、ストレージや NIC などホストで共有されるリソースが該当します。 Multus CNI プラグインにどれを選ぶ？ Kubernetes ではネットワークは単一であるため、Control Plane と Worker Node 間やアプリケーションをデプロイする Pod 間の通信は全て同じ仮想 NIC を経由します。ネットワークを追加する、つまり Pod に NIC を追加する場合、Multus CNI プラグインを利用します。 *4 ただし複数の CNI プラグインがあるため、どれを選ぶべきかが悩みどころになります。 まず CNI ネットワークプラグインは Main、IPAM、Meta の 3 種類に分類されます。 *5 Main: NIC を作成し Pod に NIC を割り当てる IPAM: Main プラグインに対して IP アドレスを管理する Meta: Bandwidth、Tuning や Flannel など機能がプラグイン毎に異なる 次に主要な IPAM プラグインと Main プラグインの概要は次の通りになります。 IPAM プラグイン Plugin Description host-local * 同じホスト上だけを対象に IP アドレスを割り当てる * IP アドレスは各ホストのローカルで管理する dhcp * IP アドレスの管理に外部の DHCP サーバを利用する whereabouts * クラスタを対象に動的に IP アドレスを割り当てる * IP アドレス を Custom Resource で管理する static * 静的に IP アドレスを割り当てる Main プラグイン Plugin Description bridge * 同じホスト上の Pod を仮想ブリッジ経由で通信させる * ホスト外部のネットワークに通信できない host-device * 同じホスト上の Pod をホストの NIC 経由で通信させる * ホスト外部のネットワークに通信できる ipvlan * 同じまたは異なるホスト上の Pod をホストの NIC (sub-interface) 経由で通信させる * Pod にホストの NIC と同じ MAC アドレスが割り当てられるため、MAC アドレスが制限される環境で選択する *6 *7 macvlan * 同じまたは異なるホスト上の Pod をホストの NIC (sub-interface) 経由で通信させる * Pod に異なる MAC アドレスが割り当てられるため、MAC アドレスが制限されない環境で選択する 上記の通り Main と IPAM プラグインは目的や制約が異なるため、ユースケースに応じたプラグインの選択とプラグインの組み合わせを検討する必要があります。 Main と IPAM プラグインにおいて、推奨される組み合わせの一例は次の様になります。 *8 bridge + host-local bridge: 同じホスト上の Pod 同士を通信させることを目的とするため、IP アドレスもローカルで管理する host-local IPAM プラグインを利用する host-device + dhcp: 同じホスト上の Pod を対象にホストの NIC 経由で通信させるが、ホストのネットワークを利用するため dhcp IPAM プラグインを利用する ipvlan + whereabouts: ipvlan の sub-interface は ホストの NIC と同じ MAC アドレスを共有し、MAC アドレスに依存する dhcp IPAM プラグインの利用は制限されるため、whereabouts IPAM プラグインを利用する *9 macvlan + static: macvlan の sub-interface はホストの NIC とは異なる MAC アドレスが割り当てられるため、 dhcp や static IPAM プラグインを利用する Linux カーネルを用いるコンテナ技術 Linux コンテナ は Namespaces、SELinux、cGroups (Control Groups)、Capabilities といった Linux カーネルを利用するため、基本的なセキュリティの考えは Linux カーネルに依存します。 *10 *11 Linux Container Linux Namespaces は Linux カーネルが扱うマウント、PID、ネットワークなどシステムリソースを分離します。アプリケーションをサンドボックス化するために Namespaces (名前空間) にを用いてホスト上で個々のコンテナを分離し、コンテナ毎に独立してリソースを分配、分割、制限させます。 *12 Namespace SELinux はポリシーベースのルールとラベルを用いて、コンテナ(プロセス) にラベルをセットすることで、実行中のコンテナがアクセスできるシステムリソースを他のコンテナやホストから隔離します。 *13 これは Namespace 単体ではプロセスがコンテナ外部にアクセスすることを制御できず、別の隔離レベルを利用する必要があるためで、SELinux を有効にすることで新たに隔離する層を設けます。 *14 特に SELinux はファイルシステムに対して有効性が挙げられた例が多く、privileged 権限に対する脆弱性 *15 や runc の脆弱性 *16 が挙げられます。 SELinux cGroups はプロセス (コンテナ) に対する CPU、メモリ、ネットワーク帯域幅 や ディスク I/O などリソースの割り当てや優先度を管理します。例えば Dos や DDos などの攻撃によりあるコンテナがシステムリソースを大量に消費して、他のコンテナやホストのリソースが枯渇することを防ぎます。 Capabilities はコンテナに割り当てる権限を管理します。Linux では UID 0 を持つ Root ユーザは Capabilities と呼ばれる複数のグループに分割した権限から構成され、Capabilities は個別に有効、または無効にすることができます。例えば Capabilities の 1 つに Well-known ポートをバインドさせる CAP_NET_BIND_SERVICE がありますが、コンテナを起動する上で一般的に必要なく、かつ不要な権限をコンテナに割り当てることは Attack Surface を増やすため、必要最低限な Capabilities に制限されています。 *17 rpm-ostree による OS のバージョン管理 rpm-ostree はソースコード管理における Git やコンテナのイメージレイヤーの様にファイルシステムをブランチ (ファイルシステムツリー)として管理します。バージョンのロールバックやアップグレードといった一連のファイルシステムに要求する変更に対し、Atomic Commit *18 を前提に単一のオペレーションで完結させます。 *19 またパッケージ管理において、FCOS は YUM や DNF はインストールされておらず、代わりに rpm-ostree ツールが提供され、rpm-ostree コマンドでパッケージをインストールするとコンテナイメージをビルドするようにファイルシステムに対して変更がコミットされ、レイヤー毎に変更がバージョンとして管理されます。 *20 *21 これは rpm-ostree は OSTree *22 と libdnf *23 ライブラリから構成され、RPM や dpkg など従来のパッケージマネージャとは依存関係を解決するためのメタデータやスクリプトを用いたファイルシステムツリーが異なるためです。 なお OKD では、Kernel パラメタの設定を変更するなど /etc 配下に変更を加える場合、ホストにログインして手動で変更するのではなく、Machine Config Operator (MCO) を用いて自動化しています。Control Plane 上で中央管理される Machine Config オブジェクトに設定を定義し、MCO が 各 Worker Node に設定を配布します。 *24 なお Configuration Drifft の観点から推奨はされませんが、ホスト上で設定を直接変更した場合、ホストへの変更は永続化されるため、OS の再起動で変更が切り戻されはしません。 Ignition によるシステムの初期化 Ignition は Anaconda Kicksart *25 による OS インストールの自動化や cloud-init *26 による OS 起動後の設定を追加するツールと似ていますが、システムの初期化を目的としている点が決定的に異なります。一例として Ignition は次の処理を実行させることができ、これは初期 RAM ディスクを利用するため 、ディスクのパーティションや物理ホストに対するスクラッチでの OS のインストールといったシステムがブートする直後に関する処理を管理します。 *27 ディスクのパーティション ディスクのフォーマット Systemd Unit の定義 各種設定ファイルの書き込みやディレクトリの作成 ユーザの作成 なお Ignition Config の形式は JSON であり、またディスクパーティションや Systemd の設定など多岐に渡るため、Ignition Config を手動で管理することは煩雑です。そのため FCOS では Ignition Config と互換性のある YAML 形式の Fedora CoreOS Configuration (FCC) とコンバート用のツールである Fedora CoreOS Configuration Transpiler (FCCT) が提供され、FCCT を用いて YAML 形式の FCC ファイルを JSON 形式の Ignition Config として生成します。 *28 例えば OKD をインストールする際、インストーラー (openshift-installer) が Ignition Config を生成するため、Ignition Config を手動で作成したり、FCCT で YAML から Ignition Config を生成することは基本的にありません。ただし設定の変更は可能でインストール前後で変更可能な設定やオペレーションを次のように Day 1 と Day 2 として定義しています。 *29 Day 1: ディスクの暗号化、カーネルの引数やカーネルモジュールの有効化など OS インストール時に適用されるオペレーション Day 2: Systemd Unit の変更などクラスタが構築された後に適用されるオペレーション いかがでしたでしょうか、紙面から除外した議題を掲載しているため、網羅性よりもかなり特定の議題にフォーカスしています。 OpenShift のセキュリティに関して興味がある方は Software Design 2021 年 4 月号をお待ち下さい。 *1 : 最終版は 2017 年 9 月 25 日に起草され、その後 2020 年 9 月 4 日に IPA より日本語版も公開されています。 https://csrc.nist.gov/publications/detail/sp/800-190/final *2 : 図は https://csrc.nist.gov/publications/detail/sp/800-190/final より抜粋しています。 *3 : https://csrc.nist.gov/publications/detail/sp/800-154/draft *4 : Multus CNI プラグインのアーキテクチャや各プラグインの概要を解説しています。 https://www.openshift.com/blog/demystifying-multus *5 : https://www.cni.dev/plugins/ *6 : ポートセキュリティの様にスイッチの物理ポート毎に MAC アドレスの最大数が制限されているケースが該当します。 *7 : 例えばパブリッククラウドを利用する場合、AWS では Promiscuous Mode が許可されないため macvlan を利用することはできず、ipvlan が推奨されます。 https://access.redhat.com/solutions/5508011 *8 : サポートされる機能の制約ではないため、詳細は各プラグインの説明を参照して下さい。 https://docs.okd.io/latest/networking/multiple_networks/understanding-multiple-networks.html *9 : DHCP Client ID だけに対応し dhcp IPAM プラグインの利用はサポートされていません。 https://www.cni.dev/plugins/main/ipvlan/ *10 : Linux コンテナを構成する技術の概要をこちらで公開しています。 https://access.redhat.com/ja/articles/1459113 *11 : コンテナに求められるセキュリティの概要をこちらで公開しています。 https://www.redhat.com/ja/resources/container-security-openshift-cloud-devops-whitepaper *12 : 各コンテナに独自の Init (PID 0)を持たせるために ホストや他のコンテナから PID を分離させる PID Namespace 、ルーティングテーブルや FW を分離し、仮想 NW スタックを持たせる Network Namespace が該当します。 *13 : 初学者向けに分かりやすくSELinux の概念を漫画で解説しています。 https://opensource.com/business/13/11/selinux-policy-guide *14 : Kubernetes で利用できる Linux カーネルのセキュリティモジュールに AppArmor が該当しますが、SELinux は AppArmour よりも複雑ではあるものの、AppArmour は Multi-Category Security (MCS) をサポートしていないことから、コンテナの権限を分離することができず、Pod 間の隔離に対応しないことなどが挙げられます。 https://www.redhat.com/sysadmin/apparmor-selinux-isolation *15 : コンテナにファイルディスクリプタにアクセスする権限を与えても、コンテナが起動するホストにアクセスすることを防ぎます。 https://www.redhat.com/en/blog/selinux-mitigates-container-vulnerability *16 : コンテナエスケープによりコンテナがホストに任意のコマンドを実行させることを防ぎます。 https://www.redhat.com/en/blog/latest-container-exploit-runc-can-be-blocked-selinux *17 : Linux Capabilities の詳細と SCC を用いた Capabilities の適用方法を解説しています。 https://www.openshift.com/blog/linux-capabilities-in-openshift *18 : https://en.wikipedia.org/wiki/Atomic_commit *19 : 内部的には切り替えに chroot を用いています。 https://ostreedev.github.io/ostree/adapting-existing/ *20 : パッケージをインストールする毎にレイヤーが作成されるため、複数のパッケージを指定することで単一のレイヤーで完結させることができます。 https://docs.fedoraproject.org/en-US/iot/add-layered/ *21 : パッケージ管理の仕組みは、本誌 2020年7月号 “月間Fedoraジャーナル Fedora系ディストリビューションにおけるパッケージ管理の変遷” で解説しています。 https://gihyo.jp/magazine/SD/archive/2020/202007 *22 : 以前の名称は OSTree で、現在は Libostree プロジェクトです。 https://ostreedev.github.io/ostree/ *23 : DNF のバックエンドとしてハイレベルな API を提供するために利用されています。 *24 : https://docs.okd.io/latest/post_installation_configuration/machine-configuration-tasks.html *25 : https://anaconda-installer.readthedocs.io/en/latest/kickstart.html *26 : https://cloudinit.readthedocs.io/en/latest/# *27 : https://coreos.com/ignition/docs/latest/examples.html *28 : https://docs.fedoraproject.org/en-US/fedora-coreos/fcct-config/ *29 : https://docs.okd.io/latest/installing/install_config/installing-customizing.html

Red Hatのソリューションアーキテクトの松田絵里奈です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services]に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2021/3月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: CodeReady Workspacesをカスタマイズして便利に開発してみよう その1 rheb.hatenablog.com 特集2: 今注目のOSS, Apicurio - APIファーストの設計からイベント駆動アーキテクチャにおいて重要なスキーマ管理まで 今回のニュースレターのIntegrationセクションでは、Red Hat Integrationの中にも含まれているOSSであるApicurio ( https://www.apicur.io/ ) について紹介させて頂きます。ApicurioはAPI設計ツールやスキーマレジストリ機能など、APIに関わるとても便利なツールを提供しており、いくつかのサブプロジェクトに分かれていますが、特に注目すべきは以下になります： Apicurio Studio / Apicurio : APIファーストのアプローチを実践するためのツールとして、OpenAPIのドキュメントをGUIベースで作成するための設計ツール Apicurio Registry : Apache Kafkaなどで使われるメッセージのスキーマ定義やOpenAPIなどのAPIドキュメントを格納するためのレジストリ機能を持ったツール これらのツールの使い方について、シェルスクリプトマガジンに掲載された記事がPDFでダウンロード可能となっておりますので、ぜひダウンロードして実際に試してみて頂ければと思います。 www.redhat.com また、Apicurio Studioと組み合わせて使われることの多いOSSのモックサーバーMicrocks ( https://microcks.io/ ) とApicurio Studioを使い、APIファーストの開発アプローチを実際に試す方法についての記事もありますので併せてお読み頂ければと思います。 thinkit.co.jp 特集3: 業務ルールの整理に役立つ！DMNを知っていますか？ DMNとは、Decision Model and Notationのことで、OMG (Object Management Group)により制定された、ビジネス上の意思決定とビジネスルールを正確に指定するためのモデリング言語および表記法です。 業務ルールを整理し定義する際に、DMNを使うことで、要件定義・設計・実装における認識の齟齬を低減し、開発効率と品質を向上することが期待されます。 DMNの基本についてまとめてみましたので、こちらご覧ください。 qiita.com SCSKセミナー記事の紹介 ルールエンジンベンダー3社がSCSK様主催のイベントでセッションを行いました。初めての企画でした！内容が記事化されましたのでぜひご一読ください。各社が考えているWith/After コロナでのお客様の方向性など、興味深い記事となっています。レッドハットからはソリューションアーキテクトの梅野が語っております。 redhat.lookbookhq.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat Process Automation Manager 7.10 Red Hat Decision Manager 7.10

みなさんこんにちは、レッドハットでソリューションアーキテクトをしている暮林といいます。 今回はCodeReady Workspacesの便利なカスタマイズ方法を紹介してみたいと思います。 CodeReady Workspacesって何？という方は下記のエントリを読んでみてください。 rheb.hatenablog.com 第一回は開発者自身がCodeReady Workspacesを自分用にカスタマイズする方法をステップ・バイ・ステップで紹介します。（標準化は第二回以降で扱おうと思います） 仮想しばり 素のCodeReady Workspacesでできること 素のCodeReady Workspacesではできないこと ゴール設定 必要条件 実践！ STEP1 Dockerfileの準備 STEP2 イメージビルドの準備 STEP3 イメージビルド STEP4 Workspaceからtoolboxのイメージをpullできるようにする STEP5 QuickStartへの組み込み STEP6 動作確認 Next Action！ 仮想しばり 本エントリのレギュレーションとして「請負開発をしていて、開発用PCには強い統制がかけられている」といった状況を想定してみます。具体的には下記の通り。 OA向きのWindowsPC（良くて2Coreメモリ4GB)しか支給されていない（Windows10ともかぎらない） PCには認められたツールしかいれることができない 有償のツールは開発メンバーの人数分買わないといけないので、おいそれと稟議にかけられない 素のCodeReady Workspacesでできること CodeReady Workspacesは、ほぼデフォルトのままデプロイした場合でも下記のようなことが簡単に実現できます。 Eclipse cheベース（使い勝手はVisual Studio Codeに近い）のエディタでいろいろな言語の開発ができる Workspaceにアタッチされているコンテナ(Linux)のなかで、いろいろなコマンドを発行できる Eclipse cheはブラウザベースなので、PCにはモダンブラウザだけあればいい KeycloakでSSO（シングルサインオン）できる 素のCodeReady Workspacesではできないこと そのままでは少し(人によっては大きく）足りない部分があります。 あらかじめ準備されたコンテナ上に使いたいコマンドが揃っていない 第一回ではこれを解決してみようと思います。 ゴール設定 CodeReady WorkspacesはVisual Code Studioとちがって、新しいターミナルを起動するときに画面右側の直方体をクリックしてから、ターミナルを起動したいコンテナを選んで [>_ New terminal] を選択します。下記画像では予め準備されたmavenが表示されていますが、ここに自分で作成したコンテナイメージの [toolbox] を表示させて、好きなコマンドを含んだコンテナが起動できるようにすることがゴールです。 追加するコマンドは以下の3つを想定します ansible jq siege ansibleはいわずもがなですが、jqはcurlなどでREST APIを通して取得したJSONから特定の項目を抜き出すのに便利なツール、siegeはアプリケーションに負荷をかけてレポートまでざっとだしてくれるツールです。 必要条件 仮想縛りがあるのであまり条件は多くつけられませんが、最低これだけは必要です。 OpenShift上で自由にイメージビルドをさせてもらえるProject(Namespace)をもらえている CodeReady Workspacesがデプロイされていて使える状態にあること CodeReady Workspacesを動かせるモダンブラウザがPCにインストールされていること (OpenShiftからアクセスできるSCM（ソース管理）があること) ※なくてもなんとかなる Proxyを通す必要がある場合はDockerfileに一工夫必要です。 外部でイメージをビルドできる人はそもそも仮想縛りの条件から外れているかなと思います。 実践！ STEP1 Dockerfileの準備 まず動かしたいコンテナイメージを作る必要があるのでDockerfileを書きます。 例えばこんなかんじです。 ここにおいておくのでForkしてもらってもOKです。（試行錯誤した跡がが残っていて恥ずかしい） https://github.com/Tatsuyak9i/my-toolbox.git SCMにリポジトリを作って一番上の階層に「Dockerfile」という名前でCommitしてください。 FROM ubi8 USER root ENV \ APP_ROOT=/opt/app-root \ HOME=/opt/app-root/src \ PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ PLATFORM="el8" RUN dnf update -y && dnf clean all -y RUN dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm && dnf clean all -y RUN dnf install -y procps which hostname sshpass siege jq python3-pip && dnf clean all -y RUN mkdir -p ${APP_ROOT} && \ chown -R 1001:1001 ${APP_ROOT} && \ chgrp -R 0 ${APP_ROOT} && \ chmod -R g=u ${APP_ROOT} RUN useradd -u 1001 -r -g 0 -d ${HOME} -s /sbin/nologin \ -c "Default Application User" default && \ chown -R 1001:0 ${APP_ROOT} RUN pip3 install --upgrade pip RUN pip3 install ansible USER 1001 FROM ubi8 再配布可能なUBI8を使っています。UBIについてはこちらの「Universal Base Imageの提供」参照してください。他にもこのブログにはUBIを説明したエントリはいくつかあります。 rheb.hatenablog.com RUN dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm && dnf clean all -y まず先にepelを使えるようにします。本物のサーバーにこれをいれようとすると勇気がいりますが、toolboxとしてのコンテナイメージなら気軽にいれてしまえます。 epelの記事はこのへん。 rheb.hatenablog.com RUN dnf install -y procps which hostname sshpass siege jq python3-pip && dnf clean all -y RUN pip3 install ansible dnfでいくつかの便利ツールとjq siege pip3を導入したあとに、pip3でansibleを導入しているだけです。 /opt以下のディレクトリはとりあえず作っているだけで現状は大した意味は有りません。毎回 clean しているのはイメージを小さくするためのテクニックです。 プロキシサーバーを通す必要がある場合は、ENVの中に http_proxy=http://hogeproxy:3128 的な項目を追加してあげれば多分うまくいきます。 STEP2 イメージビルドの準備 次にSTEP1で用意したイメージをビルドします。が、その前にUBI8をプロジェクトにImportしておく必要があります。 Red Hat Ecosystem Catalog でUBI8を検索して開くとご丁寧にimportの仕方が書いてあります。 これを自由にイメージビルドしていいプロジェクト内で実施します。 イメージのビルドはCLIを使ったほうが楽なので、CodeReady Workspaces内のTerminalから実施することとします。 例としてQuarkusのQuickStartを使います。（コマンドを追加するのもこのQuarkusのQuick Startを流用します） 左側のGet Startedの中からQuarkusを選択してしばらく待ってください。 エディタが開いたら右側の直方体をクリックして、mavenのしたにある[>_New terminal]を開いてください 下にTerminalが開いたはずです。このコンテナイメージにはOpenJDK11やmavenコマンドに加えて、OpenShiftを操作するためのocコマンドも入っているのでこれを利用します。 （余談ですがocコマンドのWindows版は64bit版しかないので、Win7 32bitなどをクローズドネットワークなどでつかっているような環境では利用できなくて非常に困ります） OpenShiftにCLIからログインしますが、普段から実行して慣れている方はそのとおり実行してください。慣れていない方はOpenShiftにWebからログインして、右上のCopy Login Command をたどっていって、oc login ~ としている行をコピーアンドペーストしてください。 これでocコマンドを使う準備ができました。 STEP3 イメージビルド では実際にビルドをしていきます。 mytoolboxというプロジェクトを利用しているとします。 oc project mytoolbox oc import-image ubi8 --from=registry.access.redhat.com/ubi8 --confirm oc new-build https://github.com/Tatsuyak9i/my-toolbox.git oc start-build my-toolbox oc logs -f builds/my-toolbox-1 oc get is/my-toolbox 一気にやってしまいましたが、それぞれ以下の意味を持っています。 プロジェクトの移動 UBI8のインポート ビルドコンフィグをSCMから自動作成（s2iのDockerBuild) ここのURLは自分で用意したSCMのリポジトリURLに変更してください ビルドを実行 ビルドのログ確認（ビルド番号ごとに確認対象がかわります） できあがったイメージストリームを確認 表示されているログを眺めると普段のLinuxで実行しているコマンドの表示結果が流れているのがわかると思います。 リポジトリ上のURIはあとで使うのでひかえておいてください。 jboss@workspacehjbny26oj3qexphy projects]$ oc get is/my-toolbox NAME IMAGE REPOSITORY TAGS UPDATED my-toolbox image-registry.openshift-image-registry.svc:5000/mytoolbox/my-toolbox latest 19 hours ago STEP4 Workspaceからtoolboxのイメージをpullできるようにする OpenShiftでは内部レジストリがプロジェクト毎に保護されていて、別プロジェクトからそのまま利用することができないようになっています。 そこでmytoolbox projectでつくったイメージをCodeReady Workspacesからpullできるようにしてあげます。 個人ごとのWorkspaceはデフォルト設定の場合「ユーザー名-codeready」というプロジェクトの中に起動します。なのでこのプロジェクトに権限をあたえます。 oc policy add-role-to-group \ system:image-puller system:serviceaccounts:tkurebay-codeready\ --namespace=mytoolbox ユーザー名のところはご利用のものにかえてください。 STEP5 QuickStartへの組み込み devfileを改変していきます。一旦起動しているWorkspaceを止めてください。 左上の黄色い矢印をおして、起動しているWorkspacesを右クリックしてStopを押します。 Workspacesをクリックして最初につくったWorkspaceを選択してください。（素直にやっていれば１つしかありませんが、写真では記事の都合上２つあります） Devfileをクリックしてください。 components: の下にこの行を付け加えてください。 - mountSources: true command: - tail args: - '-f' - /dev/null memoryLimit: 512Mi type: dockerimage alias: toolbox image: 'image-registry.openshift-image-registry.svc:5000/mytoolbox/my-toolbox' command: のところが少々独特ですが、コンテナが起動したままになってほしいのでメインプロセスは深淵を覗いたままにしてもらいます。dockerやpodmanであれば -itとするところですね。 image: はSTEP3で控えたものですが、そのままやっていれば同じになると思います。 alias: はエディター上で表示される名前です。好きなように変えてOKです。 あとは画面下でSAVEをおして、右上のRUNをおしてください。RUNしたら左の一覧から起動したWorkspacesを選択してください。 STEP6 動作確認 起動したWorkspacesの右側の直方体をクリックしてみると、「toolbox」が表示されているはずです。 [>_ New terminal]をおして追加コマンドを実行してみてください。 追加したコマンドが実行できるか確認してみてください。 おめでとうございます！これでプライベートなカスタマイズに成功しました。 Next Action！ 便利ツールボックスの追加に成功したら、これをみんなに使ってほしいですよね？ 次回のエントリではツールボックスをみんなにつかってもらえるようにする方法を紹介してみたいと思います。乞うご期待！

こんにちは、RHEL のテクニカルサポートを担当している岡田です。 RHEL では Performance Co-Pilot (PCP) というパフォーマンス監視や分析のためのフレームワークを使うことができます。今回は PCP で取得したパフォーマンスメトリクスを Grafana を使って可視化する方法についてのブログ記事を翻訳したのでご紹介します。CPU 使用率やディスクビジー率など RHEL のパフォーマンス情報を可視化して監視する方法をお探しの方はぜひご覧ください。 www.redhat.com なお PCP については過去にも以下の記事で取り上げていますのであわせてご覧ください。 rheb.hatenablog.com rheb.hatenablog.com

レッドハットの森若です。 最近は以前より減ってきた気がするのですが、購入前にRHELに含まれるパッケージのバージョン番号だけをお問いあわせされるケースがあります。多くの場合中間に複数の人がいるため質問の本来の意図はよくわかりません。 今回はまずRHELに含まれるパッケージのバージョン確認方法を紹介して、次にバージョンの確認にはあまり意味がないことを説明します。 パッケージバージョンの確認方法 カスタマーポータル内の以下ページから、rpmパッケージを検索することができます。 https://access.redhat.com/downloads/content/package-browser RPMパッケージ検索 パッケージ名を入力して検索し、アーキテクチャをクリックすると、最新パッケージと、それが提供される製品がまとまったページが表示されます。バージョンを選択することで、過去に出荷されたパッケージや他の製品むけに出荷された別バージョンなども確認できます。 個別パッケージ画面 この検索をおこなうには有効なサブスクリプションが対応づけられたアカウントが必要です。 パッケージの細かいバージョンにあまり意味がない理由 Red Hat製品のパッケージの厳密なバージョンを確認することにはあまり意味がありません。その理由は大きく2つあります。 機能拡張やセキュリティfixのバックポート時にバージョンを変えないケースがある 機能をサポート対象外にしたり無効化するケースがある 順にみていきましょう。 機能拡張やセキュリティfixのバックポート時にバージョンを変えないケースがある Red Hatは基本的にupstream firstポリシーで開発をおこなっており、upstreamプロジェクトで拡張や修正を行ったのち、製品に反映します。 あるソフトウェア foobar で重大なセキュリティの問題が発見され、バージョン 2.4.6で修正したとします。 そのソフトウェアがRHELに含まれており、パッケージのバージョン 2.3.8-10 で同じ問題の影響を受けるとします。 Red Hatのエンジニアリングはupstream projectの2.4.6で行われた修正内容を反映して、2.3.8-11 のようなパッケージを作成してリリースします。このような活動を「バックポート」と呼んでいます。 結果として「foobarのこの問題は2.4.6以降なら直っている」という知識はRHELについては間違いで「2.3.8-11以降なら直っている」ということになります。とはいえ、上記の背景を知らない状態で「今のfoobarパッケージのバージョンは2.3.8-14です」という回答だけを入手してもどの問題が対応済みなのかはわかりませんし、背景を知っていれば対応状況やバージョンも同時にわかっているはずです。機能拡張についてはバージョン変更(リベース)で対応するケースが多いですが、お客様からのリクエスト等で同様にバックポートされるケースがあります。 このような知識を持たずにバージョンだけを確認して機能や脆弱性の有無を検討するのは間違いです。 機能をサポート対象外にしたり無効化するケースがある Red Hat製品では他機能との競合や、実装が成熟していない、そのコンポーネントのメンテナンスをする体制がRed Hatにないなどの理由で機能を無効化したり、サポート対象外にするケースがあります。 たとえば RHEL 8で openldap-serverはサポート対象外となっていますが、codeready-builder-for-rhel-8-x86_64-rpms というリポジトリでサポートしないパッケージとして提供されています。この場合に openldap-serverの バージョンだけ を確認してもあまり意味がありません。 おすすめの確認方法 機能や動作を確認するには評価用サブスクリプション等を利用して実際に試すのが一番です。簡単なものなら これ以上ないほど簡単に日本語でRHEL8を試すHow to で紹介したラボで確認することもできます。 特定のパッケージについてサポート有無を確認したい場合には、RHEL 8の場合はリポジトリを確認します。BaseOSまたはAppStreamに含まれていればサポート対象で、他のリポジトリはサポート対象外です。 脆弱性の影響有無を確認したい場合には、バージョン番号の確認ではなく、 Red Hat CVEデータベース で確認できます。

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。 毎月何か書くのを目標にしているのですが、1月は残念ながら書けませんでした。きょうは2月1日ですが、1月32日ということにしてください。 今回は Ansible Tower についての問い合わせでよくいただくものについて軽く触れてみようと思います。 Engine からの移行 コマンドラインから ansible-playbook コマンドを利用して動いていたものを Ansible Tower に載せて動かそうとしたときに、必要なディレクトリを参照してくれないという問い合わせをよくいただきます。 プレイブックやその必要なファイルを含む「プロジェクト」としてのディレクトリが Ansible Tower 上に配置されますが、そのプロジェクトディレクトリにあるものを利用した処理によって Tower のインスタンスが壊されることがないよう、標準設定では「ジョブの分離」の機能が有効化されています。 docs.ansible.com docs.ansible.com 安全のため、このジョブの分離の機能は有効のままでお使いいただくことをお勧めします。必要に応じて「分離されたジョブに公開するパス」を設定していくのがいいと思います。 Web UI が更新されない 特にクラスタ構成にしている場合、ジョブを実行しても画面が更新されずにずっと実行中になっていてブラウザをリロードすると終わっている、というようなことがあります。 Web UI の更新は WebSocket の仕組みで動作しています。ロードバランサーがあって SSL/TLS を終端している場合、Tower 側では 80/tcp だけで受けるように設定して構成します。このとき、インスタンス間の WebSocket のための追加の設定がされていない場合、通信が失敗して画面の更新がされないことがあります。 docs.ansible.com 上記のドキュメントにある「プロキシーのサポート」についての設定も必要な場合があります。 WebSocket の設定は、Tower のインスタンス上ではこちらのコマンドで確認することもできます。 接続できない場合 # awx-manage run_wsbroadcast --status Broadcast websocket connection status from "host01" to: hostname state start time duration (sec) host02 disconnected N/A N/A host03 disconnected N/A N/A Broadcast websocket connection stats from "host01" to: hostname total per minute host02 0 0 host03 0 0 接続できるよう設定した場合 # awx-manage run_wsbroadcast --status Broadcast websocket connection status from "host01" to: hostname state start time duration (sec) host02 connected 2021-02-01 02:41:35.337909 230 host03 connected 2021-02-01 02:41:35.257562 230 Broadcast websocket connection stats from "host01" to: hostname total per minute host02 0 0 host03 0 0 アップグレードできない Ansible Tower は比較的足の速いプロダクトで、すぐ EOL (End Of Life) を迎えてしまいます。 access.redhat.com RHEL のバージョンも 7.7 以降もしくは 8.2 以降を要求するようになったのですが、特に日本のお客様では OS を古いバージョンに固定されていることも多く、Tower が EOL になってしまうのに OS を上げられないためにバージョンアップできないという問題を抱えていらっしゃることもあります。 EOL となった古いバージョンについての問い合わせは一切お受けすることができませんので、計画的にバージョンアップしていただくようお願いしています。 特に RHEL のバージョンについては、RHEL 7 をサポートするのは現在最新版の Ansible Tower 3.8 が最後となりますのでご注意ください。RHEL 8 をお使いいただくことで Python 3 に完全に移行することができますので、積極的にご検討いただきたいです。 認証の連携ができない Ansible Tower の認証にはさまざまな外部サービスを利用することができます。ユーザに権限を適切に設定することも、弊社が提唱する「自動化2.0」の大事な要素となっています。 Azure AD GitHub Google OAuth2 LDAP RADIUS SAML TACACS+ 特に LDAP (主に Windows Active Directory) や SAML についてのお問い合わせをよくいただきます。 基本的にはドキュメントに書かれている通りではあるのですが、実際に試してみると環境や設定の問題でうまく連携しないということもよくあります。SSL/TLS 証明書を自己署名にしている場合に失敗するという事例も多いです。 事例があるたびにナレッジベースに残すようにはしています。こちらはわたしが書いたものの一例です。カスタマーポータルにアカウントがある方はご覧ください。 How Can I Authenticate Using Windows Active Directory in Ansible Tower ? How To Configure SAML Authentication with Azure AD in Ansible Tower? How Do I Use SAML Authentication With OKTA in Ansible Tower? 思うように動かないときは 構成情報や実行のログと、何が問題なのかを明確にいただけますとお手伝いしやすくなります。Ansible Tower は REST API からさまざまな情報を取得することができます。/api/v2/ping/ 以外の API については、admin ユーザでログインしてから取得してください。 Ansible Tower のインストール状況や設定 https://<TOWER_URL>/api/v2/ping/ https://<TOWER_URL>/api/v2/instances/ https://<TOWER_URL>/api/v2/config/ https://<TOWER_URL>/api/v2/settings/all/ ジョブが終わらないとき https://<TOWER_URL>/api/v2/unified_jobs/?status__in=new,pending,waiting,running プロジェクト https://<TOWER_URL>/api/v2/project_updates/N/ https://<TOWER_URL>/api/v2/project_updates/N/stdout/ インベントリーの同期 https://<TOWER_URL>/api/v2/inventory_updates/N/ https://<TOWER_URL>/api/v2/inventory_updates/N/stdout/ ジョブ https://<TOWER_URL>/api/v2/jobs/N/ https://<TOWER_URL>/api/v2/jobs/N/stdout/ その他 Ansible Tower のログ sosreport コマンドを実行して収集していただけますととても助かります。 /var/log/tower/ /var/log/supervisor/ /var/log/nginx/ などをよく調査しています。 おわりに Ansible Towerの評価ライセンスリクエストはこちらからご利用いただけますのでお試しください。 www.redhat.com Happy Automation!

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Quarkus.io のブログ記事、 Emitter - Bridging the imperative and the reactive worlds の翻訳記事です。 Kafka と Avro についての 以前のブログ記事 ( 原文 )では、エミッタ（放出するもの）を使って Kafka のメッセージを送信していました。 この記事では、このエミッタの構造をもう少し詳しく見ていきます。 エミッタの注入 エミッタの注入は簡単です。ターゲットとするチャンネルを指定します。つまりどこにメッセージを送信するかです。 @Inject @Channel( "movies" ) Emitter<Movie> emitter; リアクティブメッセージングは、主要な抽象化としてチャネルを使用することを覚えておいてください。これらは、インメモリチャネルであったり、リモートブローカにマッピングされていたりします。 先ほどのコードスニペットでは、 Emitter<Movie> を注入しています。ペイロードとして movies を含むメッセージを送信することを意味します。そのため、指定された型はペイロードの型となります。これにより、ペイロードを直接 (メッセージ内で自動的にラップして) 送ったり、ペイロードとして movie を含むより詳細なメッセージを送れます。 Movie movie = ... // ペイロードを直接送る emitter.send(movie); // メッセージを送る emitter.send(Message.of(movie)); ペイロードの送信 ペイロードを送信することは、データを送信する最もシンプルな方法です。ペイロードを Movie のインスタンスのように send メソッドに渡すだけです。これは、ペイロードをラッピングしたシンプルな Message を作成するだけです。 ペイロードと共に使用される場合、その send メソッドはメッセージの処理が成功したか失敗したかを示す CompletionStage を返します。 emitter.send(movie) .whenComplete((success, failure) -> { if (failure != null ) { System.out.println( "D'oh! " + failure.getMessage()); } else { System.out.println( "Message processed successfully" ); } }); 処理していると、後でイベントの排出を見ることになりますが、これは非同期的に発生しています。そのため、返された CompletionStage は、メッセージがいつ処理されたかを知れます。メッセージが確認されると、 CompletionStage は正常に完了します。ほとんどの場合、スムーズに処理が完了しているか、無事にブローカーにメッセージが送られていることを意味しています。何かあった場合、例外的に CompletionStage が完了します。渡された例外を見れば、その理由がわかります。 メッセージの送信 ペイロードの送信はより簡単ですが、Kafka での書き込みの設定やトレース情報などのメタデータをメッセージに添付したい場合もあるでしょう。エミッタはメッセージの送信も可能です。なので、必要なメタデータを添付します。以下の例では、アウトバウンドの Kafka レコードを設定します。キーやトピックなどを設定します。そうすれば、異なるトピックにメッセージを派遣したり、動的に決定できます。 OutgoingKafkaRecordMetadata<?> metadata = OutgoingKafkaRecordMetadata.builder() .withTopic( "movies" ) .withKey(movie.getYear()) .build(); emitter.send(Message.of(movie).addMetadata(metadata)); 放出は非同期 エミッタは、命令的な世界とリアクティブな世界の間の架け橋となります。メッセージを発した場合、このメッセージはすぐには処理されません。メッセージを使用する下流のコンポーネントは、Reactive Streams の一部です。メッセージをすぐに渡すことは、Reactive Streams プロトコルに違反します。下流のコンポーネントがこのメッセージを受け入れる準備ができていることを確認しなければなりません。その結果、エミッタはメッセージを直接プッシュするのではありません。下流のキャパシティ（Reactive Streams の専門用語でのリクエスト）を処理するために使用されるバッファにそれをエンキューしています。 下流のコンポーネントは、リクエストに応じてメッセージを受信します。そのコンポーネントはその容量を超えることがないようにします。 オーバーフロー管理 しかし、バッファは... オーバーフローします。メッセージを出しすぎて下流が追いつかない場合、それらのメッセージは最大容量に達するまでバッファに保存されます。そうすると、これ以上発せられなくなり、発しようとすると例外が発生します。しかし、この場合はどうすればいいのでしょうか？エミッタを注入する際には、オーバーフロー戦略を設定できます。例えば、バッファサイズを設定したり、制限されないバッファを使用したり、メッセージを捨てたり、失敗したり、バックプレッシャーを無視して下流に任せたりなどできます。デフォルトではバッファを使用します。ですが、ユースケースによっては異なる設定が必要になるかもしれません。 @Inject @Channel( "movies" ) @OnOverflow(value = OnOverflow.Strategy.BUFFER, bufferSize = 1000) Emitter<Movie> emitter1; @Inject @Channel( "movies" ) @OnOverflow(value = OnOverflow.Strategy.NONE) Emitter<Movie> emitter2; @Inject @Channel( "movies" ) @OnOverflow(value = OnOverflow.Strategy.UNBOUNDED_BUFFER) Emitter<Movie> emitter3; 結論 この記事では、Reactive Messaging の Emitter の構成について簡単に紹介します。詳細については、 SmallRye Reactive Messaging のドキュメント を参照してください。 次の Quarkus バージョン（1.9）では、この機能は2つの非常に優れた機能強化によって改善されます。まずはじめに、それは Mutiny API との統合を容易にする Mutiny とわずかに異なる物を提供します。そうすれば、Kafka の場合はメタデータを使わずに直接キーと値のペアを出力できるようになります。 ご期待ください！これらをフォローアップ記事でカバーします！

Red Hatのソリューションアーキテクトの井上たかひろです。 Red Hat にはクラウドネイティブアプリの開発に役立つ、Application Services のラインナップが充実していることをご存知ですか？ ここでは、Red Hatの Application Services に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2021/2月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: イケてるシングルサインオン Keycloakベースの Red Hat Single Sign-on Red Hat Single Sign-on(RH-SSO)は、オープンソースのKeycloakの商用版になります。 シングルサインオン、API認可、外部IdP連携などが実現できます。Red HatのカスタマーポータルなどもRH-SSOで構築しています。 今回は、RH-SSOの概要や構成について紹介します。 speakerdeck.com 特集2: アプリケーション開発を更に効率化するAPI管理基盤をマネージドサービスで提供開始！ Red Hatではコンテナ基盤であるOpenShiftを既にマネージドサービス（OpenShift Dedicated）として提供していましたが、そのアドオンとして3scaleのAPI管理機能がRed Hat OpenShift API Management (RHOAM)として追加されました。更にシングルサインオン製品であるRed Hat Single Sign-on(RH-SSO)も含まれているため、OpenShift上で開発したAPIをすぐに管理し、セキュアに公開することが可能になります。 今回はそのRed Hat OpenShift API Management (RHOAM)について紹介します。 speakerdeck.com 特集3: 今からでも遅くない！Afterコロナから始める業務改革（BPR）の進め方のポイント 昨年は新型コロナウイルス（COVID-19）の流行により、今までの“当たり前”に大きな変化が訪れ、Withコロナ、Afterコロナを意識した働き方の改革の必要性を認識した年になりました。 今回は、業務改革（BPR）を進め方のポイントについて紹介します。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat build of Eclipse Vert.x 4.0 Red Hat JBoss Enterprise Application Platform expansion pack 2.0 (EAP XP)

ふたたび、Red Hat Tech Night 2021.01 運営チームからの記事です。ハイライトに続きまして、今回のRed Hat Tech Nightオンラインを支えた配信チームの話をご紹介します。 Red Hat Tech Night 2020.01のハイライトは以下の記事をご覧ください。 rheb.hatenablog.com 一番の功労賞!! 配信チームが教えてくれた裏話 配信を担当した八木澤（ひよこ大佐）です。今回のRed Hat Tech Nightは、配信を含め、すべての企画運営がボランティアチームの手で行われました。したがって、配信も、ロゴの準備やイベント会社などではなく社員の手によってすべて実施したものです。配信にあたって、運営メンバーで打ち合わせやチャットでのコミュニケーションを重ねながら、「どのようなイベントにしていくか」を含めてイチから詳細を詰めていきました。 RHTNは前回(2019年)も開催していますが、当時はRed Hat Forumの開催後に行われるオフラインのイベントでした。そのため、完全にオンラインのみとなる今回のRHTNでは、従来とは全く異なるアプローチが必要でした。 配信をするためには、当日までに必要なタスクが大量にあります。私が実際に担当したのは、以下のような作業です。 ロゴの作成 配信画面の背景画像の作成 配信用のチャンネルの設定 配信用の音源の確保 当日の配信作業 Tech Nightのロゴや背景画像は、ITエンジニアらしいサーバーラックの画像でインダストリアルな雰囲気を漂わせつつ、配信画面の邪魔をしないように暗めのモノトーンで統一しました。不思議なものでロゴなどができあがると「本当にイベントをやるんだ」という実感が湧いてくるのを実感しました。 当日のイベントでは前座のクッキングにはじまりパネルディスカッション、LTとタイプの異なるセッションが複数存在します。コアメンバーや出演者の意見や要望をヒアリングしながら、オンライン会議ツールであるGoogle Meetの制約を考慮しつつ配信の演出などを決定していきました。 今回の配信において一番難しかったのが、この「様々な要望や意見をなるべく取り入れながら、制約を加味して実際の配信に落とし込んでいく」というプロセスです。もちろんすべてを取り入れていきたいのですが、実際のリソースには限りがあるのですべてをやろうとすると途端にリソース不足になってしまいます。 イベントの配信において重要なのは「視聴者が見やすく、楽しめる」配信になることです。いくら凝った演出をいくつも用意しても、それが邪魔になるようでは本末転倒です。配信前やセッションの合間、配信終了などシーンが切り替わる場面もあるため、リハーサルを行いつつよりよい配信になるよう検討を重ねました。 当日は「配信担当者自身がLTに登壇する」というハードな状況でしたが、なんとか大きな配信上の不具合もなく安定して視聴者の皆様にお届けすることが出来ました。これもコアメンバーの協力や登壇される方々のスムーズな切り替えの賜物です。 実際の配信風景 もちろんすべてがうまくいったわけではなく、改善すべき点もたくさんありました。今後のイベントではその反省を活かしながらより皆様が楽しめる、見やすい配信にしていければと思います。 以上を踏まえて、再度RHTNが見たくなった方はこちらをご覧ください！ https://www.youtube.com/watch?v=mxyQEm0idB4&feature=youtu.be

はじめに Red Hatのもえわきです。Red Hat Tech Night 2021.01運営チームを代表して、先週1月14日に行われましたRed Hat Tech Nightのハイライトをお伝えします。 Red Hat Tech Nightとは 概要 Red Hat Forum 2018と合わせて、レッドハット日本法人のエンジニアの発案から、オープンソースの技術をより多くの人に広める活動としてはじまったこの勉強会、今回4回目の開催となりました。 2018年の開催に至った背景や経緯は、以下のブログ記事をご確認ください。 rheb.hatenablog.com 私も聴衆者として参加した2019年では、250名以上の方が現地参加されました。私はエンジニアではないため、話している内容の細かいところまでは理解できないのですが、そこは発表者の腕の見せどころ!! 分からないなりにも分かった気になれる(!!)素晴らしい構成になっており、熱量も相まって非常に楽しい時間を過ごすことができました。 2019年では、2018年のRed Hat Tech Nightがキッカケで入社した社員や、普段このようなイベントに参加されることのない社長も登壇し(いじられ)、大変盛り上がりました。以下のブログ記事でもその熱量を感じることができます。ぜひご確認ください。 rheb.hatenablog.com 目次 はじめに Red Hat Tech Nightとは 概要 Red Hat Tech Night 2021.01レポート ハイライト1: オンラインであることを最大限活用した前座...？ ハイライト2: 今年も社長をいじることができた!? ハイライト3: 今年もバラエティに富んだパネルディスカッションとライトニングトーク 箸休め的な「パネルディスカッション」 これぞ真骨頂「ライトニングトーク」 さいごに 資料 Red Hat Tech Night 2021.01レポート 今回は、オンライン開催ということもあり、これまでの「聴講者を置いてきぼりにする新感覚ミートアップ」「Red Hatの珍獣を眺める会」という特色は残しつつ、会場を包む熱量を得られない可能性も考慮して、「ゴリゴリ技術枠」と「ちょっとお楽しみ枠」を組み合わせた新しい雰囲気となっています。 ハイライト1: オンラインであることを最大限活用した前座...？ 「ちょっとお楽しみ枠」として用意された前座は「ちょっと」をはるかに超えてきた内容となりました。普段は会場で食べ物や飲み物が提供されるのが今回オンラインになってできなくなったため、その代わりとして、本番前になんと料理のライブハンズオンが開かれました。Connpassであらかじめ材料を公開し、オンライン参加のRed Hat社員と一緒に今夜のおつまみを作って、本番開始までの時を過ごしたのです。もちろん、視聴者の皆様が参加されている姿は確認できないのですが、Twitter上では画像があがったりと盛り上がりを見せていました。 今回ご紹介させたいただいたメニューです。 レシピは以下をご覧ください。 speakerdeck.com ハイライト2: 今年も社長をいじることができた!? 2019年のハイライトの一つとして紹介されていた「社長いじり」。今回はオンラインなのでさすがに難しいかと思っていましたが、そこはあきらめが悪い私たち。乾杯の挨拶をする「新人」として登場してもらうことになりました。 そして、Twitterでは、そんな新人の挨拶にも「オンラインの音声のノイズ等、まだまだ向上の余地があるので立派なYouTuberとして育って欲しい」と社員からの厳しい意見(笑)や「本物の大型新人！」など盛り上がりをみせていました。ナイスアシストです。ただ、社長も、あらかじめ用意しておいた2種類の紹介スライドの中で、カジュアルな写真(上)の方をその場で自ら選ばれるあたり、いい意味でのRed Hatの洗礼を受けてもらえたのではないでしょうか...? ハイライト3: 今年もバラエティに富んだパネルディスカッションとライトニングトーク ライトニングトークとパネルディスカッションでは、「ゴリゴリ技術枠」だけでなく、在宅勤務での体験談や、Open Cultureの話など、バラエティに富んだラインアップとなりました。 箸休め的な「パネルディスカッション」 メインのセッションの１つ、パネルディスカッションでは、ゴリゴリなライトニングトークの「箸休め」的な部分を担いつつも、Red Hatのユニークな文化がみえるディスカッションが行われました。 タイトル: あまりにも Open すぎてビビる Red Hat の Culture テーマ1: Red Hat の Open Culture についてビビったこと (入社歴3年未満の方々の体験談) テーマ2: 組織の風通しの良し悪しや働き方の多様性について (入社歴5年以上の方々の体験談) 個人的に大好きなテーマです。とくに前半。Red Hatの社員であれば誰でも何かしら逸話をもっていて、それを集めただけでもエピソード本が書けてしまいます。今回は、時期的にホットトピックであるコロナ禍での会社の対応と、プライベートと仕事の両立について話してもらいました。管理職間の話がひそひそ話にならずオープンであるところが、皆様にとって一番の驚きポイントになった様子でした。 後半は、男性社員が取得した育休の体験談と、ボトムアップでチームが変わった経緯の紹介となりました。どちらの話も、社員の要望や意見に柔軟に対応できるRed Hatだからこそ実現できたのかもしれません。蛇足ですが、このような話はなかなか聞ける機会もないので、この発表後、社内でももう少し聞きたかったという声があがりました。 これぞ真骨頂「ライトニングトーク」 Red Hat Tech Nightの真骨頂であるライトニングトークは、「ゴリゴリ技術枠」の部分を担いました。ただ、話している内容はゴリゴリしているのに、なぜか生活家電の話が出てきたり、復讐の日というセンセーショナルなタイトルで将棋盤が出てきたり、愛社精神満載のコスチュームで登場したり、配信しながら配信の話をしたり、出だしの川柳で引き付けたりするところは、いつものように私のような非エンジニアの人にも優しい、魅力的なコンテンツとなりました。 皆さんすばらしい内容でどれか一つ選んで紹介できるものではないのですが、あえてあげます。今回唯一の技術部門以外からの登壇です。 タイトル: バックオフィス社員がRHLS受けてみた 内容: RHEL管理者初心者コースRH124を1ヶ月受けてみてどうなるか体験記 発表者: 和泉陽平 Red Hat 認定トレーニングは以下のページをご参照ください。 www.redhat.com 和泉さんが挑戦されたコースです。 www.redhat.com Red Hat社員は誰でも、お客様がご利用になれるオンライントレーニングコースを受けることができます。主な対象は技術職なのですが、中には和泉さんのように、非技術職でありながら挑戦される強者もおります。技術的な話や技術者視点を理解できただけでなく「シンプルに楽しかった」と和泉さんは話していましたが、このRed Hat Tech Nightやコミュニティ活動もそうなのですが、エンジニアでなくても飛び込んでみると、案外、想像以上に楽しい体験ができるものだなと私も日々痛感しています。Red Hatには、部門間の垣根すら超えていくパワーがありますが、それは単にオープンな雰囲気で風通しが良いだけでなく、このような各自のちょっとした努力の積み重ねも、互いに理解して尊重する力の源になっているのだと思います。 今回、ご視聴いただいた皆様、視聴はしなかったけどここをご覧になっている皆様、和泉さんがお勧めしたように、何かの機会にはぜひ周りにいる非エンジニアの方もお誘いください。 さいごに 色々なものを手探りで進めてきた今回のオンラインイベント、皆様はどのような印象をもたれたのでしょうか。前回に引き続き、今回も「置いてきぼり感」「Red Hatの珍獣達」という特色は残しつつも、いつもの熱い雰囲気とは違って、肩の力を抜いて楽しんでいただけたのであれば幸いです。 イベント終了後、Twitterの投稿から、以下のページができていました。視聴するかどうか迷われている方がいらしたら、ぜひ参考にしてください(個人的にはデカデカと書かれている「生活家電」がツボです)。 AI分析サービス - Bubbly AI 次回の開催はいつになるのか(秋ぐらいにって話もありましたね!!)、オンラインなのか会場に集まれるようになるのかは分かりませんが、これからも最新技術とともに、さまざまな情報を伝えられる場を設けていきたいと思います。 最後になりましたが、ライトニングトークやパネルディスカッションに登壇いただいた皆さん、運営チームを支えてくださったすべての方、Twitterで会を盛り上げてくださったすべての方、そしてご視聴いただいたすべての方に感謝を申し上げます。 資料 今回配信されたYoutubeは、一定期間(2021/07/14までを予定)視聴することができます。 https://www.youtube.com/watch?v=mxyQEm0idB4&feature=youtu.be ライトニングトークで使用されたスライド ossbyredhat.connpass.com Twitterまとめ togetter.com

レッドハットのソリューションアーキテクトの森です。 今回は、業務改革（BPR）の進め方のポイントについてのお話です。 昨年は新型コロナウイルス（COVID-19）の流行により、今までの“当たり前”に大きな変化が訪れ、Withコロナ、Afterコロナを意識した働き方の改革の必要性を認識した年になりました。 日本においては、政府は2021年9月のデジタル庁の設立に先立ち、昨年12月に閣議決定をした「デジタル・ガバメント実行計画」の中でも、業務改革（BPR）の徹底を行うとの方針を打ち出しています。また、民間企業の間でもこれまで以上にDX化が推進していくと考えられます。 業務改革（BPR）とは？ BPR（Business Process Re-engineering）は、そのまま日本語に直訳すると、「業務プロセスの再設計」となります。 つまり、業務プロセス全体とプロセスに関連する業務を見渡しながら、生産性やQCD（Quallity,Cost,Delivery）を低下させている課題と向き合い、 抜本的な改革を目指す取り組みを意味します。 このBPRが大々的に取り上げられて、多くの企業で導入が図られることになったことの背景には、 1990年代前半に、マイケル・ハマー＆ジェームス・チャンピーの共著として発表された『リエンジニアリング革命』の存在があります。 これが発端となり、その後世界的に普及をしていきました。 同書によると、 BPRの定義とは、『コスト、品質、サービス、スピードのような、重大で現代的なパフォーマンス基準を劇的に改善するために、ビジネス･プロセスを根本的に考え直し、抜本的にそれをデザインし直すこと』とあります。 上記の定義には、４つのキーワードが含まれています。 根本的 抜本的 劇的 プロセス BPRを成功へと導くためには、この４つのキーワードを含めた上での業務の改革が必須です。 根本的 流されて仕事をしているうちは、目標を達成することはできません。 現在行っている業務はなぜ必要なのか、その業務を何の目的で実施しているのか、このような組織にはどういった意味があるのか、 と言うように根本から問いかけて見て、ひとつずつ見直しを行います。 抜本的 陳腐化・形骸化した業務は思い切って切り捨てていきましょう。 慣習だけで進めてきた業務などがあれば、それを切り捨て改善していくことが必要です。 昔から決まっていることだから、慣れていて仕事がしやすいから、という理由で判断をするのではなく、客観的な視点を持って検討を行うことが重要です。 劇的 「劇的」とは、大きな改善をすることです。 少しだけの改善や部分的な改善では、大きな成果を得られません。 変革をするのであれば、大胆にできる限りの変化を成し遂げましょう。 プロセス 顧客に対して価値のあるアウトプットを生み出すための業務へと変革させていくことです。 業務改革（BPR）を進めていく上でのポイント 働き方改革、生産性向上、コスト削減の取組みの一環として、業務改革（BPR）と、業務プロセスの再設計に取り組む企業は増えています。 一方で、取り組んだものの思ったような成果が出なかったと悩む企業も多いのではないでしょうか。 では、業務改革（BPR）を成功させるためには、どのように進めて行けば良いのか、いくつかの注意すべきポイントについて紹介していきます。 スモールスタートから徐々に拡大していく 組織全体に大きな影響を及ぼす業務プロセスの再設計ですが、必ずしも最初から全社的に取り組む必要はありません。 むしろ全社一気に取り組むリスクを考慮して、スモールスタートで開始するのがセオリーです。 最初は小さい範囲で業務プロセスを見直し、小さな成功を積み重ねながらノウハウを得ていきます。 そこから他の業務領域へ拡大していきましょう。 適用する業務プロセスは慎重に選ぶ 何事も「最初が肝心」とは言いますが、業務プロセスや問題点の優先度や改革難易度を実施した上で、目安として60日～90日程度で改革が可能な業務プロセスを選びましょう。 目的（ゴール）を明確にして、そこから必要な業務を逆算 いきなり業務プロセスのモデル化から始めてしまうと、既存業務の踏襲となってしまいがちです。 何を達成する必要があるのかを考えて、そこから必要な業務とは何か、を洗い出してみましょう。 業務の目的（ゴール）をまず設定した上で、逆算的にマイルストンを設定してから必要な業務プロセスのみをモデル化し、設計をしていきましょう。 PDCAサイクルを取り入れる 一度の業務改革で終わらせるのではなく、PDCAサイクルを取り入れて継続的に実施することも大切です。 業務改革は1日にして成るものではありません。そのため何度もPDCAサイクルを繰り返して最終的な改革を達成するよう計画します。 継続は何よりも大切なので、必ず押さえておきたいポイントです。 成功と失敗の要因を必ず分析する 業務改革では成功することもあれば、失敗することもあります。 その際に大切なのは「なぜ成功したのか？」「なぜ失敗したのか？」を考えることです。 正しく要因の分析を行うことで、合理的かつ効率的な業務改革を継続していくことができます。 業務プロセスの再設計を効率良く進めるためには？ 業務改革（BPR）における業務プロセス再設計は簡単ではありません。 業務プロセスをモデル化した後に定量的・定性的分析を行い、問題点を洗い出した上で効果的な対策と設計していく必要があります。 初めて業務改革（BPR）に取り組む企業にとって、これは大きな負担です。 かといって、業務改善コンサルタントに依頼をするのはコストがかかります。 そこで、業務プロセスの再設計を効率よく実現するためのツールとして、ビジネスプロセス管理システム（BPMS）の導入をする方法があります。 レッドハットでは、オープンソースソフトウェアとして、Red Hat Process Automation Manager（以下RHPAM） という製品を提供しています。 RHPAMには、以下のような機能が備わっています。 モデリング機能 モニタリング機能 プロセス分析機能 ビジネスルール機能 ケースマネジメント機能 「モデリング機能」とは、BPMN(ビジネスプロセスモデリング表記)という規格に準拠して、業務プロセスのモデル化を行います。 GUIベースでグラフィカルに作成できるため、モデリングに関する深い知識がなくとも作成できるため、部門間をまたいだ共通言語として活用することができます。 モデリング機能 「モニタリング機能」は、展開した業務プロセス設計が正常に機能しているかを監視します。 業務プロセスの進捗状況をリアルタイムで確認することができるので、トラブル発生を事前に察知したり、問題のあるプロセスを迅速に抽出することができます。 モニタリング機能 「プロセス分析機能」は、業務プロセスを分析し、特定の業務に時間がかかっている、特定の人間へのタスクが偏っている、等のボトルネックを洗い出すことができます。 プロセス分析機能 「ビジネスルール機能」は、業務プロセスの中で人間が行っていた判断を、システムに落とし込んで自動化することができます。 またルールの内容については、意思決定表（デシジョンテーブル）の形式で記述をすることで可視化を行い、現状の業務の内容をオープンにすることができます。 ビジネスルール機能 また企業活動においては、定型的に発生する業務プロセスと、クレーム対応や受注生産などの、非定型処理の業務プロセスも数多く存在します。 「ケースマネジメント機能」では、例えばタスクの処理が順不同であるような、非定型処理の業務プロセスをパターン化し、管理することができます。 ケースマネジメント機能 試してみる RHPAMについて試してみたい、触ってみたいという方のために、ローカルPCへのインストールの手順や、サンプルを動かしてみる際のポイントについて、 以下のブログでご紹介してあります。 参考にしてみてください。 qiita.com qiita.com qiita.com いかがでしょうか？業務改革（BPR）を実行するにあたり、適切なITソリューションを導入することで、業務プロセスを可視化したり、改革案のモニタリングを行うことで導入の効果を測定することができます。 製品の提供と共に、それを業務改革（BPR）に対してどのようにして使えば良いのか、と言ったノウハウについても提供しておりますので、 内容についてご興味のある方は是非、弊社営業までご連絡を頂ければと思います。