2020/9/15 - 読み終える時間: 10 分

HCL Accelerate はバリューチェーン管理を行うソフトウェアです。ソフトウェア開発で要となる Jenkins との連携の実際を解説する記事 HCL Accelerate VSM with Jenkins – Part 1 の翻訳版です。

HCL Accelerate VSM を Jenkins と組み合わせて使用する - パート 1

2020年9月14日

著者: Daniel Trowbridge / Technical Lead

このチュートリアルでは、HCL Accelerate でビルドデータとデプロイデータをアップロードするための Jenkins パイプラインジョブを作成する方法を紹介します。これは、Jira と GitHub を使った HCL Accelerate VSM シリーズの一部ですが、単体でも一般的なリファレンスとして使用できます。

要件: Jira と GitHub を使用した HCL Accelerate VSM チュートリアルシリーズの事前完了を前提としていますが、完全に必須ではありません。

1. Jenkins インテグレーションを作成する

「HCL Accelerate を使った Jenkins インテグレーションの作成」のチュートリアルに従ってください。

2. バリューストリームに Jenkins インテグレーションを追加する

Jenkins の統合は、他の統合とは異なる方法でバリューストリームに追加されます。vms.json ファイルを編集する必要はありませんが、ビルドデータとデプロイデータのターゲットを持つために、バリューストリームのパイプライン上に「アプリ」を作成する必要があります。

2.1 「パイプライン」に移動し、「アプリの追加」をクリックします。

2.2 ドロップダウンから「Jenkins」を選択します。

2.3 アプリケーション名を入力します。ワークブックでは「JKE App1」という名前を使用します。

2.4 新しいアプリケーションがパイプライン内の行として表示されるはずです。今のところ必要なのはこれだけで、値のストリームに戻ることができます。

3. ビルド、DEV、QA用の Jenkins ジョブを作成する

3.1 新しい Jenkins Pipeline Jobを作成する

3.2 パイプラインスクリプトの設定

パイプラインを作成したら、パイプラインスクリプトのセクションに移動します。スクリプトを貼り付け、変数値を設定した後、「適用」「保存」をクリックします。

• ここにスクリプトをコピー＆ペーストします。
• 変数を正しい値に設定する
• 適用」をクリックし、「保存」をクリックします。

3.2.1 スクリプトのコピーと貼り付け

node {
// URL to Github repository https://github.com/<owner>/<repo>
def GITHUB_REPO_URL="https://github.com/User1098429748/jke-app-1"
// Get ENV ID values for DEV and QA from HCL Accelerate Value Stream "Download attributes from API" json file
def VSM_ENV_ID_DEV="09bd6385-6b46-4fd1-a0b2-56cb0f4ecaf9"
def VSM_ENV_ID_QA="cf601828-3001-433c-bedd-f4574c5cc5f0"
// VSM_APP_NAME must match your HCL Accelerate pipeline application name
def VSM_APP_NAME="JKE App1"
// Time to wait before next stage (seconds)
def SLEEP_TIME=5

// Do not change below this line.
def GIT_COMMIT

stage ('cloning the repository'){
currentBuild.displayName = "2.1.1.${BUILD_NUMBER}"
majorVersion="${BUILD_NUMBER}"
def scm = git branch: 'master', url: "${GITHUB_REPO_URL}"
GIT_COMMIT = sh(returnStdout: true, script: "git rev-parse HEAD").trim()
echo "GIT_COMMIT=${GIT_COMMIT}"
}
sh 'printenv'
stage ("Build") {
echo "Building ${VSM_APP_NAME} (Build:${currentBuild.displayName}, GIT_COMMIT:${GIT_COMMIT}, comit2:${env.GIT_COMMIT}, name:${env.GIT_COMMITTER_NAME})"
step($class: 'UploadBuild',
id: "${currentBuild.displayName}",
versionName:"${currentBuild.displayName}",
name: "${currentBuild.displayName}",
tenantId: "5ade13625558f2c6688d15ce",
requestor: 'admin',
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
revision: "${GIT_COMMIT}",
status: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
debug: false,
fatal: false,
)
}
stage ("Deploy to DEV") {
sleep "${SLEEP_TIME}"
step([$class: 'UploadDeployment',
//"versionExtId" can be used in place of "id" and "versionName"
id: "${currentBuild.displayName}",
versionName: "${currentBuild.displayName}",
name: "${currentBuild.displayName}",
description: 'UploadBuild Example',
tenantId: "5ade13625558f2c6688d15ce",
initiator: "admin",
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
environmentName: 'PROD',
environmentId: "${VSM_ENV_ID_DEV}",
result: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
type: "Jenkins",
debug: false,
fatal: false,
])
}
stage ("Deploy to QA") {
sleep "${SLEEP_TIME}"
step([$class: 'UploadDeployment',
//"versionExtId" can be used in place of "id" and "versionName"
id: "${currentBuild.displayName}",
versionName: "${currentBuild.displayName}",
name: "${currentBuild.displayName}",
description: 'UploadBuild Example',
tenantId: "5ade13625558f2c6688d15ce",
initiator: "admin",
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
environmentName: 'PROD',
environmentId: "${VSM_ENV_ID_QA}",
result: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
type: "Jenkins",
debug: false,
fatal: false,
])
}
}

3.2.2 変数値の編集

編集するスクリプト変数

ENV IDとアプリ名の値は「APIの属性」に記載されています。

パイプライン スクリプトは、HCL Accelerate の値ストリームからいくつかの値を必要とします。これらの値を取得するには、値ストリームのツールアイコンのドロップダウンから「Download attributes for API」をクリックします。このファイルから環境IDとアプリケーション名をコピーして、スクリプト内の変数に貼り付けます。

3.3 「適用」と「保存」をクリックします。

4. ビルド、開発、QAのための Jenkins ジョブを実行する

