Docker でパイプラインのデバッグをローカルで行う

Use the Troubleshoot Failed Bitbucket Pipeline article if you are troubleshooting a failed Bitbucket Pipeline locally.


Docker を使用して、Bitbucket Pipelines のビルドをローカルでテストできます。Docker イメージが適切かどうか、またはビルドしようとしたときに Pipelines でメモリの問題が発生するかどうかを確認する際に便利です。

このガイドでは、3 段階のテストについて説明します。

  • コンテナのビルドのテスト

  • コンテナの実行のテスト

  • コンテナ内でのコマンドの実行のテスト

詳細については、Docker のドキュメントを参照してください。

はじめる前に

ローカル環境を準備します。bitbucket-pipelines.yml ファイルの準備ができている Bitbucket リポジトリのローカル コピーがあることを確認します。

リポジトリのクローン方法

要約:

$ cd /Users/myUserName/code

$ git clone git@bitbucket.org:myBBUserName/localDebugRepo.git

In the above command replace myBBUserName with your workspace ID, and localDebugRepo with your repository slug. For the detailed guidelines, see Clone a repository.

  • Pipelines ビルドをローカルでエミュレートする場合は、Pipelines ビルドのコミット ハッシュに基づいて「git reset」コマンドを実行する必要があります。これにより、ローカル ビルドがパイプラインとまったく同じコミットに対して実行されるようにします。

$ cd localDebugRepo

$ git reset --hard 58ab3379d12cd394d0cca78d165d3b42625b0750

コミット ハッシュは、Pipelines ビルドの「ビルド ステップ」にあります。

このシナリオでは、次の bitbucket-pipelines.yml ファイルをテストします。

# You can use a Docker image from Docker Hub or your own container
# registry for your build environment.
image: python:3
 
pipelines:
  default:
    - step:
        script: # Modify the commands below to build your repository.
          - python --version
          - python myScript.py

You can check your bitbucket-pipelines.yml  file with our online validator. Once your local repository is ready, proceed to the steps below.

ステップ 1: マシンに Docker をインストールする

インストール手順は、使用するオペレーティング システムによって異なります。Docker が提供しているインストール ガイドラインに従ってください。

Doker をインストールしたら、ターミナルに移動して以下を実行します。

$ docker version

Docker をインストール済みの場合、コマンドはバージョンの詳細情報を返し、適切にインストールされていることを示します。Bitbucket での実行時にローカル バージョンがパイプラインで使用されているバージョンと一致していることを確認してください。異なる場合、互換性の問題が発生する可能性があります。

Docker のインストールを完了すると、独自のカスタム イメージをビルドしたり、既存のイメージ (Docker Hub からダウンロード可能なものなど) を使用したりすることができます。

手順 2: Dockerfile を利用して Docker イメージをローカルにビルドする

カスタム Docker イメージを使用していない場合でも、ベース Docker イメージをローカルでビルドすることをお勧めします。また、ローカル リポジトリ フォルダーの場所を、作業ディレクトリを含むベース Docker イメージにコピーすることを強くお勧めします。

現在ローカル リポジトリ フォルダー内にいる場合は、1 つ前のフォルダー レベルに戻ってファイルを作成できます (たとえば、my.dockerfile または任意の Dockerfile 名)。

cd ..
touch my.dockerfile

その後、Dockerfile をセットアップできるようになります。my.dockerfile は次のようになります。

FROM python:3
WORKDIR /localDebugRepo
COPY ./localDebugRepo /localDebugRepo

ここで:

FROM python:3

実行する Docker イメージ。bitbucket-pipeline.yml ファイルで指定したイメージを使用することが一般的です。詳細は、「Docker イメージをビルド環境として使用する」を参照してください。

WORKDIR /localDebugRepo

開始点となるディレクトリを設定します。このディレクトリでコマンドが実行されます。既定では、コンテナのルート ディレクトリになります。

