在多树莓派Docker Swarm集群部署ASP.NET Core容器失败求助

Hey there! I see you've already cleared some big hurdles—building your ASP.NET Core image on Windows 10 and running it standalone on a Pi works, so the architecture compatibility is sorted. Let's dig into why your docker stack deploy is failing.

First, let's get concrete error details because vague "deployment failed" messages don't tell us much. Run these commands to diagnose what's going wrong:

1. Check Service and Task Status #

# List all services in your stack
docker stack services <your-stack-name>

# Get detailed task status (use --no-trunc to see full error messages)
docker service ps --no-trunc <your-service-name>

# Follow real-time logs for the service
docker service logs -f <your-service-name>

The docker service ps output will show if tasks are failing to start, being rescheduled, or stuck pulling the image. The logs will reveal specific errors like missing dependencies, port conflicts, or permission issues.

2. Verify Image Access Across Swarm Nodes #

Even if you pushed the image to a registry, it's possible some Swarm nodes can't pull it:

• If you're using a private registry, every node in the Swarm needs to be authenticated to pull the image. Run docker login <your-registry-url> on each Pi node, or use Docker Secrets to store registry credentials centrally (add registry_auth: true to your compose file and create a secret for your .docker/config.json).
• Double-check your image tag in the docker-compose.yml—make sure it matches exactly what you pushed (e.g., your-registry/aspnetcore-app:arm-latest instead of just aspnetcore-app:latest, which might refer to a local x64 image on your Windows machine).

3. Enforce Architecture Constraints in Swarm #

Even though standalone runs work, Swarm might be trying to schedule your service on an incompatible node (if you have any x64 nodes in the cluster by accident). Add a placement constraint to your compose file to force deployment only on ARM nodes:

version: '3.8'
services:
  aspnetcore-app:
    image: your-registry/aspnetcore-app:latest
    ports:
      - "80:8080" # Match your ASP.NET Core listening port (default is 8080)
    deploy:
      replicas: 2
      placement:
        constraints:
          # Use armhf for 32-bit Raspbian, arm64 for 64-bit
          - node.platform.architecture == armhf
      resources:
        limits:
          cpus: '0.5' # Pi's have limited CPU—adjust as needed
          memory: 256M # Prevent the service from eating too much RAM
    networks:
      - app-overlay
networks:
  app-overlay:
    driver: overlay

4. Check Network and Port Configuration #

• Ensure the port in your compose file matches the port your ASP.NET Core app is listening on (default is 8080 if you're using the base ASP.NET Core image).
• If you're using a custom overlay network, make sure it's being created correctly (Swarm handles this automatically when deploying the stack, but sometimes network conflicts can cause issues).

5. Validate Image Architecture #

Double-check that your pushed image is actually built for ARM:

# On a Pi node, pull the image and inspect its architecture
docker pull your-registry/aspnetcore-app:latest
docker image inspect your-registry/aspnetcore-app:latest | grep -A2 "Architecture"

You should see "Architecture": "armhf" or "arm64"—if it shows "amd64", your cross-compilation step might have failed, even though a standalone run worked (maybe you had a local ARM image on that specific Pi).

Once you've run through these steps, you should have a clear idea of why the stack deployment is failing. Most often, it's either a registry authentication issue, a missing architecture constraint, or a misconfigured port/resource limit.

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