これで、Jenkins ジョブを実行して、HCL Accelerate 値ストリームのステージの変化を観察する準備が整いました。この時点で、バリューストリームに戻ると、「マージされた」ステージにはまだドットがあるはずです。ビルド、DEVデプロイメント、QAデプロイメントの3つのステップを含む、作成した Jenkins パイプラインジョブを実行します。つまり、ジョブを実行すると、ドットが3つの遷移をするのがわかるはずです。つまり、ジョブを実行すると、ドットが3つの遷移をするのがわかるはずです。

4.1 マージド -> ビルド

4.2 ビルド -> DEV

DEV -> QA

三角形が見えますか？

HCL Accelerate はこのビルドからすべてのコミットデータを取得するので、私たちが作成した PR 以外のコミットが表示されることがあります。これらは三角形で表示されます。これは驚くべきことかもしれませんが、私たちが気づかなかったコミットがビルドに含まれているかもしれないということは、完全に理にかなっています。HCL Accelerate は、私たちのバリューストリームの真の状態を表示しています。

説明

スクリプトをコピー＆ペーストして、ジョブを実行して、効果を観察しただけなら、「OK、結果は見たけど、これはどうやって動いているんだろう？」ということになるかもしれません。もちろん、それに答えるためには Jenkins のパイプラインスクリプトを勉強しなければなりません。スクリプトの2つの最も重要な部分は、以下に説明する'UploadBuild'と'UploadDeployment'のステップです。

• UploadBuild ステップ UploadBuild クラスは、ビルドデータを HCL Accelerate にアップロードするために使用されます。revisionパラメータは、GitHub データ（この場合はGIT_COMMIT）を介してビルドを作業項目にリンクするために重要です。versionName は、デプロイメントへのフォワードをリンクするために重要です。appNameは、HCL Accelerate パイプラインのアプリケーション名に対応します。

step($class: 'UploadBuild',
id: "${currentBuild.displayName}",
versionName:"${currentBuild.displayName}",
name: "${currentBuild.displayName}",
tenantId: "5ade13625558f2c6688d15ce",
requestor: 'admin',
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
revision: "${GIT_COMMIT}",
status: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
debug: false,
fatal: false,
)

• UploadDeployment ステップ UploadDeployment クラスは、配置データを HCL Accelerate にアップロードするために使用されます。versionName パラメータは、ビルドデータにリンクするために重要です。appName は HCL Accelerate パイプラインのアプリケーション名に対応し、environmentName と environmentId は配置環境を識別するために使用されます。

step([$class: 'UploadDeployment',
//"versionExtId" can be used in place of "id" and "versionName"
id: "${currentBuild.displayName}",
versionName: "${currentBuild.displayName}",
name: "${currentBuild.displayName}",
description: 'UploadBuild Example',
tenantId: "5ade13625558f2c6688d15ce",
initiator: "admin",
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
environmentName: 'PROD',
environmentId: "${VSM_ENV_ID_DEV}",
result: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
type: "Jenkins",
debug: false,
fatal: false,
])

2020/9/14 - 読み終える時間: 5 分

作業とボトルネックの可視化を実現する HCL Accelerate は、AppScan と組み合わせることもでき、DevOps の可視化と効率化を実現できます。そのことについての解説記事 Integrating HCL AppScan on Cloud (ASoC) with HCL Accelerate の翻訳版です。

HCL AppScan on Cloud (ASoC) とHCL Accelerate の統合

2020年9月12日

著者: Daniel Trowbridge / Technical Lead

ポーカーをプレイしたことがある人なら、カードの組み合わせが重要なことを知っているはずです。ソフトウェアに関しては、適切な製品を組み合わせることで、勝利を手にすることができます。この記事では、HCL Accelerate チームは、HCL AppScan および AppScan on Cloud (ASoC) との統合に注目してみていきたいと思います。

HCL Accelerate は、複数のチームやワークフローにまたがる可視性とガバナンスを提供する、柔軟で強力なリリースおよびバリューストリーム管理ツールです。HCL Accelerate は、1日2回の監督者から現場の DevOps に欠かせないツールです。HCL AppScan は、HCL Accelerate と驚くほど相性が良いのですが、どちらも次世代のソフトウェア開発体験という HCL のビジョンによって推進されています。AppScanは、静的および動的なセキュリティ・スキャンを提供し、オンプレミスとクラウドで提供しています。これらのスキャンは、品質、セキュリティ、およびコンプライアンスにとって非常に重要です。HCL Accelerate は、チーム、製品、ツールチェーン全体で AppScan のデータをインジェストし、可視性とガバナンスを確保することで、作業を継続し、管理を安心して行えるようにします。

さあ、始めましょう。

このチュートリアルでは、AppScanのクラウド提供（AppScan on CloudまたはASoC）を使用します。ASoC アカウントとプロジェクトをまだお持ちでない場合は、無料トライアルを利用して今すぐ設定することができます。また、HCL Accelerate をまだお持ちでない場合は、こちらから Community Edition をダウンロードできます。プロジェクトとスキャンの例を以下に示します。

また、ASoCキーIDとキーシークレットを生成する必要があります。

スキャン結果を生成する準備ができたら、スキャナを実行し、scanIDをコピーして貼り付けます。これは、以下のHCL Accelerateセクションに示されているcurlコマンドに後で必要になります。

1. HCL AccelerateでASoCインテグレーションを作成します。

1.1 プラグインを探す

HCL Accelerate で、Settings（設定）＞Integrations（統合）＞Plugins（プラグイン）に移動し、"Plugin for ASoC"で"Add Integration（統合の追加）"をクリックします。

1.2 統合を構成する

統合の追加」フォームに必要事項を入力します。HCl Accelerate と ASoC への認証を設定します。

• 統合名：ASoC_Example_Name_1
• ユーザー・アクセス・キー。HCL Accelerateのユーザー・アクセス・キーをコピーして貼り付けます。(“Settings” > “My profile” で ASoC_Example_Name_1という名前を付けることができます)
• ASoC ベース URL: https://cloud.appscan.com
• ASoC API Key ID。クラウドAPIの認証に使用するIDです。
• ASoC API Key Secret: クラウドAPIの認証に使用される実際のキー。

1.3 統合の検査

