Cover Image

HCL DevOps Code ClearCase セミライブリフォーマット VOB (SLRV) のすべて

2024/1/22 - 読み終える時間: 17 分

All About HCL DevOps Code ClearCase Semi-Live ReformatVOB (SLRV) の翻訳版です。


HCL DevOps Code ClearCase セミライブリフォーマット VOB (SLRV) のすべて

2024年1月17日

著者: Avinash Srinivasamurthy / Senior Technical Specialist

このブログ記事では、HCL DevOps Code ClearCase 3.0.1で利用可能なセミライブリフォーマットVOB(SLRV)機能の詳細について説明します。以下のトピックを取り上げます。

  • セミライブ reformatVOB(SLRV)を使用する理由
  • 標準の reformatvob がどのように機能するか - 図による説明
  • セミライブ再フォーマットVOB(SLRV)の動作-図解による説明
  • セミライブ再フォーマットVOB(SLRV)と標準再フォーマットVOBの比較

セミライブ再フォーマットVOB(SLRV)を使用する理由

SLRVを使用してVOBを再フォーマットする主な利点は以下の通りです。

  • SLRVは次のような優れたソリューションを提供します
    • 新しいスキーマ・レベルへの VOB の更新
    • データベースのクリーンアップ
  • SLRV は、より短いロック時間で VOB を再フォーマットする能力を提供します。
  • SLRVでは、再フォーマットのダンプとロードのプロセスはバックグラウンドで行われます。SLRVでは、再フォーマットのダンプとロード処理はバックグラウンドで行われます。
  • SLRVは、チームがVOBをロックし、最終的なカットオーバー処理を実行する準備ができた時点で完了できます。

標準的な再フォーマット VOB の仕組み

SLRVの仕組みに入る前に、標準的なreformatvobの仕組みとその主な問題点について簡単に説明します。

次の図はVOBに対して行われる標準的なreformatvobの動作を表しています。

画像の説明

  • db_dumperは現在のスキーマを読み込み、いくつかのテキストファイルにデータを出力します。
  • db_loaderはこれらのテキストファイルを読み、新しいスキーマにデータを書き込みます。
  • このプロセスが終了すると、ディレクトリが入れ替わり、新しいスキーマを持つ新しいデータベースが使用できるようになります。
  • reformatvobプロセスは大規模なデータベースではかなりの時間を要します。
  • このプロセスの間、VOBはロックされ、使用できません。
  • UCM環境では、コンポーネントVOBが1つでも使用できない場合、そのUCMプロジェクトですべてのUCM操作が使用できなくなります。

セミライブ再フォーマットVOB(SLRV)の仕組み

セミライブ再フォーマットVOBプロセスは、2つのステージで動作します。

  • ステージ1:セミライブreformatVOBプロセスの開始
  • ステージ2:セミライブリフォーマットVOBプロセスの完了
ステージ 1:セミ・ライブ再フォーマットVOBプロセスの開始

この最初のステージでは、SLRVはコマンドを発行することにより、指定されたVOBに対して開始される: cleartool reformatvob -semilive <vob_stg_path

下図は、この段階で実行されるタスクを表しています。

画像の説明

  • reformatvob -semilive操作は、そのデータベースをスキーマ・レベル55(元のdbがスキーマ54の場合)またはスキーマ・レベル81(元のdbがスキーマ80の場合)に静かにアップグレードします。
  • その後、VOBはロックされます。
  • 既存のデータベース(VOBのdbディレクトリだけ)がdb.copyにコピーされます。
  • その後、VOBはロック解除されます。
  • コピーされたデータベースはダンプされ、db.semiliveにロードされる。
  • db_replay_serverプロセスが開始され、現在のVOB dbからデータベースのdb.semiliveコピーにトランザクションを再生する。
  • 現在の VOB db はコピーが作成されるとロックが解除されるため、エンドユーザーは VOB 上で作業を続けることができます(ポイント 4)。その結果、エンドユーザーの操作に影響はありません。
  • db_replay_serverプロセスは、VOB dbに加えられた新しい変更を、バックグラウンドで新しいdb.semiliveに再生し続けます。
ステージ 2:セミライブreformatVOBプロセスの完了

VOB上で進行中のSLRVを完了させるために、管理者は以下のSLRV completeコマンドを実行します: cleartool reformatvob -semilive -complete <vob_stg_path

下図はSLRV completeコマンド発行後、この段階で実行されるタスクを表しています。

画像の説明

  • complete "コマンドが発行されると、エンドユーザーによるそれ以上の変更を防ぐため、VOBは再びロックされます。
  • complete "メッセージがdb_replay_serverに送信されます。
  • db_replay_serverは、現在のVOB dbから「db.semilive」dbコピーに未処理のトランザクションをすべて再生し、終了する。
  • 現在のVOB dbディレクトリは、将来のバックアップと参照用に "db.pre-semilive... "にリネームされる。
  • スキーマ81データベースのdb.semiliveは "db "にリネームされ、VOBの新しいアップグレードされたdbとして機能します。
  • VOBのロックが解除され、エンドユーザーが使用できるようになり、SLRV操作が完了しました。
  • VOBは新しいスキーマにアップグレードされました。

セミ・ライブ再フォーマットVOB(SLRV)と標準再フォーマットVOBの比較

次の表は、セミ・ライブ再フォーマットVOB(SLRV)と標準再フォーマットVOBの方法の比較です。

 

比較表

 

Semi-live reformatVOB (SLRV)

Standard reformatvob

Efficiency

現在のVOB dbがdb.copyとしてコピーされると同時に、本番VOBのロックは解除されます。

VOBはreformatvob操作の間中ロックされたままです。

db_dumperとdb_loaderはdb.copyに対して動作し、現在のVOB dbに対しては動作しません。

db_dumperとdb_loaderは実際のVOB db自体に作用します。このため、VOBはreformatvobが完了するまでロックされたままとなり、エンドユーザーはVOBを利用できないままとなります。

エンドユーザーはコピーが作成されるとすぐにVOBの使用を再開できるため、エンドユーザーの操作への影響は最小限に抑えられます。

再フォーマットボブの操作中、VOBはロックされたままなので、エンドユーザーへの影響はより大きくなります。

UCMプロジェクトに対するダウンタイムの影響は最小限です。

もしUCMコンポーネントが1つでも標準的なreformatvob(完了までに時間がかかる巨大なVOBを含む)を受けている場合、reformatvobが完了するまでUCMプロジェクト全体がエンドユーザーによって使用できなくなります。 until the reformatvob is complete

Flexibility

管理者は SLRVプロセスをコントロールし、ダウンタイムとエンドユーザーへの影響を考慮して、いつ完了させるかを決定する柔軟性を持っています。

一旦reformatvobコマンドが発行されると、管理者とエンドユーザーはreformatvobコマンドとプロセスが完了するまで待たなければなりません。

管理者とエンドユーザーはreformatvobコマンドとプロセスが完了するまで待たなければなりません。

一度標準のreformatvobが開始されると、ダウンタイムやエンドユーザーへの影響を考慮し、後で停止したり完了したりすることはできません。

Operation

db_replay_serverプロセスは、SLRVが現在のVOBのdbの変更をdb.semiliveコピーに同期させるために作成されます。

db_replay_serverプロセスは標準のreformatvobプロセスでは作成されません。

VOBのdescribe出力に、semilive reformatvob in progress: trueという行があります。semilive reformatvob in progress: true: VOB が SLRV プロセスを実行中であるかいなかの手がかりになります。

VOBが標準的なreformatvob処理中かどうかを判断するオプションはありません。

cleartool reformatvob -semilive -status を使うと、VOBの保留中のトランザクション数をチェックできます。

標準のreformatvobにはこのようなオプションはありません。代わりに、管理者はreformatvobコマンドの出力に表示されるダンプとロードのメッセージに頼らなければなりません。

SLRVがオリジナルのVOBを完成させると、dbは将来のバックアップや参照用に
db.pre-semilive.<month>.<day>にリネームされます。

標準のreformatvobは将来のバックアップや参照用に古いデータベースの名前をdb.dateに変更します。


