Linux 用の MID Server Docker イメージのビルド

リリースバージョン: Yokohama

更新日 2025年01月30日

所要時間：21分

提供されたレシピを使用して Docker イメージを作成し、コンテナ化された MID サーバーを Linux に展開します。コンテナ化された MID サーバーは、MID サーバーの Docker イメージを使用して、MID サーバーを大規模に迅速に展開できるようにします。

始める前に

必要なロール：admin

必須条件：

ホストは Docker エンジンとコマンドラインインターフェイス（CLI）20.10.4 以降を使用する必要があります。

ライブラリを利用可能な最新バージョンに更新するか、少なくともセキュリティ修正を適用した最新バージョンに更新します。特定された問題が推移的な依存関係の一部である場合は、新しい推移的なバージョンを含む依存ライブラリのバージョンを探します。依存ライブラリをアップグレードしても推移的な依存関係をアップグレードできない場合は、依存関係を除外し、セキュアなバージョンを直接含めることを検討してください。

注:

docker version コマンドをアドミニストレーターとして実行して、docker の可用性を確認します。詳細については、docker version コマンドのドキュメントを参照してください。

手順

MID サーバーのダウンロードページから Linux Docker レシピの ZIP ファイルをダウンロードし、その署名を確認します。
MID サーバーのダウンロードページと署名検証の詳細については、「 MID Server ファイルのダウンロード (Download MID Server files)」を参照してください。
ZIP ファイルをフォルダーに展開します。
オプション: 現在のディレクトリーを新しいフォルダーに変更できます。

イメージをビルドするには、build コマンド > docker build <path-to-docker-recipe> [ --tag <docker-tag> ] を実行します。

コマンドの詳細については、「Docker build コマンドのドキュメント」を参照してください。Docker ファイルのパスは、相対パスにすることも、ファイルが Docker ディレクトリにある場合は、現在のディレクトリにすることもできます。

デフォルトのイメージタグは、.env ファイルですぐに利用可能な DOCKER_TAG パラメーターを使用して指定されます。docker コマンドを実行する前にこのパラメーターをエクスポートするには、コマンド > export $(grep DOCKER_TAG .env) を実行します。次のコマンドで <docker-tag> を DOCKER_TAG 値に置き換えることができます。

build コマンドは、次の build 引数を取ります。


プロパティ	説明
MID_INSTALLATION_URL	MID サーバーインストールファイルをダウンロードするためのリンク。デフォルトでは、MID サーバーのダウンロードページで提供される Linux 64 ビットインストール ZIP ファイルのダウンロードリンクに設定されています。
MID_INSTALLATION_FILE	MID サーバーのローカルインストールファイルの名前。デフォルト値は空です。このパラメーターが空でない場合、レシピはインストールサーバーからダウンロードするのではなく、ローカルファイルを使用します。このパラメーターは、ファイル名のみを使用し、完全パスは使用しません。ビルドする前に、ローカルファイルを recipe ディレクトリの asset/ サブフォルダーにコピーする必要があります。Rome より前の MID サーバーリリースはサポートされていません。例：`> docker build <path-to-dockerfile> --build-arg MID_INSTALLATION_FILE=<mid.installation.file.name>) --tag <docker-tag>`
MID_SIGNATURE_VERIFICATION	MID サーバーインストールファイルの署名を検証する必要があります。デフォルト値は TRUE です。これが TRUE の場合、ビルドプロセスでは、MID サーバーインストールファイルがリモートサーバーからダウンロードされたものか、またはローカルファイルかどうかについて、デジタル署名を常に確認します。そうでない場合は、署名の検証がスキップされます。例：`> docker build <path-to-dockerfile> --build-arg MID_SIGNATURE_VERIFICATION=false --tag <docker-tag>`
USER_ID と GROUP_ID	デフォルトでは、指定されていない場合、Docker はユーザーID = 1001、グループ ID = 1001 の MID サーバーユーザーを作成します。USER_ID と GROUP_ID ビルド引数を使用して、カスタムユーザー ID とグループ ID をコンテナに渡すことができます。Docker は、指定されたユーザー ID とグループ ID を使用して MID サーバーのコンテナユーザーを作成します。コンテナイメージ内で、MID サーバーインストールフォルダーの下にあるすべてのファイルは、このユーザーとルートグループ (id=0) が所有しています。イメージが Kubernetes プラットフォームに展開されると、この MID サーバーユーザーが MID サーバーを実行するコンテナユーザーになります。イメージが OpenShift プラットフォームに展開されると、OpenShift は MID サーバーを実行するコンテナユーザーとして、アドミン以外の任意のユーザー ID をアサインする場合があります。ただし、そのユーザーは常にルートグループに属します。どちらの場合も、コンテナユーザーは MID サーバーファイルへのフルアクセス権を持ちます。これにより、同じイメージを Kubernetes と OpenShift に展開できます。

