Fig caching mounted volumes

[jgadbois]

After updating fig, I'm having a problem where fig seems to be caching the local working directory and using it's own version instead of using my local directory. For instance in my fig.yml I have

  volumes:
    - .:/var/www/html/

But file changes don't show in the web server.

In another project, where a volume is mounted the same way, switching branches in my local directory does not seem to update the code in the mounted volume.

Is this a new configuration item I am missing or something?

[aanand]

Can you reproduce the bug using just docker run -v ... and not Fig? If so, it's a problem with your setup (if you're using boot2docker or some other VM-based solution, it's possible that your folder sharing isn't working properly).

[Maxim-Filimonov]

@aanand I'm facing similar issue but only with fig up.

Docker version 1.4.1, build 5bc2ff8
fig 1.0.1
Vagrant 1.7.2

See example(look for BetterErrors config which i have removed locally):

> tail config/environments/development.rb
  # Adds additional error checking when serving assets at runtime.
  # Checks for improperly declared sprockets dependencies.
  # Raises helpful error messages.
  config.assets.raise_runtime_errors = true

  # Raises error for missing translations
  # config.action_view.raise_on_missing_translations = true

  config.cache_store = :memory_store
end

> fig up app
Attaching to app_1
app_1 |   # Raises error for missing translations
app_1 |   # config.action_view.raise_on_missing_translations = true
app_1 |
app_1 |   config.cache_store = :memory_store
app_1 |
app_1 |   # Allow any ip as we are running it in docker container
=== THIS SHOULD NOT BE HERE app_1 |   BetterErrors::Middleware.allow_ip! =======
app_1 | end

> fig run app
  # Adds additional error checking when serving assets at runtime.
  # Checks for improperly declared sprockets dependencies.
  # Raises helpful error messages.
  config.assets.raise_runtime_errors = true

  # Raises error for missing translations
  # config.action_view.raise_on_missing_translations = true

  config.cache_store = :memory_store
end
> docker run -v /vagrant:/myapp <CONTAINER_ID> tail config/environments/development.rb
  # Adds additional error checking when serving assets at runtime.
  # Checks for improperly declared sprockets dependencies.
  # Raises helpful error messages.
  config.assets.raise_runtime_errors = true

  # Raises error for missing translations
  # config.action_view.raise_on_missing_translations = true

  config.cache_store = :memory_store
end

Fig.yml:

app:
  volumes:
    - /vagrant:/myapp
  command: tail config/environments/development.rb
  # dockerfile from getting started with rails
  build: . 
  ports:
    - "8080:3000"

/vagrant is folder synced to local folder using vagrant syncing. I don't think it has anything to do with vagrant as fig run and docker run work without problems

[jgadbois]

My problem is with fig up as well, I believe.

[Maxim-Filimonov]

Confirming the same problem with docker-compose 1.1.0-rc2.
Workaround i found so far:
docker-compose rm && docker-compose up

[cpuguy83]

Have you tried with docker 1.5.0?

[Maxim-Filimonov]

@cpuguy83 yes docker-compose is with docker 1.5.0.

[aanand]

@Maxim-Filimonov Are there any notable differences if you docker inspect the containers created by Docker and Fig?

[robbernabe]

Confirming this issue using fig 1.0.1 and docker 1.4.1. The workaround is fig rm --force && fig up

[adamdecaf]

I confirmed that this is an issue still. The workaround to "rm then up" it worked, but it's less than idea.

adam@ip-10-0-0-78:~$ docker --version
Docker version 1.5.0, build a8a31ef
adam@ip-10-0-0-78:~$ docker-compose --version
docker-compose 1.1.0

[troyastorino]

I'm also experiencing an issue similar to this. When I remove volumes values in docker-compose.yml, those changes aren't reflected in in the container config. For instance, I removed all volumes from my docker-compose.yml file, but when I looked at container config (in /var/lib/docker/<containerId>/config.json), it still had the old volumes values that had been deleted. The same rm --force workaround fixed my problem as well

There's a key in that config.json file called AppliedVolumesFrom that pointed to an old container, and wasn't getting changed when I changed the docker-compose.yml file. After running docker-compose rm --force && docker-compose up, the newly created container had AppliedVolumesFrom: null. I'm guessing that the issue stems from this value not getting properly flushed by docker-compose when changes are made.

[dnephin]

This would be fixed by #858

[sergej-brazdeikis]

Upgrade to docker-compose 1.2.0 solved the issue 👍

[dnephin]

#858 has been merged into 1.3.0. This should be fixed once that is released.