Dockerで未使用オブジェクトを消す「prune」オプションの整理 - Qiita
概要 Docker で不要なものを消すガベージコレクション（garbage collection ）は、prune 系のオプションを使う。 prune 系オプションを使うと、使っていない Docker オブジェクト（コンテナ、イメージ、ネットワーク、ボリューム）をまとめて削除できる。コンテナが停止してからの時間を指定できる --filter "until=24h" の指定で、更に活用しやすくなる。あるいは --filter "until=2020-06-01" のように、日時の指定も可能。 なお「prune」の意味とは、不要なものや余分なものを、削る、刈り取る、取り除くといったもの。 停止して24時間経過したコンテナと、使っていないイメージおよびネットワークを消す $ docker system prune -a --filter "until=24h" ... Are you sure
AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!
はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント（ルートユーザー）の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ
Scalaにおける細かい最適化のプラクティス - xuwei-k's blog
列挙順自体はとくに意味ありません。あと「どの最適化がどのくらい速くなるのか？」を詳細に計ったことはないですし、「原理的にこうなってるから(ry」というのを説明するに過ぎません。中には「JITで無意味になるようなどうでもいい細かすぎること」も書いてありますし、最適化のトレードオフとして失うものもあるので、そのあたり自己責任でお願いします。本当に最適化が必要とされる場合は、以下のものを無闇に実行するよりまず計測したほうがいいのは、言うまでもありません。*1 1. private[this]をつかえ scalaのvalやvarは、private[this]にしたときのみ、直接のフィールドアクセスになります(それ以外ではメソッド呼び出し)。シングルトンのobjectの場合も同様です。private[this]をつけられる場合はできるだけつけましょう 2. なんでもかんでもListをつかうな 最初の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Vagrant + CoreOS + Docker でコンテナ環境体験 - Qiita
