サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DRgolang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬDockerのOOMはRSSベースで検出時にSIGKILLを投げてくるDocker利用時にVSZで制限をかけるスクリプトを書いたgolang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
数字的には節目となるJava10が公開され、Java界隈は久々の春を満喫しつつ、これから始まるアップデートレースに戦々恐々としていると思います。Java10の新規フィーチャーはいろいろなブログで紹介されていますが、個人的に気になっていたDocker対応について、少し調べてみました。Java10のリリースノート : http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.htmlDockerについては３つほど対応が書いてありますが、気になるのがこちらです。 Improvedocker container detection and resource configurationusage The following changes have been introduced in JDK 10 t
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 気軽にDocker を使いたい人向けの軽量なDockerホスト（VM）用Linux OS です。 Only-Docker → RancherOS-Lite →DockerRoot → Barge と変遷してきています。 （最後に Barge になったのは、Docker 社が他社製品名の先頭にDocker を使用することを禁止しているため） Barge は、以下のような特徴を持っています。 最軽量 高速ブートDocker のバージョンを切り替え可能 glibc、bash、dumb-init を標準搭載 パッケージ・インストー
morishita です。 今回はいこレポでのログ出力について紹介します。 いこレポの動作環境 いこレポは ElasticBeanstalk を利用してアプリケーションサーバを稼働させています。 ElasticBeanstalk ではプラットフォームを選択できますが、 Multi ContainerDocker を利用しています。 この場合、実際にRailsが稼働するのは ECS上に起動されたDocker コンテナとなります。Dockerではコンテナ内に永続化するデータを保存しないことが基本ですが、ログも コンテナ削除時に消えていい情報ではないので何らか外に出す必要があります。 その方法としては次の方法があるかと思います。 案1.ホスト側のディレクトリをマウントして、そこにログを保存する 案2. Fluentd でログサーバに転送する 案3. CloudwatchLogsに転送す
そもそも便利なのかちゃんと考えてる？ 「日々Dockerfileをメンテして開発環境がこんなに楽になります！」 「Dockerなので本番とも開発者同士でも同じになります！」 馬鹿じゃねーのかｗ？Dockerfileメンテなんて手順書メンテとかシェルスクリプトメンテしてんのと大して変わらねーよｗ そのDockerfileから作ったものが本番と同一だなんて保証はねーって気づけボケが本番と同じものを作りたかったら本番からコンテナ作れよ なんでビルド始めちゃうの？無駄じゃん馬鹿じゃん それと「同じDockerfileから作ったものだから環境差異はありません」なんて寝言まだ言ってるの？ yumもaptもリポジトリがセキュリティアップデートやらで変化する以上 いつも同じ結果になるわけじゃねーだろが、（バージョンロックする方法はあるけどめんどいだろ）本番でもコンテナを使ってますってやつら以外無理し
概要 2017年1月18日にリリースされたDocker v1.13 以降（今日現在の v17.03.0-ce ）は、docker コマンドラインの命令体系が再編成されました。本記事では変更に至った背景と、新旧コマンド体系の比較情報を整理します。 新しいサブコマンド体系の導入と背景 新しいコマンド体系の導入に至ったのは、docker のトップレベル・コマンド群が 40 を越える状況（当時）となったためです。コマンドには頻繁に使うものもあれば、使わないものもあり、再編成されることになりました。 v1.13から論理オブジェクト単位にコマンドが再編成されました。これは、「何」（コンテナやイメージ、ネットワーク）を、「どうするか」（作成、一覧、起動、停止）で扱います。そのため、従来よりもコマンドの利用目的が分かりやすくなります。たとえば、コンテナを管理するdocker container サブ
「Kubernetesはオープンソースのコンテナオーケストレーションのデファクトになった」と、CoreOSがfleetの開発を終了、代わりにKubernetes採用を発表Dockerの競合としてコンテナに最適化したContainerLinux（旧CoreOS）などを展開するCoreOSは、これまで同社が推進してきたコンテナオーケストレーションツール「fleet」の開発を終了し、今後はKubernetesを採用すると発表しました。 today we are seeing widespread adoption ofKubernetes, which has become the de facto standard for open source container orchestration. 現在、Kubernetesは広く使われており、オープンソースのコンテナオーケストレーションと
本稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stagebuildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ
「docker run/stop/start/rm/commit」の各コマンドの役割を整理しておきます。全体像はこんな感じ。 前提環境はこちらです。 # cat /etc/redhat-release Fedora release 20 (Heisenbug) # uname -aLinux fedora20 3.14.6-200.fc20.x86_64 #1 SMP Sun Jun 8 01:21:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # rpm -qdocker-iodocker-io-1.0.0-1.fc20.x86_64まず、「docker run」で新たなコンテナを起動します。「--name」オプションで名前「web01」を付けておきます。「docker ps」は起動中のコンテナを表示します。 #docker run -it
tl;drDocker 初心者は phusion/baseimage-docker をベースイメージとして使おう。 色々と便利だしハマる機会が減る。 遅ればせながらDocker 入門した 新たにアプリケーションを作る機会があり、週末を利用し遅ればせながらDocker について調べた。 すでにネット上に多くの入門記事がアップされていたおかげで導入自体は簡単にできたが、「まともな」イメージを作成しようとすると壁にぶちあたることになった。たとえば… コンテナに ssh 接続するにはどうすればいいの？ syslog 起動してないの？cron は？ 解析のために fluentd とか newrelic agent とかも入れたいな… いずれも 1 コンテナ 1 プロセスしか許容されていないという思い込みによるもので、Docker 入門者の多くが通る道なようだ。 公式ドキュメントをちゃんと読め
米マイクロソフトはDocker社と提携し、次期Windows ServerでDockerをサポート。Microsoft AzureでもDockerをサポートするとともに、Docker Hubとの統合も行うと発表しました。 同社のエンタープライズおよびクラウド部門の責任者であるスコット・ガスリー氏が自身のブログ「Docker andMicrosoft: IntegratingDocker withWindows Server andMicrosoft Azure」で明らかにしています。DockerのWindowsイメージに対応 ガスリー氏のブログによると、Windows ServerとMicrosoft AzureによるDocker対応は以下の通り。 （1）マイクロソフトはDocker Engineを次期Windows Serverに統合。次期Windows Serverにコンテナ
開発環境を構築したり、ツールを導入したりするのに、パッケージ管理システムはよく使われる。よく目にするものでも、Homebrew・yum・apt-get・npm・pip・gem...などいろいろある。 パッケージ管理システムはエンジニアを面倒な作業から開放してくれる。コマンドひとつで、オンラインからパッケージを探せて、ダウンロードでき(リポジトリの機能)、パッケージを追加したり削除したりもできる(インストーラの機能)。さらに、パッケージに必要な別のパッケージを同時にインストールしてくれる(依存関係解決機能)。たとえば、Ubuntuでhttpieが欲しいと思ったら、次のコマンドを打ってしばらく待てば使えるようになる。 パッケージ管理システムとしてのDocker ところで、話題のツールにDockerがある。Dockerはインフラ構築の文脈で、開発環境や本番サーバのプロビジョニングして配置するよう
アプリケーション実行環境をLinuxコンテナのDocker Engineに最適化し、軽量LinuxOSとして開発されている「CoreOS」が、初めての安定版「CoreOS 367.1.0」をリリースしました。 CoreOS 367.1.0には「Linux 3.15.2」と「Docker 1.0.1」が含まれており、Amazon EC2、Google Compute Engineなどの主要なクラウドをサポート。日本では、さくらのクラウドが早速OSイメージとして「CoreOS 367.1.0」をパブリックアーカイブに含めたと発表しています。 またCoreOSの開発元であるCoreOS社が先日発表した「CoreOS ManagedLinux」では、管理ツールや電話サポートなどを含む商用サポートも提供されます。 今後さまざまなDocker実行環境が CoreOSはDocker Engine上のア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
