Containerization has revolutionized the way we develop and deploy applications. It provides a consistent, isolated, and portable environment, eliminating the classic “it works on my machine” problem. For software developers, this means a more streamlined workflow and a much smoother transition from development to production.
This article will guide you through the process of containerizing a Symfony application using Docker and Docker Compose. We’ll cover everything from defining your application’s environment with a Dockerfile to orchestrating your services with docker-compose.yml.
Containerization provides various benefits, including:
1. Consistency: It ensures that all services are isolated, allowing you to manage them independently. This makes it easier to maintain and scale the application, as each service can be isolated from the others.
2. Portability: Containerized applications are portable, meaning they can be easily moved between environments or deployed on different platforms. This reduces the need to rebuild the entire image every time a new environment is created.
3. Consistent API: Docker images are standardized and provide a consistent API for interacting with the application. This simplifies the deployment process and makes it easier to manage the application’s dependencies.
4. Scalability: By using a monolithic or sidecar pattern, you can easily scale your application across multiple environments, without
Containerization has revolutionized the way we develop and deploy applications. It provides a consistent, isolated, and portable environment, eliminating the classic “it works on my machine” problem.
For software developers, this means a more streamlined workflow and a much smoother transition from development to production.
This article will guide you through the process of containerizing a Symfony application using Docker and Docker Compose. We’ll cover everything from defining your application’s environment with a Dockerfile to orchestrating your services with docker-compose.yml.
Certainly, an application packaged as a Docker image provides us with a significant advantage for future scaling using orchestration tools like Kubernetes.
Let’s dive into the core container deployment strategies for our application. We can either opt for a monolithic container that bundles all services into a single image, leverage the sidecar pattern for managing supplementary processes, or adopt a hybrid, mixed approach tailored to specific needs.
Monolithic Container Strategy
This is the most straightforward approach. You build a single Docker image that includes your main Symfony application and all its dependencies, like a web server (e.g., Nginx) and PHP-FPM. While this simplifies the build process, it creates a large, less flexible image. Any change to a single dependency requires rebuilding the entire image, which can slow down your development workflow. This strategy is ideal for smaller projects or for teams new to containerization, as it closely mimics traditional deployment methods. It’s less suited for complex AI agents that might have multiple, distinct services.
The Sidecar Pattern
The sidecar pattern is a more modern, microservices-oriented approach. Instead of a single container, you run your main application container alongside one or more smaller, dedicated “sidecar” containers within the same Kubernetes pod. These sidecars handle auxiliary tasks like logging, metrics collection, or data synchronization, allowing your main application to focus purely on its core logic. This is perfect for AI agents, where a sidecar could manage a background queue or handle data preprocessing, leading to better scalability and separation of concerns. This approach aligns well with a microservices architecture and is highly recommended for building scalable, production-ready AI systems.
Hybrid Deployment
The hybrid approach combines elements of both. You might have a main container with a few tightly coupled services, while more isolated or specialized tasks (e.g., a background worker for asynchronous tasks) are handled by a sidecar. This strategy offers the best of both worlds: it simplifies the setup for essential services while providing the flexibility and scalability of the sidecar pattern for specific components. It’s a pragmatic choice for projects that evolve over time, allowing you to refactor and optimize specific parts of your application without a complete architectural overhaul. This method is a great starting point for developers aiming for a scalable solution without fully committing to a complex microservices setup from the get-go.
For this practical example, we’ll adopt a hybrid approach. We will assume that essential services like Nginx, PHP-FPM, and Supervisord will be contained within our main application image. This simplified containerization strategy provides an excellent learning foundation.
This approach gives us hands-on experience with the core skills needed to build and deploy a Dockerized Symfony AI agent. While a pure microservices architecture is the standard for complex production environments, this method streamlines the learning process. It offers a perfect balance, equipping you with the fundamental knowledge of Docker image creation and application deployment without the added complexity of a multi-container setup. The skills you gain here are directly transferable, providing a solid stepping stone for transitioning to more advanced Kubernetes and microservices deployments in the future.
Optimizing for Different Use Cases
The build logic for our Docker image will be centered on Supervisord. As the primary process manager, it will handle launching and monitoring all our services, including Nginx, PHP-FPM, and the Symfony message bus consumer. If any of these services fail, Supervisord will automatically restart them, ensuring the application remains robust and reliable.
A key advantage of this containerization strategy is its flexibility. When running a standard web application, the container’s entry point will be Supervisord, which manages all the core services. However, for a different use case, like a one-off command or a scheduled cron job, we can easily override the default entry point. By running the container with a different command — for instance, to execute a specific php bin/console command — Supervisord and its managed services won’t be started. This approach significantly reduces the required computational resources, making the process highly efficient and lightweight.
This dual-purpose capability is crucial for AI-Agent deployments, which often require both long-running services (for API handling) and short-lived, resource-optimized tasks (for data processing or model training). By leveraging this pattern, we can create a single, versatile Docker image that serves multiple functions, simplifying our overall DevOps workflow and ensuring we only use the resources we need.
In a single instance, we can run the application with HTTP/HTTPS access. Additionally, we can launch several instances of the application, with each instance utilizing only a multi-threaded data bus consumer. In the event of a total failure, the container will restart, a process that will be managed by either Docker or Kubernetes.
The Configuration Files (Nginx, PHP, PHP-FPM)
To get started, we’ll prepare the configuration files for our services: Nginx, PHP, and PHP-FPM. These files will be bundled into the Docker image, allowing the services to use them for initialization. If needed, we can easily change these settings at runtime by mounting external volumes, which will override the files inside the container.
By packaging these configuration files directly into the image, we create a reproducible and consistent environment. The files define how the services communicate and behave. For example, the Nginx configuration will tell the web server where to find your Symfony application’s entry point, while the PHP-FPM pool configuration will manage the number of PHP processes available to handle requests.
This approach offers a significant advantage for AI-Agent deployment, as it allows for a standardized setup across different environments — from development to production. The ability to use external volumes provides a powerful way to manage environment-specific settings, such as API keys, database credentials, or debug flags, without needing to rebuild the Docker image. This is a common DevOps practice that enhances security and flexibility.
Essentially, the image provides a reliable default configuration, and external volumes offer a simple, yet robust, mechanism for dynamic adjustments.
To start, we’ll create a docker directory in our project’s root. Inside, we’ll add a prod subdirectory where we’ll place an nginx folder to store its core configuration files.
Why Separate Configurations?
Separating configuration files by environment (e.g., dev, stage, prod) is a fundamental DevOps best practice. This approach gives us the flexibility to build a single, standardized Docker image that can be deployed with different settings depending on the environment. It ensures our application behaves predictably, whether it’s running on a local machine or in a production cluster.
Avoiding the Anti-Pattern
When implementing a proper CI/CD pipeline and following the testing pyramid methodology, it’s crucial to understand a key anti-pattern: rebuilding the Docker image for each environment. This is a mistake that leads to inconsistencies and invalidates our testing efforts. Instead, the same, single image should be promoted and used across all environments — from development to staging and finally to production. Any differences in configuration, such as database credentials or API keys, should be managed externally using environment variables or by mounting different configuration files with volumes. This immutable infrastructure approach guarantees that the code you test is the exact same code you deploy, which is essential for reliable and scalable AI-Agent deployment.
UTC is the Best Practice
One more crucial consideration for our application’s operation is time. In a globalized world, developers, users, and the servers hosting our services are often located in different time zones. This dynamic environment can cause significant issues when tracking process lifecycles and displaying data accurately for the end-user.
To address this, we’ll use UTC (Coordinated Universal Time) inside our Docker image and application. By standardizing on UTC, we create a single, consistent timeline for all our system events, regardless of where the servers or users are located. This approach eliminates common problems related to time zone offsets and Daylight Saving Time, which can lead to data inconsistencies and complex debugging.
Using a single, universal time zone ensures all logs, timestamps, and scheduled tasks are aligned. This is critical for monitoring and debugging a distributed system like an AI-agent deployment. You can quickly compare events from different parts of your system without worrying about time zone conversions.
When storing time-sensitive data in a database, saving it in UTC simplifies queries and sorting. You can easily convert the UTC time to a user’s local time on the front end, ensuring they see timestamps that are relevant to their location. This approach separates the back-end’s logical time from the front-end’s display time, a fundamental principle of modern web development.
For an application that will be scaled across different geographic regions with tools like Kubernetes, a unified time zone is essential. It prevents data corruption and ensures synchronization, a core requirement for highly available and reliable services.
By adopting UTC as our standard, we build a more resilient and scalable application from the ground up, providing a seamless and accurate experience for users regardless of their location.
Let’s configure Nginx
# Default nginx definition /docker/prod/nginx/nginx.conf
worker_processes auto;
error_log stderr warn;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
# Define custom log format to include reponse times
log_format main_timed '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'$request_time $upstream_response_time $pipe $upstream_cache_status';
access_log /dev/stdout main_timed;
error_log /dev/stderr notice;
keepalive_timeout 65;
# Write temporary files to /tmp so they can be created as a non-privileged user
client_body_temp_path /tmp/client_temp;
proxy_temp_path /tmp/proxy_temp_path;
fastcgi_temp_path /tmp/fastcgi_temp;
uwsgi_temp_path /tmp/uwsgi_temp;
scgi_temp_path /tmp/scgi_temp;
# Hardening
proxy_hide_header X-Powered-By;
fastcgi_hide_header X-Powered-By;
server_tokens off;
# Enable gzip compression by default
gzip on;
gzip_proxied any;
gzip_types text/plain application/xml text/css text/js text/xml application/x-javascript text/javascript application/json application/xml+rss;
gzip_vary on;
gzip_disable "msie6";
# Include server configs
include /etc/nginx/conf.d/*.conf;
proxy_request_buffering off;
proxy_http_version 1.1;
client_max_body_size 0;
proxy_buffering off;
}
We can indeed use the Nginx configuration file to terminate CORS (Cross-Origin Resource Sharing) and SSL requests directly within our container. This is a quick and effective solution for simpler applications or for development environments. It allows us to control which domains can access our API, ensuring a basic level of security.
# Default server definition /docker/prod/nginx/conf.d/default.conf
server {
listen [::]:8080 default_server;
listen 8080 default_server;
server_name _;
sendfile off;
tcp_nodelay on;
absolute_redirect off;
root /data/www/public;
index index.php index.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to index.php
try_files $uri $uri/ /index.php?q=$uri&$args;
}
# Redirect server error pages to the static page /50x.html
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/lib/nginx/html;
}
# Pass the PHP scripts to PHP-FPM listening on php-fpm.sock
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_buffers 16 32k;
fastcgi_buffer_size 64k;
fastcgi_busy_buffers_size 64k;
}
# Set the cache-control headers on assets to cache for 5 days
location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
expires 5d;
}
# Deny access to . files, for security
location ~ /\. {
log_not_found off;
deny all;
}
# Allow fpm ping and status from localhost
location ~ ^/(fpm-status|fpm-ping)$ {
access_log off;
allow 127.0.0.1;
deny all;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_pass unix:/run/php-fpm.sock;
}
client_max_body_size 1G;
}
However, as you correctly noted, for a robust production environment, a more advanced approach is the API Gateway pattern. An API Gateway sits in front of all internal services, acting as a single entry point for all API requests.
The API Gateway Pattern
Unlike handling CORS, SSL at the individual service level with Nginx, an API Gateway provides a centralized location for managing a variety of concerns, including:
CORS: A single, consistent place to define and enforce cross-origin policies for all services.
JWT (JSON Web Token) Validation: Centralized authentication and authorization, so individual services don’t need to handle it.
Throttling: Protecting your services from abuse by limiting the number of requests from a specific client.
Routing: Directing incoming requests to the correct internal service or microservice.
By using an API Gateway, we maintain a clean separation of concerns. Our internal services, including the Dockerized Symfony AI agent, can focus solely on their core business logic, while the gateway handles all the boilerplate security and routing tasks. This architecture is essential for building scalable, secure, and maintainable applications.
Let’s configure PHP
We’ll modify key parameters to optimize our Symfony application for a production environment, ensuring it can handle various tasks efficiently.
# Default php definition /docker/prod/php/php.ini
[Date]
date.timezone="UTC"
expose_php= Off
memory_limit = 512M
max_input_vars = 10000
post_max_size = 500M
upload_max_filesize = 500M
Configure PHP-FPM
This configuration defines a PHP-FPM process pool that listens on a Unix socket, a highly efficient method for inter-process communication within our single container.
[global]
; Log to stderr
error_log = /dev/stderr
[www]
; The address on which to accept FastCGI requests.
; Valid syntaxes are:
; 'ip.add.re.ss:port' - to listen on a TCP socket to a specific IPv4 address on
; a specific port;
; '[ip:6:addr:ess]:port' - to listen on a TCP socket to a specific IPv6 address on
; a specific port;
; 'port' - to listen on a TCP socket to all addresses
; (IPv6 and IPv4-mapped) on a specific port;
; '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
listen = /run/php-fpm.sock
; Enable status page
pm.status_path = /fpm-status
; Ondemand process manager
pm = dynamic
; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes when pm is set to 'dynamic' or 'ondemand'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
; CGI. The below defaults are based on a server without much resources. Don't
; forget to tweak pm.* to fit your needs.
; Note: Used when pm is set to 'static', 'dynamic' or 'ondemand'
; Note: This value is mandatory.
pm.max_children = 50
; The number of seconds after which an idle process will be killed.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 10s
pm.process_idle_timeout = 10s;
; The number of requests each child process should execute before respawning.
; This can be useful to work around memory leaks in 3rd party libraries. For
; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS.
; Default Value: 0
pm.max_requests = 500
; Make sure the FPM workers can reach the environment variables for configuration
clear_env = no
; Catch output from PHP
catch_workers_output = yes
; Remove the 'child 10 said into stderr' prefix in the log and only show the actual message
decorate_workers_output = no
; Enable ping page to use in healthcheck
ping.path = /fpm-ping
php_admin_value[memory_limit] =512M
php_admin_value[post_max_size] =512M
php_admin_value[upload_max_filesize] =512M
php_admin_value[max_input_vars] = 100000
The pm (process manager) settings are crucial for performance, dynamically adjusting the number of worker processes to handle the application’s load. This prevents a high number of requests from overwhelming the system and ensures a steady supply of idle processes to respond quickly. This setup provides the robust foundation needed for a scalable Dockerized Symfony AI agent.
Time to configure Supervisord
[supervisord]
nodaemon=true
logfile=/dev/null
logfile_maxbytes=0
pidfile=/run/supervisord.pid
[program:ai-agent-bus-consumer]
environment=MESSENGER_CONSUMER_NAME="consumer_%(program_name)s_%(process_num)02d"
command=/data/www/bin/console --env=prod --time-limit=3600 messenger:consume -all
process_name=%(program_name)s_%(process_num)02d
numprocs=4
autostart=true
autorestart=true
startsecs=0
user=appuser
redirect_stderr=true
[program:php-fpm]
command=php-fpm83 -F
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
autorestart=false
startretries=0
[program:nginx]
command=nginx -g 'daemon off;'
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
autorestart=false
startretries=0
Using the Redis Transport, each worker needs a unique consumer name to prevent messages from being handled by multiple workers. A common and effective method to achieve this is by setting an environment variable directly within the Supervisor configuration file. This variable, which can be dynamically referenced in messenger.yaml file, guarantees that each worker instance has a distinct identifier.
framework:
messenger:
default_bus: core.command.bus
buses:
core.command.bus:
default_middleware:
enabled: true
allow_no_handlers: false
allow_no_senders: false
core.query.bus:
default_middleware:
enabled: true
allow_no_handlers: true
allow_no_senders: true
core.event.bus:
default_middleware:
enabled: true
allow_no_handlers: true
allow_no_senders: true
transports:
main.transport:
dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
options:
consumer: '%env(MESSENGER_CONSUMER_NAME)%'
routing:
'*': [main.transport]
App\Message\Command\AIAgentSummarizeMessage: [main.transport]
App\Message\Command\NotifySummarizedMessage: [main.transport]
Dockerizing Symfony AI Agent
It’s time for the most exciting part: building our application image. For this, we’ll create two essential files: .dockerignore and Dockerfile.
The .dockerignore File
Think of the .dockerignore file as a gatekeeper for your Docker build. It tells the Docker daemon which files and directories to ignore when building the image.
This is a critical step for two main reasons:
Speed: It significantly reduces the size of the build context, making the build process much faster. You don’t want to send unnecessary files like development logs, cache directories, or node_modules to the Docker daemon.
Security and Efficiency: By ignoring temporary and sensitive files (e.g., .env files with secrets), you create a leaner and more secure image. A clean image is easier to manage and deploy.
Your .dockerignore file should look something like this:
**/*.log
**/*.md
**/*.php~
**/*.dist.php
**/*.dist
**/*.cache
**/._*
**/.dockerignore
**/.DS_Store
**/.git/
**/.gitattributes
**/.gitignore
**/.gitmodules
**/docker-compose.*.yaml
**/docker-compose.*.yml
**/docker-compose.yaml
**/docker-compose.yml
**/docker-compose.yaml
**/compose*.yaml
**/compose*.yml
**/Dockerfile
**/Thumbs.db
.git/
docs/
tests/
var/
vendor/
.editorconfig
.env.*.local
.env.local
.env.local.php
.env.test
The Dockerfile
The Dockerfile is the blueprint for our application image. It contains a series of instructions that Docker will execute to build the image layer by layer. Each command in the Dockerfile creates a new layer, and Docker caches these layers to speed up subsequent builds.
This is where all the previous steps — from setting up Nginx and PHP configurations to defining our application’s dependencies — come together. The Dockerfile will install the necessary software, copy our application code, and configure the services, all in a repeatable and automated way. This is the heart of our Dockerized Symfony deployment.
FROM alpine:latest
RUN mkdir -p /data/www
WORKDIR /data/www
# Install packages and remove default server definition
RUN apk add --no-cache \
icu-data-full \
curl \
gcc \
git \
musl-dev\
make\
nginx \
libsodium \
openssl \
curl-dev\
pkgconfig \
php83 \
php83-dev \
php83-bcmath\
php83-ctype \
php83-cli\
php83-curl \
php83-dom \
php83-fileinfo \
php83-fpm \
php83-gettext \
php83-gd \
php83-gmp \
php83-iconv \
php83-intl \
php83-imap \
php83-json \
php83-mbstring \
php83-opcache \
php83-openssl \
php83-phar \
php83-redis \
php83-session \
php83-sqlite3 \
php83-sodium \
php83-sockets \
php83-tokenizer \
php83-xml \
php83-xmlwriter \
php83-xmlreader \
php83-xsl \
php83-simplexml \
php83-pear \
php83-zip \
supervisor \
tar \
zip \
unzip
COPY docker/prod/nginx/nginx.conf /etc/nginx/nginx.conf
COPY docker/prod/nginx/conf.d /etc/nginx/conf.d/
COPY docker/prod/php-fpm/fpm-pool.conf /etc/php83/php-fpm.d/www.conf
# Configure PHP
COPY docker/prod/php/php.ini /etc/php83/conf.d/custom.ini
# Configure supervisord
COPY docker/prod/supervisord/supervisord.conf /etc/supervisor/conf.d/supervisord.conf
#add composer
COPY --from=composer:latest /usr/bin/composer /usr/local/bin/composer
# Create a group and user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
# Make sure files/folders needed by the processes are accessable when they run under the appuser user
RUN chown -R appuser:appgroup /data/www /run /var/lib/nginx /var/log/nginx
# Switch to use a non-root user from here on
USER appuser
# Add application
COPY --chown=appuser:appgroup . /data/www
RUN rm -rf /data/www/docker
RUN /usr/local/bin/composer install --no-interaction --optimize-autoloader
# Let supervisord start nginx & php-fpm
CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]
# Configure a healthcheck to validate that everything is up&running
HEALTHCHECK --timeout=10s CMD supervisorctl status
We need to make an important note: we’re bundling all Composer dependencies directly into our Docker image. This is a deliberate strategy to ensure the application has all the necessary components upon startup, making it self-contained and highly reliable.
This approach significantly increases the stability of the entire system. Every time you rebuild an image with updated dependencies, you risk pulling in different versions of libraries, which can lead to unexpected behavior or conflicts. By packaging a fixed set of dependencies into the image, we guarantee that the application’s environment remains consistent across all deployments. This is a core tenet of immutable infrastructure and is crucial for creating a predictable and robust AI-agent deployment.
Now, with the .dockerignore and Dockerfile in place, we can build our image. We have two primary options to initiate this process: manually using the docker build command or automating it within a CI/CD pipeline.
In this example, we’re using a HEALTHCHECK that checks the status of the Supervisord service. This is somewhat incorrect, as it only tells us if Supervisord is running, not if our actual application is operational or if Supervisord is in a constant loop of restarting failed services. We’ll solve this issue in future articles using both an internal checker and Prometheus agents.
This is a crucial distinction to make. While a simple health check on the process manager (like Supervisord) can tell you if the container is up, it provides no insight into the application’s health. For a truly robust and scalable AI-agent deployment, we need a deeper check that can verify:
Application Logic: Is the web server responding with a 200 OK status? Is the database connection working?
Business Logic: Is the message bus consumer actively processing tasks? Is the AI model loaded and ready?
In the future, we will explore advanced observability techniques using tools like Prometheus and its agents. By collecting and analyzing metrics on the application’s performance, we can create more intelligent and reliable health checks that truly reflect the system’s operational status. This ensures that our Kubernetes cluster can make informed decisions about when to restart a container, leading to a more resilient and self-healing system.
Manual Build with docker build
For local development and initial testing, the docker build command is the quickest way to create your image. You simply navigate to the directory containing your Dockerfile and run a command like this:
docker build -t your-image-name:latest .
This command takes all the instructions from your Dockerfile, uses the current directory as the build context, and creates a new image tagged with the name and version you specify. This is perfect for verifying your configurations and ensuring everything works as expected before pushing it to a registry.
Automating with a CI/CD Pipeline
For a professional, scalable AI-agent deployment, a CI/CD pipeline is the industry standard. Tools like GitHub Actions, GitLab CI/CD, or Jenkins can automate the entire build and deployment process.
This automated approach ensures consistency, reduces manual errors, and provides a clear audit trail for every deployment. For a serious project, especially one as complex as an AI agent, this level of automation is not just a convenience — it’s a necessity.
However, we’ll dive into the full scope of CI/CD automation for builds and deployments in our future articles.
We’re now at the final, pivotal stage. All that remains is to prepare our docker-compose.yaml file, define the essential environment variables, and launch our application inside the container.
The Grand Finale: Automated Deployment
This is where all our hard work comes together. The docker-compose.yaml file acts as our single command center, orchestrating the launch of our entire containerized application. By externalizing key settings as environment variables, we ensure our application is highly flexible and portable, seamlessly adapting to different environments without requiring any code changes. This is a cornerstone of modern DevOps practices and is crucial for scalable AI-agent deployment.
services:
# The main application service
app:
# Use the image we will build from the Dockerfile in the current directory
build: .
container_name: symfony_ai_agent
# Set environmental variables for the container
environment:
- TZ=UTC
- APP_ENV=dev
- OPENAI_API_KEY=your_api_key
- MAILER_DSN=your_mailer_dsn
- IMAP_HOST=your_imap_host
- IMAP_USERNAME=your_imap_user_name
- IMAP_PASSWORD=your_imap_password
- REDIS_DSN_CACHE=redis://redis:6379/11
- MESSENGER_TRANSPORT_DSN=redis://redis:6379/messages
- MESSENGER_CONSUMER_NAME=appConsumer
# Expose the default App port / for this case not nessesary
ports:
- "8080:8080"
# Define a dependency on the Redis service
depends_on:
- redis
# Ensure the container will restart automatically if it fails
restart: always
# The Redis service
redis:
# Use the official Redis image
image: redis:6.2-alpine
container_name: redis_ai_agent
# Expose the default Redis port
ports:
- "6379:6379"
# Ensure the container will restart automatically if it fails
restart: always
In this example, Redis data may be lost upon a container restart. To prevent this, you can mount an external volume where Redis can persist its state before shutting down and reinitialize it before starting again.
If you intend to run several application containers, a shared Redis instance accessible to all containers via the network would be a better solution.
And now we’re ready to start out app:
docker-compose up
Once launched with a single command, our application will immediately transition into a fully automated, self-contained system. The days of manual setup and configuration are behind us. The application, bundled with all its dependencies and services, is now ready to perform its tasks autonomously.
We have successfully built a robust, professional-grade foundation for a Symfony AI agent that is designed to thrive in any microservices architecture.
Conclusion
Throughout this guide, we’ve laid the groundwork for building a robust and scalable AI-agent deployment pipeline using Docker and Symfony. By adopting a methodical containerization strategy, we have bundled essential services like Nginx and PHP-FPM into a single, cohesive Docker image. We have meticulously configured each component, from standardizing on UTC for time to preparing our application for efficient asynchronous message processing. This detailed approach ensures our application is consistent, reproducible, and ready to be deployed across any environment.
While we have focused on creating a foundational, immutable image, the real power of this strategy lies in its potential for automation and advanced scalability. The principles we have established here are the perfect starting point for an automated CI/CD pipeline, which we will explore in future articles. By mastering these core Docker and DevOps principles, we can confidently simplify the complexity of deploying modern AI agents, turning a challenging task into a streamlined and reliable process.
Stay tuned — and let’s keep the conversation going.
