ssig33.com - Docker で Go で作ったバイナリを実行するなるべく小さいコンテナを作る
Go でアプリケーションを作ると、そのまま他になにもなくとも実行できるバイナリが出来あがります。この特性によりデプロイが大変楽です。 このような特性があるので、 Go を使う場合 Docker のようなオーケストレーションツールを使わなくても多くのサーバーにアプリをデプロイしていくことも可能かと思われますが、そこはまあ Docker という巨人に乗っておくと楽なことが多いです。具体的には swarm と docker-compose が便利なので Docker 上で実行したい。 ここで問題となってくるのが何も考えずに Docker イメージを作るとイメージサイズが膨れあがってしまってシングルバイナリによる手軽さなどが損なわれてしまうという点です。 たとえば golang:alpine のような比較的小さいイメージを使ってもファイルサイズはバイナリサイズ + 300MB ほどにもなってしまい
ssig33.com - docker ホストを長期間運用する際の注意点
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
高密度小池 ／ KVS を使って Web アプリケーションを作ることについて
KVS を使って Web アプリケーションを作ることについて KVS を使って Web アプリケーションについて、一般論。 従来 KVS は、キャッシュや特に更新が激しいデータを保存することに主に用いられて、メインのストレージには RDBMS を使うことが多かったけど、 KVS をメインのストレージとするアプローチも最近いくつかある。 KVS にデータを保存するという場合、 Value にシリアライズしたデータをぶちこむというケースが多いのではなかろうか。そうすると、標準状態では、キーでしか検索出来ないので、インデックスを転置するということになる。 インデックスの転置先としては、 Facebook や SimpleResource でやっているように、 RDBMS に転置するというやり方や、 Cassandra 採用前の Twitter のように KVS に転置するというやり方があ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
