Dockerコンテナを本番環境で使うためのセキュリティ設定 - Qiita
はじめに Dockerを開発環境で使うことが多くなってきてますね。 使い捨てできる環境は本当に便利なので、本番環境にも使いたいなーと思って、本番運用で注意すべきセキュリティ周りを調べてみました。 基本的な考え方 基本的な考え方は以下になります。 コンテナ内部に入られるな 権限は最小限にせよ 監視を怠るな DockerといえどVPSやオンプレのセキュリティ設定と考え方は同じですね。 ここではDockerにまつわる話を書いていきます。 コンテナ内部に入られるな 信頼できるイメージを使う 多くの場合、ベースとなるピュアなOSイメージはDockerHub上のイメージを使いますが、元となるイメージがセキュアであるかどうかを確認して使うようにしましょう。 既知の脆弱性を含んでいる場合や、最悪の場合、悪意のあるスクリプトが仕込まれている場合があります。 既知の脆弱性が含まれているかどうかはDocker
dockerのlog周りの対応 - Carpe Diem
概要 dockerを本番運用する際にログの扱いに悩んだので情報をまとめてみました。 環境 docker v1.12.1 コンテナのログは何処に渡すべきか 主に以下の３通りになると思います。 コンテナ内に保存 volume先に指定してに永続保存 log driverを使って転送 a. コンテナ内に保存 何も設定しないとコンテナに保持されます。 メリット 何も設定しなくていい デメリット 当然コンテナが破棄された場合はログファイルがなくなります。 b. volume先に指定してに永続保存 volumeを用いてホストに永続的に保存します。 参照が切れないように-v <host_path>:<container_path>とするか、--volumes-from <container_name>でデータ用コンテナに保持してください。 メリット コンテナを破棄したとしてもvolumeでそこを指定すれば
Mastodonインスタンスを閉じる時にやった方がいいこと（案） - Qiita
こうした方がいいんじゃないかな？ 立つ鳥跡を濁さず。 極力、ほかのインスタンスに迷惑をかけず去りたいものですね。 実行すると復元できないコードが含まれます。自己責任にてご使用ください。 閉じる時に行った方がよいこと 広報 自インスタンスのユーザに対してはもちろんのこと、 繋がっているインスタンスのユーザ、管理者にお知らせして、対処をお願いしましょう。 自インスタンスのユーザを他の（似たようなコンセプトの）インスタンスへ誘導することも必要かもしれません。 tootctl self-destruct の実行 これを実行すると、接続されているサーバーに対して、ローカルの全ユーザーのaccount deleteアクティビティが送信されます。 Sidekiqに積まれます。 サーバーのデータ消去 tootctl self-destruct を流し終わったら、データベース、メディアファイル、DNSなどを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
