Red HatでOpenShiftのサポートをしている id:nekop です。 OpenShift 4.5ではAWSのSpot Instanceを利用することが可能になっているので、普段テストなどに使っているAWSのクラスタにSpot Instanceを適用してコスト削減してみました。テスト目的のクラスタなので、サービスを提供しているものではなく、営業時間内しか利用しません。Spot Instanceは意図しないタイミングで中断されるインスタンスですが、このテスト目的ユースケースでは中断されても特に大きな影響はない、という前提です。 docs.openshift.com 会社では基本的にTokyo (ap-northeast-1)リージョンでm5.xlarge (4vCPU 16GB mem)を利用していますが、インスタンスコストが$0.25 per hourで、3 masters 3 workers構成で営業時間(8時間仮定)のみの起動でインスタンスコストの合計は $0.25 * 8 hours * 20 days * 6 hosts == $240.0 というお値段となります。インスタンスコスト以外にELB, NAT gateway, EBSが一日$7程度課金されるので、営業時間外はインスタンスを停止する運用でも、合計一ヶ月$440程度になります。まったく停止しないでフル稼働の場合は$1080です。 利用するSpot Instanceについて 料金履歴 , 料金表 , スポットインスタンスアドバイザー などを事前に確認しましょう。m5.xlargeのSpot料金履歴を見ると$0.07程度なので、以下の例では maxPrice: 0.08 で設定します。Frequency of interruptionは10-15%となっています。WorkerホストをSpot Instanceにスイッチすると $0.08 * 8 hours * 20 days * 3 hosts == $38.4 ということで元々$120だったインスタンスコストが$40に圧縮できます。$80の節約ですね。MasterホストはSpot Instanceにできないので引き続き$120かかります。営業時間のみインスタンス起動で一ヶ月合計は$360です。 Spot Instanceを設定していきましょう。クラスタを作成後、MachineSetにSpot Instance設定を反映して oc delete machine で既存のOn-Demandで作成されたWorkerをSpot Instance設定でリビルドしていきます。 for ms in $(oc -n openshift-machine-api get machineset -o name); do oc -n openshift-machine-api patch $ms --type json -p '[{"op":"add","path":"/spec/template/spec/providerSpec/value/spotMarketOptions","value":{"maxPrice":"0.08"}}]' done oc create -f - <<EOF apiVersion: machine.openshift.io/v1beta1 kind: MachineHealthCheck metadata: name: worker namespace: openshift-machine-api spec: selector: matchLabels: machine.openshift.io/cluster-api-machine-role: worker machine.openshift.io/cluster-api-machine-type: worker unhealthyConditions: - type: "Ready" timeout: "360s" status: "False" - type: "Ready" timeout: "360s" status: "Unknown" maxUnhealthy: "100%" EOF oc -n openshift-machine-api get machine oc -n openshift-machine-api delete machine MACHINE # ひとつずつリビルド Spot Instanceはone-shotタイプでstopはできず、終了させるにはterminateする必要があるので、停止手順はMasterホストのstopとSpot InstanceのWorkerホストのterminateとなります。MachineHealthCheckを入れておくことで、クラスタを再開するとき、MasterをstartしてMachineConfigOperatorが正常に動作した時点でWorkerホストの自動修復がトリガーされてクラスタが正常な状態となります。Workerを新規作成するので開始に5分程度かかります。 クラスタを毎回再インストールしたほうがAWSコストは安くなりますが、クラスタを再インストールすると40分程度かかる、40分ほど使えないけど課金される時間が発生する、毎回必要な初期化や追加オペレータのインストールの手間がかかる、毎日決まった時間に絶対使うというわけでもないので無駄な課金を避けようとすると自動クラスタ作成などの自動化も仕込みづらい、すぐに必要というときに40分も待てないケースがある、といった事情を考えると、クラスタを毎回再インストールするというのも様々なオーバーヘッドがあります。端的に言うとだるい。とてもだるい。停止していても一日$7かかりますが、人間がクラスタ再作成にかかわるだるい作業を行うというコストは$20くらいはありそうなので、使用頻度が高い場合はクラスタ再作成はしないほうがオトクです。 最後にAWS cliを利用した起動停止スクリプトを添付しておきます。 #!/bin/bash # Example: ocp-aws start cluster-blue # # This script needs aws cli: # $ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" # $ unzip awscliv2.zip # $ ./aws/install -i ~/.local/aws-cli -b ~/.local/bin # # You can put this script under ~/.local/bin along with aws command. # # To enable automated shutdown using cron: # $ crontab -e # 0 19 * * * $HOME/.local/bin/ocp-aws stop cluster-blue # OPERATION=$1 CLUSTER_PREFIX=$2 if [ "$CLUSTER_PREFIX" == "" ]; then echo "Usage: ocp-aws COMMAND PREFIX" echo "COMMAND: start, stop" exit 1 fi AWS_COMMAND=$HOME/.local/bin/aws REGION=ap-northeast-1 case "$OPERATION" in "start") $AWS_COMMAND ec2 start-instances --region ${REGION} --instance-ids $($AWS_COMMAND ec2 describe-instances --filters "Name=tag:Name,Values=${CLUSTER_PREFIX}-*" "Name=instance-state-name,Values=stopped" --query "Reservations[*].Instances[*].InstanceId" --region ${REGION} --output text) ;; "stop") # Terminate spot instances then stop ondemand instances $AWS_COMMAND ec2 terminate-instances --region ${REGION} --instance-ids $($AWS_COMMAND ec2 describe-instances --filters "Name=tag:Name,Values=${CLUSTER_PREFIX}-*" "Name=instance-state-name,Values=running" "Name=instance-lifecycle,Values=spot" --query "Reservations[*].Instances[*].InstanceId" --region ${REGION} --output text) $AWS_COMMAND ec2 stop-instances --region ${REGION} --instance-ids $($AWS_COMMAND ec2 describe-instances --filters "Name=tag:Name,Values=${CLUSTER_PREFIX}-*" "Name=instance-state-name,Values=running" --query "Reservations[*].Instances[*].InstanceId" --region ${REGION} --output text) ;; *) echo "Unknown operation" ;; esac

Red HatでOpenShiftのサポートをしている id:nekop です。 Kubernetes/OpenShiftではEventログはデフォルト1時間から3時間といったTTL設定となっています。Podログをログ基盤へ集約する設定を行っていても、Eventログはetcd内に格納されているリソースであり、Podログではないので、別途対応しないとログ基盤への集約ができません。 良く利用されるものに Eventrouter がありますが、これは一つのnamespaceのPodログとして全てのnamespaceのEventログを出力する、という簡易的なものであり、クラスタ管理権限がなかったりマルチテナント環境などの権限管理がしっかりしているクラスタでは利用できず、複数namespaceのEventログがひとまとめになってしまっているのでログの参照権限も問題となります。 そこで、namespace内でEventログをPodログとして出力するPodをデプロイすることで、namespace内の権限に閉じたEventrouter相当の機能を実装してみましょう。 ocコマンドを利用できるose-cliというイメージが用意されているので、それを利用します。PodのocコマンドがAPIアクセスできるようにServiceAcccountを用意してプロジェクト内リソース参照権限 view を与え、Podでは oc get event -w を無限ループで実行すればできそうですね。名前はeventlogdumperという名前にしています。 oc new-project ... oc create deployment eventlogdumper --image registry.redhat.io/openshift4/ose-cli oc scale deployment eventlogdumper --replicas=0 oc create sa eventlogdumper oc policy add-role-to-user view -z eventlogdumper oc patch deployment eventlogdumper -p 'spec: template: spec: serviceAccountName: eventlogdumper containers: - name: ose-cli command: - /bin/bash - -c - | #!/bin/bash while true; do oc get event -w -o custom-columns="LAST SEEN:{lastTimestamp},FIRST SEEN:{firstTimestamp},COUNT:{count},NAME:{metadata.name},KIND:{involvedObject.kind},SUBOBJECT:{involvedObject.fieldPath},TYPE:{type},REASON:{reason},SOURCE:{source.component},MESSAGE:{message}" done' oc scale deployment eventlogdumper --replicas=1 oc logs deployment/eventlogdumper を実行すると、 oc get event 出力がPodログとして出力されていることがわかります。このPodをデプロイすることで、namespace内のPodログとしてEventログをOpenShift EFKなどのログ基盤から参照することができるようになります。この実装も簡易的なものであり、エラーハンドリングなども行っていません。それほど問題になるシナリオは無いと思いますが、たとえばPod再作成時にTTL範囲内のEventログが再読み込みされるため、ログ出力の重複などは発生します。 ocコマンドはPodに割り当てられたServiceAccountを自動で利用するようになっているので、APIアクセスのために別途設定ファイルやtokenを明示的に指定する必要はなく、ストレートにocコマンドを発行することができます。

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Quarkus.io のブログ記事、 Free Quarkus Sessions at Quarkus Day by Red Hat の翻訳記事です。 火曜日＆水曜日 - 9月 9日 & 10日 - 16:45 日本標準時（9:45 中央ヨーロッパ夏時間） Quarkus Day by Red Hat は、クラウドネイティブ開発の未来の一部になりたいと考えている開発者や開発者チームに特化した2日間のイベントです。イベントでは、Quarkus コミュニティのエンジニアやコミュニティメンバーに会い、Quarkus に関するあらゆることを学ぶことができます。OpenJDK HotSpot と GraalVM 用に調整された Kubernetes ネイティブ Java スタックは、最高の Java ライブラリと標準規格から作られています。参加した後は、Quarkus を使ってコーディングを始める準備ができています！ 1日目 1日目は、Quarkus のテクノロジーについてのすべての内容で、リアクティブシステム、Quarkus アプリのセキュリティ、スケーラビリティとパフォーマンス、ネイティブコンパイルなどの開発トピックに焦点を当てています。開発者の喜びに興味がある方も、サービスの安全性を確保したい方も、Red Hat とパートナーエコシステムの専門家にお会いして、新しい Java フレームワークを使って実現できる魔法についてお話していただきます。 1日目のハイライトは以下の通りです。 16:45 日本標準時 （9:45 中央ヨーロッパ夏時間） 開会の挨拶と基調講演：クラウドネイティブ開発の未来は Quarkus と呼ばれる 17:30 日本標準時 （10:30 中央ヨーロッパ夏時間） モノリスから開発者の喜びとパフォーマンスを伴うマイクロサービスへ 20:00 日本標準時 （13:00 中央ヨーロッパ夏時間） 分散開発とネイティブイメージ：Quarkus、なぜ、どのように？ 2日目 2日目は、Quarkus によって開発者や開発チームがどのようにビルドするのか、また Quarkus を使用して高度に最適化されたアプリケーションをデプロイできるようになったかに焦点を当てて話を完結させます。ノード上のアプリケーションのパッケージングを最適化するにはどうすればよいですか？どうすれば開発者に喜びを還元できるのか？ソフトウェア開発プロセスにおける摩擦を減らすにはどうすればいいのか。Quarkus と Kubernetes を使用することで、一般的なコンテナオーケストレーションシステムの多くの摩擦を取り除きながら、アプリケーションとインフラストラクチャの近代化を実現できる理由について、すべてをご紹介します。 2日目のハイライトは以下の通りです。 17:20 日本標準時 （10:20 中央ヨーロッパ夏時間） マイクロサービスとコンテナは何が変わるのか、どのように採用するのか？ 20:00 日本標準時 （13:00 中央ヨーロッパ夏時間） Red Hat で課題を管理する この無料イベントのセッションやスピーカーの詳細については、 Quarkus Dayイベントページをチェックして、参加登録を行って ください。皆様のご参加をお待ちしております！

Red Hat Insights でのSAPシステム向けルール レッドハット　ソリューションアーキテクト石倉です。 今回は、Red Hat Enterprise Linux for SAP Solutions(RHEL for SAP)での、 Red Hat InsightsのSAPシステム向けAdd-On に関して紹介します。 Red Hat Insights はRed Hat Enterprise Linux(RHEL) 環境のセキュリティ、コンプライアンス、および構成のリスクを事前に特定して修復する、Saasのサービスを提供します。 Red Hat Insightsの概要については、以下のブログも合わせてご確認下さい。 ＃なお、Red Hat Insightsは現在全てのRHELに含まれており、追加費用無しで利用する事が可能です。 Red Hat Insightsで問題が顕在化する前に対処する - 赤帽エンジニアブログ Red Hat Insightsには、既にSAP NotesをはじめとするSAPシステム固有のナレッジ情報も取り込まれており、Red Hat Insightsを利用する事で、SAP Notesなどで指摘されている対処がシステムに適用されているかどうかも確認する事が可能です。 具体的にどのようなルールが適用されているのか、例として、以下のブログに記載があります。 How to gain deeper insights into your SAP landscape running on RHEL, with Red Hat Insights 通常のRed Hat Insightsのルール同様、SAPシステム固有のルールも、Red Hat Insightsで自動生成されるAnsible Playbookを利用する事で、修復が可能です。 実際にRed Hat Insightsで発見したSAPシステムのシステムリスクをAnsibleでどう解消出来るかのサンプルデモは以下になります。 https://www.facebook.com/watch/?v=380723232590000 概要に戻る Red Hat Enterprise Linux for SAP Solutions ー概要ー - 赤帽エンジニアブログ レッドハット　ソリューションアーキテクト石倉

皆様こんにちは、Red Hat ソリューションアーキテクトの岡野です。 私、ベースがインフラエンジニアでして、これまで Ansible のブログを沢山書いてきましたが、今回、ちょっと浮気して、OpenShift の注目の新機能、Advanced Cluster Management for Kubernetes (ACM)について書いてみたいと思います。というのも、これ凄く面白いんです。しかも、『インフラ視点』で。 クラウド環境への OpenShift のデプロイが超簡単。それをお伝えしたくて。インフラ管理者が喜ぶ機能だと思います。♬ ※今回の Blog は OpenShift 4.5 及び、ACM 2.0 を前提としています。他のバージョンでは設定方法やUIが異なる可能性がありますのであらかじめご了承ください。また、環境構築方法も示していますが、とりあえず動くことを目指しており、本番環境で使うことは想定しておりません。基本的に、『面白いのでちょっと試してみる』という観点で書いています。その点ご了承ください。 今回のシナリオ ACM も色々な機能があるのですが、今回はその中から、AWS環境への OpenShift の簡単構築をご紹介します。♪ 以下、本ブログの項目となります。 1. ACM 概要 2. OpenShift 4.5 上に ACM を構築する 3. ACM から AWS 上に OpenShift 環境を新規にデプロイする 環境が準備できるようであれば、皆さんも実際にやってみてください。♪ 必要なものは、ACM を構成するための OpenShift 環境と、新規に OpenShift をデプロイするための AWS 環境です。また、OpenShift の構築には、Red Hat のサブスクリプションを管理するカスタマーポータルのアカウントが必要となります。まだお持ちでない方は、 こちら の Log in ボタンから新規アカウントを作成ください。 構築する場合の注意点として、ACM は関連する沢山の Pod をデプロイするため物凄くリソースを食います。特に、ワーカーノード側のリソース消費が激しいので、PoC だからと言ってリソースをケチるとPod のデプロイが出来ず、ACM の構築が完了しませんのでご注意ください。実は私、何度やってもうまくいかないのでおかしいなぁ・・・、と思っていたら、単にリソース不足でした。勿論マニュアルは読んで必要リソースは確認していたのですが、PoC だから大丈夫だろ、と思っていたら甘かったです。（＾＾） ちなみに、私の環境は以下の通りです。 Master：8CPU 24GB Memory x 3台 Worker：8CPU 24GB Memory x 3台 それぞれ、4CPU / 16GB では構築が完了しませんでした・・・。必要なリソースに関しては こちら に記載がりますので、ご確認ください。また、ACM を使って OpenShift を新規構築する AWS 側も多くのリソースを消費しますので、 こちらは特に、費用面でご注意ください。高額請求となっても責任はとれません！ 1. ACM について ACM は複数の OpenShift や AKS / EKS / GKE / IKS など一括管理する事が出来るマルチ K8s 管理ツールです。 ACM 自体は、OpenShift 上で稼働するアプリケーションで、Hub Cluster を構成します。この Hub Cluster が、マネージドクラスターと呼ばれる管理対象の OpenShift や AKS / EKS / GKE / IKS などを管理する形です。 提供する機能は以下の通りです。 ・End-to-end visibility ・Cluster Lifecycle ・Application Lifecycle ・Governance, Risk and Compliance ACM に登録された OpenShift クラスターの状態やPod の情報、Logなどを OpenShift のコンソールにアクセスすることなく、ACM 上から確認する事が出来ます。勿論各 OpenShift クラスターへのリンクもあるので、ACM から簡単に各 OpenShift UIへアクセスして、より細かい情報を取得することも可能です。また、アプリケーションを管理して管理下のマネージドクラスターにデプロイしたり、別途定義可能なコンプライアンスに準拠しているかどうかなども確認可能です。 マネージドクラスターの種類によって提供される機能が異なりますが、OpenShift であれば、ACM から AWS / Azure / GCP 環境への OpenShift クラスター自体の新規作成や削除、バージョン管理（アップデート）も可能です。その他のマネージド K8s は、作成されたものをマネージドクラスターとして登録する形をとります。勿論、ACM 以外で作成された OpenShift もマネージド K8s 同様事後登録することも可能です。 2. OCP 4.5 上に ACM を構築する ACM は OpenShift 上で稼働するアプリケーションです。構築は Operator で行います。手順は以下の通りです。 ACM を構成するプロジェクトを作成する OpenShift Cluster Manager 内の Pull Secret 情報含むシークレットを作成する Operator で ACM をデプロイする Operator の中で、2のシークレットを指定し、Hub Cluster を構築する では順にやっていきましょう。まずはプロジェクトの作成です。これは簡単ですね。♪ ここでは、 acm というプロジェクト名にしています。 次に、シークレットの作成を行います。この作成には、ご自身の OpenShift Cluster Manager のPull Secretを使います。 この辺り から Copy Pull Secret をクリックし、クリップボードにコピーしておいてください。 Pull Secret のクリップボードへのコピーが終わったら、上部の Project で acm が選択されている事を確認して、 Workloads → Secrets から、Create のプルダウンで、 Image Pull Secret を選択。 Image Pull Secret 作成画面で、適当に名前を入力（ここでは、 acm-secret ）し、 Authentication Type で、 Upload Configuration File を選択。 Configuration File の欄に、先ほどコピーした Pull Secret を貼り付けて、 Create ボタンをクリックします。 次は、Operator のデプロイです。ACM は沢山の Pod から構成されますが、Operator を使うことにより簡単に構築が出来ます。 Operators → OperatorHub から、 Advanced Cluster Management for Kubernetes を選択します。 ACM のインストール画面となりますので、 Install をクリックします。 次ちょっと注意です。 Installed Namespace のところ、デフォルトでは open-cluster-management が選択されていると思いますので、 Pick an existing namespace を選択し、 acm プロジェクトを選択の上 Install をクリックします。 数分待つと、 Status が Succeeded となり、ACM Operator のデプロイが完了します。 次は、Hub Cluster の作成です。左にある、 Advanced Cluster Management for Kubernetes をクリックします。 MultiClusterHub を選択して、 Create MultiClusterHub をクリックします。 Hub Cluster の作成画面で、YAML View をクリックし、 spec: {} のところを以下のように編集し、 Create をクリックします。 apiVersion: operators.open-cluster-management.io/v1beta1 kind: MultiClusterHub metadata: name: acm namespace: <namespace> spec: imagePullSecret: acm-secret Status が Phase: Running なれば完了です。10分ほどかかります。状況が気になる方は、 Workloads → Pods で Pod デプロイの状況を見てみてください。ACM 関連の Pod を見る事が出来ます。この一連のPod のデプロイが全て完了すると、Hub Cluster の構築完了です！ Hub Cluster の構築が終わると、ACM アプリケーション UI へのルートが自動的に作成されますので、 Networking → Routes → Location をクリックして接続してみます。アカウント情報の入力画面では、OCP と同じユーザー名/Password が利用で可能です。 この画面が出てくれば成功です！！うまく行きましたか？ 次はいよいよ ACM を使って AWS 環境に OpenShift をデプロイしてみます。♪ 3. ACM から AWS 上に OCP 環境をデプロイし管理する ACM を使って、AWS 上に OCP クラスタを作成してみましょう。 ACM のホーム画面で、 Go to Clusters をクリックします。 Add cluster をクリックし、 Create a cluster を選択します。 Cluster 作成画面が現れます。各パラメータの意味は以下の通りです。 Cluster name ：このマネージドクラスターに名前を付けます Distribution ： Amazon Web Servicesを選択します ※ 2020年 8月24日時点、OCP 4.5 では AWS、GCP、Azure がサポート対象となっています。 Release image ：デプロイする OpenShift のバージョンを選択します。特に問題なければ最新版を選択しましょう。 最初のデプロイの際は、AWS への接続情報を登録する必要があります。 Add connection をクリックします。 AWS に OpenSfhit 環境を作成するために必要なパラメータが表示されます。各パラメーターの意味は以下の通りです。 Connection name : この接続情報に対する単なる名前です。 Namespace : 1の ACM 作成の際、シークレットを作成したプロジェクト名を選択します。今回は、 acm です。 Base DNS domain : AWS 上の OCP のベースドメイン名を入力します。 AWS Access Key ID : AWS に接続するためのアクセスキーを入力します。 AWS Secret Access Key ID : AWS に接続するためのシークレットキーを入力します。 Red Hat OpenShift Pull Secret : 自身の OpenShift Cluster Manager からPull Secret をダウンロードして中身を貼り付けます。 SSH Private Key : 作成する AWS 上のOCP クラスターにアクセスするための SSH プライベートキーの中身を貼り付けます。 SSH Public Key : 作成する AWS 上のOCP クラスターにアクセスするための SSH パブリックキーの中身を貼り付けます。 入力が完了したら、右上の Create をクリックします。 元の入力画面に戻るので、先ほど作成した接続情報 acm を選択し、必要に応じて、Node の情報（リージョン、ゾーン、インスタンスタイプ、ディスク容量、ワーカーノードの個数など）を変更し、右上の Create をクリックします。 Status が Creating 状態になって、作成中であることが分かります。あとは待つだけです。♬ 約30くらいで AWS 環境への OpenShift 環境構築が完了します。完了すると ACM 上では、以下の通り Ready となります。 OpenShift UI ログインのためのアカウント情報も記載されていますので、確認の上ログインしてみてください。 既に、Upgrade available になってますね。（＾＾） Upgrade available をクリックすると、以下の様な画面が現れて、こちらからバージョンを指定して OpenShift のバージョンアップが可能です。 まとめ さて、Advanced Cluster Management for Kubernetes による AWS 環境への OpenShift の簡単構築、如何でしたでしょうか。お楽しみいただけましたでしょうか？♬ ACM はアプリケーションのデプロイやコンプライアンス管理なども出来るのですが、今回は ACM 自体の構築と、ACM を使った OpenShift の AWS 環境への新規構築方法に関してご説明しました。こんなに簡単に OpenShift が新規構築できるなんて面白いですよね。 この ACM、マルチ K8s 管理という意味で凄く期待を抱かせる統合管理アプリケーションだと思います。 今後とも目が離せない ACM 是非ご期待ください！