オプション: イメージが正常にビルドされたら、> docker image ls コマンドでビルドされたイメージを一覧表示できます。

次のタスク

未使用または中間のイメージがある場合は、ディスクスペースを節約するために、次のコマンドを実行してそれらのぶら下がりイメージを削除します。

$ docker rmi $(docker images --filter "dangling=true" -q --no-trunc)

たとえば、ぶら下がりイメージを削除する前に、コマンド docker image ls が次のようになる場合があります。

REPOSITORY                                TAG                                           IMAGE ID       CREATED              SIZE
mid                                       trackdiscocopper-10-09-2020_10-14-2021_2200   4542b6ab34af   21 seconds ago       1.01GB
<none>                                    <none>                                        1cdae087a970   About a minute ago   1.38GB

ぶら下がりイメージを削除した後、コマンド docker image ls は次のようになります。

REPOSITORY                                TAG                                           IMAGE ID       CREATED              SIZE
mid                                       trackdiscocopper-10-09-2020_10-14-2021_2200   4542b6ab34af   About a minute ago   1.01GB

コンテナ化された MID サーバーの起動

コンテナ化された MID サーバーは、MID サーバーの Docker イメージを使用して、MID サーバーを大規模に迅速に展開できるようにします。MID サーバーは、Docker Swarm などのオーケストレーションツールを使用して展開されます。

始める前に

必要なロール：admin

必須条件：

Linux ホストでは、AlmaLinux ディストリビューション 64 ビットアーキテクチャを使用する必要があり、AlmaLinux ディストリビューションをお勧めします。
ホストは Docker エンジンとコマンドラインインターフェイス（CLI）20.10.4 以降を使用する必要があります。

注:
docker version コマンドをアドミニストレーターとして実行して、docker の可用性を確認します。詳細については、docker version コマンドのドキュメントを参照してください。

手順

イメージが使用可能になったら、次のように docker run コマンドを使用して新しい MID サーバーを起動し、env ファイルまたは env 変数のオプションを指定します。docker run --env-file <env_file_name_here> <docker_tag or image_id>

注:
セキュリティの脆弱性がある可能性があるため、このコマンドを使用して機密データを渡さないでください。機密データを渡すには、手順 Docker シークレットを使用して、コンテナ化された MID サーバーに機密データを渡すおよび Kubernetes シークレットを使用して、コンテナ化された MID サーバーに機密データを渡すを使用します。

詳細については、Docker のドキュメントページで、docker image ls コマンド、docker run コマンド、および env ファイルまたは env 変数オプションの指定を参照してください。env ファイルは、name = value 形式を使用した単純なテキストファイルです。変数が env ファイルと --env オプションの両方で指定されている場合、コマンドラインで定義された変数が優先されます。

展開要求は、コンテナ化された MID サーバーを起動するための推奨方法ですが、環境変数を使用して構成することもできます。コンテナが最初に起動されると、初期化スクリプトは環境変数を取得し、次の環境変数を使用して MID サーバーアプリケーションを設定します。

MID_INSTANCE_URL

この変数は、「url」設定パラメーターを設定します。

MID_INSTANCE_USERNAME

この変数は、「mid.instance.username」設定パラメーターを設定します。

MID_INSTANCE_PASSWORD

この変数は、「mid.instance.password」設定パラメーターを設定します。

MID_SERVER_NAME

この変数は、「name」設定パラメーターを設定します。

MID_PROXY_HOST

この変数は、「mid.proxy.host」設定パラメーターを設定します。この変数は必須ではなく、プロキシが設定されている場合にのみ必要です。

MID_PROXY_PORT

この変数は、「mid.proxy.port」設定パラメーターを設定します。

MID_PROXY_USERNAME

この変数は、「mid.proxy.username」設定パラメーターを設定します。

MID_PROXY_PASSWORD

この変数は、「mid.proxy.password」設定パラメーターを設定します。

MID_SECRETS_FILE

この変数は、パスワードや証明書などの機密データを含む完全なシークレットファイル名を指定します。

MID_MUTUAL_AUTH_PEM_FILE

この変数は、自動検証セットアップに使用されるクライアント証明書ファイルの完全なファイル名を指定します。
オプション: コンテナのリストを表示するには、docker container ls コマンド docker container ls [-a] を実行します。

Docker シークレットを使用して、コンテナ化された MID サーバーに機密データを渡す

環境変数またはシークレットファイルを介して渡された構成パラメーターを使用してコンテナ化された MID サーバーを構成できます。

始める前に

必要なロール：Docker Swarm アドミン

このタスクについて

