ssig33.com - Docker swarm モードでは全ノードをマネージャーにしたほうがよさそう
Docker swarm モードには Ingress というロードバランサ機構が存在しており、クラスタ内のどのマシンにアクセスしても上手いところ飛ばしてくれるみたいになってます。 が、実際にはこれがそんなに安定しているとは言い難く、自前での死活監視が必要、と昨日まで僕は考えていました。 ところが思い付きで全ノードをマネージャーに設定してみたところ嘘のように安定したので、そのようにするとよいと思いました。終わり。 Docker は未だにコンテナ側がホスト巻き込んで死滅するみたいなことがありえます。よって接続点としてマネージャーとしてのみ機能するノード(これは Drain にしておく)みたいのはそれはそれで置いておけばよいと思います。しかしとにかく全ノードをマネージャーにしたほうがネットワークが安定するのでよいです。 back to index of texts Site Search
ssig33.com - Docker swarm モードで service update は基本使わないほうがよさそう
よくないやり方 # サービスの作成 $ docker service create --name hogehoge -p 41311:80 fuckservice # イメージの更新 $ docker service update --image hogehoge:latest fuckservice # デプロイ先制約の追加 $ docker service update --constraints-add node.hoge==huga fuckservice よりよいやり方 # サービスの作成 $ docker service create --name hogehoge fuckservice # イメージの更新 $ docker service create hogehoge -p 41312:80 fuckservice_v2 そしてここでリバースプロキシの設定を切り替える #
ssig33.com - Docker swarm モードでのラベルの使用
Docker の swarm モードが何かについては Docker 1.12RC の swarm mode チュートリアル - Qiita を読んでおいてください。とにかくすごいやつです。ロードバランサがどうのとかそういうことを考える必要がほとんどなくなってすごいことになります。 ここで以下のようなサーバー群からなるクラスタがあるとします アメリカの糞みたいに遅い VPS にあるサーバー manager node1 node2 node3 日本のさくらインターネットにあるサーバー resource01 conoha にあるサーバー conoha1 conoha2 イタリアのよく分からない VPS にあるサーバー pizza sicilia ちなみにこれはぼくが今使っている swarm クラスタの実際の構成です。 たとえばここでアメリカの糞みたいに遅い VPS にのみデプロイしたいサービスが
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 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
ssig33.com - Jenkins で Rails アプリを docker build する話
Rails アプリを Docker で稼動させる際に、 Gemfile と Gemfile.lock を先に ADD して bundle install してからアプリケーション全体を ADD することで、 bundle install の結果をキャッシュする手法はよく知られています。 ADD Gemfile /app/Gemfile.lock ADD Gemfile /app/Gemfile WORKDIR /apps RUN bundle -j4 ADD . /app こういうやつ。 ところがこの手法は Jenkins のように毎回リポジトリが clean にチェックアウトされる環境では全く無効です。 何故なら、 Docker は ADD するファイルが更新されているかどうかを、ファイルの中身そのものではなく、タイムスタンプなどのメタデータで確認しているからです。 git checko
ssig33.com - Docker を個人が使う時の注意点
Docker が何かとかそういう話は全部抜きにして書きます。 Docker においてよくある運用は どっかにプライベートなレジストリを立てる ローカルかなんかでビルドしたコンテナをそこにプッシュする 実際の実行環境ではそれを pull してきて起動 という感じではないかと思います。 3. の後にリバースプロキシだのなんだのいろいろ設定しないといけませんから、それは各種自動化フレームワークが用いられます。 ここまではいいのですが、問題は 2 です。 Docker は 2 をやるごとにほぼフルの Linux 環境をネットワーク経由でアップロードするということになります。これが案外バカにならなくて、測定してみたところこの二週間でこれでのアップロードの合計は 350GB ほどになっていました。 もうちょっと激しくなるとプロバイダの設定する帯域規制だったり強制解約要件にひっかかってしまいますし、単純
ssig33.com - テレビ番組をノベルゲーム風にするものが強化された
以前テレビ番組をノベルゲーム風にするものを作ったことを紹介したが、これを強化した。 以前作成したものは、テレビ番組をノベルゲーム風に再生できるだけのものだったが、今回はそこで表示されている画像をクリックするとそこから動画を実際に再生できるようにした。 これによって 字幕をブラウザのページ内検索で検索し、気になる箇所やハイライトと思わしき箇所を再生する 字幕とキャプチャだけでは理解しづらい箇所があった場合に動画を併用して内容を確認する などの視聴行動が可能になった。 動画のハイライトを自動で選択して再生する仕組みは多々あるが、なんだかんだいって人間の判断力によってハイライトを選択するのが一番だと思う。人間は字幕とキャプチャがあれば十分にハイライトを高速に検索することが出来ると思う。 また字幕とキャプチャを読むことで高速に番組を確認する場合も、分かりづらい箇所は動画で内容を確認できるようになっ
ssig33.com - AWS Elastic Beanstalk メモ
最近ちょこちょこ触ってみて得られた知識。 Beanstalk 専用に AWS アカウントを作ったほうがよい 試行錯誤と共に膨大な量の Security Group が作られていって意味不明な事態になる Beanstalk に Environment を作る時に一緒に RDS を作らないほうがよい スワップしてデプロイするやつが使えなくなる。 正確には使えないわけではなくて、 RDS の設定をアプリケーションに直接記述すればよい。 RDS と紐づいていない Env からは環境変数が見えない。なので環境変数から設定読み込むやつが使えなくなる。なので一緒に RDS 作るのは意味がないし管理が複雑になる。 スワップしてデプロイするやつは初期に設定しておきましょう。 そうじゃないと上記のようなめんどくさいことが起きます。 Beanstalk はデプロイスクリプトの実行に 10 分かかるとデプロイを勝
ssig33.com - Docker 運用しまくって得られたしょぼい知識
よく知られているように Docker ではコンテナ自体は使い捨てで、アプリケーションが保持すべきデータはコンテナの外に格納する必要があります。 RDBMS 多くのアプリケーションが RDBMS を使用しています。 RDBMS の運用は実際のところかなり厄介ですが、まあ Amazon RDS を使っちゃいましょう。それが一番楽です。 EC2 じゃないところにサーバー置いてて RDS との通信量課金を払いたくないという場合は適宜頑張ってください。 Redis と memcached 現代の多くのアプリケーションが Redis や memcached を使っています。これも Amazon Web Services に ElastiCache があるので EC2 にサーバー置いてる場合はこれを使います。置いてない場合は適宜頑張ります。 その他 ここまでのことは特に何ということもないのですが、ここか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
