我编写了一些代码,用于遍历所有S3存储桶,并打印每个存储桶的帐户、名称和版本控制状态。这段代码在我昨天运行的时候没有出错。今天我发现了一个错误。除了将输出的.csv文件附加而不是重写之外,我根本没有更改代码。在
def main(access_key, access_secret):
session = boto3.Session(
aws_access_key_id=access_key,
aws_secret_access_key=access_secret,
)
s3resource = session.resource('s3')
account = session.client('iam').list_account_aliases()['AccountAliases'][0]
with open('Buckets with Versioning Enabled.csv', 'a') as output:
writer = csv.writer(output)
writer.writerow(['Account', 'Bucket', 'Versioning'])
for bucket in s3resource.buckets.all():
response = s3resource.BucketVersioning(bucket.name).status
if response is None:
versioning = "Disabled"
else:
versioning = response
print("Account: " + account + " | Bucket: " + bucket.name + " | Versioning: " + versioning)
writer.writerow([account, bucket.name, versioning])
有谁能告诉我为什么这段代码会有选择地抛出这样一个错误?此代码需要可靠地工作。由于必须检查bucket的数量,运行此代码需要很长时间,并且必须多次运行它,直到没有出现此错误为止,这将是令人沮丧的。以下是例外:
^{pr2}$
这有两个可能的原因,一个显而易见,一个不那么明显,直到你意识到S3是一个大规模的、全球分布的系统。在
如果在脚本获取列表后删除了一个bucket,这就是明显的原因。既然您说您运行脚本几次以避免错误,那么这可能不是这里的问题,但绝对要记住一些事情。在
另一种不太明显的情况是在脚本启动前几分钟删除了一个bucket。S3维护一个包含所有bucket名称的全局列表,并将该列表复制到所有区域。删除存储桶后,用于服务请求的索引副本可能还不知道该存储桶已不存在。在
我们有理由推测,在两种情况下,这种情况可能会变得更为可能或持续更长时间:最近删除的存储桶与您连接的存储桶位于不同的区域,而您连接的区域恰好不是us-east-1。这似乎很有可能,因为在幕后,us-east-1是权威bucket list的官方守护者,因此这两种情况中的一种或两种都可能会增加在实现全球一致性之前的延迟。(请注意,在2017年相对短暂的us-east-1大修期间,所有其他区域的S3几乎都能正常工作,但不可能在任何S3区域创建存储桶)。在
不管怎样,您都需要捕获异常并继续。在
相关问题 更多 >
编程相关推荐