COPY ./localDebugRepo

ファイルを、ホスト マシンからコンテナーのファイル システムにコピーします。

Dockerfile の詳細については、イメージの作成手順または Docker 公式の入門ガイドをご参照ください。Dockerfile リファレンスについては、このページもご確認ください。

完了したら、次のコマンドを実行して Docker イメージをビルドできるようになります。

$ docker build --memory=1g --memory-swap=1g -t account/imageName:tag -f my.dockerfile .

ここで:

docker build

Docker イメージのビルドを行うことを指定します。


--memory=1g --memory-swap=1g

スワップ領域を持たない 1 GB メモリのコンテナをビルドします (スワップはスワップ値 - メモリ値で計算されます)。このメモリ量は 1 つのサービス コンテナでの Pipelines のメモリ制限のシミュレーションを行います (両方のフラグが必要です)。 

ローカルでデバッグする際には、可能な限り Pipelines に近い状態を再現するためにメモリ制限を設定して、Pipelines のメモリ制限に該当しないことを確認することをおすすめします。ローカルで合格するパイプラインが失敗する原因の多くはメモリ制限です。

Docker ドキュメントでメモリの管理に関する詳細を確認できます。

macOS (OS X)

docker stats コマンドを使用して、コンテナの実際のメモリ制限を確認します。

ステータス バーで既定のメモリ設定を変更できます ( > [設定] > [詳細設定])。

-t accountName/imageName:tag

指定された名前、イメージ名、およびタグで、アカウントのイメージを作成します。

-f my.dockerfile

イメージのビルド時に使用する docker ファイルの名前を指定します。

.

docker ビルド コンテキストでルートとして使用するディレクトリを指定します (指定しない場合はカレント)。

Pipelines ファイルでイメージを定義していない場合、アトラシアンの既定のイメージが使用されます。

ステップ 3: Docker コンテナの実行をテストする

ベース Docker イメージがビルドされると、そのビルドされた Docker イメージによってコンテナーを実行できるようになります。

$ docker run -it --memory=4g --memory-swap=4g --memory-swappiness=0 --cpus=4 --entrypoint=/bin/bash account/imageName:tag

ここで:

docker run -it

TTY と STDIN open の状態で Docker コンテナを実行します。つまり、コンテナは対話モードで開き、ユーザーはコンテナ内でコマンドを実行できます。

--memory=4g --memory-swap=4g --memory-swappiness=0

ビルド コンテナでの Pipelines のメモリ制限のシミュレーションを行うための、スワップ領域を持たない 4 GB メモリのコンテナを実行します (3 つのフラグすべてが必要です)。

ローカルでデバッグする際には、可能な限り Pipelines に近い状態を再現するためにメモリ制限を設定して、Pipelines のメモリ制限に該当しないことを確認することをおすすめします。ローカルで合格するパイプラインが失敗する原因の多くはメモリ制限です。

Docker ドキュメントでメモリの管理に関する詳細を確認できます。

macOS (OS X) の場合

docker stats コマンドを使用して、コンテナの実際のメモリ制限を確認します。

Docker Desktop を開いて [Settings (歯車アイコン)] > [Resources] > [Advanced] に移動することでデフォルトのメモリ設定を変更できます。

cpus=4

コンテナに使用できる利用可能な CPU リソースの量を指定します。Docker ドキュメントでランタイム オプションに関する詳細を確認できます。

imageName:tag

実行する Docker イメージ。bitbucket-pipeline.yml ファイルで指定したイメージを使用することが一般的です。詳細は、「Docker イメージをビルド環境として使用する」を参照してください。

--entrypoint=/bin/bash

コンテナの開始時に bash プロンプトを開始します。