統合が作成されたことを確認します。ドロップダウンの詳細を展開して、エンドポイントのURLを表示します。統合エンドポイントのURLにPOSTコマンドでASoCデータをHCL Accelerateに送信します。

2. ASoCスキャン結果をHCL Accelerateに送信する

ASoCスキャン結果をHCL Accelerateに送信するには、スキャンIDを含むJSONオブジェクトをターゲットのHCL Accelerate統合のpluginEndpoint URLにPOSTするだけです。

データ構造の例

{
"scanId": "<ASoC scan ID>",
}

Curl コマンドの例 curl -H “Content-Type: application/json” -k -X POST https://<accelerate server>/reporting-consumer/pluginEndpoint/<integration ID>/asocScan -d “{\”scanId\”:\”<scan ID>\”}”

3. データを見る

HCL Accelerateでダッシュボードを設定することで、データを見ることができます。インサイト」に移動し、「ダッシュボードの作成」をクリックします。

チャートの追加」をクリックし、適切なメトリクスを選択してチャートを作成します。ASoCデータのデフォルトのメトリックは、「Risk」の下の「Application Vulnerabilities」です（ASoCプラグインのバージョン1.0.16以前の場合、デフォルトのメトリックは「Quality」の下の「ASoC Tests」です）。

フィルタリング・オプション

複数のフィルターや時間の選択など、データの異なる選択で複数のチャートタイプを作成することができます。

各チャートは、以下のように詳細表を表示することもできます。

2020/9/10 - 読み終える時間: 3 分

Unica- A Cloud-Native Marketing Platform

HCL Unica: クラウドネイティブマーケティングプラットフォーム

2020年9月9日

著者: Siddharth Deshpande / Architect for Unica Cloud-Native Solution

なぜ Unica はクラウドネイティブといえるのか？

私たちは、クラウドが牽引する情報技術革命の真っ只中にいます。高速な起動、標準化されたアプリケーションパッケージング、アイソレーションモデルを備えたコンテナの登場は、効率性と俊敏性の向上にさらに貢献しています。

ハードウェアリソースコストの削減、使いやすさ、移植性、スケーラビリティー、デプロイのモジュール性といった Docker の利点に加えて、Kubernetes は、アプリケーションのデプロイ（ロールアウトとロールバック）、ワークロードのスケーリング、高可用性を自動化するためのコンテナオーケストレーション機能を提供しています。Helm チャートでは、Kubernetes パッケージを活用して、Kubernetes 上にデプロイされたアプリケーションのインストールと管理を合理化しています。

1. リリースペースの高速化 Unica Docker イメージは、リリースおよび/または修正パックごとにロールアウトされます。市場投入までの時間は、最も革新的な組織と遅れている競合他社との間の重要な差別化要因となっています。このデプロイメントアプローチにより、Unica は顧客により多くの価値を構築し、出荷できます。この展開アプローチにより、顧客は新しいリリースを容易に利用できるようになりました。

2. より良い CX HCL Unica は、新機能を搭載した Docker イメージをより迅速に出荷し、継続的にイテレーションを続けます。Unica 製品の API の広範なセットは、企業のデータストアとの統合を可能にします。全体的に、クラウドネイティブ・アプリケーションは、顧客体験の向上を可能にします。

3. アプリケーション管理の容易さ クラウドネイティブには、インフラ管理を楽にするための多くのオプションも用意されています。ヘルムチャート、アプリケーション管理、監視、デプロイが簡単に、自動化され、構成が駆動するようになります。

4. コンテナ化によるコスト削減 コンテナは、アプリケーションをサポートするインフラストラクチャーとは独立して、アプリケーションの管理と安全性の確保を容易にします。業界は現在、これらのコンテナをスケールで管理するために、Kubernetes を中心に集約されつつあります。Kubernetes と並んで、強力なクラウドネイティブツールのホストが存在し、インフラストラクチャーとツールの標準化が進んでいます。これはオープンソースの技術と相まって、コストの削減につながっています。価格設定の柔軟性のあるモデルは、すべてクラウドネイティブなデプロイメントアプローチによって可能になります。

5. 信頼性の高いシステムの構築 クラウド上の Kubernetes のような最新のクラウドネイティブアプローチを利用することで、レジリエンスと自己回復を内蔵したフォールトトレラントなアプリケーションをより簡単に構築できます。この設計により、障害が発生した場合でも、インシデントの影響を簡単に切り分けられるため、アプリケーション全体をダウンさせることはありません。サーバーやモノリシック・アプリケーションの代わりに、クラウドネイティブのマイクロサービスを利用することで、より高いアップタイムを実現し、ユーザー・エクスペリエンスをさらに向上させることができます。

6. どこでもデプロイ Unica のソリューションは、どのようなクラウド上にも展開可能です。Unica は、EKS、GKE、AKS などのマネージド Kubernetes クラスター上に展開できます。

Unica クラウドネイティブソリューションのデプロイ方法 まずはHCLから舵取り図を入手し、configMap YAMLファイルを設定します。Unicaの各製品には、アライアンスの設定ファイルが用意されています。

始める前に

• HCL Software License Management Portal から Unica docker Images をダウンロードします。
• Dockerイメージをインポートし、タグを付けて Docker レジストリにプッシュします。
• リポジトリセクションの values.yaml - 製品イメージのURL、タグセクションのタグ番号を編集します。
• 各製品のhelm chart configMap ファイル内のDatabaseとAppServerの詳細を更新します。
• ヘルムチャートの pvc.yaml を編集して、Persistent Volume Claim の詳細を更新します。
• アップグレードについては、「オンプレミスアプリケーションを docker にアップグレードする」を参照してください。

手順

Unica クラウドネイティブソリューションをデプロイする際の手順をいくつか紹介します。

• kubectl apply -f ./unica/extra-configs/local-pv.yaml
• helm install ?name nginx stable/nginx-ingress -f ./unica/extra-configs/nginx-conf.yaml
• helm install hcl unica -f ./unica/values-local.yaml unica ?set service.hostname=hostname ?set service.applicationDomain='com' ?set ingress.enabled=true

Unica ヘルムリリース

