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?

  • Error during compilation / installation of libcontainer due to custom-build kernel
  • Invoke docker container from Jenkins pipeline which is also running as docker container on Windows for docker (for Windows 10)
  • cf ic plugin not able to find docker daemon while authentication
  • Docker Compose in Bluemix KeyError Message
  • Can't attach to bash running the Docker container
  • Docker container stops running only when volume is attached
  • 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.

  • bluemix container KO with ip public but OK in local
  • Connecting Docker container to corporate LDAP server through SSL
  • Docker: mounting local directories as a non-root user in a container
  • Bluemix port binding
  • Difference between of intermediate_ip_address and private_ip_address in bluemix container groups
  • Should I use separate Docker containers for my web app?
  • 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.