Docker containers out of same image don't work as expected
up vote
1
down vote
favorite
I have a docker-compose.yml
set up like this:
app:
build:
dockerfile: ./docker/app/Dockerfile.dev
image: test/test:${ENV}-test-app
...
Dockerfile
called here has this line present:
...
RUN ln -s ../overrides/${ENV}/plugins ../plugins
...
And there is also a script I am running to get the whole environment up (it is dependant upon several containers so I tried to omit irrelevant info).
It is a bash script and running the following:
ENV=$1 docker-compose -p $1 up -d --force-recreate --build app
What I wanted to achieve is that i can run two app containers at the same time, and this works as follows:
sh initializer.sh foo -> creates foo-test-app container
sh initializer.sh bar -> creates bar-test-app container
Now the issue I'm having is that even when I have --force-recreate
flag present two images created actually are seen as the same image with two different tags.
And what this does when I inspect the containers is that both containers have a symbolic link to:
overrides/foo/plugins
It doesn't notice when I create the new container to re-do that part. How can I fix it?
Also if I sh to one container and change the symbolic link, it is automatically changed in the other container as well.
docker docker-compose dockerfile
add a comment |
up vote
1
down vote
favorite
I have a docker-compose.yml
set up like this:
app:
build:
dockerfile: ./docker/app/Dockerfile.dev
image: test/test:${ENV}-test-app
...
Dockerfile
called here has this line present:
...
RUN ln -s ../overrides/${ENV}/plugins ../plugins
...
And there is also a script I am running to get the whole environment up (it is dependant upon several containers so I tried to omit irrelevant info).
It is a bash script and running the following:
ENV=$1 docker-compose -p $1 up -d --force-recreate --build app
What I wanted to achieve is that i can run two app containers at the same time, and this works as follows:
sh initializer.sh foo -> creates foo-test-app container
sh initializer.sh bar -> creates bar-test-app container
Now the issue I'm having is that even when I have --force-recreate
flag present two images created actually are seen as the same image with two different tags.
And what this does when I inspect the containers is that both containers have a symbolic link to:
overrides/foo/plugins
It doesn't notice when I create the new container to re-do that part. How can I fix it?
Also if I sh to one container and change the symbolic link, it is automatically changed in the other container as well.
docker docker-compose dockerfile
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have a docker-compose.yml
set up like this:
app:
build:
dockerfile: ./docker/app/Dockerfile.dev
image: test/test:${ENV}-test-app
...
Dockerfile
called here has this line present:
...
RUN ln -s ../overrides/${ENV}/plugins ../plugins
...
And there is also a script I am running to get the whole environment up (it is dependant upon several containers so I tried to omit irrelevant info).
It is a bash script and running the following:
ENV=$1 docker-compose -p $1 up -d --force-recreate --build app
What I wanted to achieve is that i can run two app containers at the same time, and this works as follows:
sh initializer.sh foo -> creates foo-test-app container
sh initializer.sh bar -> creates bar-test-app container
Now the issue I'm having is that even when I have --force-recreate
flag present two images created actually are seen as the same image with two different tags.
And what this does when I inspect the containers is that both containers have a symbolic link to:
overrides/foo/plugins
It doesn't notice when I create the new container to re-do that part. How can I fix it?
Also if I sh to one container and change the symbolic link, it is automatically changed in the other container as well.
docker docker-compose dockerfile
I have a docker-compose.yml
set up like this:
app:
build:
dockerfile: ./docker/app/Dockerfile.dev
image: test/test:${ENV}-test-app
...
Dockerfile
called here has this line present:
...
RUN ln -s ../overrides/${ENV}/plugins ../plugins
...
And there is also a script I am running to get the whole environment up (it is dependant upon several containers so I tried to omit irrelevant info).
It is a bash script and running the following:
ENV=$1 docker-compose -p $1 up -d --force-recreate --build app
What I wanted to achieve is that i can run two app containers at the same time, and this works as follows:
sh initializer.sh foo -> creates foo-test-app container
sh initializer.sh bar -> creates bar-test-app container
Now the issue I'm having is that even when I have --force-recreate
flag present two images created actually are seen as the same image with two different tags.
And what this does when I inspect the containers is that both containers have a symbolic link to:
overrides/foo/plugins
It doesn't notice when I create the new container to re-do that part. How can I fix it?
Also if I sh to one container and change the symbolic link, it is automatically changed in the other container as well.
docker docker-compose dockerfile
docker docker-compose dockerfile
edited 2 hours ago
asked 2 hours ago
Norgul
1,51611538
1,51611538
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
$ENV in your dockerfile is not the same as the one in your compose file.
When you run docker-compose up
, it can be roughly seen as a docker build
followed by a docker run
. So Docker builds the image, layer by layer, at that stage there is not env called ENV. Only at docker run
will $ENV be used.
Environment variables at build stage can be used though, they are passed via ARG
// compose.yml
build:
context: frontend
args:
- BUILD_ENV=${BUILD_ENV}
// dockerfile
ARG BUILD_ENV
RUN ./node_modules/.bin/ng build --$BUILD_ENV
You can do this to solve your problem however this will create one image per project, which you may not want. Or you can do it in an entrypoint script.
How does it initialize the first time if it is not the same$ENV
?
– Norgul
2 hours ago
1
I don't know, I guess you have it set in other script? Anyway, if you add a build ARG, it will invalidate the cache and create a new build which solves your problem
– Siyu
1 hour ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
$ENV in your dockerfile is not the same as the one in your compose file.
When you run docker-compose up
, it can be roughly seen as a docker build
followed by a docker run
. So Docker builds the image, layer by layer, at that stage there is not env called ENV. Only at docker run
will $ENV be used.
Environment variables at build stage can be used though, they are passed via ARG
// compose.yml
build:
context: frontend
args:
- BUILD_ENV=${BUILD_ENV}
// dockerfile
ARG BUILD_ENV
RUN ./node_modules/.bin/ng build --$BUILD_ENV
You can do this to solve your problem however this will create one image per project, which you may not want. Or you can do it in an entrypoint script.
How does it initialize the first time if it is not the same$ENV
?
– Norgul
2 hours ago
1
I don't know, I guess you have it set in other script? Anyway, if you add a build ARG, it will invalidate the cache and create a new build which solves your problem
– Siyu
1 hour ago
add a comment |
up vote
0
down vote
$ENV in your dockerfile is not the same as the one in your compose file.
When you run docker-compose up
, it can be roughly seen as a docker build
followed by a docker run
. So Docker builds the image, layer by layer, at that stage there is not env called ENV. Only at docker run
will $ENV be used.
Environment variables at build stage can be used though, they are passed via ARG
// compose.yml
build:
context: frontend
args:
- BUILD_ENV=${BUILD_ENV}
// dockerfile
ARG BUILD_ENV
RUN ./node_modules/.bin/ng build --$BUILD_ENV
You can do this to solve your problem however this will create one image per project, which you may not want. Or you can do it in an entrypoint script.
How does it initialize the first time if it is not the same$ENV
?
– Norgul
2 hours ago
1
I don't know, I guess you have it set in other script? Anyway, if you add a build ARG, it will invalidate the cache and create a new build which solves your problem
– Siyu
1 hour ago
add a comment |
up vote
0
down vote
up vote
0
down vote
$ENV in your dockerfile is not the same as the one in your compose file.
When you run docker-compose up
, it can be roughly seen as a docker build
followed by a docker run
. So Docker builds the image, layer by layer, at that stage there is not env called ENV. Only at docker run
will $ENV be used.
Environment variables at build stage can be used though, they are passed via ARG
// compose.yml
build:
context: frontend
args:
- BUILD_ENV=${BUILD_ENV}
// dockerfile
ARG BUILD_ENV
RUN ./node_modules/.bin/ng build --$BUILD_ENV
You can do this to solve your problem however this will create one image per project, which you may not want. Or you can do it in an entrypoint script.
$ENV in your dockerfile is not the same as the one in your compose file.
When you run docker-compose up
, it can be roughly seen as a docker build
followed by a docker run
. So Docker builds the image, layer by layer, at that stage there is not env called ENV. Only at docker run
will $ENV be used.
Environment variables at build stage can be used though, they are passed via ARG
// compose.yml
build:
context: frontend
args:
- BUILD_ENV=${BUILD_ENV}
// dockerfile
ARG BUILD_ENV
RUN ./node_modules/.bin/ng build --$BUILD_ENV
You can do this to solve your problem however this will create one image per project, which you may not want. Or you can do it in an entrypoint script.
answered 2 hours ago
Siyu
841416
841416
How does it initialize the first time if it is not the same$ENV
?
– Norgul
2 hours ago
1
I don't know, I guess you have it set in other script? Anyway, if you add a build ARG, it will invalidate the cache and create a new build which solves your problem
– Siyu
1 hour ago
add a comment |
How does it initialize the first time if it is not the same$ENV
?
– Norgul
2 hours ago
1
I don't know, I guess you have it set in other script? Anyway, if you add a build ARG, it will invalidate the cache and create a new build which solves your problem
– Siyu
1 hour ago
How does it initialize the first time if it is not the same
$ENV
?– Norgul
2 hours ago
How does it initialize the first time if it is not the same
$ENV
?– Norgul
2 hours ago
1
1
I don't know, I guess you have it set in other script? Anyway, if you add a build ARG, it will invalidate the cache and create a new build which solves your problem
– Siyu
1 hour ago
I don't know, I guess you have it set in other script? Anyway, if you add a build ARG, it will invalidate the cache and create a new build which solves your problem
– Siyu
1 hour ago
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53371479%2fdocker-containers-out-of-same-image-dont-work-as-expected%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown