Build, tag, and run a container with port mapping

WHAT THIS TESTS It checks fluency with the two commands every Docker user runs constantly, plus the small but easy-to-reverse details around tagging, build context, and port publishing.

A GOOD ANSWER COVERS To build and tag: docker build -t my-app:1.0 . The -t flag assigns the repository:tag name, and the final dot is the build context, the directory sent to the daemon and the root for COPY paths. To run detached with a port mapping: docker run -d -p 8080:80 my-app:1.0. The -d flag runs it in the background and prints the container ID; -p publishes a port using host:container ordering, so 8080 on the host forwards to 80 inside the container. A strong candidate notes that EXPOSE in the Dockerfile only documents the port; -p is what actually publishes it.

COMMON WRONG ANSWERS Reversing the mapping as -p 80:8080. Forgetting the trailing dot, so the build has no context. Believing EXPOSE alone makes the service reachable from the host. Confusing -d with -it.

LIKELY FOLLOW-UPS What does the build context dot do? How is -p different from EXPOSE? How would you publish to a specific host interface, or let Docker pick a random host port?

ONE CONCRETE EXAMPLE After docker build -t my-app:1.0 ., you run docker run -d -p 8080:80 my-app:1.0. The container starts in the background; visiting http://localhost:8080 reaches the web server listening on port 80 inside the container, and docker ps shows the 0.0.0.0:8080->80/tcp mapping.