Red Hatのソリューションアーキテクトの伊藤ちひろです。 Red Hat にはクラウドネイティブアプリの開発に役立つ、Application Services のラインナップが充実していることをご存知ですか？ ここでは、Red Hatの Application Services に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 9 月号となります。 ※前回までは Middleware でしたが、今回から Application Services に変りました。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1 : Red Hat Integration - 2020/8月リリースのハイライト: Service RegistryのGA, Mirror Maker 2のGA, 3scale 2.9のリリースをご紹介！ Red Hat Integrationの2020/8月リリースのハイライトとして、以下についてご紹介しています： Service RegistryのGA Mirror Maker 2のGA 3scale 2.9のリリースアップデート speakerdeck.com 特集2 : Red Hat Process Automation 7.8 リリースのハイライト : 新機能をいくつかご紹介！ Red Hat Process Automation 7.8が、7/29にGAとなりました！ このリリースでは、主にお客様からの要望が多かった機能の提供と、開発者およびユーザーエクスペリエンスの改善に重点を置いています。 今回はその新機能の中から、以下についてご紹介していきます： タスク拡張のための予測サービス 最適化計画に基づいたヒューマンタスクの自動割り当て プロセス変数のタグ付け speakerdeck.com 特集3 : これからの時代の要件を満たすため、サーバレスやクラウドネイティブスタックなどの技術を実現する Quarkus の技術を詳細に紹介！ 現在システムに求められる要件は必要に応じて 0 からスケールアウトするなど可用性や性能といった面で大きく変化しています。それらの要件を実現するため、サーバレスやクラウドネイティブという技術が必要となっています。それらの技術を容易に導入できる Quarkus の内部はどの様に動作しているのかを簡単に紹介します。 speakerdeck.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat Fuse 7.7 Red Hat Process Automation Manager 7.8 Red Hat 3scale API Management 2.9

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろです。 この記事は、Quarkus.io のブログ記事、 gRPC with Quarkus! の翻訳記事です。 Quarkus 1.5 では、 gRPC Quarkus拡張機能 の最初のバージョンを出荷しました。 gRPC に馴染みのない方に紹介すると、HTTP/2と Protobuf に依存した高効率なリモートプロシージャコールの仕組みです。gRPC は、Go、JavaScript、Python、Java などの任意の言語から gRPC サービスを実装して利用できます。 gRPC は、より古典的なリクエスト/レスポンスの相互スキームと同様に、双方向のデータストリームをサポートしています。gRPCは特にマイクロサービスに適しています。マイクロサービスシステムを構築する際の3つの大きな懸念事項である認証、トレース、ヘルスのサポートを提供します。 gRPC サービスは、異なるメソッドをリストアップし (次の例では Hello ) 、と交換されるメッセージ ( HelloRequest と HelloReply ) の定義した proto ファイルに記述されています。 syntax = "proto3"; option java_multiple_files = true; option java_package = "io.quarkus.grpc.examples.helloworld"; option java_outer_classname = "HelloWorld"; package io.quarkus.grpc.example; service Greeter { rpc Hello (HelloRequest) returns (HelloReply) {} } message HelloRequest { string name = 1; } message HelloReply { string message = 1; } Proto コンパイラである protoc は、これらのprotoファイルから、ターゲットとなる言語ごとにスタブ (クライアント) とベースの実装 (サービス) を生成します。 Quarkus で gRPC サポートを有効にするには、 quarkus-grpc 拡張機能を追加します。以下の依存関係をプロジェクトに追加するか、以下のコマンドを実行してください。 quarkus-grpc の依存関係 <dependency> <groupId> io.quarkus </groupId> <artifactId> quarkus-grpc </artifactId> </dependency> 既存のプロジェクトに quarkus-grpc 拡張機能を追加します。 mvn quarkus:add-extension -Dextension=quarkus-grpc もちろん、 プロジェクトジェネレータ から gRPC を選択できます。 現時点では、この拡張機能は protoc の生成をカバーしていないので、そのためにはプロジェクトを設定する必要があります。 こちらで 例をご紹介しています。gRPC 拡張機能は以下をサポートしています。 gRPC サービスの実装 gRPC サービスの消費 平文とTLS 相互認証 gRPCのリフレクションとヘルス・サービス gRPCの「bare」Java API と Quarkus のリアクティブ API と統合する Mutiny API などなど、実際に見てみよう。 youtu.be この動画で紹介しているコードは、この GitHubプロジェクト から入手できます。 まだまだ続く! それは最初の一歩に過ぎない。より良いものにするためのアイデアはいくらでもあります。まず、 protoc の生成を取り上げます。しして、開発時にこれらの proto ファイルを修正できるようにすることで、ホットリロードの体験を向上させたいと思います。カスタムコンプレッサ、ロードバランサー、ネームリゾルバのサポートもロードマップ上にあります。 私たちはあなたのフィードバックを大切にしていますので、バグを報告したり、改善を求めてください。 Quarkus のユーザーの方、または好奇心旺盛な方は、恥ずかしがらずにコミュニティに参加してください。 GitHub でフィードバックを提供します。 いくつかのコードを作成し、 PRをプッシュします 。 Zulip や メーリングリスト で議論します。 Stack Overflow で質問をします。

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。 昨日8月24日に Red Hat Ansible Tower Performance Improvements between 3.6 and 3.7 の記事が公開されました。Ryan Petrello, Imaanpreet Kaur, Charan Raj Musali によって書かれたものです。早速許諾を得まして、翻訳してこちらで紹介します。 www.ansible.com お客様から「ジョブイベントが Tower UI に出てこない」と指摘をいただき、ジョブのステータスの更新を見ようとしてもぜんぜん出てこないという重大な問題が発生していました。Red Hat Ansible Tower がよりリアルタイムにジョブのステータスの更新状況を提供できるようにするために行った、パフォーマンスの改善について説明します。 パフォーマンスの改善 3.6と3.7リリースの間で、大幅なパフォーマンスの向上を行うことで、イベント処理、ジョブの実行性能、そしてユーザーインターフェイスが改善しました。この作業は、お客様と Red Hat Scale and Performance チームの共同で行われました。 標準出力の取り込み速度を大幅にスピードアップするために、イベント処理に顕著なパフォーマンスの向上を追加しました。 Ansible Towerを更新して、クラスター化とイベント配信でRabbitMQに依存しないようにしました。 イベント処理の新しい依存関係としてRedisが追加されました。 同時に多くのユーザーがAnsible Towerにログインしているときの、さまざまなジョブビューのユーザーインターフェイスのパフォーマンスが向上しました。 ジョブの依存関係やスケジューリングアルゴリズムの最適化により、ジョブ実行のパフォーマンスが向上し、プレイブックと並列ジョブを実行するための標準出力の書き込み速度が向上しました。 Ansible Towerの速度低下を防ぐために、非常に多数のホストを持つインベントリのイベント処理を修正しました。 実行中のジョブが改善され、関連するインベントリの更新がブロックされなくなりました。 構築およびパフォーマンステスト ジョブの実行時間とジョブ結果の処理時間の間の遅延、および実行中のパフォーマンスベンチマークをよりよく把握するために、平均的な本番環境と同等のHAクラスタで Ansible Tower を構成しました。 構成 Node-A Node-B Tower Version Red Hat Ansible Tower v3.6.2 Red Hat Ansible Tower v3.7.1 CPU X5650 @ 2.67GHz 24 Core X5650 @ 2.67GHz 24 Core RAM 98GB RAM 98GB RAM VM イメージはそれぞれディスクを分離しています。 適切なベンチマークを行うには、バージョン間で行われたパフォーマンスの向上を比較するのに十分な数のジョブイベントが必要でした。 この目標を達成するために、100個の仮のホスト (ansible_connection: local を使用) を含むインベントリファイルと100個のイベント/ホストを生成するジョブを作成して、10万個のジョブイベントを生成しました。 特定のインベントリーで10個のジョブを同時に起動すると、10万件のイベントが発生し、これは私たちのニーズには十分でした。 パフォーマンスの結果 ジョブ実行時間 10個並列での平均実行時間の結果です。 Ansible Towerが10個の同時ジョブを完了する期間は、v3.6.2とv3.7.1で同じですが、パフォーマンスの急激な低下は見られませんでした。 ジョブイベントの処理時間 10個並列で実行したジョブイベントの平均処理時間の結果です。 Ansible Towerがすべてのジョブ結果を処理するのにかかる時間は大幅に改善されました。Ansible Tower v3.7.1でのイベント処理はv3.6.2と比較して82.56％高速化されました。 これは大きな改善であり、ユーザーエクスペリエンスが大幅に改善されます。 ジョブイベント間の必要時間 10個並列で実行したジョブイベント間に必要な時間の平均です。 Ansible Tower v3.7.1では、ジョブの完了後にすべてのジョブ結果を処理するために必要な追加の時間が、v3.6.2と比較して95.77％削減されました。 繰り返しになりますが、パフォーマンスの大幅な改善がここにはっきりと示され、ジョブイベントに関するユーザーエクスペリエンスがよりスムーズになります。 まとめ Ansible Tower v3.7.1から利用可能になったパフォーマンスの改善により、Ansible Towerはすべてのジョブを短い時間で処理できるようになりました。これにより、ユーザーはAnsible Towerダッシュボードでジョブステータスの更新をよりリアルタイムですばやく確認でき、よりスムーズで全体的に満足のいくユーザーエクスペリエンスを実現できます。 Ansible Towerの詳細情報に興味がある場合、Ansible Towerのドキュメントをご確認ください。 最新バージョンをダウンロードしてインストールするには、Ansible Tower インストールおよびリファレンスガイドにアクセスしてください。最近のAnsible Towerリリースのリリースノートを表示するには、リリースノート3.7.xおよびリリースノート3.6.xにアクセスしてください。 Red Hat Ansible Automation Platformの詳細に興味がある場合は、電子書籍をチェックしてください。 docs.ansible.com docs.ansible.com docs.ansible.com www.ansible.com 著者について Ryan Petrelloは、Red Hat Ansible Towerのプリンシパルソフトウェアエンジニアで、Towerのバックエンドサービスのエンジニアリングを指揮しています。 Imaanpreet Kaurは、Red Hat Scale and Performance チームのソフトウェアエンジニアです。 彼女は、Red Hat SatelliteとAnsible Towerでパフォーマンスレビュー/チェックを行います。 Charan Raj Musaliは、Red Hat Scale and Performance チームのアソシエイトソフトウェアエンジニアです。 彼は、Ansible Towerのパフォーマンスレビュー/チェックを行います。 翻訳者より 3.5 以前のバージョンの Ansible Tower ではデータベースに格納されたジョブイベントの数が膨大のとき、ダッシュボードの表示に時間がかかる、ジョブが実行できないなどといったパフォーマンスの問題を抱えていました。「管理ジョブ」の機能で古いデータを定期的に削除していただき、データベースの負担を軽減させるしか方法がなかったのです。 3.6 からは PostgreSQL を 10 にアップデートし、さらに INDEX の有効活用を図ることでジョブの標準出力をより高速に扱えるようになりました。他にはプロジェクトのロックも排除し、並列実行であってもリソースを有効に活用できるようになりました。 3.7 ではさらに、この記事で見てきたように RabbitMQ を置き換えるなどのアーキテクチャからの見直しがされ、アプリケーション側もレコード数の増加に伴うデータベース側の負荷を抑えるように改善されました。 もし古いバージョンをお使いの方でパフォーマンスの問題にお困りでしたら、格段に高速化した 3.7 (現時点での最新版は 3.7.2) への更新を是非ともご検討ください。 Ansible Towerの評価ライセンスリクエストはこちらからご利用いただけます。 www.ansible.com Happy Automation!

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろです。 この記事は、Quarkus.ioのブログ記事、 Supersonic Subatomic GraphQL の翻訳記事です。 MicroProfile GraphQL は、リリースされたばかりの Quarkus のバージョン 1.5.0 に含まれています。 GraphQL とは？ 「 GraphQL は、API 用のオープンソースのデータクエリおよび操作言語です。また、既存のデータを使ってクエリを実行するためのランタイムです。GraphQL は、クライアントから文字列を解釈ます。そして、あらかじめ定義された方法で、わかりやすく、予測可能な方法でデータを返します。GraphQL は REST の代わりとなるものではありますが、必ずしもRESTを置き換えるものではありません。」 完全な GraphQL の仕様書 を読む なぜ GraphQL なのか？ GraphQL を使う主な理由は以下の通りです。 データのオーバーフェッチやアンダーフェッチを避ける。クライアントは 1 つのリクエストで複数のタイプのデータを取得できます。また、特定の基準に基づいて応答データを制限できます。 データモデルの進化を可能にする。スキーマへの変更は、既存のクライアントの変更を必要としないように行うことがでます。その逆も可能です。これは、アプリケーションの新しいバージョンを必要とせずに実行できます。 先進的な開発者の経験： スキーマは、データへのアクセス方法を定義し、クライアントとサーバー間の契約として機能します。双方の開発チームは、これ以上コミュニケーションを取らなくても仕事ができます。 ネイティブスキーマの内観は、ユーザーがAPIを発見し、クライアント側でクエリを洗練することを可能にします。この利点は、スムーズで簡単なAPIの発見が可能になGraphiQLやGraphQL Voyagerなどのグラフィカルなツールを増加することです。 クライアント側では、クエリ言語は柔軟性と効率性を提供します。これにより、開発者はサーバーへの繰返しを減らしながら、技術環境の制約に適応できます。 MicroProfile GraphQLとは？ 「MicroProfile GraphQL仕様の意図は、"コードファースト"のAPIセットを提供することです。それは、ユーザーがJavaでポータブルなGraphQLベースのアプリケーションを迅速に開発できるます。この仕様のすべての実装には、主に2つの要件があります。 GraphQL Schemaを生成して利用可能にする。これは、ユーザーコードのアノテーションを参照することで行われます。また、すべての GraphQL クエリとミューテーション、およびクエリとミューテーションのレスポンス型または引数を介して暗黙的に定義されたすべてのエンティティを含まなければなりません。 GraphQLリクエストを実行する。これは、クエリまたはミューテーションのどちらかの形になります。最低限、仕様はHTTP経由でのこれらのリクエストの実行をサポートしなければなりません。 MicroProfile GraphQL 仕様書 の全文を読む これで code.quarkus.io を使って Quarkus を使い始め、 SmallRye GraphQL 拡張機能 を含むことができるようになりました。 これにより、以下の依存関係を持つ Quarkus スターターアプリケーションが作成されます。 <dependency> <groupId> io.quarkus </groupId> <artifactId> quarkus-resteasy </artifactId> </dependency> <dependency> <groupId> io.quarkus </groupId> <artifactId> quarkus-junit5 </artifactId> <scope> test </scope> </dependency> <dependency> <groupId> io.rest-assured </groupId> <artifactId> rest-assured </artifactId> <scope> test </scope> </dependency> <dependency> <groupId> io.quarkus </groupId> <artifactId> quarkus-smallrye-graphql </artifactId> </dependency> 今のところ、作成した例のアプリケーションは JAX-RS アプリケーションです。拡張機能がカスタムサンプルアプリケーションを定義できるようにするための いくつかの作業が進行中 です。そのため、それまでは常に JAX-RS アプリケーションを取得します。JAX-RS は必要ないので、 quarkus-resteasy の依存関係を削除できます。 最初の GraphQL エンドポイント。 ExampleResource Rest サービスを GraphQL エンドポイントに変更します。 クラスのアノテーション Path("/hello") を @GraphQLApi に置き換えます。 メソッドのアノテーション @GET を @Query に置き換えます。 メソッドのアノテーション @Produces(MediaType.TEXT_PLAIN) と、すべてのJAX-RSインポートを削除します。 これだけです！あなたの ExampleResource は現在こうになっているはずです。 package org.acme; import org.eclipse.microprofile.graphql.GraphQLApi; import org.eclipse.microprofile.graphql.Query; @GraphQLApi public class ExampleResource { @Query public String hello() { return "hello" ; } } これで、Quarkus の dev モードを使用してアプリケーションを実行できるようになりました。 mvn quarkus:dev ここで localhost:8080/graphql-ui/ を参照し、以下のクエリを実行します。 { hello } これは以下を返すでしょう。 { " data ": { " hello ": " hello " } } MicroProfile GraphQL ガイド も参照してください。 より詳細な例 GitHub プロジェクト からソースを取得して、より詳細な例を見てみましょう。 これはマルチモジュールのアプリケーションです。まず、すべてのモジュールをコンパイルします。ルートディレクトリで、 mvn clean install 今すぐ Quarkus の例を閲覧してください。 cd quarkus-example ProfileGraphQLApi.java を見てください。 @GraphQLApi とマークされています。 @Query( "person" ) public Person getPerson( @Name( "personId" ) int personId){ return personDB.getPerson(personId); } 上記のメソッドは personId で人物を取得します。ご覧のように、メソッドは @Query アノテーションで問い合せ可能になっています。オプションで名前（この場合は"person"）を指定できます。しかし、デフォルトはいずれにせよ"person"です（メソッド名に"get"を含まない）。オプションでパラメータに名前を付けられますが、デフォルトはパラメータ名 ("personId") になります。 Person オブジェクトは、システム内の Person (User または Member) を表す POJO です。それは多くのフィールドを持っており、いくつかは他の複雑な POJO です。 しかし、 Query アノテーションを使用すると、興味のあるフィールドを正確に問い合せ可能になります。 サンプルアプリケーションを実行します。 mvn quarkus:dev ここで localhost:8080/graphql-ui/ を参照し、以下のクエリを実行します。 { person ( personId :1) { names surname scores { name value } } } エディタに「code insight」があることに注目してください。それは、GraphQLがスキーマを持っていて、内観にも対応しているからです。 興味のある分野だけをリクエストすることができ、ペイロードをかなり小さくできます。 クエリを組み合わせることもできます。例えば、上記のように人物 1 のフィールドを取得し、人物 2 の名前と苗字を取得したい場合は、以下のようにします。 { person1 : person ( personId :1) { names surname scores { name value } } person2 : person ( personId :2) { names surname } } これは以下を返します。 { " data ": { " person1 ": { " names ": [ " Christine ", " Fabian " ] , " surname ": " O'Reilly ", " scores ": [ { " name ": " Driving ", " value ": 15 } , { " name ": " Fitness ", " value ": 94 } , { " name ": " Activity ", " value ": 63 } , { " name ": " Financial ", " value ": 22 } ] } , " person2 ": { " names ": [ " Masako ", " Errol " ] , " surname ": " Zemlak " } } } ソースフィールド クエリをよく見ると、人物の score フィールドを尋ねたことがわかります。ですが、 Person POJOには score フィールドが含まれていません。人物に @Source フィールドを追加して score フィールドを追加しました。 @Query( "person" ) public Person getPerson( @Name( "personId" ) int personId){ return personDB.getPerson(personId); } public List<Score> getScores( @Source Person person) { return scoreDB.getScores(person.getIdNumber()); } そこで、レスポンス型に一致する @Source パラメータを追加することで、出力にマージするフィールドを追加できます。 部分的な結果 上記の例では 2 つの異なるデータソースを統合していますが、 score システムがダウンしているとします。そうすると、まだ持っているデータと、score のエラーが返ってきます。 { " errors ": [ { " message ": " Scores for person [797-95-4822] is not available ", " locations ": [ { " line ": 5 , " column ": 5 } ] , " path ": [ " person ", " scores2 " ] , " extensions ": { " exception ": " com.github.phillipkruger.user.graphql.ScoresNotAvailableException ", " classification ": " DataFetchingException " } } ] , " data ": { " person ": { " names ": [ " Christine ", " Fabian " ] , " surname ": " O'Reilly ", " scores2 ": null } } } ネイティブモード この例をネイティブモード（ graalvm-ce-java11-19.3.2 を使用）で実行してみましょう。 mvn -Pnative clean install これでネイティブの実行ファイルが作成され、アプリケーションが非常に早く起動するようになります。 ./target/quarkus-example-1.0.0-SNAPSHOT-runner __ ____ __ _____ ___ __ ____ ______ --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \ --\___\_\____/_/ |_/_/|_/_/|_|\____/___/ 2020-06-11 17:02:55,041 INFO [io.quarkus] (main) quarkus-example 1.0.0-SNAPSHOT native (powered by Quarkus 1.5.0.Final) started in 0.026s. Listening on: http://0.0.0.0:8080 2020-06-11 17:02:55,041 INFO [io.quarkus] (main) Profile prod activated. 2020-06-11 17:02:55,041 INFO [io.quarkus] (main) Installed features: [cdi, resteasy, resteasy-jsonb, smallrye-graphql, smallrye-openapi, swagger-ui] パイプラインの中 これはMicroProfile GraphQL Specの最初のバージョンで、パイプラインにはいろいろなものがあります。そのうちの一つがクライアントです。私たちは2種類のクライアントを提案しています。 ダイナミック ダイナミッククライアントを使用すると、ビルダーを使用してクエリを構築できます。 // Building of the graphql document. Document myDocument = document( operation(Operation.Type.QUERY, field( "people" , field( "id" ), field( "name" ) ))); // Serialization of the document into a string, ready to be sent. String graphqlRequest = myDocument.toString(); 詳細は以下を参照してください： github.com/worldline/dynaql 型安全 型安全クライアントはMicroProfile RESTClientに近いものになります。上記と同じ例を見て、どのようにそれを使用することができるかを見てみましょう。プロジェクトのルートから、 quarkus-client フォルダを参照します。この例では、 Quarkus コマンドモード を使用してクエリを作成しています。 クライアントがまだ Quarkus 拡張機能ではないので、こんな感じでプロジェクトに追加しています。 <dependency> <groupId> io.smallrye </groupId> <artifactId> smallrye-graphql-client </artifactId> <version> ${smallrye-graphql.version} </version> </dependency> これで、興味のあるフィールドだけを含む POJO を作成できるようになりました。クライアントモジュールの Person と Score を見てみると、サーバー側の定義よりもかなり小さくなっています。 あとは、興味のあるクエリを定義するインターフェースを追加するだけです。 @GraphQlClientApi public interface PersonGraphQLClient { public Person person( int personId); } そして、これを使えるようになりました。 //@Inject //PersonGraphQLClient personClient; or PersonGraphQLClient personClient = GraphQlClientBuilder.newBuilder().build(PersonGraphQLClient. class ); // ... Person person = personClient.person(id); Quarkus クライアントアプリケーションを実行すると、サーバーへの呼び出しを行い（これがまだ実行されていることを確認してください）、レスポンスを出力できるようになりました。 java -jar target/quarkus-client-1.0.0-SNAPSHOT-runner.jar 2 Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd ========================= | Masako Zemlak | | | | Driving | | 48 | | | | Fitness | | 73 | | | | Activity | | 62 | | | | Financial | | 54 | | | ========================= (2) の数字は、この例では personId です。 概要 これは Quarkus で利用できるようになった MicroProfile GraphQL の簡単な紹介です。まだまだ多くの 機能 があり、さらに多くの機能が 計画 されていますので、ご期待ください。

