GitHub - docker/awesome-compose: Awesome Docker Compose samples
Icon indicates Sample is compatible with Docker Dev Environments in Docker Desktop version 4.10 or later. Icon indicates Sample is compatible with Docker+Wasm. ASP.NET / MS-SQL - Sample ASP.NET core application with MS SQL server database. Elasticsearch / Logstash / Kibana - Sample Elasticsearch, Logstash, and Kibana stack. Go / NGINX / MySQL - Sample Go application with an Nginx proxy and a MySQL
docker-compose の bind mount を1行で書くな
TL;DR docker-compose では bind mount の構文が "short", "long" の2通りあるが, それぞれ挙動が異なる docker-compose.yml の volumes に略記法 (short syntax) を用いると, コンテナ内で non-root user を用いる際にエラーの発見が遅れる可能性があるので避けよう 概要 Docker アプリケーション (コンテナ) は, 実行時にホストのファイルやディレクトリをコンテナ内にマウントし, ホストとのファイル共有を行うことができます (bind mount). docker-compose では, Compose ファイル (デフォルトでは docker-compose.yml) にマウント情報を記述することができますが, 構文によっては意図せぬ挙動や, パーミッションエラーを引き起こす原因となり
docker-compose.yml を環境ごとに分割する - yKicchan's blog
前提 Compose ファイルフォーマットバーション 3.x 結論 -f オプションを使う $ docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d または環境変数を使う: COMPOSE_FILE, COMPOSE_PATH_SEPARATOR $ export COMPOSE_PATH_SEPARATOR=: $ export COMPOSE_FILE=docker-compose.yml:docker-compose.prod.yml $ docker-compose up -d ファイル間、プロジェクト間での Compose 設定の共有 — Docker-docs-ja 17.06 ドキュメント 注意 extends キーワードは 2.1 までのサポートで、(2020年7月現在)ではご利用いただけ
docker-compose を利用して開発しているアプリを Circle CI 2.0 でテストする
普段から docker-compose を利用して開発しているアプリケーションを、Circle CI 2.0 に対応させる作業を行ったので、今回必要になった設定をまとめておきます。 アプリケーションの概要このアプリケーションでは、フロントエンドに Node.js を利用しており、バックエンドに Ruby on Rails を利用しています。それぞれ docker-compose で Node.js と Ruby のサービスを動かしており、Circle CI でも docker-compose を利用してテストすることにしました。 設定内容設定と言っても、以下のようなファイルを用意するだけです。Circle CI では docker-compose を利用できるので、普段から docker-composeを使っているのであれば、ほとんど余分な設定無しにテストを実行できます。 まず Git リ
CircleCI 2.0 で docker-compose を動かすなら、Machine Executor にしないとハマる - Qiita
CircleCI 2.0 で docker-compose を動かすなら、Machine Executor にしないとハマるCircleCIDocker 2017/09/12 追記 Circle CI 2.0 の docker executor が ECR に対応しました。 単純にECRのイメージを使いたいということだけであれば、もうこのページに書かれている machine executor を使う必要はないと思います。 CircleCI Blog - AWS EC2 Container Registry (ECR) Support 正しく動くものから 最後まで読まないと正解がわからないのはつらいと思うので、正解を最初に書くと、以下のようにすると問題なく動作する。 version: 2 jobs: build: machine: true steps: - checkout - run:
Amazon ECS CLI が、Docker Compose バージョン 3 をサポート
Amazon Elastic Container Service のコマンドラインインターフェイス (Amazon ECS CLI) が、Amazon ECS への Docker コンテナのデプロイで Docker Compose バージョン 3 ファイル形式をサポートするようになりました。 Docker Compose は、複数のコンテナから成るアプリケーションの定義と実行のためのオープンソースの仕様です。Amazon ECS CLI は、Amazon ECS のコマンドラインインターフェイスであり、高度なコントロールを提供して、ローカル開発環境から Amazon ECS によって管理されるインフラストラクチャとアプリケーションを簡単に作成、更新、監視できるようにします。以前は、Amazon ECS CLI では Docker Compose v3 形式のファイルを使用できなかったので、
Compose を 本番環境(production) で使う — Docker-docs-ja 24.0 ドキュメント
開発環境で Compose を使ってアプリケーションを定義しておけば、その設定を使い、アプリケーションを CI 、ステージング、本番環境のように異なる環境で実行できます。 アプリケーションをデプロイする最も簡単な方法は、単一サーバ上での実行です。これは開発環境で実行する方法と似ています。アプリケーションをスケールアップしたい場合には、Compose アプリを Swarm クラスタ上で実行できます。 Compose ファイルを本番環境向けに書き換え¶ アプリケーションの設定を本番環境に適用するには、おそらく書き換えが必要でしょう。以下のような変更が必要になるかもしれません： アプリケーションのコードに 結び付けている(bind) ボリュームを削除する。そのため、コードはコンテナ内に残り続けるため、外から変更できなくなる。 ホスト上では異なるポートに割り当てる コンテナのコードを外から変更でき
今更だけどdocker composeのベストプラクティス - Usual Software Engineer
複数のdocker imageとcontainerを使ってサクッと環境を整えたいときにdocker composeってとても便利ですよね。 単純な構成だと公式ドキュメントを読めばわりと簡単に思い通りになるのですが、 意外と慣れるまではどんな設定をしてどうファイルを配置するか迷いがちだと思います。 そんなわけで今更感が強いですがベストプラクティス的なものをまとめておきます。 最近になってようやくDockerfileとdocker-compose.ymlの良い書き方使い方がわかってきた気がする。初期のころに書いたやつも試行錯誤して書いたはずなんだけど今やクソみたいに感じる— innossh (@innossh) 2016年9月19日 今月のブログ書くネタに困って今更になってdocker composeを選んだわけでは…うっ… ベストプラクティスと言いつつ半年以上前の情報の可能性が…うっ… さっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
