【2026年2月追記】最新の情報を元に内容をアップデートしました！ こんにちは、Red HatでOpenShift関連のプリセールスをしている北村です。 これまでのブログでは、Developer Hub(Backstage)の基本設定からSoftware Template機能を使ったセルフサービスのアプリデプロイなどを紹介してきました。今回は、TechDocsというBackstage標準のドキュメント管理機能を使って、ドキュメントを生成・公開する方法を解説していきます。 【第1回】Developer Hubをインストールしてみよう 【第2回】GitHubを使用した認証を実装しよう 【第3回】GitLabを使用した認証を実装しよう 【第4回】Componentを作成・登録しよう 【第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう 【第6回】TechDocsを作成・登録しよう ←この記事 【第7回】Golden Pathの実装をマスターしよう - 前編 【第8回】Golden Pathの実装をマスターしよう - 後編 TechDocsとは TechDocsは、Backstageが提供するドキュメント生成・公開機能です。MkDocsと呼ばれる静的サイト生成ツールをベースにしており、ソースコードリポジトリ内に含まれているMarkdownファイルからHTMLドキュメントをビルドしてDeveloper Hub上に表示します。 これを利用することで、開発者や運用者がドキュメントをコードと一緒に管理し、Developer Hubを通じて自動的に可視化する仕組みを簡単に構築できます。 TechDocsのユースケース TechDocsは一例として、以下のようなケースで活用することができます。 開発ガイドやAPI仕様の公開 アプリケーションやマイクロサービスに関する設計・仕様をMarkdownでまとめておき、Developer HubのTechDocsタブからいつでも閲覧できるようにする。 ライブラリやフレームワークの使用方法 社内で共通利用されているライブラリやプラグインの使い方をTechDocsとしてまとめ、継続的にバージョン管理する。 運用手順書やトラブルシュートガイド 手順書をMkDocsで管理し、変更点があればPull Requestでレビューしてドキュメントを更新、常に最新状態をキープする。 「ドキュメントの更新が追いつかない」という課題に悩まされがちな組織でも、TechDocsを活用することで、コードとドキュメントが同一リポジトリで管理され、変更の追跡がしやすくなります。 TechDocsの作成・登録手順 では早速TechDocsを作成し、Developer Hubから確認できるようにしていきましょう。 TechDocsのアーキテクチャー TechDocsは以下のような構成で提供されます。 事前準備として、TechDocsの生成・登録に必要なファイル群をSkeleton Repository内に作成します。 Software Templateを実行し、fetch:template処理を行います。 TechDocsの関連ファイルを含めてGitHubにPushします。 catalog-info.yamlをベースにComponent 画面が生成されます。 Sketeton Repositoryに格納していたworkflowファイルに基づき、GitHub Actionsが実行されます。 Actions内でMarkdownファイルからHTMLドキュメントをビルドし、S3へPushします。 S3に格納されたHTMLドキュメントに対して、Developer Hub側からアクセスします。 この処理を行うために、S3バケットの準備やDeveloper Hubの設定、TechDocs用ファイルの作成を行なっていきます。 S3の作成 まずはTechdocsの静的サイトを格納するためのS3バケットを作成します。 AWSのコンソールもしくは aws コマンドを使い、自分の環境にS3バケットを作成しましょう。 今回は rhdh-practice-techdocs というバケットを作りました。バケット名はアカウントやリージョンに依存せず全世界で一意である必要があるため、手元で作業する場合は別名を付与ください。なおコンソール上で作成する場合、設定はすべてデフォルトのままでOKです。 Developer Hubの設定 次にDeveloper HubにTechdocsを表示するための設定を行います。 S3バケットへのアクセス権をDeveloper Hub Podに付与する Techdocs用のバケットにアクセスするにあたってはAWSアクセスキーとシークレットキーを利用することもできますが、せっかくROSA上で稼働しているのでIAM Role for Service Accounts (IRSA) を使ってSTS認証を行います。 IAMポリシーの作成 まず、S3バケットへのアクセスを許可するIAMポリシーを作成します。以下のファイルを作成しましょう。 techdocs-s3-policy.json { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": [ " s3:PutObject ", " s3:GetObject ", " s3:DeleteObject ", " s3:ListBucket " ] , " Resource ": [ " arn:aws:s3:::<作成したTechdocs用のバケット名> ", " arn:aws:s3:::<作成したTechdocs用のバケット名>/* " ] } ] } 以下のコマンドでIAMポリシーを作成します。 aws iam create-policy --policy-name TechDocsS3Policy --policy-document file://techdocs-s3-policy.json IAMロールの作成 ROSAのDeveloper Hub Podが利用するIAMロールを作成し、 assume-role-policy をOpenShiftのServiceAccountに関連付けます。 **assume-role-policy.json { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " Federated ": " arn:aws:iam::<AWSアカウントID>:oidc-provider/<OIDCプロバイダー名> " } , " Action ": " sts:AssumeRoleWithWebIdentity ", " Condition ": { " StringEquals ": { " <OIDCプロバイダー名>:sub ": " system:serviceaccount:<Developer HubのNamespace>:rhdh-sa " } } } ] } OIDCプロバイダー名は以下のコマンドで取得できます。取得したURLから https:// を除いた部分がOIDCプロバイダー名になります。 oc get authentication.config.openshift.io cluster -o jsonpath = ' {.spec.serviceAccountIssuer} ' IAMロールを作成します。 aws iam create-role --role-name DeveloperHubTechDocsRole --assume-role-policy-document file://assume-role-policy.json 作成したIAMロールとIAMポリシーを紐づけます。 aws iam attach-role-policy --role-name DeveloperHubTechDocsRole --policy-arn arn:aws:iam:: < AWSアカウントID > :policy/TechDocsS3Policy OpenShiftのServiceAccountとIAMロールの紐付け ROSAで実行されるDeveloper Hub PodがIAMロールを利用するためにServiceAccountを作成し、IAMロールをアノテーションで紐付けます。 rhdh-sa.yaml apiVersion : v1 kind : ServiceAccount metadata : name : rhdh-sa namespace : rhdh annotations : eks.amazonaws.com/role-arn : "arn:aws:iam::<AWSアカウントID>:role/DeveloperHubTechDocsRole" oc apply -f rhdh-sa.yaml Developer Hub PodのServiceAccountの変更 第1回で作成した developer-hub.yaml を修正して、Podに割り当てるServiceAccountを変更します。 developer-hub.yaml apiVersion : rhdh.redhat.com/v1alpha2 kind : Backstage metadata : name : developer-hub namespace : rhdh spec : application : appConfig : configMaps : - name : app-config-rhdh mountPath : /opt/app-root/src extraEnvs : secrets : - name : secrets-rhdh replicas : 1 route : enabled : true dynamicPluginsConfigMapName : dynamic-plugins-rhdh database : enableLocalDb : true # ここから下を追記 deployment : patch : spec : template : spec : serviceAccountName : rhdh-sa デプロイしてPodを更新します。 oc apply -f developer-hub.yaml これでDeveloper Hub PodからS3バケットへのアクセスに必要な権限設定が完了しました。次に実際にTechDocsを読み込むための設定を行います。 Dynamic Pluginをインストールする そろそろ感覚が掴めて来たかと思いますが、新しい機能を使うならPluginをインストール。ということで、 dynamic-plugins-rhdh.yaml を変更していきます。 dynamic-plugins-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : dynamic-plugins-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : dynamic-plugins.yaml : | includes : - 'dynamic-plugins.default.yaml' plugins : # GitHub Plugins - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-github-dynamic disabled : false # GitLab Plugins - package : ./dynamic-plugins/dist/immobiliarelabs-backstage-plugin-gitlab disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-dynamic disabled : false - package : ./dynamic-plugins/dist/immobiliarelabs-backstage-plugin-gitlab-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-gitlab-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-org-dynamic disabled : false # Kubernetes Plugins - package : ./dynamic-plugins/dist/backstage-plugin-kubernetes-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-kubernetes disabled : false # OpenShift Plugins - package : ./dynamic-plugins/dist/backstage-community-plugin-topology disabled : false # ArgoCD Plugins - package : ./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-community-plugin-redhat-argocd disabled : false - package : ./dynamic-plugins/dist/roadiehq-scaffolder-backend-argocd-dynamic disabled : false # Techdocs Plugins - package : ./dynamic-plugins/dist/backstage-plugin-techdocs disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-techdocs-backend-dynamic disabled : false app-configを変更する app-config-rhdh.yaml に以下のような設定を追記します。 app-config-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : app-config-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : app-config-rhdh.yaml : | app : ...omit... backend : ...omit... auth : ...omit... integrations : ...omit... signInPage : github catalog : ...omit... enabled : kubernetes : true argocd : true techdocs : true # ここを追記 kubernetes : ...omit... argocd : ...omit... proxy : ...omit... # ここから下を追記 techdocs : builder : external publisher : type : awsS3 awsS3 : bucketName : ${TECHDOCS_BUCKET_NAME} region : ${AWS_REGION} techdocs.builder: external : TechDocs のビルド方法を指定します。 external はTechDocsのドキュメント生成をDeveloper Hub内部ではなく外部で実行する設定になります。今回はGitHub Action内で実行するため、 external を設定します。 techdocs.publisher.type: awsS3 : TechDocsの静的コンテンツをAWS S3に保存することを指定します。 techdocs.publisher.awsS3 : TechDocsの静的コンテンツが存在するバケット情報を指定します。 Secretを設定する 最後に必要な変数をSecretに設定していきます。 secrets-rhdh.yaml apiVersion : v1 kind : Secret metadata : name : secrets-rhdh namespace : rhdh stringData : ...omit... AWS_REGION : "<バケットのリージョン>" TECHDOCS_BUCKET_NAME : "<バケット名>" 3つのファイルの反映 変更した3つのファイルをデプロイします。 oc apply -f app-config-rhdh.yaml -f secrets-rhdh.yaml -f dynamic-plugins-rhdh.yaml これでTechDocsに関するDeveloper Hubの連携設定が完了しました。 GitHub ActionsでAWSにアクセスするための認証環境を構築する 次にGitHub ActionsのworkflowからAWS S3へHTMLファイルをPushするための認証環境を作ります。 まずはAWS IAMにGitHubのOIDC プロバイダーを登録します。ここの値はgithub.comであればそのままコピペしてしまってOKです。 aws iam create-open-id-connect-provider \ --url " https://token.actions.githubusercontent.com " \ --thumbprint-list " 6938fd4d98bab03faadb97b34396831e3780aea1 " " 1c58a3a8518e8759bf075b76b750d4f2df264fcd " \ --client-id-list " sts.amazonaws.com " IAMロールの作成 GitHub Actionsが AssumeRoleWithWebIdentity を実行できるように IAM ロールを作成します。 github-assume-role-policy.json { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " Federated ": " arn:aws:iam::<AWSアカウントID>:oidc-provider/token.actions.githubusercontent.com " } , " Action ": " sts:AssumeRoleWithWebIdentity ", " Condition ": { " StringLike ": { " token.actions.githubusercontent.com:sub ": " repo:<GitHubのOrganization名>/* " } } } ] } 上記のjsonを使ってIAM ロールを作成します。 aws iam create-role --role-name GitHubActionsTechDocsRole --assume-role-policy-document file://github-assume-role-policy.json IAMロールとIAMポリシーを紐づけます。ここで紐づけるIAMポリシーは、ROSA上のDeveloper Hubと同様 TechDocsS3Policy を使います。 aws iam attach-role-policy --role-name GitHubActionsTechDocsRole --policy-arn arn:aws:iam:: < AWSアカウントID > :policy/TechDocsS3Policy Skeleton Repoの準備 次にTechDocsの中身と、MarkdownファイルからHTMLドキュメントをビルドしS3へPushするためのworkflowファイルを作成します。 Skeleton Repoは前回作成した helloworld-skeleton を活用しましょう。 まずは以下のようにディレクトリを切っていきます。 mkdir -p manifest-skeleton/.github/workflows manifest-skeleton/docs 次にいくつかファイルを作成します。 mkdocs.yml ディレクトリ直下に mkdocs.yml を作成します。これはmkdocsの設定ファイルになっており、サイトの構成や外観を制御します。 今回はpluginsとしてtechdocs-coreを設定することを忘れずに行いましょう。 vi manifest-skeleton/mkdocs.yml site_name : ${{ values.app_name }} site_description : ${{ values.description }} repo_url : https://${{ values.git_host_url }}/${{ values.git_owner_name }}/${{ values.git_repo_name }} edit_uri : edit/main/docs plugins : - techdocs-core theme : name : material font : text : - "Arial" - "Helvetica" - "sans-serif" index.md 次にTechDocsの表示コンテンツとなる index.md を作成します。当たり前ですが、Markdown形式で内容を書きましょう。 vi manifest-skeleton/docs/index.md # ${{ values.app_name }} Hello World!!! tecdocs.yaml 最後に、MarkdownファイルからHTMLドキュメントをビルドしS3へPushするためのworkflowファイルを作成します。 techdocs-cli というコマンドを使い、サイトのビルドとS3へのPushを行います。 vi manifest-skeleton/.github/workflows/techdocs.yaml name : Publish TechDocs Site on : push : branches : - develop paths : - 'docs/**' - 'mkdocs.yml' workflow_dispatch : jobs : publish-techdocs-site : name : Publish techdocs site runs-on : ubuntu-latest permissions : id-token : write contents : read env : AWS_ACCOUNT_ID : ${{ "${{" }} secrets.AWS_ACCOUNT_ID }} TECHDOCS_S3_BUCKET_NAME : ${{ "${{" }} secrets.TECHDOCS_BUCKET_NAME }} AWS_REGION : ${{ "${{" }} secrets.AWS_REGION }} ENTITY_NAMESPACE : 'default' ENTITY_KIND : 'Component' ENTITY_NAME : ${{ values.app_name }} steps : - name : Checkout code uses : actions/checkout@v3 with : fetch-depth : 0 - name : Configure AWS Credentials uses : aws-actions/configure-aws-credentials@v3 with : role-to-assume : arn:aws:iam::${{ "${{" }} env.AWS_ACCOUNT_ID }}:role/GitHubActionsTechDocsRole role-session-name : GitHubActionsSession aws-region : ${{ "${{" }} env.AWS_REGION }} - name : Setup Node uses : actions/setup-node@v4 with : node-version : 'latest' - name : Setup Python uses : actions/setup-python@v4 with : python-version : '3.9' - name : Install techdocs-cli run : sudo npm install -g @techdocs/cli - name : Install mkdocs and mkdocs plugins run : python -m pip install mkdocs-techdocs-core==1.* - name : Generate docs site run : techdocs-cli generate --no-docker --verbose - name : Publish docs site run : techdocs-cli publish --publisher-type awsS3 --storage-name ${{ "${{" }} env.TECHDOCS_S3_BUCKET_NAME }} --entity ${{ "${{" }} env.ENTITY_NAMESPACE }}/${{ "${{" }} env.ENTITY_KIND }}/${{ "${{" }} env.ENTITY_NAME }} catalog-info.yaml 最後にtechdocsを画面に表示するための設定を catalog-info.yaml に行います。 annotations に1行追記します。 catalog-info.yaml apiVersion : backstage.io/v1alpha1 kind : Component metadata : name : ${{ values.app_name }} description : Hello Worldサービスです labels : app : ${{ values.app_name }} links : - url : https://${{ values.git_host_url }}/${{ values.git_owner_name }}/${{ values.git_repo_name }} title : App Repository icon : github annotations : backstage.io/kubernetes-label-selector : 'app=${{ values.app_name }}' backstage.io/kubernetes-namespace : ${{ values.app_name }} argocd/app-selector : app.kubernetes.io/instance=${{ values.app_name }}-init backstage.io/techdocs-ref : url:https://${{ values.git_host_url }}/${{ values.git_owner_name }}/${{ values.git_repo_name }} # ここを追記 spec : type : website owner : ${{ values.owner }} lifecycle : production この4つのファイルの作成・変更が完了したらGitにPushしておきます。 GitHub Actions用の変数を設定する 最後に、GItHub Actionsで利用する変数をOrganizationに設定します。 GitHub OrganizationのSettingsから Secrets and variables を選択し、New organization secretから各変数を入力していきます。 AWS_ACCOUNT_ID: 12桁のAWS ID TECHDOCS_BUCKET_NAME: s3のバケット名 AWS_REGION: バケットのリージョン 以上で設定は完了です。 Templateを実行してみる では実際にTechDocsが表示されるか確認してみましょう。 前回と同様に、Helloworld のテンプレートを実行してみて下さい。 するとComponentのタブに"Docs"が追加されているかと思います。 実際に開いてみると、index.mdの中身が視覚化されていることがわかります。 ちなみにこの環境では、index.mdを編集するとGitHub Actionsが実行され、再ビルド→S3へPushが行われます。これによりドキュメントもGitOpsで管理することができます。 おわりに 今回はTechDocsの作成と登録について解説しました。 次回はこれまでのノウハウをフル活用して、Software Templateをさらにブラッシュアップしてみます。乞うご期待！

【2026年2月追記】最新の情報を元に内容をアップデートしました！ こんにちは、Red HatでOpenShift関連のプリセールスをしている北村です。 これまでの記事では、Developer Hubのインストールから、GitHubやGitLabとの認証連携、さらに Component の登録方法について解説してきました。 今回はDeveloper Hub(Backstage)が提供するSoftware Template機能を使って、簡単なHello WorldアプリケーションをセルフサービスでOpenShiftにデプロイするまでの流れをご紹介します。 【第1回】Developer Hubをインストールしてみよう 【第2回】GitHubを使用した認証を実装しよう 【第3回】GitLabを使用した認証を実装しよう 【第4回】Componentを作成・登録しよう 【第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう ←この記事 【第6回】TechDocsを作成・登録しよう 【第7回】Golden Pathの実装をマスターしよう - 前編 【第8回】Golden Pathの実装をマスターしよう - 後編 Software Templateとは？ Software Template は、Backstageの Scaffolder 機能を通じて実装される仕組みで、Gitリポジトリの生成やアプリケーションのデプロイをセルフサービス化するための機能です。以下のような活用シーンがあります。 新規アプリケーションの立ち上げ：テンプレート化された Skeleton Repository やディレクトリ構成を自動生成して、プロジェクトごとの初期設定にかかる時間を削減する チーム標準の構成適用：Linterやテストの設定など、組織として共通化したい設定をテンプレートに含めておくことで、属人化を防止する DevOpsツールチェーンとの連携：CI/CD、デプロイ、監視など、社内既定のパイプライン設定を自動で組み込む Scaffolder はこのSoftware Templateを実行し、指定された手順どおりに「コード生成 → パラメータ置換 → GitリポジトリへのPush → デプロイ」などを行う“仕掛け”のことを指します。 また、テンプレートの定義自体は、template.yaml に記述し、Developer Hubに登録します。 Skeleton Repositoryとは？ Skeleton Repositoryとは、テンプレートのベースとなるソースコードを格納しているリポジトリを指します。 例えば、今回のように簡単なHello Worldアプリをデプロイするテンプレートでは、最低限のKubernetes/OpenShiftマニフェストやcatalog-info.yamlなどが入ったリポジトリが「Skeleton」となります。 ディレクトリ構成例 . ├── manifests │   ├── deployment.yaml │   ├── service.yaml │   ├── route.yaml │   ├── ... │   └── kustomization.yaml ├── catalog-info.yaml └── README.md Software Template機能では、このSkeleton Repoをテンプレート実行時に取得し、ユーザーが入力したアプリ名やGitHubリポジトリ名などのパラメータを差し替えることで、独自のリポジトリを生成する仕組みを提供します。 Scaffolderとは？ Scaffolder は、Developer Hub (Backstage) におけるジョブエンジンのような存在で、template.yamlに記述した様々な自動化のステップ を順番に実行します。 Scaffolderのステップで実行可能なジョブには例として以下のようなものが存在します。 fetch:template : Skeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入する publish:github : fetch:templateで作成したソースコードをユーザー指定の新しいGitHubリポジトリにPushする argocd:create-resources : 所定のGitリポジトリ及びBranchにおけるK8sマニフェストをデプロイするためのArgoCD Application CRをK8sにデプロイする catalog:register : Gitリポジトリ内のcatalog-info.yamlをDeveloper Hubに登録する Template実行手順 とりあえず概念を書いてみましたが、おそらく全然イメージが沸かないと思うので、実際にTemplateを作成・実行していきましょう。 今回実現すること 今回は以下のような仕組みを作っていきます。 利用者はDeveloper Hubの画面で必要なパラメータを入力してTemplateを実行する fetch:template StepでSkeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入する publish:github Stepで新しいGitHubリポジトリにPushする argocd:create-resources StepでHello worldアプリ用のK8sマニフェストをデプロイするための Application CRを作成する Application CRが新しいGitHubリポジトリ上のK8sマニフェストを検知してアプリをデプロイする なお今回デプロイするHello worldアプリは、あらかじめQuay.ioに準備されているコンテナイメージを使います。 ArgoCDを準備する Template作成の前に、ArgoCDそのものをOpenShift上にデプロイしていきます。 といってもデフォルトの設定のままOperatorをインストールするだけです。 Operator Hub から"OpenShift GitOps"と検索して、"Red Hat OpenShift GitOps"を選択します。特に設定も変えずにインストールしましょう。 正常にインストールできると、OperatorとともにArgoCDの本体となるCRが openshift-gitops というNamespaceにデプロイされます。 このArgoCDにログインするための admin ユーザーのパスワードが openshift-gitops-cluster というSecretに格納されているので、こちらの値を保存しておきます。このログイン情報は後ほどDeveloper Hubの設定に使用します。 次にArgoCDにアクセスするためのRouteのURLを確認します。こちらも後ほどDeveloper Hubの設定に使用するので保存しておきましょう。 実際にURLにアクセスして、 admin ユーザーでログインします。 ログイン後、開発者ツール（ChromeだとF12）を開いて、画面更新を行い一番上のリクエスト内にある argocd.token=ey... から始まるcookieの値を取得します。 あるいは以下のコマンドで該当の値を取得できます。 curl -sk -i \ -X POST \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"<adminのパスワード>"}' \ https://openshift-gitops-server-openshift-gitops.apps.rosa.<domain>/api/v1/session \ | grep 'argocd.token' \ | sed 's/^set-cookie: \(argocd\.token=[^;]*\).*/\1/' 最後に、ArgoCDのサービスアカウントに対してさまざまなリソースをデプロイするための権限を付与します。今回は cluster-admin を付与しておきます。 oc adm policy add-cluster-role-to-user cluster-admin -z openshift-gitops-argocd-application-controller -n openshift-gitops これでArgoCDの準備と、Developer Hubとの連携に必要な情報の取得が完了しました。 Developer HubとArgoCDを連携する 次にDeveloper HubとArgoCDを連携して、Scaffolderによって Application CRを実行するための準備を行います。ついでにArgoCDに関する画面をDeveloper Hubに表示するための準備も行います。 Dynamic Pluginをインストールする Developer Hubとの連携といえばPluginです。ArgoCDとの連携に必要な各種Pluginをインストールするために dynamic-plugins-rhdh.yaml を修正します。 dynamic-plugins-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : dynamic-plugins-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : dynamic-plugins.yaml : | includes : - 'dynamic-plugins.default.yaml' plugins : # GitHub Plugins - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-github-dynamic disabled : false # GitLab Plugins - package : ./dynamic-plugins/dist/immobiliarelabs-backstage-plugin-gitlab disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-dynamic disabled : false - package : ./dynamic-plugins/dist/immobiliarelabs-backstage-plugin-gitlab-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-gitlab-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-org-dynamic disabled : false # Kubernetes Plugins - package : ./dynamic-plugins/dist/backstage-plugin-kubernetes-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-kubernetes disabled : false # OpenShift Plugins - package : ./dynamic-plugins/dist/backstage-community-plugin-topology disabled : false # ArgoCD Plugins - package : ./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-community-plugin-redhat-argocd disabled : false - package : ./dynamic-plugins/dist/roadiehq-scaffolder-backend-argocd-dynamic disabled : false 今回インストールするPluginは以下の4つです。 backstage-plugin-scaffolder-backend-module-github-dynamic : GitHubへのScaffolder機能を提供する roadiehq-backstage-plugin-argo-cd-backend-dynamic : ArgoCDとのBackend連携を実現する backstage-community-plugin-redhat-argocd : ArgoCDに関するユーザー用画面を提供する roadiehq-scaffolder-backend-argocd-dynamic : ArgoCDへのScaffolder機能を提供する app-configを変更する app-config-rhdh.yaml に以下のような設定を追記します。 app-config-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : app-config-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : app-config-rhdh.yaml : | app : ...omit... backend : ...omit... auth : ...omit... integrations : ...omit... signInPage : github catalog : ...omit... enabled : kubernetes : true argocd : true # ここを追記 kubernetes : ...omit... # ここから下を追記 argocd : appLocatorMethods : - instances : - name : main password : ${ARGOCD_PASSWORD} url : ${ARGOCD_INSTANCE_URL} username : ${ARGOCD_USERNAME} type : config proxy : '/argocd/api' : target : ${ARGOCD_INSTANCE_URL}/api/v1/ changeOrigin : true secure : false headers : Cookie : $env : ${ARGOCD_AUTH_TOKEN} argocd セクションでは、連携するArgoCDの情報を記述します。見てもらうとわかるように、ArgoCDのURL、ユーザー、パスワードが必要になります。 proxy セクションとは、Developer Hubが外部サービス（ここではArgo CDのAPI）へアクセスするときのプロキシ設定を行う場所です。今回では、Argo CDのREST APIやgRPCエンドポイントに安全にリクエストを飛ばすために利用され、Cookie情報やArgoCDのAPI URLが求められます。 Secretを設定する 最後に、ArgoCD pluginの設定をapp-configに追記したので、必要な変数をSecretに設定していきます。 secrets-rhdh.yaml apiVersion : v1 kind : Secret metadata : name : secrets-rhdh namespace : rhdh stringData : ...omit... ARGOCD_INSTANCE_URL : "https://<ArgoCDのURL>" ARGOCD_USERNAME : "admin" ARGOCD_PASSWORD : "<ArgoCDのadminユーザーのパスワード>" ARGOCD_AUTH_TOKEN : "argocd.token=ey....." 3つのファイルの反映 変更した3つのファイルをデプロイします。 oc apply -f app-config-rhdh.yaml -f secrets-rhdh.yaml -f dynamic-plugins-rhdh.yaml これでArgoCDとの連携設定が完了しました。これでScaffolderの実行とArgoCD関連の画面生成ができるはずです。 Software Tempale機能を実行する では今回の本題に入りましょう。実際にSoftware Template機能を使ってみます。 template.yamlとSkeleton Repositoryを準備 まずはtemplate.yamlとSkeleton Repositoryを準備します。おさらいですが、今回は以下のステップを実行します。 利用者はDeveloper Hubの画面で必要なパラメータを入力してTemplateを実行する fetch:template StepでSkeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入する publish:github Stepで新しいGitHubリポジトリにPushする argocd:create-resources StepでHello worldアプリ用のK8sマニフェストをデプロイするための Application CRを作成する Application CRが新しいGitHubリポジトリ上のK8sマニフェストを検知してアプリをデプロイする ファイルがいくつか必要なので、今回は こちらのリポジトリ にソースコードを公開しました。まずはこちらから自身の環境にForkしてください。 Fork後、 template.yaml の spec.owner の部分だけ書き換えてください。 template.yaml apiVersion : scaffolder.backstage.io/v1beta3 kind : Template metadata : name : helloworld title : Hello world app description : シンプルなHelloWorldアプリをデプロイするためのテンプレート tags : - recommended spec : owner : user:default/skitamura7446 #ここを自分のDeveloper Hubユーザー名に書き換えてください。 type : website このリポジトリのディレクトリ構成は以下のようになっています。 . ├── README.md ├── manifest-skeleton │   ├── argocd │   │   └── application.yaml │   ├── catalog-info.yaml │   └── manifests │   ├── deployment.yaml │   ├── kustomization.yaml │   ├── route.yaml │   └── service.yaml └── template.yaml manifest-skeleton : このディレクトリ配下がSkeleton Repositoryとして fetch:template Stepでコピーされます。 argocd : Developer Hubから実行するArgoCDのApplication CR が格納されています。 catalog-info.yaml : このテンプレート実行によって登録する Component 情報が記載されています。 manifests : Hello worldアプリをデプロイするためのK8sマニフェストが格納されています。ArgoCD Applicationはこのディレクトリ配下をデプロイしにいきます。 template.yaml : 今回のテンプレートです。 テンプレートをDeveloper Hubに登録する template.yamlやSkeleton Repositoryの中身を見ていく前に、まず一旦このtemplate.yamlをDeveloper Hubに登録していきましょう。 前回の記事で画面上から手動で登録する手順を紹介しましたが、今回は app-config-rhdh.yaml にこのファイルの読み込み設定を行い、自動でこのテンプレートを登録する状態にしてみます。 以下の部分を追記してみましょう。 app-config-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : app-config-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : app-config-rhdh.yaml : | app : ...omit... backend : ...omit... auth : ...omit... integrations : ...omit... signInPage : github catalog : providers : ...omit... # ここから下を追記 locations : - type : url target : https://github.com/<GitHub Organization名>/helloworld-skeleton/blob/main/template.yaml # 先ほど作成→Pushしたtempalte.yamlを指定 schedule : frequency : PT60S initialDelay : PT30S timeout : PT120S # ここまで これを適用します。 oc apply -f app-config-rhdh.yaml しばらくするとDeveloper Hubが立ち上がり、テンプレートが登録されていることを確認できます。 テンプレートを実行する このままテンプレートの実行までしていきましょう。画面とtemplate.yamlを見比べながら理解を深めていきます。 この画面に表示されている情報は、template.yamlの以下の部分です。 template.yaml(抜粋) apiVersion : scaffolder.backstage.io/v1beta3 kind : Template metadata : name : helloworld title : Hello world app description : シンプルなHelloWorldアプリをデプロイするためのテンプレート tags : - recommended spec : owner : user:default/<Developer Hubにログイン中のユーザー名> type : website metadata.name : このテンプレートの名前です。画面には反映されませんが、URLのPathとして使われます。 metadata.title : このテンプレートのタイトルです。画面ではこちらがテンプレート名になります。 metadata.description : このテンプレートの説明です。こちらも画面で確認できます。 metadata.tags : このテンプレートを検索する際に活用できるキーワードを設定します。 spec.owner : このテンプレートの管理者の名前です。 type : このテンプレートの属性を定義できます。 次に"Choose"を選択して中身とtemplate.yamlを見比べてみましょう。 最初の画面は以下の通りです。 この画面を構成しているのはtemplate.yamlの以下の部分です。 template.yaml(抜粋) parameters : - title : 作成するComponentの情報 required : - app_name - owner properties : app_name : title : アプリケーション名 description : 作成するアプリ名を指定してください。 type : string default : "helloworld" owner : title : オーナー type : string description : 作成するComponentのオーナーを選択してください。 ui:field : OwnerPicker ui:options : catalogFilter : kind : - Group - User title : Stepごとの入力画面のタイトルになります。 required : この入力画面で必須項目となるパラメータkeyを指定します。 properties.xxx : properties配下に入力項目を並べていきます。xxxの部分がパラメータkeyになります。 xxx.title : 画面に表示するパラメータ名です。 xxx.type : パラメータの型を定義します。 xxx.description : このパラメータの説明です。こちらは画面に表示されるため、パラメータの補足として利用します。 xxx.default : このパラメータのデフォルト値です。 上記までが一般的な記述内容になります。一方で、例えばすでにDeveloper Hubに登録済みのパラメータ(GroupやUser、Systemなど)を参照してプルダウン形式で選択させたい場合は、 ui:field: と ui:options: を活用します。 xxx.ui:field : EntityPicker OwnerPicker RepoUrlPickerの3種類から選択できます。それぞれパラメータの属性に応じて適切なものを選択します。詳細は こちら を参照下さい。 xxx.ui:field.OwnerPicker.catalogFilter : ここでプルダウンで表示させる値をフィルタリングしています。ownerの場合はDeveloper Hub内に登録してあるGroupとUserがここに表示されることになります。 次の画面は以下になります。 この画面を構成しているのはtemplate.yamlの以下の部分です。 template.yaml(抜粋) - title : GitHubリポジトリの情報 required : - git_repo_name - git_host_url - git_owner_name properties : git_repo_name : title : GitHubリポジトリ名 description : 生成するGitHubリポジトリ名を入力してください。 type : string default : helloworld git_host_url : title : GitHub URL description : GitHubリポジトリのURLを入力してください。 type : string default : github.com git_owner_name : title : GitHub Organization名 description : GitHubリポジトリを生成するGitHub Organization名を入力してください。 type : string default : rhdh-practice ここは画面とyamlファイルの中身がある程度リンクしていることがわかります。 入力する値は自身の環境に合わせて適宜修正してください。（githubのURLやOrganization名など） では実際に実行してみましょう。 実行すると画面のように各Stepが実行されます。 "Componentを開く"を選択すると、無事にComponentも登録されていることがわかります。 また、Links の App Repository を選択すると、テンプレート実行によって新規作成されたGitリポジトリにアクセスすることができます。 template.yamlとSkeleton Repositoryを読み解く では、画面入力後から実行まで、なにが起こったのかを確認していきましょう。 template.yamlの中身をもう少し見てみると、以下のように steps から始まる記述があります。 template.yaml(抜粋) steps : - id : fetch name : Fetch skeleton action : fetch:template input : url : ./manifest-skeleton values : app_name : ${{ parameters.app_name }} owner : ${{ parameters.owner }} git_repo_name : ${{ parameters.git_repo_name }} git_host_url : ${{ parameters.git_host_url }} git_owner_name : ${{ parameters.git_owner_name }} targetPath : ./tenant stepsでは、テンプレートの実行部分を記述します。このstepsはリスト形式で各処理を記述していき、その順番通りに実行されていきます。その実行される内容を指定しているのがactionになります。 たとえば、今回のテンプレートでは最初に fetch:template というactionを実行します。 この fetch:template では、先述した通りSkeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入します。 上記のコードを見てみると、 app_name: ${{ parameters.app_name }} というように、 parameters でユーザーから入力された値を変数に格納していることがわかります。今回では、 app_name や git_repo_name といった変数に対して、Developer Hubの画面で入力された値を代入していることになります。 ではこの格納された変数はどのようにskeletonファイルに反映されるのでしょうか？ ここで manifest-skeleton/manifests 配下にある deployment.yaml を見てみましょう。 deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : labels : app : ${{ values.app_name }} name : ${{ values.app_name }} spec : replicas : 1 selector : matchLabels : app : ${{ values.app_name }} template : metadata : labels : app : ${{ values.app_name }} spec : containers : - image : quay.io/skitamur/hello-world:latest name : ${{ values.app_name }} ports : - containerPort : 3000 protocol : TCP これは、Hello worldアプリをPodとしてデプロイするためのdeploymentのyamlファイルです。 例えばこれの metadata.name を見てみましょう。値が ${{ values.app_name }} となっています。このように、fetch:templateで渡された変数の値は、 ${{ values.app_name }} のように記述されたところに代入されていきます。 今回で言うと、Developer HubのTemplate実行画面の"アプリケーション名"に入力した値が deployment.yaml の metadata.name に反映されることになります。 イメージとしては以下になります。 そのほかのパラメータについては以下のとおりです。 input.url : 取得するテンプレートの相対パスになります。このtemplate.yamlはhelloworld-skeletonリポジトリ直下にあるため、そこからの相対パスとして./manifest-skeletonを指定しています。 input.values : この値が変数に代入するパラメータになります。 input.targetPath : これはローカル（Developer Hun Pod内）のワークスペースを指定します。ディレクトリがなければ/tmp配下に作成されます。今回は tenant ディレクトリに manifest-skeleton 配下のファイル群を一時的に格納します。 次のstepでは、変数を代入したファイル群を新しいGitリポジトリとしてPushするactionを実行しています。 template.yaml(抜粋) - id : publish name : Push to GitHub action : publish:github input : repoUrl : ${{ parameters.git_host_url }}?owner=${{ parameters.git_owner_name }} &repo=$ {{ parameters.git_repo_name }} repoVisibility : public sourcePath : ./tenant defaultBranch : develop protectDefaultBranch : false input.repoUrl : Pushする先のGitHubのURLです。これでPushできるOrganizationは以前の記事で連携設定を行ったOrganizationに限られます。 input.repoVisibility : GitHubのリポジトリの公開設定です。PublicかPrivateを設定できます。 input.sourcePath : GitHubにPushするデータが格納されているパスを指定します。ここでは前の fetch:template actionでskeletonから取得＆変数代入を行った ./tenant を指定します。 input.defaultBranch : Pushする際のデフォルトのBranchになります。今回はdevelopをデフォルトのブランチとしています。 input.protectDefaultBranch : GitHubはデフォルトブランチが保護されています。今回はfalseにしています。 イメージは以下の通りです。 その次はargoCDのApplication CRをデプロイするActionです。 template.yaml(抜粋) - id : argocd name : Deploy with ArgoCD action : argocd:create-resources input : appName : ${{ parameters.app_name }}-init argoInstance : main namespace : openshift-gitops repoUrl : https://${{ parameters.git_host_url }}/${{ parameters.git_owner_name }}/${{ parameters.git_repo_name }}.git path : 'argocd/' input.appName : このactionによってデプロイするArgoCDのApplication名です。 input.argoInstance : これはapp-configで設定したArgoCD instanceのNameを記述します。今回は main となります。 input.namespace : Applicationのデプロイ先のNamespaceです。 input.repoUrl : GitOpsの参照先となるGitのURLです。 input.path : GitのURLにおけるサブディレクトリを指定します。 ここを読み解くと、新しく作成(Push)されたリポジトリの argocd ディレクトリ配下のK8sマニフェストをターゲットとしてGitOpsが行われることが分かります。 ここで鋭い人は、「なんで直接 manifests 配下のK8sマニフェストを対象にしないの？」と思うかもしれません。 実際はそれでも動く時はありますが、このDeveloper Hubから実行可能な argocd:create-resources actionでは、作成されるApplication CRの設定がかなり制限されます。Application名やターゲットパス以外のパラメータはほぼ変更できず、全てデフォルト値でデプロイされてしまいます。 そこで、「Application CRからApplication CRをデプロイする」という手法を使うことで、アプリ自体のGitOpsをする際の設定を細かく行えるようにしています。この階層構造でのデプロイを一般的に" App of apps pattern "と言います。なお、細かい設定の例として、例えば CreateNamespace=true や AutoSync などがあります。 ともあれこれによってアプリの自動デプロイまでが完了しました。 最後は、作成されたGitリポジトリ配下にある catalog-info.yaml をDeveloper Hubに登録するactionです。 template.yaml(抜粋) - id : register name : Register Catalog into Developer Hub action : catalog:register input : repoContentsUrl : ${{ steps['publish'].output.repoContentsUrl }} catalogInfoPath : "/catalog-info.yaml" この catalog:register では、 repoContentsUrl と catalogInfoPath で指定されたファイルをDeveloper Hubに登録します。 catalog-info.yaml は前回の記事の内容も参考にしながら、以下のような内容になっています。 catalog-info.yaml apiVersion : backstage.io/v1alpha1 kind : Component metadata : name : ${{ values.app_name }} description : Hello Worldサービスです labels : app : ${{ values.app_name }} links : - url : https://${{ values.git_host_url }}/${{ values.git_owner_name }}/${{ values.git_repo_name }} title : App Repository icon : github annotations : backstage.io/kubernetes-label-selector : 'app=${{ values.app_name }}' backstage.io/kubernetes-namespace : ${{ values.app_name }} argocd/app-selector : app.kubernetes.io/instance=${{ values.app_name }}-init spec : type : website owner : ${{ values.owner }} lifecycle : production 一点新たにannotationsに argocd/app-selector: app.kubernetes.io/instance=${{ values.app_name }}-init を追加しています。これを記載することで、 app.kubernetes.io/instance=${{ values.app_name }}-init のlabelを持つArgoCDのApplication情報をこのComponentに表示できるようになります。 Component画面を確認する 最後に今回作成されたアプリのComponent画面を確認してみましょう。 Topology タブに移動すると、実際にPodが稼働していることが確認できます。 アイコン右上の"Open URL"にアクセスして、 Hello world! が表示されることを確認しましょう。 また、新たに増えた CD タブに移動してみると、今回デプロイされたArgoCDの情報が確認できます。リンクを選択することでArgoCDの画面にも遷移できます。 おわりに 今回はSoftware Template機能の基本的な概念と、template.yamlやSkeleton Repositoryの記述方法、そして実行方法について解説しました。 次回はTechdocs機能について触れていきます。乞うご期待！

【2026年2月追記】最新の情報を元に内容をアップデートしました！ こんにちは、Red HatでOpenShift関連のプリセールスをしている北村です。 これまでGitHubやGitLabの認証連携を進めてきたことで、Developer Hubにアクセスできる状態になったかと思います。 今回はDeveloper Hubに Component を登録し、その表示を確認していこうと思います。 Component はDeveloper HubのEntityのひとつで、アプリケーションやマイクロサービス、さらには社内のツールやサービスなど、開発者ポータルで管理したい要素を表すものです。この記事では、 Component の基本的な概念から、実際にDeveloper Hubに登録する手順、そしてどのように画面に表示されるかについて深堀りしていきます。 なおこれ以降の記事では、ソースコードリポジトリとして"GitHub"を前提とします。そのため、本記事は 【第2回】GitHubを使用した認証を実装しよう の手順が完了していることを前提としています。 【第1回】Developer Hubをインストールしてみよう 【第2回】GitHubを使用した認証を実装しよう 【第3回】GitLabを使用した認証を実装しよう 【第4回】Componentを作成・登録しよう ←この記事 【第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう 【第6回】TechDocsを作成・登録しよう 【第7回】Golden Pathの実装をマスターしよう - 前編 【第8回】Golden Pathの実装をマスターしよう - 後編 Componentとは？ まず Component の基本概念を押さえておきましょう。Developer Hubでの Component とは、開発チームが扱うあらゆるリソースを指します。具体的には、次のようなものが該当します アプリケーション：内部で利用しているアプリケーションやツール マイクロサービス：社内で稼働している個別のサービス ライブラリ：他のアプリケーションで利用されるライブラリやコンポーネント これらを Component として登録することで、Developer Hub内で一元的に管理できるようになります。開発者や運用担当者は、 Component を簡単に検索・表示し、管理することができるようになります。 とはいえ百聞は一見にしかず、早速実機で確認してみましょう。 Componentを作成・登録してみよう それでは、実際に Component をDeveloper Hubに登録する手順を見ていきましょう。 yamlファイルの作成 Component を登録するためには、まずyamlファイルを作成する必要があります。このyamlファイルに Component に関する情報を記述します。次の例では、社内で運用している example-service というサービスを登録するためのyamlファイルを作成しています。 catalog-info.yaml apiVersion : backstage.io/v1alpha1 kind : Component metadata : name : example-service description : デモンストレーション用のサービスです labels : app : example spec : type : website owner : user:default/<githubのuser名> lifecycle : production metadata.name : Componentの名前です。 metadata.description : Componentの簡単な説明です。 spec.type : このComponentの種類を指定します。APIなどのアプリは service 、webアプリは website 、npmモジュールやJavaライブラリは library を設定することが一般的です。 spec.owner : このComponentを管理するチームの名前です。ここではuser:default/<githubのuser名>を登録してください。 spec.lifecycle : Componentのライフサイクルを指定します。例えば production や development など。 GitHubやGitLabへの登録 作成したyamlファイルをGitHubやGitLabのリポジトリに保存します。今回はGitHubに以下のようなリポジトリを作成し、yamlファイルを格納しました。 Developer Hubへの登録 では作成したyamlファイルを登録してみます。 Developer Hubの画面右上部にある ＋アイコン "Self-service" を選択します。 "Register Exsisting Component" を選択します。 Select URLで、yamlファイルのURLを記入し"Analyze"を選択します。 Importを選択します。 View Componentを選択します。 無事に Component の登録が完了しました。 見てもらうとわかる通り、yamlファイルに記載した内容が反映されています。 しかしこのレベルの記述では、 ただそのアプリが存在することがわかるだけ にとどまってしまいます。 もう少しこの Componert を編集してみて実用的にしていきましょう。 もっと実用的なComponentを作成してみよう 今回は、事前にOpenShiftにサンプルアプリをデプロイしてみて、それを管理するための Component を作成してみます。 サンプルアプリをデプロイする Componentの挙動を確認するために、まずはサンプルアプリをデプロイしていきましょう。 今回は こちらのSample Blogアプリ を利用します。自分のGitHub OrgにForkして、 README.md を参考にデプロイしてください。 Dynamic Pluginをインストールする デプロイされたSample Blogを Component に登録するにあたり、便利なPluginをいくつかインストールしてみます。 dynamic-plugins-rhdh.yaml を以下のように修正してみましょう。 dynamic-plugins-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : dynamic-plugins-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : dynamic-plugins.yaml : | includes : - 'dynamic-plugins.default.yaml' plugins : # GitHub Plugins ...omit... # GitLab Plugins ...omit... # ここから下を追記 # Kubernetes Plugins - package : ./dynamic-plugins/dist/backstage-plugin-kubernetes-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-kubernetes disabled : false # OpenShift Plugins - package : ./dynamic-plugins/dist/backstage-community-plugin-topology disabled : false ここでは、Topology Pluginと、Kubernetes Plugin×2をインストールしています。この3つのプラグインは、 Component 画面にOpenShift環境のコンテナ情報を可視化する機能を提供します。Kubernetes Pluginの2つはそれぞれ Component 画面の描写用と、Kubernetesからの情報取得(Backend)用になります。 app-configを変更する app-config-rhdh.yaml に以下のような設定を追記します。 app-config-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : app-config-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : app-config-rhdh.yaml : | app : ...omit... backend : ...omit... auth : ...omit... integrations : ...omit... signInPage : github catalog : ...omit... # ここから下を追記 enabled : kubernetes : true kubernetes : clusterLocatorMethods : - clusters : - authProvider : serviceAccount name : ${K8S_CLUSTER_NAME} serviceAccountToken : ${K8S_CLUSTER_TOKEN} url : ${K8S_CLUSTER_URL} skipTLSVerify : true type : config customResources : - apiVersion : v1 group : route.openshift.io plural : routes serviceLocatorMethod : type : singleTenant kubernetes.enabled : kubernetes plugin を有効化するために true と設定します。 kubernetes.clusterLocatorMethods : どのクラスタを扱うか、どのような認証方法を使うかを定義します。 authProvider : 今回は serviceAccount を利用しており、serviceAccountToken には後ほど作成するServiceaccountのTokenを設定します。 skipTLSVerify : TLS検証をスキップする設定です。 kubernetes.customResources : OpenShift Routeなど、デフォルトではサポートしていないカスタムリソースもあらかじめ登録しておくことで、リソース情報を取得できます。 serviceLocatorMethod : singleTenant の場合、単一のK8sクラスターのみをDeveloper Hubと連携させます。 Serviceaccountを作成する 3つのpluginの動作に必要な権限を持つServiceaccountをOpenShift上にデプロイします。 以下のyamlファイルを作成して、デプロイしていきましょう。このyamlファイルでは、Serviceaccountを作成し、Pluginに必要な権限(ClusterRole)をBindingし、Secretに設定が必要なTokenを作成します。 k8s-plugin-sa.yaml --- apiVersion : v1 kind : ServiceAccount metadata : name : rhdh-k8s-plugin namespace : rhdh secrets : - name : rhdh-k8s-plugin-sa-token --- apiVersion : v1 kind : Secret metadata : name : rhdh-k8s-plugin-sa-token namespace : rhdh annotations : kubernetes.io/service-account.name : rhdh-k8s-plugin type : kubernetes.io/service-account-token --- apiVersion : rbac.authorization.k8s.io/v1 kind : ClusterRole metadata : name : rhdh-k8s-plugin rules : - apiGroups : - '*' resources : - '*' verbs : - get - list - watch --- apiVersion : rbac.authorization.k8s.io/v1 kind : ClusterRoleBinding metadata : name : rhdh-k8s-plugin-role-binding roleRef : apiGroup : rbac.authorization.k8s.io kind : ClusterRole name : rhdh-k8s-plugin subjects : - kind : ServiceAccount name : rhdh-k8s-plugin namespace : rhdh このyamlファイルをデプロイします。 oc apply -f k8s-plugin-sa.yaml 以下のコマンドでServiceaccount tokenを取得します。 oc get secret rhdh-k8s-plugin-sa-token -n rhdh -o jsonpath='{.data.token}' | base64 --decode 最後にOpenShiftのAPIのURLを取得します。 oc whoami --show-server するとROSAの場合 https://<cluster-name>.<domain>.openshiftapps.com:443 といった形のURLが出力されるので、このURL全体とcluster-nameを保管しておきます。 Secretの設定 では最後に、Kuberentes/Topology pluginの設定をapp-configに追記したので、必要な変数をSecretに設定していきます。 以下のように secret-rhdh.yaml に情報を追記します。 secret-rhdh.yaml apiVersion : v1 kind : Secret metadata : name : secrets-rhdh namespace : rhdh stringData : ...omit... K8S_CLUSTER_NAME : "<cluster-name>" K8S_CLUSTER_TOKEN : "`ey`から始まるServiceaccount token" K8S_CLUSTER_URL : "OpenShiftのAPI URL" 3つのファイルの反映 変更した3つのファイルをデプロイします。 oc apply -f app-config-rhdh.yaml -f secrets-rhdh.yaml -f dynamic-plugins-rhdh.yaml これでComponentに追加情報を表示するための準備が整いました。 Component を作成する 前半で作成した catalog-info.yaml を以下のように変更してみましょう。 caralog-info.yaml apiVersion : backstage.io/v1alpha1 kind : Component metadata : name : sample-blog description : デモンストレーション用のサービスです labels : app : sample-blog links : - url : https://console-openshift-console.apps.rosa.<cluster-name>.<domain>.openshiftapps.com/k8s/cluster/projects/sample-blog title : OpenShift Console icon : dashboard - url : https://nginx-sample-blog.apps.rosa.<cluster-name>.<domain>.openshiftapps.com title : Application Web Site icon : dashboard - url : https://<ForkしたSample BlogのGitリポジトリのURL> title : App Repository icon : github annotations : backstage.io/kubernetes-label-selector : 'app=sample-blog' backstage.io/kubernetes-namespace : sample-blog spec : type : website owner : user:default/<githubのuser名> lifecycle : production 値は環境に合わせて適宜編集してください。 前半のyamlファイルと比較すると、以下の項目が追加されています。 links : Component画面に表示したいリンクを記載します。 annotations : Component画面に反映するための設定をここに追記します。どんなkey: valueが必要かどうかは、導入するPluginに依存します。今回はKubernetes/Topology Pluginに必要なものを2つ設定しています。 backstage.io/kubernetes-label-selector : Kubernetes内に存在する様々なリソースの中から、ここで指定したラベルを持つものをComponent画面に表示します。今回のSample Blogアプリは各リソースに app: sample-blog というラベルを付与しているので、それを指定します。 backstage.io/kubernetes-namespace : Component画面に表示したいNamespaceを指定します。 変更がおわったらGitのリモートにPushしておきます。 Component を登録する 前半でComponentを登録した手順をもう一度実行して、変更を反映します。すると以下のように、Linksが増えていたり、新しいタブが増えているかと思います。 Topologyタブでは、Deploymentの構成情報や通信ルートが表示されます。これはOpenShiftの開発者パースペクティブにおけるトポロジー画面とほぼ同様のものになります。（変更作業はできない） Kubernetesタブでは、Topologyよりも詳しいリソース情報を確認できます。いろんな操作をしてどんな情報が確認できるか試してみてください。 おわりに 今回はComponentの基本的な概念から、実用的なComponent画面の作成方法について解説しました。 次回はSoftwate Template機能について触れていきます。乞うご期待！

レッドハットのソリューションアーキテクトの森です。 Red Hat build of Apache Camel（旧 Red Hat Fuse）では、開発のためのツールをいくつかご用意しています。 今回は、Camel JBang の Kubernetes Plugin をご紹介します。 Camel JBang Kubernetes Plugin を使うと、ローカル環境でカジュアルにCamelのルートを試すのと同じ感覚で、コマンド一発でKubernetesクラスタにデプロイしたり削除したりできます。 前回の記事はこちら rheb.hatenablog.com 事前準備 以下のものをインストールしておきます。 JBang Camel JBang (Camel CLI) OpenShift CLI JBang 及び Camel JBang (Camel CLI) のインストールについては、 前回記事 を参照ください。 OpenShift CLI のインストール手順については、 製品ドキュメント を参照ください。 今回使用するCamelのサンプルについて 指定した都市の3日間分の気温予測データを取得する、REST APIサービスを作ってみます。 今回は2つの Free API を組み合わせて作ります。 Open-Meteo : 無料の気象データ API で、緯度・経度を指定して、その地点の天気予報を取得可能。 GeoDB Cities : 都市や地域に関する詳細な地理データ（緯度、経度、人口、標高、時差、ISO コードなど）を取得可能。 以下は サンプルのフローです。VSCodeの拡張機能として提供しているGUIエディタの Kaoto で作成しています。 サンプルのソースコードです。 - route: id: route-3280 from: id: from-2281 description: /temp uri: platform-http parameters: path: /temp steps: - setVariable: name: location simple: expression: ${header.location} - removeHeaders: pattern: "*" - toD: description: geodb-free-service.wirefreethought.com/v1/geo/places uri: http parameters: httpMethod: GET httpUri: geodb-free-service.wirefreethought.com/v1/geo/places limit: 1 namePrefix: ${variable.location} sort: -population - unmarshal: json: library: Jackson - removeHeaders: pattern: "*" - toD: description: api.open-meteo.com/v1/forecast uri: https parameters: daily: temperature_2m_max,temperature_2m_min forecast_days: 3 httpMethod: GET httpUri: api.open-meteo.com/v1/forecast latitude: ${body[data][0][latitude]} longitude: ${body[data][0][longitude]} - unmarshal: json: library: Jackson - setBody: simple: expression: |- { "city": "${variable.location}", "unit": "celsius", "temperature": { "today": { "maximum": "${body[daily][temperature_2m_max][0]}", "manimum": "${body[daily][temperature_2m_min][0]}" }, "forecast": { "${body[daily][time][1]}": { "maximum": "${body[daily][temperature_2m_max][1]}", "manimum": "${body[daily][temperature_2m_min][1]}" }, "${body[daily][time][2]}": { "maximum": "${body[daily][temperature_2m_max][2]}", "manimum": "${body[daily][temperature_2m_min][2]}" } } } } Camel JBang Kubernetes Plugin で OpenShift にデプロイしてみる それでは、 Camel JBang Kubernetes Plugin を使って、サンプルをOpenShiftにデプロイしてみます。 まずはローカルの環境に、上記のサンプルコードをyaml形式で保存し、OpenShift CLI で OpenShiftにログインした状態にします。 Kubernetes Plugin は、以下のコマンドで Camel JBangに追加することができます。 camel plugin add kubernetes インストールされている Plugin は、以下のコマンドで確認できます。 camel plugin get Kubernetes Plugin がリストに表示されていればOKです。 NAME COMMAND DEPENDENCY DESCRIPTION kubernetes kubernetes org.apache.camel:camel-jbang-plugin-kubernetes Run Camel applications on Kubernetes Kubernetes Plugin の詳細については以下のリンクを参照してください。 Camel Kubernetes plugin :: Apache Camel Kubernetes Plugin を使って OpenShift にデプロイをするには、以下のコマンドを実行します。 今回は REST API で OpenShiftに外部からアクセス可能にするための Route 生成と、Route における TLS Termination 設定 をオプションで指定しました。 camel kubernetes run sample.yaml \ --cluster-type=openshift \ --trait route.enabled=true \ --trait route.tls-termination=edge デフォルトではランタイムは Quarkus が選択されますが、 --runtime=spring-boot を指定すると、 Spring Boot のアプリケーションとしてデプロイされます。 ローカル上でコマンドを実行すると、OpenShift上でビルドが始まります。 しばらくすると、ビルドが完了して、アプリケーションが起動します。 Route に 記載されたURLに、 /temp?location=<都市名> でアクセスします。（残念ながら都市名は日本語には対応していません・・・！） 上記の通り、札幌の3日間分の気温予報データを取得することができました。 おわりに いかがでしょうか？ Camel JBang Kubernetes Plugin は、手軽さと素早い実行にフォーカスしており、 Kubernetes や OpenShift 上でのCamelアプリケーションの開発に非常に便利です。 設定作業や準備も最小限で済むため、PoCや小規模実装のスタートアップに特にメリットがあります。 Red Hat build of Apache Camel に関して興味がある・もう少し詳しい内容が聞きたい、などありましたら、是非弊社までお問合せ頂ければと思います。

Red Hatの森若です。 systemdの前後関係で問題が発生することが原因で、NFS mountに失敗することがあります。 実際の問題で困っている人は以下のナレッジ記事をどうぞ :) access.redhat.com 今回はこの背景を簡単に紹介します。 systemdによる前後関係の矛盾検出 systemdはどのunitをいつ起動するかを、After= および対応する Before= で管理しています。 この定義はシステム起動やシャットダウン時のような、複数のunitのstart/stopが関連する操作の時に利用され、systemdはこの前後関係が満たされる範囲で並列にstart/stopをおこないます。 以下では「unit Aを開始する」を A/start と記述します。 systemdは、実際に起動の操作をおこなう前の計画段階で矛盾を検出します。ここで言う「矛盾」は、前後関係にループが作成されることです。 たとえば 以下のようになっているとループが発生します。 A/start のあとに B/start B/start のあとに C/start C/start のあとに A/start systemd-fstab-generator による fstabから mount unitの作成 systemdは、 /etc/fstab を直接扱えませんが、fstabで定義されたmountをどのような順番で実行するかを決めるのはsystemdです。 systemdの起動直後、rootファイルシステム変更、 systemctl daemon-reload 実行時等のタイミングで systemd-fstab-generator というプログラムが /etc/fstab を読み込み、systemd用の unit fileを /run/systemd/generator/ 以下に生成します。そのため、fstabを編集したあとには systemctl daemon-reload を実行して unit fileを再生成して読み込み直す必要があります。 mount unit の名前では、mount pointを一定の規則で置き換えた、以下のような名前が利用されます。 / は -.mount /var は var.mount /boot/efi は boot-efi.mount シンプルな例 /etc/fstab UUID=xxxx / xfs defaults 0 0 10.0.0.100:/exp /mnt nfs defaults 0 0 いろいろ省略していますが、関連する前後関係はこのようになります。 前後関係のグラフ この場合、 -.mount/start 、 NetworkManager.service/start 、 mnt.mount/start の順に実行して特に問題になりません。 問題のある例 /mnt/opt/foo を /opt/foo にbind mountすることにします。 /etc/fstab UUID=xxxx / xfs defaults 0 0 10.0.0.100:/exp /mnt nfs defaults 0 0 /mnt/opt/foo /opt/foo none bind 0 0 前後関係にサイクルができる この場合、 opt-foo.mount/start が local-fs.target (ローカルファイルシステムのmountが完了したことを示すtarget unit) より先にある必要があるため、矛盾が発生しています。このように実行順が決まらない場合、systemdは サイクル内に登場するランダムなjobを間引いて解決します。 どのunitの起動が間引かれるかは起動毎にかわるので、サイクルをそのままにすると、 mnt.mount/start に失敗したり、 opt-foo.mount/start に失敗したり、 NetworkManager.service/start に失敗するような、部分的な問題が発生します。 問題修正した例 この例の場合、問題の解決は簡単で、 bind mountの行に _netdev オプションを追加するだけです。 /etc/fstab UUID=xxxx / xfs defaults 0 0 10.0.0.100:/exp /mnt nfs defaults 0 0 /mnt/opt/foo /opt/foo bind,_netdev 0 0 _netdev により矛盾解消 なぜ直るのか? _netdev の有無であっさり動作がかわりました。 これは systemd-fstab-generator の動作によるもので、 /etc/fstab 内でファイルシステムが nfs や cifs 等である場合や _netdev がある場合には Before=remote-fs.target を、そうでない場合には Before=local-fs.target を指定します。 興味がある方は ソース を辿ってみると詳細がわかります。

