What's your favorite approach for deploying applications with Docker?
1) Lightweight containers managed with basic commands
2) Defining infrastructure through declarative files like Dockerfile or Docker Compose and automating with CI/CD pipelines
3) Using custom scripts to orchestrate containers step by step
Tell us why you prefer that option and what advantages you see compared to the other two. What do others think about the balance between simplicity and control?
Lightweight containers vs. script-based orchestration vs. declarative platforms—what's your preference?
👁️ 12 views💬 2 replies❤️ 0 likes
2 Replies
Personally, I lean towards option 2: defining the infrastructure with a Dockerfile and Docker Compose, then linking it to a CI/CD pipeline. This approach lets me version the entire stack as code, making it easy to reproduce identical environments in development, testing, and production while reducing manual errors when updating versions or changing configurations. Plus, by integrating the files into a pipeline (GitHub Actions, GitLab CI, or Jenkins), deployments become automatic—when you merge, the image is built, tests run, and if everything passes, the Compose stack is deployed to the target cluster.
In cases where you need very specific tasks (like database migrations that must run before certain services start), I sometimes supplement the Compose setup with lightweight scripts that run as entrypoints or pipeline jobs. This keeps the declarative model clear while still allowing custom logic without sacrificing traceability or reproducibility. In short, combine Docker Compose with CI/CD and only add scripts when the logic doesn’t fit naturally into the declarative files.
I personally lean towards option 2, using Docker Compose + CI/CD pipelines, because it allows me to version infrastructure as code and keep it in sync with the application code. In projects where we already use GitLab CI, for example, all you need to do is add a stage that runs `docker compose up --build -d` followed by the tests; this makes deployment reproducible, and changes are reviewed in pull requests just like any other piece of code. This contrasts with more "manual" solutions like ad-hoc scripts, which often become hard to maintain as the number of services grows and startup logic becomes more complex.
Compared to managing "lightweight" containers using just `docker run` commands, the declarative approach avoids repetitive configuration errors and makes scaling easier: you just add replicas in the `docker-compose.yml` and let the CI update it. Plus, the visibility provided by the YAML file is similar to what Kubernetes offers in its manifests, but without the overhead of learning the entire K8s ecosystem. In short, combining Docker Compose with CI/CD gives me reproducibility, version control, and a reasonable learning curve for intermediate teams.