はじめに
2025/8/25に国立研究開発法人理化学研究所様における Google Cloud を利用した Nextflow 実行環境の導入事例が公開されました。
アイレットはインフラ構築について支援させていただきました。
当該記事はインフラ構築の裏側について解説する記事となります。
今回は Cloud Workstations におけるカスタムコンテナ構築 に関する内容となります。
事例に関連する記事はこちら：
概要
Google Cloud 上で nextflow を動作させたい要望があり、研究者様が自分で構成せずともデフォルトで必要なアプリケーションがインストールされた状態で利用可能にする必要がありました。今回は Cloud Workstations 上で2つの観点でのコンテナのカスタマイズについてご紹介します。
2つの観点でのカスタムコンテナ
必要なパッケージを導入する観点のカスタム
Cloud Workstations を作成する際にデフォルトで準備されたベースイメージを選択することが可能ですが、それでは上記している必要なアプリケーションが導入された状態ではございませんので、コンテナイメージに自由にパッケージを導入したイメージを選択して、Cloud Workstations を作成しています。
基本イメージ構成及び新たなパッケージ導入
事前構成済みのベースイメージのリストについては事前構成済みのベースイメージを参照ください。こちらの中の us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest がデフォルトでは利用することが可能です。今回はベースに含まれる Code-OSS を利用する必要はあるため、それらの基本的な機能は維持しつつ、新たに nextflow を利用する必要があり、ベースイメージに nextflow をインストールしたコンテナイメージを Artifact Registry に準備しました。
ユーザ制御する観点のカスタム
同じ環境で複数人が扱ったり、管理者が開発者に対して、root 権限を使わせたくないケースや、ユーザを変更したいような場合もあるかと思いますが、そういったケースに合わせたカスタムすることが可能です。
必要なユーザの追加や sudo root 権限のオフする観点のカスタム
コンテナイメージのカスタマイズについてはこちらに詳細記載されております。今回定はリンク内の以下2つの項目を利用した設定を行っております。
- sudo root 権限をオフにする
- ユーザーの作成と変更
ベースイメージの構造の理解
コンテナカスタマイズの内容として、ユーザ追加やデフォルトでのファイル配置をコントロールしたい場合、以下2点必要となります。詳細はこちらを参照ください。
- Cloud Workstations を起動すると、GCE が動作しますが、GCE 上では home ディレクトリが永続ディスクでマウントされてしまうため、Dockerfile 内でユーザ関連の内容や home ディレクトへのファイル配置を行っても、Cloud Workstations 起動後は、その内容は反映されません。
- 起動時にベースイメージは
/etc/workstation-startup.d/*に配置されたスクリプトを順次実施するので、ユーザを新たに追加する場合はユーザ追加スクリプトを配置し、既存のユーザを変更したい場合はスクリプトに変更内容を含める必要があります。
ユーザ追加するには
上記の内容から例えば以下のようなスクリプトを /etc/workstation-startup.d/ に配置します。
#!/bin/bash
###
GROUPSOTHER=docker,users
USERNAME=hsaito
###
# ユーザーが存在するか確認
if ! id -u "$USERNAME" > /dev/null 2>&1; then
# ユーザーが存在しない場合は作成
useradd -m $USERNAME -G $GROUPSOTHER --shell /bin/bash > /dev/null
passwd -d $USERNAME >/dev/null
echo "ユーザー $USERNAME を作成しました"
else
echo "ユーザー $USERNAME はすでに存在します"
fi
このように行うことで起動時に Cloud Workstations 上でユーザが作られます。仮に Cloud Workstations を停止した場合、対象ユーザの home ディレクトリ自体は永続ディスクにあるため残りますが、作成されたユーザ自体はブートディスク上で記録されており、Cloud Workstations の仕様で停止ごとにブートディスクは削除されてしまうため、配置したスクリプトが起動時に再度動作しユーザが作成される形になります。
纏め
Cloud Workstations のカスタマイズについて一例を用いてご紹介しました。カスタマイズが必要な場合には、記載したコンテナ イメージをカスタマイズするを参照し、コンテナ作成時に Dockerfile 内でできること、起動時のスクリプトにて行わなければならないことを理解し、構築することでスムーズに開発環境の作成が可能になると思います。なお、記載したようなパッケージをカスタムで新たに導入されるような場合、追加分のパッケージは自動更新されませんので、インターネットからアクセスされるような環境であったりする場合、パッケージの更新などの配慮が必要となります。
簡単30秒