レッドハットのソリューションアーキテクトの森です。 Red Hat build of Apache Camel（旧 Red Hat Fuse）では、開発のためのツールをいくつかご用意しています。 今回は、効率よくプロトタイピングを行うことができる、Camel JBang (Camel CLI) についてご紹介をします。 Camel JBangを使用すると、シンプルなスクリプトファイルを使用してCamelルートを実行できます。 事前準備 以下のものをインストールしておきます。 JBang Camel JBang (Camel CLI) JBangのインストールについては、 こちら を参照ください。 JBangがインストールされていれば、以下のコマンドで Camel JBang をインストールすることができます。 既にApache Camelを使用している方は、Camelと同じバージョンを指定してください。（ここでは 4.8.2 を指定しています） jbang app install -Dcamel.jbang.version=4.8.2 camel@apache/camel インストールが完了すると、 camel version で JBang と Camel JBang のバージョンが確認できます。 出力例 % camel version JBang version: 0.122.0 Camel JBang version: 4.8.2 Camel JBang の主なコマンドについて 以下にCamel JBangの基本的なコマンドを示します。(私がよく使うもの) コマンド 内容 init Camel の 基本的な ルート を作成する run 指定したCamelスクリプトファイルを実行 version インストールされているCamel JBangのバージョンを表示 help 使用可能なコマンドの一覧とその説明を表示 export CamelプロジェクトをMavenプロジェクトとしてエクスポート transform route CamelのDSLの形式変換（YAML ↔︎ XML） ps ローカルで実行している Camel を監視する stop ローカルで実行中の Camel を停止する debug Camel ルート のデバッグを行う その他のコマンドや詳細については、 camel --help を確認するか、 Camel JBang のドキュメントを確認してみてください。 Camel JBang を使ってみる Camel ルート の作成と実行 camel init コマンドを使用して、新しい基本 ルート を作成できます。 ファイル形式は *.java 、 *.yaml 、 *.xml などが指定可能です。 例えば、YAML DSL形式の ルート を作成するには、以下のようにします。 camel init sample.yaml サンプルルートを含むファイルを sample.yaml（現在のディレクトリに）作成します。 YAML DSL形式の ルート であれば、VSCodeの拡張機能として提供しているGUIエディタの Kaoto で編集をすることができます。 marketplace.visualstudio.com このサンプルルートは、以下のような動作を定義しています。 Timerコンポーネントの使用: from 句に Camel の Timer コンポーネントが設定されています。 これは、定期的にイベントを発生させることができます。 parameters セクションで period: "1000" が設定されており、これはタイマーが毎秒（1000ミリ秒）ごとにメッセージを生成することを意味します。 処理ステップの定義: steps セクションでは、メッセージの生成とログへの出力が定義されています。 setBody: このステップでは、メッセージの本文を設定しています。ここでは "Hello Camel from ${routeId}" という文字列を使用しており、 ${routeId} はこのルートのIDに動的に置き換えられます。 log: 設定したメッセージ本文をログに出力しています。 ${body} は現在のメッセージ本文を参照しており、これにより前の setBody で設定された文字列がログとして出力されます。 Camel ルート を Camel JBang で実行するには、次のコマンドを実行します。 camel run sample.yaml Camel Quarkus, Camel Springboot へのエクスポート camel export --runtime=quarkus コマンドは、現在のCamel JBangファイルを、Mavenベースの Quarkus プロジェクトにエクスポートします。 例えば、Maven の groupId: com.foo と artifactId: acme 及び、 version: 1.0-SNAPSHOT で Quarkus にエクスポートするには、次のコマンドを実行します。 camel export <files> --runtime=quarkus --gav=com.foo:acme:1.0-SNAPSHOT --directory=./myproject 必要な依存関係などは pom.xml に含まれているので、Camel Quarkus としてすぐに動かすこともできます。 cd myproject mvn quarkus:dev 同様に、Spring Boot のプロジェクトにエクスポートする場合は、 --runtime=spring-boot と指定してください。 camel export <files> --runtime=spring-boot --gav=com.foo:acme:1.0-SNAPSHOT --directory=./myproject おわりに いかがでしょうか？ Camel JBang を使うことで、Apache Camelのインテグレーションの開発がより効率よく行うことができるようになります。 次回は、Camel JBang の Kubernetes Plugin を使って、プロトタイプを OpenShift にデプロイする方法をご紹介します。 Red Hat build of Apache Camel に関して興味がある・もう少し詳しい内容が聞きたい、などありましたら、是非弊社までお問合せ頂ければと思います。

