danielpm1982/meeting-app repository overview

⁠meeting-app

This is a Docker Image with a sample Meeting Management Web App developed with Spring Boot 2

© 2022 Daniel Pinheiro Maia All Rights Reserved
(see Copyright© License at the end of this text).

⁠How to run:

v.1.0.0⁠: this is a standalone spring boot image, with no additional dependencies other than those inside it, including an in-memory and in-built relational DBMS: H2. No data remains persisted after the application or its container is exited / stopped. On each container start all data is reset to its default.
Sources available at: github.com/danielpm1982/springboot2-meeting-mng/tree/master⁠

For running Meeting App v.1.0.0, just use:

sudo docker run -it -p 8080:8080 danielpm1982/meeting-app:v.1.0.0

and then test it through localhost:8080/ path, at your browser.


v.2.0.0⁠: this is a spring boot image which depends on another image - mysql⁠ - to run. The mysql image container, with the database and tables created, will guarantee the persistence of data even after the web application is closed or its container stopped. On each container start, all previous existing data, from the mysql set volume, is reused.
Sources available at: github.com/danielpm1982/springboot2-meeting-mng/tree/mysql-db⁠

For running Meeting App v.2.0.0, using docker default bridge network, you can choose either OPTION 1 or OPTION 2 below:

OPTION 1 (not leveraging the full extent of Links nor the best optimization for the run statements):

1.1: sudo docker run --name meeting-app-mysql-container -p 3306:3306 -p 33060:33060 -v [some-absolute-path-in-your-host-machine]:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=[some-root-password] -d mysql:8

1.2: Then, get into the first container (meeting-app-mysql-container) and manually create a database name (e.g. "meeting_app_db"), set the allowed access from any host ('%') and create a user with a username (e.g. "danielpm1982_user") and a password (e.g. "admin"). Initially grant all privileges to that user, so that Hibernate, running inside meeting-app-mysql-container springboot application, can create the tables and schema at meeting-app-mysql-container database. After the tables and schema are created and persisted, you then can restrict the privileges for that user again, if you want:
sudo docker exec -it meeting-app-mysql-container bash
mysql -u root -p
[type the MYSQL_ROOT_PASSWORD set above (e.g. 'root')]
create database [some-database-name, e.g. meeting_app_db];
create user [some-user-name, e.g. 'danielpm1982_user']@'%' identified by [some-user-password, e.g. 'admin'];
grant all on [some-database-name, e.g. meeting_app_db].* to [some-user-name, e.g. 'danielpm1982_user']@'%';
The tables for this database schema are created automatically on the first run of the application by Hibernate, and are automatically populated with the default initial data.

1.3: sudo docker run --name meeting-app-springboot-container --link meeting-app-mysql-container:mysql -p 8080:8080 -e MYSQL_PORT_3306_TCP_ADDR=meeting-app-mysql-container -e MYSQL_PORT_3306_TCP_PORT=3306 -e MYSQL_ENV_MYSQL_DATABASE=[some-database-name] -e MYSQL_ENV_MYSQL_USER=[some-user-name] -e MYSQL_ENV_MYSQL_PASSWORD=[some-user-password] -d danielpm1982/meeting-app:v.2.0.0

and then test it through localhost:8080/ path, at your browser.

Observation: OPTION 1 is NOT an optimized solution because of the run statements of both containers.
- For the mysql container, for instance, as the standalone containers are in a same docker network (default bridge) and linked, there is no need for the source container (mysql) to publish ports (3306 or 33060) to the recipient container(s) (spring boot app), because, by default, all ports declared at one container (in this case at the dockerfile of the mysql image) will be exposed to the other one(s) and no external application (outside the network or outside docker) will need access to the mysql DBMS or the respective database. In fact, these ports should NOT be published unnecessarily to the outside world. Additionally, and still regarding the mysql container run statement, not only the minimum MYSQL_ROOT_PASSWORD (required for running the image), but also all other necessary custom data (MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD) could be set at once, at the same run statement, as environment variables. This better approach avoids the user being forced to get into this source container later for setting that custom data manually. It also enables the share of this data with all recipient containers, automatically.
- For the spring boot app container, this option is also not optimized, because it ignores the automatic environment variable creation at the recipient containers, as well as their dynamic setting with the source container data values, discovered at runtime. Some of these variables, though, will only be created (at the recipient containers) if their corresponding environment variables are declared at the source container. So, for demonstration purposes, and as we did not declare them at the source container, we explicitly and manually created those environment variables at the recipient container, with the same names generated by docker when creating them automatically, and also with the same names used at the spring boot application.properties file (see the sources at the github link above). Some of these variables had already been created and set automatically (others not), and their explicit declaration and setting are completely redundant. Also, in the case of MYSQL_PORT_3306_TCP_ADDR variable, specifically, we reset it manually from the IP of the spring boot container to its name (DNS), proving that the DNS resolution, at the default bridge network, when using links, actually works. At the spring boot application, when the source container DNS is used, its IP will be automatically resolved and used instead.
For optimizing and correcting all those issues, check out the OPTION 2 run statements below - how much simpler and more elegant they are when compared to OPTION 1 statements.

OPTION 2 (leveraging the full extent of Links and the best optimization for the run statements):

2.1: sudo docker run --name meeting-app-mysql-container -v [some-absolute-path-in-your-host-machine]:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=[some-root-password] -e MYSQL_DATABASE=[some-database-name] -e MYSQL_USER=[some-user-name] -e MYSQL_PASSWORD=[some-user-password] -d mysql:8