Cover Image

HCL DevOps Code ClearCase が Jenkins と統合し、シームレスな自動化を実現

2023/12/27 - 読み終える時間: 8 分

HCL DevOps Code ClearCase Integrates with Jenkins for Seamless Automation の翻訳版です。


HCL DevOps Code ClearCase が Jenkins と統合し、シームレスな自動化を実現

2023年12月13日

著者: Arun R / Senior Software Engineer

はじめに

Jenkins は人気のある DevOps ビルド自動化ツールです。オープンソースの統合は何年も前から利用可能ですが、この新しい統合はHCL DevOps Code ClearCase開発チームによって作成され、HCLSoftwareによって公式にサポートされています。

この統合はJenkinsのフリースタイルジョブとパイプラインジョブの両方をサポートします。デフォルトに加え、HCL DevOps Code ClearCaseの統合は、HCL DevOps Code ClearCaseの完了トリガーから呼び出されるWebhooksや、ストリーム上の変更をポーリングするためにHCL DevOps Code ClearCaseプラグインでJenkinsジョブを構成することによって、ビルドを開始する機能を追加します。

SL No: Topic
1 環境
2 HCL DevOps Code ClearCaseのインストール
3 Linux上でのJenkinsのインストールと設定
4 LinuxでのJenkinsのアンロック
5 Jenkinsのカスタマイズ
6 JenkinsサーバーのSSL/TLS設定
1. 環境
  • HCL DevOps Code ClearCase 3.0.1 リリース。

  • HCL DevOps Code ClearCaseは、LinuxのJenkins LTS 2.332.xをサポートしています。

  • RHEL、SLES、Ubuntu、Solaris。

  • 詳細については、システム要件のページを参照してください。

  • Jenkinsをインストールする前に、Java 8専用の64ビットJava実行環境(JRE)がインストールされている必要があります。JREをまだお持ちでない場合は、Adoptiumからhttps://adoptium.net/temurin/releases/?version=8。

  • Javaをインストールした後

    • Javaのパスを設定します。

    画像の説明

    • Javaのパスをシステム環境変数として設定します。

    画像の説明

ステップ

2. HCL DevOps Code ClearCase のインストール

LinuxホストにJenkinsをインストールする前に、まずHCL DevOps Code ClearCaseをインストールする必要があります。HCL HCL DevOps Code ClearCaseリモートクライアントまたはHCL HCL DevOps Code ClearCaseをインストールし、システムパスに/opt/hcl/ccm/HCL DevOps Code ClearCase/binが含まれていることを確認する必要があります。以下のスニペット例では、完全な機能を含む「HCL DevOps Code ClearCaseフル機能インストール」を選択し、Jenkinsビルドに自動ビューを使用する場合は、インストール中に「自動ビュー」オプションを選択する必要があります。

注:VV 3.0.1のインストールには、同じホスト上にJava 8が必要です。

画像の説明

3. Linux での Jenkins のインストールと設定

HCL HCL DevOps Code ClearCase と Jenkins の統合のために Linux に Jenkins をインストールするには、以下の手順を使用します。

  • https://get.jenkins.io/war-stable/ から jenkins.war ファイルをダウンロードし、ホームディレクトリに置きます。

    • mkdir JENKINS
    • chmod 700 JENKINS
    • cd JENKINS
    • cp ~user/jenkins-2.332.x.war .
    • lsでjenkins-2.332.x.warファイルを表示します。
  • 以下のコマンドを実行します。

    画像の説明

  • Jenkinsのインストール中に、以下の例に示すように、Jenkinsのログと初期パスワードが作成される:

    画像の説明

    デフォルトでは、initalAdminPasswordはユーザーのホーム・ディレクトリにあります。例

    画像の説明

  • ヒント: パスワードは、Jenkinsのロックを解除するために必要なので、メモしておくこと。

4. Linux での Jenkins のロック解除

インストール・プロセスの完了後、Linux 上で HCL HCL DevOps Code ClearCase-Jenkins 統合用に Jenkins をカスタマイズして使い始める前に、Jenkins のロックを解除する必要があります。

  • このインストールでは、Jenkins はポート 8080 でホストされます。ウェブ・ブラウザを開き、http://hostname:8080 にアクセスします。

  • ヒント Jenkins のポートを変更する方法については、https://phoenixnap.com/kb/jenkins-change-port を参照してください。

  • Jenkinsのロック解除ダイアログ・ボックスの管理者パスワード・フィールドに、Jenkinsのインストール・セクションのステップ3で取得したパスワードを入力するか、initialAdminPasswordファイルからパスワードを取得して、[続行]をクリックします。

    画像の説明

5. Jenkins のカスタマイズ

Jenkins のインストール・プロセスを完了し、Jenkins のロックを解除した後、Linux 上で HCL HCL DevOps Code ClearCase-Jenkins 統合に使用する前に、Jenkins をカスタマイズする必要があります。

以下の手順を使用して、Jenkins を使用する前にカスタマイズしてください:

  • Jenkinsのカスタマイズ・ダイアログ・ボックスで、Jenkinsに最も頻繁に使用されるプラグインを自動的にインストールさせるには、Install suggested pluginsをクリックします。

    画像の説明

  • プラグインがインストールされたら、[Create First Admin User]ダイアログボックスに必要な情報を入力し、[Save and Continue]をクリックします。

  • インスタンス構成]ダイアログボックスで、Jenkinsに使用させたいポート番号を確認し、[保存して終了]をクリックします。これで初期カスタマイズは完了です。

  • Start using Jenkinsをクリックして、Jenkinsダッシュボードに移動します。

  • HCL DevOps Code ClearCase-jenkins.hpiとcmapi-jenkins.hpiを以下からコピーします。

  • HCL DevOps Code ClearCase-home-dir/java/lib/HCL DevOps Code ClearCase-jenkins.hpiとHCL DevOps Code ClearCase-home-dir/java/lib/cmapi-jenkins.hpi をコピーします。

  • コピーしたファイルHCL DevOps Code ClearCase-jenkins.hpiとcmapi-jenkins.hpiを、次のステップで説明するように、Jenkins管理ウェブページを使用してJenkinsサーバーにインストールします。

  • Manage Jenkins > Manage Plugins > Advanced タブを選択し、以下のプラグインを追加します。

    • cmapi-jenkins.hpi
    • HCL DevOps Code ClearCase-jenkins.hpi
  • a) Jenkinsホームページの左側に、"Manage Jenkins "オプションがありますので、それを選択してください。

    画像の説明

  • b) システム設定の下にスクロールダウンすると、"プラグインの管理 "があります。

    画像の説明

  • c) "Plugin Manager "の下にある "Advanced "オプションを選択します。

    画像の説明

  • d) スクロールダウンして、"プラグインのデプロイ "オプションに行く。次に、"Choose File "オプションを選択して、2つのプラグイン・ファイル(HCL DevOps Code ClearCase-jenkins.hpiとcmapi-jenkins.hpi)を選択し、"Deploy "をクリックします。

    画像の説明

  • e) 2つのプラグインファイルがデプロイされると、以下の結果が表示されます。

    画像の説明

6. JenkinsサーバーのSSL/TLS設定