【2026年2月追記】最新の情報を元に内容をアップデートしました！ こんにちは、Red HatでOpenShift関連のプリセールスをしている北村です。 前回の記事では GitHub と連携してDeveloper Hubの認証を実装しました。 しかし中には、GitHubではなく社内のオンプレミス環境に構築した GitLab を利用している方もいるかと思います。 なので今回はGitLab OAuthを利用したDeveloper Hub認証の実現方法をまとめてみます。 【第1回】Developer Hubをインストールしてみよう 【第2回】GitHubを使用した認証を実装しよう 【第3回】GitLabを使用した認証を実装しよう ←この記事 【第4回】Componentを作成・登録しよう 【第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう 【第6回】TechDocsを作成・登録しよう 【第7回】Golden Pathの実装をマスターしよう - 前編 【第8回】Golden Pathの実装をマスターしよう - 後編 GitLabを利用した認証に関する問題 GitLabでの認証では、GitHubのように直接Developer Hubと連携するとこはできません。 これはRed Hatのサポート状況に関するものです。Developer Hubで利用可能な認証はv1.8時点で "GitHub"、"Red Hat Build of Keycloak(RHBK)"、"Microsoft Azure" の3種類となっています。 それを踏まえ、今回はDeveloper HubでサポートされているRHBKを経由して認証を実装します。GitLabをRHBKのIdentity Providerとして登録します。ちなみにRHBKはOpenShiftのSubscriptionに含まれており、ROSA環境でも追加費用なく導入可能です。（詳細は こちら ） つまりイメージはこんな感じ↓ Developer Hub GitLab 認証 実装手順 今回の手順はコミュニティ版のGitLabを前提としています。おそらくエンタープライズ版でも同様の手順で実現できます。 GitLab Application設定 まずはGitLab側の設定から始めます。 GitHubのようにGroupを作成後、Applicationを登録します。今回は rhdh-gitlab-group というGroupにしました。 GroupのページからSettings→Applications→Add new applicationを選択して、以下の内容を入力します。 Redirect URI は後ほど書き換えるのでダミーで適当な値を入れておきます。 Name 任意の値 Redirect URI https://dummy.hoge Confidential false Scopes read_user openid 作成完了の画面で Application ID と Secret を取得しておきます。 RHBK設定 次にRHBK側の設定を進めます。 まずはRHBKをOpenShiftにインストールしていきます。 今回は rhdh NamespaceにRHBK Operatorをインストールします。インストール時はデフォルトの設定でOKです。2026年2月時点での更新チャネルは stable-v26.2 、バージョンは v26.2.12-opr.1 でした。 次にKeycloakが使うDBをデプロイします。今回は開発用の一時的な PostgreSQL Podを作成します。 postgres.yaml apiVersion : apps/v1 kind : StatefulSet metadata : name : postgresql-db namespace : rhdh spec : serviceName : postgresql-db-service selector : matchLabels : app : postgresql-db replicas : 1 template : metadata : labels : app : postgresql-db spec : containers : - name : postgresql-db image : postgres:15 volumeMounts : - mountPath : /data name : postgres-storage env : - name : POSTGRES_USER valueFrom : secretKeyRef : name : keycloak-db-secret key : username - name : POSTGRES_PASSWORD valueFrom : secretKeyRef : name : keycloak-db-secret key : password - name : PGDATA value : /data/pgdata - name : POSTGRES_DB value : keycloak volumes : - name : postgres-storage persistentVolumeClaim : claimName : postgres-storage --- apiVersion : v1 kind : Service metadata : name : postgres-db namespace : rhdh spec : selector : app : postgresql-db type : ClusterIP ports : - port : 5432 targetPort : 5432 --- apiVersion : v1 kind : Secret metadata : name : keycloak-db-secret namespace : rhdh stringData : password : testpassword username : testuser --- apiVersion : v1 kind : PersistentVolumeClaim metadata : name : postgres-storage namespace : rhdh spec : accessModes : - ReadWriteOnce resources : requests : storage : 10Gi DB作成できたらkeycloakをデプロイしていきます。以下のyamlを作成してデプロイしましょう。 keycloak.yaml apiVersion : k8s.keycloak.org/v2alpha1 kind : Keycloak metadata : labels : app : sso name : keycloak namespace : rhdh spec : instances : 1 http : httpEnabled : true hostname : strict : false proxy : headers : xforwarded ingress : className : openshift-default しばらくすると route が作成されるので、 keycloak-initial-admin というSecretに記載のユーザーとパスワードでログインします。 次にrealmとgitlabのIdentity Providerを登録します。今回はRHBK Operatorを使っているので、 KeycloakRealmImport というCRを使って一気に登録を行います。 reaml と client の名前は rhdh としました。 keycloakrealmimport.yaml apiVersion : k8s.keycloak.org/v2alpha1 kind : KeycloakRealmImport metadata : name : realm-import namespace : rhdh spec : keycloakCRName : keycloak realm : realm : rhdh displayName : "GitLab Realm for RHDH" enabled : true ssoSessionIdleTimeout : 28800 ssoSessionMaxLifespan : 86400 rememberMe : true clients : - clientId : rhdh name : rhdh enabled : true publicClient : false redirectUris : - "https://<Developer HubのURL>/*" webOrigins : - "https://<Developer HubのURL>" clientAuthenticatorType : client-secret secret : "<任意の値>" # node -p 'require("crypto").randomBytes(24).toString("base64")' などで生成 identityProviders : - enabled : true alias : "gitlab" displayName : "GitLab" providerId : "oidc" config : clientId : "<GitLab ApplicationのClient ID>" clientSecret : "<GitLab ApplicationのClient Secret>" authorizationUrl : "https://<GitLabのURL>/oauth/authorize" tokenUrl : "https://<GitLabのURL>/oauth/token" 適宜自分の環境に合わせてパラメータを編集してデプロイします。 KeycloakRealmImport がデプロイされるとJobが起動し、Keycloak Podが再起動します。再度ログインすると以下のように Realm 、 Client 、 Identity Provider が作成されています。 このGitLabの Identity Provider にある Redirect URI の値をコピーしておきましょう。 GitLab Applicationの変更 GitLab Applicationにダミーで登録した Redirect URI を、コピーしてきた値に変更します。 これで認証周りの実装は完了しました。 次にDeveloper HubがGitLabからUserやGroup情報を読み込むために必要なアクセストークンを払い出します。 GroupのページからSettings→Access tokens→Add new tokenを選択して、以下の内容を入力します。 Token name 任意の値 Token description 任意記入 Expiration date 任意記入 Select a role Developer Select scopes api read_repository write_repository 作成すると Your new project access token にアクセストークンが払い出されるので、これをコピーしておきます。 Developer Hubの設定変更 Developer Hubからこのファイルを読み込むための設定をします。 最初は dynamic-plugins-rhdh.yaml にGitLab pluginのインストール設定を記入します。 dynamic-plugins-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : dynamic-plugins-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : dynamic-plugins.yaml : | includes : - 'dynamic-plugins.default.yaml' plugins : # GitHub Plugins - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic disabled : false # GitLab Plugins ←GitLab用のPluginを追記 - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-dynamic # GitLab APIからデータを取得するための「専用の裏口（Proxy/API）」を提供 disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-org-dynamic # GitLabの「グループ」や「ユーザー」の構造を、RHDHのUser/Groupエンティティとして同期 disabled : false 次に app-config-rhdh.yaml を編集します。以下のように、 auth , integrations , signInPage , catalog の設定を追記・編集します。 auth : Developer Hubの認証に関する設定 integrations : GitHubなどの外部システムとの統合（連携）に関する設定 signInPage : ログインするときに表示されるサインインページを指定する設定 catalog : Developer HubにさまざまなEntity(Catalog)を登録するための設定 app-config-rhdh.yaml kind: ConfigMap apiVersion: v1 metadata: name: app-config-rhdh namespace: rhdh annotations: rhdh.redhat.com/backstage-name: developer-hub data: app-config-rhdh.yaml: | app: ...omit... backend: ...omit... auth: providers: gitlab: # GitLabの情報を追記 production: clientId: ${AUTH_GITLAB_CLIENT_ID} clientSecret: ${AUTH_GITLAB_CLIENT_SECRET} signIn: resolvers: - resolver: usernameMatchingUserEntityName oidc: # OIDC(Keycloak)の情報を追記 production: clientId: ${KEYCLOAK_CLIENT_ID} clientSecret: ${KEYCLOAK_CLIENT_SECRET} metadataUrl: https://${KEYCLOAK_BASE_URL}/realms/${KEYCLOAK_REALM} prompt: auto signIn: resolvers: - resolver: preferredUsernameMatchingUserEntityName signInPage: oidc # SigninページをOIDC(Keycloak)に設定 integrations: github: ...omit... gitlab: # GitLabの情報を追記 - host: ${GITLAB_HOST} apiBaseUrl: https://${GITLAB_HOST}/api/v4 token: ${GITLAB_TOKEN} catalog: rules: - allow: - User - Group providers: gitlab: # GitLabの情報を追記 gitlabProvider: host: ${GITLAB_HOST} orgEnabled: true allowInherited: true group: ${GITLAB_GROUP} rules: - allow: - Group - User - Location schedule: frequency: PT60S initialDelay: PT30S timeout: PT120S 導入した GitLab Plugin と catalog.providers.gitlab の設定によって、Developer Hubが定期的に該当のGroupのユーザー情報を取得します。 最後に secrets-rhdh.yaml も修正して必要な値を追加しておきましょう。 apiVersion: v1 kind: Secret metadata: name: secrets-rhdh namespace: rhdh stringData: ...omit... # GitLab Settings GITLAB_GROUP: "<GitLabのGroup名>" GITLAB_HOST: "<GitLabのURL(https://は不要)>" GITLAB_TOKEN: "<取得したGitLab アクセストークン>" AUTH_GITLAB_CLIENT_ID: "<作成したGitLab ApplicationのApplication ID>" AUTH_GITLAB_CLIENT_SECRET: "<作成したGitLab ApplicationのSecret>" # Keycloak Settings KEYCLOAK_BASE_URL: "<KeycloakのURL(http://は不要)>" KEYCLOAK_CLIENT_ID: "rhdh" KEYCLOAK_CLIENT_SECRET: "<KeycloakRealmImportに設定したsecretの値>" KEYCLOAK_LOGIN_REALM: "rhdh" KEYCLOAK_REALM: "rhdh" これらをデプロイします。 oc apply -f app-config-rhdh.yaml -f secrets-rhdh.yaml -f dynamic-plugins-rhdh.yaml Podの再起動後、ログインしてみると、無事にHOME画面が表示されます。 OIDC の Sign In を選択すると、Keycloakのログイン画面が表示されるので、下の方の GitLab マークを選択します。 するとGitLabのページに飛ぶので、 Authorize rhdh を選択するとKeycloakの画面に戻ります。ここで First name や Last name を追記します。ここで設定した First name や Last name はDeveloper Hubにも反映されます。なお、 Username の項目は変更NGです。 Submitを選択すると、無事にDeveloper Hubにログインできます。 Settings に移動すると、先ほど設定した First name や Last name が反映されていたり、 Backstage Identity を見ると、作成したGroup/User Entityに紐づいていることも確認できます。 おわりに 今回はGitLabと連携してDeveloper Hubの認証を実装する方法を解説しました。 次回の記事以降でいよいよDeveloper Hubの中身に触れていきます。乞うご期待！

