Should Docker be used in a non devops, not very agile environment? [closed]

Imagine yourself at the beginning of a new web app project. The usual infrastructure needs to be set up – databases, webservers, appservers. From the very start you know that this project is going to be very waterfally, with strict devision between dev team, deployment team, ops team, etc. No continuous deployments, no continuous anything.

Does it make any sense to advocate the use of docker for a project like this?

  • How can I keep container running on Kubernetes?
  • Docker: Unable to specify port for a running container
  • Enter docker container from host using docker-machine
  • Running ipython notebook in a Docker Container
  • Can't connect to my Bluemix container (Connection: close)
  • Check for network error in cf ic login in Bluemix
  • Are there any hidden advantages to using docker that I’m missing?

    Edit: The point made by @VonC below is perfectly valid, what I’m looking for here however are arguments for or against embracing docker in the development/release process itself.

  • How to set up container using Docker Compose to use a static IP and be accessible outside of VM host?
  • docker build fails on a cloud VM
  • docker container port accessed from another container
  • OpenVSwitch in container with IP-Tables
  • Is it possible to run GUI apps in windows containers?
  • Can I transport just the image changes/layers i'm concerned with?
  • 2 Solutions collect form web for “Should Docker be used in a non devops, not very agile environment? [closed]”

    In that case, docker can be used for specifying a development environment, that is an image which includes:

    • the right language pre-installed
    • the right IDE with the right settings
    • the right tools at the right version

    That way, a developper only has to pull and run an image dedicated to dev, and can start working right away, without having anything to configure.

    arguments for or against embracing docker in the development/release process itself

    This is mainly about the ability to reproduce an execution environment.
    That may not be for continuous integration/deployment in your case, but that remains useful for developing in an environment “like” (or “close to”) production, which can be easily rebuilt on the production machine at any time.

    • Consistent Development/Production environments (no need for Vagrant or the like)
    • Provisioning with Docker is much simpler
    • If you want to employ a microservices pattern, then Docker makes a LOT of sense regardless of the lifecycle.
    • Making full-use of Docker also forces you to build better apps in my opinion.
      • It encourages you to create highly-decoupled/12-factor apps
      • Everything is disposable – containers, servers, load balancers, etc. If you have a problem with a server, destroy/replace it.
      • Using Service Discovery patterns makes scaling much simpler and much more dynamic
    • Docker infrastructure – once setup, scales to multiple applications easily, saving time in the long-run.
      • Server clusters
      • Service Registration/Discovery mechanisms
      • DNS handling & Dynamic Load Balancing
      • …all these, once setup, will work for multiple applications
    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.