[New] Ultimate Docker Bootcamp for ML, GenAI and Agentic AI

Kick off your first project: a machine learning dev environment built with Docker instead of local installs. You will run JupyterLab notebooks for development and MLflow for experiment tracking, both as containers, so the whole setup becomes a portable package anyone on your team can launch in one or two commands. After this you understand the project goal and what container skills you will pick up while building it.

Learn the core Docker vocabulary: images, containers, registries, and repositories. You will pull the official MLflow image from GitHub Container Registry, read the full image name field by field (registry, organization, repository, tag), and see how image layers make distribution efficient. After this you can use docker pull and docker image ls with confidence and know exactly where an image comes from and what its name means.

Run your first container with docker run and launch MLflow for experiment tracking. You will learn port mapping with the -p flag, why the container port differs from your host port, and how to reach the MLflow web UI in your browser. Watching docker system events, you will see the pull, create, attach, network, and start steps happen live. After this you can launch a container and connect to the app inside it.

Master everyday container operations. You will run containers in the background with the -d flag, list them using docker ps and its -a, -l, and -n options, and start, stop, and remove containers by ID or name. You will also check logs with docker logs -f, get a shell inside with docker exec, and name your containers. After this you can run and manage long-lived containers instead of getting stuck in an attached session.

Run JupyterLab in a container with a volume mounted from your host, so your notebooks survive even if the container is deleted. You will mount a local directory with the -v flag, find the login token in docker logs, and edit files that stay in sync between the container and your machine. After this you can set up a persistent, shareable ML development environment and know why volumes matter for your work.

Write and run your first machine learning workflow inside a container-hosted JupyterLab notebook. You will load the classic Iris dataset from scikit-learn, train a logistic regression model, and read the accuracy score and confusion matrix to judge how well it predicts. By the end you can build a notebook cell by cell, mix Python code with markdown notes, and open the same file later in VS Code.

Connect two running containers so your notebook can log experiments to MLflow for tracking. You will use the special host.docker.internal hostname to reach MLflow across the port mapping, pip install MLflow inside the Jupyter container, and log a linear regression run with its metrics and model artifact. After this you can track experiments, compare runs, and clean up containers with stop, rm, and prune.

Meet Project Nebula, your hands-on mission to containerize the Tech Stack Advisor ML app and deploy it to Hugging Face Spaces. You will fork the starter repo, train the model locally, build and validate the container, push the image to Docker Hub, and ship it live. The lecture walks through the product spec, prerequisites like Docker, UV, and git, and how to showcase your finished work on LinkedIn.

Get the Tech Stack Advisor running on your own machine before you containerize anything. You will fork and clone the repo, set up a Python 3.11 virtual environment with UV, install dependencies from requirements.txt, and run train.py to generate the model and encoder pickle files. Then you launch the Gradio app on port 7860 and watch it predict a tech stack from your inputs.

Understand why building a container image by hand first makes Dockerfiles click later. This lecture maps the manual, imperative approach step by step: clone the code, pull a base image, launch a build container, copy the source, run pip install, test the app, then commit it into an image. Think of it like building a VM and taking a snapshot, so you know exactly what the Dockerfile will automate.

Put the manual approach into action and build a real container image without a Dockerfile. You will pull the official python:3.11-slim base, run a dev container with port mapping, use docker cp to copy the source, exec in to run pip install, and launch the app to test it. Then you tag it with your Docker Hub username and turn the container into an image using docker container commit.

Turn the manual steps into a Dockerfile and build the image the recommended way. You will place a Dockerfile at the repo root, run docker image build with a tag and the build context dot, and see how a .dockerignore file keeps the virtual environment out to shrink the image. After building, you launch a container from the image and confirm the app comes up and predicts correctly.

Compare the manually built image against the Dockerfile-built one and see why the Dockerfile version wins. Using docker image history you will read the layers, understand the iterative build that commits one instruction at a time, and see why the Dockerfile image is smaller and knows which port and command to run. Then you tag an image as latest and push both versions to Docker Hub with docker image push.

Read a Dockerfile line by line and understand what each instruction actually does. You will learn FROM for the base image, WORKDIR for where commands run, COPY for bringing in code, RUN for build-time steps like pip install, EXPOSE for the app port, and CMD for launch-time. You will also see why combining commands into one RUN reduces layers and keeps your image small.

Deploy your containerized Tech Stack Advisor live on Hugging Face Spaces for free. You will create a Docker Space, add Hugging Face as a git remote, and force push your code and model files so it builds and runs the image automatically. You will also debug a real Gradio flagging permission error by pointing it at a writable /tmp path, then watch the app go live and make predictions.

Get the brief for a hands-on project where you build a production-like ML dev environment with Docker Compose. You will stand up a house price prediction app with a Streamlit front end, a FastAPI model server, and MLflow for experiment tracking, all wired together in one stack. After this you will know how to codify a full local ML setup that a new teammate can spin up in minutes instead of copying long docker run commands.

Walk through the house price predictor stack before you build it, so the pieces make sense. You will see how the Streamlit UI calls the FastAPI backend, why the model gets wrapped in FastAPI instead of served as a raw pickle file, and where MLflow fits in the training workflow. By the end you can map out the three services and the data-to-model flow, then fork and clone the repo to start building.

