testcontainers / testcontainers/testcontainers-java

How to make sure there's no stray container not removed when using withDockerfileFromBuilder?

オープン
#3,558 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
Java
スター
8.7k
フォーク
1.9k
平均マージ
2日 17時間
マージ済み PR(30日)
9

説明

Hi guys,

On XWiki, and since the upgrade to TC 1.15.0 (might not be related but didn't notice it before), I've noticed on our CI agents, that there are some TC-created containers that are not always removed on agents. For example:

Screenshot 2020-12-06 at 17 18 06

These containers are created with the following:

                LOGGER.info("(*) Build a dedicated image embedding LibreOffice...");
                // The second argument of the ImageFromDockerfile is here to indicate we won't delete the image
                // at the end of the test container execution.
                container = new XWikiLocalGenericContainer(new ImageFromDockerfile(imageName, false)
                    .withDockerfileFromBuilder(builder -> {
                        builder
                            .from(baseImageName)
                            .user("root")
                            .env("LIBREOFFICE_VERSION", officeVersion)
                            .env("LIBREOFFICE_DOWNLOAD_URL", "https://downloadarchive.documentfoundation.org/"
                                + "libreoffice/old/$LIBREOFFICE_VERSION/deb/x86_64/"
                                + "LibreOffice_${LIBREOFFICE_VERSION}_Linux_x86-64_deb.tar.gz")
                            // Note that we expose libreoffice /usr/local/libreoffice so that it can be found by
                            // JODConverter: https://bit.ly/2w8B82Q
                            .run("apt-get update && "
                                + "apt-get --no-install-recommends -y install curl unzip procps libxinerama1 "
                                    + "libdbus-glib-1-2 libcairo2 libcups2 libsm6 && "
                                + "rm -rf /var/lib/apt/lists/* /var/cache/apt/* && "
                                + "wget --no-verbose -O /tmp/libreoffice.tar.gz $LIBREOFFICE_DOWNLOAD_URL && "
                                + "mkdir /tmp/libreoffice && "
                                + "tar -C /tmp/ -xvf /tmp/libreoffice.tar.gz && "
                                + "cd /tmp/LibreOffice_${LIBREOFFICE_VERSION}_Linux_x86-64_deb/DEBS && "
                                + "dpkg -i *.deb && "
                                + "ln -fs `ls -d /opt/libreoffice*` /opt/libreoffice")
                            // Increment the image version whenever a change is brought to the image so that it can
                            // reconstructed on all machines needing it.
                            .label(OFFICE_IMAGE_VERSION_LABEL, imageVersion);
                        if (this.testConfiguration.getServletEngine() == ServletEngine.JETTY) {
                            // Create the right jetty user directory since it doesn't exist
                            builder.run("mkdir -p /home/jetty && chown jetty:jetty /home/jetty")
                                // Put back the user as jetty since it's a best practice to not execute the container as
                                // root.
                                .user("jetty");
                        }

                        builder.build();
                    }));

See https://github.com/xwiki/xwiki-platform/blob/eaced75f5a08b4131e36504fb5f6c71d6b392fa8/xwiki-platform-core/xwiki-platform-test/xwiki-platform-test-docker/src/main/java/org/xwiki/test/docker/internal/junit5/servletengine/ServletContainerExecutor.java#L286 for more details.

Would you have any idea what could be happening and what we could do?

Thanks a lot

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

ServletContainerExecutor.java の 286 行目付近から始め、issue に示されている withDockerfileFromBuilder の使用箇所を追跡します。参照されているコンテナを使って CI-agent のシナリオを再現し、Testcontainers のクリーンアップ動作を調査します。作成されたコンテナが残る理由を特定し、検証済みのクリーンアップ修正を文書化または実装できれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
docker, java
領域
devops, testing
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。