JenkinsサーバーにSSL/TLSを使用したい場合は、Jenkinsのドキュメント(https://www.jenkins.io/doc/book/installing/initial-settings/ )を参照して、前述のコマンドラインフラグの代わりに他のコマンドラインフラグを使用してください。


Cover Image

HCL DevOps Code ClearCase と Jenkins 統合 - ステップバイステップガイド (Windows)

2023/12/27 - 読み終える時間: 9 分

HCL DevOps Code ClearCase Jenkins Integration on Windows - Step-by-Step Guide の翻訳版です。


HCL DevOps Code ClearCase と Jenkins 統合 - ステップバイステップガイド (Windows)

2023年12月12日

著者: Arun R / Senior Software Engineer

はじめに

Jenkins は人気のある DevOps ビルド自動化ツールです。オープンソースの統合は何年も前から利用可能ですが、この新しい統合は HCL DevOps Code ClearCase 開発チームによって作成され、HCLSoftware によって公式にサポートされています。

この統合は、Jenkinsのフリースタイルジョブとパイプラインジョブの両方をサポートします。デフォルトを超えて、HCL DevOps Code ClearCase統合は、DevOps Code ClearCase の完了トリガーから呼び出される Webhooks と、ストリーム上の変更をポーリングする DevOps Code ClearCase プラグインを持つ Jenkins ジョブを構成することによって、ビルドを開始する機能を追加します。

注: この統合により、Jenkins ジョブはビルドの必要に応じてビューを作成したり削除したりできるようになります。現在のところ、自動ビューとWebビューを持つ UCM のみがサポートされています。

SL No: Topic
1 環境
2 HCL DevOps Code ClearCase のインストール
3 Windows 上での Jenkins のインストールと設定
4 Windows での Jenkins のアンロック
5 Jenkins のカスタマイズ
6 Jenkins サーバの SSL/TLS 設定
1. 環境
  • HCL DevOps Code ClearCase 3.0.1 リリース。
  • Jenkins LTS 2.332.x for Windows。
  • Microsoft Windows 10、11、2019 Serverおよび2022 Server。
  • 詳細については、システム要件のページを参照してください。
  • Jenkinsをインストールする前に、Java 8専用の64ビットJava実行環境(JRE)がインストールされている必要があります。JREをまだお持ちでない場合は、Adoptiumからhttps://adoptium.net/temurin/releases/?version=8。

Javaの環境変数のパスを設定します。システム環境変数の場合

ヒント Jenkinsのインストール時にJavaのホーム・ディレクトリを指定する必要があるため、Javaのパスを覚えておいてください。

  • JAVA_HOME変数にJDKのパスを設定します。同様に、JREについてもこのようにしてください。

    画像の説明

  • PATH変数に、JDK用のbinフォルダを設定します。

    画像の説明

ヒント Jenkinsのインストール中にJavaのホーム・ディレクトリを指定する必要があるため、Javaへのパスを覚えておくこと。

ステップ
2. HCL DevOps Code ClearCaseのインストール

WindowsホストにJenkinsをインストールする前に、まずHCL DevOps Code ClearCaseをインストールする必要があります。HCL DevOps Code ClearCase Remote ClientまたはHCL DevOps Code ClearCaseをインストールし、Jenkinsのビルドに自動ビューを使用する場合は、インストール中に Automatic Views コンポーネントを選択する必要があります。

画像の説明

3. Windows上でのJenkinsのインストールと構成

以下の手順を使用して、HCL DevOps Code ClearCase と Jenkins の統合のために Windows に Jenkins をインストールします。

  • Jenkins LTS 2.332.x for Windows の jenkins.msi インストール・ファイルを https://get.jenkins.io/windows-stable/2.332.4/ からダウンロードします。どのバージョンの Jenkins LTS 2.332.x でもダウンロードできるが、このブログでは 2.332.4 を使用します。
  • ダウンロードが完了したら、jenkins.msiファイルを実行し、インストールを進めます。以下のインストール手順に関する情報をいくつか示します。

    • Service Logon Credentials ダイアログ・ボックスの Run service as a local or domain user オプションに、Jenkinsを実行するユーザ・アカウントのドメイン・ユーザ名とパスワードを入力します。Test Credentials をクリックして、認証データを確認します。(Run service as Local System オプションは安全性が低いため、推奨しません)。

    注意: Run service as local or domain user オプションの場合、インストールを行うユーザは、サービスとしてログオンするために必要な権限を持っている必要があります。そうでない場合、アカウントが確認できないというエラーメッセージが表示されます。この状況を解決するには、ローカルセキュリティポリシーを更新して、ユーザーをユーザー権限の割り当てに追加する必要があります。

    画像の説明

    • ポートの選択]ダイアログ・ボックスで、Jenkinsを実行するポート番号を入力し、[ポートのテスト]をクリックして、選択したポートが使用可能かどうかを確認します。

    画像の説明

    • Javaホーム・ディレクトリ(JDKまたはJRE)を選択する必要がある場合、これはJavaがインストールされている場所であることを覚えておいてください。

    画像の説明

    • インストールが完了したら、Finishをクリックしてインストール・ウィザードを終了します。

    画像の説明

4. WindowsでJenkinsのロックの解除

WindowsにJenkinsをインストールしたら、以下の手順でロックを解除します。

  • Webブラウザで、インストール中に選択したポート番号に移動します。

    画像の説明

  • ヒント Jenkinsでポートを変更する方法については、https://phoenixnap.com/kb/jenkins-change-port を参照してください。

  • Jenkinsのアンロック・ダイアログ・ボックスが開きます。

    • ダイアログ・ボックスで提供された情報から、Windowsエクスプローラを使用してinitialAdminPasswordファイルの場所に移動し、Microsoftメモ帳などのテキストエディタでファイルを開く。
    • 以下はファイルのデフォルトのパスです。

    画像の説明

    • 注意:この場所は隠しディレクトリかもしれません。その場合、Windowsで隠しファイル、隠しフォルダ、隠しドライブの表示を有効にする必要があります。
    • initialAdminPassword ファイルからパスワードをコピーし、Unlock Jenkinsダイアログ・ボックスの管理者パスワード・フィールドに貼り付けて、Continue をクリックします。

    画像の説明

5. Jenkinsのカスタマイズ

Jenkins のインストール・プロセスを完了し、Jenkins のロックを解除した後、Windows 上で HCL DevOps Code ClearCase-Jenkins 統合に使用する前に、Jenkins をカスタマイズする必要があります。

以下の手順で Jenkins をカスタマイズしてから使用してください。

  • このインストールでは、Jenkins はポート 8080 でホストされます。ウェブ・ブラウザを開き、http://hostname:8080 にアクセスします。

  • Jenkinsのカスタマイズ・ダイアログ・ボックスで、最も頻繁に使用されるプラグインをJenkinsに自動的にインストールさせるには、Install suggested plugins をクリックします。

    画像の説明

  • インスタンス構成]ダイアログ・ボックスで、Jenkinsに使用させたいポート番号を確認し、Save and Continue をクリックします。これで初期カスタマイズは完了です。

  • Start using Jenkins をクリックして、Jenkinsダッシュボードに移動します。

  • HCLDevOpsCodeClearCase-home-dir/java/lib/HCLDevOpsCodeClearCase-jenkins.hpiHCLDevOpsCodeClearCase-home-dir/java/lib/cmapi-jenkins.hpi から HCL DevOps Code ClearCase-jenkins.hpiとcmapi-jenkins.hpi をコピーします。

  • コピーしたファイル HCLDevOpsCodeClearCase-jenkins.hpicmapi-jenkins.hpi を、次のステップで説明するように、Jenkins 管理ウェブページを使用してJenkinsサーバーにインストールします。

  • Manage Jenkins > Manage Plugins > Advanced タブを選択し、以下のプラグインを追加します。

    • cmapi-jenkins.hpi
    • HCLDevOpsCodeClearCase-jenkins.hpi

(a) Jenkinsホームページの左側に "Manage Jenkins" オプションがあるので、それを選択します。

画像の説明

(b) System Configuration の下にスクロールダウンすると、"Manage Plugins" があります。

画像の説明

(c) "Plugin Manager" の下にある "Advanced" オプションを選択してください。

画像の説明

(d) スクロールダウンして、"Deploy Plugin" オプションを選択します。次に、"Choose File" オプションを選択して、2つのプラグイン・ファイル、すなわち HCLDevOpsCodeClearCase-jenkins.hpicmapi-jenkins.hpi を選択し、"Deploy" をクリックします。

画像の説明

(e) 2つのプラグイン・ファイルがデプロイされると、以下の結果が表示されます。

画像の説明