デプロイされたヘルムリリースの確認

Unica Helmのインストールを確認するには、「チャートの確認」のリンクをクリックしてください。

新しい Unica クラウドネイティブプラットフォームで便利になった利点は、デプロイが容易になり、数分でデプロイして数時間でアップグレードできます。また、Docker、Kubernetes、Helm の技術を使ったオンプレム、クラウドにも対応しています。それについて詳しく知りたい方は、#UNICAisDockerized を読んでみてください

2020/9/5 - 読み終える時間: ~1 分

Day 2 DevOps : Getting more out of your software delivery pipeline の翻訳版です。

Day 2: DevOps: ソフトウェア・デリバリー・パイプラインをもっと使いこなす

2020年9月4日

著者: Nick Mathison / Value Stream Manager

多くのチームの DevOps の起源は、2つの方法のいずれかで始まった。最初のシナリオでは、製品のリードやマネージャーがカンファレンスから戻ってきて、突然「 DevOps が必要だ！」と主張し、「すべてを自動化する」というマントラを唱える。もう1つのシナリオでは、不正な開発者が手動インストールの繰り返しに飽きてしまい、自分の悩みを自動化することにした場合です。どのようなアプローチであっても、数ヶ月後には、これらの開発チームは、複数のツール、チーム、依存関係にまたがる行き当たりばったりの自動化の上で日々運用されています。さらに、ログイン認証情報、アプリケーション、実行中のプロセス、成功したか失敗したかのログを解釈する能力が必要なので、デプロイメントタスクを実行する方法を理解しているのは、チームの一部の人だけです。

これらのツールを毎日使用していない限り、単純な質問にすぐに答えることは不可能です。"本番ではどのバージョンが使われているのか？今日のCI/CDの世界では、開発者はパイプラインに目を向けて、一貫性のない自動化された世界に構造を提供し、これらの単純な質問に答えるのを助けようとしています。しかし、パイプラインを深く掘り下げていくと、その答えは全体像のほんの一部に過ぎません。

最も単純な形では、パイプラインはアプリケーション・ディストリビューションと、意図されたホストである環境の交差点です。提示されたインベントリは、新しいバージョンがビルドされ、デプロイされると、左から右へ、パイプラインを通って、環境から環境へと移動します。しかし、毎日の複数の CI ビルドのおかげで、何時間も離れて行われるビルドの違いを見分けることができなくなりました。自動デプロイに暗号化されたバージョンを乗算すると、今では無意味なバージョンがあちこちに存在しています。したがって、以下のようなより深い質問に答えるのに役立つ、より高度なパイプラインが必要になります。"本番環境ではどのような変更が行われているのか」、「変更されたバージョンはどのように本番環境にデプロイされたのか」など、より深い質問に答えるのに役立つ、より高度なパイプラインが必要です。このような知識があれば、問題のある変更が発生したときに素早くピンポイントで特定し、問題のあるバージョンをデプロイ前に停止させることができます。幸いなことに、HCL Accelerate は、パイプライン全体にわたってより深い可視性と厳格なガバナンスを提供するように構築されています。その方法をお見せしましょう

パイプラインの構築

始めるために、コードから一歩引いて、候補となるアプリケーションとその関係者を特定します。CI サーバーから始まり、最終的に顧客の手に渡るまで、ビルドされた成果物の移動を支援する個人を含めたいと考えています。これらの利害関係者には、開発、運用、テスト、パフォーマンスエンジニア、リリースマネージャ、テクニカルサポートなどが含まれます。これらのリソースを特定したら、以下の2つのパートのアジェンダで約2時間のセッションを行うために、これらのリソースを集めてください。

まず、以下の 3 つのリストを作成し、既知のすべてのパイプラインコンポーネントを特定します。

• 開発、テスト、本番、リリースの観点から、アプリケーションのデプロイをサポートするために、どのような環境がアップグレードされ、保守されているか？(注: これらの環境は、必ずしもアプリケーションをホストしているとは限りません。パフォーマンスや統合のためなど、適切なテストを行うために、セカンダリインスタンスが必要になることがよくあります。)
• これらの環境を更新するために、どのような手動または自動化されたプロセスを使用していますか？
• リリース前に、どのようなリリース要件、マイルストーン、サインオフをすべてのバージョンで取得しなければならないか？

次に、この情報を手にして、典型的なバリュー・ストリーム・マッピングの手法を使用して、アプリケーションのパイプラインのフローチャートを構築してください。ホワイトボードを使うのが最も一般的ですが、オンラインのエンティティ関係図ツールでも問題ありません。このモデルでは、環境（#1）、プロセス（#2）、および要件（#3）は、それぞれバブル、入力、および出力で表されます。すべての利害関係者が各コンポーネントの配置に満足したら、HCL Accelerateのパイプラインにきれいにトランスポーズするための明確なアクションプランを持って会議から退散することができます。

余談ですが、様々なエンティティのパターンやグループ化は、パイプラインマッピングプロセスの副作用として認識されていた可能性が高いです。例えば、順次デプロイするのではなく、複数の環境を同時にデプロイすることができます。あるいは、環境ごとに1つの自動化スクリプトを使用するのではなく、1つのスクリプトを複数の環境で再利用することができます。あるいは、リリース要件を左にシフトして、無駄なテストを防ぐことはできませんか？これらのアイデアは、CI/CDパイプラインを最適化し、技術的な負債を減らすために重要ですが、それぞれのリストが変わるたびにパイプラインは進化し続けます。いずれにしても、シンプルなパイプラインを採用することは、開発のエンパワーメントを向上させるための大きな一歩であり、パイプラインには柔軟性を期待すべきです。

提供されるパイプライン戦略は、実装を容易にするために焦点が絞られています。完了すると、チームは「すべてを自動化する」という DevOps のマントラをようやくコントロールできるようになったとマネージャーに警告することができ、自信を持って「どのバージョンが本番であるか」という質問に答えることができるようになる。しかし、それはより大きな DevOps の旅の1日目に過ぎない。どのチーム・メンバーでもパイプラインの中のより深い問題を正確かつ迅速に特定できるようになる2日目の課題を解決するために、パイプラインはどのように役立つのでしょうか？

