-
Notifications
You must be signed in to change notification settings - Fork 16
Containerized App and DB #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Containerized App and DB #1
Conversation
CodelineAtyab
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please provide clarification for better understanding
| # Copy the pom.xml and the project source code | ||
| COPY pom.xml . | ||
| COPY src ./src | ||
| COPY .env . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a need to copy this .env file inside the container ?. Copying the .env file in the container might not have any benefit.
We have to specify the env file when we run a container directly using docker run OR through docker-compose.
Please provide clarification
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For review purposes it's fine, but we should never push the changes with a .env file. The reason is that, this .env is environment specific. On our PC there might be a MySQL server running locally with a different username and password.
Similarly, Another team member may spin up a container and point to a MySQL server running on cloud.
| EXPOSE 8080 | ||
|
|
||
| # Run the application with .env variables | ||
| ENTRYPOINT ["sh", "-c", "java -jar rihal-0.0.1-SNAPSHOT.jar"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any benefit of running java through "sh" and not directly using ENTRYPOINT ["java", "-jar", "/app/your-application.jar"] ?
| System.setProperty("SPRING_DATASOURCE_USERNAME", dotenv.get("SPRING_DATASOURCE_USERNAME")); | ||
| System.setProperty("SPRING_DATASOURCE_PASSWORD", dotenv.get("SPRING_DATASOURCE_PASSWORD")); | ||
| System.setProperty("SPRING_JPA_HIBERNATE_DDL_AUTO", dotenv.get("SPRING_JPA_HIBERNATE_DDL_AUTO")); | ||
| System.setProperty("SPRING_JPA_SHOW_SQL", dotenv.get("SPRING_JPA_SHOW_SQL")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really needed ?
application.properties are reading the environment variables exposed by the container and setting it.
This happens when we do docker-compose up
For the Docker setup, I specified the build process for the Java Spring Boot application in the Dockerfile, using a .env file to provide necessary environment variables for database connectivity during local development. Docker Compose was created to manage both the MySQL and Spring Boot application services, utilizing the env_file directive to maintain consistent configuration without hardcoding sensitive information. To ensure data persistence across container restarts, Docker volumes were used to mount the MySQL data directory, and both containers were configured to be part of the same Docker network for smooth communication between the application and the database.