他の言語では部分一致になることが多いと思うが。。 部分一致にしたい場合はre.searchを使う。
参考：
boto3のlist_objects_v2は最大1000オブジェクトまでしか取得出来ない
1001以上取得したい場合はループを回す必要がある。例は以下。
def list_all_contents(self, prefix: str = ''): next_token = '' base_kwargs = { 'Bucket': self.bucket_name, 'Prefix': prefix, } all_contents: List[dict] = [] while next_token is not None: kwargs = base_kwargs.copy() if next_token != '': kwargs.update({'ContinuationToken': next_token}) objs = self.bucket.meta.client.list_objects_v2(**kwargs) all_contents.extend(objs.get('Contents')) next_token = objs.get('NextContinuationToken') return all_contents
参考：
pythonでメソッドの実引数に**を付けるとdictを展開してくれる
これ知らなかった。。コードを見た方がわかりやすいと思う。例は以下。
>>> def parrot(voltage, state='a stiff', action='voom'):
... print("-- This parrot wouldn't", action, end=' ')
... print("if you put", voltage, "volts through it.", end=' ')
... print("E's", state, "!")
...
>>> d = {"voltage": "four million", "state": "bleedin' demised", "action": "VOOM"}
>>> parrot(**d)
参考：
AWS CLIを使ってS3からファイルをダウンロードすると途中から速度が落ちる
現象は以下。
- インスタンスタイプはg4dn.xlarge
- 同じリージョンのS3バケットからEBS gp2にダウンロードする
- aws s3 cpコマンドで実行
このとき、 最初：210MB/s⇒5GBぐらいから速度が下がり始める⇒10GBを越える頃には150MB/sぐらい のように速度が変化する。
インスタンスタイプをg4dn.2xlargeにすると、 最初：240MB/s⇒9GBぐらいから速度が下がり始める⇒14GBを越える頃には220MB/sぐらい のようになる。
原因ははっきりしないが、EC2⇒EBS間の転送速度がS3⇒EC2よりも低いためそこで詰まっているのでは無いか？という気がする（最初早いのはバッファを使っているためでは。）
大きいファイルをダウンロードしてくるときは注意。
特定のVPCからの通信のみ権限を与えるポリシー
以下のようにVPCエンドポイント指定で権限を付けられる。
{
"Version": "2012-10-17",
"Id": "Policy1415115909152",
"Statement": [
{
"Sid": "Access-to-specific-VPCE-only",
"Principal": "*",
"Action": "s3:*",
"Effect": "Deny",
"Resource": ["arn:aws:s3:::examplebucket",
"arn:aws:s3:::examplebucket/*"],
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1a2b3c4d"
}
}
}
]
}
VPC IDで指定もできる。
{
"Version": "2012-10-17",
"Id": "Policy1415115909153",
"Statement": [
{
"Sid": "Access-to-specific-VPC-only",
"Principal": "*",
"Action": "s3:*",
"Effect": "Deny",
"Resource": ["arn:aws:s3:::examplebucket",
"arn:aws:s3:::examplebucket/*"],
"Condition": {
"StringNotEquals": {
"aws:sourceVpc": "vpc-111bbb22"
}
}
}
]
}
参考：
JetBrains系IDEの.imlファイルに差分が出て困る問題
.imlファイルはコミットしてチームで共有することが推奨されているのでコミットしているが、 この中にコンパイラ・インタープリタの設定も入っていてその名前が人によって自由に決められるので そこで差分が出て困る。。
以下で「インタープリタの名前をPython3のような一般的な名前にしてみんなその名前にすることで差分を無くす」という方法が紹介されていたのでそれに倣うことに↓。 https://youtrack.jetbrains.com/issue/PY-24060
インタープリタの名前はimlに入れないでほしかったな。。
AutoScaling時にOutOfMemoryError発生時のヒープダンプを回収する
AutoScalingしている時にOOMが発生するとサーバが落ちてAutoScalingGroupがサーバを消す。 なので、-XX:+HeapDumpOnOutOfMemoryError JVMオプションを設定していてもヒープダンプファイルがEBSもろとも消えてしまう。
消える前にS3にアップロードさせたいが、S3へのアップロードは時間がかかるので終わる前に消されそう。（消すのをちょっと待つ設定も出来るが、そんなに長くは待てない） EC2が消えてもEBSは消えない設定にすると、AutoScalingでインスタンスが消えたり増えたりを繰り返すといらないEBSがどんどんたまっていき、 それを消す運用が必要になってめんどくさい。。
今回は結局出さないようにしたけど、ダンプを出すのが必須の場合は大変だろうな。。
