Issues deploying phoenix locally via docker

[rileytaylor]

I haven't any problems until a few days ago with this, but I am currently unable to get the Phoenix app running locally. It runs (I can reach the console output via localhost) but doesn't actually provide any api output at api.localhost.

I'm having issues on Windows (fully up to date docker), and @ivy-g is also having issues on Mac, same problems.

Here is the console output from Ivy's machine:

Ivys-iMac:~ ivygarrenton$ 
Ivys-iMac:~ ivygarrenton$ cd
Ivys-iMac:~ ivygarrenton$ cd github
Ivys-iMac:github ivygarrenton$ cd code-corps-phoenix
Ivys-iMac:code-corps-phoenix ivygarrenton$ docker-compose up
Starting codecorpsphoenix_postgres_1
Starting codecorpsphoenix_apiary_1
Starting codecorpsphoenix_elasticsearch_1
Starting codecorpsphoenix_web_1
Starting codecorpsphoenix_test_1
Attaching to codecorpsphoenix_elasticsearch_1, codecorpsphoenix_apiary_1, codecorpsphoenix_postgres_1, codecorpsphoenix_web_1, codecorpsphoenix_test_1
postgres_1       | LOG:  database system was shut down at 2016-09-15 00:23:03 UTC
elasticsearch_1  | [2016-09-15 00:25:33,306][WARN ][bootstrap                ] unable to install syscall filter: seccomp unavailable: your kernel is buggy and you should upgrade
apiary_1         | Invalid path /code-corps-api/blueprint/api.apib
elasticsearch_1  | [2016-09-15 00:25:33,517][INFO ][node                     ] [Xavin] version[2.4.0], pid[1], build[ce9f0c7/2016-08-29T09:14:17Z]
elasticsearch_1  | [2016-09-15 00:25:33,517][INFO ][node                     ] [Xavin] initializing ...
postgres_1       | LOG:  MultiXact member wraparound protections are now enabled
postgres_1       | LOG:  autovacuum launcher started
postgres_1       | LOG:  database system is ready to accept connections
elasticsearch_1  | [2016-09-15 00:25:34,286][INFO ][plugins                  ] [Xavin] modules [reindex, lang-expression, lang-groovy], plugins [], sites []
elasticsearch_1  | [2016-09-15 00:25:34,352][INFO ][env                      ] [Xavin] using [1] data paths, mounts [[/usr/share/elasticsearch/data (/dev/vda2)]], net usable_space [54.2gb], net total_space [59gb], spins? [possibly], types [ext4]
elasticsearch_1  | [2016-09-15 00:25:34,352][INFO ][env                      ] [Xavin] heap size [990.7mb], compressed ordinary object pointers [true]
codecorpsphoenix_apiary_1 exited with code 1
web_1            | ** (Mix) Could not find a Mix.Project, please ensure a mix.exs file is available
test_1           | ** (Mix) Could not find a Mix.Project, please ensure a mix.exs file is available
codecorpsphoenix_web_1 exited with code 1
codecorpsphoenix_test_1 exited with code 1
elasticsearch_1  | [2016-09-15 00:25:36,895][INFO ][node                     ] [Xavin] initialized
elasticsearch_1  | [2016-09-15 00:25:36,896][INFO ][node                     ] [Xavin] starting ...
elasticsearch_1  | [2016-09-15 00:25:36,988][INFO ][transport                ] [Xavin] publish_address {172.18.0.2:9300}, bound_addresses {[::]:9300}
elasticsearch_1  | [2016-09-15 00:25:36,996][INFO ][discovery                ] [Xavin] elasticsearch/sItHwZINSieCABP4_cyL9g
elasticsearch_1  | [2016-09-15 00:25:40,053][INFO ][cluster.service          ] [Xavin] new_master {Xavin}{sItHwZINSieCABP4_cyL9g}{172.18.0.2}{172.18.0.2:9300}, reason: zen-disco-join(elected_as_master, [0] joins received)
elasticsearch_1  | [2016-09-15 00:25:40,069][INFO ][http                     ] [Xavin] publish_address {172.18.0.2:9200}, bound_addresses {[::]:9200}
elasticsearch_1  | [2016-09-15 00:25:40,069][INFO ][node                     ] [Xavin] started
elasticsearch_1  | [2016-09-15 00:25:40,097][INFO ][gateway                  ] [Xavin] recovered [0] indices into cluster_state

The most important sections (afaik) being `elasticsearch_1... unable to install syscall filter: seccomp unavailable: your kernel is buggy and you should upgrade' and '(Mix) Could not find a Mix.Project, please ensure a mix.exs file is available'

A post here discusses the permissions issues. But I'm not sure that really explains why that would still happen in Windows as well (unless its an issue within the linux container)

This is output from http://localhost:49235/users :

This may be related to #108

Let me know what other information is needed.

[fahrradflucht]

Is this still present after the latest changes to the docker setup?

[joshsmith]

@rileytaylor @ivy-g can you verify this?

[joshsmith]

Closing because do not recommend using Docker now.