Update docker

Author: viet34tqc

docker.md

@@ -408,9 +408,13 @@ volumes:
     name: nest-prisma-docker-db
 ```
 
-After create docker-compose file, run this command: `docker compose up -d`
+After create docker-compose file, run this command: `docker compose up -d`. This command Starts your services in detached mode (running in the background) and build the images if they don't exist. Otherwise, it uses existing images
 
-**Wait for db run first**:
+You can also use `docker compose up -d --build` to forces a rebuild of the images regardless of whether an image already exists. It ensures that any changes in your Dockerfile or build context are incorporated into the new image.
+
+Using --build is particularly useful when you've updated your code or Dockerfile and want to make sure your containers are running the latest version.
+
+### Wait for db run first
 
 App can run already while db needs time to set up => we need to wait for db run first before running app
 
@@ -434,6 +438,35 @@ mysql:
       retries: 20
 ```
 
+## ENTRYPOINT
+
+The purpose of
+
+```Dockerfile
+ENTRYPOINT ["./entrypoint.sh"]
+```
+
+is to set entrypoint.sh as the entry point for the container. This means when the container starts, it will always execute `entrypoint.sh` first before running any command specified in CMD or provided at runtime.
+
+Why Use ENTRYPOINT?
+
+1. Ensures a Script Runs Before Anything Else
+  - `entrypoint.sh` can be used to prepare the environment before the main process starts, such as:
+    - Replacing environment variables in configuration files
+    - Running database migrations
+    - Checking for required services (e.g., waiting for a database to be ready)
+2. Allows Custom Commands While Keeping the Default Behavior
+If you define:
+
+```
+ENTRYPOINT ["./entrypoint.sh"]
+CMD ["nginx", "-g", "daemon off;"]
+```
+
+  - The container will always execute entrypoint.sh first.
+  - After entrypoint.sh finishes, it will run nginx -g 'daemon off;' (from CMD).
+  - You can override CMD at runtime, but ENTRYPOINT will still execute first.
+
 ## Optimize docker image size
 
 <https://github.com/webuild-community/advent-of-frontend/blob/main/2022/day-23.md>

micro-frontend.md

@@ -142,7 +142,11 @@ new ModuleFederationPlugin({
 new ModuleFederationPlugin({
   name: 'host',
   remotes: {
-    remoteAppContainer: 'remoteApp@http://localhost:3001/remoteEntry.js', // remoateAppContainer is like the alias of the remote container
+    // remoteAppContainer is like the alias of the remote container.
+    // remoteApp is the 'name' the remote container
+    // Basically, in the host app, when it read the remoteEntry.js file, there will be a global variable named `remoteApp`
+    // You can read this line as: Go to fetch remoteApp's remoteEntry file and name it as remoteAppContainer
+    remoteAppContainer: 'remoteApp@http://localhost:3001/remoteEntry.js', 
   },
   shared: {
     react: { singleton: true, requiredVersion: '^18.0.0' },
@@ -154,7 +158,7 @@ new ModuleFederationPlugin({
 - singleton: true → Ensures only one instance of React is used across all apps.
 - requiredVersion → Ensures a compatible version is used.
 
-Then inside host app, we import the module like this: `import remoteAppContainer/Button`
+Then inside host app, we import the module like this: `import remoteAppContainer/Button`. You can think of other remote container as a package and `remoteAppContainer` is the name of the package. Inside remote container, there are lots of exported modules. In this example, the module is `Button`.
 
 #### Dynamic loading