How do you run Envoy with Docker and what are the basics of containerized deployment?

Think of running Envoy with Docker as setting up a pre-built security checkpoint at a building entrance. The Docker image provides the checkpoint equipment (Envoy binary), you provide the rules for who can enter and which floor they go to (envoy.yaml configuration), and you connect it to the building's entry points (port mappings). Docker ensures the checkpoint runs consistently regardless of the building's infrastructure.

The official Envoy Docker image is published on Docker Hub as envoyproxy/envoy and is available with various tags corresponding to Envoy versions. The image contains the Envoy binary, default configuration, and minimal system dependencies. To run Envoy with a custom configuration, you mount your envoy.yaml file into the container at the default configuration path /etc/envoy/envoy.yaml. Port mappings expose the listener ports and the admin interface port to the host machine. The most basic run command maps the primary listener port (e.g., 10000) and the admin port (9901), mounts the configuration file, and starts the container.

Envoy's Docker image supports several command-line flags that control runtime behavior. The --concurrency flag sets the number of worker threads, which should typically match the number of CPU cores allocated to the container. The --log-level flag sets the initial application log verbosity. The --component-log-level flag allows setting different log levels for different components, such as --component-log-level upstream:debug,connection:trace. The --config-path flag specifies the configuration file location, and --config-yaml allows passing inline YAML configuration for simple setups. The --service-cluster and --service-node flags set metadata that identifies this Envoy instance to the control plane.

In production Docker deployments, Envoy is typically run with resource constraints to prevent it from consuming excessive CPU or memory. Docker's --cpus and --memory flags limit resource usage. Health checks are configured to use the admin interface's /ready endpoint, ensuring the container orchestrator knows when Envoy is ready to accept traffic. The container should run as a non-root user for security, and the admin interface should only be bound to localhost or an internal network. When running Envoy alongside an application in Docker Compose, both containers share a Docker network, allowing Envoy to reach the application by container name.

A common beginner mistake is running Envoy without validating the configuration first. Envoy provides a --mode validate flag that checks the configuration file for syntax errors and semantic issues without actually starting the proxy. Always validate configuration changes before deploying them. Another gotcha is forgetting to expose the admin port for debugging. While the admin interface should not be publicly accessible, having it available internally is essential for troubleshooting. In Docker Compose environments, define the admin port mapping only for development profiles and exclude it from production configurations. File permission issues with mounted configuration files are another frequent problem: ensure the Envoy user inside the container has read access to the mounted envoy.yaml file.