Zenn
ツクリンクPublicationへの投稿
🐳

SREチームでチーム開発を行うためにdockerで実行環境を統一した

ida.
に公開
Docker
Terraform
DevOps
ecspresso
SRE
tech

こんにちは、ツクリンクでSREエンジニアをやってるida.です。

ツクリンクではSREチームを発足して2年ほど経ちます。SREチームではAWS CLIやTerraform、ecspresso等いくつか開発でツールを利用しますが、チーム発足時は各自のローカル環境にインストールして開発を行っていました。ただ、チームを拡充していく中でバージョンが異なってきたり、都度ローカルをセットアップしたりと課題がでてきたのでDockerを使って実行環境を統一しました。今回はその方法を紹介しようと思います。

実行環境で利用するツール、コマンドについて

先にも少し記載しましたが、ツクリンクのSREチームでは以下のようなツールを使っております。
そのためこれらのツールを利用できる実行環境を用意するようにしました。

  • Docker
  • AWS CLI
  • Terraform
  • ecspresso

また他に、よく使うコマンドとして以下をイメージに追加で含めるようにしました。
curl / tar / gzip / unzip / bash / vim / cat / make / git / jq

Dockerを利用した実行環境の作成

実際にDockerfileとcompose.ymlの例を以下に記載します。

Dockerfile

まず、Dockerfileです。結構単純で必要なツールをコマンドをインストールしているだけですね！
こちらを参考に実際の開発に必要なツール、コマンドを適宜調整すると良いと思います。

Dockerfile
# 各バージョンは執筆時点の最新なので流用する際は適宜更新してください。
ARG TERRAFORM_VERSION=1.12.0
ARG DOCKER_VERSION=28.0.4
ARG AWS_CLI_VERSION=2.27.17

FROM hashicorp/terraform:${TERRAFORM_VERSION} AS terraform
FROM docker:${DOCKER_VERSION} AS docker
FROM amazon/aws-cli:${AWS_CLI_VERSION} AS awscli

ARG ECSPRESSO_VERSION=2.5.0

# 必要なパッケージをインストール
RUN yum install -y curl tar gzip unzip bash vim cat make git jq && yum clean all

# ecspressoはARM64バイナリをダウンロードして展開
# ホストがAMD64の場合はAMD64バイナリを指定してください。
RUN curl -Lo /usr/local/bin/ecspresso.tar.gz https://github.com/kayac/ecspresso/releases/download/v${ECSPRESSO_VERSION}/ecspresso_${ECSPRESSO_VERSION}_linux_arm64.tar.gz && \
    tar -zxvf /usr/local/bin/ecspresso.tar.gz -C /usr/local/bin/ && \
    rm /usr/local/bin/ecspresso.tar.gz

COPY --from=terraform /bin/terraform /usr/local/bin/
COPY --from=docker /usr/local/bin/docker /usr/local/bin/docker
COPY --from=docker /usr/local/libexec/docker/cli-plugins/docker-buildx /usr/local/libexec/docker/cli-plugins/docker-buildx

# シェルをバッシュに変更
SHELL ["/bin/bash", "-c"]

# エントリーポイントを設定
ENTRYPOINT ["/bin/bash"]

compose.yml

次に、compose.ymlで実際の実行環境を構成します。

compose.yml
services:
  sredocker:
    env_file:
      - path: variables.env
        required: false
    environment:
      TZ: Asia/Tokyo
      HISTTIMEFORMAT: '%F %T '
    build: .
    volumes:
      - ./:/project # カレントディレクトリ全体をマウント projectは適宜カレントディレクトリ名に修正してください。
      - root:/root # ホームディレクトリをマウント
      - ~/.aws:/root/.aws # AWS認証情報をマウント
      - /var/run/docker.sock:/var/run/docker.sock # ホストのDockerデーモンにアクセスできるようマウント
      # 以下の非マウントの指定は不要であれば削除しても問題ないです。
      - /project/log # docker build時にイメージへ含ませないため非マウント
      - /project/node_modules # docker build時にイメージへ含ませないため非マウント
    working_dir: /project
    entrypoint: [ "/bin/bash", "-c", ".docker/entrypoint.sh" ]