こんにちは。Specialist Solution Architect の瀬戸です。 Red Hatから去年発表されたRed Hat Trusted Software Supply ChainおよびTrusted Application Pipelineという製品群をご存知でしょうか？ ご存知でなくても、これらの製品が実現したいことはとても簡単なので、簡単に学んでみましょう。 どこにでもある「脅威」 これらはTrusted (信頼できる程度の意味)という名前がついている通り、セキュリティを担保するための製品群です。 ソフトウェアを開発して、本番環境でアプリケーションを動作させるまでをセキュアに保ちます。 実はRed Hat はソフトウェアを提供しているアプリケーション開発会社だということはご存じでしょうか？ Red Hat は Red Hat Enterprise Linux をはじめとした多くのユーザーがいるソフトウェアを開発しており、それらをセキュアに保つための活動をしています。 今回、 Red Hat ではそれらで培ったソフトウェアリリースをセキュアに行うための方法論を製品としてリリースしました。 セキュアにしましょうとだけ言われても、なんで？となってしまうので、開発環境にどのような問題がありがちなのかを見ていきましょう。 ソフトウェア開発環境は狙われている！ 本番環境はセキュリティ対策がしっかりしていると思います。アンチウィルスソフト等を動作させ監視させ、変更には手続きが必要で何が動いているかをきちんと管理できるようにする。 手作業が必要な場合も事前に申請をし、何を行うのかを確認の上で、手順書通りに行い、余計なことがされてないことを保証していると思います。 しかし、開発環境はどうでしょうか？ 開発者個人に支給されたPCで作業をし、好きなソフトウェアを使用し、ソフトウェア開発を行っている場合が多いです。 大多数である事務用のPCの場合は最低限のOfficeスイート製品や、別途必要になるいくつかの製品だけあればよい場合が多いですが、 開発者の場合は特殊なソフトウェアが必要になる場合があります。 また、Officeスイート製品等はベンダーから提供される自動アップデート機能が有効だったりもしますが、 開発者が使うようなソフトウェアの場合は個人が開発している場合もあり、自動アップデート機能が存在しない場合もあります。 そのような状態で開発者の開発環境が狙われ、そこが踏み台とされ企業内のデータ漏洩事故等が発生するようになっています。 依存しているライブラリも狙われている！ 本番環境で動いているシステムがいくつのサードパーティー製のライブラリに依存しているかを数えたことがある人はいるでしょうか？ ある程度の規模になると数十～数百は含まれているはずです。 もし調べたことがない人は、JavaでMavenを使用している場合は次のコマンドで簡単に調べることができます。 mvn dependency:tree 今、ためしに手元にあったアプリケーションに対してかけてみたら次のような結果になりました。 1行が1依存ライブラリなので、119個(テスト用を含めると159個)のサードパーティー製のライブラリに依存しています。 C:\git\camel-example>mvn dependency:tree [INFO] Scanning for projects... [INFO] [INFO] ----------------------< com.redhat:camel-example >---------------------- [INFO] Building A Camel Spring Boot Route 1.0-SNAPSHOT [INFO] from pom.xml [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- dependency:3.7.0:tree (default-cli) @ camel-example --- [INFO] com.redhat:camel-example:jar:1.0-SNAPSHOT [INFO] +- org.springframework.boot:spring-boot-starter-web:jar:2.7.4:compile [INFO] | +- org.springframework.boot:spring-boot-starter:jar:2.7.4:compile [INFO] | | +- org.springframework.boot:spring-boot:jar:2.7.4:compile [INFO] | | +- org.springframework.boot:spring-boot-autoconfigure:jar:2.7.4:compile [INFO] | | +- org.springframework.boot:spring-boot-starter-logging:jar:2.7.4:compile [INFO] | | | +- ch.qos.logback:logback-classic:jar:1.2.11:compile [INFO] | | | | \- ch.qos.logback:logback-core:jar:1.2.11:compile [INFO] | | | +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.17.2:compile [INFO] | | | | \- org.apache.logging.log4j:log4j-api:jar:2.17.2:compile [INFO] | | | \- org.slf4j:jul-to-slf4j:jar:1.7.36:compile [INFO] | | +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile [INFO] | | \- org.yaml:snakeyaml:jar:1.30:compile [INFO] | +- org.springframework.boot:spring-boot-starter-json:jar:2.7.4:compile [INFO] | | +- com.fasterxml.jackson.core:jackson-databind:jar:2.13.4:compile [INFO] | | | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.4:compile [INFO] | | | \- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile [INFO] | | +- com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.13.4:compile [INFO] | | +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.13.4:compile [INFO] | | \- com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.13.4:compile [INFO] | +- org.springframework:spring-web:jar:5.3.23:compile [INFO] | | \- org.springframework:spring-beans:jar:5.3.23:compile [INFO] | \- org.springframework:spring-webmvc:jar:5.3.23:compile [INFO] | +- org.springframework:spring-aop:jar:5.3.23:compile [INFO] | +- org.springframework:spring-context:jar:5.3.23:compile [INFO] | \- org.springframework:spring-expression:jar:5.3.23:compile [INFO] +- org.springframework.boot:spring-boot-starter-undertow:jar:2.7.4:compile [INFO] | +- io.undertow:undertow-core:jar:2.2.19.Final:compile [INFO] | | +- org.jboss.logging:jboss-logging:jar:3.4.3.Final:compile [INFO] | | +- org.jboss.xnio:xnio-api:jar:3.8.7.Final:compile [INFO] | | | +- org.wildfly.common:wildfly-common:jar:1.5.4.Final:compile [INFO] | | | \- org.wildfly.client:wildfly-client-config:jar:1.0.1.Final:compile [INFO] | | +- org.jboss.xnio:xnio-nio:jar:3.8.7.Final:runtime [INFO] | | \- org.jboss.threads:jboss-threads:jar:3.1.0.Final:compile [INFO] | +- io.undertow:undertow-servlet:jar:2.2.19.Final:compile [INFO] | +- io.undertow:undertow-websockets-jsr:jar:2.2.19.Final:compile [INFO] | +- jakarta.servlet:jakarta.servlet-api:jar:4.0.4:compile [INFO] | +- jakarta.websocket:jakarta.websocket-api:jar:1.1.2:compile [INFO] | \- org.apache.tomcat.embed:tomcat-embed-el:jar:9.0.65:compile [INFO] +- org.springframework.boot:spring-boot-starter-actuator:jar:2.7.4:compile [INFO] | +- org.springframework.boot:spring-boot-actuator-autoconfigure:jar:2.7.4:compile [INFO] | | \- org.springframework.boot:spring-boot-actuator:jar:2.7.4:compile [INFO] | \- io.micrometer:micrometer-core:jar:1.9.4:compile [INFO] | +- org.hdrhistogram:HdrHistogram:jar:2.1.12:compile [INFO] | \- org.latencyutils:LatencyUtils:jar:2.0.3:runtime [INFO] +- org.apache.camel.springboot:camel-spring-boot-starter:jar:3.14.5.redhat-00012:compile [INFO] | +- org.apache.camel.springboot:camel-spring-boot:jar:3.14.5.redhat-00012:compile [INFO] | | +- org.apache.camel:camel-spring:jar:3.14.5:compile [INFO] | | | +- org.apache.camel:camel-management-api:jar:3.14.5:compile [INFO] | | | \- org.springframework:spring-tx:jar:5.3.23:compile [INFO] | | +- org.apache.camel:camel-spring-main:jar:3.14.5:compile [INFO] | | | \- org.apache.camel:camel-main:jar:3.14.5:compile [INFO] | | | \- org.apache.camel:camel-base:jar:3.14.5:compile [INFO] | | +- org.apache.camel:camel-xml-jaxb-dsl:jar:3.14.5:compile [INFO] | | | +- org.apache.camel:camel-core-model:jar:3.14.5:compile [INFO] | | | | \- org.apache.camel:camel-core-processor:jar:3.14.5:compile [INFO] | | | \- org.apache.camel:camel-dsl-support:jar:3.14.5:compile [INFO] | | | \- org.apache.camel:camel-endpointdsl:jar:3.14.5:compile [INFO] | | +- org.apache.camel:camel-cloud:jar:3.14.5.redhat-00009:compile [INFO] | | +- org.apache.camel:camel-cluster:jar:3.14.5.redhat-00009:compile [INFO] | | | \- org.apache.camel:camel-base-engine:jar:3.14.5.redhat-00009:compile [INFO] | | \- org.apache.camel:camel-health:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-core-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-core-engine:jar:3.14.5.redhat-00009:compile [INFO] | | +- org.apache.camel:camel-api:jar:3.14.5.redhat-00009:compile [INFO] | | +- org.apache.camel:camel-core-reifier:jar:3.14.5.redhat-00009:compile [INFO] | | \- org.apache.camel:camel-util:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-bean-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-bean:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-browse-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-browse:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-controlbus-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-controlbus:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-dataformat-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-dataformat:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-dataset-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-dataset:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-direct-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-direct:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-directvm-starter:jar:3.14.5:compile [INFO] | | \- org.apache.camel:camel-directvm:jar:3.14.5:compile [INFO] | +- org.apache.camel.springboot:camel-file-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-file:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-language-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-language:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-log-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-log:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-mock-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-mock:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-ref-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-ref:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-rest-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-rest:jar:3.14.5.redhat-00009:compile [INFO] | | \- org.apache.camel:camel-tooling-model:jar:3.14.5.redhat-00009:compile [INFO] | | \- org.apache.camel:camel-util-json:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-saga-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-saga:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-scheduler-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-scheduler:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-seda-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-seda:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-stub-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-stub:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-timer-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-timer:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-validator-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-validator:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-vm-starter:jar:3.14.5:compile [INFO] | | \- org.apache.camel:camel-vm:jar:3.14.5:compile [INFO] | +- org.apache.camel.springboot:camel-xpath-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-xpath:jar:3.14.5.redhat-00009:compile [INFO] | +- org.apache.camel.springboot:camel-xslt-starter:jar:3.14.5.redhat-00012:compile [INFO] | | \- org.apache.camel:camel-xslt:jar:3.14.5.redhat-00009:compile [INFO] | \- org.apache.camel.springboot:camel-xml-jaxp-starter:jar:3.14.5.redhat-00012:compile [INFO] | \- org.apache.camel:camel-xml-jaxp:jar:3.14.5.redhat-00009:compile [INFO] | \- org.apache.camel:camel-xml-io-util:jar:3.14.5.redhat-00009:compile [INFO] +- org.apache.camel.springboot:camel-stream-starter:jar:3.14.5:compile [INFO] | \- org.apache.camel:camel-stream:jar:3.14.5:compile [INFO] | \- org.apache.camel:camel-support:jar:3.14.5:compile [INFO] +- org.springframework.boot:spring-boot-starter-test:jar:2.7.4:test [INFO] | +- org.springframework.boot:spring-boot-test:jar:2.7.4:test [INFO] | +- org.springframework.boot:spring-boot-test-autoconfigure:jar:2.7.4:test [INFO] | +- com.jayway.jsonpath:json-path:jar:2.7.0:test [INFO] | | +- net.minidev:json-smart:jar:2.4.8:test [INFO] | | | \- net.minidev:accessors-smart:jar:2.4.8:test [INFO] | | | \- org.ow2.asm:asm:jar:9.1:test [INFO] | | \- org.slf4j:slf4j-api:jar:1.7.36:compile [INFO] | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.3:compile [INFO] | | \- jakarta.activation:jakarta.activation-api:jar:1.2.2:compile [INFO] | +- org.assertj:assertj-core:jar:3.22.0:test [INFO] | +- org.hamcrest:hamcrest:jar:2.2:test [INFO] | +- org.junit.jupiter:junit-jupiter:jar:5.8.2:test [INFO] | | +- org.junit.jupiter:junit-jupiter-api:jar:5.8.2:test [INFO] | | | +- org.opentest4j:opentest4j:jar:1.2.0:test [INFO] | | | +- org.junit.platform:junit-platform-commons:jar:1.8.2:test [INFO] | | | \- org.apiguardian:apiguardian-api:jar:1.1.2:test [INFO] | | +- org.junit.jupiter:junit-jupiter-params:jar:5.8.2:test [INFO] | | \- org.junit.jupiter:junit-jupiter-engine:jar:5.8.2:test [INFO] | | \- org.junit.platform:junit-platform-engine:jar:1.8.2:test [INFO] | +- org.mockito:mockito-core:jar:4.5.1:test [INFO] | | +- net.bytebuddy:byte-buddy:jar:1.12.17:test [INFO] | | +- net.bytebuddy:byte-buddy-agent:jar:1.12.17:test [INFO] | | \- org.objenesis:objenesis:jar:3.2:test [INFO] | +- org.mockito:mockito-junit-jupiter:jar:4.5.1:test [INFO] | +- org.skyscreamer:jsonassert:jar:1.5.1:test [INFO] | | \- com.vaadin.external.google:android-json:jar:0.0.20131108.vaadin1:test [INFO] | +- org.springframework:spring-core:jar:5.3.23:compile [INFO] | | \- org.springframework:spring-jcl:jar:5.3.23:compile [INFO] | +- org.springframework:spring-test:jar:5.3.23:test [INFO] | \- org.xmlunit:xmlunit-core:jar:2.9.0:test [INFO] \- org.apache.camel:camel-test-spring-junit5:jar:3.14.5:test [INFO] +- org.apache.camel:camel-test-junit5:jar:3.14.5:test [INFO] | \- org.apache.camel:camel-core-languages:jar:3.14.5:compile [INFO] \- org.apache.camel:camel-spring-xml:jar:3.14.5:compile [INFO] +- org.apache.camel:camel-xml-jaxb:jar:3.14.5:compile [INFO] | +- com.sun.xml.bind:jaxb-core:jar:2.3.0:compile [INFO] | \- com.sun.xml.bind:jaxb-impl:jar:2.3.3:compile [INFO] | \- com.sun.activation:jakarta.activation:jar:1.2.2:runtime [INFO] \- org.apache.camel:camel-core-xml:jar:3.14.5:compile [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.434 s [INFO] Finished at: 2025-01-06T11:18:35+09:00 [INFO] ------------------------------------------------------------------------ 多くのシステムや製品ではOSSが使われており、動作にはOSSが必要になります。また、そのOSSは別のOSSが使われており、動作には別のOSSが必要になります。またまたその別のOSSにはさらに別のOSSが使われており・・・・ と芋づる式に依存ライブラリが増えていってしまっています。 予期しない依存ライブラリを狙った攻撃というのは毎年行われており、ライブラリ自体に脆弱性を埋め込もうとした xz utilsの事例 や脆弱性の含まれたライブラリに対する外部からの攻撃が行われた log4shellの事例 等があります。 本番環境でアプリケーションを動作させる前に検証環境などで動作確認しているから問題ないと考える人もいるかもしれませんが、業務の動作に関係ない時限式の罠が末端の依存ライブラリに含まれていない事の検証まで行われている方はどれくらいいるのでしょうか？ なお、他の言語でもパッケージマネージャーを使用して依存関係を管理している場合のほとんどで簡単に依存関係の一覧を出力することができます。 例えば、 JavaScript(npm)の場合はnpm ls -allで出力できます。 そのほかの言語についても必要な場合は確認してみてください。 みんな気にはなっている脅威 IPAは情報セキュリティ10大脅威として毎年、去年に発生した社会的に影響が大きかったと考えられる情報セキュリティにおける事案から、IPAが脅威候補を選出し、情報セキュリティ分野の研究者、企業の実務担当者など約200名のメンバーからなる「10大脅威選考会」が脅威候補に対して審議・投票を行い、決定したものを公開しています。それの2024年度版の組織向けの脅威によると、1位はランサムウェアによる被害で、2位はサプライチェーンの弱点を悪用した攻撃、3位は内部不正による情報漏えい等の被害でした。 情報セキュリティ10大脅威[組織] IPAより www.ipa.go.jp ランサムウェアはソフトウェアを勝手にインストールしたときに感染する場合もあります、また、開発環境だからと統制を行わずに好き勝手にPCを使わせていたら内部不正の温床になる可能性があります。サプライチェーンの弱点の中には依存ライブラリに起因する脆弱性が含まれます。 情報セキュリティ10大脅威のTOP3にはアプリケーション開発に関わるものが含まれています。当然、それ以外の物にもアプリケーション開発に関わるものが多く含まれています。 さて、どうしていくか 世の中にはこれらの課題を解決するためのソリューションが多数あります。しかし、本当にそれらのソリューションで解決できるのでしょうか？解決した気になっているだけではないでしょうか？ Red Hatは30年以上にわたりRed Hat Enterprise Linuxをセキュアに提供しています。その中でRed Hatでどうやって安全なアプリケーションをユーザーに提供してきたのかをノウハウとしてユーザーに提供できるようにしたのが、Red Hat Trusted Software Supply Chain および Trusted Application Pipeline です。 Red Hat Trusted Software Supply Chainは Red Hat OpenShift Plus に含まれるいくつかの製品とTrusted Application Pipelineを含んだソリューションの名前で単体では販売されていません。 ここから、開発プロセスを安全にするためにはどのようにしていけばよいのかと、Red Hat OpenShift PlusとTrusted Application Pipelineにどのような機能が含まれているのかについて説明していきます。 この記事では一般的なCI/CDパイプラインについての知識があることを前提としています。ご了承ください。 なお、これ以外にもかならずセキュリティパッチを当てる等一般的な事柄もありますが、割愛しています。 開発環境では誰が何をしたのかを判るようにする Red HatではRed Hat build of KeyCloakというシングルサインオンを実現するための製品があります。そちらと各機能を連携させて、誰が何を行ったのかを確実にわかるようにします。 社内のIDは統合済みでしょうか？事務をされる方々等が使用するIDはMicrosoft Active Directory等を使用して統合されている場合がほとんどでしょうが、開発者が使用するシステムについてはユーザー数が少ないからという理由で統合されていない場合があります。それらをすべて統合する必要があります。 そのうえで適切に作業ログを取るようにしていきます。 Gitの設定を適切に行う Gitのリポジトリには何を使っているでしょうか？GitHubですか？ 実はGitHubではデフォルトでコミット履歴を改ざん(変更)することができます。方法は Gitのマニュアルに記載されているとおりに実行するだけ です。GitHub以外ではデフォルトでは改ざんできないようになっている場合もありますが、設定を変更することで改ざんができるようになります。 git-scm.com また、Gitでは、コミットするユーザー名やメールアドレスは自由に入力できます。どのような値が入力されているかきちんと管理されているでしょうか？GitHubやGitLab等を使用している場合は、Gitとは別途に認証機能を使用して、正しいユーザー名、メールアドレスが使用されているか認証してくれる機能を持っている場合もあります。 Gitリポジトリのプロバイダ側でそういった仕組みを持っていない場合は、Trusted Application Pipeline に含まれる Sigstore Gitsign を使用する事で、Gitに署名を行い、誰がコミットをしたのか、改ざんされていないことを担保することができます。 とにかく署名、ログを取る 開発中に作られたアプリケーションバイナリがその後改変されていないことを保証し、責任の所在を明確にするため、出来上がったものに署名を行います。Javaのjarファイルの場合は jarsigner を使用することができます。コンテナイメージなどの場合は汎用的な仕組みとして Sigstore Cosign を使用することができます。 これでアプリケーションに何かがあった場合にどこまで安全だったのかを確認することができます。コンテナイメージを使用していないRHEL(Linux)の場合は、 Tripwire等を使用する事でその時点で何が入っていたのかのログを記録することができます。 そうすることで改変されてないことを確認できるようになります。 開発者に手続きを守らせる 開発者全員が従順で、監督をしなくても決められたとおりに開発手順を守ってくれるのであればよいのですが、そういうわけにはいきません。特に優秀な開発者は手順を省略するのがうまく、効率化を旗印にどんどん手順を変更していきます。署名等を行うことは監査上重要なのですが、どうしても面倒くさくなって省略されがちです。 CI/CDビルドパイプラインの固定、標準化 ビルド、デプロイの自動化のためCI/CDパイプラインを使用するのが一般的になっています。しかし、現実的に多くのCI/CDパイプラインはそれぞれのプロジェクトで善意の開発者による維持、メンテナンスがされており、きちんとした管理ができているかわからない場合もあるのではないかと思います。 昨今のモダンと言われるCI/CDサーバーの多くはgitのリポジトリ上にCI/CDの設定ファイルを置くことでCI/CD中に何を行うのかの定義ができます。DevOpsの考え方の元、開発者が柔軟にビルドプロセスを変更することができるようになっています。しかしながら、それでは問題がある場合があります。 優秀な開発者は多くの場合、CI/CDに対する知見があり、柔軟にCI/CDを変更することで開発の効率化を行っていきます。CI/CD内で絶対に行わなくてはならないと決められていることを、開発者が勝手に削除してしまう場合もあり、問題になります。 先ほど、ビルドしたアプリケーションバイナリに署名をしようという話をしましたが、CI/CDパイプライン内で署名を自動的に行えるように設定していたとします。しかし、開発者がビルドパイプラインを勝手にいじれるようになっている場合は、その署名行為が必ず行われることを保証できません。 CI/CDパイプラインに関わる設定ファイルをgit内に保持する必要のあるCI/CDサーバーの場合、gitリポジトリのエイリアスを作る等で、設定ファイルを開発者から保護することもできますが、Trusted Application Pipelineに含まれる Developer Hub(backstage) を使用するとCI/CDパイプラインに関わる設定を開発者から分離した形でテンプレート( Golden Pathと呼ばれます )として保持することができ、OpenShift(Kubernetes)上に開発者が変更できない形でデプロイすることができます。 開発環境で標準化されたソフトウェアのみを使用する 開発環境に開発者が自由にソフトウェアをインストールすることができる場合、当然マルウェアが混入する可能性があります。そこを起点として本番稼働中のアプリケーションなどに影響が出ることがあります。そのため、開発者のPCには自由にソフトウェアを入れられないようにすることが望ましいです。この試み自体は昔から行われていて、簡単な方式であれば MicrosoftのActive Directoryを使用してソフトウェアを配布 します。それ以外にも シンクライアント端末 という形で標準化されたソフトウェアのインストールされた環境をサーバー上に作り、開発者からはそこにアクセスさせ、クリーンな環境で開発をさせるという事が行われていました。現在はクラウドベンダーが同じような形で環境を提供しており、 Amazon WorkSpaces や Azure Virtual Desktop などがあります。ただ、これらはいわゆるリモートデスクトップで接続する形なので、リッチなGUIが必要であり、サーバー側のリソースが潤沢に必要になるという問題があります。 最近では、 Visual Studio Code が言語を問わない開発のデファクトスタンダードの一つになっているということと、Visual Studio CodeがJavaScriptで開発されており、WebからアクセスできるようなフォークされたOSS( Eclipse Che 等)が出てきたため、簡易なシンクライアント環境としてVisual Studio CodeをSaaSとして提供するような GitHub Codespaces のようなサービスが登場しています。 Red HatでもEclipse Cheをベースにした Red Hat OpenShift Dev Spaces という製品があり、OpenShift上でVisual Studio Codeベースのシンクライアント開発環境を提供しています。Developer HubにはRed Hat OpenShift Dev Spacesのテンプレートを提供する機能もあり、開発者に統一された開発環境を提要できます。Javaで開発している場合は歴史的にEclipseやNetBeans、IntelliJといったパワフルなIDEがあり、それらに比べるとどうしても弱いところはあるのですが、コアチームを覗いた大多数の開発者向けとしては一考する余地があります。 署名の検証、正しいプロセスを踏んでいるかの確認 先ほど、アプリケーションバイナリに署名をしようという話をしましたが、正しく署名されているかについてはデプロイ前に確認する必要があります。デプロイするアプリケーションはただしいビルドプロセスを踏んでいるのかも確認したいです。そのためにTrusted Application Pipelineに含まれる Enterprise Contract の機能を使用することができます。 多くの製品では署名が行われており、インターネットからファイルをダウンロードする場合にはファイルのシグネチャ(CRC/SHA-1等)が提供されている場合もありますが、きちんと確認されているでしょうか？インターネットからダウンロードしたファイルが正しいものであるという証明をしているでしょうか？ Enterprise Contractではアプリケーションの署名の検証や、正しい手順で作られたアプリケーションであるかの確認などをすることができます。 Enterprise Contractではその他にも多数のチェックを行うことができます。詳細については以下のURLを参照してください。 enterprisecontract.dev 正しいサードパーティー製ライブラリを使用する 先に述べたとおりに、現在のソフトウェアは多くのサードパーティー製ライブラリに依存しています。それらに脅威が含まれていないことを確かにする必要があります。 信頼できるリポジトリを使用する Javaで言えばMaven、JavaScriptで言えばnpm等のパッケージマネージャーを使用されていると思いますが、そのパッケージマネージャーはどこのリポジトリからライブラリを取得しているかご存知でしょうか？そのリポジトリは誰が運用して、いつまで運用される予定かを気にしたことはありますか？ライブラリがリポジトリにどのように公開され、どのように非公開となる可能性があるかを気にしたことはありますか？ ライブラリがビルドできることを保証し続けるためにはそれらを確認する必要があります。また、ライブラリの取得先の永続性が保証されるかわからないので、 JFrog Artifactory や Sonatype Nexus Repository 、Red Hat OpenShift Platform Plusに含まれる Quay 等のリポジトリソフトウェアを使用して、リポジトリ自体を社内にコピーする必要があります。 どのライブラリを使用しているか明らかにする アプリケーションが依存しているライブラリのすべてのソースコードをユーザー側が確認し、脅威が含まれていないことを確認するのは現実的ではありません。しかし、OSSである場合には第三者の評価機関がCVEとして驚異の情報を公開してくれています。プロプライエタリである場合は最低限信頼できる組織や人が作成した、もしくは信頼できる組織や人が検証したライブラリであること、OSSである場合は一般的な経路を通って、第三者機関がきちんと検査できる状態になっているもののみを使用する必要があります。最近SBOM（ソフトウェア部品構成表）というのが話題に上がっているのはご存知でしょうか。 経済産業省からSBOMを使用して依存ライブラリを管理するように手引きが発行されています。 www.meti.go.jp SBOMは簡単に言えば、どのライブラリに依存しているのかをしっかり管理しようという標準規格のファイルです。 SBOMを作成するツールはたくさんありますが、Trusted Application Pipelineに含まれる syft でSBOMを作成することができます。Syftでは各言語の仕組みをハックして情報を取得してくれます。 SBOMは言語に依存しない汎用的な形式ですが、JavaでMavenを使用している場合はpom.xmlファイルがそのまま部品表となります。どのライブラリに依存しているかは先に示した通りに以下のコマンドで表示できます。 mvn devendency:tree さらに詳細な情報まで必要な場合は以下のコマンドで表示することができます。(HTMLが生成されます。) mvn site mvn site 使用しているライブラリに脅威が含まれていないかをモニタリングする 依存しているライブラリに脆弱性が含まれていないかを絶えずチェックする必要があります。また、大きな脅威が見つかった場合には過去にさかのぼって脅威が含まれていなかったかどうか、いつから含まれていたか等を確認する必要が出てきます。 GitHubやGitLab等ではそのまま依存関係のバージョン管理からチェックまで行ってくれます。 Trusted Application Pipelineに含まれる Trusted Profile Analyzer でもチェックを行うことができます。Trusted Profile AnalyzerではSBOMを履歴として保管しておくこともできるので、特に法令でSBOM対応が必要な場合にはちょうどよくなっています。GitHubやGitLab等を使用する場合は設定によってはカジュアルに履歴を改変できる可能性がある点についてはご注意ください。 なお、Trusted Profile Analyzerと同等の機能はRed Hat Dependency Analyticsという名前でプレビュー版がVSCodeのプラグインとして無償で公開されています。Maven等を使用している場合はそのままチェックができるので試してみてください。 marketplace.visualstudio.com 本番環境で怪しい振る舞いがないか確認をする 本番環境はユーザー、その他からアクセスされる環境なので、脅威が発覚しやすい環境です。怪しい挙動がないかを逐次確認することで、開発環境に素早くフィードバックすることができます。各種ベンダーが出しているアンチウィルスソフトを導入したり、Tripwire等のファイル変更検知ソフトウェアを使用したりします。Red Hatの場合はOpenShift Platform Plusに含まれる Red Hat Advanced Cluster Security for Kubernetes を使用する事で実行中のコンテナに含まれる脅威を検知することができます。また、OpenShiftではルートレスコンテナという仕組みを使用し、そもそも外部から混入した怪しいアプリケーションが実行しにくいようになっています。 まとめ この記事では開発環境にどのような脅威が存在するか、それに対する一般的なソリューション及びRed Hat Trusted Software Supply Chain/Trusted Application Pipelineで何が行えるのかについて紹介しました。具体的にどう設定していくべきかについてはそれぞれの環境に合わせて検討していく必要があります。 個別のソリューションはあるもののRed Hat Trusted Software Supply Chain/Trusted Application Pipelineほどの網羅性があるものはあまりないのかなという印象があります。 Red Hat Trusted Software Supply Chain/Trusted Application Pipelineは既存のCI/CDパイプラインにも部分で気に導入できる柔軟性の高さが特徴です。すでに他の製品を導入している場合でも部分的に機能を選択して導入することができます。既存の社内ルールにあわせて柔軟に対応することもできます。 また、そもそも現在の開発環境のセキュリティがどうなっているかわからないから調査して改善の支援までしてほしい、トータルで支援してほしい等もRed Hatコンサルティングにより可能です。 ぜひお問い合わせください。 誤字指摘thx! @henrich

Red Hatの森若です。 Red Hat Enterprise Linux(RHEL) 9.5 にて、opensslが 3.0.x から 3.2.x にリベースされています。 Red Hat Enterprise Linux 9.5 リリースノート >> 4.2. セキュリティー RHEL 9.0から9.4まで提供されていたopenssl 3.0.x ライブラリを利用したまま、 RHEL 9.5 の openssl 3.2.x ライブラリを想定したアプリケーションを使おうとする(またはその逆)と問題がある可能性があります。 たとえばpostfixではライブラリのバージョンを確認しているので、以下のような警告が出ます。(動作に問題がないためこのメッセージ出力自体は特に問題ではありません。) warning: run-time library vs. compile-time header version mismatch: OpenSSL 3.0.0 may not be compatible with OpenSSL 3.2.0 古いopensshと新しいopensslの組み合わせでは以下のようなエラーとともに起動に失敗します。 OpenSSL version mismatch. Built against 30000070, you have 30200020 混在した状態での利用について RHELでは、あるエラータはそれ以前の全てのエラータが適用されている前提でのみテストされています。 つまり、opensslとアプリケーションの新旧リリースでの組み合わせについて「その組みあわせはテストされていないのでどうなるかはわからない。全部更新したほうがいいよ」としか言えません。当然「動作する」とは言えませんし「どんな問題が起きるの？」と聞かれてもわかりません。 新旧を混在させて問題が発生するような場合は、 まず関連するパッケージ全てを更新して問題が再現するかの確認をお願いします。 RHELでは新旧リリースを混在させず、全てのパッケージについて最新バージョンを利用することをお勧めします。 結論 つまり何が言いたいかというと「アップデートするときはパッケージ単位ではなく全部最新にしよう」といういつもの話でした。 # yum update -y

LogFileMetricExporter カスタムリソースを見てみる はじめに LogFileMetricExporter 収集できるメトリクス ダッシュボードで確認 Top producing containers Top producing containers in last 24 hours DaemonSet の定義をみる ソースをみる まとめ LogFileMetricExporter カスタムリソースを見てみる はじめに 今年も残り僅かとなりました。OpenShift Advent Calendar 2024 24日目の記事です。年の瀬のお忙しい中お立ち寄りありがとうございます。 qiita.com LogFileMetricExporter 本記事では、OpenShift Cluster Logging 5.8 から collector から分離された Exporter について見ていきます。製品ドキュメントでは以下のように記載されています。 In logging version 5.8 and newer versions, the LogFileMetricExporter is no longer deployed with the collector by default. You must manually create a LogFileMetricExporter custom resource (CR) to generate metrics from the logs produced by running containers. If you do not create the LogFileMetricExporter CR, you may see a No datapoints found message in the OpenShift Container Platform web console dashboard for Produced Logs. デプロイするのであれば、LogFileMetricExporter カスタムリソースを定義する必要があります。 このカスタムリソースがない場合は、Web Console のダッシュボード に ProducedLog が表示されないとのことです。 どんな情報がとれるのでしょうか。 Configuring the logging collector - Logging | Observability | OpenShift Container Platform 4.16 収集できるメトリクス 実際にデプロイしてどんなメトリクスを収集できるか見てみみます。 特別要件がないため、ドキュメントにあるサンプルをそのまま活用します。 apiVersion: logging.openshift.io/v1alpha1 kind: LogFileMetricExporter metadata: name: instance namespace: openshift-logging spec: nodeSelector: {} resources: limits: cpu: 500m memory: 256Mi requests: cpu: 200m memory: 128Mi tolerations: [] 定義すると、 logfilesmetricexporter が現れ、各ノードに metricexporter が起動してきました。 NAME READY STATUS RESTARTS AGE cluster-logging-operator-75bfb4b58c-xclvh 1/1 Running 0 8h collector-5pcnz 1/1 Running 0 14m collector-7mwlt 1/1 Running 0 14m collector-hs62g 1/1 Running 0 14m collector-j66g8 1/1 Running 0 14m collector-mrw6g 1/1 Running 0 14m logfilesmetricexporter-8gkfx 1/1 Running 0 14m logfilesmetricexporter-hb5hb 1/1 Running 0 14m logfilesmetricexporter-hn9sm 1/1 Running 0 14m logfilesmetricexporter-qwvqx 1/1 Running 0 14m logfilesmetricexporter-v86x5 1/1 Running 0 14m logging-loki-compactor-0 1/1 Running 0 3h37m logging-loki-distributor-5b4756f5bb-pc8dc 1/1 Running 0 3h37m logging-loki-gateway-5f67b59847-n55z9 2/2 Running 0 3h37m logging-loki-gateway-5f67b59847-rxrhx 2/2 Running 0 3h37m logging-loki-index-gateway-0 1/1 Running 0 3h37m logging-loki-ingester-0 1/1 Running 0 3h37m logging-loki-querier-d666d57c-x4qjt 1/1 Running 0 3h37m logging-loki-query-frontend-7c78459847-b4xfw 1/1 Running 0 3h37m logging-loki-ruler-0 1/1 Running 0 3h37m logging-view-plugin-7597965997-rmb9w 1/1 Running 0 5h57m メトリクスのエンドポイントは、Observe > Targets で確認したところ、 https://<pod ip>:2112/metrics でした。 メトリクス情報を収集してみます。Pod に乗り込んでエンドポイントにアクセスします。 $ oc rsh logfilesmetricexporter-8gkfx sh-5.1# sh-5.1# curl -sk https://localhost:2112/metrics # HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles. # TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 5.6023e-05 go_gc_duration_seconds{quantile="0.25"} 0.000183166 go_gc_duration_seconds{quantile="0.5"} 0.000266248 go_gc_duration_seconds{quantile="0.75"} 0.00034949 go_gc_duration_seconds{quantile="1"} 0.001925796 go_gc_duration_seconds_sum 0.004054525 go_gc_duration_seconds_count 10 # HELP go_goroutines Number of goroutines that currently exist. # TYPE go_goroutines gauge go_goroutines 14 # HELP go_info Information about the Go environment. # TYPE go_info gauge go_info{version="go1.22.7 (Red Hat 1.22.7-1.el9_5)"} 1 # HELP go_memstats_alloc_bytes Number of bytes allocated and still in use. # TYPE go_memstats_alloc_bytes gauge go_memstats_alloc_bytes 4.524896e+06 # HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed. # TYPE go_memstats_alloc_bytes_total counter go_memstats_alloc_bytes_total 1.8430024e+07 # HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table. # TYPE go_memstats_buck_hash_sys_bytes gauge go_memstats_buck_hash_sys_bytes 7742 # HELP go_memstats_frees_total Total number of frees. ... 情報が多いので間引くと以下のような感じです。（go に関するメトリクスは省きました） メトリクス 説明 メトリクスタイプ log_logged_bytes_total Total number of bytes written to a single log file path, accounting for rotations counter process_cpu_seconds_total Total user and system CPU time spent in seconds. counter process_max_fds Maximum number of open file descriptors. gauge process_open_fds Number of open file descriptors. gauge process_resident_memory_bytes Resident memory size in bytes. gauge process_start_time_seconds Start time of the process since unix epoch in seconds. gauge process_virtual_memory_bytes Virtual memory size in bytes. gauge process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes. gauge promhttp_metric_handler_requests_in_flight Current number of scrapes being served. gauge promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code. counter 色々ありますが、メインのメトリクスは log_logged_bytes_total になりそうです。 ローテーションを考慮した単一のログファイルパスに書き込まれた合計バイト数 です。 これを見ることで、コンテナごとにどのくらいのログを出力したのかを確認できそうです。 ダッシュボードで確認 このメトリクスは、前述したようにWeb Console のダッシュボードですでにグラフ表示が内蔵されています。 ダッシュボードを開いてみます。Observe > Dashboard の順に開き、 Logging/Collection ダッシュボードを開きます。 ダッシュボードの中程に Produced Logs という項目があります。 Top producing containers と Top producing containers in last 24 hours というグラフがあります。 Top producing containers グラフのクエリ情報は以下となっており、ログの出力が多い順に 10 個のコンテナの時系列データを眺めることができます。 topk(10, round(rate(log_logged_bytes_total[5m]))) Top producing containers in last 24 hours topk(10, sum(increase(log_logged_bytes_total[24h])) by (exported_namespace, podname, containername)) 一方で、こちらは24時間以内の増加情報をもとに、ログ出力が多い順に 10 個のコンテナ情報をリストにしています。 DaemonSet の定義をみる どのような方法で確認しているかを見ていきます。DaemonSet の定義をみます。 $ oc describe ds logfilesmetricexporter Name: logfilesmetricexporter Selector: component=logfilesmetricexporter,logging-infra=logfilesmetricexporter,provider=openshift Node-Selector: kubernetes.io/os=linux Labels: app.kubernetes.io/component=logfilesmetricexporter app.kubernetes.io/instance=logfilesmetricexporter app.kubernetes.io/managed-by=cluster-logging-operator app.kubernetes.io/name=lfme-service app.kubernetes.io/part-of=cluster-logging app.kubernetes.io/version=5.8.0 component=logfilesmetricexporter implementation= logging-infra=logfilesmetricexporter pod-security.kubernetes.io/enforce=privileged provider=openshift security.openshift.io/scc.podSecurityLabelSync=false Annotations: deprecated.daemonset.template.generation: 1 Desired Number of Nodes Scheduled: 5 Current Number of Nodes Scheduled: 5 Number of Nodes Scheduled with Up-to-date Pods: 5 Number of Nodes Scheduled with Available Pods: 5 Number of Nodes Misscheduled: 0 Pods Status: 5 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: app.kubernetes.io/component=logfilesmetricexporter app.kubernetes.io/instance=logfilesmetricexporter app.kubernetes.io/managed-by=cluster-logging-operator app.kubernetes.io/name=lfme-service app.kubernetes.io/part-of=cluster-logging app.kubernetes.io/version=5.8.0 component=logfilesmetricexporter implementation= logging-infra=logfilesmetricexporter pod-security.kubernetes.io/enforce=privileged provider=openshift security.openshift.io/scc.podSecurityLabelSync=false Annotations: target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"} Service Account: logfilesmetricexporter Containers: logfilesmetricexporter: Image: registry.redhat.io/openshift-logging/log-file-metric-exporter-rhel9@sha256:daa8fa30560a787835f7f3fa6d584555ddf8f10beda023a1d747b1f7ab8e2d36 Port: 2112/TCP Host Port: 0/TCP Command: /bin/bash Args: -c /usr/local/bin/log-file-metric-exporter -verbosity=2 -dir=/var/log/pods -http=:2112 -keyFile=/etc/logfilemetricexporter/metrics/tls.key -crtFile=/etc/logfilemetricexporter/metrics/tls.crt -tlsMinVersion=VersionTLS12 -cipherSuites=TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-CHACHA20-POLY1305,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-GCM-SHA384 Limits: cpu: 500m memory: 256Mi Requests: cpu: 200m memory: 128Mi Environment: <none> Mounts: /etc/logfilemetricexporter/metrics from lfme-metrics (ro) /var/log/containers from varlogcontainers (ro) /var/log/pods from varlogpods (ro) Volumes: varlogcontainers: Type: HostPath (bare host directory volume) Path: /var/log/containers HostPathType: varlogpods: Type: HostPath (bare host directory volume) Path: /var/log/pods HostPathType: lfme-metrics: Type: Secret (a volume populated by a Secret) SecretName: lfme-secret Optional: false Priority Class Name: system-node-critical Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CreateObject 38m logfilemetricexporter CreateObject DaemonSet openshift-logging/logfilesmetricexporter Normal SuccessfulCreate 38m daemonset-controller Created pod: logfilesmetricexporter-hn9sm Normal SuccessfulCreate 38m daemonset-controller Created pod: logfilesmetricexporter-hb5hb Normal SuccessfulCreate 38m daemonset-controller Created pod: logfilesmetricexporter-v86x5 Normal SuccessfulCreate 38m daemonset-controller Created pod: logfilesmetricexporter-qwvqx Normal SuccessfulCreate 38m daemonset-controller Created pod: logfilesmetricexporter-8gkfx HostPath を利用して /var/log/containers や /var/log/pods のディレクトリ配下を確認しているようです。 ソースをみる ソースコードを探してみます。Red Hat Ecosystem Catalog で log file metric exporter を検索すると以下のコンテナイメージにたどり着きます。 https://catalog.redhat.com/software/containers/openshift-logging/log-file-metric-exporter-rhel9/6447991f3270b32a256c4e2a?gs=&q=log%20file%20metric&container-tabs=technical-information Technical Information のタブを開くと、ソースコードは https://github.com/ViaQ/log-file-metric-exporter にあることがわかります。 ソースコードで実際に処理をしていそうなところは、 watcher.go でした。 https://github.com/ViaQ/log-file-metric-exporter/blob/main/pkg/logwatch/watcher.go#L123 stat, err := os.Stat(path) if err != nil { return err } if stat.IsDir() { log.V(3).Info("Ignoring path given it is a directory", "path", path) return nil // Ignore directories } defer w.mutex.Unlock() w.mutex.Lock() lastSize, size := w.sizes[l], float64(stat.Size()) log.V(3).Info("Stats", "path", path, "lastSize", lastSize, "size", size) w.sizes[l] = size var add float64 if size > lastSize { // File has grown, add the difference to the counter. add = size - lastSize } else if size < lastSize { // File truncated, starting over. Add the size. add = size } stat 情報を取得し、ファイルサイズを確認。前回より増えていれば増分を追加。減っていたら新たなファイルとして、サイズを追加ということを繰り返しています。 この部分がローテーションを考慮したということなのでしょうか。 まとめ LogFileMetricExporter により分割された Exporter について確認をしました。 分割されたのはコンテナが出力するログ量を計測していたメトリクスです。ダッシュボードが定義されていたため、LogFileMetricExpoter リソースを定義しない場合はグラフは表示されませんが、どのような値が出力されるかを確認することができました。 LogFileMetricExporter について不明点がなくなりすっきりしました。これで年を越せるでしょうか。

みなさん本当にメリークリスマス｡Red Hatのさいとうです｡ Ansible Advent Calendar 2024 の今年最後の記事です｡例年､最終日の記事では､翌年の予想をしているのですが､昨日のよこちさんの 記事 で紹介されていたとおり､AWXのリニューアル工事が進行中で来年の予想がさっぱりつきません｡もう今年は来年の予想をあきらめました｡来年はおとなしく運命を受け入れるのみです｡ そういったわけで､今日の記事では､来年の安定したAnsibleライフに向けて開発環境をコンテナに移行してみたというお話をしようかと思います｡ 大掃除の時期です 僕は､Ansibleのエンジン部分やモジュール･プラグインの不具合の調査､そして修正を生業としています｡その合間に､ansible.posixコレクションのメンテナとしての仕事もしています｡ このメンテナとしての仕事用に開発環境を作っているのですが､ここ数年の激務で､心も開発環境もだいぶ荒れてきたので､2025年のアップストリーム活動に向けて､コレクションの開発とテストを行う環境を大掃除してコンテナに移行しようと試行錯誤しています｡紆余曲折を経て､そこそこ使い物になりそうな環境ができたので､ここでご紹介しようと思います｡ アドカレは毎年書いてますが､誰かの参考になりそうな記事は初めて書くかもしれない｡ Ansible Collectionの日常的な開発･テスト環境を作る 開発環境 RedHatterなのですが開発環境はMacOSです｡ごめんなさい｡ MacBook Pro 16インチ (Apple M2 Pro / MEM 32GB) エディタ: Visual Studio Code コンテナ環境: Podman Desktop このような環境の上に開発環境を構築しています｡いやpodmanを使うならLinux(x86)ですよね｡MacOSとaarch64でわざわざ苦労することもない｡わかります｡わかりますよ｡ しかし､Red Hatは自由な社風なので､僕はMacOSで暮らしてます｡自由万歳｡ ワークスペースを作成する まずは開発拠点となるVisual Studio Codeのワークスペース用のディレクトリを作成します｡以降はこのワークスペースである ansible_dev ディレクトリで作業します｡ % mkdir ansible_dev % cd ansible_dev Ansible Builderをインストールする まずはカスタムコンテナをビルドするために､virtualenv環境を作ってAnsible Builderをインストールします｡ % mkdir builder % cd builder % python3 -m venv venv % source venv/bin/activate (venv) % pip install -U pip (venv) % pip install ansible-builder 続いて､ execution-environment.yml を作成します｡ できるだけ特別なことはせずに､必要となるパッケージ(rsyncのようにsynchronizeモジュールが必要とするようなもの)やPythonモジュール(デバッグ用のqなど)をインストールする程度にしています｡Ansible NavigatorとAnsible-lintをインストールしているくらい｡ --- version : 3 images : base_image : name : quay.io/fedora/fedora:41 dependencies : ansible_runner : package_pip : ansible-runner ansible_core : package_pip : ansible-core python : - ansible-lint - ansible-navigator - bcrypt - passlib - pexpect - psutil - pypsrp - pywinrm - q - six system : - bind-utils [ platform : rpm ] - gcc [ platform : rpm ] - git [ platform : rpm ] - glibc-langpack-en [ platform : rpm ] - hostname [ platform : rpm ] - iputils [ platform : rpm ] - lsof [ platform : rpm ] - oniguruma-devel [ platform : rpm ] - plocate [ platform : rpm ] - podman [ platform : rpm ] - procps-ng [ platform : rpm ] - rsync [ platform : rpm ] - shellcheck [ platform : rpm ] - sshpass [ platform : rpm ] - sudo [ platform : rpm ] - tar [ platform : rpm ] - tree [ platform : rpm ] - traceroute [ platform : rpm ] options : package_manager_path : /usr/bin/dnf5 additional_build_steps : prepend_base : - RUN echo "Install mandatory packages:" - RUN $PKGMGR -y -q install python3 python3-pip python3-devel - RUN pip install --upgrade pip append_final : - ENV LANG en_US.UTF-8 - ENV LC_ALL en_US.UTF-8 - RUN echo "Create ansible user with sudo privilege:" - RUN useradd -m -s /bin/bash ansible && echo "ansible ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/ansible && chmod 0440 /etc/sudoers.d/ansible ... 開発･テスト用のコンテナ(ansible-dev-tool)をビルドする execution-environment.yml を利用して､Ansible Builderでカスタムコンテナを構築します｡ (venv) % ansible-builder build -f execution-environment.yml -t quay.io/saito_hideki/ansible-dev-tools:1.0.0 --no-cache --prune-images (venv) % podman images REPOSITORY TAG IMAGE ID CREATED SIZE quay.io/saito_hideki/ansible-dev-tools 1.0.0 7de76c4274f6 58 seconds ago 1.06 GB quay.io/fedora/fedora 41 75628098827e 23 hours ago 194 MB (venv) % deactivate これで､カスタムコンテナは完成です｡quay.ioにpushして､必要に応じて修正していくことになるので､quay.ioにpushしておきます｡ % podman push quay.io/saito_hideki/ansible-dev-tools:1.0.0 Visual Studio Codeのワークスペースファイルを作成する ansible_dev ディレクトリにもどって､ワークスペースファイル(ansible_dev.code-workspace)を作成します｡中身はpathだけです｡ % cat << EOF > ansible_dev.code-workspace { "folders": [ { "path": "." } ] } EOF Visual Studio Code Dev Containers環境を設定する VIsual Studio CodeのDev Containersを利用するので､ devcontainer.json を作成します｡ Ansible Navigatorでは､podmanコンテナの実行環境を動かすので､podman in podmanを想定した設定をrunArgsに設定しています｡Ansible Builderで作成したカスタムコンテナを指定するのも忘れずに｡ また､ここでは､テスト環境として準備してある切られ役のマネージドノード3台(server0[012].example.com)をコンテナの/etc/hostsに追加するよう設定しています｡この設定を基本として目的によって設定を編集すればよさそうです｡ % mkdir .devcontainer % cat << EOF > .devcontainer/devcontainer.json { "name": "ansible-dev-container-podman", "image": "quay.io/saito_hideki/ansible-dev-tools:1.0.0", "containerUser": "ansible", "runArgs": [ "--privileged", "--cap-add=CAP_SETUID", "--cap-add=CAP_SETGID", "--cap-add=CAP_MKNOD", "--cap-add=CAP_NET_RAW", "--cap-add=NET_ADMIN", "--cap-add=SYS_ADMIN", "--cap-add=SYS_RESOURCE", "--cap-add=CAP_AUDIT_WRITE", "--device=/dev/fuse", "--security-opt=seccomp=unconfined", "--security-opt=label=disable", "--security-opt=apparmor=unconfined", "--security-opt=unmask=/sys/fs/cgroup", "--userns=host", "--hostname=ansible-dev-container", "--add-host=server00.example.com:172.16.46.100", "--add-host=server01.example.com:172.16.46.101", "--add-host=server02.example.com:172.16.46.102" ], "mounts": [ ], "customizations": { "vscode": { "extensions": ["redhat.ansible"] } } } EOF Visual Studio Codeでワークスペースを開く 準備ができたら､Visual Studio Codeで ansible_dev.code-workspace を開きます｡ワークスペースが開いてビルドしたカスタムコンテナが起動してきます｡ ファイル => ファイルでワークスペースを開く => ansible_dev.code-workspace 右下に表示されるダイアログボックスからコンテナーで再度開くを選択する VSCODE_DEV_CONTAINER ターミナルから動作確認 Visual Studio Codeのターミナルを開くと､コンテナ内のシェルが操作できるようになっています｡母艦のワークスペースが置かれている ansible_dev ディレクトリは､コンテナの /workspaces/ansible_dev にマウントされています｡ [ansible@ansible-dev-container ansible_dev]$ cat /etc/fedora-release Fedora release 41 (Forty One) [ansible@ansible-dev-container ansible_dev]$ id uid=1000(ansible) gid=1000(ansible) groups=1000(ansible) [ansible@ansible-dev-container ansible_dev]$ pwd /workspaces/ansible_dev 動作確認もかねて､ansible系のコマンドのバージョンを確認してみます｡ $ ansible --version ansible [core 2.18.1] config file = None configured module search path = ['/home/ansible/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/local/lib/python3.13/site-packages/ansible ansible collection location = /home/ansible/.ansible/collections:/usr/share/ansible/collections executable location = /usr/local/bin/ansible python version = 3.13.1 (main, Dec 9 2024, 00:00:00) [GCC 14.2.1 20240912 (Red Hat 14.2.1-3)] (/usr/bin/python3) jinja version = 3.1.5 libyaml = True [ansible@ansible-dev-container ansible_dev]$ ansible-navigator --version ansible-navigator 24.12.0 [ansible@ansible-dev-container ansible_dev]$ ansible-runner --version 2.4.0 [ansible@ansible-dev-container ansible_dev]$ ansible-lint --version ansible-lint 24.12.2 using ansible-core:2.18.1 ansible-compat:24.10.0 ruamel-yaml:0.18.6 ruamel-yaml-clib:None podman in podmanに対応しているはずなので､念のためpodmanコマンドも機能するかを確認しておきしょう｡ [ansible@ansible-dev-container ansible_dev]$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES [ansible@ansible-dev-container ansible_dev]$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE いけてそう｡ Playbookの動作確認もしてみます｡ ansible.cfg､invenotryファイル(inventory/hosts)､そしてテスト用のPlaybook(playbook/ping.yml)を準備しましょう｡ ansible.cfg [defaults] log_path = ./logs/ansible.log host_key_checking = False collections_path = ./collections inventory/hosts [testserver] server00.example.com server01.example.com server02.example.com [testserver:vars] ansible_user='testuser' ansible_password='****************' playbook/ping.yml --- - name : Ping all hosts hosts : all tasks : - name : Ping all hosts ansible.builtin.ping : テスト用のPlaybookを実行してみます｡ [ansible@ansible-dev-container ansible_dev]$ ansible-playbook -i inventory/hosts playbook/ping.yml PLAY [Ping all hosts] ************************************************************************************************************************** TASK [Gathering Facts] ************************************************************************************************************************* ok: [server02.example.com] ok: [server01.example.com] ok: [server00.example.com] TASK [Ping all hosts] ************************************************************************************************************************** ok: [server00.example.com] ok: [server02.example.com] ok: [server01.example.com] PLAY RECAP ************************************************************************************************************************************* server00.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 server01.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 server02.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Ansible Navigatorでコンテナ実行環境をテストする せっかくpodman in podman環境を準備したので､Ansible Navigatorもテストしてみます｡実行環境のコンテナとして awx-ee を指定してみました｡ ansible-navigator.yml --- ansible-navigator: execution-environment: image: "quay.io/ansible/awx-ee:latest" logging: level: debug append: False file: ./logs/navigator.log Ansible Navigatorでテスト用Playbookを実行してみます｡ [ansible@ansible-dev-container ansible_dev]$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE [ansible@ansible-dev-container ansible_dev]$ ansible-navigator run playbook/ping.yml --mode stdout -i inventory/hosts $ ansible-navigator run playbook/ping.yml --mode stdout -i inventory/hosts ---------------------------------------------------------------- Execution environment image and pull policy overview ---------------------------------------------------------------- Execution environment image name: quay.io/ansible/awx-ee:latest Execution environment image tag: latest Execution environment pull arguments: None Execution environment pull policy: tag Execution environment pull needed: True ---------------------------------------------------------------- Updating the execution environment ---------------------------------------------------------------- Running the command: podman pull quay.io/ansible/awx-ee:latest Trying to pull quay.io/ansible/awx-ee:latest... Getting image source signatures Copying blob da67aebfb456 done | ... Copying config 9083553381 done | Writing manifest to image destination 90835533812f20b995b153861ab5806f58aa184856559380acc58b3910166b8e PLAY [Ping all hosts] ********************************************************** TASK [Gathering Facts] ********************************************************* ok: [server02.example.com] ok: [server00.example.com] ok: [server01.example.com] TASK [Ping all hosts] ********************************************************** ok: [server00.example.com] ok: [server01.example.com] ok: [server02.example.com] PLAY RECAP ********************************************************************* server00.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 server01.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 server02.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 念のため､コンテナ実行環境であるawx-eeがダウンロードされていることを確認してみます｡ [ansible@ansible-dev-container ansible_dev]$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE quay.io/ansible/awx-ee latest 90835533812f 6 hours ago 2.2 GB ちゃんとできてそう｡良い感じだ｡今回ご紹介したワークスペースのディレクトリ構造(Level2まで)は以下のような感じです｡ % tree -L 2 . ├── ansible-navigator.yml ├── ansible.cfg ├── ansible_dev.code-workspace ├── builder │   ├── context │   ├── execution-environment.yml │   └── venv ├── collections │   └── ansible_collections ├── inventory │   └── hosts ├── logs │   ├── ansible.log │   └── navigator.log └── playbook └── ping.yml まとめ 今回ご紹介したように､開発環境をコンテナに移行することにしました｡ansible-testコマンドのコンテナランタイムでのテストがまだうまく動作しなかったり､MacOSとpodmanとの組み合わせゆえの面倒くささなどはありますが､その都度対処しながら､アップデートがあれば､この場でシェアしていきたいと思っています(いまのところ)｡ 2025年は､このコンテナ環境で暮らしながら､アップストリームに貢献する時間をもう少し作りたいな｡それではみなさんメリークリスマス&ハッピーニューイヤー｡そしてHappy Automating! :)

【2026年1月追記】最新の情報を元に内容をアップデートしました！ こんにちは、Red HatでOpenShift関連のプリセールスをしている北村です。 前回の記事でDeveloper Hubのインストールが完了したので、今回はGitHubと連携してDeveloper Hubの認証を実装します。 【第1回】Developer Hubをインストールしてみよう 【第2回】GitHubを使用した認証を実装しよう ←この記事 【第3回】GitLabを使用した認証を実装しよう 【第4回】Componentを作成・登録しよう 【第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう 【第6回】TechDocsを作成・登録しよう 【第7回】Golden Pathの実装をマスターしよう - 前編 【第8回】Golden Pathの実装をマスターしよう - 後編 前回の状態 前回ログイン画面まで表示されることを確認しましたが、この状態でGitHubの"Sign In"を選択すると、以下のようなエラーが表示されます。 これはまだGitHubとの連携情報がDeveloper Hubに設定されていないために発生しています。 ではGitHub認証を実装していきましょう。 Developer Hub GitHub 認証 実装手順 GitHubでの認証を実現するために、GitHub Appの作成を行います。 ここでGitHubの個人アカウントでGitHub Appを設定するとそのユーザーのみ認証可能になりますが、Organizationで登録することで、そのOrganization配下のユーザー全員が認証可能になります。 Developer Hubは複数の開発メンバーでの利用を想定されるケースが多いので、ここでは新たにOrganizationを作成して、そのGitHub Appを登録します。 GitHubの設定 GitHub Organizationは以下の公式URLを参考に作成してください。おそらくすでにOrganizationが存在するケースが多いので、ここでは手順を割愛します。 新しい Organization をゼロから作成 - GitHub ドキュメント 今回は"rhdh-practice"というOrganizationを作成しました。 次にGitHub Appを作成していきます。OrganizationのページからSetttings→Developer settings→GitHub Apps→New GitHub Appを選択します。 以下の内容を入力します。 GitHub App name 任意の値 Homepage URL https:// (Developer HubのURL) Callback URL https:// (Developer HubのURL) /api/auth/github/handler/frame Webhook URL https:// (Developer HubのURL) (Webhook) Secret 任意の値 Permissions 以下の項目にRead-onlyを付与 Repository permissions - Commit statuses - Dependabot alerts - Deployments - Pull Requests - Webhooks Organization permissions - Members 以下の項目にRead and writeを付与 Repository permissions - Administration - Contents - Workflows Where can this GitHub App be installed? Only on this account 入力が完了したらCreate GitHub Appを選択します。 するとGitHub Appが作成され、App ID , Client IDが払い出されます。 そのままGenerate a new client secretを選択すると画面上にClient Secretが払い出されるため、 App ID , Client ID , Client Secret をコピーして手元に残しておきましょう。 そして画面の下の方にいき、 Generate a private key を選択すると、Private Keyが払い出され、pemファイルがダウンロードされます。この中身を後ほど使います。 ここまで完了したら、最後に作成したGitHub appをOrganizationにインストールします。左側のメニューから Insatall App を選択してインストールを実行します。 これでGitHub側の準備は完了しました。 Developer Hub の設定 GitHub側の設定が完了したので、次にDeveloper Hub側の設定を行います。 まずはGitHub Appの情報を、前回の記事で作成した secrets-rhdh.yaml に反映します。 GITHUB_PRIVATE_KEY_FILE にはpemファイルの中身を記載します。 secrets-rhdh.yaml apiVersion : v1 kind : Secret metadata : name : secrets-rhdh namespace : rhdh stringData : # Backstage Settings BASE_URL : "https://backstage-developer-hub-rhdh.apps.<ROSAドメイン>" BACKEND_SECRET : "<バックエンド認証キー>" SESSION_SECRET : "<セッションシークレット>" # 任意。　node -e "console.log(require('crypto').randomBytes(64).toString('base64'))"などで取得 # GitHub Settings AUTH_GITHUB_CLIENT_ID : "<GitHub App Client ID>" AUTH_GITHUB_CLIENT_SECRET : "<GitHub App Client Secret>" GITHUB_APP_ID : "<GitHub App ID>" GITHUB_APP_CLIENT_ID : "<GitHub App Client ID>" # AUTH_GITHUB_CLIENT_IDと同じ値でOK GITHUB_APP_CLIENT_SECRET : "<GitHub App Client Secret>" # AUTH_GITHUB_CLIENT_SECRETと同じ値でOK GITHUB_WEBHOOK_URL : "https://backstage-developer-hub-rhdh.apps.<ROSAドメイン>" GITHUB_WEBHOOK_SECRET : "<Webhook Secretに設定した任意の値>" GITHUB_PRIVATE_KEY_FILE : | -----BEGIN RSA PRIVATE KEY----- [ PRIVATE_KEY_PLACEHOLDER ] -----END RSA PRIVATE KEY----- このSecretをデプロイします。 oc apply -f secrets-rhdh.yaml 次にDeveloper Hubの設定ファイル app-config-rhdh.yaml を編集します。以下のように、 auth , integrations , signInPage の設定を追加します。 auth : Developer Hubの認証に関する設定 integrations : GitHubなどの外部システムとの統合（連携）に関する設定 signInPage : ログインするときに表示されるサインインページを指定する設定 app-config-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : app-config-rhdh namesapce : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : app-config-rhdh.yaml : | backend : auth : externalAccess : - type : legacy options : secret : “${BACKEND_SECRET}” subject : legacy-default-config baseUrl : ${BASE_URL} cors : origin : - ${BASE_URL} app : title : Red Hat Developer Hub baseUrl : ${BASE_URL} analytics : segment : enabled : false auth : environment : production session : secret : ${SESSION_SECRET} providers : github : production : clientId : ${AUTH_GITHUB_CLIENT_ID} clientSecret : ${AUTH_GITHUB_CLIENT_SECRET} signInPage : github integrations : github : - host : github.com apps : - appId : ${GITHUB_APP_APP_ID} clientId : ${GITHUB_APP_CLIENT_ID} clientSecret : ${GITHUB_APP_CLIENT_SECRET} webhookUrl : ${GITHUB_APP_WEBHOOK_URL} webhookSecret : ${GITHUB_APP_WEBHOOK_SECRET} privateKey : | ${GITHUB_APP_PRIVATE_KEY} このConfigmapをデプロイします。 oc apply -f app-config-rhdh.yaml するとDeveloper Hub Podが再起動されるので、立ち上がるまで待ってからDeveloper Hubにアクセスしてみましょう。 こんな感じで、Guestのログイン項目がなくなり、GitHubのみでのログイン画面になりました。 Sign Inを選択してログインしてみると... エラーが出るのだが😡 はい、実はまだ他に対応しなければならないことがあります。 GitHubからUser情報を取得する Developer Hubではユーザー認証の際、Auth Provider（先述で設定してきたもの）による認証行為に加えて、Developer Hub内に紐付け可能なUser Entityが存在するかどうかもチェックします。 先ほどのエラーはGitHubとの認証連携自体はできたものの、Developer Hub側で紐づけるべき User という エンティティ(Entity) が存在しないために発生しているエラーになります。 （なおDeveloper Hubにおける Entity については、次回の記事で詳しく説明していきます。） そしてこのUser Entityというのは、Developer HubのPluginを活用することで、GitHubのOrganizationからユーザー情報を取得することができます。 イメージとしては以下のような形になります。 では設定していきましょう。 まず、GitHub Organizationから User / Team 情報を読み取り、Developer Hubに User / Group Entity を作成する GitHub Org というPluginを導入します。 前回の記事でしれっと作成した dynamic-plugins-rhdh.yaml にdynamic pluginのインストール設定を記入します。 plugins : Developer HubにインストールするPluginの情報を記載する。 package にはdynamic pluginのパスを記載する disablded を false にすることで、Podのinit処理時にdynamic pluginをインストールする。 今回は GitHub Org Pluginをインストールするので、 GitHub Org Pluginが格納されているパスを指定しています。 Developer Hubにあらかじめ格納されているdynamic pluginの一覧やパスは以下の公式ドキュメントに記載があります。 動的プラグイン参照 | Red Hat Developer Hub | 1.8 | Red Hat Documentation dynamic-plugins-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : dynamic-plugins-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : dynamic-plugins.yaml : | includes : - 'dynamic-plugins.default.yaml' plugins : # GitHub Plugins - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic disabled : false 次に app-config-rhdh.yaml に設定を追記します。 Developer Hubでは app-config に適切な設定を記述すると、連携先のシステム（今回で言うとGitHubそのもの）やGitリポジトリ内にあるyamlファイルから、内部に登録するEntity情報を取得することができます。 なお、このEntityを登録するための仕組みをDeveloper Hubでは Catalog といいます。 Catalog と Entity は厳密には別物ですが、ほぼ同じものと捉えてもらって構いません。 今回は以下の項目を追記しましょう。 catalog : Developer Hubにさまざまな Entity(Catalog) を登録するための設定 catalog.providers : Entity(Catalog) のデータを取得するための Provider(GitHubやGitLabなど) に関する設定 catalog.providers.githubOrg : 特定のGitHub Organization内のUserやTeam情報をもとにDeveloper Hub側に User / Group Entityを作成するための設定 app-config-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : app-config-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : app-config-rhdh.yaml : | backend : ...omit... app : ...omit... auth : ...omit... signInPage : github integrations : ...omit... catalog : providers : githubOrg : githubUrl : 'https://github.com/${GITHUB_ORG}' id : production orgs : [ '${GITHUB_ORG}' ] schedule : frequency : PT60S initialDelay : PT30S timeout : PT120S schedule フィールドは、GitHubへ定期的にアクセスしてOrganizationの情報を取得するためのパラメータです。 ここはpluginによって記述方法が変わります。今回の GitHub Org Pluginでは ISO 8601 Duration 形式 で記述する必要があります。 ISO 8601 Duration 形式の書き方は以下を参照ください。 P2Y3DT6H8M！？ この暗号を解読するための ISO 8601 duration specification とは | 株式会社AMG Solution 今回は実装中のため、1分ごとにGitHub Organizationの情報を取得するような設定にしています。 安定稼働後は1時間に一回程度に変更することをおすすめします。 最後に secrets-rhdh.yaml も修正して GITHUB_ORGANIZATION を追加しておきましょう。 secrets-rhdh.yaml apiVersion : v1 kind : Secret metadata : name : secrets-rhdh namespace : rhdh stringData : ...omit... GITHUB_ORG : "<今回使うGitHub Organization名>" これらをデプロイします。 oc apply -f app-config-rhdh.yaml -f secrets-rhdh.yaml -f dynamic-plugins-rhdh.yaml これらの設定によって、Developer Hubが定期的にGitHubへアクセスし、GitHub Organization内のUserやTeamの情報を User Group Entityとして内部に登録する処理が行われます。 Podの再起動後、ログインしてみると、無事にHOME画面が表示されます。 ちなみにこの状態で画面左下の Settings を選択すると、ちゃんとGitHubのユーザーでDeveloper Hubにログインできていることがわかります。 おわりに 今回はGitHubと連携してDeveloper Hubの認証を実装する方法を解説しました。 次回の記事では、同様の認証作業をGitLabを使って実装してみます。乞うご期待！

はじめに Ansible - Qiita Advent Calendar 2024 - Qiita の12/23 の記事になります(4時間遅れ) Red Hatでコンサルタントをしている山下です。 今回の記事では2024年10月にリリースされたAAP 2.5 でアップデートされたEvent-Driven Ansible (EDA) の新機能を紹介させていただきます。 1.イベントのルーティングがさらに簡単に！ AAP 2.5からWebhookを利用したイベントルーティングを簡素化することができる、「イベントストリーム」という新しい仕組みが導入されました。 これにより、イベントソースを複数のルールブックに接続するプロセスが大幅に効率化されます。 抑えておきたいポイント： 単一のエンドポイントで管理が可能になりました。 以前は、ルールブックごとに新しいエンドポイントを設定する必要がありましたが、今では1つのエンドポイントで複数のルールブックに対応できます。 副次的ではありますが、ファイアウォールに開けるポート数が減り、保守作業も簡単になります。 あらかじめ用意された各種サービス向けのWebhook対応が設定をより簡潔にしてくれます。 例：ServiceNow、ソースコード管理（SCM）ツール、監視ツールなど。 活用例： ネットワーク障害のアラート数が閾値を超えた際、自動でデータセンターをフェイルオーバー。 新しいコードをリポジトリにプッシュした際、Webサーバーを自動リロード。 一定期間利用されていない仮想マシンを自動でアーカイブし、リソースを回収。 2. 高スケーラビリティと高可用性 AAP 2.4ではHAオプションが提供されていませんでしたが、AAP 2.5から複数のEvent-Driven Ansibleノードをインストールできるようになり、高可用性を実現しました。 これにより、システム障害が発生しても自動化ジョブが継続され、業務が止まるリスクを軽減することができるようになります。 EDAはとても便利な半面、自動化が進むと共に重要度もますコンポーネントです。 例えば自動的に障害を検知してフェイルオーバーをするような処理をEDAに行わせている場合にEDAが実は障害で動作しておらずWebhookを受け取っていなかった、などということがあれば大問題に発展してしまいます。 そういった問題を解決するためにAAP 2.5ではHAサポートを行い、堅牢なシステムへと進化を遂げました。 抑えておきたいポイント： スケーラブルなルールブック運用。 水平スケーリングにより、負荷が高いユースケースにも対応可能。 障害発生時のリスクを低減。 ミッションクリティカルなルールブックも安全に運用可能。 3. セキュリティと運用性の強化 AAP2.5からールブックで使用する認証情報やVault変数を安全に管理できるようになり、暗号化されたデータを活用で切るようになります。 またPlatform Gatewayの導入によりAAP全体で統一された認証メカニズムを導入し管理を簡素化し、統合されたRBACの適用がEDAにも行えるようになりました。 主なメリット： エンタープライズ環境での安全性向上 機密情報を暗号化し、セキュリティリスクを低減。 4. 実際に動かしてみた！ これから新たに追加されたEvent streamを作成してみます。 Event streamを作成するためには認証情報の登録が必要になります。 今回の例ではBasic認証を追加しています。 認証情報の作成 次にEvent streamを作成していきます。今回はBasic認証のEvent stream typeを選択します。 Event streamの作成 使用できるEvent stream typeの一覧はこちらから確認できます。 Event streamでサポートしているEvent stream type Event streamが作成されるとEndpointが払い出されます。 Event streamのendpoint このEndpointに対してRequestを投げることでJob templateの実施が可能になります。 次にEvent streamに紐づけるrulebookの登録を行います。 rule bookは以下のコードを用意しました、内容はいたってシンプルでEvent stream「basic」に対してRequestが来たらevent.payload.messageをパースし中に記載されている内容が"Ansible is super cool"であった場合は「Demo Job Template」を実施すると言ったものです。 --- - name: Listen for events on a webhook hosts: all sources: - name: 'basic' rules: - name: Say Nyahello condition: event.payload.message == "Ansible is super cool" action: run_job_template: name: Demo Job Template organization: Default こちらのrulebookをGUIから登録していきます。 AAP2.5の新たなポイントはEvent stream(s)に先ほど作成したbasicを指定しているところになります。 新機能の紹介でもさせていただいた通り、複数のrulebookとEvent streamを1:nの関係で紐づけることができるようになりました。 rulebookの登録 早速先ほど作成したEndpointに対してRequestを発行してみます。 curl -k -X POST https://aap4.local:443/eda-event-streams/api/eda/v1/external_event_stream/24bba765-d2d2-47a6-a343-d6fb54c92f5f/post/ -u "admin:admin" -H "Content-Type: application/json" -d '{"message": "Ansible is super cool"}' 実際にEventが実施されたことが確認できました！ Say Nyahello 5. まとめ 今回のAAP 2.5でのEDAの進化により、エンタープライズ環境でのイベント駆動型自動化がさらに強力かつ安全に運用できるようになりました。Webhookを活用した効率的なイベントルーティング、高可用性のアーキテクチャ、そしてセキュリティ管理の強化により、複雑なユースケースにもシンプルな構成で対応可能になったと思います！ これらの新機能を活用し、運用の効率化と安定性を高めてみてはいかがでしょうか？

はじめに 本記事は、OpenShift Advent Calendar 2024 の12月23日の記事です。 皆様、こんにちは！ レッドハットのミニチュア工場の工場長、大塚から情報をお届けします。 出展: イラストや レッドハットでは、オフィスにミニチュア工場を導入し、IT（情報技術）とOT（運用技術）の技術を融合した便利なソリューションを創出していきます。 実際に工場が動いている様子など、詳細は以下の記事をご参照ください。 rheb.hatenablog.com ご挨拶 レッドハットのミニチュア工場、工場長の大塚と申します。 普段は、製造業のお客様を中心にプリセールス活動をしています。 ハードウェアや Edge が大好きなことがご縁となり、工場長をやらせてもらっています。 ミニチュア工場を題材とした情報やメンテナンス方法なども発信していきますので、どうぞよろしくお願いします。 ミニチュア工場とは ミニチュア工場は、ドイツ発祥の fischertechnik 社 が提供している、実際の製造現場で利用されている制御機器 (PLC：プログラマブル・ロジック・コントローラ) を接続し、リアルな生産ラインをレゴブロックで忠実に再現したものです。 見た目にインパクトがあり、精巧に作られたミニチュア工場は、大人から子供まで思わず足を止め、興味津々でじっくり見てくれます。 動きのある仕組みやリアルな制御システムが、製造業の魅力やテクノロジーへの好奇心を引き出し、イベントや展示会でも大きな注目を集めています。 イベントでの展示をきっかけに、多くの方々がミニチュア工場の魅力に引き込まれ、実際に購入される企業様も増えたと感じています。 ミニチュア工場 PLC ミニチュア工場のコンセプト ミニチュア工場は、単なる「簡単・すぐにできる」といったお気軽なアイテムではなく、工学の基礎や製造技術を深く学ぶための高度な教育商材です。リアルな生産ラインを模した構造やメカニズムが搭載されており、組み立てやメンテナンスを通して実践的な知識や技術を習得できます。 組み立ての説明書が存在しないため、部品が外れたり緩んだりした場合、自ら考え、試行錯誤しながら解決策を見つける必要があります。この過程で、単に手を動かすだけでなく、論理的思考力や応用力、創造的なアイデアが自然と養われます。さらに、現場さながらの問題解決を繰り返すことで、実際の製造現場で求められる課題解決能力や耐久性のあるエンジニアリングスキルが身につきます。 このように、ミニチュア工場は単なる学習ツールにとどまらず、次世代のエンジニアや技術者の育成、さらにはリーダーシップやチームワークの向上にも貢献する、非常に価値のあるものと感じています。 ミニチュア工場の利用価値 ミニチュア工場は、製造現場のトレーニングツールや教育コンテンツとしての活用はもちろん、社内の啓蒙活動や技術展示会でのデモにも最適です。さらに、IoTやエッジコンピューティング、AI技術の導入シミュレーションとしても利用でき、現場改善や新技術の検証を効率的に行えます。 また、顧客向けプレゼンテーションや技術研修でのデモを通じて、スマートファクトリーの概念や自動化技術の魅力を直感的に伝えることができ、社内外の理解促進や技術浸透に大きく貢献できると感じています。 特に実物を利用したデモは非常に効果的で、資料だけでは伝わりにくい部分やモヤモヤを解消してくれると思います。 ミニチュア工場のメンテナンス ミニチュア工場は、動かせば動かすほど実際の製造現場さながらのメンテナンスが必要になります。 特に、摩耗しやすい箇所や可動部分には、定期的にシリコンスプレーを吹き付けて、スムーズな動きと長寿命化を維持する必要があります。 シリコンスプレーは、潤滑性が高くゴミやホコリが付着しにくいため、頻繁に稼働させるミニチュア工場に最適です。 一方で、グリスを使用すると、時間が経つにつれ固形のゴミやホコリを巻き込んでしまい、動作不良や部品の劣化を引き起こす可能性があります。そのため、シリコンスプレーによる定期的なメンテナンスが推奨されています。 こうしたメンテナンスを行うことで、機械工学の基礎や保守管理の重要性を体感し、実際の生産現場で必要とされる運用スキルや問題解決能力が自然に身につけることができます。 先日、 Edge Tech+ 2024 のイベントに出展した際、オフィスから現地へ移動した後、ミニチュア工場の搬送用アームが途中までしか動かないトラブルが発生しました。 その際は、部品の調達が間に合わなかったため、瞬間接着剤を使用して復旧を試み、なんとか場をしのぎました。 （瞬間接着剤を使用する際は、爪楊枝の先端に液体を少量付け、バリが発生しないよう注意しないと、アームが完全に動かなくなってしまうため、細心の注意が必要です！） このような経験を積むことで、臨機応変な対応力や、どんな状況でも「何とかする」という強い気持ちも鍛えることができます。 まとめ 本稿では、レッドハットがミニチュア工場を導入した背景や、活用方法についてご紹介しました。 ミニチュア工場は、製造業のリアルな課題やソリューションを体感できるだけでなく、エッジコンピューティングや自動化技術、AI連携の可能性を視覚的に理解できる教育・デモンストレーションツールとしても非常に効果的です。 「実際に見てみたい」「動かしてみたい」と感じた方は、ぜひレッドハットのオフィスへお越しください！ 次回は、最新の画像AI技術を組み込んだミニチュア工場へとアップデート予定です。AIによるリアルタイム検品や異常検知など、より高度なスマートファクトリー体験を創出いたしますので、どうぞご期待ください！

1. はじめに 2. IT/OT融合の動向 IT（情報技術）とOT（運用技術）の「融合」とは レッドハットの取り組み PLCをソフトウェアで定義する ①PLCのハード故障時の駆けつけ保守のコスト削減 ②ハードウェア集約によるハードウェアコストの削減や、配線変更のしやすさの向上 ③変種変量生産の生産能力の向上!? そして、妄想は尽きない... Linux Foundation配下に「margo」設立 3. ソフトウェアファーストでミニチュア工場をスマート化してみよう！ ミニチュア工場について簡単に解説 1. 自動倉庫 2. 搬送ロボット 3. 加熱装置 4. 研磨装置 5. 仕分け装置 デモの解説 アプリのインストール アプリの設定作業の自動化 ITシステムと設備の連携 まとめ 1. はじめに 本記事は、OpenShift Advent Calendar 2024 の12月23日の記事です。 みなさん、こんにちは。 ソリューションアーキテクトの小野です。 エッジコンピューティング厨です。 突然ですが… 我々はついにオフィスに工場を導入しました！ どーん！ おもちゃのミニチュアですが、実際の工場で使用されているPLCという設備で動作するようになっています。 いや〜、ハードウェアって、格好良いですね！ この工場の導入の背景には、昨年、ドイツのとある製造業のお客様の工場を見学させていただいたことにあります。その工場がとても刺激的で、その知見を日本に持ち帰って、みなさまに日本でも簡単に体験してもらえる環境を作れないかな、と思ったのがきっかけです。 昨今、製造業においても、市場のニーズや世界情勢の変化へ臨機応変に対応することが求められています。 その中で、従来の”カイゼン”による生産性向上に加えて、柔軟性や持続可能性の向上には、デジタル技術の活用が不可欠です。リーン生産によるカイゼンを継続するだけでは、どうしても限界があります。 そこで、IoTやAIなどのITの技術と、ロボットなどに代表されるOT（Operational Technology）の技術をシームレスに統合した、 IT/OT融合 、という考え方が着目されています。 本記事では、 IT/OT融合の定義 と、 世の中の動向を俯瞰 した上で、僕たちが導入したミニチュア工場を通じて、 レッドハットの実現するIT/OT融合の世界の片鱗を簡単に体験 いただきたいなと思います。 本記事が、みなさんのIT/OT融合のイメージを具体化するお役立ちができたら幸いです。 2. IT/OT融合の動向 IT/OT融合というキーワードについて、インターネット上でさまざまな記事が存在します。 関係者の方は見聞きする機会も多いんじゃないでしょうか。 ただ、僕自身、この言葉を見て思ったのは、「融合と連携の違いってなんだろう」ということです。ネットでさまざまなスマートファクトリーの記事を目にします。でも、これって、融合なのかな、と。ここ数年ずっと考えてきました。 そこで、前述のドイツ出張の体験も踏まえて自分なりに整理してみたいと思います。 IT（情報技術）とOT（運用技術）の「融合」とは IT/OT「融合」…融合というからには、 それぞれの独立した領域を保ちながら、データやシステムの一部を「共有」して、 業務の効率化や生産性の向上を目的に、究極的にはITとOTの双方のスペシャリティを持った同一または仮想的なチームで推進すること くらい言っても良いじゃないでしょうか。 一方で、IT/OT「連携」というと、なんとなく、ITのチームとOTのチームがそれぞれ疎結合な印象を受けます。融合と連携では、微妙にゴールが違う気がするんです。 連携のゴールは、 ITとOTがそれぞれの「独自性を保ちながら協力する」 こと であるのに対し、 融合は、 ITとOTの境界がなくなり、一体化したシームレスなシステムやプロセスとして機能する状態を目指す こと …なイメージです。 もう少し言うと、 連携のゴールは、 業務の効率化や迅速な意思決定 融合のゴールは、 より高度な自律化や、スマートファクトリーなどの先進的なシステムの実現 にあると言えます。 みなさんは、「連携」ですか？それとも、「融合」ですか？ ちなみに、IT/OT融合なOT製品とは、もはやITの影を感じることのないくらい当たり前にITが溶け込んでるOT製品、ということなのかも...汗 レッドハットの取り組み こんなIT/OT融合の取り組みにおいて、レッドハットは何ができるのか？僕らとしては、やっぱり、みなさんにもっとアプリケーションに集中して欲しい！と思うわけです。 今年、「 ソフトウェアファースト 」という書籍の第二版が出版されたりしました。ハードとソフトが密結合して、ハード単位で提供される製品が多い組み込みの世界こそ、そして、こと日本においては、特にソフトウェアファーストという考え方が重要なんじゃないか！と、個人的に強く思います。 ITでもOTでも、アプリケーションを試しながら試行錯誤を早く回し、良いものはすぐに他の拠点へスケールしてノウハウを伝播できる…そんな体験を軸にして、スマートファクトリーを効率良く推進できるようにするのが、レッドハットのソリューションの基本です。言い方を変えれば、縁の下の力持ち的なポジションです。 そこで、レッドハットでは、IT/OT融合のプラットフォーム、というコンセプトで、お客様が、ITのアプリケーションもOTのアプリケーションも、共通のプラットフォーム上で動作させ、効率良く運用できるソリューションを提供します。 僕は、このプラットフォームで得られる体験を、よく「スマホみたいな世界観」と言います。 例えば、スマホアプリを試すみたいに、みなさんが使用している産業用パソコンへ、産業用のソフトウェアを簡単に配備でき、機能の改善やセキュリティパッチの適用、機能の追加を柔軟に行えたら、色々な運用課題に対処できそうじゃないですか？ こんなスマホみたいな世界観は、まさに産業オートメーション製品で実現されようとしています。 PLCをソフトウェアで定義する レッドハットは、昨年より、Intel、レッドハットと、グローバルのコントロールベンダの3社で、Virtual PLCの実現を推進しています。 www.redhat.com www.redhat.com Virtual PLCは、従来、専用ハードウェアで提供されてきたPLCを、汎用ハードウェア、つまり産業用PC上のソフトウェアとして提供する取り組みです。 従来のPLCは、専用のWindowsのクライアントツールとして提供されるIDEを用いて制御プログラムを開発し、IDEからPLCに、開発した制御プログラムを書き込んで動作させるのが一般的です。ちなみに、制御プログラムの動作環境はRTOSが採用されます。 Virtual PLCは、その制御プログラムやプログラムの実行環境をコンテナイメージの単位でパッケージ化し、PodmanやMicroShift（小型デバイス向けの軽量OpenShift）といったコンテナの管理環境へ展開されます。また、コンテナ化に伴い、IDEもWeb IDEになってたりします。 すでに、 Codesys や Schneider Electric といった企業が、Virtual PLCの提供を開始しました。 www.codesys.com www.redhat.com なお、PLCのような決定論的なワークロードを汎用Linuxで安定して動作させるために、 Intel ECI(Edge Controls for Industrial) というオープンソースの提供するドライバの利用が推奨されます。参考までに、こちらの ホワイトペーパー をリンクしておきます。 PLCの制御プログラムをコンテナ化することで、制御プログラムの展開の柔軟性の向上や展開作業の効率化が可能です。でも、PLCの制御プログラムの展開が柔軟になると何が嬉しいの？と思うかもしれません。 このメリットは大きく3つがよく取りあげられます。 ①PLCのハード故障時の駆けつけ保守のコスト削減 従来のPLCで、HA構成を組むことが可能な製品も少なくありません。たとえば、ハードウェアが1台故障した際に、予備系のPLCが主系へ昇格し、設備の稼働を継続させる、という具合です。しかし、電力プラントなど、無人の環境で、かつ全断による社会的影響が大きいような設備では、ダウンタイムの長期化は命取りです。故に、PLCが片系運転となった際は、早期に両系運転へ復帰できるように、人が現地へ駆けつけて、故障したPLCを交換する作業を行っていたりします。 この課題に対し、PLCがコンテナとして動作して制御プログラムの展開を効率良く行えることで、たとえば、予備系のハードを2台以上配置し、片系運転のリスクを回避することができます。 これにより、故障したPLCを、まとめて決められた日に一括交換する、といった対応が可能になります。 その結果、人の派遣コストを減らし、コストを最適化できるよね？という点が、一つ目のメリットです。 www.youtube.com www.redhat.com ②ハードウェア集約によるハードウェアコストの削減や、配線変更のしやすさの向上 PLCは一般に、工程毎やロボットなどの設備毎に配置されます。そして、PLCと設備の間には、多くの配線が複雑に絡み合っているのをよく目にします。工場のフィールドには、多くのハードウェアが存在し、その管理はとても煩雑です。 実際、我々のミニチュア工場の環境は、せいぜい10台くらいのハードウェアしかないのに、すでに配線が複雑怪奇になりつつあります。片付けられない人がチームにいないので、なんとか救われてますが... ハードウェアが増えると、もちろん配線も更に複雑になってくるので、ラインの組み替えなど、配線変更が伴うような作業が一筋縄ではいきません。よく、夏休みの間にライン組み替えに対応しているお話を耳にしますが、将来的にその頻度が多くなってくると、それだけ設備の稼働率に響いてきます。 Virtual PLCは、コンテナとして共通のハードウェア環境で複数台のPLCを実行できることで、必要なハードウェアの数を減らし、ハードウェアの管理コストの削減につながります。そして、ハードウェアが減るに伴って、配線を簡素化でき、それがダウンタイムの短縮につながり、設備稼働率の向上に寄与する、という点が二つ目のメリットです。 ③変種変量生産の生産能力の向上!? 昨今、顧客のニーズへ柔軟に対応するために、同じシリーズの製品でも、製品毎に仕様が異なるということが珍しくありません。製品の品種が多いと、それだけ、製造計画にばらつきが生まれます。たとえば、今日は品種Aが100台、品種Bが500台、明日は品種Aを10,000台製造する、と言うように、日によって製造台数が異なるようなケースがあり得ます。 いわゆる 変種変量生産 に対応するために、大量生産に向いてるライン生産でなく、セル生産への切り替えが進められています。 セル生産を自動化するために、多くのロボットの整備が進められています。しかし、従来のPLCでは、どうしてもロボット一台に対して、一つの役割しか持たせることができません。 変種変量生産で大量生産に対応するためにはどうすれば良いでしょうか？...そう、大量のロボットを整備すれば良いのです(爆)。 しかし、現実には、ロボットへの投資規模が大きくなりコストが最適化されない、また、ロボットを設置するスペースが枯渇する、電気代も高くなる…、といった問題も出てきます。 そこで、Virtual PLCです。 コンテナのメリットにより、制御プログラムの変更や更新を柔軟に行えるならば、ロボット一台の役割を柔軟に変更し、一台の同じロボットに複数の異なる仕事を任せることができるんじゃないか...？ということで、そのような期待の元、海外の一部の企業でもPoCの動きがチラ見えし始めています。 Virtual PLCが、既存のロボットの再利用性を向上させる...僕個人は、 まるでロボットのリソースプール化や！ と、一人で勝手に興奮を抑えられない模様です。 そして、妄想は尽きない... このような「スマホみたいな世界観」の実現する姿は、「アプリを色々試しやすくなる」だけではありません。 さらにでかいことを言うと、Amazonや楽天のように、スマホアプリで商品を注文すると、いつまでに商品が手元に届くのか瞬時に画面に表示され、実際に配達される…こんな世界観が製造業のサプライチェーンでも実現できたら、多くの企業の競争力の向上に繋がりませんか？ 僕は最近ユニクロのUTime!というスマホアプリで、ペットの犬のオリジナルTシャツを作るのにハマっています。 スマホアプリでTシャツのデザインをして、オーダーボタンを押すと、いつまでにTシャツが届くのかスマホアプリに表示されます。 こんな世界観が、もっと多くのモノづくりに広がったら、世の中変わる気がします。 実際の製造業では、営業からの注文オーダが入ってから、さまざまな工程で人手による確認と調整が行われます。ロットの生産計画の確認、部品表から部品在庫の確認、設備や人のスケジュールの作成、設備へのセットアップ、原価への反映、製品価格の確定、流通計画、などなど… それらが裏で全て自動化されるイメージです。つまり、製品を納品するまでに介在する人による確認・調整のプロセスが、データ連携で自動化される世界観の実現です。これは、エンドユーザに対して圧倒的なリードタイムを提供し、エンドユーザの体験を変容することになる…まさに、製造DXの究みじゃないか！！ しかし、現実はそう簡単ではありません。 こんな夢のようなサプライチェーンを構築するには、企業間のデータ共有も必要となります。 これは、なかなかハードルが高いなぁ...と。 そうした企業間のデータ共有のあり方は、欧州の Manufacturing-X というデータ共有基盤の構築を図るプロジェクトで推進されています。でも、いきなり企業間でデータを共有し合う姿を目指すのはなかなか勇気が要ります。故に、最初はもちろん自社内がスコープになりますよね。 アプリだけでなく、データ連携を効率化し、IT（経営、計画）とOT（現場）をシームレスにしていく活動も、製造DXの重要な取り組みです。この部分は、レッドハットの提供する様々なミドルウェア製品が色々役に立つのですが、その話はまた今度、深掘りしたいと思います。 Linux Foundation配下に「margo」設立 そんな中、今年、Linux Foundation配下に、突如「margo」というプロジェクトが設立されました。これは、グローバルの様々なコントロールベンダーが推進するプロジェクトで、オープンな技術をベースとしたプラットフォームの相互運用性を実現する、標準化の取り組みです。 現状は、以下の図にあるような構成の元で、プラットフォームのインタフェース仕様が定義されています。ぱっと見わかる方にはわかると思いますが、コンテナやKubernetesといったクラウドネイティブな技術がベースとなってます。 ハードウェアビジネスからソフトウェアビジネスへ、モノ売りからコト売りへのシフト…そのような新たなビジネスモデルへの挑戦に向けて、産業オートメーションの変革がまさに議論されてます。 margo.org 3. ソフトウェアファーストでミニチュア工場をスマート化してみよう！ 長々とIT/OT融合の動向を書いてしまいましたが...汗 みなさん、ここからが本番です！ ここからは、みなさんに、IT/OT融合によるソフトウェアファーストな世界観を簡単に体験してもらいたいと思います。 本デモの目的と流れは以下です。 デモは、以下の動画から視聴できます！ ショート版は1.5分で概要だけわかるようにしてます。 詳細を見てみたい方はフル版をご視聴ください。(11分程度あります) ショート動画(約1.5分): www.youtube.com フル動画(約11.5分): youtu.be ⚠︎音声付きですので注意！また、字幕ONで見ていただくと見やすいかなと思います。 ミニチュア工場について簡単に解説 ミニチュア工場についての解説は、弊社の工場長が以下のブログを書いてくれてます。詳細は、こちらをご参照ください！ rheb.hatenablog.com ここでは、デモを理解いただく上で、最低限の情報をまとめておきます。 まず、ミニチュア工場は、大きく5つの設備で構成されています。 1. 自動倉庫 倉庫には、赤・青・白の3色のボールが3つずつ、合計9つあります。これらのボールを一つずつ出庫し、搬送ロボットへ引き渡す工程です。デフォルトでは、白のボールから出庫し、白が3つ出庫されたら、赤が出庫される。赤の出庫が終われば、青が出庫される...というように、白、赤、青の優先度でボールを出庫するように実装されています。この辺の、出庫したいボールの色の優先度は、PLC内のパラメータを変更することで、調整できます。 2. 搬送ロボット 搬送ロボットは、倉庫から出庫されたボールを加熱装置へ引き渡す工程です。 3. 加熱装置 加熱装置では、ボールごとに決められた秒数だけ、擬似的に加熱処理を行います。加熱時間は、PLC内のパラメータで管理されていますが、デフォルトでは変更できません。 強制的に変更することは可能です 4. 研磨装置 研磨装置では、ボールごとに決められた秒数だけ、擬似的に研磨処理を行います。研磨時間は、加熱装置と同様に、PLC内のパラメータで管理されていますが、デフォルトでは変更できません。 強制的に変更することは可能です) 5. 仕分け装置 最後に、仕分け装置は、研磨加工したボールを、赤、青、白の決められた箇所に仕分けして格納する工程です。ボールの色の特定には暗明センサーが使用されます。 この5つの装置が連携して、ミニチュア工場が動作します。 工場の動作には、三菱電機の MELSEC Qシリーズ を使用し、同様に三菱電機の表示器である GOT を使用して、PLCのパラメータの変更や工場の稼働・停止を制御できます。また、Red Hat Device Edgeをインストールするデバイスとして、本デモでは、 Advantech UNO-137 を使用しています。 PLCのデータを取得するためには、制御プログラムが、PLC内の各レジスタを、どのような用途で利用しているのか、事前に把握しておく必要があります。一般に、PLCの制御プログラムを実装する際には、各レジスタの用途をコメントとして残しておくと思います。このコメントをPLCのIDEからエクスポートして、以下のように、エクセルか何かで整理しておくことをオススメします。 ちなみに、このミニチュア工場では、2106点くらい使用しています。 なお、ミニチュア工場には、倉庫からボールを出す出庫モードと、仕分けされたボールを倉庫へ戻す入庫モードの2つのモードが実装されていますが、本デモでは出庫モードのみ使用しています。 最後に、ミニチュア工場の動作フロー (出庫時) をまとめると、以下の通りです。 以降、本デモの構成やどう実装しているのかについて簡単に解説します！ デモの解説 アプリのインストール みなさんが初めてスマホを手にした時って、どんなことを試しましたか？ 多くの方は、App Storeなどにどんなアプリがあるのか眺めてみて、面白そうなアプリをインストールして試してみたと思います。 このように、ソフトウェアファーストでは、アプリをすぐに試せるようにする仕組みがとても重要です。 本デモでは、その仕組みを、 Red Hat OpenShift と Red Hat Device Edge を連携させて実現しています。 以下に、簡単な構成を示します。 OpenShiftには、自身の外側にある複数のKubernetes環境を一元管理する「Red Hat Advanced Cluster Management for Kubernetes(RHACM)」という機能があります。RHACMは、OpenShiftの追加機能として提供され、管理対象の環境にラベルを付与して、そのラベルを指定することで、どの環境にアプリを配信するのか制御できます。 本デモでは、産業用PCにインストールされたRed Hat Device Edgeを、RHACMの管理下に置き、産業用PC毎に固有のラベルを付与して、アプリを配信する対象の産業用PCを特定する、という仕組みで実装されています。 また、OpenShiftには、もともとアプリをカタログとして公開する機能があります。このカタログの機能を活用し、RHACMの設定を固めて、OpenShift上にカタログとして公開することで、カタログの操作で、産業用PCへアプリを配信することができます。 一方、Red Hat Device Edgeは、「MicroShift GitOps」という、Gitリポジトリに配置されたアプリの構成情報をデバイスへ同期するためのコントローラをオプションとして提供しています。この仕組みを使うと、アプリの管理者がアプリをカタログとしてOpenShift上に公開した後、アプリの細かい修正や機能追加をしたいときに、再度カタログへ修正版を公開し、ユーザのカタログ操作で更新してもらうのでなく、管理者自身で人知れず行いたい、というケースに対応できます。 つまり、本デモでは、以下のシナリオでアプリを運用することとしています。 アプリの大きな更新は、アプリの管理者が修正版をカタログに公開し、ユーザがセルフサービスで実際のアプリケーションに適用する（App Storeでアップデートボタンを押すイメージ） ユーザに気づかれない様に細かい修正を反映したい、という際は、アプリの管理者が、Gitリポジトリ上のアプリの構成情報を修正する（スマホアプリのWebviewで表示されるコンテンツが、微妙に更新されるイメージ） このような、Gitリポジトリでの管理や操作を中心に、アプリを運用する方法を「GitOps」と呼びます。 ここまでの情報を整理すると、一つ目のデモでは、以下の流れで、産業用PCへのアプリの配信を実現しています。 RHACMが産業用PCを管理し、各デバイスにはそれぞれラベルが付与されている ユーザは、カタログの操作の中で、ラベルを指定し、インストールボタンをクリックする 指定されたラベルに対応する産業用PCへ、MicroShift GitOpsの設定が配信される 産業用PCは、適用されたMicroShift GitOpsの設定に基づき、Gitリポジトリからアプリの構成情報を取得する 産業用PCは、MicroShiftの機能を使って、取得した構成情報に基づき、アプリを起動する アプリの設定作業の自動化 よくあるエンタープライズ向けの業務アプリは、インストールした後、アプリの設定作業が必要です。 だけど、スマホアプリって、インストールしたら特に難しい設定もなく、すぐに利用できますよね？ アプリを簡単に利用できるようにするには、設定作業を自動化して、人のスキルギャップを埋めたり、アプリを利用開始するまでの時間を短縮したりする工夫がとても大切です。 レッドハットは、IT/OT融合プラットフォームに対応するアプリを増やすために、多くのパートナーさんとの協業を進めています。その中でも、今回のデモは、「 たけびし 」という会社の「 DeviceGateway 」というアプリを利用しています。 DeviceGatewayは、 レッドハット認定コンテナ として公開されています。 また、Red Hat Device Edgeを産業用PCに組み込んだ形でのご提供も可能です。興味のある方はぜひ見てみてください！ tv.redhat.com www.faweb.net このDeviceGatewayは、専用のWebコンソールがDeviceGateway毎に提供され、設備との通信設定や、設備から取得したデータをITシステムと連携する設定などを行えるようになっています。しかし、DeviceGateway 1台ずつ設定する作業は、結構大変です。設定自体は超簡単なのですが、台数が増えてくると時間がどうしてもかかります。 そこで、レッドハットとたけびしとの協業で、このDeviceGatewayの設定作業を自動化するソリューションを開発し、今回のデモで活用しています。 今回のデモでは、協業のソリューションを応用して、DeviceGatewayの設定作業をGitOpsの方法で行えるように拡張しています。 DeviceGatewayは、設定された情報を設定ファイルとして内部で保持します。この設定ファイルは、Webコンソールの操作で、ローカルにエクスポートできるようになってます。今回は、DeviceGatewayの横に一台コンテナを追加し、DeviceGatewayの設定ファイルがエクスポートされたら、Gitリポジトリに自動バックアップするように、機能をちょっとだけ拡張しました。 そして、GitリポジトリにあるDeviceGatewayの設定ファイルの中で、一つマスターとするものを指定すると、本番環境のDeviceGatewayに、マスターとした設定ファイルが適用される、という仕組みを実装してみました。 マスターとする設定ファイルは、以下のような感じで指定できます。Kubernetesには、自身のAPIを拡張して、カスタムのAPIを追加できる機能があります。その仕組みを利用して、Kubernetesが、DeviceGatewayの設定の状態を管理するようにしています。 apiVersion: dgw.io/v1 kind: DeviceGatewayAutomationAgent metadata: name: setting spec: gitRepo: "https://gitlab.com/yono1/dgw-auto-config-setting-files" gitFilePath: "dgw-settings" gitFileName: "export_all.dxg" -> ここに複数台へ適用したい設定ファイル名を指定する applicationName: "dgw" namespace: "cps" 本デモの実装で面倒だったのは、ミニチュア工場自体が会社にあって、リモートから開発作業を進めるのが難しかったことです。僕の家には、DeviceGatewayの開発環境があるのですが、何回もDeviceGatewayの設定を変えて動作検証を繰り返していると、開発環境で固めた設定ファイルをローカルにエクスポートし、本番環境にコピーして、DeviceGatewayに適用する、という作業が地味に苦痛でした。 この仕組みを取り入れたことで、家でDeviceGatewayを検証する→会社に来た時に、本番環境のDeviceGatewayに設定が反映されている！という感じで、ちょっとだけ開発作業を効率化できた気がします。 ITシステムと設備の連携 ここまでの流れで、アプリを産業用PCへインストールして、設定が完了したら、ミニチュア工場をちょっとだけ賢くしてみましょう。 今回のデモでは、 設備とITシステムとを連携させる 、という方法で、ミニチュア工場を賢くします。 ミニチュア工場には、前述のとおり、赤・青・白の3色のボールが存在します。これらを「品種」とみなし、品種毎にITシステム側で納期が管理されていることを想定して、その納期情報を設備と連携させてみました。 動作の流れは、以下のとおりです。 生産管理の担当者が、生産管理システムへ、品種毎に製造オーダと納期情報を登録する 生産管理システムの情報をMES(Manufacturing Execution System: 製造実行システム)と連携させて、製造オーダから製造ロットを作成し、ボタンを押すと自動的に作業計画が自動出力される 設備を稼働させると、MESの作業計画とPLCが連携し、納期順にボールが倉庫から出庫される 設備とITシステムの連携には、 OPC-UA という産業系の標準プロトコルを採用しています。OPC-UAは、クライアント-サーバの構成で、産業設備のデータを外部のシステムと連携できるプロトコルです。最近は、OPC-UAサーバの機能が具備されたPLCも少なくありません。しかし、世の中には、導入以降、20年以上使い続けられているPLC、というのも多いのが実情です。昔からある工場の設備は、そもそもOPC-UAに対応していないケースがよくあります。 そんなときに、たけびしのDeviceGatewayを利用すると、たけびしのDeviceGatewayが旧型のPLCと連携して、上位システム側にOPC-UAサーバとして振る舞う構成を実現できます。多くのメーカーのPLCやセンサーなどと簡単な設定で連携できる様々なドライバーを内包しているのが、DeviceGatewayの便利なところです。 そして、ITシステム側は、OPC-UAクライアントとして、DeviceGateway経由で、PLC内のレジスタの値の読み書きを行います。 まとめると、以下の構成で、ITシステムで管理される計画値を元に、設備を動作させることができました。 まとめ 本稿では、レッドハットのオフィスに常設しているミニチュアの工場を使って、ソフトウェアファーストで工場をスマート化する様子を体験いただきました。 ご覧いただいたように、まだまだ拡張の余地はたくさんあります。我々、レッドハット工場 生産技術部のメンバーは、日々スマートファクトリーに向けて試行錯誤を繰り返しています。 そんな中で、LLMとも友達になれました。その辺も、今度、近況報告できたらなと思います。 ちなみに、次は、ボールにQRでも貼ってトレーシングできるようにしたり、画像AIと連携させて製品検査の工程を追加したりしたいなぁ、とアイディアは尽きません。 ミニチュア工場を軸としたアイディアソンやIT/OT融合のワークショップなんかも開催させていただいたりしてますので、興味のある方がいましたら、ぜひご連絡いただけると嬉しいです。 また、今回見ていただいたようなソフトウェアファーストな考え方は、工場だけでなく、さまざまな取り組みにも、もちろん応用できます。 ぜひ、「スマホみたいな世界観」を一緒に議論しましょう！ 最後に、宣伝！ 2月13日のオンライン開催の「Virtual IT Expo 2024冬」というイベントに出展します。 promotion.itmedia.co.jp オンラインですが、ミニチュア工場のデモや、もう少し詳しい事例の紹介なども行います。興味のある方はぜひお越しくださいー！ それでは！

レッドハットのAnsibleサポートチームのひよこ大佐こと八木澤です。クリスマス目前で、気温も寒くなってきましたが皆様いかがお過ごしでしょうか。 今回は、「 Ansible Tips 」として、Ansibleで知っておくと役立つちょっとした小ネタや知識をご紹介します。 この記事は「 Ansible Advent Calendar 2024 」の23日目の記事になります。 rawモジュールとは？ Ansibleには多種多様なモジュールがありますが、一部他のモジュールと挙動が大きく異なるモジュールも存在します。そのうちの一つが、「raw」モジュールです。 ansible.builtin.raw module – Executes a low-down and dirty command — Ansible Community Documentation rawとは「生の、未加工の」という意味の英語です。このモジュールはその名の通り「実行先のノードで指定されたコマンドを実行する」という最小限の機能のみを有しており、同様の目的で使用される「shell」や「command」モジュールとは、大きく挙動が異なります。 百聞は一見にしかずということで、まずは実際にrawモジュールを実行してみましょう。 --- - hosts : all tasks : - name : Execute whoami command raw : whoami 上記のPlaybookは、rawモジュールで「whoami」コマンドを実行するという至ってシンプルなものです。実際に実行すると、以下のようにコマンドが実行されます(実行結果をわかりやすくするため、-vvvを指定しています) TASK [ Execute whoami command ] ********************************************************************************************************************************************************************************************************************************************************************************************************* task path : / home / hiyoko / Documents / raw . yml :4 < aap25 - ctr1 > ESTABLISH SSH CONNECTION FOR USER : hiyoko < aap25 - ctr1 > SSH : EXEC ssh - C - o ControlMaster = auto - o ControlPersist =60s - o KbdInteractiveAuthentication = no - o PreferredAuthentications = gssapi - with - mic , gssapi - keyex , hostbased , publickey - o PasswordAuthentication = no - o 'User="hiyoko"' - o ConnectTimeout =10 - o 'ControlPath="/home/hiyoko/.ansible/cp/031c196615"' - tt aap25 - ctr1 whoami < aap25 - ctr1 > ( 0 , b'hiyoko\r\n' , b'Shared connection to aap25-ctr1 closed.\r\n' ) changed : [ aap25 - ctr1 ] => { " changed ": true , " rc ": 0 , " stderr ": " Shared connection to aap25-ctr1 closed. \r\n ", " stderr_lines ": [ " Shared connection to aap25-ctr1 closed. " ] , " stdout ": " hiyoko \r\n ", " stdout_lines ": [ " hiyoko " ] } rawモジュールの最大の特徴は、「ターゲットノード上のPython実行環境を介さず、直接コマンドを実行する」ことにあります。つまり、コネクションプラグイン(sshなど)の接続が確立さえしていれば機能するモジュールとなります。この点で、他のPythonを利用するモジュールとは大きく性格が異なります。上記のタスクの実行結果を見ると、SSHコネクションが確立された直後にコマンドが実行され、実行結果が返却されていることがわかります。実際に、同じくwhoamiコマンドを実行するだけのshellモジュールと、-vvvの出力を比較してみましょう。shellモジュールでは、SSHのコネクションが確立された後、 AnsiballZ_command.py を転送していることがわかります。 TASK [ Execute whoami command ] ********************************************************************************************************************************************************************************************************************************************************************************************************* task path : / home / hiyoko / Documents / raw . yml :4 < aap25 - ctr1 > ESTABLISH SSH CONNECTION FOR USER : hiyoko < aap25 - ctr1 > SSH : EXEC ssh - C - o ControlMaster = auto - o ControlPersist =60s - o KbdInteractiveAuthentication = no - o PreferredAuthentications = gssapi - with - mic , gssapi - keyex , hostbased , publickey - o PasswordAuthentication = no - o 'User="hiyoko"' - o ConnectTimeout =10 - o 'ControlPath="/home/hiyoko/.ansible/cp/031c196615"' aap25 - ctr1 '/bin/sh -c ' " '"'echo ~ hiyoko && sleep 0 '"' " '' < aap25 - ctr1 > ( 0 , b'/home/hiyoko\n' , b'' ) < aap25 - ctr1 > ESTABLISH SSH CONNECTION FOR USER : hiyoko < aap25 - ctr1 > SSH : EXEC ssh - C - o ControlMaster = auto - o ControlPersist =60s - o KbdInteractiveAuthentication = no - o PreferredAuthentications = gssapi - with - mic , gssapi - keyex , hostbased , publickey - o PasswordAuthentication = no - o 'User="hiyoko"' - o ConnectTimeout =10 - o 'ControlPath="/home/hiyoko/.ansible/cp/031c196615"' aap25 - ctr1 '/bin/sh -c ' " '"' ( umask 77 && mkdir - p "` echo / home / hiyoko /. ansible / tmp `"&& mkdir "` echo / home / hiyoko /. ansible / tmp / ansible - tmp -1734916880.8232417-13918-57931879742332 `" && echo ansible - tmp -1734916880.8232417-13918-57931879742332="` echo / home / hiyoko /. ansible / tmp / ansible - tmp -1734916880.8232417-13918-57931879742332 `" ) && sleep 0 '"' " '' < aap25 - ctr1 > ( 0 , b'ansible-tmp-1734916880.8232417-13918-57931879742332=/home/hiyoko/.ansible/tmp/ansible-tmp-1734916880.8232417-13918-57931879742332\n' , b'' ) Using module file / usr / lib / python3 .13/ site - packages / ansible / modules / command . py < aap25 - ctr1 > PUT / home / hiyoko /. ansible / tmp / ansible - local -13901wvkcruny/ tmp2872f93f TO / home / hiyoko /. ansible / tmp / ansible - tmp -1734916880.8232417-13918-57931879742332/AnsiballZ_command. py < aap25 - ctr1 > SSH : EXEC sftp - b - - C - o ControlMaster = auto - o ControlPersist =60s - o KbdInteractiveAuthentication = no - o PreferredAuthentications = gssapi - with - mic , gssapi - keyex , hostbased , publickey - o PasswordAuthentication = no - o 'User="hiyoko"' - o ConnectTimeout =10 - o 'ControlPath="/home/hiyoko/.ansible/cp/031c196615"' '[aap25-ctr1]' < aap25 - ctr1 > ( 0 , b'sftp> put /home/hiyoko/.ansible/tmp/ansible-local-13901wvkcruny/tmp2872f93f /home/hiyoko/.ansible/tmp/ansible-tmp-1734916880.8232417-13918-57931879742332/AnsiballZ_command.py\n' , b'' ) < aap25 - ctr1 > ESTABLISH SSH CONNECTION FOR USER : hiyoko < aap25 - ctr1 > SSH : EXEC ssh - C - o ControlMaster = auto - o ControlPersist =60s - o KbdInteractiveAuthentication = no - o PreferredAuthentications = gssapi - with - mic , gssapi - keyex , hostbased , publickey - o PasswordAuthentication = no - o 'User="hiyoko"' - o ConnectTimeout =10 - o 'ControlPath="/home/hiyoko/.ansible/cp/031c196615"' aap25 - ctr1 '/bin/sh -c ' " '"'chmod u + x / home / hiyoko /. ansible / tmp / ansible - tmp -1734916880.8232417-13918-57931879742332/ / home / hiyoko /. ansible / tmp / ansible - tmp -1734916880.8232417-13918-57931879742332/AnsiballZ_command. py && sleep 0 '"' " '' < aap25 - ctr1 > ( 0 , b'' , b'' ) < aap25 - ctr1 > ESTABLISH SSH CONNECTION FOR USER : hiyoko < aap25 - ctr1 > SSH : EXEC ssh - C - o ControlMaster = auto - o ControlPersist =60s - o KbdInteractiveAuthentication = no - o PreferredAuthentications = gssapi - with - mic , gssapi - keyex , hostbased , publickey - o PasswordAuthentication = no - o 'User="hiyoko"' - o ConnectTimeout =10 - o 'ControlPath="/home/hiyoko/.ansible/cp/031c196615"' - tt aap25 - ctr1 '/bin/sh -c ' " '"' / usr / bin / python3 / home / hiyoko /. ansible / tmp / ansible - tmp -1734916880.8232417-13918-57931879742332/AnsiballZ_command. py && sleep 0 '"' " '' < aap25 - ctr1 > ( 0 , b'\r\n{"changed": true, "stdout": "hiyoko", "stderr": "", "rc": 0, "cmd": "whoami", "start": "2024-12-22 20:21:20.973026", "end": "2024-12-22 20:21:20.974877", "delta": "0:00:00.001851", "msg": "", "invocation": {"module_args": {"_raw_params": "whoami", "_uses_shell": true, "expand_argument_vars": true, "stdin_add_newline": true, "strip_empty_ends": true, "argv": null, "chdir": null, "executable": null, "creates": null, "removes": null, "stdin": null}}}\r\n' , b'Shared connection to aap25-ctr1 closed.\r\n' ) < aap25 - ctr1 > ESTABLISH SSH CONNECTION FOR USER : hiyoko < aap25 - ctr1 > SSH : EXEC ssh - C - o ControlMaster = auto - o ControlPersist =60s - o KbdInteractiveAuthentication = no - o PreferredAuthentications = gssapi - with - mic , gssapi - keyex , hostbased , publickey - o PasswordAuthentication = no - o 'User="hiyoko"' - o ConnectTimeout =10 - o 'ControlPath="/home/hiyoko/.ansible/cp/031c196615"' aap25 - ctr1 '/bin/sh -c ' " '"'rm - f - r / home / hiyoko /. ansible / tmp / ansible - tmp -1734916880.8232417-13918-57931879742332/ > / dev / null 2>&1 && sleep 0 '"' " '' < aap25 - ctr1 > ( 0 , b'' , b'' ) changed : [ aap25 - ctr1 ] => { " changed ": true , " cmd ": " whoami ", " delta ": " 0:00:00.001851 ", " end ": " 2024-12-22 20:21:20.974877 ", " invocation ": { " module_args ": { " _raw_params ": " whoami ", " _uses_shell ": true , " argv ": null , " chdir ": null , " creates ": null , " executable ": null , " expand_argument_vars ": true , " removes ": null , " stdin ": null , " stdin_add_newline ": true , " strip_empty_ends ": true } } , " msg ": "", " rc ": 0 , " start ": " 2024-12-22 20:21:20.973026 ", " stderr ": "", " stderr_lines ": [] , " stdout ": " hiyoko ", " stdout_lines ": [ " hiyoko " ] } どんな時に使えばいいの？ rawモジュールが、shellやcommandモジュールと異なることはわかりました。では、実際にrawモジュールをどのような時につかえばよいのでしょうか？ ・シンプルなコマンドを実行する ご紹介したように、マネージドノード上であるコマンドや特定のシェルスクリプトを実行したいという場合に、rawモジュールであればPythonスクリプトを介さず直接SSH接続したような感覚でコマンドを実行できます。上記の例はRHELに対して実行していますが、実はrawモジュールはWindows環境やネットワークデバイスに対しても動作しますので、環境を選ばずにコマンドを実行させることができます。 さらに、rawモジュールによるコマンド実行は、オーバーヘッドが非常に小さいです。plofile_tasksのcallbackプラグインで計測した結果を比較してみましょう。 shellモジュールを利用した場合: TASKS RECAP ******************************************************************** 月曜日 23 12月 2024 10:35:31 +0900 (0:00:00.220) 0:00:00.224 *************** =============================================================================== Execute whoami command -------------------------------------------------- 0.22s rawモジュールを利用した場合: TASKS RECAP ******************************************************************** 月曜日 23 12月 2024 10:36:15 +0900 (0:00:00.020) 0:00:00.024 *************** =============================================================================== Execute whoami command -------------------------------------------------- 0.02s rawモジュールを利用するだけで、シンプルなコマンド1つの実行が0.2秒の差があります。当然、より多くのコマンドを実行したり、スクリプトを実行するようなシチュエーションでは、この差は大きくなるでしょう。このように、ノードに対してシンプルなコマンドを実行したり、スクリプトを起動するような用途では、rawは非常に優れた選択肢になります。 ・接続先にPythonが存在しない場合の回避策 通常、RHELノードなどであればPythonはデフォルトで利用可能ですが、ネットワーク機器など接続先によってはPythonが利用できない場合があります。そういったデバイスの自動化において対応するモジュールがない場、rawモジュールであれば直接コマンドを実行できるため、多少ダーティーなPlaybookにはなりますが、自動化を実装することができます。 ・トラブルシューティングの切り分け トラブルシューティングの際は、なるべく問題の原因となるレイヤーを少なくしたいものです。rawモジュールであれば、間にPythonスクリプトの実行という余計なプロセスを挟むことなくコマンドやスクリプトを実行できるため、例えばshellモジュールで実行したスクリプトが正常に動作しない場合に、どこに原因があるのか切り分ける時などに非常に役立ちます。 rawモジュールのデメリットは？ では、すべてのコマンドを実行するモジュールはrawモジュールひとつでよいように思えますが、実際にはshellモジュールなどを利用することが多いのはなぜでしょうか？ 理由のひとつに、「利用できる機能が最小限である」ということが挙げられます。 rawモジュールのドキュメント を見ていただければわかる通り、指定できるオプションはほぼ存在しません。また、最初のrawモジュールとshellモジュールの実行結果を比較していただくと、実行後に利用できる戻り値も大きく異なることがわかります。そのため、コマンドの実行結果を元に条件分岐したりするようなケースでは不便なケースもあります。 また、シェルの機能に極度に依存するようなもの（長大なパイプやリダイレクトなど）が機能しないケースもあるため、必ずしもrawモジュールだけを使えばよいというものではなく、適材適所でその時の要件にあったモジュールを選択していただければ幸いです。

はじめに Red Hat でコンサルタントをしている id:nanodayo です。 タイトル通り、Ansible Playbook で極端にループが遅くなった話となります。 ※実案件での知見ですが、案件特有の情報を載せない形であればOKと、お客様の許可を得て記事にしています。 Ansible - Qiita Advent Calendar 2024 - Qiita の12/21 の記事になります(1日遅れ) 結論(わかったこと) include_tasks や flatten を伴うループは、ループ数が多いと極端に遅くなる(測定環境では500ループで5h程度) ループ数100では 3min 程度で実行完了する。(単純な比例ではない) なお、根本原因は調べておらず、あくまで事象の紹介のみとなります。 背景: 案件で受けた Playbook のパフォーマンス改善の相談 ユーザを作成するPlaybook(Role)実行に時間がかかっている(ユーザ数は500くらい・時間は5時間くらい) 実行中、AAPホストのCPU利用率が高くなっている。 LDAPなど、ユーザ認証関連での通信はない状態 やったこと ソフトウェアレベルで再現環境を構築 RPM, pip でバージョン指定でパッケージをインストールし、同一バージョンのソフトウェアが入っている環境を構築しました。(手順は割愛) 他、仮想マシンで環境を構築しましたが、お客様の環境と同等スペックのVMを作成しました。(メモリ・コア数) お客様と同じ Playbook (Role) で測定 顧客情報のため、詳細は割愛しますが、Role は以下のような作りになります。 input 情報は作成したいユーザのリスト(user 用の辞書構造のリスト) 内部構造として、loop 分の中で include_tasks を用いている。(上記のリストを flatten=1 して指定) 特徴を元に chatGPTに書かせたものが以下になります。 . ├── main.yml ├── create_user.yml └── vars.yml playbook (実際は role の tasks/main.yml がこのような内容でした) --- - name: Create users based on the given list hosts: localhost vars_files: - vars.yml # ユーザリストを外部のvarsファイルから読み込む tasks: - name: Loop through users and create them include_tasks: create_user.yml loop: "{{ users|flatten=1 }}" loop_control: loop_var: user create_user.yml --- - name: Create a user user: name: "{{ user.name }}" # ユーザ名 state: present # ユーザが存在することを確認 password: "{{ user.password }}" # パスワード (プレーンテキスト) shell: "{{ user.shell | default('/bin/bash') }}" # デフォルトのシェル comment: "{{ user.comment | default('No comment') }}" # コメント create_home: "{{ user.create_home | default(true) }}" # ホームディレクトリを作成するか 想定データ(vars) --- users: - name: "alice" password: "alicepassword" comment: "Alice User" shell: "/bin/zsh" - name: "bob" password: "bobpassword" comment: "Bob User" - name: "charlie" password: "charliepassword" comment: "Charlie User" create_home: false ダミーデータで測定 ダミーデータで100ユーザ分の vars で実行したものの、Job 実行にかかった時間は 3分程度でした。 当時は「これを5倍にしても15分だしなぁ」と、何か別の差異があると考え、データ量は考慮しておりませんでした。 再現度合いを上げるために パスワード文字列を複雑にする 等の試行錯誤をしましたが、実行時間に大きな影響は出ませんでした。 お客様の実データで測定 データ構造の複雑さに起因しているのではと考え、実データ(vars)を共有いただいて測定したところ、 500ユーザの作成に5時間かかる事象 が確認できました。 測定の小ネタ profile_tasks を設定 どの task に時間がかかっているかを特定するために設定。 参考: AnsibleのCallback Pluginをためしてみよう - 赤帽エンジニアブログ task の timestamp を確認 Role の構造上、include_tasks を経由して全ての task が実行されているため、profile_tasks での出力は include_tasks の時間のみが表示 され、内訳を確認するに至りませんでした。 以下のように、被疑箇所となる候補が複数あったため、task 実行時のタイムスタンプが手がかりとなりました include_tasks に時間がかかっている vault で暗号化したパスワードの復号化 user の作成処理そのものに時間がかかっている 事象が再現した際は、タイムスタンプと、ログの表示のされ方から、include_tasks に極端に時間がかかっていることが確認できました。 リアルタイムに眺めていたら、以下のような具合に、 include_tasks に入ったところで何10分もそのまま でした。 AAPのログ画面(一部切り抜き)、この状態で何10分も動かない。 多数のループと相性の悪かった記述 構造上、include_tasks や flatten を使わない形に修正できたので、その上で測定すると以下のようになりました。 include_tasks あり include_tasks なし flatten=1 あり 遅い 遅い flatten=1 なし 遅い 速い include_tasks or flatten のどちらかがあると、今回のデータ量では実行時間が5時間近くになりました。 調べてないこと 深掘りの余地のあるトピックですが、根本原因は調べていません。 例えば、以下は深掘りの余地がありそうです。 「極端に遅くなるループ数」のしきい値はどのくらいか(100から500の間にあるはず) 上記の数は何に起因するか(ハードウェアスペックで変わるか) 今回はユーザの作成で発覚しましたが、一定数のループ+(flatten or include_tasks) で確認できた事象ですので、task としては debug module でも確認可能と思います。 反響があれば調べるかもしれません。それでは Happy Automation。

※この記事は OpenShift Advent Calendar 2024 の 20日目の記事です。 qiita.com こんにちは、ストレージと OpenShift を生業にしているうつぼ（宇都宮）です。ご無沙汰しております。 ここ最近というかこの一年はすっかり OpenShift Virtualization（OCP-V）の小僧として活動させていただいております。 お陰様で OCP-V は非常に多方面から注目を浴びております。ありがとうございます。 さて。OCP-V は仮想マシンのライブマイグレーションができることで知られていますが、ストレージのライブマイグレーションにはこれまで対応していませんでした。 ストレージのライブマイグレーションは、バックエンドのストレージの負荷が偏ってしまって分散させたいときや、ストレージ装置の更改（入れ替え）のときには欠かせない機能です。 そして最新の OpenShift Virtualization 4.17 で、 Storage Class Migration という名前で対応できるようになりました。 4.17 時点では Storage Class Migration は Tech Preview 機能です ので、フルサポートはまだ無いのですが、機能としては普通に使えます。 今日はそんな Storage Class Migration について紹介します。 Storage Class Migration 仮想マシンの仮想ディスクのライブマイグレーションは、皆さんの馴染みの深いであろう vSphere では Storage vMotion という名前で実装されていました。 ざっくり言えばデータストア間で vmdk 等のファイルを移動させる機能ですが、OpenShift にはデータストアも仮想ディスクファイルもありません。 あるのは、Storage Class と Persistent Volume (PV) です。 そうです。 Storage Class Migration は名前の通り、異なる Storage Class 間で PV を移動させる機能です。 厳密に言えば移動ではなくコピー（クローン）ではありますが、何はともあれ別の Storage Class に PV を移すことができるのです。仮想マシン無停止で移すことが可能です。 Storage Class Migration 利用条件 Storage Class Migration を行うには、次のようなバージョンの条件があります。 OpenShift 4.17 以上 OpenShift Virtualization Operator 4.17 以上 Migration Toolkit for Container Operator 1.8.4 以上 OADP Operator 1.4.1 以上 各々ほぼほぼ最新のバージョンですね。これらを導入したうえで、OpenShift Virtualization の "HyperConverged" カスタムリソースに annotation を追加します。次の oc コマンドで適用するのが簡単です。 oc annotate --overwrite -n openshift-cnv hco kubevirt-hyperconverged kubevirt.kubevirt.io/jsonpatch='[ {"op": "add", "path": "/spec/configuration/developerConfiguration/featureGates/-", "value": "VolumesUpdateStrategy"}, {"op": "add", "path": "/spec/configuration/developerConfiguration/featureGates/-", "value": "VolumeMigration"} ]' これによって、"VolumeMigration" と "VolumeUpdateStrategy" という KubeVirt の feature を使えるようになります。 Storage Class Migration は Migration Toolkit for Container で実行 利用条件には、Migration Toolkit for Container Operator というのがありますが、これは必要なのか？はい、必要です。 Migration Toolkit for Container（MTC） は超ざっくり言えば、PV を使うようなステートフルなアプリケーションを OpenShift クラスタ間で移行する際に使うツールです。 Storage Class Migration は、MTC の機能の一部として実行します。 MTC で Migration Plan 作成時に Migration Type に Storage class conversion を選択 なお、既存仮想化基盤から仮想マシンの移行する際に使う、Migration Toolkit for Virtualization（MTV）というツールがありますが、MTC はそれとはまた別のツールです。 MTC で Storage Class Migration を実行すると、移行先の Storage Class で自動的に PVC が発行 & PV がバインドされて、移行元の PV から移行先の PV にコピーが走ります。 コピーが完了すると、 OCP-V 仮想マシンの "DataVolume" に紐づけられている PVC は、自動的に移行先の PVC に切り替わります。 ですので、仮想マシン側の切り替え作業は必要がなく、気づいたら移行が終わってる、という感じになります。 ※DataVolume って？という方は ↓ こちらの記事を読んで下さい。 rheb.hatenablog.com 注意点 はい、ようやく実装された Storage Class Migration ですが、いくつか頭に留めておいていただきたい注意点があります。 同一の Namespace 内でのみ移行できる Storage Class Migration は異なる Namespace への移行は対応していません。 同時に仮想マシンのライブマイグレーションも起きる PVC が移行先に切り替わるタイミングで、仮想マシン自身もライブマイグレーションするため、別の Compute ノードに移動します。 今日時点では PVC だけを切り替えることは対応していません。 移行元の PVC は残る 普通に考えれば移行したら移行元には何も残らないと思いがちですが、Storage Class Migration では移行元に PVC が残ります。 冒頭で厳密には移行ではなくコピーと言ったのはそのためです。必要に応じて移行完了後に手で移行元の PVC を削除して下さい。 この他にも、Share disk は移行対象にはできないよとか、PV のサイズは移行元と移行先とでピッタリ合ってないといけないよ、とかいくつかの細々とした制限がありますが、本当に細々としているのでここでは省きます。 まとめ 以上が Storage Class Migration の紹介です。 多分、やりたいこと自体はシンプルなのでご理解いただけると思うのですが、具体的にどうやってやるのか？は文言だけではイメージがつきづらいかもしれません。 ちょっとデモが見たいよという方は、お気軽に担当営業までお問い合わせいただければと思います。 ちょっと落ち着いたらそのうちデモ動画も用意できたらなと思っています。 というわけで、今回はここまで。

はじめに はじめまして、Red HatでOpenShift Container Platformのテクニカルサポートの野間です。 OpenShift Advent Calendar 2024 の12/19の記事ですが、遅れてしまいました。申し訳ありません。 本日はOpenShift Container Platformでサポートされるノード構成について、現在の情報を整理してお伝えします。というのも、リリースから5年の進化をとげ、選択できる構成が格段に増えました。これにより、初学者にとって「結局、何台のサーバー（インスタンス）が必要なのか」が製品ドキュメントから理解しづらくなったと思います。 control plane/compute node と master/worker node の表記について これも今更なのですが本題の前に少し補足させてください。OpenShiftもしくはkubernetesではnodeの種類として、control planeとmaster nodeもしくはcomputeとworker nodeが同じように使われています。これは大人の事情で、表記を置き換えたためです。意味は全く同様で、現在はcontrol plane/compute nodeを使用するのが正しいです。ただし、古い表記はドキュメントやソースに根深く存在し、今も混在した表記が散見されます。混乱しないように脳内で置き換えてください。 旧 master node worker node 現在 control plane node compute node それではノード構成について解説します。 基本の構成 control plane node [3-5]台 + compute node n台(n≧2) まずは基本のキの構成です。control plane 3台以上と、compute node2台以上です。 control plane nodeはクラスタ全体のステータスを管理をするnodeであり、 それを構成するコンポーネント はいくつかあるのですが、特に台数に関連しているのは、分散key valueストアであるetcdです。etcdはRAFTと呼ばれる、メンバーがリーダーを多数決で選出するアルゴリズムを採用しており、耐障害性をもつ最小構成が3ノードです。そのため、基本のcontrol plane node は3台なのですね。 しかしながら、OpenShift4.17から、 bare metalプラットフォームでetcdを5台までスケールさせる機能 がリリースされました。4.17以上であれば、control plane は4台もしくは5台でも構成可能です。ただし、ドキュメントによると、3台構成と4台構成のFailure toleranceはいずれも1です。つまり3台中1台まで故障可能と、4台中1台まで故障可能という意味になり、ノード台数と故障率も考慮すると可用性は3台構成のほうが高い計算になります。正直、4台構成は積極的に使用するメリットは見つかりません。5台構成にするための段階的なステップぐらいでしょうか。 compute nodeは、ユーザーワークロードコンテナを稼動させるノードです。ですのでユーザーのワークロードにあわせて好きな台数を揃えてください。2台以上となっているのは、やはり耐障害性のためです。実際はユーザーワークロードコンテナだけでなく、Ingress Operator や Cluster Monitoring Operator といったOpenShiftのOperatorが管理するPodも稼動するのですが、これらは耐障害性のため2台以上のcompute nodeが前提で開発されています。 control plane node [3-5]台 + compute node n台(n≧2) + infrastructure node(n≧3) 前述の構成にオプションでinfrastructure nodeを加えることができます。infrastructure nodeは、デフォルトではクラスタのcompute node上で動くinfrastructureのコンポーネント(前述のIngress Operator や Cluster Monitoring Operatorなど)を専用として配置するノードです。利点としてはinfrastructure nodeはcontrol plane nodeと同様でsubscriptionを必要としません。そのため、役割をユーザーワークロードに集中させたcompute nodeにのみsubscriptionがかかります。台数については ドキュメント を確認すると、推奨が3台以上となってますね。 three-node cluster 上記の基本構成は最低が5台からなので、少しとっつきにくい感じがしますね。そんなニーズに対応したのか、three-node clusterという構成があります。どのようにしているかタネをあかすと、control plane node 3台にワークロードも稼動しているだけです。つまり実態は(control plane nodeかつcompute node) × 3ということですね。ただし、サブスクリプションはcompute nodeとして使っている分だけー！とはいかず全体にかかります。ここら辺は去年のAdvent Calendarで宇都宮さんが 3ノードクラスタのすゝめ で記事にしてくださっています。 single node OpenShift(SNO) SNO 1台 3台でも多いでしょう！という方のために、 single node OpenShift(SNO) と呼称される1台構成もあります。可用性を考慮しなければetcdも1ノードで構成できるので、すべてを1台に集約した構成です。もちろんノードが故障すればすべて止まります。検証用に便利で当ブログでもよくみかける、みんな大好きな構成ですね。本番環境で使うこともでき、代表的なユースケースはエッジコンピューティングです。昔は本番環境未サポートの検証用としてRed Hat CodeReady Containersという別の1台構成もあったのですが、SNOによってこちらを使用する理由はなくなりました。 SNO 1台 + compute node n台(n≦2) なんと、 単一ノード構成に compute node を追加 することができます。台数少ないことがメリットじゃないんかーい！とツッコまれそうですね。追加の compute node は2台までで、追加方法も少し特殊となります。追加しても1台のSNOがトラフィックを受けるため、Single point of failureは変わりません。ポコポコ増やしたら他のクラスタ構成と同等になるというわけでなく、あくまでSNO構成環境の延長という、限定されたユースケースでの利用が想定されます。 Hosted Control Plane (HCP) Hosting cluster + compute node n台 ノード構成とは異なるトピックになるかもしれませんが、 Hosted Control Planeという機能 があります。要はcontrol plane の機能だけ別システムに集約し、管理してもらおうという機能です。この別システムはやはりOpenShiftクラスターで、Hosting clusterもしくは管理クラスターと呼ばれます。クラスターを何個もポコポコ構成するような大規模な環境で、組織的に運用管理者も権限分離したいようなユースケースでメリットがでると思います。OpenShift Advent Calendar 2024でも HCPをデプロイする記事 が書かれましたので参考にしてください。 まとめ 本記事では、OpenShift Container Platformにおけるノード構成の選択肢について解説しました。ここ数年で選択可能な構成が多様化し、目的や環境に応じて柔軟な選択が可能となっています。以下に主要なポイントを簡単に振り返ります。 1.基本構成 Control plane nodeは3台以上、Compute nodeは2台以上が推奨される標準構成です。耐障害性やスケーラビリティにすぐれています。また、Infrastructure nodeを加えることで、ユーザーワークロードとクラスタ管理機能を分離できます。 2.小規模構成 Three-Node ClusterやSingle Node OpenShift (SNO)といった構成は、小規模環境や検証用途での利用に適しています。ただし、可用性の制約があるため、本番利用時はユースケースに応じた検討が必要です。 3.Hosted Control Plane (HCP) Control planeを別クラスタにホストすることで、特定の運用要件を満たす柔軟な構成も可能です。特に大規模環境での運用管理者の権限分離に効果を発揮します。 各ノード構成にはそれぞれ利点と課題があり、利用するユースケースや環境に応じた選択が重要です。本記事が、OpenShiftクラスタの設計における参考となれば幸いです。

こんにちは。Red Hatの呉と申します。普段はAnsible Automation Platform製品のテクニカルサポートエンジニアをしております。 今回は題名の通り、Ansible Event-DrivenとPerformance Co-Pilot(PCP)を使ったファイルシステム管理について紹介したいと思います。 Linuxサーバーを使っていたら、いつのまにかファイルシステムがいっぱいになっていたという状況は誰しも一度は経験したことがあるかと思います(私だけでしょうか笑)。 検証の最中にサーバーがフリーズしたりして面倒ですし、それだけならまだしも本番環境で発生したら、面倒では済まない事もあるかと思います。 そこで、ファイルシステムがいっぱいになるのを未然に防ぐ方法は無いかと思い今回の方法を思いつきました。 Performance Co-Pilot（PCP）の設定 Performance Co-Pilot (PCP)は、システムレベルのパフォーマンス測定を監視、視覚化、保存、および分析するためのオープンソースソフトウェアです。RHEL9以降、PCPではWebhookを利用できるようになりました。これにより、「システムがあるパフォーマンスルールに該当する状況になったら、Webhookを発行する」という事ができるようになりました。 まずは参考までに、監視対象のLinuxサーバーにPCPをセットアップする手順を記載します。せっかくなのでAnsibleでセットアップします。 インベントリファイルを作成 まずはインベントリファイルを作成します。IPアドレスやsudoパスワード等は管理対象サーバーのログイン情報に合わせて適宜変更してください。 参考： インベントリファイルを構築する方法 inventory.yaml --- all: children: pcp_servers: hosts: 192.168.57.10: ansible_become_pass: password 192.168.57.11: ansible_become_pass: password 2. Playbookの作成 次に、以下のコードを使用してプレイブックを作成します。 CHANGEME の部分は、ルールブックを実行するサーバーのIPアドレスもしくはFQDNに置き換えてください。 pre_setup.yaml --- - hosts: pcp_servers become: true gather_facts: no vars: webhook_endpoint: "http://CHANGEME:5000/endpoint" tasks: - name: Install pcp packages on the managed nodes ansible.builtin.dnf: name: "{{ item }}" state: latest loop: - pcp - name: Install additional packages for stress test and analyze performance ansible.builtin.dnf: name: "{{ item }}" state: latest loop: - sysstat - stress-ng - name: Start and enable pmcd service ansible.builtin.systemd_service: name: pmcd state: started enabled: true - name: Start and enable pmcd service ansible.builtin.systemd_service: name: pmie state: started enabled: true - name: Start and enable pmcd service ansible.builtin.systemd_service: name: pmlogger state: started enabled: true - name: Configure global webhook_action as "yes" command: "pmieconf -f /var/lib/pcp/config/pmie/config.default modify global webhook_action yes" - name: Configure webhook endpoint command: "pmieconf -f /var/lib/pcp/config/pmie/config.default modify global webhook_endpoint {{ webhook_endpoint }}" loop: "{{ groups['pcp_servers'] }}" notify: Restart pmie handlers: - name: Restart pmie ansible.builtin.systemd_service: name: pmie state: restarted enabled: true ３. プレイブックの実行 以下のコマンドでプレイブックを実行してください： $ ansible-playbook -i inventory.yaml pre_setup.yaml 以上で、PCPサービスを実行するための初期セットアップが完了しました。 Ansible Rulebookの実行環境を用意する ルールブックを実行するために、まずはルールブックの実行に必要となる環境を用意する必要があります。ルールブックの実行環境としては以下2パターンが考えられます。 1. ルールブックの実行環境を含んだコンテナをダウンロードして、コンテナで実行する。 2. ansible-rulebookおよびJavaなど、必要なパッケージをサーバーにインストールする。 今回は簡単に実行環境を用意したいので、コンテナを利用する方法を記載したいと思います。2をご希望の場合は、公式サイトをご参考ください。 ansible.readthedocs.io それでは実行環境を構築していきます。 まずは、Red Hat quay.io registryレジストリーから配布されているansible-rulebookコンテナイメージをダウンロードします。 $ podman pull quay.io/ansible/ansible-rulebook 次に、以下のルールブックを用意します。各ルールの解説については、ファイル内のコメントをご参考ください。 pcpEventRules.yaml --- - name: Listen for RHEL Performance Co-Pilot events hosts: all sources: - ansible.eda.webhook: host: 0.0.0.0 port: 5000 rules: - name: Respond to PMIE rule filesys.filling #ファイルシステムが100%フルの場合、Ansibleは管理対象ノードにログインできません。 #このため、ファイルシステムが100%でない場合のみこのルールを起動します。 condition: "event.payload.pcp.pmie.message is not match('100%',ignorecase=true) and event.payload.pcp.pmie.rule == 'File system is filling up'" action: run_playbook: name: /work/filesys.filling.yaml # 100%フルの場合は、監視対象ノードにログインせず、ファイルシステムがいっぱいになっていることを通知するだけにします。 #通知用プレイブックの実装は今回はスキップします。 #- name: Launch PMIE rule filesys.filling when the managed node file system is 100% full # condition: "event.payload.pcp.pmie.message is match('100%',ignorecase=true) and event.payload.pcp.pmie.rule == 'File system is filling up'" # action: # run_playbook: # name: playbooks/manage_filesystems/notify_filesystem_usage.yaml #デバッグ用 - name: Display any contents of event.payload variable condition: event.payload is defined action: debug: msg: "Received: {{ event.payload }}" ちなみに、PCPが送ってくるWebhookの中身はこんな感じになっています。 "pcp": { "pmie": { "rule": "File system is filling up", "hostname": "192.168.122.182", "message": "99%used[/dev/mapper/rhel-root]@192.168.122.182" } } } ルールブックが起動するプレイブックも実装しましょう。なお、このプレイブックでは実装例として「/tmpディレクトリ配下で7日間利用が無かったファイルを削除する」というタスクを実装していますが、もしサイズの大きなファイルやディレクトリがあらかじめわかっている場合はそれらをピンポイントで削除するといったタスクなども実装すると役に立つかと思います。ここはそれぞれご利用の環境や運用状況に合わせて実装してください :) filesys.filling.yaml --- - name: EDA response to PMIE rule file.filling hosts: "{{ ansible_eda.event.payload.pcp.pmie.hostname }}" #Webhookを送信してきたホストに対してプレイブックを実行したいので、受信したWebhookからホスト名を取り出します。 become: true gather_facts: false #<---管理対象ノードは現在パフォーマンスが低下しているため、不要な負荷をかけるタスクは避けます。 tasks: - name: Display ansible_eda.event.payload.pcp.pmie.message variable debug: msg: "ansible_eda.event.payload.pcp.pmie.message value: {{ ansible_eda.event.payload.pcp.pmie.message }}" - name: Display ansible_eda.event.payload.pcp.pmie.rule variable debug: msg: "ansible_eda.event.payload.pcp.pmie.rule value: {{ ansible_eda.event.payload.pcp.pmie.rule }}" #7日間利用がなかったファイルを見つける - name: Find files unused for 7 days command: find /tmp -type f -atime +7 register: unused_files #7日間利用がなかったファイルを削除する - name: Delete unused files for 7 days ansible.builtin.file: path: "{{ unused_files.stdout }}" state: absent register: deleted_files #削除したファイルを表示する - name: Showing the deleted files debug: var=deleted_files #削除されたファイルをチャットツールに送信するタスク。これはCiscoのWebexに送信しています。実装はお好みで。 #- name: Cisco Webex Teams - Text Message to a Room # community.general.cisco_webex: # recipient_type: roomId # recipient_id: "{{ room_id }}" # msg_type: markdown # personal_token: "{{ token }}" # msg: "{{ lookup('ansible.builtin.template', './templates/chatMsg.j2') }}" 次に、コンテナを起動します。以下の例では、quay.io/ansible/ansible-rulebook イメージを使用してコンテナを起動し、プロジェクトディレクトリをマウントしてポート5000をリッスンします。/home/vagrant/work/project を実際のプロジェクトディレクトリに置き換えてください。 $ sudo podman run -p 5000:5000 -v /home/vagrant/work/project:/work:z quay.io/ansible/ansible-rulebook ansible-rulebook --rulebook /work/pcpEventRules.yaml -i /work/inventory.yaml --verbose 監視対象ノードでターミナルを開き、curl コマンドを実行して、リクエストがAnsible Event-Drivenサーバーに到達するか確認してください。これにより、PCPからのWebhookがEvent-Drivenサーバーに到達できるか確認できます。IPアドレス192.168.122.11は実際のAnsible Event-Drivenサーバーのホストアドレスに置き換えてください。 $ curl -H 'Content-Type: application/json' -d "{\"message\": \"Ansible is super cool\"}" 192.168.122.11:5000 リクエストが実行中のAnsible Event-Drivenサーバーに到達すると、次のようなログ出力が表示されます： ** 2024-12-19 06:45:46.221739 [debug] ****************************************** Received: {'message': 'Ansible is super cool'} ******************************************************************************** 動作テスト それでは、管理対象サーバーに巨大なファイルを作成して、動作テストをしてみましょう。 ルールブックを起動したまま、以下のようなコマンドを管理対象サーバーで実行します。 たとえば、5GBのダミーファイルを作成する場合: dd if=/dev/zero of=/tmp/testfile bs=1M count=5120 ファイルサイズを調整しながら、使用率が 95% 程度になるまでファイルを追加してください。 ファイル使用率の確認コマンド： df -h 筆者の監視対象ノードでは、こんな感じでファイルシステムをいっぱいにしました。この状態でしばらく待ってみましょう。 $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 3.8G 0 3.8G 0% /dev/shm tmpfs 1.5G 9.4M 1.5G 1% /run /dev/mapper/rhel-root 35G 34G 1.4G 97% / #<---here /dev/vda1 1014M 397M 618M 40% /boot tmpfs 768M 36K 768M 1% /run/user/976 tmpfs 768M 100K 768M 1% /run/user/1000 筆者の環境では3分ほど待つと、先ほど作成した、ファイルを削除するプレイブック file.filling.yaml が実行されるのを確認できました。 なお、うまく再現できない場合や待っていられない場合は、PCPが送信するWebhookの中身を監視対象ノードからCurlで飛ばしてテストする手段もあります。 例えばこちらのように実行できます。endpointのIPは、ルールブックを実行中のサーバーのものに置き換えてください。 $ curl -X POST http://192.168.122.11:5000/endpoint -H "Content-Type: application/json" -d '{ "pcp": { "pmie": { "rule": "File system is filling up", "hostname": "192.168.122.183", "message": "99%used[/dev/mapper/rhel-root]@192.168.122.183" } } }' まとめ いかがでしたでしょうか。PCPにはファイルシステムの監視ルール「filling.filesystem」の他にも、現時点で32個ほどルールがありますので、この仕組みはシステムのパフォーマンス監視に役立てると思います。 ※PCPのルールについては pmieconf rules コマンドでご確認できます。 このクリスマスや年末年始を平和に過ごすための1つの手段として、ぜひご検討ください。