在AWS部署WebGoat失败：Dockerfile与Dockerrun.aws.json报错求助

Hey there! Let’s figure out why your WebGoat deployment on AWS Elastic Beanstalk is throwing those Dockerfile/Dockerrun.aws.json errors—especially since it works perfectly locally. I’ve debugged plenty of EB Docker deployments, so here’s a breakdown of the most common issues and how to fix them:

1. Missing or Misplaced Core Files #

Elastic Beanstalk expects your Dockerfile and (if used) Dockerrun.aws.json to be at the root of your uploaded zip file. If you just uploaded the raw GitHub repo zip, chances are these files are nested inside a subfolder (like the main WebGoat directory in the repo).

• Fix: Extract the GitHub zip, move the Dockerfile and any required config files to a new folder’s root, then zip that folder for deployment. Don’t include extra subfolders or hidden .git directories—keep it clean.

2. Invalid Dockerrun.aws.json Syntax #

If you’re using a Dockerrun.aws.json file (for single-container overrides or multi-container setups), even a tiny syntax error (missing comma, unclosed quote, wrong key name) will break the deployment.

For a basic single-container WebGoat setup, your file should look something like this (adjust ports if you’re using non-default ones):

{
  "AWSEBDockerrunVersion": "1",
  "Image": {
    "Name": "webgoat/webgoat-8.0",
    "Update": "true"
  },
  "Ports": [
    {
      "ContainerPort": "8080",
      "HostPort": "80"
    }
  ],
  "Logging": "/var/log/webgoat"
}

• Pro tip: Validate your JSON with a simple lint tool before uploading—saves you from silly syntax headaches.

3. Dockerfile Incompatibility with EB’s Environment #

Your local Docker setup might support commands or base images that don’t play nice with EB’s default EC2 instances. For example:

• Using a base image that requires more CPU/RAM than a t2.micro instance (EB’s default) can lead to build timeouts.
• Running commands as a non-existent user (like USER nonroot) if the EB instance doesn’t have that user created.

Simplify your Dockerfile first to rule out build issues—use the official WebGoat image directly:

FROM webgoat/webgoat-8.0:latest
EXPOSE 8080
CMD ["java", "-jar", "webgoat-server.jar"]

4. Messy Deployment Zip Structure #

EB gets confused if your zip includes unnecessary files or nested folders. Avoid including:

• Hidden directories like .git/ or .github/
• Extra test files, documentation, or unrelated repo assets
• Nested subfolders that don’t relate to the Docker build

Stick to only the files needed for deployment: Dockerfile, Dockerrun.aws.json (if applicable), and any custom configs you need.

5. Wrong EB Platform Selection #

Double-check that you created your EB application with the Docker platform (not Python, Node.js, or another language). Choosing the wrong platform will make EB ignore your Docker files entirely, leading to confusing errors.

If you’re still stuck, grab the full logs from your EB environment:

1. Go to your EB environment dashboard
2. Click Logs → Request Logs → Full Logs
3. Look for lines marked ERROR related to Docker builds or container startup—this will give you the exact issue (like a missing dependency or invalid config).

Also, test your deployment zip locally first: Unzip it, run docker build -t webgoat-test . and docker run -p 8080:8080 webgoat-test. If it fails locally, fix that before deploying to EB—local success is a prerequisite for EB success!

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