volumes:
  root:

ポイントとなるのは以下の設定です。

  • ローカルのファイルを参照するようにプロジェクト全体をコンテナ内にマウントしてます。
  • AWSを利用するのでAWS認証情報をコンテナ内で利用可能にしてます。
  • 実行環境上でDockerを利用するのでホストのDockerデーモンを利用できるようにマウントしました。（Docker in Docker構成）
  • ログやnode_modulesなど不要なものはマウントしない設定
  • env_fileを指定して実行環境上で設定したい環境変数variables.envに記載して読み込むようにしています。
  • entrypointのスクリプトではaws sso loginを実施してaws cliを実行できるようにしてます。

entrypoint.sh

必須ではないですがさらに効率的に使うため、実行環境の起動時にentrypoint.shを実行して初期セットアップを行うようにしています。主な処理としてはaws sso loginを実施してaws cliを実行できるようにしています。
（都度aws sso loginを行うとちょっと面倒くさいので、ログイン済みの時はスキップするようにしています。）

こちらは実際に利用する環境に応じて必要なセットアップを行うと良いと思います!

entrypoint.sh
#!/bin/sh

# AWS認証情報の有効性をチェックしてログインしていなければログインする
if ! aws sts get-caller-identity &>/dev/null; then
    echo "AWS認証情報が無効または期限切れです。再ログインします。"
    aws sso login --profile my-profile --no-browser --use-device-code
else
    echo "有効なAWS認証情報が見つかりました。ログインをスキップします。"
fi

# プロンプトの表示形式を設定
export PS1="\u:\w\\$ "

# ログイン後の接続を維持するためにbashを起動
exec /bin/bash -l

利用時

あとは利用時に以下のコマンドを実行してコンテナを起動します。

docker compose run --rm sredocker

導入してみて

Dockerを利用した実行環境を導入した結果、以下のようなメリットを得ることができました！

1. 開発環境の統一

全メンバーが同一のツールバージョンで開発を行えるようになりました。「自分の環境では動くのに、いざ検証環境にリリースする際にエラーになる...」という事態が解消されました。これにより、バグの再現性が高まり、問題解決のスピードが向上しました。

2. 初期セットアップの簡略化

新しいメンバーが参画した際も、Dockerさえインストールされていれば、AWS SSOの初期設定だけであとはdocker composeで実行環境を利用できます。セットアップ手順書の準備やメンテ、実際の設定作業が不要になりました。オンボーディングの時間が大幅に短縮され、新メンバーがすぐに開発に参加できるようになりました。

3. プラットフォーム間の差異解消

チームでは全員Macユーザーなのですが、Linux環境で実行できるようになり、本番環境との挙動の差異を事前に確認できるようになりました。これにより、「本番でだけ発生する不具合」が減少しました。また、別件でLinux環境で試したいこともこの実行環境ですぐに試すことができとても便利に感じています。

4. 環境の分離と廃棄の容易さ

プロジェクトごとに独立した環境を持てるため、別プロジェクトとのバージョン競合が解消されました。また、不要になったらイメージを削除するだけで環境を綺麗に廃棄できます。これにより、メンバーが複数のプロジェクトに参加しても環境の衝突が起きなくなりました。

あとは、ローカルにツールをあまりインストールしたくない人も多いと思うので、それもメリットですね！（かくいう私もその一人です😇）

おわりに

Dockerを利用した実行環境の導入は、試行錯誤しながら作成しましたが、いざ運用してみると良いことばかりでかなりのメリットをチーム全体にもたらしてると思います。特に新メンバーのオンボーディングがスムーズになったことは、大きな効果だと感じています。

みなさまもチーム開発で環境の統一に課題を抱えている場合は、Dockerによる環境構築も一案として検討してみてください。

ツクリンク
ツクリンクPublication

Discussion