6. JenkinsサーバーのSSL/TLS設定
  • JenkinsサーバーにSSL/TLSを使用したい場合は、Jenkinsのドキュメント(https://www.jenkins.io/doc/book/installing/initial-settings/ )を参照して、前述のコマンド・ライン・フラグの代わりに他のコマンド・ライン・フラグを使用してください。

Cover Image

HCL VersionVault のGCP へのデプロイを計画する

2023/8/9 - 読み終える時間: ~1 分

Plan Your HCL VersionVault Deployment in GCP の翻訳版です。


HCL VersionVault のGCP へのデプロイを計画する

2023年8月8日

著者: Cristina Suchland / Integrated Marketing Manager, Secure DevOps

はじめに

HCL VersionVault は、エンタープライズ ソフトウェア構成管理機能を使用して、革新的なチームが新しいプロジェクトを迅速かつ効果的に作成し、提供できるようにします。 HCL VersionVault を Google Cloud Platform (GCP) にデプロイする方法を学びます。

柔軟な導入と効果的な管理

HCL VersionVault サーバーとクライアントは、コンピューター エンジン サービスやその他のサービス (バックアップと災害復旧、ファイルストア、マネージドなど) を通じて仮想マシン (VM インスタンス) を提供するサーバー スペースを提供するクラウド サービス スイートである Google Cloud Platform (GCP) で正常に実行できます。 Microsoft Active Directory)。 GCP VM インスタンスは、HCL VersionVault もサポートしている Windows および Linux OS バージョンをサポートしているため、これらの OS バージョンを使用した完全な HCL VersionVault インストールを GCP でセットアップできます。

HCL VersionVault では、GCP VM インスタンスにも適用されるクライアントとサーバーのサイジング (CPU、メモリ、ディスク、ネットワーク遅延など) を推奨しています。 ローカル クライアント (動的ビューまたはスナップショット ビュー) の場合、通常、クライアントとサーバーが同じゾーン (理想的には同じクラスター内) で実行される必要があります。 リモート クライアント (自動ビューまたはウェブ ビュー) の場合、クライアントは、異なる GCP リージョン内のサーバー、または GCP とオンプレミス ネットワークの間でサーバーから分離できます。

GCP で HCL VersionVault を設定するときは、これらの推奨事項を満たし、コストを決定するなど、GCP のドキュメントとツールを参照する必要があります。HCL VersionVault が正常に実行されるように、GCP 仮想マシンのセットを構成するにはさまざまなオプションがあります。

ホワイトペーパーをダウンロードして、GCP の機能を使用して GCP に HCL VersionVault をデプロイする方法の詳細を確認してください。


Cover Image

HCL VersiobVault と Visual Studio Code の統合

2023/7/3 - 読み終える時間: 2 分

HCL VersionVault Integration with Visual Studio Code の翻訳版です。


HCL VersiobVault と Visual Studio Code の統合

2023年6月30日

著者: Nitesh Hibare / Lead Software Engineer

Visual Studio Code は、軽量で強力なデスクトップ ソース コード エディターです。 詳細については、https://code.visualstudio.com をご覧ください。

HCL VersionVault は、バージョン管理に使用されるソフトウェア構成管理 (SCM) ツールであり、ソース コード、設計文書、モデル、テスト計画、およびテスト結果へのアクセス制御を提供します。 安全なバージョン管理と信頼できるビルド監査を備えています。 詳細については、https://www.hcltechsw.com/jp/products/versionvault をご覧ください。

HCL VersionVault と Visual Studio Code IDE の統合により、次の VersionVault 操作が提供されます。

  • 既存のビューを追加
  • WANサーバーに接続します
  • アクティビティ - アクティビティの作成、既存のアクティビティの設定
  • ソース管理に追加
  • チェックアウト
  • チェックイン
  • チェックアウトを元に戻す
  • ハイジャック
  • ハイジャックを元に戻す
  • 名前の変更
  • 削除
  • リフレッシュ
  • リポジトリから更新
  • WANサーバーから切断します

UCMBase VersionVault をサポートします。 WebAutomatic の 2 つのビュー タイプを持つ Windows プラットフォームのみをサポートします。

前提条件
  • VersionVault または VersionVault リモート クライアントがインストールされている必要があります。
  • https://code.visualstudio.com から Visual Studio Code をダウンロードしてインストールします
  • VersionVault ビュー (Web/自動) は、VersionVault ツールを使用して作成する必要があります。

詳細については、VersionVault-VS Code 統合ガイドをダウンロードしてください。


Cover Image

HCL VersionVault v3.0.1 の新機能について

2023/6/19 - 読み終える時間: 2 分

What's New in HCL VersionVault v3.0.1 の翻訳版です。

HCL VersionVault v3.0.1 の新機能について

2023年6月13日

著者: Otto Klaren / Senior product manager and client advocacy manager for HCL Software. 共著: Peter Hack / VersionVault Architect

今年5月に発表されたばかりのHCL VersionVault v3.0.1ですが、皆様はご存知でしょうか?VersionVaultのユニークな機能は、世界で最も柔軟なソフトウェア構成管理(SCM)システムを構築するために組み合わされ、お客様に愛されています。

HCL VersionVaultは、コード、要件、設計文書、モデル、回路図、テスト計画、テスト結果などのソフト資産へのアクセス制御を提供します。ユーザー認証と信頼性の高い監査証跡により、最小限の管理作業でコンプライアンス要件を満たせます。

VersionVaultのスケーラビリティ、コンポーネント管理、セキュリティ管理、プロセス自動化/強化メカニズム、統合ビルド管理は、ソフトウェア(およびハードウェア)開発プロジェクトの最も重要な課題の多くを解決するために日々使用されています。

新しいv3.0.1リリースでは、ユーザビリティ、DevOpsツールチェーンとの統合、パフォーマンス、管理の容易さに主眼が置かれています。ここでは、エキサイティングな新製品機能の一部をご紹介します!

1. 自動ハイジャックモード

多くの開発プロジェクトは、HCL VersionVaultの予約チェックアウトに依存して、作業を調整し、ファイルをマージする必要性を低減しています。また、ファイルを書き込み可能にするための開発者のアクション(チェックアウトやハイジャック)を必要とせず、バージョン管理されたファイルを自由に変更できることを好む人もいます。

新しいv3.0.1では、VersionVaultのビュー(現在はスナップショットとWebビュー)に自動ハイジャックモードが追加されました。開発者は、新しいコマンドラインフラグ"-ahi/jack "で、スナップショットやWebビューを作成できるようになりました。自動ハイジャック・モードでビューを作成するオプションは、VersionVault Explorerでも利用できますが、現在はスナップショット・ビューにのみ適用されます。

自動ハイジャック・モードで作成されたビューは、バージョン管理されたファイルを、読み取り専用ではなく、書き込み可能なものとして表示します。 ファイルへのいかなる変更も、ユーザーの明示的な操作なしに、自動的にファイルをハイジャックします。 自動ハイジャックされたファイルは、以前のリリースで明示的にハイジャックされたファイルと同様に扱われます。 開発者が自分の変更をチェックインする準備ができたら、ファイルをチェックアウトし、必要であれば他のユーザーからの変更をマージし、結果をチェックインします。ハイジャックされたファイルは、「ハイジャック解除」して元の形に戻すことも可能です。

あなたのチームが予約チェックアウトの安全策を利用しない場合、新しい自動ハイジャック・モードは、ファイルをチェックする際に追加のマージの可能性を許容する、歓迎すべき機能拡張かもしれません。

注:自動ハイジャックモードは、ビューを作成するときに選択する必要があります。

2. Jenkins との統合

Jenkinsは、DevOpsのビルド自動化ツールとして人気があります。 オープンソースの統合は何年も前からありますが、この新しい統合はVersionVaultの開発チームによって作成され、HCLSoftwareによって公式にサポートされています。

この統合は、Jenkinsのフリースタイルジョブとパイプラインジョブの両方をサポートしています。 VersionVaultの統合では、デフォルトに加え、VersionVaultの配信完了トリガーから呼び出されるWebhooksや、VersionVaultプラグインを持つJenkinsジョブがストリーム上の変更をポーリングする設定により、ビルドを開始する機能が追加されています。

