web-dev-qa-db-ja.com

docker-compose：ファイルの変更を即座に確認する方法（開発時）

私はdockerに慣れていないので、とにかくこれは非常に基本的なように思えるかもしれません。

コンテナ上で新しいWebプロジェクトを開発することにしました。もちろん、Dockerについて考えました。チュートリアルを完了してDockerfileなどを読んだ後、docker-composeを使用することにしました。

開発用、本番用など、複数の構成ファイルが必要です。今、私は3つの異なるサービスを使用して基本的なphp/mysql/redisアプリケーションをオーケストレーションすることができました。メインアプリケーションはphpベースで、プロジェクトsrcで維持されます。 MysqlとRedisは、基本イメージで単純に構成され、ビジネスロジックを必要としません。

コンテナを構築して、それらを持ち出すことができます

ビルド：

docker-compose -f compose-Development.yml build

アップ：

docker-compose -f compose-Development.yml up

メインアプリケーションコンテナ内の多くのファイルはgulp（テンプレート、cssなど）によって構築され、コードはjavascriptとphpの両方に存在します。

ファイルを変更してもアプリの状態が変わらないことに気付きました。コンテナを再構築して再起動する必要があります。

Vagrantでの経験があれば、開発中に何らかの共有ソースを探します。しかし、どうすればそれを達成できますか？

私のアプリケーションDockerfile（開発用）は次のようになります。

FROM webdevops/php-nginx:7.1
COPY ./ /app
COPY docker/etc/ /opt/docker/etc

# php config...
RUN ln -sf /opt/docker/etc/php/php.Development.ini /opt/docker/etc/php/php.ini

WORKDIR /app/
EXPOSE 80

構成ファイル：

version: "3"
services:

  app:
    build:
      context: .
      dockerfile: Dockerfile.Development
    links:
      - mysql
      - redis
    volumes:
      - ./data/fileadmin:/app/public/fileadmin
      - ./data/uploads:/app/public/uploads
    env_file:
      - docker/env/All.yml
      - docker/env/Development.yml
    ports:
      - "80:80"
    restart: always

  # Mysql Container
  mysql:
    build:
      context: docker/mysql/
      dockerfile: Dockerfile
    restart: always
    volumes:
      - mysql:/var/lib/mysql
    env_file:
      - docker/env/All.yml
      - docker/env/Development.yml

  # Cache Backend Container
  redis:
    build:
      context: docker/redis/
      dockerfile: Dockerfile
    ports:
      - "6379:6379"
    volumes:
      - redis:/data
    env_file:
      - docker/env/All.yml
      - docker/env/Development.yml
    restart: always

volumes:
  mysql:
  redis:

これまでのところ、いくつかのgithubリポジトリを使用してチャンクをコピーしました。私の設定にも他の問題があるかもしれないことを知っています。今のところ、最もブロッキングの問題はリンクされた/コピーされたソースに関するものです。

敬具、フィリップ

dockerdocker-composedevopsprovisioning
11
Philipp Wrann

「開発/生産パリティ」という考えは、この面の多くを混乱させます。これは、単一の構成を使用できることを意味するものではなく、すべての構成で機能します。これは、多くのcloserパリティを持ち、本番環境に非常に近いものに似た環境を作成できることを意味します。

ここで間違っているのは、現在イメージを作成しており、出荷する準備ができていること、コードを持っていること、アップロード用にボリュームを確保していることなどです。素晴らしい！

残念ながら、このセットアップは開発には適していません。その場でコードを編集したい場合は、ローカルの作業ディレクトリもボリュームとしてイメージに添付する必要があります。これはnot本番環境で行われます。それは非常に近い-しかし、まったく同じ設定ではありません。

作成ファイルのappサービスボリュームセクションに次を追加すれば、準備完了です。

- .:/app
13
TJ Biddle