Docker シークレットを使用すると、パスワードや証明書などの機密データをコンテナ化された MID サーバーに渡すことができます。この手順を使用する前に、Docker Swarm をセットアップして起動してください。

展開を作成するときは、レプリカが 1 に保たれていることを確認してください。

手順

機密データを mid-secrets.propertiesに配置します。
次のコマンドを使用して Docker シークレットを作成します。docker secret create mid-secrets mid-secrets.properties

最初の mid-secrets は Docker Swarm 内のシークレットファイルを表し、2 番目の mid-secrets.properties パラメーターはホストマシンのファイルシステム上のシークレットを読み取るためのファイルパスを表します。作成されたすべてのシークレットを一覧表示するには、コマンド docker secret lsを実行します。

docker secret コマンドの詳細については、「docker secret のドキュメント」を参照してください。
コンテナ内のシークレットファイルへのパスを使用して、MID_SECRETS_FILE 環境変数を更新します。
Linux での Docker Swarm シークレットのデフォルトパスは、/run/secrets/mid-secrets.properties です。
次の docker service create コマンドを使用して、MID サーバーイメージコンテナを Swarm に展開します。Docker service create --name mid-service --secret mid-secrets.properties --env-file mid.env<docker-tag or image-id>

コンテナサービスが指定されたシークレットに関連付けられるように、--secret flag が指定されていることを確認してください。

Docker シークレットを使用して、コンテナ化された相互認証済みの MID サーバーに機密データを渡す

環境変数またはシークレットファイルを介して渡された設定パラメーターを使用してコンテナ化された MID サーバーを構成できます。

始める前に

必要なロール：admin

必要なロール：Docker Swarm アドミン

このタスクについて

証明書ベースの認証がインスタンスで有効になっている場合は、相互認証クライアント証明書 (PEMファイル) を使用して自動検証するように MID サーバーを構成できます。これは、コンテナ内の PEM 証明書ファイルへの完全パスを MID_MUTUAL_AUTH_PEM_FILE 環境変数で設定することで実行できます。たとえば、mid.env ファイルで変数を MID_MUTUAL_AUTH_PEM_FILE= /run/secrets/certificate.pem に更新できます。

Docker または Kubernetes シークレットを使用して、PEM 証明書ファイルをコンテナに渡すことができます。以下は、PEM 証明書ファイルをコンテナに渡すコマンドの例です。docker service create --name mid-service --secret mid-secrets.properties --secret <certificate-secret-name> --env-file mid.env <docker-tag or image-id>

相互 PEM 証明書は、初期化中に MID サーバーにインストールされます。その後、MID サーバーはインスタンスに接続し、自動検証します。相互認証が正常に有効になっている状態で MID サーバーがインスタンスに接続すると、MID エージェントのログに次のようなエントリーが記録されることがあります。

カスタム証明書を MID キーストアにインストールしました
相互認証を使用するように構成された MID

手順

相互認証 PEM バンドルを準備します。
次の docker secret create コマンドを使用して、Docker シークレットを作成します。docker secret create mutual-auth-secret <mutual-auth-pem-file-on-local-filesystem> 。

作成されたすべてのシークレットを一覧表示するには、コマンド docker secret lsを実行します。
コンテナ内のシークレットファイルへのパスを使用して、MID_MUTUAL_AUTH_PEM_FILE 環境変数を更新します。

Linux での Docker Swarm シークレットのデフォルトパスは、/run/secrets/<mutual-auth-pem-file-name> です。
次の docker service create コマンドを使用して、MID サーバーイメージコンテナを Swarm に展開します。docker service create --name mid-service --secret mutual-auth-secret --env-file mid.env <docker-tag or image-id>

コンテナサービスが指定されたシークレットに関連付けられるように、--secret flag が指定されていることを確認してください。
deployment.yml を使用してコンテナ化された MID サーバーをポッドに展開し、kubectl create -f deployment.yml コマンドを実行します。

Kubernetes シークレットを使用して、コンテナ化された MID サーバーに機密データを渡す

環境変数またはシークレットファイルを介して渡された設定パラメーターを使用してコンテナ化された MID サーバーを構成できます。

始める前に

必要なロール：Kubernetes アドミン

この手順を使用する前に、Kubernertes クラスターをセットアップして起動してください。Kubernetes シークレットの詳細については、「Kubernertes シークレットのドキュメント」を参照してください。

注:

Kubernetes はローカルイメージと直接連携しません。MID サーバーイメージをパブリックレジストリにアップロードするか、ローカルレジストリーをセットアップします。Docker レジストリーのビルドについては、「Docker の公式の説明」を参照してください。

展開を作成するときは、レプリカが 1 に保たれていることを確認してください。

手順