環境変数をコンテナに渡すには、-e スイッチを使用できます (例: --e "VAR1=hello" -e "VAR2=world を上述のコマンドの -it の前に追加、または --env-file=env-vars.txt ファイルを使用)。詳細をご確認ください

Docker イメージが実行され、次のように ID を確認できるようになっているはずです。

root@1af123ef2211:/localDebugRepo

これは、ユーザーはコンテナ内の作業ディレクトリ内にいて、コマンドの実行を開始できることを意味します。パイプライン ビルドをローカルでエミュレートしている場合、bitbucket-pipeline.yml ファイルの script セクションで定義したコマンド シーケンスと同じものを実行できます。

ビルド サービスでのテスト

ビルドで MySQL などのサービスを標準的に使用する場合、別のコンテナを使用してこれをローカルでテストすることもできます。

サービスを使用するには、--network=host オプションを追加してホストのネットワークを直接使用し、メイン コンテナーの前にサービス コンテナーを起動します。

MySQL の例:

docker run --network=host --name my-mysql-name  \ 
-e MYSQL_DATABASE='pipelines' \ 
-e MYSQL_RANDOM_ROOT_PASSWORD='yes' \ 
-e MYSQL_USER='test_user' \ 
-e MYSQL_PASSWORD='test_user_password' \ 
-d mysql:<tag>

次に、メイン コンテナーの実行時に、必ず --network=host オプションも追加してサービス コンテナーにリンクします。

メイン コンテナーを実行するためにステップ 3 で実行するコマンドの例は次のようになります。

docker run -it --network=host --memory=4g --memory-swap=4g --memory-swappiness=0 --cpus=4 --entrypoint=/bin/bash account/imageName:tag

ステップ 4: ローカル環境でスクリプトをテストする

コンテナをビルドして実行したら、Pipelines スクリプトに一覧化したコマンドを実行できます。

ローカルでデバッグできる問題が見つかり、その修正を行った場合は、bitbucket-piplines.yml を更新して一致させます。

実際にこれを使用した場合の例を見てみましょう。

この段階で、オープンな python:3 コンテナーがあり、ユーザーはリポジトリ ディレクトリ内にいます。

ここから、次のことが実行できます。

  • bitbucket-pipelines.yml から個々のコマンドを実行してテストする

  • コンテナ内のツールを構成する

このガイドの冒頭で触れた bitbucket-pipelines.yml ファイルをテストします。

bitbucket-pipelines.yml
# You can use a Docker image from Docker Hub or your own container
# registry for your build environment.
image: python:3
 
pipelines:
  default:
    - step:
        script: # Modify the commands below to build your repository.
          - python --version
          - python myScript.py

スクリプトの最初のステップは、python バージョンのテストです。

$ python --version

出力は適切に見えます。

Python 3.11.0

次に、python スクリプトを実行します。

$ python myScript.py

この例は、リポジトリに myScript.py スクリプトがある場合にのみ動作します。スクリプトには、上記で実行したバージョン コマンドが含まれます。

ここでも、出力にエラーは表示されていません。

Python 3.11.0

次に、コンテナ内で設定を行う場合があります。

$ pip install scipy

出力:

Collecting scipy
  Downloading scipy-1.9.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (43.9 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 43.9/43.9 MB 24.1 MB/s eta 0:00:00
Collecting numpy<1.25.0,>=1.18.5
  Downloading numpy-1.23.3-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 17.1/17.1 MB 24.9 MB/s eta 0:00:00
Installing collected packages: numpy, scipy
Successfully installed numpy-1.23.3 scipy-1.9.1

これが正常に実行されているため、これを bitbucket-pipelines.yml ファイルに追加して変更をコミットし、パイプラインをエラーなしで実行できることを確認できます。

bitbucket-pipelines.yml
# You can use a Docker image from Docker Hub or your own container
# registry for your build environment.
image: python:3
 
pipelines:
  default:
    - step:
        script: # Modify the commands below to build your repository.
          - python --version
          - python myScript.py
          - pip install scipy
最終更新日: 2025 年 1 月 27 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.