Organizations

@github @twitter @
2 results for s3
  • 最近言われて嬉しかった言葉は 「戦闘民族だよね。戦い生きるみたいな生き方をしている」 です。 精神的腕力のあるゴリラを目指している身としては身に余る言葉です。 なんか殺傷力高くて瞬発力ありそう。 media削除のコマンドを試す前に 「メディアストレージの容量を確認して、ビフォーアフター見てみたいなあ」 と、いうことで postgresqlが稼働しているdisk容量を確認するコマンドを調べたの。 $ df -Th dfコマンドにType付き&人に優しいhumanizeな表示で見ることができました。 /dev/xvda1 20G 13G 7.0G 65% / ふむふむ。 ラズパイも見てみました。 /dev/mmcblk0p1 vfat 253M 41M 213M 16% /boot mmcblk0p1で調べたらSDカードのパーティションとのこと。 ふん?? (下記サイトより引用) ふむふむ。 fdiskの操作方法 また、重要なのが「swap」パーティションだ。 このパーティションはメインメモリが不足しているときにメインメモリのかわりとして使用できる領域のことだ。 これは高価なメインメモリを安価な記憶媒体で補うと同時に、メインメモリ以上の容量を確保するため、比較的に昔からある仕組みだ。とても便利だし、設定しない理由はない。 やたらと大きくしてもパフォーマンスは発揮されないので注意しよう。 Linuxのパーティションとは?とパーティションの区切り方を詳細解説 https://eng-entrance.com/linux-partition パーティションの中でもswapって大事なんやなー swap領域を確保する一番手っ取り早い方法として、EC2のインスタンスストアスワップボリュームがあります。 これは、EC2のインスタンスタイプがm1.smallとc1.mediumのときのみ /dev/xvda3ないし/dev/xvde3という900MBのmkswap済みディスクが EC2のブート時に自動で提供されます(デバイス名はAMIによりまちまちです)。 他のインタンスタイプではm1/c1ファミリーであっても提供されず、 またManagement ConsoleやAWS APIでは本ボリュームを確認できないことに注意しましょう。 Amazon EC2(Linux)のswap領域ベストプラクティス | DevelopersIO https://dev.classmethod.jp/cloud/ec2linux-swap-bestpractice/ swapの設定しなきゃ!! してた!!! 全く記憶にないけど、とりあえずコピペ頑張ったんだなってきもちです。 $ sudo docker-compose run –rm web bundle exec bin/tootctl media remove –days=30
    docker linux s3 Created Mon, 02 Sep 2019 13:00:00 +0000
  • 最初はAWS日本語だしAWSの設定なら楽チン! とおもっていたけれども、これ日本語が意味不明だと突然 「何言ってるのかな??」 に、なるのつらい。 vimで設定ファイル編集するほうが 言われたとおり素直にコピペするだけなので ラクだなと思うようになってきた。 素直にコピペして動く場合であれば。 . パブリックアクセスのブロックは全解除でいけました。 公開しても良い画像で、ファイルをひとつ作ってみて それを投稿してerror出ないかテストしてみました。 . パケットポリシーエディタの中身は AWSのポリシージェネレーターでパパッと生成できた。 しかしジェネレーターの選択欄ものすごく種類あるので どれ選択したら良いのか初見わからないのでは… . で、メディアストレージの設定ファイルの編集なんですが 参考にしていたblogの内容の表記っていうのかな 若干違っていて どれが正しいのかわからないので 設定ファイルを書き直して Docker立ち上げ直して マストドンで画像投稿してみて Dockerのログみてerror探して というのを10回ほど繰り返し まだerror出ています。 うお〜〜〜〜〜〜 アプリ開発の動画みて気分転換しよ🙋 また明日がんばります。 . でもねでもね 最初の頃はerrorの特定も全くわからなかったの。 最近は、だんだん流れがわかってきたの嬉しい。 こういうリズムで、こういう順序で こういう角度からerrorの原因を潰していくのかあ って、少しずつ見えてきた。 メディアストレージのerrorちっともわからんけども‪ᐠ( ᐛ )ᐟ笑 まじでわからん
    aws mastodon s3 Created Thu, 27 Jun 2019 13:00:08 +0000