注:この統合により、Jenkinsジョブはビルドの必要に応じてビューの作成と削除を行えます。 現在、自動ビューとWebビューを持つUCMのみがサポートされています。

3. VersionVaultリモート・クライアント・オファリングにおける自動ビュー

自動ビューは、VersionVaultの仮想ファイルシステムであるMVFS(Multi-Version File System)を利用することで、高度でWANに適したワークスペース管理とセキュリティ強化機能を提供します。 v3.0.1以前は、自動ビューは、IBM Installation Managerを使用して、VersionVault製品群の中からインストールすることしかできませんでした。

自動ビューは、オプションでインストール可能な機能として、VersionVault Remote Client製品にも含まれるようになりました。 これにより、完全な製品機能を必要としないWANのみのユーザーに対する自動ビューの導入が大幅に容易になりました。

4. Microsoft Windows のシンボリックリンクのサポート

Microsoft Windows上で、VersionVaultはVOBシンボリックリンク(シンボリックリンク)を、シンボリックリンクの代わりにシンボリックリンクのターゲット(個々のファイルまたはディレクトリ階層全体)のコピーとしてスナップショットビューのコピー領域にロードしていました。 最近のWindowsのシンボリックリンクの改良により、VersionVault V3.0.1では、VOBシンボリックリンクをWindowsシンボリックリンクとして読み込むオプションが追加されました。 デフォルトの動作は変わりませんが、スナップショット・ビューを作成する際に、「cleartool mkview」コマンドで「-slink_mode use_slinks」を使用すると、新しい動作を選択できます。

5. 高性能なユニコード・ファイル管理

VersionVaultは、5つのエンコーディング(UTF-8、UTF-16LE、UTF-16BE、UTF-32LE、UTF-32BE)すべてのUnicodeファイルの広範囲なバージョン管理を提供します。 V3.0.1のUTFタイプマネージャーは、UTFファイルを扱う際のパフォーマンスを向上させました。 これは、チェックイン、チェックアウト、差分、マージ、注釈、およびクリアテキスト構築(必要なときにバージョンを解凍する)操作に影響します。

6. セミライブリフォーマット VOB

歴史的に、VOBスキーマの更新を必要とするVersionVaultの新機能を採用するために、VOBの再フォーマットが必要になることがあります(これは、v3.0.1の機能では必要ありません)。 スキーマを更新せずにVOBを再フォーマットすることで、VOBデータベースの断片化を解消し、ガベージコレクションを実行することも可能です。

VOBを再フォーマットする場合、従来はVOBをオフラインにする必要があり、非常に大きなVOBの場合、数時間から1日以上かかることがありました。 セミライブ再フォーマットVOBは、再フォーマット中もVOBを使用し続け、再フォーマット処理の最初と最後に短時間だけVOBをオフラインにする機能です。

これはVersionVault管理者にとって重要な機能であり、メンテナンスウィンドウを待つことなく、ほぼいつでもVOBを再フォーマットすることが可能になります。

7. プラットフォームの更新

お客様のご要望により、Oracle Solaris SPARCがCore VersionVaultのサポート対象プラットフォームとして追加されました。また、Oracle Solaris for x86は、Core VersionVaultプラットフォームとして変更されました。

Core VersionVaultプラットフォームは、プラットフォームを使用して製品開発を継続するために必要な必須機能を提供しますが、EclipseベースのGUIやVersionVault Remote Clientなど、Java Runtime Environment(JRE)を必要とするVersionVaultコンポーネントを除外します。

ご自身の目でお確かめください

HCL VersionVault v3.0.1は、いつでもどこでもアクセスできるため、必要な時に必要な場所で効率的に作業できます。ぜひ一度、その実力をお確かめください!

詳しくは、HCL VersionVault v3.0.1 のリリース情報をご覧ください。また、HCL VersionVault の導入をご検討の方は、HCLSoftware までお問い合わせください!


Cover Image

Docker コンテナによる VersionVault Dynamic View クライアントアクセス

2023/1/11 - 読み終える時間: 12 分

Docker Container with VersionVault Dynamic View Client Access の翻訳版です。


Docker コンテナによる VersionVault Dynamic View クライアントアクセス

はじめに

本ブログでは、HCL VersionVaultとDockerをインストールしたDockerホストに、Docker Container with Dynamic View Client Accessを提供する設定方法について説明します。これまで開発者は、1台のマシンで異なるバージョンのソフトウェアに対応する環境を構成するのは面倒な作業でした。しかし現在では、アプリのバージョンごとに「Dockerコンテナ」と呼ばれる隔離された環境を作成し、各コンテナは、開発者マシン上で同時に実行されるOSや他のコンテナの構成に影響を与えない個別の環境設定を保持することができます。このような柔軟な環境をユーザーに提供するため、HCL VersionVaultはDockerに対応するよう強化されました。

Si No: トピック
1 VersionVaultとDockerコンテナの統合のための前提条件
2 LinuxホストへのVersionVaultとDockerのインストール
3 NFS サーバーと Linux Automounter を Docker ホストにインストールする。
4 Dockerホスト上でのVOBとViewの作成
5 サンプルDockerコンテナ - 動的なビュークライアントアクセスを持つコンテナ
6 最終的な統合の動作
1. VersionVaultとDockerコンテナの統合のための前提条件

Linuxホスト上に以下の4つがインストールされ、稼働していることが必要です。

  • HCL VersionVault バージョン2.0.1以降
  • Docker
  • NFSサービス
  • Automounter サービス
  • LinuxホストへのDockerとVersionVaultのインストール

2.1. VersionVaultのインストール

  • MVFSとMVFSデバイスを共有するために、Dockerホストは最低限VersionVault 2.0.1をインストールし、VersionVaultダイナミックビュークライアントとして動作するように設定する必要があります。
  • コマンドラインユーザーのソフトウェア開発ワークステーションに必要な最小数のVersionVaultコンポーネントをインストールするため、Dockerホストでは、VersionVault最小開発者用インストールのみが必要です。
  • Dockerコンテナに含まれ、共有が必要な主なコンポーネントは、MVFSとview/VOBサーバーです。
  • HCL VV 2.0.1をDockerホストにインストールするには、IBM Installation Manager 1.8.6、1.9.1およびその将来の修正パックを使用する必要があります。

画像の説明

  • VV 2.0.1インストール後の "cleartool-version "コマンドのスクリーンショットを以下に掲載します。

画像の説明

2.2. Dockerのインストール

  • VersionVault 2.0.1がインストールされたLinuxホストには、最新バージョンのDockerをインストールすることができます。以下は、Docker Engineのインストール概要のリンクで、異なるLinuxプラットフォームでのインストール手順を共有しています。

https://docs.docker.com/engine/install/

1. DockerホストへのNFSサーバとLinux Automounterのインストール

  • VersionVaultは、NFSとLinuxオートカウンターを使用して、ビューやVOBストレージにアクセスします。Dockerホストシステムは、NFSとLinuxオートカウンター用に設定されている必要があります。

3.1. NFSサーバーのインストール

  • このブログ記事では、RedHat OSを使用しています。以下に示すコマンドは、使用する特定のLinuxディストリビューションによって異なります。

ステップ 1:サーバーの更新とホスト名の設定

サーバーには、再起動後も有効な固定IPアドレスと固定ホスト名が必要です。

画像の説明

ステップ 2:NFSサーバーのインストール。

次に、LinuxホストへのNFSサーバ・パッケージのインストールです。

画像の説明

インストール後、nfs-serverサービスを開始し、有効にします。

画像の説明

ステータスが "running" と表示されるはずです。

画像の説明

2. Linuxオートカウンターのインストール

ステップ 1:Linuxホストにautofsをインストールします。

画像の説明

  • AutoFSパッケージをインストールする場合、インストールプロセスでは以下のことが行われます。
  • /etcディレクトリに auto.master、auto.net、auto.misc などの複数の設定ファイルを作成します。
  • systemd に AutoFS サービスを作成 (Create) します。
  • 「nsswitch.conf」ファイルに automount エントリを追加し、files ソースにリンクします。

ステップ 2: インストール直後、systemctl status コマンドで AutoFS サービスが起動していることを確認します。

画像の説明

ステップ 3: スタートアップ時に実行されるように、AutoFSサービスを有効にすることもできます。

画像の説明

3. Docker Host での VOB、View 作成について

  • Dockerコンテナ内で使用するVOB/Viewを作成する場合、オプションを指定する必要があります。-ホスト、-hpath、-gpath を指定します。hpathとgpathは、いずれもVOB/Viewの格納ディレクトリのグローバルパス名を指定します。

例えば、ホスト名がtest_hostであるマシンにVOB/Viewを常駐させたいとします。DockerホストとVOB/Viewサーバーのホストであるtest_hostは、automounterを使用しています。

コンテナ内で使用するVOB/ViewをDockerホスト上に作成する場合は、以下のようにします。

cleartool mkview -tag testview -host dockhost -hpath /net/ dockhost /viewstg/testview.vws -gpath /net/dockhost/user/viewstg/testview.vws /net/dockhost /user/viewstg/testview.vwsを実行します。

cleartool mkvob -tag /vob/testvob -host dockhost -hpath /net/dockhost/vobstg/testvob.vbs - gpath /net/dockhost/user/vobstg/testvob.vbs /net/dockhost/user/vobstg/testvob.vbsを実行します。

VOB/View が Docker ホストまたは Docker コンテナ上に存在する場合に必要です。

Dockerコンテナでは、コンテナの設定次第でストレージもホスト名も一時的なものになるため、Dockerコンテナの外部のVOB/Viewを使用することをお勧めします。

1. サンプルのDockerコンテナ

動的なビュークライアントアクセスが可能なDockerコンテナ

  • この方法では、コンテナ内にビューを作成し、VOBにアクセスして新しいファイル/ディレクトリの要素を作成したり、既存のファイル/ディレクトリの要素を変更したりすることができます。
  • Docker build ディレクトリは、Dockerfile, config_ssh.sh, config_dir, docker_compose.yml から構成されています。
  • Linuxのベースイメージは、Dockerホスト上で動作するVersionVaultのリリースでサポートされている必要があり、initプロセスもサポートされている必要があります。RedHatとSUSEの両社は、それぞれのレジストリでベースイメージを提供しています。
  • Linuxベース・イメージには、VersionVaultを実行するために必要なすべてのパッケージが含まれていない場合があります。ユーザーは、これらのパッケージをインストールするためにコンテナを更新する必要があります。Technote 535653887639718343 を参照してください。
  • Dynamic View Client Access 搭載コンテナに関連するDocker buildディレクトリとサンプルDockerfile、docker_compose.yml、config_ssh.sh、config_dirの詳細については、以下のリンク先を参照してください。ウィンドウ右上のResourcesドロップダウンで、"HCL VersionVault and Docker Containers"という記事へのリンクを探します。

https://www.hcltechsw.com/versionvault

2. 最終的な統合の実行

  • Dockerfile と docker_compose.yml ファイルが必要な設定内容で作成されたら、Docker build ディレクトリに移動して、以下のコマンドを実行してコンテナを構築・実行する必要があります。引数"-d "は、コンテナをデタッチャブルモードで実行するために使用されます。

画像の説明

  • 上記のコマンドは、サービス用のコンテナのビルド、(再)作成、起動、アタッチメントを行うものです。実行中のコンテナを確認するには、以下のコマンドを実行する。

画像の説明

画像の説明

  • コンテナにsshでアクセスするためには、コンテナのIPアドレスを見つける必要があります。これを実現するために、以下のコマンドを実行する必要があります。

画像の説明

コマンドの出力の最後に、IPアドレスが表示されます。以下は、参考のためのサンプルスニペットです。

画像の説明

  • コンテナのIPアドレスが見つかったら、Dockerホストの/etc/hostsファイルにコンテナのIPとホストネームを入力します。同様に、Dockerfileで提供された入力に従って、コンテナ作成時に作成したアカウントを使用してコンテナにsshした後、コンテナの/etc/hostsファイルにDockerホストのIPアドレスとホスト名の詳細情報を追加してください。

  • このブログ記事では、コンテナ作成時に「root」アカウントを作成するようにDockerfileをカスタマイズしているため、コンテナのログインにも同じアカウントを使用します。また、Dockerfileを修正して、そのアカウントがClearCaseコマンドの実行、ビューの作成、VOBへのアクセスを確実に行えるようにすれば、必要に応じてVOBオーナーや通常のVersionVaultユーザーを作成することができます。

  • VOBオーナーアカウントは、Dockerホストに存在するようなコンテナ内に作成されるため、ログイン後に切り替えることができます。VersionVaultのVOBオーナーアカウントを特定する理由は、VOBやVOBオブジェクトをrootアカウントやVersionVault管理者グループに所有させることは、権限の問題に直面することになるため、良い習慣とは言えないからです。

画像の説明

  • コンテナ内で "cleartool "コマンドを実行できるようになりました。

画像の説明

DockerホストがVersionVaultのバイナリをボリュームとしてコンテナと共有しているからこそ、「cleartool」コマンドの実行が可能なのです。

画像の説明

  • Dockerコンテナから、DockerホストにホストされているVOBを一覧表示し、説明することができます。

画像の説明

  • DockerホストでホストされているVOBにアクセスするために、コンテナ内にビューを作成する。

画像の説明

画像の説明

  • VOBにアクセスするために、ビューをコンテナ内に作成した後、ビューに設定します。

画像の説明

  • チェックアウトを行い、"mkelem "を実行してVOBの下に新しいファイルエレメントを追加しました。最後にcatコマンドを実行し、test.txtファイルの中身を確認。

画像の説明

  • コンテナ内に作成したファイル「test.txt」は、Dockerホストからアクセスすることができます。

画像の説明

サンプルビルドの実行

※本節では、サンプルビルドを実行します。

  • このセクションでは、コンテナ内でビルドを実行する方法について説明します。
  • コンテナにsshで入り、VOBのオーナーアカウントに切り替えて、コンテナ内に作成したビューにセットし、VOBにcdします。

画像の説明

  • VOBの下にhelloworldディレクトリが作成され、その下に簡単なC言語プログラムが配置されているのがわかります。

画像の説明

  • 次に、ビルドユーティリティ "clearmake "を実行して、単純なCコードをコンパイルし、helloworldプログラムを実行して出力を見ます。

画像の説明

  • clearmakeの完了後、上記のスクリーンショットから、helloworldの実行ファイルが作成され、 実行可能な状態にあることが分かります。

画像の説明

  • この例では、コンテナ内でのシンプルなclearmakeのビルドを確認しましたが、同様の方法で、Dockerコンテナ内で実行可能な他のカスタマイズされたビルドを設定することが可能です。このように、異なるビルド環境のために複数の物理ビルドマシンを構成する代わりに、異なるコンテナ内で実行するようにビルド環境を構成することができるので、コストと時間を節約することができます。

  • VersionVaultは、コンテナ内にインストールすることができます。コンテナではMVFSファイルシステムのインストールと起動を行わないため、インストールはサーバーインストールである必要があります(最小または完全な開発者用インストールではありません)。


Cover Image

HCL VersionVault Express を Azure Cloud Platform で利用する

2022/7/22 - 読み終える時間: 8 分

HCL VersionVault Express on the Azure Cloud Platform の翻訳版です。


HCL VersionVault Express を Azure Cloud Platform で利用する

2022年7月21日

著者: Laurent Marechal / Advisory Software Engineer


はじめに

Azure Cloud Platform上のパブリックまたはプライベートクラウドで、HCL VersionVault Express仮想マシンのインスタンスを立ち上げて実行する方法について説明します。


とりかかり

