이 페이지에서는 gsutil에서 boto 구성 파일이 사용되는 방법을 설명하고 이 파일을 사용하는 공동작업 예시를 제공합니다. boto 구성 파일은 Python용 Amazon S3 SDK인 boto에서도 사용됩니다.
구성 파일 개요
Boto 구성 파일에는 gsutil의 동작을 제어하는 값이 포함되어 있습니다. 예를 들어 prefer_api 변수는 우선적으로 사용하는 API gsutil을 결정합니다. 구성 파일을 직접 수정하여 Boto 구성 파일 변수를 변경할 수 있습니다. 대부분의 사용자는 이러한 변수를 수정할 필요가 없지만, 일반적으로 다음과 같은 이유로 수정합니다.
boto 구성 파일의 기본 위치는 Linux 및 macOS의 경우 사용자 홈 디렉터리인 ~/.boto이고, Windows의 경우 %HOMEDRIVE%%HOMEPATH%입니다. gsutil version -l 명령어를 실행하여 구성 파일의 위치를 확인할 수 있습니다.
BOTO_CONFIG 환경 변수를 설정하여 gsutil에서 구성 파일을 찾을 위치를 재정의할 수 있습니다. 또한 : 구분 경로(Windows의 경우 ;)를 사용해 BOTO_PATH 환경 변수를 설정하여 로드할 boto 구성 파일의 경로를 설정할 수 있습니다. 예를 들어 BOTO_PATH 환경 변수를 다음과 같이 설정합니다.
파일을 수정할 때 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 구성 경로에서 지정할 수 있는 중앙 파일에 생성하고 저장합니다. 그러면 각 직원이 구성의 공유 부분을 수동으로 설정하지 않아도 되며, 관리자는 필요에 따라 이러한 공유 구성을 쉽게 변경할 수 있습니다.
설치 중에 직원은 회사에서 사용하는 프로젝트 ID를 지정해야 합니다. 또한 사용자 인증 정보를 중앙에서 공유할 수 없으므로 개별 인증 사용자 인증 정보를 생성해야 합니다.
직원이 BOTO_PATH 환경 변수를 추가하도록 합니다.
BOTO_PATH 환경 변수는 중앙에 위치한 구성 파일의 경로를 나열한 다음 직원의 로컬 구성 파일을 나열합니다. 예를 들어 중앙 구성 파일이 centralhub/ 디렉터리에 위치한 경우 jane 사용자를 위한 BOTO_PATH 환경 변수가 다음과 같을 수 있습니다.
BOTO_PATH =/centralhub/boto.cfg:home/jane/.boto
직원은 gsutil을 실행할 때 중앙 boto 파일에 지정된 구성을 자동으로 사용하게 됩니다. 필요한 경우, 관리자는 중앙 구성 파일에서 프록시 설정, 동시 복합 업로드 기준, 기타 설정을 변경하고 중앙 구성 파일을 사용하여 변경 내용을 모든 직원에게 반영할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Boto configuration file\n\n| **Important:** gsutil is not the recommended CLI for Cloud Storage. [Use\n| `gcloud storage`](/storage/docs/discover-object-storage-gcloud) commands in the Google Cloud CLI instead.\n\nThis page describes how gsutil uses a boto configuration file and provides\na collaboration example that uses the file. The boto configuration file is\nalso used by boto, which is the Amazon S3 SDK for Python.\n| **Note:** boto3 is not supported with gsutil.\n\nConfiguration file overview\n---------------------------\n\nThe boto configuration file contains values that control how gsutil behaves. For\nexample, the `prefer_api` variable determines which API gsutil preferentially\nuses. Boto configuration file variables can be changed by editing the\nconfiguration file directly. While most users won't need to edit these\nvariables, those do typically do so for one of the following reasons:\n\n- Setting up gsutil to work through a proxy.\n- Using [customer-managed or customer-supplied encryption keys](/storage/docs/encryption).\n- Performing specialized customization of global gsutil behavior.\n\n### Location\n\nThe default location for the boto configuration file is in the user home\ndirectory, \\~/.boto, for Linux and macOS, and in %HOMEDRIVE%%HOMEPATH%,\nfor Windows. You can get the location of the configuration file by running\nthe command `gsutil version -l`.\n\nYou can override where gsutil expects to find the config file by setting the\n`BOTO_CONFIG` environment variable. You can also set up a path of boto\nconfiguration files to load by setting the `BOTO_PATH` environment variable\nusing a `:` delimited path (or `;` for Windows). For example, setting the\n`BOTO_PATH` environment variable to: \n\n```\n/etc/projects/my_group_project.boto.cfg:/home/mylogin/.boto\n```\n\ncauses gsutil to load each configuration file found in the path in order.\nThis is useful if you want to set up some shared configuration state among many\nusers. See the [example of using the configuration file](#example) for such a\ndata sharing and collaboration scenario.\n\n### Structure\n\nThe configuration file contains a number of sections: `[Credentials]`, `[Boto]`,\n`[GSUtil]`, and `[OAuth2]`. The following are the currently defined\nconfiguration settings, broken down by section. Their use is documented in the\nboto configuration file itself, in comments preceding each setting: \n\n```\n[Credentials]\n aws_access_key_id\n aws_secret_access_key\n gs_access_key_id\n gs_host\n gs_host_header\n gs_json_host\n gs_json_host_header\n gs_json_port\n gs_oauth2_refresh_token\n gs_port\n gs_secret_access_key\n gs_service_client_id\n gs_service_key_file\n gs_service_key_file_password\n s3_host\n s3_host_header\n s3_port\n\n[Boto]\n proxy\n proxy_type\n proxy_port\n proxy_user\n proxy_pass\n proxy_rdns\n http_socket_timeout\n ca_certificates_file\n https_validate_certificates\n debug\n max_retry_delay\n num_retries\n\n[GoogleCompute]\n service_account\n\n[GSUtil]\n check_hashes\n content_language\n decryption_key1 ... 100\n default_api_version\n disable_analytics_prompt\n encryption_key\n json_api_version\n max_upload_compression_buffer_size\n parallel_composite_upload_component_size\n parallel_composite_upload_threshold\n sliced_object_download_component_size\n sliced_object_download_max_components\n sliced_object_download_threshold\n parallel_process_count\n parallel_thread_count\n gzip_compression_level\n prefer_api\n resumable_threshold\n resumable_tracker_dir (deprecated in 4.6, use state_dir)\n rsync_buffer_lines\n software_update_check_period\n state_dir\n tab_completion_time_logs\n tab_completion_timeout\n task_estimation_threshold\n test_cmd_regional_bucket_location\n test_notification_url\n use_magicfile\n test_hmac_service_account\n test_hmac_alt_service_account\n test_hmac_list_service_account\n\n[OAuth2]\n client_id\n client_secret\n oauth2_refresh_retries\n provider_authorization_uri\n provider_label\n provider_token_uri\n token_cache\n```\n\nWhen you edit the file, be careful not to mis-edit any of the setting names,\nsuch as `gs_access_key_id`, and don't remove the section delimiters, such as\n`[Credentials]`.\n\n### Updating to the latest configuration file\n\nNew configuration controllable features are added to the boto configuration file\nover time, but most gsutil users create a configuration file once and then\nkeep it for a long time. This means that new features aren't apparent when you\nupdate to a newer version of gsutil. If you want to get the latest configuration\nfile, which includes the latest settings and documentation, rename your current\nfile (e.g., to `.boto_old`), run `gcloud init` (or if using a legacy stand-alone\nversion of gustil, `gsutil config` with the `-a` or `-e` flags), and then\ntransfer any configuration settings you want to keep from your old file into the\nnewly created file. Note, however, that if you're using OAuth2 credentials and\nyou go back through the OAuth2 configuration process, doing so invalidates your\nprevious OAuth2 credentials.\n\nExample using the configuration file\n------------------------------------\n\nIn this example, a small company wants to use Cloud Storage as a storage\nsystem for their employees. As the IT administrator, you create a project in the\nGoogle Cloud console and create buckets for each employee. To make it easier\nfor employees to use Cloud Storage, you want to create and store\ncompany-wide settings, such as a proxy configuration and parallel composite\nupload thresholds, in a central file that employees can point to in their BOTO\nconfiguration path. This eliminates the need for each employee to set the\nshared parts of the configuration manually and allows you, as the administrator,\nto easily change these shared configurations if necessary.\n\nTo accomplish this, perform the following steps:\n\n1. **Create a central boto configuration file that is readable by all employees.**\n\n This can be done by using `gcloud init`.\n\n The boto configuration file might contain, for example: \n\n ```\n [Boto]\n proxy = yourproxy.com\n proxy_port = 8080\n proxy_type = http\n \n [GSUtil]\n parallel_composite_upload_threshold = 150M\n ```\n | **Note:** `socks4` and `socks5` proxies are also supported for `proxy_type`.\n2. **Instruct employees to [install the Google Cloud CLI](/storage/docs/gsutil_install#sdk-install).**\n\n During installation, employees need to specify the project ID that the\n company is using. They also need to [generate individual authentication credentials](/storage/docs/gsutil_install#authenticate)\n because you should never share authentication credentials centrally.\n3. **Instruct employees to add a BOTO_PATH environment variable.**\n\n The BOTO_PATH environment variable lists the path of the centrally located\n configuration file, followed by the employee's local configuration file. For\n example, if the central configuration file is located in the directory\n `centralhub/`, then for user `jane`, the BOTO_PATH environment variable\n might be: \n\n ```\n BOTO_PATH =/centralhub/boto.cfg:home/jane/.boto\n ```\n\nWhen employees run gsutil, they will automatically use the configuration\nspecified in the central boto file. If necessary, the administrator can change\nthe proxy settings, parallel composite upload threshold, and other settings\nin the central configuration file and have the changes reflected for all\nemployees using the central configuration file."]]
