概要 dockerを本番運用する際にログの扱いに悩んだので情報をまとめてみました。 環境 docker v1.12.1 コンテナのログは何処に渡すべきか 主に以下の3通りになると思います。 コンテナ内に保存 volume先に指定してに永続保存 log driverを使って転送 a. コンテナ内に保存 何も設定しないとコンテナに保持されます。 メリット 何も設定しなくていい デメリット 当然コンテナが破棄された場合はログファイルがなくなります。 b. volume先に指定してに永続保存 volumeを用いてホストに永続的に保存します。 参照が切れないように-v <host_path>:<container_path>とするか、--volumes-from <container_name>でデータ用コンテナに保持してください。 メリット コンテナを破棄したとしてもvolumeでそこを指定すれば
7/16 hidekuroサンからのコメントを受けて修正 Dockerのコンテナで動作中のシェルへの接続方法 sshdをコンテナ内に立てることなしにシェルに接続する方法として以下の2つがある。 docker attach コンテナ名 docker exec -it コンテナ名 /bin/bash じゃあ、この2つの違いってなによ? ということで整理してみた。 docker attach コンテナ名 こっちは単純にdockerコンテナ内で既に起動しているシェルの標準出力につなげるイメージ?? コンテナで起動しているPID=1のプロセスの標準入出力(STDIN/STDOUT)に接続(attach)する。 docker exec -it コンテナ名 /bin/bash こっちはdockerコンテナで任意のコマンドを実行させる。 -itオプションについては意味合いは以下の通りらしい オプション名
開発環境と運用環境の差異 Railsアプリの開発をMacでしている人は多いと思います。しかし本番では大抵Linuxマシンで運用するため、実行環境の違いから問題が発生することがあります。特にサードパーティ製ライブラリやツールを使う場合、MacとLinuxで同じ動作をする保証はどこにもありません。また、開発にLinuxマシンを使っていたとしても、本番と全く同じ構成で開発するのは難しいでしょう。 Dockerを使うと開発から運用まで同じ環境を使え、しかもハードウェア仮想化よりも遥かに軽量です。そこで、私が今KRAYで担当しているプロジェクトでは開発から本番まで全ての環境でDockerを使えるようにしました。 それぞれの環境で解決すべき課題がありましたが、今日は本番環境にデプロイする仕組みを紹介します(KRAYでインテグレーション環境と呼ばれる環境についてはDockerホストをプロジェクトや権限で
概要 DockerでRails5のAPIモードの開発用環境構築です。 Rails5の中身などについては触れません。 今回作る環境 DBにMySQLを使い、フロントサーバにNginxとUnicornを使います。 必要な環境 macOSXを対象としています。(Windowsでも動くと思いますが、未確認です。) 下記の環境を想定しています。 docker 1.12.0 docker-compose 1.8.0 Rails5 ruby 2.3 フォルダ構成 フォルダ構成は説明を簡単にするため、Docker関連をRailsアプリのルート直下に置くことにします。 Railsアプリのルート |- app/ |- config/ |- Gemfile ~ |- docker/ |- nginx/ |- Dockerfile |- docker-compose.yml
※ Docker, boot2dockerなどの基本はご自身でお調べ下さい。 ※ Docker Toolbox をインストールして下さい。以下すべての作業はDocker Quickstart Terminalで行っています。 構成 こちらの構成を再現しました。 (参考にした記事はEC2インスタンス上に直接構築していますが、今回はMac上のboot2dockerインスタンス上に構築したので、ちょこちょこと詰まることがありました。) MacでのDockerの構造については主題とは関連が薄いので割愛しますが、調べてみると良いかと思います。 昔はいろいろ問題があったようです。 さておき、ホスト上に4つのコンテナを構築します ・data: このコンテナーを介してデータやソケットの共有、ホストのファイルの共有などを行う ・app: RubyやRails、unicornが動作するコンテナー ・mysql
Docker は Dockerfile から命令を読み込み、自動的にイメージをビルドできます。 Dockerfile はテキストファイルであり、イメージを作り上げるために実行するコマンドライン命令を、すべてこのファイルに含められます。 docker build を実行すると、順次コマンドライン命令を自動化した処理を行い、ビルド結果となるイメージが得られます。 このページでは、 Dockerfile で利用可能なコマンドを説明します。このページを読み終えたら、 Dockerfile の ベストプラクティス を開き、理解を重視するガイドをご覧ください。 使用法¶ docker build コマンドは、 Dockerfile と コンテキスト(context) からイメージを 構築(build) (ビルド)します。構築におけるコンテキストとは、指定された PATH (場所)または URL にある
こんにちは。CTOの馬場です。 最近利用する機会が増えてきたdockerネタです。 nginxを動かすときのTipsを3つ紹介します。 foregroudで起動する dockerではコマンドをforegroundで動かさないとコンテナが停止してしまいます。 nginxはデフォルトはデーモンとして動くので、foregroundで動くように設定しましょう。 nginx.confで設定するならこうです。 daemon off; Dockerfileの起動コマンドで指定するならこうです。 CMD ["/usr/sbin/nginx", "-g", "daemon off;"] 動的な設定を外部化する イメージの中に設定値を入れちゃうのはダサいですよね。 コンテナ起動時に動的に設定したいものです。 dockerの場合は docker run 時に -e で環境変数を指定できるので使いましょう。 do
はじめに そもそもソケット使った方が動作速度が速い。 参考: http://qiita.com/ma2shita/items/6f1905847b2059f7cf7d NginxとRailsが同一サーバにある構成だしソケット使いたい。 構成 DockerのVOLUME機能を利用する。 Rails動作用コンテナでUnicornを起動して、ソケットがあるディレクトリにVOLUMEを作成する。 Nginx用コンテナ起動時に作成したVOLUMEを付けることで、Ngnixからソケットにアクセスできるようにする。 Railsアプリの作成 $ rails new blog --skip-bundle $ vi blog/Gemfile source 'https://rubygems.org' gem 'rails', '4.2.5' gem 'sqlite3' gem 'unicorn' rails_
目次 なぜDockerfileを使うのか? ADDとDockerfileにおいてのコンテキストを理解する CMDでコンテナをバイナリのように扱う CMDとENTRYPOINTの違い exec format error ビルド時のキャッシュについて: キャッシュが有効なときと無効なとき ある一行でキャッシュが使われなかったらそれ以降のすべての行でキャッシュは使われない 何もしないコマンドを追加してもキャッシュは無効になる コマンドと引数の間に意味のないスペースの入れてもキャッシュは無効となる Dockerfileの行に意味のないスペースを入れてもキャッシュは有効 冪等ではない命令でもキャッシュは効いてしまう ADD以降にある命令はキャッシュされない (ただし、0.7.3以前のバージョンを使っている場合のみ) コンテナをバックグラウンドで動かすハック なぜDockerfileを使うのか? Do
結論 以下の手順で作るのが効率的です。 ベースにする Docker イメージを決める docker run -it <docker-image> sh でコンテナ内部で作業 1行ずつ、うまくいったらどこかにメモ 失敗したらいったん exit して再度 docker run ファイルの取り込みやポートの外部公開が必要ならオプション付きで docker run 全部うまくいったら Dockerfile にする ネットで見たことはないですが、もし docker build で試行錯誤しながら Dockerfile を作るとしたら、それはさすがに苦行です。 遅い デバッグしにくい!コンテナ爆発しろ!!って気持ちになります。 これが原因で「Docker 使えない 便利じゃない 」と思っていたのならそれは勘違いです。 手順詳説 試しに ip-api.com にリバースプロキシするだけの Nginx イ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く