幸いなことに、HCL Accelerate は、先に述べた挑戦的な Day 2 の質問に答える準備ができています。これまでCI/CDツールについてのみ説明してきましたが、チームは、無料のソースコントロールと課題追跡プラグインを利用することで、バージョン、計画された作業、および計画されていない作業の間で点を結びつけることができます。この関係性により、チームは「本番ではどのような変更があるのか」という質問に明確に答えることができます。さらに、当社のパイプラインのデプロイ計画は、監査とトレーサビリティを通じて、「変更バージョンはどのように本番環境にデプロイされたのか」を説明することができます。そして、より厳しい、あるいはより緩い制御が必要な場合には、当社の堅牢なゲーティングシステムを利用して、パイプラインを流れるバージョンを管理します。Day 2の課題は、HCL Accelerat eの無料の Community Edition で反復的に解決することができます。今すぐダウンロードするにはここをクリックしてください

2020/9/4 - 読み終える時間: 4 分

Understanding BigFix: The Premier Endpoint Patch Solution の翻訳版です。

BigFix を理解する：Premier Endpoint Patch Solution

2020年9月3日

著者: Casey Cannady / Enterprise Architect 共著: Cyril Englert / Solution Architect

BigFix は、あらゆる規模や業界の何千もの企業に、エンタープライズ・エンドポイント管理ツールとして選ばれています。実際、BigFix は世界中で何百万ものエンドポイントを管理しており、IT およびセキュリティ運用チームに実質的で具体的な価値を提供しています。BigFix は、効果的なエンドポイントの衛生管理に不可欠な、継続的なパッチ適用と設定のドリフトの排除に優れています。これらの対策が適切に実装され、監視されていれば、侵害の可能性は飛躍的に低下します。なぜ CIO や CISO がエンドポイント環境のセキュリティを BigFix に依存しているのかを理解することは、BigFix が 98%以上の初回合格率を達成している理由を理解する上で非常に重要です。

主な機能 BigFix は、以下のような効果的なパッチ適用をサポートしています。

• Windows、Linux、UNIX、macOS など 90 種類以上の OS と、サポートが終了している特定の OS のサポート。BigFix により、複数のツールを削減でき、大幅なコスト削減を実現します。
• Windows および macOS 用のサードパーティ製アプリケーション。
• オフラインやローミング中のワークステーション（在宅勤務の従業員が使用するワークステーションを含む）。
• Amazon Web Services、Microsoft Azure、VMware、およびGoogle Cloud Platform（GCP）クラウドで実行されているリソース。

BigFix のパッチ適用は、以下のプラットフォームの機能と能力に依存しています。

• 低い CPU 要件 - 通常は2%未満。
• ネットワーク・スロットリング - 高レイテンシー、低容量のネットワーク回路への影響を管理できます。
• プリキャッシング - 指定されたメンテナンスウィンドウでパッチ時間を短縮します。
• クラウドエンドポイントの可視性 - Azure、Google、Amazonで実行されています。
• 最大25万のエンドポイント - 1台のルートBigFix Enterprise Serverから。
• 分散型インテリジェンス - 意思決定と計算をインフラストラクチャの上位レベルではなく、エンドポイントに移動します。インテリジェント・エージェントは、ネットワーク帯域幅の消費を抑え、より小さなサーバを必要とする一方で、パッチの展開、構成、および修復を高速化します。
• 柔軟な配布ポイント - 効果的でありながら低コストのインフラストラクチャを構築する上で、多くの柔軟性を提供します。専用リレーの他にも、多くの組織にとって有用な低コストのオプションがいくつかあります。BigFixバーチャルリレーは、リソースとメンテナンス要件が少なく、導入が簡単です。 非専用リレーは、既存のシステムに BigFix サービスを共同で配置することで、企業全体で BigFix 機能を利用することができます。最後に、BigFix ピアネスト機能により、1つの BigFix エージェントが小規模なオフィスやリモートサイトでサブネットリピーターとして機能することができます。
• 粒度の高い管理と制御 - BigFix では、パッチがいつ展開され、いつエンドポイントが再起動されるかを粒度の高い制御で制御することができます。多くの組織では、中央のIT部門がパッチの開発、テスト、パッチコンテンツの配布を可能にする分散型パッチ展開プロセスを実装しており、個々のユーザーグループや部門が、指定された時間枠内で都合の良いときにパッチを展開・インストールするタイミングを決定できるようにしています。

BigFix Patch には特定の機能があり、その結果、初回のパッチ成功率が非常に高く、多くの場合、98%以上となっています。ファーストパスの成功率が高いということは、パッチサイクルが短く、修正作業が少なく、安全なエンドポイントのランドスケープが得られることを意味します。

その他のパッチ固有の機能と機能は以下のとおりです。

自動化されたコンテンツ配信

BigFix チームは、オペレーティング・システムやサードパーティ・アプリケーション・ベンダーが提供するコンテンツを使用して Fixlet を作成し、脆弱性の窓を減らします。Fixlets と呼ばれるBigFixコンテンツは、当社のクラウド配信サーバで利用可能になります。BigFix Enterprise Server (BES) は、毎日1回（設定されている場合はそれ以上の頻度で）新しいコンテンツをチェックします。新しいサイトコンテンツは自動的にダウンロードされるため、BigFix はどの Fixlet が関連性のあるものかを判断し、関連性のないコンテンツのための無駄な帯域幅を排除します。

BigFix は、ベンダーからリリースされてから2営業日以内に重要なパッチを配信しますが、通常はもっと早く配信されます。最も重要なパッチが最初に配信されます。サポートされているすべてのトップティアのオペレーティングシステムに対して、コンテンツの自動開発とBigFix環境への配信が行われるため、より迅速な通知と脆弱性へのパッチ適用が可能となり、脆弱性が発生する可能性の窓を減らすことができます。

自動パッチ適用

自動パッチ適用は、パッチ管理者とオペレータが必要とする労力を軽減します。パッチポリシーとスケジュールを定義することで、オペレータはパッチ適用を自動化することができます。例えば、Windows Server のパッチポリシーを設定して、重要なパッチのみを展開し、Windows サーバを対象としたスケジュールと重ね合わせることができます。そのため、BESサーバーが関連するコンテンツをダウンロードするとすぐに、パッチが自動的に展開されます。ポリシーの更新は、1ヶ月ごとに1分以内で完了します。

本番環境の BigFix では、管理者はアルファ、ベータ、本番1のような複数のスケジュールを使用して、計画的なテスト、検証、パッチ展開を行います。これらの自動スケジュールが数日離れている場合、問題のあるパッチが展開されるのを防ぐためにITオペレーションが介入することができます。そうでなければ、パッチは体系的に自動的に展開され、時間と労力を節約することができます。これは、リソースに制約がある中小規模の組織にとって特に重要です。

柔軟なベースライン

BigFix ユーザーは、複数のパッチや設定項目をベースラインにまとめて配信することで、時間と労力を節約できます。また、ベースラインをポリシーにすることもできます。エンドポイントがベースラインの仕様から外れると、BigFix は自動的に内容を再適用します。ベースラインは、より効率的で一貫性のあるセキュリティとパッチ適用の姿勢を実現します。

パッチインストールの検証

市場に出回っている多くのソリューションとは異なり、BigFix は、エンドポイントがパッチを受け取る資格を与えたのと同じ基準を使用して、パッチが正常にインストールされているかどうかを検証します。この信頼できる方法により、パッチが適切にインストールされることが保証されます。既存のパッチソリューションでは、パッチが正常にインストールされていないのに、パッチが正常にインストールされたと誤って報告されていたため、数え切れないほどの組織がBigFixを導入しています。この問題は、ITおよびセキュリティ組織に誤ったセキュリティの感覚を与え、攻撃の脆弱性を増大させています。組織は、エンドポイント管理ソリューションが正確なパッチ状況を正しく報告していることに自信を持つ必要があります。BigFix は、その自信をユーザーに提供します。

ソフトウェアへの依存はありません

BigFix は、問題があり信頼性が低いことが知られているWindows 用の WSUS、WMI、または Active Directory のパッチ適用に依存しません。RedHat Linuxでは、BigFix は Satellite リポジトリまたはネイティブの BigFix コンテンツ・ライブラリのいずれかを使用できる柔軟性を持っています。さらに、BigFix のパッケージング・ウィザードを使用することで、コンテンツをパッケージングするための追加ツールのコストや、障害や問題点の追加を排除することができます。

コンテンツの完全性の確保

チェックサムを使用することで、BigFixインフラストラクチャコンポーネント間でのファイルの安全な転送が保証されます。具体的には、BigFix ではSH1 や SH256 などの SHA (Secure Hashing Algorithms) を採用しています。クラウド配信サーバーからコンテンツがダウンロードされると、BigFix は各ファイルのチェックサムを計算し、ソフトウェアベンダーが公開しているオリジナルのチェックサムと比較します。両方のチェックサムが一致する場合、BigFixはダウンロードされたコンテンツが安全であると判断します。チェックサムが一致しない場合は、データの損失や改ざんを意味し、ファイルが破損している可能性があります。

デプロイメントのロールバック

BigFix を使えば、Windows パッチのロールバックや削除は簡単です。BigFix ロールバックウィザードで Microsoft Knowledge Base (KB) 番号を入力すると、関連する Fixlet が自動的に作成されます。他のオペレーティングシステムやアプリケーションでは、フィックスレット内でベンダが提供するアンインストールタスクを使用して、パッチやソフトウェアデプロイメントをアンインストールするためのフィックスレットを簡単に作成することができます。

インテリジェントな上位互換エンジン

BigFix の代替エンジンは、パッチ管理を簡素化するインテリジェンスを提供します。BigFix は、どのパッチが他のパッチに取って代わられているかを知ることができるため、管理者とパッチ適用ソリューション側の重複や不必要な作業を減らすことができます。BigFix の代替エンジンは、関連するエンドポイントのターゲティングとパッチ適用の効果を向上させます。対照的に、パッチツールの中には、最新のパッチを適用する前に先行するパッチを適用する必要があるものがありますが、これは不必要に労力とパッチの複雑さを増大させます。

BigFix は並外れたビジネス価値を提供

上記の理由により、BigFix は強力で効果的なパッチソリューションであり、セキュリティ侵害の可能性を低減しながら、IT コストと複雑さを軽減することができます。HCL の IT 組織は、すでに大幅なコスト削減を実現しています。BigFix は、いわゆる「無料」のソリューションと競合する場合でも、費用対効果の高いツールです。HCL の BigFix チームは、ビジネス価値評価 (BVA) プロセスを使用してBigFixのビジネスケースを構築するための支援を日常的に行ってきました。この無料の共同作業プロセスは、通常、BigFix が組織に与える影響を評価するのにわずかな時間しか必要としません。

定量化可能なメリットには以下のようなものがあります。

• ソフトウェアの使用量の削減
• ITインフラの複雑さとコストを削減
• エンドポイント情報の品質向上
• コンプライアンス管理のコスト削減
• パッチ修復作業の削減
• ソフトウェアおよびオペレーティング・システムの簡易導入
• セキュリティリスクの回避
• データ漏洩コストの削減

BigFix を使用してパッチ管理プロセスを最適化し、コストを削減し、IT の複雑さを軽減し、セキュリティ姿勢を改善した他の人たちの仲間入りをしましょう。詳細は、BigFix.com をご覧ください。

2020/9/4 - 読み終える時間: 2 分

Installing Z and I Emulator for Windows (ZIEWin) の翻訳版です。

HCL Z and I Emulator for Windows のインストール (ZIEWin)

2020年9月3日

著者: Mahua Chanda / Developer, Lab Services, HCL ZIE

はじめに

Z and I Emulator for Windows は、3270、5250、および VT エミュレーションを提供し、z/OSR、z/VMR、eServer? i5、iSeriesR、System i5R、zSeries、および ASCII システムに接続します。Z and I Emulator for Windows は、すべてのインストール手順に Microsoft Windows Installer テクノロジーを使用しています。

