Module 17 Exercises: Shipping to the World

Building is only half the battle. Shipping—and keeping it running—is where real engineering happens. These exercises will help you master the bridge to production.

---

Exercise 1: The Worker Architect

You are deploying to a server with 16 vCPUs.

1. Write the gunicorn command you would use to start your FastAPI app (main:app) with the optimal number of Uvicorn workers.
2. Explain why you are choosing that specific number.

---

Exercise 2: The Multi-Stage Dockerfile

Below is a "Bad" Dockerfile that is very large and slow. Identify two mistakes and explain how you would fix them using a Multi-Stage Build.

FROM python:3.11
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "80"]

---

Exercise 3: Designing the Pipeline

You want to ensure that code is never deployed if it has a linting error (i.e., your code is messy).

1. Which stage of the CI/CD pipeline would you add a "Linter" check (like flake8 or ruff)?
2. What happens if the linter fails during a pull request?

---

Self-Correction / Discussion

Exercise 1 Answer:

1. gunicorn main:app -w 17 -k uvicorn.workers.UvicornWorker
2. The standard formula is (2 * CPU) + 1 or CPU + 1. For 16 cores, 17-33 workers is common. It ensures that while some workers are waiting for I/O, others can use the CPU.

Exercise 2 Answer:

Mistake 1: Using python:3.11 (large base image) instead of python:3.11-slim or alpine. Mistake 2: Copying everything (COPY . .) before installing dependencies. This breaks the Docker layer cache (every tiny code change forces a full pip install). Fix: Use a builder stage to install dependencies and then copy only the results to a fresh, slim runtime image.

Exercise 3 Answer:

1. The very first stage (Pre-test). We call this a "Gate".
2. The pipeline stops immediately. The code is not tested, built, or deployed until the developer fixes the formatting errors.

---

Summary of Module 17

You have learned to "Launch":

• ASGI: You understand the high-speed engine of your app.
• Docker: You can package your app to run anywhere.
• CI/CD: You can automate the path from Git to the Cloud.

In Module 18: Observability and Monitoring, we will learn how to "Watch" our app once it's live, using logs and metrics to stay ahead of problems.