コンテナ目線で考えるUnikernelとmicroVM / MicroVM and Unikernel in the container world
コンテナ目線で考えるUnikernelとmicroVM / MicroVM and Unikernel in the container world
Diving Through The Layers: Investigating runc, containerd, and the Docker engine architecture A presentation given on Thursday, January 19th, 2017 at the Devops Remote Conf 2017. This talk details the history of the Docker engine architecture, focusing on the split in April 2016 into the containerd and runc layers, and talking through the December 2016 announcement of the *new containerd project a
以前、Docker コンテナ内で Docker ホストと同じユーザを使う方法として、以下のような記事を書いた。 ちょっと強引だけど /etc/passwd と /etc/group をコンテナからマウントすることで不整合をなくしてしまう、というもの。 blog.amedama.jp ただ、上記のやり方だと不都合が出る場合もあったので、別のやり方についても試してみた。 どちらかというと、今回のやり方の方が後々の面倒がなくて良いかもしれない。 方法というのは、コンテナを起動するタイミングでコンテナ内にユーザを使って各種 ID などを引き継がせてしまう、というもの。 使った環境は次の通り。 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTI
この記事はなに タイトル通り。 主にsbt-native-packagerのとりあえずの使い方紹介。 Akka-HTTPでWebアプリを実装し、sbt-native-packagerを使ってDockerイメージを作成、localhostで稼働させてHTTPリクエストを受け付けられるようにするまで。 環境 Scala 2.12.4 sbt 1.0.4 Akka-HTTP 10.0.10 sbt-native-packager 1.3.3 ScalaのWebアプリ build.sbtにはAkka-HTTPの依存を追加しておく。 import akka.actor.ActorSystem import akka.event.Logging import akka.http.scaladsl.Http import akka.http.scaladsl.server._ import akka.s
After 6 years, I removed Docker from all my home servers. apt purge -y docker-ce Why? This was triggered by a recurring incident I faced where the Docker daemon was using 100% CPU on multiple cores that made the host effectively unusable. This had happened a few times before, and was likely due to a script that had got out of hand starting up too many containers. I’d never really got to the bottom
dockerでvolumeをマウントするときの問題点 docker runするときに-vオプションをつけることによってホストのディレクトリをコンテナ内にマウントすることができる。 ホスト側のファイルをコンテナ内で使いたい場合や、逆にコンテナで作ったファイルにホストからアクセスしたい場合に有用なのだが、ファイルのアクセス権限についてちゃんと考えておかないと問題が起きることがある。 例えば、ホスト内でのユーザーのuidが500だったとしよう。 $ id uid=500(ec2-user) gid=500(ec2-user) groups=500(ec2-user),10(wheel),497(docker) $ mkdir -p temp && touch temp/foo # 実験用に適当なディレクトリを作ってみる $ docker run -it -v $(pwd)/temp:/temp
Kubernetesがコンテナオーケストレーションツールのデファクトスタンダードを確立 参考資料:Dockerコンテナの導入状況に関するユーザー調査結果・調査年別(作成:IDC Japan) コンテナの導入状況について調査した結果、本番環境で使用している企業は9.2%となり、2018年調査からの上昇率は1.3ポイントにとどまった。さらに導入構築/テスト/検証段階にある企業は16.7%となり、これも2018年調査からわずかな上昇となった。 この結果から、Dockerコンテナは導入構築やテスト/検証に時間を要し、本番運用になかなか移れていない状況にあると考えられる。また、使用を計画、検討している企業と情報収集や調査を行っている企業の割合が2018年調査からやや低下している。 この傾向は、導入意向のある企業とそうでない企業がはっきりしてきており、具体的な導入に向けた検討や調査の段階に移ってきてい
By Dominic Fraser _[Source](https://www.docker.com/what-docker" rel="noopener" target="blank" title=") This article serves as a “how-to” guide for using Selenium Docker images alongside CodeceptJS and an Express server. In it, we will cover: What is E2E acceptance testing? Why use Docker? Loosely coupled testing tools Layers of testing tools Creating a test project E2E Acceptance Testing Acceptanc
この記事はWSL(Bash on Windows)上でDockerを使用するための手順です。 動作環境 Windows 10 Pro (Docker for WindowsはHyper-V必須) Docker for Windows Stable v17.03 WSL(Bash on Windows): Creator Update以降 WSL上のdocker: 17.03以降 WSL, Docker関連のバージョンはこれよりも低くても動作するかもしれませんが、Windows 10についてはProfessinal版を使用しないとDocker for Windowsを利用できないため注意してください。これはDocker for WindowsではHyper-Vを使用する前提があり、Hyper-VはWindows10 Professinal版でしか利用できないためです。 ということで、仮想環境
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
やってること メモ Jenkins を動かす環境 Docker イメージ itamae レシピ Serverspec テスト Jenkins の準備 プラグイン Docker 周り ジョブ infra-itamae の設定 infra-serverspec の設定 動いてる図 Build Pipeline ログ 以上 やってること 今更かもしれないけど, ギョームで以下のようなことをやって, ここ数日で運用も回ってきた気がするのでメモしておく. itamae のレシピを amazonlinux コンテナに適用 適用したコンテナに対して Serverspec でテスト 1 と 2 を Jenkins のビルドパイプラインで流す 3 が正常に終了したら, pull request を作成, 又はマージ master ブランチのレシピをサーバーに手動で適用 Jenkins のポテンシャルと it
実際には、まだ本当の本番環境では運用できてなくて開発用のステージングで運用が開始できたぐらいで、他にもやること一杯あるんだけど、ある程度知見が溜まったのでまとめておく。 ちなみに、規模はそんなに大きくないがデータ量は多いアプリケーションで運用環境はAWSのECSを想定しており、現時点で普通のEC2ノードとコンテナで並行稼動している。 docker-swarmなりで自前でコンテナプールを構築してもいいのだが、そうするとサービスディスカバリとか考えなければいけないことが増えるので、後回しにしている。 (注: かなりサービス固有の事情が含まれるため、もし参考にされる方が居たとしても、そのままの形では適用できない可能性が高い) 追記: RailsアプリのためのDockerfileとdocker-compose.ymlのサンプル - Qiita コンテナ化のモチベーション CentOSのお守りからの
Dockerで試行錯誤しているとき、コンテナを作ったり潰したりします。 コンテナを潰すにはdocker killコマンドにコンテナIDかコンテナ名を渡すわけですが、ここの補完が効いてくれたらいいのにと思って探してみました。 Docker公式リポジトリから頂いてくる docker/contrib/completion/ GitHubのDocker公式リポジトリの上記パスに、各種シェル用の補完設定ファイルが入っています。 私の環境(zsh+Prezto)の場合は、zsh用の_dockerファイルを~/.zprezto/modules/completion/external/srcに置きました。 補完が効いている状態でdocker killを叩いてTABを押すと こんな感じに補完候補が出てきます。 便利。
http://dockerjp.connpass.com/event/26538/ で発表したやつ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く