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)機能の詳細について説明します。以下のトピックを取り上げます。
SLRVを使用してVOBを再フォーマットする主な利点は以下の通りです。
SLRVの仕組みに入る前に、標準的なreformatvobの仕組みとその主な問題点について簡単に説明します。
次の図はVOBに対して行われる標準的なreformatvobの動作を表しています。
セミライブ再フォーマットVOBプロセスは、2つのステージで動作します。
この最初のステージでは、SLRVはコマンドを発行することにより、指定されたVOBに対して開始される: cleartool reformatvob -semilive <vob_stg_path
下図は、この段階で実行されるタスクを表しています。
VOB上で進行中のSLRVを完了させるために、管理者は以下のSLRV completeコマンドを実行します: cleartool reformatvob -semilive -complete <vob_stg_path
下図はSLRV completeコマンド発行後、この段階で実行されるタスクを表しています。
次の表は、セミ・ライブ再フォーマット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 |
標準のreformatvobにはこのようなオプションはありません。代わりに、管理者はreformatvobコマンドの出力に表示されるダンプとロードのメッセージに頼らなければなりません。 |
|
SLRVがオリジナルのVOBを完成させると、dbは将来のバックアップや参照用に |
標準のreformatvobは将来のバックアップや参照用に古いデータベースの名前をdb.dateに変更します。 |
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設定 |
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をインストールした後
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が必要です。
HCL HCL DevOps Code ClearCase と Jenkins の統合のために Linux に Jenkins をインストールするには、以下の手順を使用します。
https://get.jenkins.io/war-stable/ から jenkins.war ファイルをダウンロードし、ホームディレクトリに置きます。
以下のコマンドを実行します。
Jenkinsのインストール中に、以下の例に示すように、Jenkinsのログと初期パスワードが作成される:
デフォルトでは、initalAdminPasswordはユーザーのホーム・ディレクトリにあります。例
ヒント: パスワードは、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ファイルからパスワードを取得して、[続行]をクリックします。
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 タブを選択し、以下のプラグインを追加します。
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つのプラグインファイルがデプロイされると、以下の結果が表示されます。
JenkinsサーバーにSSL/TLSを使用したい場合は、Jenkinsのドキュメント(https://www.jenkins.io/doc/book/installing/initial-settings/ )を参照して、前述のコマンドラインフラグの代わりに他のコマンドラインフラグを使用してください。
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 設定 |
Javaの環境変数のパスを設定します。システム環境変数の場合
ヒント Jenkinsのインストール時にJavaのホーム・ディレクトリを指定する必要があるため、Javaのパスを覚えておいてください。
JAVA_HOME変数にJDKのパスを設定します。同様に、JREについてもこのようにしてください。
PATH変数に、JDK用のbinフォルダを設定します。
ヒント Jenkinsのインストール中にJavaのホーム・ディレクトリを指定する必要があるため、Javaへのパスを覚えておくこと。
WindowsホストにJenkinsをインストールする前に、まずHCL DevOps Code ClearCaseをインストールする必要があります。HCL DevOps Code ClearCase Remote ClientまたはHCL DevOps Code ClearCaseをインストールし、Jenkinsのビルドに自動ビューを使用する場合は、インストール中に Automatic Views コンポーネントを選択する必要があります。
以下の手順を使用して、HCL DevOps Code ClearCase と Jenkins の統合のために Windows に Jenkins をインストールします。
ダウンロードが完了したら、jenkins.msiファイルを実行し、インストールを進めます。以下のインストール手順に関する情報をいくつか示します。
注意: Run service as local or domain user オプションの場合、インストールを行うユーザは、サービスとしてログオンするために必要な権限を持っている必要があります。そうでない場合、アカウントが確認できないというエラーメッセージが表示されます。この状況を解決するには、ローカルセキュリティポリシーを更新して、ユーザーをユーザー権限の割り当てに追加する必要があります。
WindowsにJenkinsをインストールしたら、以下の手順でロックを解除します。
Webブラウザで、インストール中に選択したポート番号に移動します。
ヒント Jenkinsでポートを変更する方法については、https://phoenixnap.com/kb/jenkins-change-port を参照してください。
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.hpi と HCLDevOpsCodeClearCase-home-dir/java/lib/cmapi-jenkins.hpi から HCL DevOps Code ClearCase-jenkins.hpiとcmapi-jenkins.hpi をコピーします。
コピーしたファイル HCLDevOpsCodeClearCase-jenkins.hpi と cmapi-jenkins.hpi を、次のステップで説明するように、Jenkins 管理ウェブページを使用してJenkinsサーバーにインストールします。
Manage Jenkins > Manage Plugins > Advanced タブを選択し、以下のプラグインを追加します。
(a) Jenkinsホームページの左側に "Manage Jenkins" オプションがあるので、それを選択します。
(b) System Configuration の下にスクロールダウンすると、"Manage Plugins" があります。
(c) "Plugin Manager" の下にある "Advanced" オプションを選択してください。
(d) スクロールダウンして、"Deploy Plugin" オプションを選択します。次に、"Choose File" オプションを選択して、2つのプラグイン・ファイル、すなわち HCLDevOpsCodeClearCase-jenkins.hpi と cmapi-jenkins.hpi を選択し、"Deploy" をクリックします。
(e) 2つのプラグイン・ファイルがデプロイされると、以下の結果が表示されます。
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 をデプロイする方法の詳細を確認してください。
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 操作が提供されます。
UCM と Base VersionVault をサポートします。 Web と Automatic の 2 つのビュー タイプを持つ Windows プラットフォームのみをサポートします。
詳細については、VersionVault-VS Code 統合ガイドをダウンロードしてください。
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ツールチェーンとの統合、パフォーマンス、管理の容易さに主眼が置かれています。ここでは、エキサイティングな新製品機能の一部をご紹介します!
多くの開発プロジェクトは、HCL VersionVaultの予約チェックアウトに依存して、作業を調整し、ファイルをマージする必要性を低減しています。また、ファイルを書き込み可能にするための開発者のアクション(チェックアウトやハイジャック)を必要とせず、バージョン管理されたファイルを自由に変更できることを好む人もいます。
新しいv3.0.1では、VersionVaultのビュー(現在はスナップショットとWebビュー)に自動ハイジャックモードが追加されました。開発者は、新しいコマンドラインフラグ"-ahi/jack "で、スナップショットやWebビューを作成できるようになりました。自動ハイジャック・モードでビューを作成するオプションは、VersionVault Explorerでも利用できますが、現在はスナップショット・ビューにのみ適用されます。
自動ハイジャック・モードで作成されたビューは、バージョン管理されたファイルを、読み取り専用ではなく、書き込み可能なものとして表示します。 ファイルへのいかなる変更も、ユーザーの明示的な操作なしに、自動的にファイルをハイジャックします。 自動ハイジャックされたファイルは、以前のリリースで明示的にハイジャックされたファイルと同様に扱われます。 開発者が自分の変更をチェックインする準備ができたら、ファイルをチェックアウトし、必要であれば他のユーザーからの変更をマージし、結果をチェックインします。ハイジャックされたファイルは、「ハイジャック解除」して元の形に戻すことも可能です。
あなたのチームが予約チェックアウトの安全策を利用しない場合、新しい自動ハイジャック・モードは、ファイルをチェックする際に追加のマージの可能性を許容する、歓迎すべき機能拡張かもしれません。
注:自動ハイジャックモードは、ビューを作成するときに選択する必要があります。
Jenkinsは、DevOpsのビルド自動化ツールとして人気があります。 オープンソースの統合は何年も前からありますが、この新しい統合はVersionVaultの開発チームによって作成され、HCLSoftwareによって公式にサポートされています。
この統合は、Jenkinsのフリースタイルジョブとパイプラインジョブの両方をサポートしています。 VersionVaultの統合では、デフォルトに加え、VersionVaultの配信完了トリガーから呼び出されるWebhooksや、VersionVaultプラグインを持つJenkinsジョブがストリーム上の変更をポーリングする設定により、ビルドを開始する機能が追加されています。
注:この統合により、Jenkinsジョブはビルドの必要に応じてビューの作成と削除を行えます。 現在、自動ビューとWebビューを持つUCMのみがサポートされています。
自動ビューは、VersionVaultの仮想ファイルシステムであるMVFS(Multi-Version File System)を利用することで、高度でWANに適したワークスペース管理とセキュリティ強化機能を提供します。 v3.0.1以前は、自動ビューは、IBM Installation Managerを使用して、VersionVault製品群の中からインストールすることしかできませんでした。
自動ビューは、オプションでインストール可能な機能として、VersionVault Remote Client製品にも含まれるようになりました。 これにより、完全な製品機能を必要としないWANのみのユーザーに対する自動ビューの導入が大幅に容易になりました。
Microsoft Windows上で、VersionVaultはVOBシンボリックリンク(シンボリックリンク)を、シンボリックリンクの代わりにシンボリックリンクのターゲット(個々のファイルまたはディレクトリ階層全体)のコピーとしてスナップショットビューのコピー領域にロードしていました。 最近のWindowsのシンボリックリンクの改良により、VersionVault V3.0.1では、VOBシンボリックリンクをWindowsシンボリックリンクとして読み込むオプションが追加されました。 デフォルトの動作は変わりませんが、スナップショット・ビューを作成する際に、「cleartool mkview」コマンドで「-slink_mode use_slinks」を使用すると、新しい動作を選択できます。
VersionVaultは、5つのエンコーディング(UTF-8、UTF-16LE、UTF-16BE、UTF-32LE、UTF-32BE)すべてのUnicodeファイルの広範囲なバージョン管理を提供します。 V3.0.1のUTFタイプマネージャーは、UTFファイルを扱う際のパフォーマンスを向上させました。 これは、チェックイン、チェックアウト、差分、マージ、注釈、およびクリアテキスト構築(必要なときにバージョンを解凍する)操作に影響します。
歴史的に、VOBスキーマの更新を必要とするVersionVaultの新機能を採用するために、VOBの再フォーマットが必要になることがあります(これは、v3.0.1の機能では必要ありません)。 スキーマを更新せずにVOBを再フォーマットすることで、VOBデータベースの断片化を解消し、ガベージコレクションを実行することも可能です。
VOBを再フォーマットする場合、従来はVOBをオフラインにする必要があり、非常に大きなVOBの場合、数時間から1日以上かかることがありました。 セミライブ再フォーマットVOBは、再フォーマット中もVOBを使用し続け、再フォーマット処理の最初と最後に短時間だけVOBをオフラインにする機能です。
これはVersionVault管理者にとって重要な機能であり、メンテナンスウィンドウを待つことなく、ほぼいつでもVOBを再フォーマットすることが可能になります。
お客様のご要望により、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 までお問い合わせください!
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 | 最終的な統合の動作 |
Linuxホスト上に以下の4つがインストールされ、稼働していることが必要です。
2.1. VersionVaultのインストール
2.2. Dockerのインストール
https://docs.docker.com/engine/install/
1. DockerホストへのNFSサーバとLinux Automounterのインストール
3.1. NFSサーバーのインストール
ステップ 1:サーバーの更新とホスト名の設定
サーバーには、再起動後も有効な固定IPアドレスと固定ホスト名が必要です。
ステップ 2:NFSサーバーのインストール。
次に、LinuxホストへのNFSサーバ・パッケージのインストールです。
インストール後、nfs-serverサービスを開始し、有効にします。
ステータスが "running" と表示されるはずです。
2. Linuxオートカウンターのインストール
ステップ 1:Linuxホストにautofsをインストールします。
ステップ 2: インストール直後、systemctl status コマンドで AutoFS サービスが起動していることを確認します。
ステップ 3: スタートアップ時に実行されるように、AutoFSサービスを有効にすることもできます。
3. Docker Host での 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コンテナ
https://www.hcltechsw.com/versionvault
2. 最終的な統合の実行
コマンドの出力の最後に、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管理者グループに所有させることは、権限の問題に直面することになるため、良い習慣とは言えないからです。
DockerホストがVersionVaultのバイナリをボリュームとしてコンテナと共有しているからこそ、「cleartool」コマンドの実行が可能なのです。
※本節では、サンプルビルドを実行します。
この例では、コンテナ内でのシンプルなclearmakeのビルドを確認しましたが、同様の方法で、Dockerコンテナ内で実行可能な他のカスタマイズされたビルドを設定することが可能です。このように、異なるビルド環境のために複数の物理ビルドマシンを構成する代わりに、異なるコンテナ内で実行するようにビルド環境を構成することができるので、コストと時間を節約することができます。
VersionVaultは、コンテナ内にインストールすることができます。コンテナではMVFSファイルシステムのインストールと起動を行わないため、インストールはサーバーインストールである必要があります(最小または完全な開発者用インストールではありません)。
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 イメージがバージョンに利用可能であれば、それを使用することもできます。
変換を行う方法として、フリーの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 ファイルを 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で使用できる適切なルールを持つネットワークセキュリティグループを作成します。
公開するポートを選択することができます。
あなたの設定と異なるバージョンで導入された機能に基づいて、追加のポートが必要になる場合があります。完全なリストについては、リリースノートを参照してください。
ネットワークセキュリティグループを作成し、すべてのポートを開放するルールを追加します。
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を使い始める準備が整いました。あらかじめ設定されているユーザでログインし、最初のプロジェクトを作成します。もし、システムが許可していれば、プロジェクトに参加するユーザーを追加してください。そうでない場合は、システム管理者に新しいユーザーを招待するように依頼してください。
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インスタンスの追加作成
プロジェクト・チームごとにインスタンスを作成したり、組織内の異なるビジネス・ユ ニットにインスタンスを割り当てたりすることができます。新しいインスタンスを作成するには、次の手順を使用します。
複数のリソースグループの使用
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>