Mixing
docker compose always building the Dockerfile thus it does not depend on db
I have a Dockerfile which is actually building a maven spring boot project. My docker-compose.yml is bellow
version: '3'
services:
db:
image: mysql
restart: always
environment:
- MYSQL_DATABASE=calero
- MYSQL_ROOT_PASSWORD=root
volumes:
- ./db:/var/lib/mysql
ports:
- "3306:3306"
phpmyadmin:
image: phpmyadmin/phpmyadmin
restart: always
environment:
PMA_ARBITRARY: 1
MYSQL_ROOT_PASSWORD: root
ports:
- "8082:80"
links:
- "db:db"
redsparrow:
build: .
restart: always
ports:
- "8081:8080"
links:
- "db:db"
depends_on:
- db
volumes:
db:
driver: "local"
And the Dockerfile is this
FROM maven:3.6.0-jdk-11 as build
WORKDIR /app
COPY . /app
RUN mvn clean package
FROM tomcat
COPY context.xml /usr/local/tomcat/webapps/manager/META-INF/context.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY --from=build /app/target/*.war /usr/local/tomcat/webapps
But what I am facing here docker-compose always try to build the redsparrow before spinning up the mySQL container and mvn clean package trying to access the database as it is not up then, the build does not get succeed.
I think I am missing something so that the spring boot app (redsparrow) should always get built after the database container is up.
Please help!
docker docker-compose
asked Jan 1 at 20:59
Dave BDave B
135113
add a comment |
I have a Dockerfile which is actually building a maven spring boot project. My docker-compose.yml is bellow
version: '3'
services:
db:
image: mysql
restart: always
environment:
- MYSQL_DATABASE=calero
- MYSQL_ROOT_PASSWORD=root
volumes:
- ./db:/var/lib/mysql
ports:
- "3306:3306"
phpmyadmin:
image: phpmyadmin/phpmyadmin
restart: always
environment:
PMA_ARBITRARY: 1
MYSQL_ROOT_PASSWORD: root
ports:
- "8082:80"
links:
- "db:db"
redsparrow:
build: .
restart: always
ports:
- "8081:8080"
links:
- "db:db"
depends_on:
- db
volumes:
db:
driver: "local"
And the Dockerfile is this
FROM maven:3.6.0-jdk-11 as build
WORKDIR /app
COPY . /app
RUN mvn clean package
FROM tomcat
COPY context.xml /usr/local/tomcat/webapps/manager/META-INF/context.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY --from=build /app/target/*.war /usr/local/tomcat/webapps
But what I am facing here docker-compose always try to build the redsparrow before spinning up the mySQL container and mvn clean package trying to access the database as it is not up then, the build does not get succeed.
I think I am missing something so that the spring boot app (redsparrow) should always get built after the database container is up.
Please help!
docker docker-compose
asked Jan 1 at 20:59
Dave BDave B
135113
add a comment |
I have a Dockerfile which is actually building a maven spring boot project. My docker-compose.yml is bellow
version: '3'
services:
db:
image: mysql
restart: always
environment:
- MYSQL_DATABASE=calero
- MYSQL_ROOT_PASSWORD=root
volumes:
- ./db:/var/lib/mysql
ports:
- "3306:3306"
phpmyadmin:
image: phpmyadmin/phpmyadmin
restart: always
environment:
PMA_ARBITRARY: 1
MYSQL_ROOT_PASSWORD: root
ports:
- "8082:80"
links:
- "db:db"
redsparrow:
build: .
restart: always
ports:
- "8081:8080"
links:
- "db:db"
depends_on:
- db
volumes:
db:
driver: "local"
And the Dockerfile is this
FROM maven:3.6.0-jdk-11 as build
WORKDIR /app
COPY . /app
RUN mvn clean package
FROM tomcat
COPY context.xml /usr/local/tomcat/webapps/manager/META-INF/context.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY --from=build /app/target/*.war /usr/local/tomcat/webapps
But what I am facing here docker-compose always try to build the redsparrow before spinning up the mySQL container and mvn clean package trying to access the database as it is not up then, the build does not get succeed.
I think I am missing something so that the spring boot app (redsparrow) should always get built after the database container is up.
Please help!
docker docker-compose
asked Jan 1 at 20:59
Dave BDave B
135113
I have a Dockerfile which is actually building a maven spring boot project. My docker-compose.yml is bellow
version: '3'
services:
db:
image: mysql
restart: always
environment:
- MYSQL_DATABASE=calero
- MYSQL_ROOT_PASSWORD=root
volumes:
- ./db:/var/lib/mysql
ports:
- "3306:3306"
phpmyadmin:
image: phpmyadmin/phpmyadmin
restart: always
environment:
PMA_ARBITRARY: 1
MYSQL_ROOT_PASSWORD: root
ports:
- "8082:80"
links:
- "db:db"
redsparrow:
build: .
restart: always
ports:
- "8081:8080"
links:
- "db:db"
depends_on:
- db
volumes:
db:
driver: "local"
And the Dockerfile is this
FROM maven:3.6.0-jdk-11 as build
WORKDIR /app
COPY . /app
RUN mvn clean package
FROM tomcat
COPY context.xml /usr/local/tomcat/webapps/manager/META-INF/context.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY --from=build /app/target/*.war /usr/local/tomcat/webapps
But what I am facing here docker-compose always try to build the redsparrow before spinning up the mySQL container and mvn clean package trying to access the database as it is not up then, the build does not get succeed.
I think I am missing something so that the spring boot app (redsparrow) should always get built after the database container is up.
Please help!
docker docker-compose
docker docker-compose
asked Jan 1 at 20:59
Dave BDave B
135113
asked Jan 1 at 20:59
Dave BDave B
135113
asked Jan 1 at 20:59
Dave BDave B
135113
asked Jan 1 at 20:59
Dave BDave B
135113
asked Jan 1 at 20:59
Dave BDave B
135113
135113
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
As far as I know, the docker-compose.yml configuration doesn't provide the feature you outline in your question. The image of the service containing the build: . option will always be built in isolation. However, you could achieve what you want in other ways.
To sum up, the service at issue is a dockerized Java/Maven/Spring-Boot project that relies on a dockerized MySQL database, and accessing that database is required to build you project with mvn clean package, probably due to the presence of integration tests in the test Maven phase.
To overcome this, I see two possible approaches (the first approach being less standard and less easy to implement than the second one; so I'll elaborate mostly on the latter):
You could rely on the docker-maven-plugin to spin the MySQL container directly from Maven. See also this blog article. The practical issue here will be that the
dockercommands are not directly available inside the considered Docker container, unless you rely on DinD (Docker-in-Docker).
A simpler approach would involve adapting the tests themselves rather than changing the docker setup:
- this is closer to standard conventions assuming
mvn test(triggered bymvn package) targets unit tests, whilemvn verify(relying on the failsafe Maven plugin) targets integration tests, involving external databases or services; - still, if you want to keep all the same a number of unit tests involving database operations, you might want to use an in-memory database engine such as H2, which is often used in the context of Spring Boot unit tests (see e.g. that tutorial);
then, you could move your integration tests in an extra docker-compose service, following the approach outline in this tutorial and that article, for example:
integrationtest:
build: ./integrationtest
command: ./wait-for-it.sh -h db -p 3306 -s -t 150 -- mvn verify
depends:
- db
- this is closer to standard conventions assuming
As an aside, note that the links: property is now deprecated.
Note also that the above .yml excerpt relies on wait-for-it because the depends: property only waits for dependencies' containers to be started, not to be fully ready.
answered Jan 2 at 16:28
ErikMDErikMD
2,4711421
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2f53998900%2fdocker-compose-always-building-the-dockerfile-thus-it-does-not-depend-on-db%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
As far as I know, the docker-compose.yml configuration doesn't provide the feature you outline in your question. The image of the service containing the build: . option will always be built in isolation. However, you could achieve what you want in other ways.
To sum up, the service at issue is a dockerized Java/Maven/Spring-Boot project that relies on a dockerized MySQL database, and accessing that database is required to build you project with mvn clean package, probably due to the presence of integration tests in the test Maven phase.
To overcome this, I see two possible approaches (the first approach being less standard and less easy to implement than the second one; so I'll elaborate mostly on the latter):
You could rely on the docker-maven-plugin to spin the MySQL container directly from Maven. See also this blog article. The practical issue here will be that the
dockercommands are not directly available inside the considered Docker container, unless you rely on DinD (Docker-in-Docker).
A simpler approach would involve adapting the tests themselves rather than changing the docker setup:
- this is closer to standard conventions assuming
mvn test(triggered bymvn package) targets unit tests, whilemvn verify(relying on the failsafe Maven plugin) targets integration tests, involving external databases or services; - still, if you want to keep all the same a number of unit tests involving database operations, you might want to use an in-memory database engine such as H2, which is often used in the context of Spring Boot unit tests (see e.g. that tutorial);
then, you could move your integration tests in an extra docker-compose service, following the approach outline in this tutorial and that article, for example:
integrationtest:
build: ./integrationtest
command: ./wait-for-it.sh -h db -p 3306 -s -t 150 -- mvn verify
depends:
- db
- this is closer to standard conventions assuming
As an aside, note that the links: property is now deprecated.
Note also that the above .yml excerpt relies on wait-for-it because the depends: property only waits for dependencies' containers to be started, not to be fully ready.
answered Jan 2 at 16:28
ErikMDErikMD
2,4711421
add a comment |
As far as I know, the docker-compose.yml configuration doesn't provide the feature you outline in your question. The image of the service containing the build: . option will always be built in isolation. However, you could achieve what you want in other ways.
To sum up, the service at issue is a dockerized Java/Maven/Spring-Boot project that relies on a dockerized MySQL database, and accessing that database is required to build you project with mvn clean package, probably due to the presence of integration tests in the test Maven phase.
To overcome this, I see two possible approaches (the first approach being less standard and less easy to implement than the second one; so I'll elaborate mostly on the latter):
You could rely on the docker-maven-plugin to spin the MySQL container directly from Maven. See also this blog article. The practical issue here will be that the
dockercommands are not directly available inside the considered Docker container, unless you rely on DinD (Docker-in-Docker).
A simpler approach would involve adapting the tests themselves rather than changing the docker setup:
- this is closer to standard conventions assuming
mvn test(triggered bymvn package) targets unit tests, whilemvn verify(relying on the failsafe Maven plugin) targets integration tests, involving external databases or services; - still, if you want to keep all the same a number of unit tests involving database operations, you might want to use an in-memory database engine such as H2, which is often used in the context of Spring Boot unit tests (see e.g. that tutorial);
then, you could move your integration tests in an extra docker-compose service, following the approach outline in this tutorial and that article, for example:
integrationtest:
build: ./integrationtest
command: ./wait-for-it.sh -h db -p 3306 -s -t 150 -- mvn verify
depends:
- db
- this is closer to standard conventions assuming
As an aside, note that the links: property is now deprecated.
Note also that the above .yml excerpt relies on wait-for-it because the depends: property only waits for dependencies' containers to be started, not to be fully ready.
answered Jan 2 at 16:28
ErikMDErikMD
2,4711421
add a comment |
As far as I know, the docker-compose.yml configuration doesn't provide the feature you outline in your question. The image of the service containing the build: . option will always be built in isolation. However, you could achieve what you want in other ways.
To sum up, the service at issue is a dockerized Java/Maven/Spring-Boot project that relies on a dockerized MySQL database, and accessing that database is required to build you project with mvn clean package, probably due to the presence of integration tests in the test Maven phase.
To overcome this, I see two possible approaches (the first approach being less standard and less easy to implement than the second one; so I'll elaborate mostly on the latter):
You could rely on the docker-maven-plugin to spin the MySQL container directly from Maven. See also this blog article. The practical issue here will be that the
dockercommands are not directly available inside the considered Docker container, unless you rely on DinD (Docker-in-Docker).
A simpler approach would involve adapting the tests themselves rather than changing the docker setup:
- this is closer to standard conventions assuming
mvn test(triggered bymvn package) targets unit tests, whilemvn verify(relying on the failsafe Maven plugin) targets integration tests, involving external databases or services; - still, if you want to keep all the same a number of unit tests involving database operations, you might want to use an in-memory database engine such as H2, which is often used in the context of Spring Boot unit tests (see e.g. that tutorial);
then, you could move your integration tests in an extra docker-compose service, following the approach outline in this tutorial and that article, for example:
integrationtest:
build: ./integrationtest
command: ./wait-for-it.sh -h db -p 3306 -s -t 150 -- mvn verify
depends:
- db
- this is closer to standard conventions assuming
As an aside, note that the links: property is now deprecated.
Note also that the above .yml excerpt relies on wait-for-it because the depends: property only waits for dependencies' containers to be started, not to be fully ready.
answered Jan 2 at 16:28
ErikMDErikMD
2,4711421
As far as I know, the docker-compose.yml configuration doesn't provide the feature you outline in your question. The image of the service containing the build: . option will always be built in isolation. However, you could achieve what you want in other ways.
To sum up, the service at issue is a dockerized Java/Maven/Spring-Boot project that relies on a dockerized MySQL database, and accessing that database is required to build you project with mvn clean package, probably due to the presence of integration tests in the test Maven phase.
To overcome this, I see two possible approaches (the first approach being less standard and less easy to implement than the second one; so I'll elaborate mostly on the latter):
You could rely on the docker-maven-plugin to spin the MySQL container directly from Maven. See also this blog article. The practical issue here will be that the
dockercommands are not directly available inside the considered Docker container, unless you rely on DinD (Docker-in-Docker).
A simpler approach would involve adapting the tests themselves rather than changing the docker setup:
- this is closer to standard conventions assuming
mvn test(triggered bymvn package) targets unit tests, whilemvn verify(relying on the failsafe Maven plugin) targets integration tests, involving external databases or services; - still, if you want to keep all the same a number of unit tests involving database operations, you might want to use an in-memory database engine such as H2, which is often used in the context of Spring Boot unit tests (see e.g. that tutorial);
then, you could move your integration tests in an extra docker-compose service, following the approach outline in this tutorial and that article, for example:
integrationtest:
build: ./integrationtest
command: ./wait-for-it.sh -h db -p 3306 -s -t 150 -- mvn verify
depends:
- db
- this is closer to standard conventions assuming
As an aside, note that the links: property is now deprecated.
Note also that the above .yml excerpt relies on wait-for-it because the depends: property only waits for dependencies' containers to be started, not to be fully ready.
answered Jan 2 at 16:28
ErikMDErikMD
2,4711421
edited Jan 3 at 18:26
answered Jan 2 at 16:28
ErikMDErikMD
2,4711421
answered Jan 2 at 16:28
ErikMDErikMD
2,4711421
answered Jan 2 at 16:28
ErikMDErikMD
2,4711421
2,4711421
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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%2f53998900%2fdocker-compose-always-building-the-dockerfile-thus-it-does-not-depend-on-db%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
