HCL Launch における “Process as Code”

2020/10/29 - 読み終える時間: 5 分

Processes as Code in HCL Launch の翻訳版です。

HCL Launch における “Process as Code”

2020年10月28日

著者: Hayden Schmackpfeffer / Product Manager

導入とユーティリティー

HCL Launch version 7.1.1.0 で追加されたエキサイティングな新機能の1つは、Web UI の外でアプリケーションやコンポーネントのプロセスを設定できることです。HCL Software の “Process as Code” フォーマットにより、開発チームはプロセスを定義し、簡単に変更可能なフォーマットで保存することができます。

HCL Launch サーバーには、いくつかのコマンドで構成されたユーティリティである Process as Code Compiler がバンドルされています。その主な目的は、Launch サーバーと対話し、PAC フォーマットと Launch サーバーによって理解される JSON フォーマットの間で変換することです。

最も便利なコマンドは upload と download です。これらのコマンドには、download-component-process、download-application-process、upload-component-process、upload-application-process の 4つがあります。

ダウンロードコマンドは、Launch 内のプロセスの特定のバージョンを指し示し、そのプロセスをダウンロードし、PAC 形式に変換して保存します。

download-<process-type>-process <user-name> <server-url> <process-id> [<version>|latest] output.pac

アップロードコマンドは逆のことをします; アップロードコマンドはローカルの PAC ファイルをサーバーが期待する JSON フォーマットに変換し、指定されたプロセスの新しいバージョンとしてアップロードします。

upload-<process-type>-process <user-name> <server-url> <process-id> <next-version | latest> input.pac

pacc スクリプトはローカルに保存されている Launch JSON ファイルを PAC フォーマットに変換し、 ccap スクリプトは PAC から JSON フォーマットに変換します。

基本的な構文

PACC ユーティリティの README には、私たちが定義したカスタム構文の詳細な説明が含まれていますが、ここでは基本的なことを説明します。

• "start" と "finish" は、プロセスの入口と出口を表すために使用されます。
• "start " は、定義されたステップを呼び出すために使用されます。
• "plugin step is" は、ステップを定義し、設定します。この一般的な構文は任意のプラグインコマンドを指定することができ、"shell" のような一般的に使用されるステップのための短縮記号があります。
  • "plugin" は使用するプラグインを指します。
  • "command" は、そのプラグインの中で使用する特定のプラグインステップを指します。
  • "on [success | failure | complete]" は、特定のステップが終了した後に実行されるその後のステップを定義する。
  • "property " = " は、プラグインのステップフィールドの値を指定します。

ここでは、シンプルな Tomcat ウェブアプリケーションのアーティファクトセットをダウンロードし、Tomcat プラグインを使用してアプリケーションをデプロイする小さなコンポーネントプロセスの例を示します。

start is
    start "Download Artifacts"
end

plugin step "Download Artifacts" is
    plugin "UrbanCode Deploy Versioned File Storage"
    command "Download Artifacts"
on success
    start "Deploy Tomcat Application"
end

plugin step "Deploy Tomcat Application" is
    plugin "Tomcat"
    command "Deploy Application"
    property "tomcatManagerUrl" = "${p:environment/tomcat.manager.url}"
    property "tomcatUsername" = "exampleTomcatUser"
    property "tomcatPassword" = "${p:environment/secureTomcatPassword}"
    property "tomcatContext" = "/TestA"
    property "warFile" = "./TestApp.war"
    property "configFile" = ""
on success
    finish
end

この例では、Deploy Application ステップのための特定のプロパティを明示的に定義していますが、成果物のダウンロードコマンドは基本的に空のままにして、ステップのデフォルト値を使用しています。PAC プロセスは HCL Launch に直接アップロードされ、サーバーが理解できる形式に変換されているので、プロパティを参照することができます。

始めるには、既存の Launch プロセスを PAC フォーマットに変換するためにプロセスのダウンロードコマンドを使用し、PAC の変更の出発点として使用することをお勧めします。

私は現在、開発用 Launch サーバー上のデプロイメントプロセスを Processes as Code とカスタム githook を使って管理しています。サーバー上で管理したいプロセスは、以下のディレクトリ構造を使って「deployment-processes」リポジトリに格納しています。

Deployment-processes/<processType>/<nameOfComponentOrApplication>/<ProcessID>.pac

これにより、変更した .PAC ファイルのパスには、コミット時に処理をアップロードするために githook が必要とするすべての情報が含まれていることが保証されます。この例では、ブランチにコミットしたらすぐにアップロードするために post-commit フックを使用していますが、toy 以外の例では、git サーバー側の pre-receive フックや post-receive フックのほうが適切です。

下の githook の例は python で書かれたもので、pexpect ライブラリを使用しています。現在のバージョンの PAC ユーティリティでは、Launch サーバーとやりとりするときにパスワードを手動で入力しなければならないという事実を回避しています。

#!/usr/bin/env python3 
from subprocess import check_output
import pexpect
import json
TYPE = 0
NAME = 1
ID = 2
username = ''
password = ''
serverUrl = ''
# returns tuple of type, name, processId
# assumes files are appropriately structured
def parseTargetsFromFile(filepath):
    #component/testComponent/175427f6-0a8b-93b4-d73a-6a8ba534b060.pac
    targets = filepath.split('/')
    filename = targets[ID]
    return targets[TYPE], targets[NAME], filename[:filename.index(".")]
def uploadProcess(cmd):
    child = pexpect.spawn(cmd)
    try:
        i = child.expect([pexpect.TIMEOUT,'password:'])
        if i == 0:
            print("Got unexpected output: %s %s" % (child.before, child.after))
        else:
            child.sendline(password)
        child.read()
    except:
        print("Problem encountered: ")
        print(str(child))
def uploadChangedProcesses():
    # git diff-tree -r --name-only --no-commit-id HEAD
    changedFiles = check_output(['git', 'diff-tree', '-r', '--name-only', '--no-commit-id', 'HEAD']).decode()
    lines = changedFiles.splitlines()
    for line in lines:
        print(f"uploading pac file: {line}")
        line = str(line)
        targets = parseTargetsFromFile(line)
        cmd = buildCommand(targets, line)
        uploadProcess(cmd)

def buildCommand(targets, filename):
    return f"upload-{targets[TYPE]}-process {username} {serverUrl} {targets[ID]} latest {filename}"
if __name__ == "__main__":
    with open('conf.json') as confFile:
        conf = json.load(confFile)   
        username =  conf['username']
        password = conf['password']
        serverUrl = conf['url']
    uploadChangedProcesses()

上記のスクリプトをポストコミットフックとして保存し、私のPACファイルに修正をコミットすると、それらのファイルは、以下のように私のLaunchサーバー上で同じIDを持つプロセスの最新バージョンとしてアップロードされます。

HCL Launch 7.1.1.1 の他のアップデートと一緒に、新しい "Processes as Code "機能が実際に動作しているのを見たい方は、こちらから登録してウェビナーに参加してください。