Docker Composeを使ったWebLogicの自動デプロイ

著者
Damian
Terlecki
6分間の読書
JEE

Docker Composeは、多数のコンテナからなる開発環境を迅速に立ち上げるための便利なツールです。 Dockerイメージの文脈では、典型的な戦略は、アプリケーションの新しいバージョンを含む新しいイメージをビルドし、 それを外部環境にデプロイすることです。 開発環境のニーズに合わせて、同じコンテナを再利用してアプリケーションの新しいイテレーションをデプロイすることで、開発を加速できます。

非本番モードに基づいて自動デプロイの可否を判断するWebLogicの起動ログ – domain_name: [base_domain]; admin_listen_port: [7001]; domain_path: [/u01/oracle/user_projects/domains/base_domain]; production_mode: [dev]; admin name: [AdminServer]; administration_port_enabled: [true]; administration_port: [9002]

WebLogicの場合、サーバーは自動デプロイ機能を提供しています。アーティファクトまたは展開されたアーカイブをautodeployディレクトリに 配置するだけです。Dockerのボリュームを使えば、 アプリケーションのアーティファクトを自動デプロイの場所にバインドできます。

ビルド時、アーティファクトは通常build(Gradle)またはtarget(Maven)ディレクトリに生成されます。しかし、このパスを直接リンクすることは、 いくつかの理由から最善のアイデアではありません:

  1. デプロイ不可能なサブディレクトリが含まれている。
  2. アーティファクトがない場合、空のサブディレクトリに変わってしまう。
  3. mvn cleanを実行するたびに、次の再起動までボリュームバインドが失われたように見えることがある(ファイルシステム固有)

したがって、手動介入を必要としない信頼性の高い設定は、ボリュームを親ディレクトリにバインドすることです。

project/
├─ src/
│  ├─ main/
│  │  ├─ java/
│  │  │  ├─ .../
│  │  ├─ webapp/
│  │  │  ├─ WEB-INF/
│  │  │  │  ├─ web.xml
├─ target/
│  ├─ classes
│  ├─ wlsdemo
│  ├─ wlsdemo.war
├─ src/
│  ├─ index.css
│  ├─ index.js
├─ docker-compose.yml
├─ domain.properties
├─ pom.xml

上記のサンプルツリーで、projectフォルダをコンテナ内の/projectディレクトリにバインドするには、次のdocker-compose.ymlを使用します。

version: '3'
services:
  weblogic:
    build: ./
    environment:
      - "debugFlag=true"
      - "DEBUG_PORT=*:8453"
    ports:
      - "7001:7001" #admin_listen_port
      - "9002:9002" #secure administration_port
      - "8453:8453" #custom debug port
    volumes:
      - ./:/project
      - ./:/u01/oracle/properties

アーティファクトの自動デプロイは、ソフトリンクを使用して実装できます。以下のDockerfileを見てください。 これはdocker-compose.ymlによって自動ビルドされます。packageフェーズ中に maven-war-plugin/maven-ear-pluginによって生成された展開済みアーカイブは、完全なアーティファクトと交換することもできます。

# Requires license acceptation at https://container-registry.oracle.com/ Middleware > WebLogic
FROM container-registry.oracle.com/middleware/weblogic:14.1.1.0-dev-11
RUN mkdir -p /u01/oracle/user_projects/domains/base_domain/autodeploy/ \
    && /usr/bin/ln -s /project/target/wlsdemo \
    /u01/oracle/user_projects/domains/base_domain/autodeploy/wlsdemo

classesサブフォルダの変更は継続的に監視され、クラスローダーのリロードを引き起こします。 ドキュメントでは、 展開されたWAR/EARアーティファクトのWEB-INF/META-INF下にあるREDEPLOYファイルを更新することによる完全な再デプロイも記述されています。これをpackageフェーズの最後に配置されたmaven-antrun-pluginで自動化します。

    <build>
        <finalName>${artifactId}</finalName>
        <plugins>
            <!--...-->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-antrun-plugin</artifactId>
                <version>3.0.0</version>
                <executions>
                    <execution>
                        <id>touch-redeploy-file</id>
                        <phase>package</phase>
                        <goals>
                            <goal>run</goal>
                        </goals>
                        <configuration>
                            <target>
                                <touch file="${project.build.directory}/${project.artifactId}/WEB-INF/REDEPLOY"
                                       verbose="true" />
                            </target>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
</build>

この例では、debugFlagDEBUG_PORT環境変数を使用しました。これらは /u01/oracle/user_projects/domains/base_domain/bin/setDomainEnv.shスクリプトによって処理されます。要するに、これはすべてのネットワークインターフェースでデバッガモードを設定します(JDK 9+)。 これでデバッグが可能になり、 お気に入りのIDE(IntelliJ > Edit Configuration > Remote JVM Debug)が提供するJPDAホットスワップの利点を活用できます。

domain.propertiesファイルは、カスタム初期化スクリプトなしのクリーンなイメージに必要です。管理者ユーザー名とパスワードを次の形式で含める必要があります:

username=myadminusername
password=myadminpassword12#

JVMデバッガーがアタッチするのを待ちたい場合は、debugFlagの代わりにJAVA_OPTIONS環境変数を直接設定してください。

カスタムポートマッピングには注意してください。t3接続を確立するために-Dweblogic.rjvm.enableprotocolswitch=trueが必要になる場合があります。