RHEL for SAP Solutions での特別なアップデートサポート(Update Services for SAP Solutions) レッドハット　ソリューションアーキテクト石倉です。 今回は RHEL for SAP Solutions のアップデートサポートに関して紹介します。 Red Hat Enterprise Linux では原則、機能拡張や不具合の対応は最新バージョンのみに対して行われます。 アップデートの重要性、また、アップデートの際に有効な考え方など、以下のブログも合わせてご確認下さい。 Red Hat Enterprise Linuxを定期的にアップデートする - 赤帽エンジニアブログ 一方、全てのシステムがリアルタイムにアップデートが出来れば問題は無いのですが、システム特性によってはアップデート作業に伴う検証などに時間がかかるシステムも少なからず存在すると思います。 そのような性質のシステムに対して、レッドハットは延長アップデートサポート (Extended Update Support(EUS)) という名前で、Red Hat Enterprise Linux サブスクリプションのオプションサービスを提供しています。 このサービスは、特定のマイナーリリースに対して、最長約24ヶ月のRed Hat Enterprise Linux のマイナーリリースに提供される重大な影響を与えるセキュリティアップデートと、緊急優先度のバグ修正に関するバックポートを提供するものです。 このサービスを利用する事で、サポート期間が重複している期間中に、計画的にアップデートを実施する事が可能になります。 EUSの詳細な考え方や、具体的な活用方法については、以下のKnowledgebaseもご確認下さい。 延長アップデートサポート (EUS) の標準オペレーティング環境 (SOE) のガイド - Red Hat Customer Portal アップデート作業に伴う検証などに時間がかかるという点では、企業システムの中核となる、基幹系システムであればなおさら問題になると思います。 レッドハットとしても、より長いアップデートサポートを提供出来るよう、RHEL for SAP Solutionsでは、Update Services for SAP Solutions (E4S)という名前で、EUSに追加して更に約24ヶ月の延長、合計48ヶ月の、重大な影響を与えるセキュリティアップデートと、緊急優先度のバグ修正に関するバックポートを提供しています。 E4Sを有効に活用頂く事で、EUSより更に柔軟なアップデートプランの検討が可能になります。 引用元： Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal 現時点の予定では、例えば来年以降で開発環境から順次新システムの導入を検討されている場合、RHEL for SAP Solutions8.4で導入を進め、2024年〜2025年の期間でRHEL for SAP Solutions8.10へのマイナーアップデートを実施する事で、2029年5月までの長期の利用が可能な形となります。 概要に戻る Red Hat Enterprise Linux for SAP Solutions ー概要ー - 赤帽エンジニアブログ レッドハット　ソリューションアーキテクト石倉

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろです。 この記事は、Quarkus.io のブログ記事、 Quarkus 1.6 released - AppCDS, Google Cloud Functions, GraalVM 20.1.0 and more... の翻訳記事です。 夏になりました。私たちはまだまだ急ピッチでQuarkusの改良に励んでいます。 もちろん、既存の機能やドキュメントの改善とバグを修正するだけではありません。私たちは非常に興味深い新機能もお届けしました。 JVMモードでの起動時間を改善するためのAppCDSアーカイブの生成を統合 Google Cloud Functionsのサポート - 既存の Amazon Lambda と Azure Functions のサポートに追加 リアクティブな IBM Db2 クライアント (Db2 JDBC ドライバは 1.7 で登場) Apache Cassandra クライアント WebJars のロケーター拡張機能と Spring @Scheduled のサポート アプリケーションのトラブルシューティングのためのより良いツール GraalVM 20.1.0 へのアップグレード これらの多くは、貴重なフィードバックがあったからこそ可能になりました。そしてコミュニティに参加することで、問題をオープンにしたり、quarkus-devリストでスレッドを立ち上げたり、Zulipでチャットをしたりと、どんどん参加してください。私たちは迅速に動き、フィードバックは次のバージョンのQuarkusに直接注入されます。 移行ガイド 既存のアプリケーションの移行をお考えですか？ここに 1.6への移行ガイド があります。 何か新しいことは？ コアの変更 迅速な jar のパッケージ形式 迅速な jar のパッケージ形式が成熟してきています。まだあなたのアプリケーションで試してない場合は、将来的にデフォルトにする予定なので、試してみることをお勧めします。 以下の行を application.properties に追加するとテストできます。 quarkus.package.type=fast-jar またはビルド時に -Dquarkus.package.type=fast-jar を渡します。 AppCDS Quarkus 1.6では、ビルドプロセスの一部として AppCDS を自動的に生成する機能が導入されました。 基本的には、Java 11 以上を使用している場合は、 quarkus.package.create-appcds=true を設定します(そう、それはとても簡単です！)。 Quarkus は AppCDS ファイルを作成し、これを活用してJVMモードでのアプリケーションの起動時間を改善します。AppCDS　ファイルは app-cds.jsa という名前です。それはアプリケーション jar と同じディレクトリに生成されます（Quarkus のすべてのタイプの jar がサポートされています）。 これを利用するには、jar と AppCDS ファイルの両方が存在するディレクトリから java -jar -XX:SharedArchiveFile=app-cds.jsa myapp.jar を実行してください（このディレクトリは必ずしも元のビルドディレクトリである必要はありません。しかしファイルが同じディレクトリにある必要があり、そこから java プロセスを実行する必要があります）。このディレクトリ要件は、Quarkus固有の制限ではありません。 JVM の要件が AppCDS ファイルをビルドしてアプリケーションを実行する際にクラスパスが同じでなければならないということに注意してください。最後に、アプリケーションをビルドして実行する際には、同じJVMバージョンを使用してください（これも JVM の制限です）。 近日中に、より多くの詳細を専用のブログ記事でお伝えする予定です。 この機能は実験的なものであり、まだコンテナイメージ生成拡張機能と適切に統合する必要がありますが、それにもかかわらず完全に機能します。 CDI 開発モードのエンドポイント Quarkus 1.6では、 /quarkus/arc/beans と /quarkus/arc/observers で CDI コンテキストの概要を知れる便利なエンドポイントを導入しました。 それらは CDI リファレンスガイド に詳しく記載されています。 リクエスト本文の最大ファイルサイズ 以前はデフォルトで無制限でしたが、現在は 10MB に制限しています。もちろん、 quarkus.http.limits.max-body-size で設定できます。 拡張機能 Google Cloud Functions Quarkusは、Google Cloud Functionsのサポートを追加したことで、すべての主要なクラウドプロバイダーでサーバーレスをサポートするようになりました。 それについての詳細を知りたいなら、私たちはあなたが 簡単な関数 を開発するか、 HTTPを使用 したい場合のいずれかのために 2 つの新しいガイドを持っています。 リアクティブなIBM Db2 クライアント 現在、MySQL/MariaDB、PostgreSQL、IBM Db2 用のリアクティブ SQL クライアントを提供しています。 Apache Cassandra クライアント Apache Cassandra クライアントが Quarkus Platform に参加しました。 QuarkusアプリケーションでのCassandraの使用方法については、 専用ガイドを参照 してください。 WebJars ロケータ拡張機能 アプリケーションで webjars を使用している場合、webjar パスからバージョンを破棄できる拡張機能を提供しています。 詳細は ドキュメント をご覧ください。 Spring @Scheduled 対応 Spring 互換性レイヤは、Spring の @Scheduled アノテーションのサポートが追加され、より包括的になってきています。 私たちがサポートしていることや現在の制限事項は、すべて この新しいガイド に記載されています。 GraphQL 拡張機能の OpenTracing 追跡するのが好きですか？GraphQL が好きですか？ SmallRye GraphQL 拡張機能で OpenTracing が有効になったので、OpenTracing 拡張機能が登場するとすぐに対応できるようになりました。 OptaPlanner 拡張機能はコアリポジトリから移動しました。 OptaPlanner 拡張機能は、Quarkus コアリポジトリから OptaPlanner リポジトリに取り出されました。 アーティファクト ID が変更されたので、プロジェクトで OptaPlanner 拡張機能を使用している場合は、新しいものに変更してください。 org.optaplanner:optaplanner-quarkus org.optaplanner:optaplanner-quarkus-jackson org.optaplanner:optaplanner-quarkus-jsonb アーティファクトはQuarkus Platformの一部です。 https://code.quarkus.io から直接インストールするか、通常の add-extension コマンドでインストールできます。 これはプラットフォーム BOM の一部ですので、バージョンを定義する必要はありません。 ネイティブイメージ GraalVM 20.1.0 GraalVM 20.1.0 にアップグレードしました。古いバージョンでも動作する場合がありますが、このバージョンへのアップグレードをお勧めします。 信頼ストア 信頼ストアがネイティブイメージで処理される方法は、GraalVM 19.3 で根本的に変更されました。 私たちのドキュメントは時代遅れでした。それらはこの点ではあまり参考になりませんでしたが、 アップデートされています 。 トラブルシューティング TROUBLESHOOTING.md Quarkus の起動時間と実行時のパフォーマンスは常に向上しています。その主な理由はコミュニティから有益なフィードバックを得られることです。(まあ、ベンチマークもやっていますが) Quarkus でパフォーマンスの問題に遭遇した場合、詳細をお聞きすることが多く、有用な内部情報を提供してくれる様々なツールに慣れていない可能性があります。 ユーザーアプリケーションの起動やランタイムの遅さのプロファイリングは、新しい TROUBLESHOOTING.md を使用することで簡単に行えます。 拡張機能の依存性を検証 この変更は、あなたが拡張機能の開発者である場合にのみ関係します。Quarkus は、デプロイメントとランタイムの依存関係が拡張機能の中で一貫しているかどうかを検証するようになりました。 Quarkus が警告を出している場合は、各ランタイム依存関係がデプロイメント pom に対応するデプロイメントアーティファクトを持っていることを確認してください。 完全な変更ログ 1.6.0.CR1 と 1.6.0.Final の完全な変更ログはGitHubで入手できます。 ADOPTERS.md Quarkusの使用に関する情報を共有するために、リポジトリのルートに ADOPTERS.mdファイル を追加しました。 Quarkusを使用していて、私たちのブログでインタビューを受けたい場合、または単にこのファイルに追加したい場合は、私たちにご連絡ください。 貢献者 Quarkusには現在 316人の貢献者 がいます。皆様、本当にありがとうございました。 特に1.6リリースについてはみなさんのおかげです。 Aaron Rogers, Ales Justin, Alex Soto, Alexander Schwartz, Alexey Loubyansky, Andrea Cosentino, Andrej Petras, Andrew Guibert, Andy Damevin, Antonio Goncalves, Aurea Munoz, Luis Barreiro, Bill Burke, Cem Nura, Chris Laprun, Christian Beikov, Clement Escoffier, crissi98, Cuneyt Ozen, David Santos, Dejan Bosanac, Diogo Quintela, Domenico Loiacono, Dominika Vagnerova, Emanuel Alves, Emmanuel Bernard, Falko Modler, Foivos Zakkak, Galder Zamarreño, Garima Monga, Gaétan Collaud, Geoffrey De Smet, George Gastaldi, Georgios Andrianakis, ghokun, Giacomo Margaria, Guillaume Le Floch, Guillaume Nodet, Guillaume Smet, Gunnar Morling, Gwenneg Lepage, Gytis Trikleris, hantsy, Harald Reinmueller, Harsh Madhani, Hugh Lunnon, Ioannis Apostolidis, Ioannis Canellos, Jaikiran Pai, James Perkins, Jan Martiška, Jiří Locker, Jonathan Dowland, Jordi Sola, Jorge Solórzano, Justin Lee, kdnakt, Ken Finnigan, Kevin Viet, Ladislav Thon, Loïc Mathieu, Luka Lodrant, Manyanda Chitimbo, Marcin Czeczko, Mark Borner, Markus Heberling, Martin Kouba, Matej Novotny, Matej Vasek, Max Rydahl Andersen, Michał Górniewski, Michał Szynkiewicz, Moritz Becker, Paul Carter-Brown, Paul Robinson, Paulo Casaes, Pedro Igor, Peter Palaga, Phillip Krüger, Raffael Correia Mendes, Robbie Gemmell, Roberto Cortez, Romain Quinio, Rostislav Svoboda, Sanne Grinovero, Sergey Beryozkin, Sorin I Costea, Stuart Douglas, Ståle Pedersen, Stéphane Épardaud, Thomas Segismont, Timothy Power, Vincent Sevel, Vinícius Ferraz Campos Florentino, Vlastimil Eliáš, Willem Jan Glerum and Yoann Rodière. 参加しよう 私たちはあなたのフィードバックをとても大切にしていますので、バグを報告し、改善を依頼してください...一緒に何か素晴らしいものを作りましょう! Quarkusのユーザーや好奇心の強い人は、恥ずかしがらずに歓迎コミュニティに参加してください。 GitHub にフィードバックを提供する; コードを作成して PRを行う ; Zulip や メーリングリスト で議論する; なにか質問があれば Stack Overflow で投稿してください。