2.2: sudo docker run --name meeting-app-springboot-container --link meeting-app-mysql-container:mysql -p 8080:8080 -d danielpm1982/meeting-app:v.2.0.0

and then test it through localhost:8080/ path, at your browser.

For running Meeting App v.2.0.0, using user-defined bridge networks, you can choose either OPTION 1 or OPTION 2 below:

OPTION 1 (neither using links nor docker compose - not the best optimization for the run statement):

1.1: sudo docker network create --driver bridge [network name]

1.2: sudo docker run --name meeting-app-mysql-container --network [network name] -v [some-absolute-path-in-your-host-machine]:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=[some-root-password] -e MYSQL_DATABASE=[some-database-name] -e MYSQL_USER=[some-user-name] -e MYSQL_PASSWORD=[some-user-password] -d mysql:8

1.3: sudo docker run --name meeting-app-springboot-container --network [network name] -p 8080:8080 -e MYSQL_PORT_3306_TCP_ADDR=meeting-app-mysql-container -e MYSQL_PORT_3306_TCP_PORT=3306 -e MYSQL_ENV_MYSQL_DATABASE=[some-database-name] -e MYSQL_ENV_MYSQL_USER=[some-user-name] -e MYSQL_ENV_MYSQL_PASSWORD=[some-user-password] -d danielpm1982/meeting-app:v.2.0.0

and then test it through localhost:8080/ path, at your browser.

Observation: as there is no automatic environment variable creation, data sharing or dynamic variable values discovery (at runtime) from the source to the recipient containers when using user-defined bridge networks without docker compose (differently from when using default bridge network with links), all necessary variables and respective values for the dockerized springboot application must be explicitly declared at its run statement (and must match the properties' names at the web app application.properties configuration file). If you check the sources of the spring boot web app available at the github link above, you'll see that those variables used at the application.properties file of the web application must exist (at the container, as env variables) or the application will fall back to the default values (set at the application.properties file), in order to try to connect to the DBMS running at the mysql container. If neither the environment variables exist at the web app container nor the default values at the application.properties file match the respective properties of the database running on the other container (mysql container), the connection from the web app to the mysql database will fail. When using user-defined bridge networks, and for not having to explicitly declare these environment variables at the web app run statements (specially if you have multiple web apps for the same database), and for not having to rely on, or be fixed to, the default values at the application.properties file when running a web app container, a better solution would be to make use of docker compose - the variables will thus be sharable again between the containers (and declared only once at the yaml configuration file). Alternatively, one could try using a common docker volume for the containers, sharing common configuration files, or one could also make use of swarm / kubernetes secrets and configs... all these workarounds being suggested by Docker at its documentation. Next "OPTION" demonstrates how to use docker compose in such cases, which is the best and simplest approach among all others described above.

OPTION 2 (using docker compose - the best optimization):

2.1: use the docker-compose yaml file at the link below to create a local file of same name, at the directory you wanna run this app from, and change whatever customizable values you wish for its environment variables (e.g. MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER and/or MYSQL_PASSWORD):
https://github.com/danielpm1982/springboot2-meeting-mng/blob/mysql-db/docker-compose.yml⁠

2.2: sudo docker compose up

and then test it through localhost:8080/ path, at your browser.

Restriction (for all mysql cases above): if you're running again a previous run container, you should use the same environment variable values used before, regarding not only the mysql host volume path, but all variable values saved internally at the mysql configuration tables, i.e., MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER and MYSQL_PASSWORD values. Otherwise, the spring boot application won't be able to connect to the database, as the new values from the environment variables will differ from those already and previously set at the mysql configuration tables. If you wanna use different values for your environment variables, you can either use another host folder as a volume, losing previous data - this way new databases, tables and users would be created with the new values - or you would have to get into mysql container and change the databases, tables and users manually so that they would match the new values.

⁠Bug Alert - MySQL Official Image !!!

In some cases, MySQL official image seams to take up to 8 minutes to start the DBMS server and socket (at port 3306). Without this initialized, an error keeps appearing, either from inside the container (if used MySQL CLI) or from outside linked applications, including the spring boot app inside the meeting-app docker image. Thus, if you receive the error message: ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2) , when trying to access the database container, just use the sudo docker logs --follow [name of mysql container] command to check when the mysql server and socket actually are ready for use. After mysql is really up and running, everything should work and you can then test the other containers and web apps linked to the MySQL container. This error generally appears only at the first running of the MySQL image/container. More info on the issues below:

https://stackoverflow.com/questions/71600176/mysql-docker-image-takes-too-long-to-startup-the-dbms-server-and-socket-error-2⁠

https://forums.docker.com/t/mysql-official-image-takes-up-8-minutes-to-start-should-start-instantly/122594?u=danielpm1982⁠

⁠Copyright© License

© 2022 Daniel Pinheiro Maia All Rights Reserved
This Docker repository's images are exclusively for academic and individual learning purposes, and are NOT AVAILABLE FOR COMMERCIAL USE, nor have warranty of any type. You're authorized to run / pull them, at your own risk, for individual learning purposes only, but you're NOT ALLOWED to distribute, sublicense and/or sell copies of the whole or of parts of it without explicit and written consent from its owner / author. If you wish to use any of this repository content in any way other than what is expressed above, or publish it anyway or anywhere, please contact this repository owner / author using the contact info below.

Owner and Author of this Docker Hub Repository
Daniel Pinheiro Maia
danielpm1982.com⁠
[email protected]⁠
linkedin.com/in/danielpm1982⁠
Brazil
.