このページでは、gsutil が boto 構成ファイルを使用する方法と、このファイルを使用して共同作業を行う例について説明します。boto 構成ファイルは、Amazon S3 SDK for Python である boto でも使用されます。
構成ファイルの概要
boto 構成ファイルには、gsutil の動作を制御する値が含まれています。たとえば、gsutil が優先的に使用する API を決定する prefer_api 変数などです。boto 構成ファイルの変数は、構成ファイルを直接編集することで変更できます。大半のユーザーはこれらの変数を編集する必要はありませんが、編集の必要が生じる主な理由には以下のようなものがあります。
- プロキシ経由で使用できるように gsutil を設定する。
- 顧客管理または顧客指定の暗号鍵を使用する。
- 独自の運用に合わせて gsutil の動作を全体的にカスタマイズする。
場所
boto 構成ファイルのデフォルトの場所は、Linux と macOS ではユーザーのホーム ディレクトリの ~/.boto、Windows では %HOMEDRIVE%%HOMEPATH% です。gsutil version -l コマンドを実行すると構成ファイルの場所を確認できます。
BOTO_CONFIG 環境変数を設定することで、gsutil が構成ファイルを参照する場所をオーバーライドできます。また、BOTO_PATH 環境変数を : 区切りのパス（Windows の場合は ;）で設定することで、読み込む boto 構成ファイルのパスを設定することもできます。たとえば、BOTO_PATH 環境変数を次のように設定します。
/etc/projects/my_group_project.boto.cfg:/home/mylogin/.boto
この場合、gsutil は、このパスにある構成ファイルを順番に読み込みます。これは、多くのユーザー間で共有する構成を設定する場合に便利です。このようなデータ共有と共同作業の例については、構成ファイルの使用例をご覧ください。
構造
構成ファイルには、[Credentials]、[Boto]、[GSUtil]、[OAuth2] という複数のセクションが含まれています。以下では、現在定義されている設定をセクション別に説明します。それぞれの用途は、boto 構成ファイル内の各設定の前にあるコメントに記載されています。
[Credentials] aws_access_key_id aws_secret_access_key gs_access_key_id gs_host gs_host_header gs_json_host gs_json_host_header gs_json_port gs_oauth2_refresh_token gs_port gs_secret_access_key gs_service_client_id gs_service_key_file gs_service_key_file_password s3_host s3_host_header s3_port [Boto] proxy proxy_type proxy_port proxy_user proxy_pass proxy_rdns http_socket_timeout ca_certificates_file https_validate_certificates debug max_retry_delay num_retries [GoogleCompute] service_account [GSUtil] check_hashes content_language decryption_key1 ... 100 default_api_version disable_analytics_prompt encryption_key json_api_version max_upload_compression_buffer_size parallel_composite_upload_component_size parallel_composite_upload_threshold sliced_object_download_component_size sliced_object_download_max_components sliced_object_download_threshold parallel_process_count parallel_thread_count gzip_compression_level prefer_api resumable_threshold resumable_tracker_dir (deprecated in 4.6, use state_dir) rsync_buffer_lines software_update_check_period state_dir tab_completion_time_logs tab_completion_timeout task_estimation_threshold test_cmd_regional_bucket_location test_notification_url use_magicfile test_hmac_service_account test_hmac_alt_service_account test_hmac_list_service_account [OAuth2] client_id client_secret oauth2_refresh_retries provider_authorization_uri provider_label provider_token_uri token_cache
ファイルを編集するときは、gs_access_key_id などの設定名を誤って編集しないように注意してください。また、[Credentials] などのセクション区切り文字は削除しないでください。
最新の構成ファイルへの更新
構成によって制御できる新機能は boto 構成ファイルに随時追加されますが、大半の gsutil ユーザーは最初に作成した構成ファイルを長く使い続けます。そのままだと、gsutil を新しいバージョンに更新しても新機能は利用できません。最新の設定とドキュメントを含む最新の構成ファイルを取得する場合は、現在のファイルの名前を変更し（.boto_old など）、gcloud init を、（または、従来のスタンドアロン バージョンの gustil を使用している場合は、-a フラグまたは -e フラグを指定した gsutil config）を実行し、保持したい構成設定を古いファイルから新しく作成したファイルに転送します。OAuth2 の認証情報を使用している場合には、OAuth2 設定プロセスを実行すると、前の OAuth2 認証情報が無効になります。
構成ファイルの使用例
次の例では、小規模な会社が社員向けのストレージ システムとして Cloud Storage を使用するケースについて説明します。IT 管理者は、Google Cloud コンソールでプロジェクトを作成し、社員ごとにバケットを作成します。社員が Cloud Storage を簡単に使えるように、プロキシ構成や並列複合アップロードのしきい値など、会社全体の設定を中央のファイルを保存し、社員が個々の BOTO 構成パスでそのファイルを参照できるようにします。これにより、各社員が構成の共有部分を手動で設定する必要がなくなり、管理者は必要に応じてこれらの共有構成を簡単に変更できるようになります。
これを実現するために、次の手順を実行します。
すべての社員が読み取ることのできる共有の boto 構成ファイルを作成します。
これを行うには、
gcloud initを使用します。boto 構成ファイルには、たとえば次の情報を入れることができます。
[Boto] proxy = yourproxy.com proxy_port = 8080 proxy_type = http [GSUtil] parallel_composite_upload_threshold = 150M
社員に Google Cloud CLI をインストールするよう指示します。
インストール中に、社員は会社が使用しているプロジェクト ID を指定する必要があります。また、社員は個々の認証情報を生成し、認証情報を中央で共有しないようにする必要があります。
BOTO_PATH 環境変数を追加する手順を社員に説明します。
BOTO_PATH 環境変数には、共有の構成ファイルのパスと社員のローカルの構成ファイルを順番に指定します。たとえば、共有の構成ファイルがディレクトリ
centralhub/にあり、ユーザーがjaneの場合、BOTO_PATH 環境変数は次のようになります。BOTO_PATH =/centralhub/boto.cfg:home/jane/.boto
社員が gsutil を実行すると、共有の boto ファイルで指定された構成を自動的に使用します。必要に応じて、管理者は共有の構成ファイル内のプロキシ設定、並列複合アップロードしきい値などの設定を変更し、共有の構成ファイルを使用してすべての社員にその設定を反映させることができます。