4ヶ月ほど M1 Mac で実務をやってきて、ちょっと Docker 周りのノウハウが溜まったので整理しました これから M1 Mac を買う人買った人や迷っている人の助けになれば嬉しいです この本は問題切り分けや対応方針の考え方をケース集としてまとめたもので、直接エラーを解決するコマンド集ではありません ご了承ください
![M1 Mac で Docker を動かすための知識とノウハウ](https://cdn-ak-scissors.b.st-hatena.com/image/square/f719920ff2bafeddfa7a114d3614043f1d277363/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--IqfQrFVF--%2Fg_center%252Ch_280%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYm9va19jb3Zlci80ZGE5YTZiN2Y0LmpwZw%3D%3D%252Cw_200%2Fv1627283836%2Fdefault%2Fog-base-book_yz4z02.jpg)
はじめに dockerコンテナ上でElectronの開発環境を構築した時の手順を残します。 環境 2020/4/28 MacOS Catalina v10.15.4 1. Docker上のGUIをホスト側で表示できるようにする 1-1. XQuartzをインストールする docker上のGUIウィンドウを表示させるために、XQuartzをインストールします。 1-2. XQuartzの設定をする インストールが終わったら XQuartz のアイコンをクリックし、 Macのメニューバーから 「xquartz」 → 「環境設定」 → 「セキュリティ」タブ → 「ネットワーク・クライアントからの接続を許可」にチェックを入れて、xquartzとターミナルを再起動します。 1-3. XQuartzの設定を確認する ここまでできたら、MacOS側でecho $DISPLAYコマンドを実行し、環境変数D
golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DR golang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬ DockerのOOMはRSSベースで検出時にSIGKILLを投げてくる Docker利用時にVSZで制限をかけるスクリプトを書いた golang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて
今回は Docker で使える「ヘルスチェック機能」を試す.Release Note を読むと,機能としては Docker 1.12 から使えるらしく,3年前からあったなんて...!仕組みとしては,Docker デーモンからコンテナに指定したコマンドを定期的に実行する. Dockerfile 構文 「ヘルスチェック機能」を使う場合,まず Dockerfile に HEALTHCHECK を設定する.実行するコマンド以外に以下のオプションも設定できる.注意点として,--retries 以外は秒数を指定するため,表記は 5s のように単位も付ける. --interval=DURATION (default: 30s) --timeout=DURATION (default: 30s) --start-period=DURATION (default: 0s) --retries=N (defa
入門 Docker¶ About¶ Dockerの入門からプロダクションで活用するプラクティスについてのドキュメントです。 プロダクションへ導入するために必要なDockerの概要から設計までをなるべく最短経路で学ぶことが目的です。 想定する読者層¶ WebAPIのようなサーバーサイドのプログラミングをしたことがある Dockerをこれからプロダクション環境へ導入してみたいと考えている初学者 Version¶ Docker 18.09.3 docker-compose 1.23.2 必要な環境¶ Docker Hub のアカウント Docker公式レジストリ Play with Docker DockerをWeb上で動かせる環境 Play with Dockerを起動するのに前述のDockerHubアカウントが必要 Docker for Mac(Windows)の場合VMが間に挟まり挙動が異
表題のような問題があり,その調査したという記録です.なお,結論を一言で言うと--initを使え,ということになります. そもそもDockerコンテナを起動すると,CMDあるいはENTRYPOINTに指定されたコマンドがコンテナ内でPID 1として起動します.これが何を意味するかと言うと,「CMDあるいはENTRYPOINTに指定されたコマンド」はそのコマンド自体の責務をまっとうするのと同時に,initプロセスとしての振る舞いも行わなければならないということになります (id:hayajo_77さんにこの辺を詳しく教えてもらいました,ありがとうございます). つまりPID 1で動いているプロセスは「SIGCHLDをトラップすることで孤児プロセスを適切に回収し,waitpidをかける」という処理も適切に行う必要があります. さて,puppeteerを使ってChromeブラウザを起動するとどうな
The build time of Golang Docker images always frustrated me as there was always a need to do the go get ./... before we started building the binary. This resulted in fetching the dependencies every time we wanted to build the image. The Dockerfile then looked like this: FROM golang:alpine AS build-envCOPY . $GOPATH/src/mypackage/myapp/ WORKDIR $GOPATH/src/mypackage/myapp/# go get and build <-- THI
動機 dockerのようなコンテナでは通常のLinuxシステムではinitなどがやってくれる処理をdocker自体が面倒を見てくれる。実際にどこまでやってくれるのかを調べるために、busybox一個だけを含むイメージを作って動かして、どんなファイルが自動生成されているのか調べた。 使用したdockerは、Ubuntu 16.04 で sudo apt install docker.io でインストールしたもの。 $ docker version Client: Version: 1.13.1 API version: 1.26 Go version: go1.6.2 Git commit: 092cba3 Built: Thu Nov 2 20:40:23 2017 OS/Arch: linux/amd64 Server: Version: 1.13.1 API version: 1.26
私は以前の仕事で Docker を使っており、今の会社(eralabs.io)でも顧客のために使っています。そして、これまでの経験により得た Docker の知識を皆さんにシェアしたいと思い、Painless Docker Course を始めました。 私は Docker、コンテナ、オーケストレーション、分散システムが好きです。そして、Painless Docker の多くの読者がその内容に満足していることは嬉しいことでした。 Painless Docker はただの本ではなくコースとなりました。詳しくは、ウェブサイトをご覧ください。 ここで紹介しているのは、 Painless Docker Course の中身の一部です。Git repo でも公開していますので、ぜひご覧ください。 このチートシートは、Painless Docker Course にあるものの一部です。 GitHub の
Lobi事業部 サービス基盤チームの長田です。 最近プロジェクト内で使用する開発環境にDockerを利用するようになったので、その紹介をします。 Dockerにしたってどういうこと? 公開済みのWebサービスに変更を加えて動作確認をする場合、本番環境でそれを行うわけにはいきません。 ほとんどの場合はローカルマシンでWebサービスの全体または一部のコピーを動かして動作確認を行うことでしょう。 その後ステージング環境などの他の開発メンバーも触ることができる環境で動作確認やQAを行い、 問題がなければ晴れて本番環境に反映、という流れが一般的かと思います。 この「ローカルマシンでWebサービスのコピーを動かす」部分にDockerを利用している、ということです。 Dockerにしてどうなった? Before 開発環境構築に1〜2日かかっていた After 開発環境構築がランチに行っている間に終わるよ
長かった本連載も今回が最終回です。 この連載では、プログラムがコンピュータ上で動くときに何が起きているのかを、Go言語のコードを通して覗いてきました。 今回は、その締めくくりとして、コンテナについて紹介します。 現在広く利用されているコンテナ技術であるDockerのコアは、Go言語製のlibcontainerというライブラリです。 このライブラリを使って自作のコンテナを仕立ててみます。 今回の原稿にあたっては、仮想化周りでsyohexさんに細かく指摘をいただきました。ありがとうございました。 仮想化 コンテナの話に入る前に、コンテナと目的がよく似た技術である仮想化について説明します。 仮想化は、コンテナよりも先に広く使われるようになった技術ですが、 歴史的にさまざまなソリューションがあり、どのような仕組みか、どのようなメリットがあるか、どのような制約があるか、どこにフォーカスするかで分類の
概要 Web アプリケーションを開発しているときに、開発環境に MySQL や Redis を用意しバージョンを揃え、いや Redis はキャッシュにしか使ってないし必須じゃないから開発環境に無い場合のコードも書いて…… というようなことを2017年にもなってやりたくないので、Docker を使って良い感じにやっていきます。 Docker や Docker Compose に関する基本的な説明は割愛するので、公式ドキュメントをあたってください。 目標 コマンド一発で必要なサービス群が全て立ち上がるようにする Docker Compose を使い、1サービスごとに1コンテナを立ち上げる vendor や node_modules は、ホスト側のものと完全に分離する。OS が違う場合、Native extension があると問題の原因になるので避けたい。 ホスト側ではエディタと git さえ
本稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ
Go でアプリケーションを作ると、そのまま他になにもなくとも実行できるバイナリが出来あがります。この特性によりデプロイが大変楽です。 このような特性があるので、 Go を使う場合 Docker のようなオーケストレーションツールを使わなくても多くのサーバーにアプリをデプロイしていくことも可能かと思われますが、そこはまあ Docker という巨人に乗っておくと楽なことが多いです。具体的には swarm と docker-compose が便利なので Docker 上で実行したい。 ここで問題となってくるのが何も考えずに Docker イメージを作るとイメージサイズが膨れあがってしまってシングルバイナリによる手軽さなどが損なわれてしまうという点です。 たとえば golang:alpine のような比較的小さいイメージを使ってもファイルサイズはバイナリサイズ + 300MB ほどにもなってしまい
2016 - 08 - 12 Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング Docker Linux もう半年くらいフルDockerでmicroservicesなサービスを運用してるんですが、イマイチパフォーマンスを出し切れていないなという面がありまして、今回Dockerホストの TCP カーネル パラメータを抜本的に見直しました。 そしたら劇的に症状が改善して、 インスタンス 数も削減できた上に安定して メシウマ状態 になったので紹介します。実際効果があったのでチューニングポイントとしてはある程度正解であったと考えていますが、もちろん扱ってるアプリケーションの特性にもよるはずなので一つの ケーススタディ であることをご了承頂ければと。 前提 まずは今回のお話の前提を。こんな環境です。 EC2 c3.xlarge ホストは Ubuntu (EC2 Opt
Docker イメージを小さく作るテクニックって、いろいろありますよね。不要なファイルやディレクトリを削除したり、複数の RUN 命令をひとつにまとめたりなどなど。 ところが、ベースイメージに Alpine Linux を使う(FROM alpine とする)と、Docker イメージのサイズを 劇的に小さくできる ことがわかりました。 いままで、Docker イメージのサイズを小さくするために、ちまちまとやってきたことは、なんだったんだろうという感じです。まあ、それはそれで組み合わせて使いますが . . . なんとも . . . ねえ(笑) Alpine Linux とは Alpine Linux は、セキュアで軽量な Linux ディストリビューション musl libc と BusyBox をベースに構成されている 組込み系に適した Linux ディストリビューション パッケージ管理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く