始めるには、Azure Cloud Platform に接続された Azure アカウントが必要です。仮想マシンを操作するために、ブラウザでAzure Cloud Consoleを使用することができますが、コマンドライン・ツールを取得するためにAzure CLIをダウンロードしてインストールすることも検討してください(https://docs.microsoft.com/en-us/cli/azure/install-azure-cli を参照)。本記事では、Azure CLIをお持ちで、コマンドラインツールを使用できる方を想定しています。この作業を進めるにあたり、Azureのゾーン、リージョン、VPC、サブネットについて知っておく必要があります。先に進み、Azureアカウントにログインします。

az login

複数のサブスクリプションを持っている場合、ログイン時に正しいサブスクリプションIDを指定し、アカウントのサブスクリプションを設定します。

az login –tenant <tenant_ID>
az account set –subscription <subscription_ID>


リソースグループ

Azureでは、すべてのリソースを保持するために、リソースグループが必要です。まだ定義されていない場合は、以下のように新規に作成します。

az group create –name myVVExpressRG –location eastus


VHDファイルの生成または取得

VersionVault Expressは、仮想マシンとしてOVAファイル(/my_pathdirectoryにコピーされることが前提)で提供されます。Azure Cloud PlatformでOVAファイルを使用する前に、Azureが使用するVHDディスク・イメージに変換する必要があります。

または、提供された VHD イメージがバージョンに利用可能であれば、それを使用することもできます。


OVAファイルを使って解凍し、VHDに変換する方法

変換を行う方法として、フリーのVirtualBoxツールであるVBoxManage(https://www.virtualbox.org/wiki/Downloads 参照)を使用する方法があります。まず、OVAファイルの中身を展開します。

tar -xvf /my_path/vvexpress.ova

解凍されたファイルには、versionvault-disk001.vmdkのような名前のVMDK形式のディスクイメージが含まれています。そのファイルをVboxManageツールで使用して、VHDファイルを生成します。

VBoxManage clonehd –format VHD \
/my_path/versionvault-disk001.vmdk \
/my_path/versionvault-disk001-dyn.vhd

VHDを固定サイズに変換する

Azure は、固定サイズの VHD ディスクイメージのみをサポートしています。そのため、先ほど生成したVHDを固定サイズ(ダイナミックではない)に変換する必要があります。固定サイズのVHDを作成するには、VBoxManageユーティリティを使用します。

VBoxManage clonehd \
/my_path/versionvault-disk001-dyn.vhd \
/my_path/versionvault-disk001.vhd \
–variant Fixed

提供されたVHDを使用する

お使いのバージョンですぐに使用できるVHDが提供されている場合があります。この場合、このVHDを直接使用することができます。


VHDのアップロードとインポート

ストレージアカウントとコンテナの作成

VHD ファイルを blob としてアップロードし、その blob を使用して VM で使用できる OS ディスク イメージを作成できるように、Azure ストレージ アカウントを作成します。なお、ストレージアカウント名は小文字のアルファベットと数字で、Azure全体で一意である必要があります。

az storage account create \
–resource-group myVVExpressRG \
–name foobarvvestg \
–allow-shared-key-access

次に、アップロードしたblob(VHDファイル)を保持するコンテナをアカウント内に作成します。

az storage container create \
–account-name foobarvvestg \
–name vvevhds

VHDのアップロードとディスクの作成

あとは、先ほど作成したコンテナ内にVHDをblobとしてアップロードします。

az storage azcopy blob upload \
–account-name foobarvvestg \
–container vvevhds \
–source “/my_path/versionvault-disk001.vhd” \
–destination “versionvault-disk001.vhd”

blobname(destination)は好きなものを入れてください。次に、以下のコマンドを使用して、後でOSディスクを作成するために使用する、このblobのURLを探します。

az storage account show-connection-string \
–resource-group myVVExpressRG \
–name foobarvvestg

az storage blob url \
–connection-string “<from above>” \
–container-name vvevhds \
–name versionvault-disk001.vhd

Create an Azure disk to hold the uploaded VHD disk image so that a VM can use it. The source comes from the blob URL above.

az disk create \
–resource-group myVVExpressRG \
–name myVVEdiskOS \
–sku standard_lrs \
–source https://foobarvvestg.blob.core.windows.net/vvevhds/versionvault-disk001.vhd

Tip!: サポートされていないダイナミックディスクに関するエラーが表示された場合は、先に説明したように、VHD ファイルを固定ディスクに変換する必要があります。

ネットワーク・セキュリティ・グループの作成

VersionVault Expressは、最大で4つのポートを使用します。そのすべてを公開することも、一部を公開することも可能ですが、少なくとも1つのポートを公開する必要があります。ポートを公開するには、以下に作成するVMで使用できる適切なルールを持つネットワークセキュリティグループを作成します。

公開するポートを選択することができます。

  • VersionVault Expressのブラウザ・インターフェイス/REST APIsは設定可能ですが、デフォルトではポート443です。
  • VersionVault Expressアプライアンスのセットアップ・コンソール(ポート8443
  • VersionVaultクライアントがポート8080で接続するサーバ
  • 仮想マシンへのSSHインターフェイス(ポート22)。

あなたの設定と異なるバージョンで導入された機能に基づいて、追加のポートが必要になる場合があります。完全なリストについては、リリースノートを参照してください。

ネットワークセキュリティグループを作成し、すべてのポートを開放するルールを追加します。

az network nsg create \
–resource-group myVVExpressRG \
–name myVVEnsg

az network nsg rule create \
–resource-group myVVExpressRG \
–nsg-name myVVEnsg \
–name myVVEnsgrule \
–priority 100 \
–access Allow –direction Inbound \
–destination-address-prefixes ‘*’ \
–destination-port-ranges 22 443 8443 8080 \
–source-address-prefixes ‘*’\
–source-port-ranges ‘*’

Tip!: ソース仮想マシンを設定するためにVersionVault Expressアプライアンスのセットアップ・コンソールを公開する必要がありますが、マシン・イメージ・インスタンスを本番環境に置く際には、ポート8443と22を無効化する必要があります。

VMインスタンスの作成

OVAファイルが(VHDディスク・イメージとして)アップロードされ、ネットワーク・セキュリティ・グループができたので、ディスク・イメージに基づいて実行するVMインスタンスを開始することができます。最新のVersionVault Expressのシステム要件を確認し、VMに推奨されるメモリとCPUの数を入手してください。次に、Azureのドキュメントを確認し、VMサイズ(例えば、https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/)とディスクSKU値(例えば、https://docs.microsoft.com/en-us/azure/virtual-machines/disks-types#disk-type-comparison、https://docs.microsoft.com/en-us/cli/azure/disk?view=azure-cli-latest#az_disk_create)の推奨値に一致する適切な値を見つけます。また、VersionVault Express仮想マシンは、データ(VOB、ビュー、その他のインスタンス固有のデータ)が独自のディスクを必要とするように設計されています。2番目のディスクの適切なサイズを決定します。コマンドは次のようなものになります。

az disk create \
–resource-group myVVExpressRG \
–name myVVEDiskVOB \
–location eastus \
–size-gb 100 \
–sku standard_lrs

az vm create \
–resource-group myVVExpressRG \
–name myVVEVM \
–public-ip-sku Standard \
–nsg myVVEnsg \
–attach-os-disk  myVVEdiskOS \
–os-type linux \
–size Standard_B2ms \

–location eastus \
–attach-data-disks  myVVEDiskVOB \
–boot-diagnostics-storage “foobarvvestg”

VersionVault Expressの初回起動時には、2つのチェックが行われます。1つ目は、VOB用のディスクがマウントされているかどうかの確認です。これまで通りであれば、これは完了しています。2つ目のチェックは、ネットワークが設定されているかどうかです。VersionVault Expressでは、デフォルトのネットワーク構成が表示され、それを受け入れるか、変更することができます。Azure Cloud Platformでは、デフォルトの構成で問題ないはずです。VMの前に座っている場合、VersionVault Expressの起動を継続させるために、任意のキーを押すことができます。しかし、Azure Cloudで初めてVMを起動する場合、プロンプトが表示されないため、何もキーを押さないかもしれません。10分後、VersionVault Expressはタイムアウトし、デフォルトのネットワーク構成が表示されます。

VMの設定

ここまでで、VersionVault ExpressのVMは起動しているはずですが、ログインすることができません。この理由の1つは、まだユーザーを作成していないことです。また、VersionVault Expressのプロセスのほとんどはまだ開始されていません。必要なプロセスの1つであるアプライアンス・セットアップ・コンソールは起動しています。

VersionVault Expressのシステム管理者は、VersionVault Expressの設定とVersionVault Expressのユーザーを管理するために、アプライアンス・セットアップ・コンソールを使用します。アプライアンスセットアップコンソールは、ポート8443(ネットワークセキュリティグループを覚えていますか)で実行され、ブラウザインターフェイスとREST APIを提供します。

次に進むには、最低限必要な設定を行う必要があります。

ローカル管理者

最初にしなければならないことは、システム管理者ユーザーを作成することです。最初にログインしようとしたユーザーにはローカル管理者権限が付与されます。

重要! このアカウントを忘れたり失ったりしないようにしてください。

ブラウザで https://myVVEVM IP:8443 にアクセスし、ユーザー名とパスワードを選択するか、REST API (https://myVVEVM IP:8443/setup/swagger-ui.html に記述) を使用して createInitialAdminUser() API に投稿します。なお、myVEVMのIPは、上記のaz vm createコマンドで作成されたVMのIPアドレスです。

ホスト名

メール通知やウェブフックを使用する場合は、仮想マシンのホスト名をDNSで解決可能なものに変更することを検討するとよいでしょう。

ポート、証明書、SSHキー

ポートを設定するか、デフォルトの443ポートを受け入れる必要があります。ネットワークセキュリティグループでポートを公開することを忘れないでください。SSL証明書やSSHキーをお持ちの場合は、今すぐ追加してください。 ライセンス設定

ライセンス情報を入力する必要がある場合があります。入力しない場合、HCLは、このVersionVault Expressインスタンスが期間限定の無料トライアルを実行していると見なします。

LDAPサーバー

VersionVault Expressは、自身のユーザーを管理するか(デフォルトの構成)、外部のLDAPサーバーにバインドすることができます。ここで、どちらを選択するか決定してください。

独自のユーザーを管理することを選択した場合、今すぐ少なくとも 1 人のユーザーを作成することをお勧めします。これは、アプライアンスのセットアップコンソールまたは REST APIs のいずれかを使用して行うことができます。セットアップ コンソールを使用するには、新しいユーザーの電子メール アドレスを入力し、[ユーザーの追加] ボタンをクリックします。SMTP サーバーを設定した場合、ユーザーにはアカウント作成を促す電子メールが送信されます。そうでない場合は、「Temporarily disable SMTP」スイッチを切り替えてから、ユーザー一覧のメールアイコンをクリックします。これにより、デフォルトのメールクライアントが起動し、そこから招待状を送信することができます。 設定の検証

すべての項目を確認し(ほとんどのセクションに「確認」または「検証」ボタンがあります)、設定を保存し、VersionVault Expressを起動します。

ユーザーを作成した場合は、受け取ったメールのリンクからサインアップし、ログインしてもらいます。


最終テスト

この時点で、VersionVault Expressのインスタンスが稼働し、少なくとも1人のユーザーがログインできる状態になっているはずです。ブラウザーを開き、IPアドレス(DNSが設定されている場合はホスト名)のポートに接続してテストしてください。プロジェクトやVOBはまだありません。

これでVMは本番環境での使用が可能になりました。


VersionVault Expressの使用

これで、VersionVault Expressを使い始める準備が整いました。あらかじめ設定されているユーザでログインし、最初のプロジェクトを作成します。もし、システムが許可していれば、プロジェクトに参加するユーザーを追加してください。そうでない場合は、システム管理者に新しいユーザーを招待するように依頼してください。


追加情報

VMインスタンスの停止

Azure CLIを使用して、次のようにVMを停止できます。

az vm stop \.
–resource-group myVVExpressRG
-name myVVEVM
az vm deallocate \ -resource-group myVVExpressRG -name myVVEVM
-resource-group myVVExpressRG ?name myVVEVM
-name myVEVM

VMインスタンスの追加作成

プロジェクト・チームごとにインスタンスを作成したり、組織内の異なるビジネス・ユ ニットにインスタンスを割り当てたりすることができます。新しいインスタンスを作成するには、次の手順を使用します。

  • アップロードしたブロブから新しいOSディスク(上記ではmyVVEdiskOSと呼びます)を作成します。
  • 新しいVOBディスクを作成する(上記ではmyVEdiskVOBと呼ぶ)。
  • 新しいディスクを使用して新しいVMインスタンスを作成し(上記のmyVEVMと呼びます)、それを設定します。ネットワークセキュリティグループは以前作成したもの(上記myVEnsgと呼ぶ)を使用できます。

複数のリソースグループの使用

IT環境によっては、あらかじめ定義されたリソースグループがあり、それを使用することもできますし、複数のリソースグループを使用して、様々な構成(サブネット、nsg、ディスクなど)を分けたい場合もあるでしょう。このような場合、コマンドラインから作業するときは、Azure のコマンドラインの要件であるため、使用するそれぞれの完全なリソースパスを提供する必要があります。新しいVMを作成する例です。

az vm create
-resource-group <RESOURCE_GROUP_1> \
-name <VM_NAME
-name <VM_NAME> \
-subnet /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/ <RESOURCE_GROUP_2>/providers/Microsoft.Network/virtualNetworks/<VNET>/subnets/<SUBNET> \...
-public-ip-address "" \.
-nsg /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_2>/providers/Microsoft.Network/networkSecurityGroups/<NSG>の各プロバイダー。
-attach-os-disk /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_3>/providers/Microsoft.Compute/disks/<VIRTUAL_OS_DISK> \
-os-type linux
-size Standard_B2ms ? -location <REGION
-location <REGION> \
-attach-data-disks /subscription/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_3>/providers/Microsoft.Compute/disks/<VIRTUAL_DATA_DISK>

このブログについて

HCL Japan の Software 部門の複数担当者で HCL Software 全般について記しています。

Tags

Academy Accelerate Accelerator Actian Ambassador AoC AppDev Pack AppScan ASoC BigFix BigFix Workspace CAA CDP Clara Client Applicatin Access Cloud Native Commerce Common Local License Server Compass Connections Connnections CVE-2021-44228 DevOpes Velocity DevOps DevOps Code ClearCase DevOps Code RealTime DevOps Deploy DevOps.Launch.AppScan DevOps Model RealTim DevOps Model RealTime DevOps Plan DevOps Test DevOps Velocity Digital Experience Discover Domino Domino Leap Domino Volt Domino管理者アップデート認定試験対策 DQL DRYiCE DX Enterprise Integrator event General HCAA HCL Ambassador HCL Ambassadors HCL Domino REST API HCL OneTest Embedded HCL Z and I Emulator HCL Z and I Emulator for Transformation HCLSoftware U Hero history HTMO iControl iNotes IZSAM KEEP Launch Launch.DevOps Leap Link MarvelClient nds2019 ndv12beta Noets/Domino Nomad Nomad Mobile Nomad Web notes Notes/Domino notes-domino-9-10-limited-supportability-as-of-202204 Notes/Domino V12 Notes/Domion notescons Now OneDB OneTest OnTime REST RTist SafeLinx Sametime SoFy Total Experience Traveler Traveler for Microsoft Outlook Unica Unica Discover Unica Interact UrbanCode Deploy UrbanCode Velocity Velocity Verse VersionVault Volt Volt MX Volt MX Go Volt MX サンプルアプリ Wordload Automation Workload Automation youtube Z Z Abend Investigator Z and I Emulator Z and I Emulator for Transformation Z and I Emulator for Web Z and I Emulator for Web Client Z Asset Optimizer Z Data Tools Z Software Asset Manager ZAI ZAO ZIE ZIE for Transformation ZIE for Web ZIE for Windows ZIET ZIETrans ZIEWeb イベント ガイド クラウド サポート サポート技術情報 サポート終了 セキュリティ セキュリティー セキュリティー脆弱性 テクてく Lotus 技術者夜会 ニュース ノーツコンソーシアム パートナー ライセンス 九州地区 Notes パートナー会 出荷日 研修