機密データを mid-secrets.properties に適切に配置します。
次のコマンドを使用して、Kubernetes シークレットを作成します。kubectl create secret generic mid-secret --from-file=mid-secrets.properties
オプション: 作成されたすべてのシークレットを一覧表示するには、kubectl get secrets コマンドを実行します。
コンテナ内のシークレットファイルへのパスを使用して、MID_SECRETS_FILE 環境変数を更新します。
パスはシークレットの構成ファイルを作成するときにデータフィールドで定義されます。

次のサンプル YML コンテンツを使用して展開を作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: basic-example
spec:
  selector:
    matchLabels:
      app: MIDServerManagement
      provider: ServiceNow
  replicas: 1
  template:
    metadata:
      labels:
        app: MIDServerManagement
        provider: ServiceNow
    spec:
      containers:
        - name: basic-example-container
          imagePullPolicy: IfNotPresent
          image: "mid:imageTag"
          env:
            - name: MID_INSTANCE_URL
              value: " https://exampleinstance.service-now.com/"
            - name: MID_INSTANCE_USERNAME
              value: "mid_server_user_name”
            - name: MID_SECRETS_FILE
              value: "/opt/snc_mid_server/secrets/mid-secrets.properties“
            - name: MID_SERVER_NAME
              value: "Basic-Example-MID"
          volumeMounts:
            - mountPath: "/opt/snc_mid_server/secrets"
              name: "mid-mount-secret"
              readOnly: true
      volumes:
      - name: "mid-mount-secret"
        secret:
          secretName: "mid-secret"

注:

展開またはポッドを作成する方法は多数あります。詳細については、「Kubernetes の展開手順」を参照してください。

deployment.yml を使用してコンテナ化された MID サーバーをポッドに展開し、kubectl create -f deployment.yml コマンドを実行します。

Kubernetes シークレットを使用して、コンテナ化された相互認証済みの MID サーバーに機密データを渡す

環境変数またはシークレットファイルを介して渡された設定パラメーターを使用してコンテナ化された MID サーバーを構成できます。

始める前に

必要なロール：Kubernetes admin

必須条件：

証明書ベースの認証がインスタンスで有効になっている場合は、相互認証クライアント証明書 (PEMファイル) を使用して自動検証するように MID サーバーを構成できます。これは、コンテナ内の PEM 証明書ファイルへの完全パスを MID_MUTUAL_AUTH_PEM_FILE 環境変数で設定することで実行できます。Kubernetes シークレットを使用して、PEM 証明書ファイルをコンテナに渡すことができます。

カスタム証明書を MID キーストアにインストールしました
相互認証を使用するように構成された MID

手順

相互認証 PEM バンドルを準備します。
次のコマンドを使用して、Kubernetes シークレットを作成します。kubectl create secret generic mutual-auth-secret --from-file=<mutual-auth-pem-file>
オプション: 作成されたすべてのシークレットを確認するには、kubectl get secrets コマンドを実行します。
コンテナ内のシークレットファイルへのパスを使用して、MID_MUTUAL_AUTH_PEM_FILE 環境変数を更新します。

次のサンプル YML コンテンツを使用して展開を作成します。

6.	apiVersion: apps/v1
7.	kind: Deployment
8.	metadata:
9.	  name: mutual-auth-example
10.	spec:
11.	  selector:
12.	    matchLabels:
13.	      app: MIDServerManagement
14.	      provider: ServiceNow
15.	  replicas: 1
16.	  template:
17.	    metadata:
18.	      labels:
19.	        app: MIDServerManagement
20.	        provider: ServiceNow
21.	    spec:
22.	      containers:
23.	        - name: mutual-auth -container
24.	          imagePullPolicy: IfNotPresent
25.	          image: "mid:imageTag”
26.	          env:
27.	            - name: MID_INSTANCE_URL
28.	              value: "https://exampleinstance.service-now.com/"
29.	            - name: MID_INSTANCE_USERNAME
30.	              value: "mid_server_user_name”
31.	            - name: MID_SERVER_NAME
32.	              value: "Mutual-Auth-Deployment-MID"
33.	            - name: MID_MUTUAL_AUTH_PEM_FILE
34.	              value: "/opt/snc_mid_server/mutual-auth/yourpemfile.pem"
35.	          volumeMounts:
36.	            - mountPath: "/opt/snc_mid_server/mutual-auth"
37.	              name: "mid-mount-mutual-auth"
38.	              readOnly: true
39.	      volumes:
40.	      - name: "mid-mount-mutual-auth"
41.	        secret:
42.	          secretName: "mid-mutual-auth-secret"

deployment.yml を使用してコンテナ化された MID サーバーをポッドに展開し、kubectl create -f deployment.yml コマンドを実行します。