Angular 5项目容器化：Express分离与Mongo连接疑问

Hey there! Let's walk through your questions step by step, using your current setup as a reference.

Should I separate my Express server into its own container? #

Absolutely—separating your Express backend from the Angular frontend container is a great practice, and here are the key benefits:

• Single Responsibility Principle: Each container has one clear job: your client container handles the Angular frontend (serving dev builds, compiling assets), while a dedicated server container runs the Express API. This makes debugging, updating, and maintaining each part way easier—you won't have to rebuild the entire stack just to fix a frontend bug or tweak an API endpoint.
• Resource Isolation: Frontend and backend workloads have different resource needs. For example, Angular's ng build can be CPU-intensive, while Express might need more memory for handling API requests. Separating containers lets you allocate resources (like CPU/memory limits) specifically to each service.
• Independent Deployment: You can deploy updates to the frontend or backend separately. If you push a new UI feature, you only need to restart or redeploy the client container—no need to touch the Express server. This reduces deployment risk and downtime.
• Scalability: As your app grows, you can scale each service independently. For example, you could spin up multiple server containers behind a load balancer to handle more API traffic, while serving the Angular static files from a CDN (or scaled client containers) for better performance.

How to adjust your setup for separation: #

1. Create a new server directory in your project root, move your app.js and backend dependencies (like express, mongoose) into it, and add a dedicated Dockerfile for the server:

   FROM node:8.1.4-alpine
   WORKDIR /usr/src/server
   COPY package.json .
   RUN npm install
   COPY . .
   EXPOSE 3000
   CMD ["node", "app.js"]
   

2. Update your docker-compose.yml to add the server service, and adjust the client service to no longer include backend code:

   version: '2'
   services:
     client:
       build: ./client
       volumes:
         - ./client:/usr/src/app
       depends_on:
         - server
     server:
       build: ./server
       volumes:
         - ./server:/usr/src/server
       links:
         - mongo
       depends_on:
         - mongo
     mongo:
       # ... keep your existing mongo config ...
     nginx:
       build: ./nginx
       ports:
         - "80:80"
       links:
         - client
         - server
   

3. Modify your Nginx default.conf to proxy API requests to the server container:

   server {
     location / {
       # ... existing proxy config for client ...
       proxy_pass http://client:4200/;
     }
   
     location /api/ {
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_pass http://server:3000/api/;
     }
   }
   

Is linking the Client container to the Mongo container the right approach? #

Short answer: No, you don't need to link your client container directly to Mongo—and here's why:

Angular is a client-side framework, which means all its code runs in the user's browser. Your frontend should never connect directly to a MongoDB instance (this is a huge security risk, as it would expose your database credentials and internal network to the public). Instead, your Express server should act as an intermediary: the Angular app sends requests to the Express API, which then interacts with MongoDB on behalf of the client.

Fixes for your current setup: #

• Remove the links: - mongo and depends_on: - mongo lines from your client service in docker-compose.yml—they're unnecessary here.
• Ensure your Express server is configured to connect to the mongo container (using the service name mongo as the hostname in your database connection string, e.g., mongodb://mongo:27017/your-db-name).
• Add a readiness check or retry logic in your Express server to handle cases where Mongo might take a few seconds to start up (Docker's depends_on only ensures the container starts, not that the service inside is fully ready).

That said, your Mongo container setup looks solid—using a volume to persist database data (./data/db:/data/db) is the right way to avoid losing data when the container is stopped or recreated.

内容的提问来源于stack exchange，提问作者oudekaas