Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
ゴールデンウィークにやってみましたので、その備忘録です。この後は、Swarm 入れてやろうなんてことを考えています。 微妙に突っかかったりしています。 前提条件/構成 次の構成で実施しました。 クライアント iMac(El Capitan) へ docker-toolbox をインストールしておきます サーバ Proxmox VE 上に、次の 3つの仮想マシン(VM) を準備しました docker00 Debian jessie : Swarm Manager 用 (仮IP 192.168.0.100) docker01 Debian jessie : Docker agent #1 (仮IP 192.168.0.101) docker01 Debian jessie : Docker agent #2 (仮IP 192.168.0.102) debian サーバでは、次の通り構成してます
Jenkins 2.0を動かすときのボリューム周りのTips を自分用のメモとして書いておきます。 課題 JenkinsのDockerイメージ、もしくはそれを継承したイメージを作成した場合、課題になるのが、ディスクの実行権限です。このイメージは、Dockerイメージの中で定義された、Jenkinsユーザ(uid 1000) で実行されるようになっています。 Dockerコンテナは、通常だとコンテナの内部にボリュームを持っていて、コンテナを削除すると、ボリュームは消えてしまいます。設定内容を保存したいケースでは、-vオプションを使って、保存したいディスク領域を、ホストOSのディスク領域にマウントする必要があります。 ただ、その場合、マウントした、ホストOS側のディスク領域が、Docker内のJenkinsユーザからアクセスできる必要があります。 参考Jenkins 2.0 container
nginx の reuseport オプションとは nginx 1.9.1 からの新機能で、 SO_REUSEPORT というソケットのオプションを有効化するもの。 https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/ SO_REUSEPORT とは Linux Kernel 3.9 以降の機能で、 1 つのポートを複数のプロセスで bind できるようにするもの。 SO_REUSEPORT (since Linux 3.9) Permits multiple AF_INET or AF_INET6 sockets to be bound to an identical socket address. This option must be set on each socket (including the firs
はじめに Dockerでの開発環境構築については色々と情報が転がっていましたが、情報が古かったり構成が違ったりで試行錯誤ありましたのでひとまずまとめました。ちなみに本番環境は今のところDocker全く使っておらず、開発環境を手軽に整えるという目的のみで使っています。 開発中のサービスは現在下記のコンポーネントで構成されています。 Ruby on Rails 4 MySQL memcached redis nginx Docker導入前と後での変化 弊社では各個人のPCに環境を構築して開発しています。 mysqldやmemcached、ImageMagickなど依存しているモジュールを入れて環境をセットアップするのですが、まぁビルドは時間かかるしバージョンが違ったりでなんだかんだ丸一日費やすことが多かったです。 Dockerで開発環境をセットアップできるようにした結果、PCがまっさらな状態で
今年の春くらいにWEB+DBの「サーバ/インフラ徹底攻略 (WEB+DB PRESS plus)」を読み、イミュータブルインフラストラクチャというものに興味が湧いた。そこで、これまではBitnami StacksでOSXに直接インストールしていたWebアプリケーションを、VagrantとDockerで不変なものに置き換えてみることにした。 ※スライド版資料もあります →Dockerで楽しむ自宅サーバ 2016-02-15追記 紹介しているサーバ構成の簡易版をgithubにアップロードしました。自宅と全く同じ構成ではありませんが(非SSL・内部ネットワーク化など)、VagrantとOSXさえあれば動作するようになっています。 →デモ用Vagrantfile + docker-compose.yml 最終的に出来上がったシステムの俯瞰図 設定ファイルの一覧 ├── Vagrantfile ├─
はじめに この記事では、Docker環境でしかおこらない厄介な問題の原因を突き止めるためにGDBを利用する際のヒントを解説します。これにより、怪しい部分を絞り込んでいくための取っ掛かりを作ることができます。 前提となる知識・スキル 知識・スキルとして以下をおおよその前提としています。 C言語およびGo言語によるプログラミングができる。 Dockerの基本操作ができる。 Linux(UNIX)上でのGDBによる実行の追跡ができる。 なぜDockerでGDBか Docker環境であるプログラム(Aとする)を実行してトラブルが起こった場合、 Aにもともと問題があった Dockerに問題がある DockerとAの組み合わせに問題がある のどれなのかを見極めて解決する必要がありますが、この切り分けはかならずしも簡単ではありません。そこできわめて強力な道具として登場するのがGDB(The GNU Pr
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 📜 要約 コンテナー管理ソフトウェアのDockerを利用することで、データ分析の場面で利用頻度の高いRおよびPythonの分析環境として実行することが出来るRStudio Server、Jupyter、Beaker Notebookを容易に構築可能になる。Dockerを使うことの利点として、複数人でのデータ分析や将来の利用面においてデータ分析結果の再現性を高められると考えられる。 🍵 前置き〜データ分析者が直面する再現性への挑戦 データ分析の結果が、自分以外では再現できない、同じデータを使っているのにナンデ!?ということが時々ありま
初めに 著者はGo言語、インフラ構築自動化技術に関する知識はあまりないので、知識のある上級者は適切なアドバイスなり、間違いの指摘をして頂けると幸です。 このようなシチュエーションを想定しています。 ある日、上司からこんな無茶ぶりが・・・ 「君、優秀なんだね。Go言語が良いみたいだからGo言語でセキュアなAPIを軽く作っておいてよ。ついでにインフラ構築自動化も流行ってるから、導入して実行環境の構築も自動化しといて」 という無茶ぶりされたときにあなたはこのようなまなざしを上司に向けるでしょう。 安心して下さい。そんなあなたのためにこの記事を書きました。笑 冗談はさておき、本題に入ります。 構成 今回の構成を図に表してみます。 図の参照元 Go Lang, GitLab, Vagrant, Docker, CircleCi, Ansible, Terraform, AWS 工夫した点 開発環境と
修正履歴: @aosho235 さんのコメントより、Dockerfile の"EXPOSE 8888" の不要な記述を修正 @aosho235 さんのコメントより、node アプリを起動するコマンドが抜けていた点を修正(Dockerfile, docker-compose.yml) @alt さんより編集リクエスト。シンタックスハイライトを適切なものに修正 感謝<(_ _)> Docker Compose 概要 Docker compose とは、複数のコンテナから成るサービスを構築・実行する手順を自動的にし、管理を容易にする機能です。 Docker compose では、compose ファイルを用意してコマンドを1 回実行することで、そのファイルから設定を読み込んですべてのコンテナサービスを起動することができます。 Docker Compose を使うまでの主なステップ Docker
ローカルの Rails の開発環境を直接OSに構築してしまうと、 仕事で別のバージョンの DB が必要になったケースなどで非常に苦労するので 何らかの仮想マシン上に開発環境を構築するほうが楽だと思う。 Vagrant と何かしらのプロビジョニングツールを使う方法がベターだが、 Docker Compose を試しに使ってみたら便利だった。 Docker Compose なに? Docker における複数コンテナの管理を docker-compose.yml という1ファイルでできるようにするツールです。 詳しくは https://docs.docker.com/compose Vagrant と比べたメリット 設定ファイルが短い。 例えば Vagrant + ansible の場合、Ruby とか PostgreSQL とかのインストール方法を自分で書く必要がありますが、 docker-c
OSXでdockerを使った開発環境を組もうとすると、docker入りのVagrant boxを自作しないとならなかったり、docker-machineのファイル共有をセットアップする必要があったりと、開発を始めるまでの手間が多い。 dinghyは上記のような手間を省略し、OSXとdocker環境をシームレスにしてくれるプロダクトで、次の特徴がある。 ホストマシン(OSX)側のファイルをコンテナにマウントできる マウントだけでなくファイルシステムのイベントもサポートする。つまり、webpackなどのファイル更新を検出してタスクを走らせるツールと相性がいい。 DNSを内包しているので、Macの/etc/hostsを書き換えたり等、自前で名前解決が不要。 HTTPプロキシを内包しているので、1つのVMに複数のウェブアプリを簡単に起動できるようになっている。 docker-compose.yml
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く