Z and I Emulator for Windows インストールイメージが最初に実行されると、ターゲットシステムを検査し、必要に応じて、適切なバージョンの Windows Installer サービスを自動的にインストールします。Setup.exe は、Windows Installer サービス (msiexec.exe) を呼び出してインストールダイアログを起動するブートストラップローダーです。

Z and I Emulator for Windowsをインストールする際には、以下の点に注意してください。

• Windows Installer のインストールにより、システムの再起動が必要になる場合があります。Windows Installer のインストールによっては、システムの再起動が発生する場合があります。再起動が必要な場合は、その後の起動時にすぐに Windows Installer に戻り、Z and I Emulator for Windows のインストールを続行します。
• Windows Installer のインストールが正常に終了した後、Z and I Emulator for Windows のインストールに失敗したり、ユーザーがキャンセルした場合、Windows Installer は、部分的にインストールされた Z and I Emulator for Windows のファイルをすべてロールバックし、システムを元の状態に戻します。
• これらのインストールを実行するには、管理者グループのメンバーである必要があります。
• インストールを開始する前に、他のアプリケーションがすべて停止していることを確認してください。Z and I Emulator for Windows を再インストールする場合、または Z and I Emulator for Windows をアップグレードする場合は、セットアップを開始する前に Z and I Emulator for Windows が起動していないことを確認してください。

詳しくは、「Z and I Emulator for Windows のインストール (ZIEWin Installation’)」の動画をご覧ください :

お問い合わせ

HCL ZIE での Web アプリケーションの整理、自動化機能、ラボサービスの提供に関する詳細については、以下までお問い合わせください。

ZIO@hcl.com

マフアシャンダ

開発者、ラボサービス、HCL ZIE

2020/9/4 - 読み終える時間: 3 分

Configuring session on Z and I Emulator for Windows (ZIEWin) の翻訳版です。

Z and I Emulator for Windows でのセッションの設定 (ZIEWin)

2020年9月3日

著者: Mahua Chanda / Developer, Lab Services, HCL ZIE

Z and I Emulator for Windows は、エミュレータの設定情報をワークステーションプロファイル (.WS) に保存します。お使いの Z and I Emulator for Windows の設定によっては、ワークステーションプロファイルのみ、またはワークステーションプロファイルと設定ファイルの両方を持っている場合があります。ワークステーションプロファイルは、後で他の Z and I Emulator for Windows セッションで使用したり、このセッションを再起動したりすることができます。

セッションの設定

新しいセッションを作成するには、以下の手順に従ってください。

1. Windows メニューから、Programs -> HCL Z and I Emulator for Windows -> Start or Configure Sessions をクリックします。
2. Session Manager ダイアログボックスで、New Session をクリックします。

Customize Communication」ウィンドウが表示されます。

1. Type of Host ドロップダウンリストボックスからホストのタイプを選択します。
2. Interface ドロップダウンリストボックスから使用するインタフェースを選択します。
3. Attachment ドロップダウンリストボックスから、使用する添付ファイルの種類を選択します。
4. Session Parameters をクリックして、セッションタイプ（ディスプレイまたはプリンタ）、ホストコードページ、および表示/グラフィックオプションを変更します。

セッションパラメーター - 3270、5250、または ASCII - ホストウィンドウが表示されます（ステップ 3 で選択したホストによって異なります）。

1. OK をクリックします。
2. Link Parameters をクリックします。

各ページに適切な情報を入力し、「次へ」をクリックして続行し、完了したら「完了」をクリックします。

1. Host Definition タブをクリックして、Connection Options を構成します。

   • Auto-reconnect を選択して、中断された接続を再確立します。
   • Connection Timeout 値は、Z and I Emulator for Windows がホストに接続するまでの待ち時間を指定します。
   • Try connecting to last configured host infinitely オプションは、デフォルトで有効になっています。Z and I Emulator for Windows が最後に正しく設定されたサーバー/ホストからの接続要求の確認を自動的に無期限に待機することを望まない場合は、このボックスをオフにしてください。

2. セッションオプションを設定したら、Telnet タブパネルで OK をクリックします。

3. Customize Communication ウィンドウで OK をクリックします。セッションが自動的に表示されます。

詳細については、「ディスプレイとプリンタのセッションを設定する (Configuring Display and Printer Session)」のビデオを参照してください。

お問い合わせ

HCL ZIE での Web アプリケーションの整理、自動化機能、ラボサービスの提供に関する詳細については、以下までお問い合わせください。

ZIO@hcl.com

Mahua Chanda / Developer, Lab Services, HCL ZIE

2020/9/4 - 読み終える時間: 4 分

3270や5250端末を今風のUIを備えたWebアプリに変換する HCL Z and I Emulator の最初の一歩についての記事 Creating simple ZIETrans project の翻訳版です。

簡単な ZIETrans プロジェクトの作成

2020年9月2日

著者: Mahua Chanda / Developer, Lab Services, HCL ZIE

はじめに

HCL Z and I Emulator for Transformation (ZIETrans) を使用すると、IBMR z Systems プラットフォーム上で実行されている 3270 アプリケーションと IBM i OS プラットフォーム上で実行されている HCL の 5250 アプリケーションを、使いやすいグラフィカル・ユーザー・インターフェース (GUI) を持つ Web アプリケーションを作成できるようになります。

ZIETrans アプリケーションでは、モダンな外観に模様替えすることができます。ZIETrans Web アプリケーションは、会社の Web ページまたはポータル・ページと一致するインターフェイスで開発することができ、ユーザーは Web ブラウザからアクセスすることができます。ZIETrans Web アプリケーションは、携帯電話、データ収集端末、PDA（パーソナル・デジタル・アシスタント）などのモバイル機器からホストアプリケーションへのアクセスを提供するために開発することもできます。