Turn a manual docker run command for MLflow into a Docker Compose spec you can share and version control. You will learn the compose.yaml syntax step by step, define a service with image, ports, and command, and mind the YAML indentation rules. After this you can launch MLflow with docker compose up, then use logs, exec, stop, start, and down to manage it, so your whole team gets the same environment every time.

Run the full ML pipeline that produces the model artifacts you will later package. You will set up a virtual environment with uv, install requirements, and run the pipeline script that cleans raw data, builds features, trains the model, and logs everything to MLflow. By the end you will have a model pickle file and preprocessor ready for containerizing, plus experiments, metrics, and hyperparameters you can inspect in the MLflow UI.

Build a multi-service Docker Compose spec that packages both the FastAPI model server and the Streamlit UI. You will add build context and Dockerfile settings so Compose builds the images for you, tag them with your Docker Hub username, and map the ports each app runs on. After this you can run docker compose build and up to bring both services live in parallel, and you will spot the service-to-service connection problem we fix next.

Fix why Streamlit cannot reach FastAPI and understand what localhost really means inside a container. You will learn how Docker Compose gives every service a DNS name automatically, so you connect by service name instead of a changing IP address, wired through an environment variable. After this you can use service discovery to link containers, apply changes with an idempotent docker compose up, and hand a working dev environment to any teammate in minutes.

Get the brief for a project where you connect a LocalGPT app to an LLM running on your own machine. The app ships with a FastAPI service and a Gradio UI, and your job is to serve the model with Docker Model Runner instead of a hosted API. After this you will understand how to run local inference with no internet needed, pull models from Docker Hub, and wire it all into Docker Compose.

Learn what Docker Model Runner is and get it enabled on your machine. You will check the hardware and Docker version it needs, turn it on from Docker Desktop or the command line, and switch on host-side TCP support so apps outside a container can reach it. By the end you can confirm the runner is running and reachable on its local port, ready to pull and run models with familiar Docker-style commands.

Pull and run large language models locally using Docker Model Runner and the AI models catalogue on Docker Hub. You will list, inspect, and run models with the same workflow you already use for images, try pulling from Hugging Face, and start an interactive chat session. You will also hit the OpenAI-compatible endpoint from the host, so you can see how any app connects to a locally running LLM, no hosted API required.

Connect the LocalGPT app to your locally running model through an OpenAI-compatible endpoint. You will clone the repo, read how FastAPI reaches the model runner from inside a container, and let the Gradio UI find FastAPI through Compose service discovery. After running docker compose up with the build flag, you will have a working ChatGPT-style app talking to a local LLM, and you will meet the compose bake tool that speeds up parallel image builds.

Bring your local model straight into Docker Compose using the new provider feature. You will define Docker Model Runner as a provider, wire the runner URL and model name into your FastAPI app through environment variables, and swap models like Gemma 3 or SmolLM2 without touching code. By the end you can switch the model behind your app right from the compose spec and redeploy just the service that changed.

This exploratory project sets the stage for the Model Context Protocol and Docker's MCP Toolkit. You will see how MCP connects your LLM to the real world so it can take actions, and how Docker's catalog and Gordon AI make it easy to try. After this you will understand why MCP is the foundation for building AI agents and agentic AI workflows, and be ready to connect tools like the file system and GitHub.

Understand what Model Context Protocol is and why it matters as we move from LLMs to AI agents. Think of MCP as a USB standard: it lets your LLM take actions in the real world, and shifts the burden of writing tool code to the actual providers, which is why MCP servers are exploding. You will also see how Docker's trusted MCP catalog keeps things secure when servers hold access to GitHub, Kubernetes, or your files. After this you can explain how MCP sets the foundation for agentic AI.

Get hands-on with the Docker MCP Toolkit from Docker Desktop. You will install the toolkit as an extension, browse the curated MCP server catalog, and connect the Gordon AI client to a file system MCP server scoped to one safe directory. By the end you can add an MCP server, restrict its access to a specific path, and watch Gordon list files by calling the tool with your permission.

Put the file system MCP server to work through Gordon AI. You will have the LLM generate a Python script, write it into your allowed directory, add test data to a file, then run the script and read back the output, all through MCP tool calls. After this you can see exactly which tool Gordon picks for each step and understand how the LLM chains file operations to finish a real task.

Connect your LLM to GitHub through the official GitHub MCP server, the secure way. You will create a fine-grained personal access token with read-only scope, hand it to the MCP server through Docker instead of a plaintext config, and then list repositories and read commit history from Gordon. By the end you understand how Docker keeps your tokens safe and why a read-only token stops the LLM from creating issues it is not authorized to make.

Give the GitHub MCP server write access and let the LLM run a full workflow on its own. With one detailed prompt, Gordon creates a GitHub issue, generates a FastAPI app with requirements.txt, initializes a local git repository, commits the code, and pushes a new repo to your account. After this you can see how chaining MCP tools together forms a real MCP-based AI agent, the starting point for building agentic AI.