ssig33.com - docker ホストを長期間運用する際の注意点
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
ssig33.com - よく分からない人のためのセキュリティ
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
ssig33.com - Docker を個人が使う時の注意点
Docker が何かとかそういう話は全部抜きにして書きます。 Docker においてよくある運用は どっかにプライベートなレジストリを立てる ローカルかなんかでビルドしたコンテナをそこにプッシュする 実際の実行環境ではそれを pull してきて起動 という感じではないかと思います。 3. の後にリバースプロキシだのなんだのいろいろ設定しないといけませんから、それは各種自動化フレームワークが用いられます。 ここまではいいのですが、問題は 2 です。 Docker は 2 をやるごとにほぼフルの Linux 環境をネットワーク経由でアップロードするということになります。これが案外バカにならなくて、測定してみたところこの二週間でこれでのアップロードの合計は 350GB ほどになっていました。 もうちょっと激しくなるとプロバイダの設定する帯域規制だったり強制解約要件にひっかかってしまいますし、単純
%E8%87%AA%E5%AE%85%E3%81%A7%E5%A4%A7%E5%AE%B9%E9%87%8F%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%82%92%E9%81%8B%E7%94%A8%E3%81%99%E3%82%8B
前回 RAID に関するちょっとした話を書きましたが個人が巨大なストレージを運用するにあたって得られたノウハウをだいたい全部書いておきます。 そもそもメリットあるのか？ メリットはあります。金です。 Google Drive は安いですが、それでも 1TB 月 1000 円です。しかし運用にかなり制限がでます。柔軟に使える Amazon Web Service ならその 3 倍+転送量課金です。 16TB だと月 5 万円もかかってしまいます。ちなみにもっとも柔軟に使える EBS だと 16TB で 83000 円ぐらいです。 Google Compute Engine の低冗長性ストレージは S3 より少し安かった気はするけど別にとても安いわけではなかったと思う(よく覚えていないし調べるのがめんどくさい)。 50TB のストレージを Google Drive でごまかしごまかし運用したと
ssig33.com - Docker 運用しまくって得られたしょぼい知識
よく知られているように Docker ではコンテナ自体は使い捨てで、アプリケーションが保持すべきデータはコンテナの外に格納する必要があります。 RDBMS 多くのアプリケーションが RDBMS を使用しています。 RDBMS の運用は実際のところかなり厄介ですが、まあ Amazon RDS を使っちゃいましょう。それが一番楽です。 EC2 じゃないところにサーバー置いてて RDS との通信量課金を払いたくないという場合は適宜頑張ってください。 Redis と memcached 現代の多くのアプリケーションが Redis や memcached を使っています。これも Amazon Web Services に ElastiCache があるので EC2 にサーバー置いてる場合はこれを使います。置いてない場合は適宜頑張ります。 その他 ここまでのことは特に何ということもないのですが、ここか
ssig33.com - Ruby On Rails でサブドメインを使った Web サイトを作る
という地獄の話です。 基本的な部分 # config/initializers/session_store.rb Hogehoge::Application.config.session_store :cookie_store, domain: ".#{ENV['DOMAIN']}", key: '_hogehoghoge' というような感じにする。アプリを起動する時に環境変数でドメインを指定する。 .#{ドメイン} と cookie のドメインを指定しておくことでサブドメインでもクッキー共有できるようにする。クッキー共有したくないならこうしない。 ./bin/rails server とかを使うなら、この場合 localhost としてアプリが起動するのだから、 DOMAIN=localhost ./bin/rails server とかする。 hoge.localhost とかで名前解
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