Red Hatで OpenShift のサポートエンジニアをしている Daein（デイン） です。 Security Context Constraints(SCC) を正しく設定するためにどのようなプロセスで適用されているか確認していきます。 Security Context Constraints(SCC) は、 OpenShift で Pod が実行できるアクション及びアクセスを制御するリソースです。 Pod を作成するユーザーやリンクされている ServiceAccount で許可された SCC の制限を利用し、 Pod を起動させます。詳細情報は次のドキュメントをご参照ください。 docs.openshift.com 処理の流れ まず、 Priority の項目を一番高く指定した SCC のみ適用されると考えてしまいがちですが、実際には対象 Pod の設定によっても左右されます。 また、 SCC を複数付与してもその機能や権限が合わせて適用されるわけではないのでビルトインの SCC で対応できない場合は別途カスタム SCC を作成する必要があります。 処理の流れを簡単に説明すると、次のようになります。 操作するユーザーまたは Pod で参照される ServiceAccount(SA) で許可されたSCCを洗い出します。 洗い出された SCC を Priority の高い順にソートします。 ソートされた SCC 順で Pod の設定に適用できる SCC があるかチェックします。 最初にマッチした1つの SCC で Pod を作成します。この処理順序は、 Priority 設定が影響します。（ Priority が指定されていない場合は" 0 "としてみなされます。） 同じ Priority の場合はより制約された SCC が優先されます。 Priority と"制約"も同じの場合は SCC 名のソート順で優先されます。 マッチする SCC がなかった場合は Pod は無効になって作成されません。 scc process diagram 動作確認 上記の動作を実際に OpenShift Container Platform 4.5 の環境で次の通り確認してみましょう。 注： こちらの例はSCCでの処理詳細及び理解のため、"Priority"を修正したりしていますが、OCPで提供するビルトインSCCの"Priority"の変更は推奨されませんのでご注意ください。 "Priority"の修正が必要であれば既存SCCを複製して別途SCCを作成し、ご要件に合わせて十分ご検証のうえご利用ください。 "Priority"よりPodの設定が優先されるパターン default ServiceAccount(SA) に anyuid 、 hostnetwork 2つの SCC をアサインして" hostNetwork: true "を Pod に設定した前後の違いを確認してみましょう。 " hostNetwork: true "はアサインされた SCC の中で hostnetwork のみ提供できるため、 anyuid がより高い Priority が設定されていても Pod に" hostNetwork: true "がリクエストされた場合は hostnetwork SCC で Pod が作成されます。 テストのため、プロジェクトを作成し、その配下の default SA に anyuid と hostnetwork をアサインします。 $ oc new-project test-scc $ oc adm policy add-scc-to-user anyuid -z default -n test-scc clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "default" $ oc adm policy add-scc-to-user hostnetwork -z default -n test-scc clusterrole.rbac.authorization.k8s.io/system:openshift:scc:hostnetwork added: "default" 一般ユーザーとして認証して" hostNetwork: true "を設定しない Pod と設定した Pod を作成します。 $ oc login -u normal-user -p YOURPASSWORD $ oc whoami normal-user $ oc create -f - <<EOF apiVersion: v1 kind: Pod metadata: name: test-anyuid spec: containers: - args: - tail - -f - /dev/null image: registry.redhat.io/ubi8/ubi name: test --- apiVersion: v1 kind: Pod metadata: name: test-hostnetwork spec: hostNetwork: true containers: - args: - tail - -f - /dev/null image: registry.redhat.io/ubi8/ubi name: test EOF 次の通り、同じ default SA で起動した Pod でも" hostNetwork: true "が設定された Pod は anyuid の Priority がより高く設定されているにも関わらず、 houstnetwork SCC が適用されていることが確認できます。 $ oc get pod NAME READY STATUS RESTARTS AGE test-anyuid 1/1 Running 0 3m22s test-hostnetwork 1/1 Running 0 3m22s $ oc get pod -o yaml | grep -E '^ name:|openshift.io/scc:|serviceAccountName:' openshift.io/scc: anyuid name: test-anyuid serviceAccountName: default openshift.io/scc: hostnetwork name: test-hostnetwork serviceAccountName: default Pod に設定された機能や権限が提供可能なものがアサインされた SCC の中でマッチされなかった場合は次の通り Forbidden エラーメッセージが表示され、Podが作成できなくなります。 Error from server (Forbidden): error when creating "STDIN": pods "test-hostnetwork" is forbidden: unable to validate against any security context constraint: [provider anyuid: .spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used spec.containers[0].securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used provider restricted: .spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used spec.containers[0].securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used] 同じ"Priority"の場合はより強い制約のSCCが適用されるパターン default ServiceAccount(SA) に root が指定できない制限をしたまま、 Dockerfile の USER に指定された特定の UID で Pod を作成する意図として nonroot SCC をアサインしているにも関わらず、デフォルト SCC の restricted が同じ Priority でかつより強い制約を持っているため優先して適用されます。 nonroot SCC を適用するためには明示的に" securityContext.runAsUser: XXX "で特定の UID を Pod 設定に指定するか、 nonroot SCC の Priority を restricted より高く設定する必要があります。 Pod 設定での適用は先程のパターン例で確認しましたので今回は Priority を修正するパターンで確認します。 テストのため、プロジェクトを作成し、その配下の default SA に nonroot のみアサインします。 $ oc new-project test-scc2 $ oc adm policy add-scc-to-user nonroot -z default -n test-scc2 clusterrole.rbac.authorization.k8s.io/system:openshift:scc:nonroot added: "default" 一般ユーザーとして認証してPodを作成します。 $ oc login -u normal-user -p YOURPASSWORD $ oc whoami normal-user $ oc create -f - <<EOF apiVersion: v1 kind: Pod metadata: name: test-nonroot spec: containers: - args: - tail - -f - /dev/null image: registry.redhat.io/rhel8/nginx-116 name: test 次の通り、同じ Priority の SCC であってもより制約が強い restricted SCC が適用されることが確認できます。 $ oc get pod NAME READY STATUS RESTARTS AGE test-nonroot 1/1 Running 0 16m $ oc rsh test-nonroot id uid=1000600000(1000600000) gid=0(root) groups=0(root),1000600000 $ oc get pod test-nonroot -o yaml | grep -E 'openshift.io/scc:|serviceAccountName:' openshift.io/scc: restricted serviceAccountName: default 続いて cluster-admin のクラスタロールを持つアカウントで nonroot SCC の Priority を" 20 "に修正してから一般ユーザーとして認証して Pod を作成します。 $ oc login -u admin-user -p YOURPASSWORD $ oc whoami admin-user $ oc edit scc nonroot : priority: 20 : $ oc get scc restricted nonroot NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES restricted false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] nonroot false <no value> MustRunAs MustRunAsNonRoot RunAsAny RunAsAny 20 false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] $ oc login -u normal-user -p YOURPASSWORD $ oc whoami normal-user $ oc create -f - <<EOF apiVersion: v1 kind: Pod metadata: name: test-nonroot-after-prio spec: containers: - args: - tail - -f - /dev/null image: registry.redhat.io/rhel8/nginx-116 name: test EOF 次の通り、より高い Priority が設定された nonroot SCC が適用され、 Dockerfile の USER に指定された UID が暗黙的に反映されていることが確認できます。 $ oc get pod NAME READY STATUS RESTARTS AGE test-nonroot 1/1 Running 0 89m test-nonroot-after-prio 1/1 Running 0 62s $ oc rsh test-nonroot-after-prio id uid=1001(default) gid=0(root) groups=0(root) $ oc get pod test-nonroot-after-prio -o yaml | grep -E 'openshift.io/scc:|serviceAccountName:' openshift.io/scc: nonroot serviceAccountName: default "cluster-admin"のクラスタロールで操作した場合、別途SCCのアサインなしで関連機能が利用できるパターン cluster-admin のクラスタロールを持つ認証ユーザーであれば SCC を別途設定しなくてもどの SCC でも利用できるため、 Forbidden エラーなしで適切な SCC が設定されて Pod が作成されることを確認します。 デフォルトで提供している SCC の一覧は次の通りになります。 cluster-admin 権限を持つアカウントは次の SCC が利用できます。 $ oc get scc NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES anyuid false <no value> MustRunAs RunAsAny RunAsAny RunAsAny 10 false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] hostaccess false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret] hostmount-anyuid false <no value> MustRunAs RunAsAny RunAsAny RunAsAny <no value> false [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret] hostnetwork false <no value> MustRunAs MustRunAsRange MustRunAs MustRunAs <no value> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] node-exporter true <no value> RunAsAny RunAsAny RunAsAny RunAsAny <no value> false [*] nonroot false <no value> MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <no value> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] privileged true [*] RunAsAny RunAsAny RunAsAny RunAsAny <no value> false [*] restricted false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] 一般ユーザーと比較して、 cluster-admin のクラスタロールを持つ認証ユーザーであれば、別途アサイン作業なしでただ Pod を作成するだけで SCC が設定されますので、一般ユーザーに設定をテストする場合は注意してください。 $ oc new-project test-scc-adminuser $ oc login -u admin-user -p YOURPASSWORD $ oc whoami admin-user $ oc create -f - <<EOF apiVersion: v1 kind: Pod metadata: name: test-anyuid spec: containers: - args: - tail - -f - /dev/null image: registry.redhat.io/ubi8/ubi name: test --- apiVersion: v1 kind: Pod metadata: name: test-hostnetwork spec: hostNetwork: true containers: - args: - tail - -f - /dev/null image: registry.redhat.io/ubi8/ubi name: test EOF pod/test-anyuid created pod/test-hostnetwork created $ oc get pod -o yaml | grep -E '^ name:|openshift.io/scc:|serviceAccountName:' openshift.io/scc: anyuid name: test-anyuid serviceAccountName: default openshift.io/scc: hostnetwork name: test-hostnetwork serviceAccountName: default 実装の確認 以下は、興味ある方はご参考ください。 主に" computeSecurityContext "関数から SCC の適用プロセスが実施されます。ソースコード全文はこちらで参照できます。 github.com func (c *constraint) computeSecurityContext(ctx context.Context, a admission.Attributes, pod *coreapi.Pod, specMutationAllowed bool , validatedSCCHint string ) (*coreapi.Pod, string , field.ErrorList, error ) { // get all constraints that are usable by the user : // "FindApplicableSCCs"関数から許可されたSCCを"Priority"順にソートした一覧が返却されます。 constraints, err := sccmatching.NewDefaultSCCMatcher(c.sccLister, nil ).FindApplicableSCCs(ctx, a.GetNamespace()) : // ここからPod設定にマッチするSCCを確認するループが実装されています。 loop: for _, provider := range providers { // Get the SCC attributes required to decide whether the SCC applies for current user/SA sccName := provider.GetSCCName() sccUsers := provider.GetSCCUsers() sccGroups := provider.GetSCCGroups() // continue to the next provider if the current SCC one does not apply to either the user or the serviceaccount if !sccmatching.ConstraintAppliesTo(ctx, sccName, sccUsers, sccGroups, userInfo, a.GetNamespace(), c.authorizer) && !(saUserInfo != nil && sccmatching.ConstraintAppliesTo(ctx, sccName, sccUsers, sccGroups, saUserInfo, a.GetNamespace(), c.authorizer)) { continue } : // the entire pod validated switch { case specMutationAllowed: // if mutation is allowed, use the first found SCC that allows the pod. // This behavior is different from Kubernetes which tries to search a non-mutating provider // even on creating. We prefer most restrictive SCC in this case even if it mutates a pod. : まとめ 簡単に SCC がどのように処理されて適用されるか紹介しました。 SCC の設計関連の資料も補足としてご参考にしてください。 github.com 通常は、専用の SA を作成し、必要最低限の SCC を利用して Pod を運用するべきですが、1つの SA で仕様が違う複数の Pod を運用する場合には注意が必要です。

皆様こんにちは、Red Hat ソリューションアーキテクトの岡野です。 Ansible Tower による VMware vSphere の自動化の第5弾です。 前回 のPart 4では、 info 系のモジュールを使った vSphere の構成情報の取得方法ついてご説明しました。 今回のシナリオ 今回は、Web Server の作成を Ansible Tower で自動化してみましょう。♪ 具体的には以下を実施します。 1. Linux 仮想マシンをテンプレートからデプロイ 2. デプロイした仮想マシンに対しタグを付与 3. タグの付いた仮想マシンに対し httpd のインストール、80 / 443 のポート開放 4. httpd 動作確認 5. タグの削除 皆さんも同じ環境を準備して実行しながら進めてみてください。♪ 一見すると簡単そうに見えますが、上記を一気に自動化しようとすると少し難しいところがあります。 例えば、手順 1 で vCenter Server に対し仮想マシンをデプロイを行い、手順 3、４ では新規作成した仮想マシンを指定してタスクを実行する必要があるのですが、1 を実行する時には 3 で対象となるインベントリ情報は存在しない・・・、じゃ、手順 3 のインベントリ情報ってどこから持ってくるの？しかも自動的に？？という疑問ですね。 ※今回一連のブログで利用する Playbook は こちら に公開しています。 1. Linux 仮想マシンをテンプレートからデプロイ ではまず仮想マシンの作成から行ってみましょう。作成には Linux のテンプレートを使います。vCenter Server にあらかじめ登録されている Linux 仮想マシンテンプレートが存在することを前提としています。 Playbook は こちら の中から createVM.yml を使います。 --- - name: Create a VM from a template hosts: localhost gather_facts: no tasks: - name: Clone the Template vmware_guest: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" datacenter: DC cluster: CL name: "{{vmname}}{{item}}" folder: /DC/vm template: "{{template}}" networks: - name: VM Network type: dhcp state: poweredon datastore: NFS validate_certs: no with_sequence: count={{number|int - 1}} - name: Clone the Template with wait for customization vmware_guest: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" datacenter: DC cluster: CL name: "{{vmname}}{{number}}" folder: /DC/vm template: "{{template}}" networks: - name: VM Network type: dhcp state: poweredon datastore: NFS validate_certs: no wait_for_ip_address: yes ※ {{ }} で記載した部分は変数です。仮想マシンを作成する datastore については変数にしていませんので環境に合わせて変更してください。 Ansible Tower でジョブテンプレートを作成する際、インベントリーは、Local Host でお願いします。 with_sequence の中に指定されている変数 number は、作成する仮想マシンの数を示しています。 また、オプションとして仮想マシンの稼働を待つ処理を入れています。具体的には、 wait_for_ip_address: yes というオプションです。 vmware_guest モジュールは仮想マシンのデプロイが終了した時点で処理が終了します。このため、このオプションを記載しないと仮想マシンが起動する前に手順 3 の httpd のインストール操作が発生し、ジョブが失敗する可能性があります。このオプションは新規作成した仮想マシンが確実に httpd Install Ready になるまで待つために記載しているとお考え下さい。 ※今回のこの Playbook では複数の仮想マシンをシーケンシャルに作成します。上記仮想マシンの稼働を1台1台待っていると時間がかかるので、最後の1台の作成のみこのオプションを記載しています。 2. デプロイした仮想マシンに対しタグ付け 次に、新規と既存の仮想マシンを区別するため、新規作成した仮想マシンにタグを付与します。 今回はあらかじめ vCenter Server に仮想マシン用として作成されているタグ New_VM を利用する想定です。 ※ New_VM タグがあらかじめ作成されていないとジョブがエラーとなりますのでご注意ください。 Playbook は こちら の中から tag_vm_manage.yml を使います。 --- - name: Tag Control for VM hosts: all gather_facts: no tasks: - name: Manage VM Tag vmware_tag_manager: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" validate_certs: False tag_names: New_VM object_name: "{{vmname}}{{item}}" object_type: VirtualMachine state: "{{tag_state}}" with_sequence: count={{number}} こちらも、インベントリーは、Local Host となります。 3. タグの付いた仮想マシンに対し httpd のインストール、80 / 443 のポート開放 仮想マシンへのタグ付けも完了しましたので、新規に作成した仮想マシンを Web Server として構成してみましょう。♪ これに関しては以下の 2 点に関し、少し考慮が必要です。 ・新規仮想マシンのインベントリー情報の取得 ・タグを使った新規仮想マシンの選別 順にみていきましょう。今回、ジョブ実行の前提として、手順1～5を一気通貫で自動的に実行することを目指しています。このため、新規作成された仮想マシンのインベントリー情報を Ansible Tower が利用可能なインベントリー情報として取得・利用しなければなりません。 これを実現するのが、ダイナミックインベントリーという便利な仕組みです。ダイナミックインベントリーを使うことにより、Ansible Tower は vCenter Server から仮想マシン情報取得し、その結果を、Ansible Tower が利用可能なインベントリー情報として自動的に登録することが可能となります。イメージは以下のような感じです。 Ansible Tower に登録された vCenter Server の認証情報を使って vCenter Server に登録された仮想マシン情報を取得し、その結果をインベントリーのホストとして登録します。 ダイナミックインベントリーですが、Ansible Tower を使えば設定も極めて簡単です。通常通りインベントリー作成画面から、”ソース” を選択して、"+" をクリック、 ソースに VMware vCenter を指定。さらに、定義されている vCenter Server の認証情報を選択します。 オプションの更新のところは、ヘルプをご確認の上必要なものにチェックを入れておくようにしましょう。 私は、 上書き（既存インベントリーの上書き） と 起動時の更新（ジョブ実行時のインベントリー情報の自動更新） にチェックを入れることが多いです。 登録が終わったら、以下の画面で、vCenter Server へ同期を行い、"ホスト" タブを確認してみてください。 起動中の仮想マシンが登録されていると思います。 ※起動していない仮想マシンも登録する場合は、インスタンスフィルターに以下のように記述します。 {{ runtime.powerState == 'poweredOn' }} {{ runtime.powerState == 'poweredOff' }} これでインベントリー取得が出来ました。 さて、次に、もう 1 つの課題、タグ情報による仮想マシンの選別です。インストール対象である、新規仮想マシンを New_VM というタグで選別する方法ですね。 一番 Cool なのは、ダイナミックインベントリのフィルターで、タグの付いた仮想マシンのみを選別し登録！ なのですが、実は、vSphere 環境の場合、このタグ情報を使ったダイナミックインベントリー内での仮想マシンの選別・登録は現時点では出来ない様です。AWS だと簡単にできるんですが・・・。 ま、出来ないものは仕方がないので、Playbook の中で、タグ情報を拾って仮想マシンを選別します。 やりようはいくらでもあるということです。♬ Playbook は こちら の中から httpd-inst.yml を使います。 --- - name: Get VM Tag & httpd install & Firewall (80/443) config hosts: all gather_facts: yes tasks: - name: Confirm VM Tag & Register to variable vmware_guest_info: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" validate_certs: False datacenter: DC name: "{{ansible_nodename}}" tags: yes register: vm_facts delegate_to: localhost - name: httpd install yum: name: httpd state: latest when: vm_facts.instance.tags == ["New_VM"] - name: httpd running & Enabled service: name: httpd state: started enabled: yes when: vm_facts.instance.tags == ["New_VM"] - name: Firewall Setting 80/443 firewalld: service: "{{item}}" zone: public state: enabled permanent: true immediate: true with_items: - http - https when: vm_facts.instance.tags == ["New_VM"] このインベントリーは、先ほどダイナミックインベントリーを登録したものを利用します。 vmware_guest_info モジュールを使って自分自身のタグ情報を取得します。 このモジュール実行時に取得される情報（戻り値）については、 Part4 をご確認ください。 このモジュールの戻り値を変数 vm_facts で受けると、仮想マシンに付与されたタグの値は、 vm_facts.instance.tags から取得する事が出来ます。 その後の yum タスク、 service タスク、 firewalld タスクの実行に関しては、 when による条件が付与されており、具体的には、 New_VM タグが付与されている時のみ実行されます。これで、タグが付与された仮想マシンのみに必要な処理を実行することが可能となるわけです。♪ 4. httpd 動作確認 ここまで来たら後は簡単です。せっかく Ansible Tower で自動化していますので、本当に httpd アクセスが可能かどうか確認してみましょう！ 色んな方法がありますが、ここでは、 curl を使った方法で簡単に確認しています。 Playbook は こちら の中から http-test.yml を使います。 --- - name: Test Connect to New Web Server hosts: all gather_facts: yes tasks: - name: Show VM Tag vmware_guest_info: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" validate_certs: False datacenter: DC name: "{{ansible_nodename}}" tags: yes register: vm_facts delegate_to: localhost - name: Test http Access command: curl http://localhost/ when: vm_facts.instance.tags == ["New_VM"] ダイナミックインベントリーを記載したインベントリー指定でお願いします。 こちらもタグが付与されている仮想マシンを選択して Task を実行しています。 5. タグの削除 最後はタグの削除です。使うジョブテンプレートは手順 2 と同じで、変数 tag_state の値を absent で実行すれば大丈夫です。 上記 1～5 の手順を こちら や、 こちら を参考に、ジョブテンプレート、さらには、ワークフローテンプレートで定義し実行してみてください。 参考までに、私は以下の様なワークフローテンプレートを作成し、利用しています。 ジョブテンプレートの実行が失敗したときのリカバリも Ansible Tower であれば簡単に定義することが可能です。 まとめ さて、これで、5 回に及んだ Ansible Tower による VMware vSphere 環境の自動化のブログは終了となります。お楽しみいただけましたでしょうか？各回では、それぞれ以下の様な事を学んできました。 Part1 ：Ansible Tower で vSphere の何をどうやって自動化できるのか Part2 ：vSphere モジュールを使った Playbook の書き方とAnsible Tower での実行方法について Part3 ：Ansible Tower を使った ESXi ホストの自動構築とvMotion による確認 Part4 ：info モジュールを使った vSphere 環境の構成の確認 Part5：仮想マシンの作成とアプリケーションの構築・設定、ダイナミックインベントリの利用、仮想マシン情報（タグ情報）の取得について vSphere そのものや、仮想マシン、アプリケーション、ストレージ、ネットワーク機器含めた vSphere の周辺環境を管理されている方は多いのではと思います。その方々の日々の運用が Ansible Tower を使うことで、少しでも楽になれば、しかも楽しく（ここが重要ですね）、となれば嬉しく思います。♬ 是非ご検討ください！！ 長々とご拝読、誠にありがとうございました！！ Ansible Tower のバイナリーと評価ライセンスは以下から取得可能です。是非使ってみてください！！ ・Ansible Tower バイナリーダウンロードは こちら から ・Ansible Towerの評価ライセンスは こちら から 　※Customer Portal のアカウント作成が必要です。

SAP on RHEL for SAP Solutions でのSAPシステム向けSystem Role レッドハット　ソリューションアーキテクト石倉です。 今回は RHEL for SAP Solutions の SAP システム System Role について紹介します。 SAP システム System RoleはSAP システム導入に必要なSAP Notesにもとづく設定作業を自動化します。 ＃この記事ではこれからSAP社ERPソフトウェア(SAP ERP Central Component(ECC))をSAP S/4HANAへ移行する方を想定していますので、RHELの最新バージョンである、RHEL8の利用が前提になっています。 ＃この記事ではAnsibleそのものの使い方には触れません。 Ansibleはレッドハットが開発するオープンソースの構成管理ツールで、SAPシステムの導入に役に立つSystem Roleもテクノロジープレビュー版ではありますが提供しています。 7.8. Red Hat Enterprise Linux システムロール Red Hat Enterprise Linux 8 | Red Hat Customer Portal 現在SAPシステム System Roleでは、 sap-preconfigure：SAPシステム共通準備Role sap-hana-preconfigure：SAP HANAインストール用準備Role sap-netweaver-preconfigure：SAP NetWeaverインストール用準備Role の3種類のAnsible Roleが提供されています。 対象システムへの導入方法は以下の通りで、 関連するRepositoryを有効にした後、 # yum clean all # subscription-manager repos --disable="*" # subscription-manager repos \ --enable="rhel-8-for-$(uname -m)-baseos-e4s-rpms" \ --enable="rhel-8-for-$(uname -m)-appstream-e4s-rpms" \ --enable="rhel-8-for-$(uname -m)-sap-solutions-e4s-rpms" \ --enable="rhel-8-for-$(uname -m)-sap-netweaver-e4s-rpms" System Rolesをインストールします。 # yum install rhel-system-roles-sap インストール後、Roleが展開されたことが確認できます。 # ls /usr/share/ansible/roles sap-hana-preconfigure/ sap-netweaver-preconfigure/ sap-preconfigure/ ディレクトリ構造はAnsible Role構成に沿って、以下のようになっています。 ＃ディレクトリ、ファイル構成など、不定期にアップデートされる可能性があります。 # tree -d /usr/share/ansible/roles /usr/share/ansible/roles ├── sap-hana-preconfigure │   ├── defaults │   ├── handlers │   ├── meta │   ├── tasks │   │   ├── RedHat │   │   │   └── generic │   │   ├── RedHat_6 │   │   ├── RedHat_7 │   │   ├── RedHat_8 │   │   └── sapnote │   │   ├── 2292690 │   │   └── 2777782 │   └── vars ├── sap-netweaver-preconfigure │   ├── defaults │   ├── handlers │   ├── meta │   ├── tasks │   │   └── sapnote │   ├── tests │   └── vars └── sap-preconfigure ├── defaults ├── files │   └── etc │   └── tmpfiles.d ├── handlers ├── meta ├── tasks │   └── sapnote │   ├── 2002167 │   └── 2772999 ├── tests └── vars 各ディレクトリにはYAMLファイルが配置されており、YAMLファイルのファイル名、ディレクトリ名は数字で、対応するSAP Notesを示しています。 ＃例えば、ディレクトリ「2772999」には、「SAP Notes2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration」に対応する為のタスクが配置されています。 システムへの適用方法は、例えば「sap-hana.yml」の名前で以下の内容のPlaybookを作成し、 --- - hosts: localhost connection: local roles: - role: sap-preconfigure - role: sap-hana-preconfigure ... 以下のコマンドで、一括での適用処理が可能になります。 # ansible-playbook sap-hana.yml 概要に戻る Red Hat Enterprise Linux for SAP Solutions ー概要ー - 赤帽エンジニアブログ レッドハット　ソリューションアーキテクト石倉

皆様こんにちは、Red Hat ソリューションアーキテクトの岡野です。 Ansible Tower による VMware vSphere の自動化の第4弾です。 前回 のPart 3では、既存の vSphere クラスター環境に新規インストールした ESXi ホストを追加するシナリオを想定した Ansible Tower での自動化についてご説明しました。 今回の内容 今回、仮想マシンの作成方法を書いて一連のブログ完了！！と思っていたのですが、少し脱線して、vSphere 関連の情報取得方法についてご説明したいと思います。（＾＾） 次に予定している Part 5 では以下のような手順で仮想マシンの作成を行うのですが、この際にも利用しますので是非マスターしておいてください。 1. Linux 仮想マシンをテンプレートからデプロイする 2. デプロイした仮想マシンに New_VM というタグを付ける 3. 仮想マシンにタグが付いているかどうかを確認する 4. タグが付いている仮想マシンに httpd をインストールする この手順のうち、手順 3 で、 vmware_guest_info を使って仮想マシンに付与されたタグ情報の取得つまり、『構成情報の取得』を行います。 また、構成確認に関しては、vSphere だけではなく、他の環境への応用も出来ますので、ご存知ない方は是非参考にしていただけると嬉しいです。逆に、既に理解されている方は今回は読み飛ばしていただいて大丈夫です。 vSphere 環境の構成の確認 Ansible Tower はいわゆる『構成変更や新規構築』だけではなく、『構成の確認』も得意としています。 これは vSphere 環境だけの課題ではありませんが、通常の運用業務の中で構成の確認って結構手間になっているという話をよく聞きます。そういった観点でも理解しておくと価値は高いのかなと思います。♪ そもそも各端末を操作するから構成が分からなくなるんだ！ GitなどのSCMを使ってコードベースでインフラを管理すべし！！ という硬派な話も大好きなのですが、ま、その議論はちょっと横に置いておいて、Ansible Tower による vSphere 環境の構成の確認方法について学んでみましょう。♪ ※今回一連のブログで利用する Playbook は こちら に公開しています。 標準仮想スイッチ (vSwitch) 情報の取得 vSphere 関連モジュールは こちら です。この中で、構成確認のモジュールには、 vmware_xxxxxxx_info と、モジュール名の最後に、info が付いています。分かりやすいですね。♬ 2年位前までは vSphere に関する構成確認のモジュールはほとんどなかったのですが、最近目に見えて増えてきています。それだけ需要があるという事なんですね。 さて、vSphere に関する質問の中で、多くいただく物の1つに、 『vSwitch の構成の確認って可能ですか？』 という物があります。ということで、vSwitch の情報取得方法から見てみる事にしましょう。vSwitch の構成確認のモジュールは こちら です。Part 4 まで読んでいただき、そろそろモジュールの見方にも慣れてきた頃でしょうか？♪ Playbook は こちら の中から factsvSS.yml を使います。 Playbook 上はホストを all で記載していますが、インベントリは Local host （つまり、Ansible Tower ですね）でお願いします。 vCenter Server の環境変数を記載していますので、Ansible Tower のジョブテンプレートの認証情報に自分自身の ssh 接続に関する認証情報だけでなく、vCenter Server の認証情報も忘れずに追加してください。 factsvSS.yml --- - name: ESXi vSwitch Information hosts: all gather_facts: no tasks: - name: Show vss facts vmware_vswitch_info: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" validate_certs: False esxi_hostname: "{{ esxi_host }}" register: vss_facts - debug: var: vss_facts 構成確認モジュールが通常の構成変更系のモジュールと異なるところは、出力が必要になるというところです。 出力されないと Playbook 実行しても意味が無いですからね。（＾＾） これを担当するのが、 register と、 - debug です。 register ・・・このモジュールから出力された戻り値を変数に入力 - debug ・・・変数を指定して出力 です。 私の環境で実行したところ、以下の様な出力が得られました。 Ansible は戻り値を階層構造で入れてくれるので物凄く使いやすいです。 ok: [localhost] => { "vss_facts": { "ansible_facts": { "discovered_interpreter_python": "/usr/libexec/platform-python" }, "changed": false, "failed": false, "hosts_vswitch_info": { "xxx.xxx.xxx.xxx": { # ---> esxi IP address "vSwitch0": { "mtu": 1500, "num_ports": 128, "pnics": [ "vmnic0" ] }, "vSwitch1": { "mtu": 1500, "num_ports": 128, "pnics": [ "vmnic1" ] } } } } } ※IPアドレスなど固有情報は xxx など隠し文字にしています。 ただ、思ったより情報少ないですよね・・・。vSwitch に紐づく、ポートグループや vmkernel の情報も欲しい場合が多いと思いますが、こちらは別モジュールで提供。ということで、 vmware_portgroup_info と、 vmware_vmkernel_info モジュールを使ってさらに詳細な情報を取得してみましょう。♪ Playbook は こちら の中から factsPG.yml と factsVMK.yml を使います。 factsPG.yml --- - name: vSphere Port Group Infomation hosts: all gather_facts: no tasks: - name: Show Port Group Information vmware_portgroup_info: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" validate_certs: False esxi_hostname: "{{ esxi_host }}" register: pg_facts - debug: var: pg_facts 私の環境では以下の様な出力が得られました。 ok: [localhost] => { "pg_facts": { "ansible_facts": { "discovered_interpreter_python": "/usr/libexec/platform-python" }, "changed": false, "failed": false, "hosts_portgroup_info": { "xxx.xxx.xxx.xxx": [ # ---> ESXi Host Information / IPAddress { "portgroup": "VM Network", "vlan_id": 0, "vswitch": "vSwitch0" }, { "portgroup": "Management Network", "vlan_id": 0, "vswitch": "vSwitch0" }, { "portgroup": "vmotion", "vlan_id": 0, "vswitch": "vSwitch1" } ] } } } 次に vmkernel の情報取得です。 factsVMK.yml --- - name: vSphere vmkernel Information hosts: all gather_facts: no tasks: - name: Show vmkernel Information vmware_vmkernel_info: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" validate_certs: False esxi_hostname: "{{ esxi_host }}" register: vmk_facts - debug: var: vmk_facts 実行結果 ok: [localhost] => { "vmk_facts": { "ansible_facts": { "discovered_interpreter_python": "/usr/libexec/platform-python" }, "changed": false, "failed": false, "host_vmk_info": { "xxx.xxx.xxx.xxx": [ # ---> ESXi Host Information / IP Address { "device": "vmk0", "dhcp": false, "enable_ft": false, "enable_management": true, "enable_vmotion": false, "enable_vsan": false, "ipv4_address": "xxx.xxx.xxx.xxx", # ---> ESXi Host Management Network IP Address "ipv4_subnet_mask": "xxx.xxx.xxx.xxx", "key": "key-vim.host.VirtualNic-vmk0", "mac": "xx:xx:xx:xx:xx:xx", "mtu": 1500, "portgroup": "Management Network", "stack": "defaultTcpipStack" }, { "device": "vmk1", "dhcp": false, "enable_ft": false, "enable_management": false, "enable_vmotion": true, "enable_vsan": false, "ipv4_address": "xxx.xxx.xxx.xxx", # ---> for vMotion vmkernel Network IP Address "ipv4_subnet_mask": "xxx.xxx.xxx.xxx", "key": "key-vim.host.VirtualNic-vmk1", "mac": "xx:xx:xx:xx:xx:xx", "mtu": 1500, "portgroup": "vmotion", "stack": "defaultTcpipStack" } ] } } } この３つを使うと ESXi の標準仮想スイッチのネットワークの情報かなり得られますね。 ここまででくれば十分ではないでしょうか。♬ 仮想マシン情報の取得 ついでにもう1つ。次回、Part 5 で利用予定の、仮想マシン情報についても取得してみましょう。 使うモジュールは vmware_guest_info で、 これ です。このモジュールを使うと、特定の仮想マシンの詳細情報が取得できます。似たモジュールに vmware_vm_info というのがあるのですが、こちらは個別の仮想マシン情報はほどほどに抑えて、仮想マシンの一覧を取得するモジュールです。 Playbook は こちら の中から factsGuest.yml を使います。 --- - name: Get VM Information hosts: all gather_facts: no tasks: - name: Show VM Infotmation vmware_guest_info: hostname: "{{lookup('env', 'VMWARE_HOST')}}" username: "{{lookup('env', 'VMWARE_USER')}}" password: "{{lookup('env', 'VMWARE_PASSWORD')}}" validate_certs: False datacenter: DC tags: yes name: "{{ vm_name }}" register: vm_facts - debug: var: vm_facts 実行結果は以下の通りです。仮想マシン名の変数には、Webserver-1 を入力して実行しています。 ok: [localhost] => { "vm_facts": { "ansible_facts": { "discovered_interpreter_python": "/usr/libexec/platform-python" }, "changed": false, "failed": false, "instance": { "annotation": "", "current_snapshot": null, "customvalues": {}, "guest_consolidation_needed": false, "guest_question": null, "guest_tools_status": "guestToolsRunning", "guest_tools_version": "10346", "hw_cluster": "CL", "hw_cores_per_socket": 1, "hw_datastores": [ "NFS" ], "hw_esxi_host": "xxx.xxx.xxx.xxx", # ---> ESXi IP Address "hw_eth0": { "addresstype": "assigned", "ipaddresses": [ "xxx.xxx.xxx.xxx", # ---> VM IPv4 Address "xxxx::xxxx:xxxx:xxxx:xxxx" # ---> VM IPv6 Address ], "label": "Network adapter 1", "macaddress": "xx:xx:xx:xx:xx:xx", "macaddress_dash": "xx-xx-xx-xx-xx-xx", "portgroup_key": null, "portgroup_portkey": null, "summary": "VM Network" }, "hw_files": [ "[NFS] Webserver-1/Webserver-1.vmx", "[NFS] Webserver-1/Webserver-1.nvram", "[NFS] Webserver-1/Webserver-1.vmsd", "[NFS] Webserver-1/vmware-3.log", "[NFS] Webserver-1/vmware-2.log", "[NFS] Webserver-1/vmware-1.log", "[NFS] Webserver-1/vmware.log", "[NFS] Webserver-1/Webserver-1.vmdk" ], "hw_folder": "/DC/vm", "hw_guest_full_name": "Red Hat Enterprise Linux 7 (64-bit)", "hw_guest_ha_state": null, "hw_guest_id": "rhel7_64Guest", "hw_interfaces": [ "eth0" ], "hw_is_template": false, "hw_memtotal_mb": 1024, "hw_name": "Webserver-1", "hw_power_status": "poweredOn", "hw_processor_count": 1, "hw_product_uuid": "423cba51-9668-0eb5-a156-191d252fd625", "hw_version": "vmx-13", "instance_uuid": "503cc8df-24b5-8019-77d9-cc6ae9ca08da", "ipv4": "xxx.xxx.xxx.xxx", "ipv6": null, "module_hw": true, "moid": "vm-3170", "snapshots": [], "tags": [ "New_VM" # ---> このタグ情報 Part 5 で使います！！ ], "vimref": "vim.VirtualMachine:vm-3170", "vnc": {} } } } 結構色々見えると思いませんか。♪ まとめ さて、Part 4 如何でしたでしょうか。お楽しみいただけましたでしょうか？今回は、vSphere 環境の中で良く質問をいただく、標準仮想スイッチと仮想マシンに関する情報を取得してみました。 info 系のモジュールは非常に充実してきていますので、上記したもの以外にも、分散仮想スイッチや、クラスター、データストア、仮想マシンのスナップショットなどなど様々な情報を取得する事が出来ます。さらに、この Info 系のモジュール、Playbook の書き方も、各モジュール間でほとんど違いがありません。 凄く良く似てますよね。基本は、 ・モジュール指定 ・オプションをいくつか指定 ・結果を変数に入れる ・表示 だけです。1つ Playbook を書くことができれば、他の Info 系のモジュールもすぐに応用できると思います。 とても簡単で分かりやすいと思いませんか？これが私が Ansible にハマっている理由の一つです。♬ さて、いよいよ次回は、一連のブログ、最終回・・・、の予定です。 仮想マシンの作成と仮想マシン内のアプリケーションの設定をやってみましょう！！ Ansible Tower のバイナリーと評価ライセンスは以下から取得可能です。是非使ってみてください！！ ・Ansible Tower バイナリーダウンロードは こちら から ・Ansible Towerの評価ライセンスは こちら から 　※Customer Portal のアカウント作成が必要です。 （2020年8月4日追記） 一連のブログが終了しましたので、各回に対するダイレクトのリンクを貼っておきます。 Part1 ：Ansible Tower で vSphere の何をどうやって自動化できるのか Part2 ：vSphere モジュールを使った Playbook の書き方とAnsible Tower での実行方法について Part3 ：Ansible Tower を使った ESXi ホストの自動構築とvMotion による確認 Part5 ：仮想マシンの作成とアプリケーションの構築・設定、ダイナミックインベントリの利用、仮想マシン情報（タグ情報）の取得について

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろです。 この記事は、Quarkus.io のブログ記事、 Mocking CDI beans in Quarkus の翻訳記事です。 Quarkusアプリケーションのテストは、Quarkus Developer Joyの重要な部分です。JVMアプリケーションをテストするための@QuarkusTestと、ネイティブイメージのブラックボックステストのための@NativeTestは、最初のリリース以来、Quarkusの一部となっています。しかし、私たちのコミュニティメンバーの間では、特定のテスト用に特定のCDI Beanを選択的にモックすることをQuarkusに許可してほしいという要望が何度もありました。この記事では、1.4 がもたらす新しいモッキング機能を紹介します。これらの関心事を解決することを目的としています。また、1.5 の一部となる追加の改善点を垣間見ることができます。 古いアプローチ Quarkusアプリケーションが以下の（純粋に考案された）Beanを含んでいると仮定してみましょう。 @ApplicationScoped public class OrderService { private final InvoiceService invoiceService; private final InvoiceNotificationService invoiceNotificationService; public OrderService(InvoiceService invoiceService, InvoiceNotificationService invoiceNotificationService) { this .invoiceService = invoiceService; this .invoiceNotificationService = invoiceNotificationService; } public Invoice generateSendInvoice(Long orderId) { final Invoice invoice = invoiceService.generateForOrder(orderId); if (invoice.isAlreadySent()) { invoiceNotificationService.sendInvoice(invoice); } else { invoiceNotificationService.notifyInvoiceAlreadySent(invoice); } return invoice; } } generateSendInvoiceメソッドをテストする際には、実際の通知を送信することになるので、実際のInvoiceNotificationServiceは使いたくないでしょう。以前のQuarkusのアプローチでは、テストソースに以下のBeanを追加することで、テストでInvoiceNotificationServiceを「オーバーライド」することができました。 @Mock public class MockInvoiceNotificationService implements InvoiceNotificationService { public void sendInvoice(Invoice invoice) { } public void notifyInvoiceAlreadySent(Invoice invoice) { } } Quarkusがこのコードをスキャンしたところ、@Mockを使用すると、InvoiceNotificationService Beanが注入された場所（CDI用語では注入ポイントと呼ばれています）のすべてで、MockInvoiceNotificationServiceがInvoiceNotificationServiceの実装として使用されることになりました。 このメカニズムは非常に使いやすいのですが、いくつかの問題点があります。 新しいクラス（または新しいCDIプロデューサメソッド）は、モックを必要とする各Beanタイプに使用する必要があります。多くのモックが必要とされる大規模なアプリケーションでは、定型コードの量が許容できないほど増えてしまいます。 モックが特定の試験にしか使えないなんてことはありえません。これは、@MockでアノテーションされたBeanが通常のCDI Beanであるという事実に起因しています（したがって、アプリケーション全体で使用されます）。テストの必要性にもよりますが、これは非常に問題があります。 JavaアプリケーションでのモッキングのデファクトスタンダードであるMockitoとの統合はありません。ユーザーは確かにMockitoを使用することができます（CDIのプロデューサーメソッドを使用することで最も一般的です）が、ボイラープレートコードが関与しています。 新しいアプローチ Quarkus 1.4以降、ユーザーは、io.quarkus.test.junit.QuarkusMockを使用して、通常のスコープ付きCDI Beanのテストごとのモックを作成して注入できるようになりました。さらに、QuarkusはMockitoとの統合を提供しており、io.quarkus.test.junit.mockito.@InjectMockアノテーションを使用してCDI Beanのモッキングをなんの労力なく行えます。 QuarkusMockの使用 QuarkusMockは通常のスコープ付きCDI Beanをモックするための基盤を提供します。それは@InjectMockによって内部でも使われています。まずはこれを検証してみましょう。一番良いのは、以下の例を使った方法です。 @QuarkusTest public class MockTestCase { @Inject MockableBean1 mockableBean1; @Inject MockableBean2 mockableBean2; @BeforeAll public static void setup() { MockableBean1 mock = Mockito.mock(MockableBean1. class ); ① Mockito.when(mock.greet( "Stuart" )).thenReturn( "A mock for Stuart" ); QuarkusMock.installMockForType(mock, MockableBean1. class ); ② } @Test public void testBeforeAll() { Assertions.assertEquals( "A mock for Stuart" , mockableBean1.greet( "Stuart" )); ③ Assertions.assertEquals( "Hello Stuart" , mockableBean2.greet( "Stuart" )); ④ } @Test public void testPerTestMock() { QuarkusMock.installMockForInstance( new BonjourMockableBean2(), mockableBean2); ⑤ Assertions.assertEquals( "A mock for Stuart" , mockableBean1.greet( "Stuart" )); ⑥ Assertions.assertEquals( "Bonjour Stuart" , mockableBean2.greet( "Stuart" )); ⑦ } @ApplicationScoped public static class MockableBean1 { public String greet(String name) { return "Hello " + name; } } @ApplicationScoped public static class MockableBean2 { public String greet(String name) { return "Hello " + name; } } public static class BonjourMockableBean2 extends MockableBean2 { @Override public String greet(String name) { return "Bonjour " + name; } } } ①この例の部分では、便宜上のためだけにMockitoを使用しています。QuarkusMockはMockitoとは何ら結びついていません。 ②注入されたBeanインスタンスがまだ利用できないので、QuarkusMock.installMockForType()を使用します。JUnit の @BeforeAll メソッドのモックの設定で特筆する非常に重要なことは、そのクラスのすべてのテストメソッドで使用されるということです (他のテストクラスはこの影響を受けません)。 ③MockableBean1用のモックは、そのクラスのすべてのテストメソッドに定義されていたものを使用されます。 ④MockableBean2にはモックが設定されていないので、CDI Beanが使用されます。 ⑤ここではQuarkusMock.installMockForInstance()を使用していますが、これはテストメソッドの中で注入されたBeanインスタンスが利用できるからです。 ⑥MockableBean1用のモックは、クラスのすべてのテストメソッドに定義されていたものを使用されます。 ⑦BonjourMockableBean2をモックMockableBean2として使用していたので、このクラスは使用されるようになりました。 QuarkusMockは、通常のスコープ付きCDI Bean のために使用されるでしょう - 最も一般的なものは@ApplicationScopedと@RequestScopedです。つまり、@Singletonや@Dependentスコープを持つBeanはQuarkusMockでは使えないということです。 さらに、QuarkusMockは、同じJVMで並列実行されるテストで使用すると、正しく動作しません。 ブログ記事の元の例に戻ると、MockInvoiceNotificationService クラスを削除して、代わりに以下のようなものを使用できます。 public class OrderServiceTest { @Inject OrderService orderService; @BeforeAll public static void setup() { MockableBean1 mock = Mockito.mock(InvoiceNotificationService. class ); Mockito.doNothing().when(mock).sendInvoice(any()); Mockito.doNothing().when(mock).notifyInvoiceAlreadySent(any()); QuarkusMock.installMockForType(mock, MockableBean1. class ); } public void testGenerateSendInvoice() { // perform some setup Invoice invoice = orderService.generateSendInvoice( 1L ); // perform some assertions } } この場合、InvoiceNotificationServiceを実装したクラスを新たに作成する必要はないことに注意してください。さらに、私たちはモックを完全に、そしてテストごとにコントロールすることができます。それはテストを書くときに、多くの柔軟性を与えてくれます。 例えば、実際のInvoiceNotificationServiceを使用したいテストがあった場合、そのテストではInvoiceNotificationServiceのモッキングを行わないようにします。 他のテストで InvoiceNotificationService を別の方法でモックする必要がある場合は、OrderServiceTest が使用しているのと同じメソッドを使用して、他のテストに問題を与えることなく、完全に自由に行うことができます。 最後に、上の例では InvoiceService をモックしていないので、OrderServiceTest で実際の InvoiceService が使用されていることに注意してください。 @InjectMockの使用 前のセクションで、旧来のアプローチよりもQuarkusMockのメリットを納得していただけたと思います。しかし、定型コードをさらに減らして、Mockito との統合をより強固にする方法はないかと思うかもしれません。そこで便利なのが@InjectMockです。 @InjectMockのデモをするために、前節のMockTestCaseを書き換えてみましょう。 まず、以下のような依存関係を追加する必要があります。 <dependency> <groupId> io.quarkus </groupId> <artifactId> quarkus-junit5-mockito </artifactId> <scope> test </scope> </dependency> これで、MockTestCaseをこのように書き換えることができるようになりました。 @QuarkusTest public class MockTestCase { @InjectMock MockableBean1 mockableBean1; ① @InjectMock MockableBean2 mockableBean2; @BeforeEach public void setup() { Mockito.when(mockableBean1.greet( "Stuart" )).thenReturn( "A mock for Stuart" ); ② } @Test public void firstTest() { Assertions.assertEquals( "A mock for Stuart" , mockableBean1.greet( "Stuart" )); Assertions.assertEquals( null , mockableBean2.greet( "Stuart" )); } @Test public void secondTest() { Mockito.when(mockableBean2.greet( "Stuart" )).thenReturn( "Bonjour Stuart" ); ③ Assertions.assertEquals( "A mock for Stuart" , mockableBean1.greet( "Stuart" )); Assertions.assertEquals( "Bonjour Stuart" , mockableBean2.greet( "Stuart" )); } @ApplicationScoped public static class MockableBean1 { public String greet(String name) { return "Hello " + name; } } @ApplicationScoped public static class MockableBean2 { public String greet(String name) { return "Hello " + name; } } } ①@InjectMockの結果、モックが作成され、テストクラスのすべてのテストメソッドで利用可能になります（他のテストクラスはこの影響を受けません） ②ここでは、クラスのすべてのテストメソッドに対してmockableBean1が設定されています。 ③このテストのためだけにmockableBean2を設定します。 @InjectMockは内部でQuarkusMockを使用しているため、同じ制限が適用されます。 さらに、@InjectMockはBeanのインジェクションポイントのように動作します。ターゲットBeanがCDI修飾子を使用しているときに正しく動作するためには、それらの修飾子もフィールドに追加する必要があります。次のセクションでは、@RestClient Beanをモックする例を見てみましょう。 最後の例として、OrderServiceTest テストを次のように書き換えることができます。 public class OrderServiceTest { @Inject private OrderService orderService; @InjectMock private InvoiceNotificationService invoiceNotificationService; @BeforeAll public static void setup() { doNothing().when(invoiceNotificationService).sendInvoice(any()); doNothing().when(invoiceNotificationService).notifyInvoiceAlreadySent(any()); } public void testGenerateSendInvoice() { // perform some setup Invoice invoice = orderService.generateSendInvoice( 1L ); // perform some assertions } } @RestClientで@InjectMockを使用します。 非常に一般的な要求は、@RestClientのBeanをモックすることです。ありがたいことに、それは@InjectMockによって十分にカバーされている必要があります - 以下の2つの原則が守られている限り。 Beanは@ApplicationScopedに作成されます。(@RegisterRestClientが暗示するデフォルトのスコープである@Dependentを受け入れる代わりに) テストにBeanを注入する際には、@RestClient CDI修飾子が使用されます。 いつものように、例はこれらの要件を最もよく示しています。Restクライアントを構築するために使用したいGreetingServiceがあるとします。 @Path( "/" ) @ApplicationScoped ① @RegisterRestClient public interface GreetingService { @GET @Path( "/hello" ) @Produces(MediaType.TEXT_PLAIN) String hello(); } ① GreetingServiceをモック可能にするためには、@ApplicationScopedを使用する必要があります。テストクラスの例としては、次のようなものが考えられます。 @QuarkusTest public class GreetingResourceTest { @InjectMock @RestClient ① GreetingService greetingService; @Test public void testHelloEndpoint() { Mockito.when(greetingService.hello()).thenReturn( "hello from mockito" ); given() .when().get( "/hello" ) .then() .statusCode( 200 ) .body(is( "hello from mockito" )); } } ① Quarkusはこの修飾子を使用してGreetingService Beanを作成するので、@RestClient CDI修飾子を使用する必要があります。 Quarkus 1.5のその他のモッキング Quarkus 1.5には新しいテストモジュール（quarkus-panache-mock）が同梱され、Panacheエンティティのモックが簡単にできるようになります。この機能がどのようなものなのか見てみたいと思っている方は、ぜひ これを チェックしてみて、早めのご意見をお聞かせください。

(注) 本記事は、 Software Design 2020年6月号 に掲載された「月刊Fedora Journal」初出の記事に修正を加えたものです。 Red Hat ソリューションアーキテクトの小島です。 Fedora系列の主要なLinux Distributionとしてよく名前が挙げられる、Fedora, CentOS, RHELに加えて、2019年9月に発表された新しいDistributionであるCentOS Streamの特徴や関係性をご紹介します。 Fedora系列の主要なLinux Distribution Fedora CentOS Stream CentOS Red Hat Enterprise Linux (RHEL) Red Hat Insights Red Hat Developer Program Red Hat Universal Base Images (UBI) まとめ Fedora系列の主要なLinux Distribution FedoraはRed HatがスポンサーをしているOSSコミュニティのプロジェクトで開発されている非商用のLinux Distributionであり、Red Hat Enterprise Linux (RHEL, 通称れる)はRed Hatが開発している商用のLinux Distributionです。さらに2019年9月には、RHEL 8.1などのRHELのマイナーリリースのローリングリリースに相当するCentOS Streamを提供開始することが、 Red HatとCentOS Projectから発表 されています。これら3つのLinux Distributionのリリースや開発プロセスの関係性を示すイメージは、下記となります。 Fedora/CentOS Stream/RHELのリリースのイメージ 引用元: CentOS Stream is Continuous Delivery - Stef Watler - 11 Dec, 2020 | Image licensed CC-BY-SA 4.0 Fedora/CentOS Stream/RHELの開発イメージ これらのLinux DistributionはUpstreamとして開発されている数多のOSSプロジェクトの成果物を直接的または間接的に取り込んでいるのと同時に、OSSのユーザや開発者の修正リクエストの受け皿ともなっています。修正リクエストをもとにUpstreamとなるOSSプロジェクトで適宜開発を行い、それらの成果物をDownstreamとなるOSSまたはDistributionに取り込んでいくといった開発サイクルを回しています。これらのDistrubitionは用途がそれぞれ異なるので、ユーザや開発者は自身のユースケースに応じて、どれを利用するか選択することになります。以降は、各Linux Distributionの特徴を紹介していきます。 Fedora FedoraはRHELのベースとして開発されている非商用のLInux Distributionであり、Red Hatが開発支援をしているFedora Projectによって開発・提供されています。元々Red HatがRed Hat Linux(リリース当初は Red Hat Software LinuxやRed Hat Commercial Linuxといった名前が付いていた こともあります)という名前で無料でダウンロード・利用可能なOSとして提供していたものを、商用のLinux DistributionとしてRHELをリリースする際に、当時大学生で元Red Hat社員でもあるWarren Togamiが設立した Fedora Linux Projectと、Red Hat Linux Projectをマージ してできたものがFedora Projectとなります。 Fedora Projectは、Upstreamで開発されている先進的な機能を開発・テストするためのプロジェクトとして位置づけられています。そのため、FedoraはRHELよりもソフトウェアのライフサイクルが短くなっています。例えば、Fedora 28はRHEL 8のベースとなっていますが、RHEL 8のkernelは4.18系を使っているのに対し、Fedora 28はFedora 29がリリースされるまでの間に4.16から4.18に、その次のFedora 29に至ってはFedora 30がリリースされるまでに4.18から5.0にバージョンアップしています。 Fedora Projectで開発・提供しているFedoraについては、ユースケースごとに用意された様々なEditionがあります。その中でも、FedoraのOfficial Editionとして位置づけられているものが、WorkstationとServerになります。 Workstation: ノートPCやデスクトップ用途に提供しているEditionです。GNOME、Libreoffice、開発ツールなど業務に利用するためのソフトウェアがデフォルトで組み込まれています。Live ISOファイルを提供しているためUSBデバイスなどを利用したインストールが比較的容易です。 Server: サーバー用途に提供しているEditionです。Webブラウザによるサーバ管理を可能にするCockpitやドメイン管理に利用するFreeipaなどのソフトウェアを提供しています。 WorkstationとServerについてですが、よく利用されるであろうx86_64版については、実は同じソフトウェアを利用できます。Fedora WorkstationではCockpitなどのサーバ管理ツールを利用できますし、Fedora ServerでもLibreofficeなどのオフィス製品を利用できます。実際にFedora Workstationをインストールした後に、OSの種類やバージョンを確認するためのファイルの中身を表示すると、WorkstationやServerといったEditionの情報は記載されていないことが分かります。 $ cat /etc/redhat-release Fedora release 31 (Thirty One) 便宜上WorkstationやServer用途と定義されたソフトウェアの導入をインストール時にカスタマイズしたい場合は、 Fedora Everything と呼ばれる全部盛りのEditionを利用するのもオススメです。Everythingでは、ネットワークインストール用に最小化されたサイズのISOファイルを提供しています。また、WorkstationとServerはARMv8(aarch64)版のソフトウェアも提供しているので、 Raspberry Pi 3へのインストール も可能です。 その他のEditionでは、Red Hatが提供するコンテナプラットフォームであるOpenShiftの専用OSとなる、RHEL CoreOSのベースとして開発されるFedora CoreOS、flatpakやrpm-ostreeという技術を用いてデスクトップ上でイミュータブルなインフラストラクチャを構築するためのFedora Silverblue、同じくrpm-ostreeを用いてAI/ML/IoT用途に特化したソフトウェア構成を提供するFedora IoTがあります。Fedora ProjectはこうしたFedora CoreOSやFedora IoTなど様々なFedoraのサブプロジェクトから構成されており、これらのサブプロジェクトの成果物の一部が後述するCentOS StreamやRHELとしてリリースされていきます。また、Fedora CoreOSとFedora Silverblueについては、2020年7月時点においてSoftware Designに連載中の「月刊Fedora Journal」の中で順次紹介する予定です。 fedoraproject.org Fedora ProjectによるFedoraのコミュニティサポートについてですが、Fedoraのメジャーリリースが提供されてから およそ13ヶ月の間メンテナンスを実施すると定義 しています。より正確に表現すると、Fedoraのメジャーリリースが出てから2つ後のメジャーリリースが出て1ヶ月経つと(例えば31の場合だと、33が出てから1ヶ月後)、ソフトウェアのアップデートを提供を止めてEnd of Life(EOL)を迎えます。ちなみに、Fedoraのメジャーリリースはおよそ半年に1回の頻度で提供される予定となります。メンテナンスが実施されている間は、 Fedora Projectで情報取得やディスカッションをしたり 、 Red Hat Bugzilla でソフトウェアの修正リクエストをしたり、 パッチのプルリクエストを行ったりする ことで、Fedora Projectのコミュニティに参加することができます。 CentOS Stream CentOS Streamは、RHELの将来のマイナーリリース *1 を想定した、RHELのNightlyビルドに相当するLinux Distributionとして、ローリングリリース方式で提供されます。2020年7月時点ではRHEL8のみが対象となります。なお、RHELのNightlyビルドといっても、 RHELのために開発・整備されている大量の品質保証テストをパスしたものだけがCentOS Streamとして提供 されており、RHELと同等の安定性を保つように努めています。 CentOS StreamもCentOSと同様に、CentOS Projectによって開発・提供される非商用のLInux Distributionです。CentOS Streamを提供することにより、RHELのPublic Betaがリリースされるより先に、将来のマイナーリリースに対してコミュニティのユーザや開発者が無料でアクセスできるようになっています。これは、Red HatによるIndependent Software Vendor (ISV)やIndependent Hardware Vendor (IHV)などに対してのソフトウェア/ハードウェア認定を取得しやすくなるような開発支援の1つとなります。CentOS StreamはFedoraやRHELと同様にRed Hat Bugzillaによりバグ追跡や修正リクエストを管理しますので、ISVやIHVがCentOS Streamを使って開発や自動テストを行った結果のフィードバックをBugzillaに登録し、Red Hatがそのフィードバックを適宜RHELに取り込んでRHELの最新のマイナーリリースとして提供する、といったエコシステムな開発モデルを構築しやすくなります。 CentOS Streamが誕生する前は、CentOS Projectを介してRHELに直接修正リクエストを投げる方法がなかったため、RHELのDownstreamであるCentOSで問題が見つかった場合、UpstreamであるOSSプロジェクトに修正依頼し、それを取り込んだRHELの修正が提供され、さらにそれをベースとしたCentOSの修正がリリースされるまで待たなくてはいけませんでした。CentOS Streamによって直接RHELに対して修正リクエストを投げるパスが増えたため、問題の修正対応が早くなるというメリットも生まれており、CentOS StreamではRHELに先行して修正が随時提供されていきます。そのため、ユーザが持っている継続的インテグレーション(Continuous Integration, CI)や継続的デプロイ(Continuous Deploy, CD)といった仕組みと組み合わせて、開発及び検証環境ではCentOS Streamを使ってシステム開発及び自動テストのサイクル(CI)を通して先行テストを行い、そこで得られた問題修正/機能拡張リクエストといったフィードバックを随時Bugzillaに登録して、そのフィードバックを基に修正されたRHELをステージング及び本番環境で使って自動テスト及び自動デプロイのサイクル(CD)を実施するといった、変化に強いシステムを作るなどのユースケースでも活用できるようになります。 CentOS Streamの詳細については、下記の記事もご参照ください。 rheb.hatenablog.com CentOS CentOS Projectが提供するCentOSは、全てのソフトウェアアップデートの提供を終了しました。 CentOSはCentOS Projectによって開発・提供される、GA版のRHELのソースコードをベースとした非商用のLinux Distributionです。CentOSは2004年に誕生して以来、CentOS Projectが独自に開発・提供してきましたが、OpenStackやKubernetes/OpenShiftなどのOSSコミュニティにRed Hatが提供する技術要素を利用してもらい、OSSコミュニティのイノベーションや開発速度を加速させることなどを目的として、2014年以降Red HatがCentOS Projectのスポンサーとなっています。なお、Red Hat BugzillaはCentOS用には利用できず、 CentOS Projectのメーリングリスト や CentOS Bug Tracker などを介して開発コミュニティに参加することになります。また、 CentOS StreamとCentOS、及び、CentOS StreamとCentOSのパッケージについては、Red Hatのサポートを提供していません。 このうちCentOSについては、ベースとなるRHELのメジャーリリースの標準サポート期間とほぼ同等の期間、CentOS Projectがコミュニティサポートを提供しています。RHELのメジャーリリース及びマイナーリリースの延長サポートに相当するアップデートの提供は行っていません。 2020年12月9日追記: CentOS Projectが 今後のCentOSリリースをCentOS Streamリリースに変更していくことを発表 しました。 CentOS ProjectがCentOS Stream1本に注力してUpstreamとの連携をより密に行うことで、Linuxのイノベーション推進及びエコシステム構築を加速させることを目的としています。これに伴い、CentOSの各メジャーリリース提供について下記のように変更されました。 CentOS 9: リリース予定はありません。 CentOS 8: ソフトウェアアップデート提供は2021年12月31日で終了しました。 CentOS 7: ソフトウェアアップデート提供は2024年6月30日で終了しました。 CentOS 6、及び、それ以前のメジャーリリース: ソフトウェアアップデート提供は既に終了しています。変更ありません。 現時点では、2024年7月以降はCentOSのどのメジャーリリースにおいてもソフトウェアアップデートを提供しなくなる予定のため、それ以降もCentOSユーザがCentOS Projectの提供するソフトウェアアップデートを適用したい場合は、CentOS Streamに移行する必要があります。ちなみに、CentOS 8では、CentOS上でCentOS Streamのリポジトリを利用できるように設定することで、CentOSをCentOS Streamに移行する手順が用意されています。この移行手順は、CentOS 7及びそれ以前のメジャーリリースは対象外です。 # dnf install centos-release-stream <- CentOS Streamのリポジトリを参照するためのリポジトリ情報をインストール # dnf swap centos-{linux,stream}-repos <- CentOSのリポジトリ情報を削除 # dnf distro-sync <- ↑で追加した、CentOS Streamのリポジトリで提供している最新のソフトウェアアップデートをインストール また、CentOS Streamの今後の提供については、下記を予定しています。CentOSのように、 CentOS Streamのメジャーリリースは個別にブランチを持つ 予定です。なお、CentOS Stream 11以降の予定はここでは記載していませんので、CentOS Projectの CentOS StreamのWebページ をご参照ください。 CentOS Stream 10: 2024年6月に プレビュー版の提供を開始 しました。 CentOS Stream 9: 2021年12月に提供を開始しました。 ソフトウェアアップデート提供はRHEL 9のFull Support期間に準拠しており、2027年5月31日に終了予定です。 CentOS Stream 8: 2019年9月に提供を開始しました。 ソフトウェアアップデート提供は RHEL 8のFull Support期間 に準拠しており、2024年5月31日で終了しました。 この発表に伴い、OSSプロジェクト/コミュニティ向けのオプションや、システム管理者の需要に対応するためのRed Hat Developer Subscription(開発用途に無償提供. 後述)のユースケースの拡張など、様々なユースケースを想定した無料または低価格のプログラムを2021年前半に導入する予定です。こちらについては詳細が決まり次第、追って発表する予定です。本発表に関する詳細なアナウンスやFAQは、下記もご参照ください。 centos.org www.redhat.com www.redhat.com Red Hat Enterprise Linux (RHEL) RHELはRed Hatが開発・提供している商用のLinux Distributionです。基本的には有償のRed Hatのサブスクリプションサービスを購入して、商用環境のOSとして利用することになります。RHELは1999年にリリースされたRed Hat Linux (RHL) 6.1を利用した、企業向けサポートプログラムの発表から始まり、RHL 7.2をベースとしたRHEL 2.1という名前で商用のLinuxとしてリリースしたのが起源になります。RHLはこの後もRHL 9までRed Hatが開発・提供していましたが、前述の通りFedora Linux Projectとマージされ、以降はRHELのUpstreamとしてFedoraという名前で開発 *2 されるようになりました。ちなみに、RHELはFeodraをベースとしていますが、独立して開発されています。Fedoraの特定のメジャーリリースをベースにしてRHELを公開したあとは、FedoraはFedoraで、RHELはRHELでそれぞれOSSコミュニティと連携しながら開発されます。なお、Fedora ProjectやCentOS Projectが提供する無償のコミュニティサポートと違う点は次の通りです。 SLAに基づく、最大24時間365日対応のRHELサポートを提供 特定のマイナー/メジャーリリースに対する延長サポートをオプションで提供 Red Hatのパートナー企業による認定ハードウェア/ソフトウェアのサポート ここで言及している「サポート」は大きくまとめると、ライフサイクル期間が終了していないRHELのインストール/設定/利用中に何か問題が起こった場合のワークアラウンドやソフトウェア修正を、電話/チャット/サポートケース/カスタマーポータルを介して提供することを意味します。なお、Red Hatがサポート対象外と定義しているいくつかのソフトウェアや構成、Technology Preview機能の利用、及び、ソフトウェアの改変/設計/開発についてはサポート対象外となります。 Red Hatはパートナー企業とエコシステムを構築しており、RHELの動作認定を取得しているハードウェア、または、RHELの上で動作認定を取得しているソフトウェアについては、提供元のパートナー企業がサポートを提供することが可能です。また、24時間365日対応の「Premium」サブスクリプションを購入すると、特定のマイナーリリースに対する延長サポート(Extended Update Support, EUS)が無償で提供される他に、深夜にRHELのkernelをアップデートするので不測の事態に備えておいてほしいといったリクエストをするための、 プロアクティブチケット(英語での対応のみ) を作成できるようになります。サポート内容についての詳細は、 Red Hatのカスタマーポータルに記載されているサポート範囲やサポートポリシー などのページをぜひ一度ご参照ください。 そして、パートナー企業とのエコシステムを強化するために、Red HatはRHELの互換性ポリシーを定義しています。特にRHELのメジャーリリース(RHEL 7やRHEL 8など)内でリリースされた全てのパッケージ更新について、アプリケーションバイナリ/構成ファイル/設定ファイルの互換性を維持するように努めています。そのため、特定のマイナーリリース(RHEL 8.2など)でRHEL上での動作認定を取得したサードパーティのソフトウェアについては、 それ以降のマイナーリリース(RHEL 8.3など)でも同様に動作認定を取得している ものとして扱います。また、RHELに含まれる一部のパッケージについては、複数のメジャーリリース(最大3つ)にわたってアプリケーションバイナリインタフェース(Application Binary Interface, ABI)の互換性を維持するように努めており、メジャーリリース間の移行を補助しています。こうしたRHELのアプリケーション互換性ポリシーの詳細については、下記もご参照ください。 access.redhat.com 続けて、RHELに関連する主要なサービスをいくつかご紹介します。 Red Hat Insights RHELの有償サブスクリプションを持っていると無料で利用できる、Red Hat InsightsというSaaS形態のサービスがあります。Red Hat InsightsはRHELを始めとするRed Hat製品の問題(RPMパッケージの脆弱性情報や設定情報の不備など)を未然に検知し、Red HatのWebサイト上で下記のようなHTMLベースのレポートを表示するサービスです。この問題を修正するためのAnsible PlaybookをInsights上で作ることもでき、Ansible Towerなどと連携して修正適応を自動化することもできます。Red Hat Insightsについては、 概要の紹介ページ や下記のブログ記事などもご参照ください。 Red Hat Insightsにより表示されるHTMLレポートのイメージ www.redhat.com Red Hat Developer Program 1ユーザ(複数人での共用は不可)、16台までの物理マシン/仮想マシンに利用できるという条件は付きますが、RHELの有償サブスクリプションの有無に関わらず、無償で提供しているRed Hat Developer Subscriptionというサブスクリプションもあります。こちらは個人で利用する場合に限り、利用用途は限定されません。Red Hat Developer Programに登録してRed Hat Developer Subscriptionを入手することで、 RHELを始めとした様々なソフトウェア を無料で入手して利用したり、Red Hatのカスタマーポータルのナレッジベースにアクセスして製品導入に関するノウハウを習得できるようになります。 developers.redhat.com Red Hat Universal Base Images (UBI) RHELをベースにしたコンテナイメージであるUniversal Base Images (UBI)を、RHELの有償サブスクリプションの有無に関わらず、無償で提供しています。UBIはRHEL7とRHEL8をベースとしたコンテナイメージとして提供しており、 UBIに関するEULA のもとに、UBIに独自ソフトウェアを追加して第3者へ配布できるため、Red HatがISVなどを支援する仕組みの1つとなっています。UBIを再配布する際には、Red Hat関連のソフトウェアについては、 UBI専用のリポジトリ によって提供されるソフトウェアだけをUBIに追加できるなどの制約がありますのでご注意ください。UBIは任意の環境で実行できますが、RHELやOpenShift環境の場合だと、コンテナの実行基盤からUBIの部分までRed Hatのサポート対象になります。そのため、UBIとRed Hat Developerの制度を利用すると、RHELを使った開発もしやすくなります。 UBIを始めとしたRHELの修正リクエストについては、Fedoraと同様にRed Hat Bugzillaで対応しています。有償のサブスクリプションを持っている場合、Red Hatのサポートチームを介してBugzillaにリクエストを登録できます。UBIの利用方法やQ&Aについては、以下の製品ドキュメントやRed Hat DeveloperのWebページをご参照ください。 access.redhat.com developers.redhat.com まとめ Red Hatが開発または開発支援をしている4つのLinux Distributionの特徴を紹介してきました。これらのLinux Distributionのうち、Fedora/CentOS Stream/RHELについてはRed Hatの「Upstream First」という開発ポリシーに準拠しているので、ユーザはRed Hatだけでなく世界中のOSSエンジニアの開発の恩恵を得ることができます。これらの特徴を考慮しながら、自身のユースケースに応じたLinux Distributionの利用をご検討ください。 *1 : RHEL8.xなどを意味します。2020年7月時点では、RHEL8.2を最新のマイナーリリースとして提供しているため、現時点で「x」に入る数字は少なくとも「3」以上の数字になります。 *2 : Fedora 6まではFedora Core, Fedora Extrasという2つのリポジトリがありましたが、7以降に統合されました。

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろです。 この記事は、Quarkus.io のブログ記事、 Introducing Command Mode の翻訳記事です。 コマンドラインアプリケーションからQuarkusの素晴らしいAPIとフル機能セットを使いたいと思ったことはありませんか？ 時々スケジュールされたバッチジョブを実行する必要があり、それをQuarkusが構築したメインのサービスに埋め込みたくなかったのでしょうか？ Quarkusはこれまでのところ、エンドポイントを介して実行されるアプリケーションを記述するために使用されています。これは、すなわち、HTTPを介して長く実行されるウェブサーバーや、サーバーレス環境で使われる短命な関数です。 Quarkus 1.4のコマンドモードでは、エンドポイントなしで実行し、オプションですぐに終了するアプリを書けます。 これにより、Quarkusを使用して、コマンドラインクライアント（CLI）、バッチスクリプト、コンソールアプリなど、まったく新しいスタイルのアプリケーションを書けます。 使用方法 以下は、すべてのクイックスタートの伝統的な GreetingService を使用したシンプルな GreetingMain クラスです。 import io.quarkus.runtime.QuarkusApplication; import io.quarkus.runtime.annotations.QuarkusMain; @QuarkusMain ① public class GreetingMain implements QuarkusApplication { @Inject ② GreetingService service; @Override public int run(String ... args) throws Exception { ③ if (args.length> 0 ) { System.out.println(service.greeting(arg[ 0 ])); } else { System.out.println(service.greeting( "" )); } return 0 ; } } ①QuarkusMainアノテーションは、これがメインのエントリーポイントであることをQuarkusに伝えます。 ②Quarkusが起動するとrunメソッドが一度呼び出され、終了するとアプリケーションが停止します。リクエストスコープされた Bean にアクセスしたい場合は、run メソッドに @ActivateRequestContext をアノテーションできます。これは、Hibernate Panache Entity beansのクエリメソッドなどを使用して、既存のビジネスロジックを書いたり、再利用したりするのに便利です。 これをGreetingMain.javaに追加して、.jarファイルまたは完全なネイティブ(mvnwパッケージ-Dnativeを使用)にコンパイルできます。 ./target/getting-started-command-mode-1.0-SNAPSHOT-runner commando __ ____ __ _____ ___ __ ____ ______ --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \ --\___\_\____/_/ |_/_/|_/_/|_|\____/___/ 2020-04-25 00:14:38,999 INFO [io.quarkus] (main) getting-started-command-mode 1.0-SNAPSHOT (powered by Quarkus 999-SNAPSHOT) started in 0.005s. 2020-04-25 00:14:38,999 INFO [io.quarkus] (main) Profile prod activated. 2020-04-25 00:14:38,999 INFO [io.quarkus] (main) Installed features: [cdi] hello commando 2020-04-25 00:14:38,999 INFO [io.quarkus] (main) getting-started-command-mode stopped in 0.000s クリーンな出力 CLIで作業する場合、デフォルトのコンソールログ出力は冗長なものになります。今のところ一番良い方法は、以下のプロパティを設定することでオフにします。 quarkus.log.level=SEVERE quarkus.hibernate-orm.log.sql=false quarkus.banner.enabled=false これらは、%cli.接頭辞を追加することで、cli と呼ばれるカスタム・プロファイルで設定できます。 これにはいくつかの問題があります。可能な解決策は課題 #8871 で議論されています。 開発モード コマンドモードは quarkus:dev 別名 dev モードで動作します。 mvn quarkus:devで実行する場合、コマンドラインに渡したい引数として-Dquarkus.args=任意の値 を追加できます。 quarkusargsはホワイトスペースで分割され、エスケープされた引用符を受け入れます。このように、mvn quarkus:dev -Dquarkus.args="foo bar \"baz qux\""とすると、アプリは開始し以下のように終了します。 foo bar baz qux Quarkus application exited with code 0 Press Enter to restart or Ctrl + C to quit Enterを複数回押して強制的に再実行できます。ソースコードを編集した場合は、Enterを押すとビルドが開始され、実際のオーバーヘッドなしで再起動されます。 mainメソッド QuarkusMain アノテーションクラスを介してコマンドモードを追加する一環として、独自のstatic void main() メソッドを持てます。以下のコードの断片は、main メソッドからQuarkusを実行するための最低限のものです。 static void main(String ... args) { Quarkus.run(args); } 上記の@QuarksMainクラスで使用するには、以下のようになります。 static void main(String ... args) { Quarkus.run(GreetingMain. class , args); } 以上です。これは、Quarkusアプリの起動/停止をカスタマイズするのではなく、多くの人が求めていたのは、IDEから直接Quarkusアプリを起動/デバッグする機能です。 これらのクラスの完全な動作例は、 コマンドモードのクイックスタート で見られます。 最小限のCLIアプリ CLI アプリがまだエンドポイントを提供していることは注目に値します - 実際、先ほど作ったようなデフォルトアプリは、REST エンドポイントはまだ起動して実行しています。気づかないだけです。Quarkus はそれほど速いのです。 本当に最小限の拡張が欲しい場合は、pom.xmlの中のquarkus-resteasy拡張を削除して、代わりにarcを入れます。 そうすると、あなたのQuarkusメインクラス以外は何も実行されません。 次は何をするの？ 私たちに教えてください！あなたはQuarkusのコマンドアプリを使って何をしたいですか？ 今のところはCLIを書くことを楽しんでいますが、他にどれだけの人が参加してくれますか！？ https://github.com/quarkusio/quarkus/issues でご意見をお聞かせください。

Red Hatのソリューションアーキテクトの森です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ミドルウェアラインナップが充実していることをご存知ですか？ ここでは、Red Hatのミドルウェアに関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は8月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1 : 運用業務の自動化最先端！Red Hatのミドルウェア群とAnsibleで実現する「運用高度化ソリューション」 Ansibleが非常に人気を集めているとおり、運用業務の自動化を推進する流れが加速しています。 サーバーやネットワーク設定の自動化は進んでも、その周辺にはまだまだ人手による判断や調整ごとが多く、運用現場は慢性的な人手不足となっています。 それらの人による作業を自動化し、作業効率と作業品質をアップするソリューションがこちらです。 speakerdeck.com 特集2 : COVID-19と闘う医療関係者を支援！OptaPlannerによる医療リソース最適化 ビジネスにおける最適化問題を解決するソリューションとして、Business Optimizerがあることをご存知でしょうか？ Business Optimizerは、Red Hat Decision Manager に含まれるAI制約ソルバーです。限られたリソース内で、様々な制約を満たしつつ、最良の結果を得たいというようなケースにおいて、どの組合せが最適かを現実的な時間で探索することができます。 以下の記事では、COVID-19に対処する医療関係者の勤務シフトを、Business Optimizer のコミュニティ版である Optaplanner を活用し、効率的にスケジューリングしたケースを紹介しています。 rheb.hatenablog.com 特集3 : オンデマンドで配信中！クラウドネイティブアプリ開発のためのウェビナー全6回をダイジェストで！ コンテナを含む新しい開発基盤でのソフトウェア開発、マイクロサービスやサーバーレスを用いたアプリケーションのクラウドネイティブ化、既存アプリケーションのモダナイゼーション、クラウドネイティブアプリケーションの開発と運用の価値を最大化するDevOpsなど、開発者が知るべきことは増えています。そしてその分、ITにもビジネスにも開発者の力がこれまで以上に求められています。 Red Hat Developer Webinar Seriesでは、クラウド時代に輝く開発者の方々へ、Red Hatから最新の技術動向やオープンソースソフトウェアを核とするRed Hatのソリューションまで、様々な情報をお届けします。 speakerdeck.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなったMiddleware製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat AMQ Broker 7.7 Red Hat AMQ Streams 1.5 Red Hat JBoss Enterprise Application Platform expansion pack 1.0 (EAP XP)

皆さま、こんにちは。Red Hatの西村( @iamnishipy )です。入社するまでDockerユーザーだった私が、わかりやすいと感じたPodmanの記事を共有いたします。 この記事は Red Hat Developer の Podman and Buildah for Docker users を、許可を受けて翻訳したものです。 ::: William Henry 2019年2月21日::: 最近Twitterにて、Dockerに詳しい人のために Podman と Buildah をよりよく説明してほしいと頼まれました。ブログやチュートリアル(後ほど紹介)はたくさんありますが、DockerユーザーがどのようにDockerからPodmanやBuildahに移行していくのかについて、私たちコミュニティから一元的な説明を行っていませんでした。Buildahはどのような役割を果たしているのでしょうか？Dockerを置き換えるために、PodmanとBuildahの両方が必要なほど、Podmanには何らかの欠陥があるのでしょうか？ この記事ではそれらの疑問に答え、Podmanへの移行方法を紹介します。 Dockerはどのように動くのか？ PodmanやBuildahを理解するために、まずDockerがどのように動作するのかを明確にしておきましょう。Dockerユーザーであれば、すべてのDockerコマンドを処理するために、デーモンプロセスを実行しなければならないことを理解していると思います。この背景にある動機を理解することはできませんが、当時はDockerが行うことすべてを一箇所で実施し、さらに将来の進化のためにそのプロセスに有用なAPIを提供するのが、素晴らしいアイデアに思えたのではないかと想像しています。下の図を見ると、Dockerデーモンが必要なすべての機能を提供していることがわかります。 イメージレジストリからイメージをプルおよびプッシュする ローカルコンテナストレージにイメージのコピーを作成し、それらのコンテナにレイヤーを追加する コンテナをコミットし、ホストリポジトリからローカルコンテナイメージを削除する カーネルに対して、正しい名前空間やcgroupなどを指定してコンテナを実行するように依頼する 基本的には、Dockerデーモンがレジストリ、イメージ、コンテナ、カーネルを利用したすべての作業を実施します。Dockerコマンドラインインターフェイス(CLI)は、あなたの代わりにこれを行うようデーモンに依頼します。 この記事では、Dockerデーモンプロセスの詳細な長所と短所については扱いません。このアプローチに賛成することは多くありますし、Dockerの初期の頃、このアプローチが多くの意味を持っていた理由もわかります。しかしDockerの利用が増えるにつれ、Dockerユーザーがこのアプローチを不安視する理由がいくつかあったことは、言うまでもありません。以下に、いくつか挙げておきます。 1つのプロセスが1つの障害点になる可能性がある このプロセスはすべての子プロセス(実行中のコンテナ)を所有する 障害が発生した場合、孤児(orphan)となるプロセスが存在する すべてのDockerの操作は、同一の完全なroot権限を持つユーザーによって行われなければならなかった この他にもあるでしょう。これらの問題が修正されたかどうか、この特徴付けに同意できないのかどうかは、この記事では議論の対象ではありません。私たちコミュニティは、Podmanがこれらの問題の多くを解決したと信じています。Podmanの改善点を活用したいのであれば、この記事が役立ちます。 Podmanのアプローチは、単純にイメージレジストリ、コンテナとイメージストレージ、そしてrunCコンテナランタイムプロセス(デーモンではありません)を介してLinuxカーネルと直接対話することです。 動機の一部を説明したところで、Podmanに移行するユーザーにとってそれが何を意味するのかを議論しましょう。 ここで取りあげることはいくつかあり、それぞれに個別に説明します。 Dockerの代わりにPodmanをインストールする Dockerでお馴染みのコマンドはPodmanでも同じように動作する PodmanはコンテナとイメージをDockerとは別の場所に保存する PodmanとDockerイメージは互換性がある Podmanは Kubernetes 環境のためにDockerよりも多くのこと行う Buildahとは何か、なぜ必要なのか？ Podmanのインストール 現在Dockerを使っているのであれば、移行しようと決めた時点でDockerを削除できます。しかし、Podmanを試している間はDockerを使い続けたいかもしれません。便利な チュートリアル と素晴らしい デモ があるので、移行をより理解するために最初に実行してみるといいでしょう。デモの例では、互換性を示すためにDockerを必要としています。 Red Hat Enterprise Linux 7.6以降にPodmanをインストールするには、以下のようにします。Fedoraを使用している場合は、 yum を dnf に置き換えてください。 # yum -y install podman PodmanコマンドはDockerコマンドと同じ Podmanを構築する際の目標は、Dockerユーザーが簡単に適応できるようにすることでした。そのため、おなじみのコマンドはすべてPodmanにも存在しています。実際、Dockerを実行する既存のスクリプトを持っていれば、 podman 用の docker エイリアス( alias docker=podman )を作成すれば、すべてのスクリプトが動作するはずです。もちろん、最初にDockerを停止( systemctl stop docker )しておく必要があります。podman-dockerというパッケージをインストールすれば、この変換を行ってくれます。 /usr/bin/docker のスクリプトをドロップし、同じ引数でPodmanを実行します。 あなたがよく知っているコマンド、例えば pull 、 push 、 build 、 run 、 commit 、 tag などはすべてPodmanに含まれています。詳細については、 Podmanのマニュアルページ を参照してください。特筆すべき違いは、Podmanが一部のコマンドにいくつかの便利なフラグを追加したことです。例えば、Podmanでは、 podman rm と podman rmi に --all ( -a )フラグが追加されています。便利だと感じるユーザーが多いはずです。 また、Fedora上のPodman 1.0では、通常の非rootユーザーからもPodmanを実行することができます。RHELのサポートはバージョン7.7と8.1以降を対象としています。ユーザースペースのセキュリティが強化されたことで、これが可能になりました。通常のユーザーとしてPodmanを実行すると、デフォルトではPodmanはイメージとコンテナをユーザーのホームディレクトリに保存します。これについては次のセクションで説明します。Podmanを非rootユーザーとして実行する方法の詳細については、Dan Walshさんの How does rootless Podman work? 1 をご覧ください。 Pormanとコンテナイメージ 最初に podman images と入力すると、すでにプルされているDockerイメージが表示されていないことに驚くかもしれません。これは、Podmanのローカルリポジトリが /var/lib/docker ではなく /var/lib/containers にあるからです。恣意的な変更ではなく、この新しいストレージ構造はOpen Containers Initiative(OCI)に準拠しています。 2015年、Docker、Red Hat、CoreOS、SUSE、GoogleなどのLinuxコンテナ業界のリーダーたちは、コンテナイメージとランタイムを定義するための標準仕様を管理する独立した組織をとして、Open Container Initiativeを設立しました。その独立性を維持するために、 containers/image プロジェクトと containers/storage プロジェクトが GitHub 上に作られました。 rootでなくても podman を実行できるため、 podman がイメージを書き込める別の場所が必要です。Podmanはユーザーのホームディレクトリにあるリポジトリを利用します。Podmanはユーザーのホームディレクトリにあるリポジトリ、つまり ~/.local/share/containers を利用します。これにより、 /var/lib/containers が誰でも書き込み可能になることや、潜在的なセキュリティ問題につながる可能性のあるその他の方法を回避できます。また、これにより、すべてのユーザーが別々のコンテナとイメージのセットを持ち、すべてのユーザーが同じホスト上で、お互いに干渉せずに同時にPodmanを使用できるようになります。ユーザーは作業が終わったら、共通のレジストリにプッシュしてイメージを他の人と共有することができます。 Podmanを使うようになったDockerユーザーは、これらの場所を知っていると、デバッグややり直したいときに重要な rm -rf /var/lib/containers を行う際に、便利だと気付きます。しかし、Podmanを使い始めると、おそらく podman rm と podman rmi に対して新しい --all オプションを代わりに使うでしょう。 コンテナイメージはPodmanと他のランタイムの間で互換性がある ローカルリポジトリの場所が新しくなったにも関わらず、DockerやPodmanで作成されたイメージはOCI標準と互換性があります。Podmanはプライベートレジストリだけでなく、 Quay.io やDocker hubのような一般的なコンテナレジストリへのプッシュやプルも可能です。例えば、Docker hubから最新のFedoraイメージをプルして、Podmanを使って実行することができます。レジストリを指定しないと、Podmanはデフォルトで registries.conf ファイルにリストされているレジストリを順番に検索することになります。 registries.conf ファイルが変更されていない場合は、最初にDocker hubを検索します。 $ podman pull fedora:latest $ podman run -it fedora bash Dockerでイメージレジストリにプッシュしたイメージは、Podmanでプルして実行することができます。以下の例のように、Dockerを使って作成したイメージ(myfedora)をDockerを使って Quay.ioのリポジトリ (ipbabble)にプッシュしたものは、以下のようにPodmanでプルして実行することができます。 $ podman pull quay.io/ipbabble/myfedora:latest $ podman run -it myfedora bash Podmanのコマンドラインでは、 push コマンドと pull コマンドで、イメージを /var/lib/docker から /var/lib/containers に、またはその逆に適切に移動させる機能を提供します。 例えば、次のようにできます。 $ podman push myfedora docker-daemon:myfedora:latest 上記の docker-daemon を除外すると、デフォルトでDocker hubにプッシュされます。 quay.io/myquayid/myfedora を使うと、イメージをQuay.ioレジストリにプッシュします。但し、 myquayid は、個人のQuay.ioアカウントです。 $ podman push myfedora quay.io/myquayid/myfedora:latest Dockerを削除する準備ができたら、デーモンをシャットダウンしてからパッケージマネージャを使ってDockerパッケージを削除してください。但し、Dockerで作成したイメージを保持しておきたい場合は、それらのイメージがレジストリにプッシュされていることを確認して、後でそれらをプルできるようにしておく必要があります。もしくは、Podmanを使って、ホストのDockerリポジトリからPodmanのOCIベースのリポジトリに各イメージ（例えばfeedora）を引っ張ってくることもできます。RHELでは以下のように実行できます。RHELでは以下のように実行できます。 # systemctl stop docker # podman pull docker-daemon:fedora:latest # yum -y remove docker # optional Podmanは、Kubernetesへの移行を支援する Podmanは、Kubernetes環境での開発者や運用者を支援するいくつかの追加機能を提供しています。これには、Dockerでは利用できないものが含まれます。Dockerに慣れ親しんでいて、コンテナプラットフォームとしてKubernetes/ OpenShift の使用を検討している場合、Podmanが役立ちます。 Podmanは、 podman generate kube を使用して実行中のコンテナに基づいてKubernetesのYAMLファイルを生成できます。 podman pod というコマンドは、標準のコンテナコマンドとともに、実行中のKubernetesポッドのデバッグを支援するのに役立ちます。PodmanがどのようにKubernetesへの移行を支援するかの詳細については、Brent Baudeさんの Podman can now ease the transition to Kubernetes and CRI-O を参照ください。 Buildahとは何か？なぜ使うのか？ 実はBuildahが先に出てきました。一部のDockerユーザーは少し混乱してしまうのは、そのためかも知れません。「なぜこのPodmanエバンジェリストたちもBuildahの話をしているんだろう？Podmanはビルドをしないのか？」 Podmanはビルドを行いますし、Dockerに詳しい人にとってはビルドのプロセスは同じです。 podman build を実行してDockerfileを使ってビルドするか、コンテナを実行して多くの変更を加え、その変更を新しいイメージタグにコミットするかのどちらかです。Buildahはコンテナイメージの作成と管理に関連したコマンドのスーパーセットと表現することができ、イメージに対してより細かい制御を行うことができます。Podmanの build コマンドにはBuildahの機能のサブセットが含まれています。ビルドにはBuildahと同じコードを使用します。 Buildahを使う最も強力な方法は、Dockerfileを書くのと同じようにイメージを作成するためのBashスクリプトを書くことです。 次のように進化したと考えるとよいです。KubernetesがOCIランタイム仕様に基づいた CRI-O に移行したときに、Dockerデーモンを実行する必要がありません。そのため、Kubernetesクラスタ内のどのホストについても、ポッドやコンテナを動かすためにDockerをインストールする必要がありませんでした。KubernetesはCRI-Oを呼び出すことができ、runCを直接呼び出すことができました。これにより、コンテナプロセスが起動します。しかし、OpenShiftクラスタを使う場合などで、同じKubernetesクラスタを使ってビルドを行う際に、Dockerデーモンを必要とせず、その後にDockerのインストールを必要としないビルド用の新しいツールが求められました。そのようなツールは、 containers/storage プロジェクトと containers/image プロジェクトをベースにしており、多くのユーザーが懸念していたビルド時のオープンなDockerデーモンソケットのセキュリティリスクも排除することができます。 Buildah(「builder」を発音するときのDan Walshさんのボストンアクセントが面白いからいう理由で名付けられた)は、この要望に合致しました。Buildahの詳細については buildah.io を参照し、特にブログやチュートリアルのセクションをご覧ください。 実務者がBuildahについて理解しておくべきことは、いくつかあります。 イメージレイヤーの作成をより細かく制御できるようになります。これは多くのコンテナユーザーが長い間求めていた機能です。1つのレイヤーに多くの変更をコミットすることが望ましいです。 Buildahの run コマンドは、Podmanの run コマンドとは異なります。Buildahはイメージをビルドするためのものなので、 run コマンドは基本的にDockerfileの RUN コマンドと同じです。実際、私はこれを明示されたときのことを覚えています。試していたポートやマウントが思ったように動かないと愚痴っていました。Danさん( @rhatdan )は、Buildahはそのような方法でのコンテナ実行をサポートすべきではないと意見を述べました。ポートマッピングもしないし、ボリュームマウントもありません。これらのフラグは削除されました。 代わりに buildah run はコンテナイメージの構築を支援するために特定のコマンドを実行するためのもので、例えば buildah run dnf -y install nginx のようになります。 buildah はゼロからイメージを構築することができます。ゼロからです。実際、 buildah from scratch コマンドの結果として作成されたコンテナストレージを見ると、空のディレクトリが表示されます。これは、アプリケーションを実行するために必要なパッケージだけを含む、非常に軽量なイメージを作成するのに便利です。 スクラッチビルドの良い使用例は、Javaアプリケーションの開発用イメージとステージング用イメージ、または本番用イメージを比較することです。開発中のJavaアプリケーションコンテナイメージは、JavaコンパイラやMavenなどのツールを必要とすることがあります。しかし、本番環境では、Javaランタイムとパッケージだけでいいかもしれません。ちなみに、DNF/YUMやBashなどのパッケージマネージャも必要ありません。Buildahはこのユースケースのための強力なCLIです。下の図を参照してください。詳しくは、 Building a Buildah Container Image for Kubernetes や、 こちらのBuildahのデモ を参照してください。 進化の話に戻ります。CRI-OとrunCでKubernetesのランタイム問題を解決し、Buildahでビルド問題を解決した今でも、Kubernetesホスト上でDockerがまだ必要とされている理由が1つありました。デバッグです。デバッグするためのツールがない場合、どうやってホスト上でコンテナの問題を確認できるでしょうか？Dockerをインストールする必要があれば、ホスト上でDockerデーモンを使用していた時のような状態に戻ってしまいます。しかし、Podmanはこの問題を解決します。 Podmanは2つの問題を解決するツールになります。運用者が使い慣れたコマンドで、コンテナやイメージを調べることを可能にします。そして、開発者にも同じツールを提供します。つまり、Dockerユーザーでも開発者でも運用者でも、Podmanに移行して、Dockerで慣れ親しんだ楽しいタスクをすべて行うことができ、さらに多くのことができるようになります。 結論 この記事が役に立ち、自信を持って無事にPodman(および Buildah)へ移行できることを願います。 より詳細な情報は、以下をご覧ください。 Podman.io プロジェクトと Buildah.io プロジェクトのWebサイト github.com/containers プロジェクト: 参加したり、ソースを入手したり、開発中のものを見たりできます libpod (Podman) buildah image : OCI コンテナイメージを扱うためのコード storage : ローカルイメージおよびコンテナストレージのためのコード 関連記事 Containers without daemons: Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta Podman: Managing pods and containers in a local container runtime Managing containerized system services with Podman : systemdを使って、Podmanのコンテナを管理する Building a Buildah Container Image for Kubernetes Podman can now ease the transition to Kubernetes and CRI-O Security Considerations for Container Runtimes : Dan WalshさんのKubeCon 2018での講演映像 IoT edge development and deployment with containers through OpenShift: Part 1 : podman、qemu、binfmt_misc、Ansibleを使ってOpenShift上でARM64コンテナを構築しテストする 日本語版の記事「 ルートレスのPodmanはどのように動作しますか？ 」もあります ↩