ZIETrans アプリケーション開発のすべてのステップは、Eclipse ベースの IBM Rational Software Delivery Platform (Rational SDP) を使用して実行されます。Rational SDP は、ユーザー・インターフェースと統合開発環境 (IDE) を提供し、そこからウィザードを起動してリソースを作成したり、リソースのリストを表示したり、エディタを使用してリソースを変更できます。

Rational SDP を起動すると、1 つのウィンドウに 1 つ以上のパースペクティブが表示されます。パースペクティブとは、ビューとエディタの集合体で、特定のタイプのプロジェクト (この場合は ZIETrans プロジェクト) に属するリソースの作成、編集、表示、実行を可能にします。一度に複数のパースペクティブを開くことができますが、一度に表示して作業できるのは1つだけです。

Rational SDP ウィンドウの右端には、新しいパースペクティブを開いたり、すでに開いているパースペクティブ間を移動したりするためのショートカットバーがあります。アクティブなパースペクティブの名前がウィンドウのタイトルに表示され、ツールバーにはアクティブなパースペクティブに関連付けられたアイコンが表示されます。

ZIETrans ツールキットとパースペクティブの起動

ZIETrans Toolkit は、2 つの方法で起動できます。

• Windows のスタートメニューから Rational SDP を起動してから、ZIETrans パースペクティブを開く。
• Windows スタートメニューから ZIETrans Toolkit を起動して Rational SDP を起動し、ZIETrans パースペクティブを自動的に開く。

ZIETrans パースペクティブには、2 つの主な領域があります。

• ZIETrans Projects ビューは、ZIETrans プロジェクトを拡張可能なツリー表示で一覧表示します。
• エディタウィンドウは、最初に ZIETrans のウェルカムページを含んでいます。このウィンドウでは、ZIETrans リソースを操作するためのエディタも使用します。エディタの下と右側には、エディタでリソースを編集するためのビューがあります。
• ナビゲータービューは、Rational SDP のデフォルトビューで、プロジェクトの .ear ファイルやその他のローカルアーティファクトなど、ワークベンチ内のリソースを階層的に表示します。また、ZIETrans Projects ビューには表示されない、クローズされた (またはアーカイブされた) ZIETrans プロジェクトも表示されます。これらのクローズされたプロジェクトは、右マウスをクリックしてプロジェクトを開くを選択することで、再度開くことができます。

ZIETrans ツールキットを初めて起動すると、ZIETrans のヒントが表示されます。チップウィンドウのチェックボックスを使用して、表示するチップを制御することができます。

Rational SDP を起動したときに ZIETrans パースペクティブが表示されない場合は、Window > Open Perspective > Other をクリックして、使用可能なパースペクティブのリストから Z and I Emulator for Transformation を選択することで、ZIETrans パースペクティブを開くことができます。ZIETrans パースペクティブの一部のウィンドウを閉じたり、配置を変更したりすると、終了時に配置が保存されます。ZIETrans Toolkit に戻ると、最後に正常に保存された終了時の設定に復元されます。元の ZIETrans ウィンドウを復元するには、Window > Reset Perspective をクリックします。

ZIETrans プロジェクトの作成

ZIETransプロジェクトの作成には複数の方法があります（動画のリンクをたどってください

ウェルカムページから開始します。ウェルカムページが表示されていない場合は、メインツールバーの Open ZIETrans Welcome Page icon アイコン をクリックしてください。

1. Create your first project セクションを展開します。
2. Launch the Create a Project wizard リンクをクリックします。
3. ZIETransプロジェクトページで、プロジェクト名を入力します。
   • 作成するプロジェクトの名前を入力します。
   • プロジェクトの説明を入力します。これはオプションです。ここにメモを取っておくこともできますし、お好きなように使用することもできます。
   • Use default location チェックボックスを選択したままにします。
   • Deployment セクションで、プロジェクトがWebアプリケーション用であるかどうかを選択します。
   • Next をクリックします。 *

注: Web 配置オプションが無効になっている場合、サーバー ランタイムが定義されていないことを意味します。サーバーランタイムを定義するには、Window > Preferences > Server > Installed Runtimes に移動し、少なくとも 1 つのランタイム定義を追加します。

• Web
  • アプリケーションに使用するターゲットサーバーを選択します。
  • エンタープライズアプリケーション(.earファイル)プロジェクトに使用する名前を指定するか、デフォルトの名前を使用します。
  • Optimize options for mobile devices チェックボックスをクリアしたままにします。
  • Add administration console support チェックボックスを選択したままにします。

4. Connection Settings ページで、以下の設定を行います。

   • ホストアプリケーションにアクセスするために使用する Telnet サーバーの名前を入力します。ホスト名、ドメイン名（myhost.mycompany.comなど）、エイリアス、またはIPアドレスを入力します。
   • ホストアプリケーションが 3270 プロトコルを使用する場合は、アプリケーションが必要とする機能に応じて、3270 または 3270E 接続タイプを選択します。例えば、印刷をサポートする場合は、3270E 接続タイプが必要です。ホストアプリケーションが 5250 プロトコルを使用している場合、5250 Telnet サーバーを介してアクセスする場合は、5250 接続タイプを選択してください。
   • ポート、コードページ、画面サイズを選択します。
   • 次へ]をクリックします。

5. プロジェクトのテーマページで、アプリケーションの全体的な外観と動作を選択します。アプリケーションをエミュレータのように表示して動作させるか、最新のアプリケーションのように表示するか、またはその中間のカスタム設定にするかを選択することができます。次へ]をクリックします。

6. デフォルトテンプレートページには、ZIETransで提供されているすべてのテンプレートが表示されます。プロジェクトの出発点として使用するテンプレートを選択し、終了をクリックします。

7. ZIETrans がプロジェクトを作成すると、プログレスバーが表示されます。

詳細については、「HCL Z and I Emulator for Transformation で簡単なプロジェクトを作成する (Creating a Simple project on ZIETrans)」のビデオをご覧ください。

お問い合わせ HCL ZIE での Web アプリケーションの整理、自動化機能、ラボサービスの提供に関する詳細については、以下までお問い合わせください。

ZIO@hcl.com

Mahua Chanda / Developer, Lab Services, HCL ZIE